AI 時代の開発者英語: AGENTS.md・システムプロンプト・RFC — エージェントが読む英語を書く技術

"2026年にあなたが書く最も重要な英語は、人間ではなくエージェントが読む英語だ。"

プロローグ — 英語の読者が変わった

5年前、開発者が英語を書く理由は明確でした。コードレビューで同僚に説明するため。グローバルな issue tracker で海外の同僚と協働するため。カンファレンス talk を英語で行うため。面接で経験を英語で語るため。読者はすべて人間でした。

2026年現在、英語の最も重要な読者が変わりました。1週間で最も多く書く英語は、おそらく同僚に送る Slack メッセージではなく、エージェントが読む英語です。AGENTS.md に書くビルドコマンド。Claude Code セッションのシステムプロンプト。Devin に投げる issue 記述。Codex に渡す PR コンテキスト。RFC に書く non-functional requirements — 2026年の RFC は、人間がまず書き、エージェントがそれを実行可能な単位に分解する文書になりました。

この記事は、このブログのこれまでの英語記事(コードレビュー、standup、年俸交渉、FDE 面接)とは明確に違う角度を取ります。それらはすべて「人間に向けて話す英語」でした。この記事は エージェントに書く英語、そして人間とエージェントの両方が読む英語 を扱います。両者は微妙に、しかし決定的に異なります。

この記事の命題

2026年、開発者が書く英語の中で、単位時間あたり最もレバレッジが高いのは、エージェントが読む英語である。

理由は3つです。

第一に、再利用性。同僚への Slack メッセージは1人が1回読みます。AGENTS.md はチーム全員のすべてのエージェントセッションが毎回読みます。1行の品質差が何千回も繰り返されます。

第二に、literal さ。人間は曖昧な文章をコンテキストで補正します。エージェントは補正しないか、誤った方向に補正します。弱い英語は弱い行動に直結します。

第三に、レバレッジ。1行のよく書かれたシステムプロンプトは、100回の review コメントを置き換えます。1本のよく書かれた RFC は、30個のよく shape された作業に変換されます。

この記事の構成:

1章 · 読者が変わった — 人間とエージェントの違い

英語を上手く書くとは、読者を理解することです。人間の読者とエージェントの読者は、明らかに別の audience です。

1.1 人間はコンテキストで補正する

同僚にこう書いたとします。

We probably want to use the new auth flow for this, unless there's a reason
to stay on the old one. Let me know what you think.

同僚は同時に5つのことを読み取ります。(1) 新しい auth flow を使う提案。(2) 弱い確信(probably)。(3) 反対意見への openness(unless)。(4) 決定権の部分的な委譲(let me know)。(5) フレンドリーな tone(we)。これがすべて成立するのは、同僚が会社のポリティクス、あなたの seniority、過去のやりとり、そして英語話者の hedging 慣習を知っているからです。

同じ文章をエージェントに与えると、エージェントはしばしばこう解釈します — 「新しい auth flow を使う指示。ただし unless と probably があるので、決定を保留してユーザに尋ねよう」。あるいは逆に「新しい auth flow をそのまま適用」。どちらにせよ、人間の読者が自然にたどり着く「一緒に決めよう」という意図とは違います。

1.2 エージェントは token を weight として読む

エージェントは文章を semantic な単位で読みません。token の weight の和として読みます。だからこそ、人間にとっては些細な単語 — should, must, may, prefer, always, never — がエージェントの行動に大きな差を生みます。

核心は、consider と perhaps は人間にとっては温かい推奨だが、エージェントにとってはノイズ であるという点です。エージェントには Use X または Do not use X のどちらかがほぼ常により良いです。

1.3 人間は1回読み、エージェントは毎回読む

AGENTS.md は毎セッション、毎タスク、毎呼び出しで再ロードされます。同僚が README を1回読んで頭に保管するのとは違います。だから AGENTS.md の1行は一回限りのコストではなく、繰り返しコスト です。ノイズ1行が1000回繰り返されれば、1000回分の weight になります。

これが Anthropic の公式推奨の一つ — 「CLAUDE.md のすべての行について、『これがなければ Claude が間違えたか?』 を問え」 — の理由です。答えが No なら、その行はノイズです。

2章 · エージェントは literal に読む — hedging の罠

英語話者が自然に使う表現の中で、最もエージェントを壊すのが hedging です。kind of, sort of, I think, perhaps, it might be that, would probably want to。人間にとっては丁寧さですが、エージェントにとっては SN 比を下げます。

2.1 弱い英語 vs 強い英語 — before / after

before — hedging だらけのシステムプロンプトの一部:

You should probably try to use TypeScript for new files, although JavaScript
might be acceptable in some cases. It would be nice if you could add tests,
but if you don't have time, that's okay too. Please try to follow the
existing code style as much as possible.

エージェントの挙動:

• TypeScript を使うか JavaScript を使うか毎回ユーザに尋ねる
• テストを書かない(if you don't have time が事実上の免罪符)
• コードスタイルは as much as possible — どういう意味か不明

after — 同じ意図、強い英語:

Write all new files in TypeScript. JavaScript is only allowed when modifying
an existing .js file in place — do not convert .js to .ts as part of an
unrelated change.

Write tests for any new function exported from a module. Tests live next to
the source as <name>.test.ts.

Follow the rules in eslint.config.js. If a rule conflicts with your output,
fix your output — never disable the rule.

エージェントの挙動:

• TypeScript で新しいファイルを書く(例外条件が明確)
• export された関数すべてにテストを書く
• lint ルールに従う — 衝突時の挙動も定義されている

核心の変更は3つ:

1. 曖昧語の削除: probably, might, would be nice を消す
2. 例外の明示化: どのケースが例外か正確に書く
3. 衝突時の挙動定義: if X conflicts with Y, do Z

2.2 否定の罠 — エージェントは否定をしばしば無視する

長い否定文はエージェントにとって難しいです。

before:

Do not delete files unless you are sure they are not used by any other
module that you have not yet read.

二重否定と条件の入れ子のため、エージェントはしばしばこの文を「delete files」に単純化します。

after:

Never delete a file in this session. If you believe a file is unused, list
it in your final summary under "Files I would delete" — let the user delete it.

否定を単一の肯定的な行動指示に変え、代替行動を正確に定義しました。エージェントは否定 + 代替行動が並んでいる時、否定をはるかによく守ります。

2.3 If unsure, ask の罠

If unsure, ask the user は注意深く使えば良いですが、naive に書くとエージェントを質問機械にします。unsure の閾値がないからです。

before:

If you are unsure about anything, ask the user before proceeding.

after:

Proceed without asking when: (a) the change is a typo or comment-only fix,
(b) the test suite passes locally, (c) you can produce a unit test that
demonstrates correctness.

Ask the user when: (a) the change touches authentication or billing code,
(b) you cannot find a relevant test, (c) the change requires a new
dependency.

unsure を whitelist と blacklist に置き換えた結果、エージェントはより autonomous で、同時により safe になります。

3章 · AGENTS.md / CLAUDE.md — コンテキストファイルの書き方

AGENTS.md は2026年の最も重要な新文書フォーマットです。OpenAI Codex で convention として始まり、エージェント ecosystem 全体で採用され、現在は Linux Foundation 配下の Agentic AI Foundation が open standard として steward しています。60,000以上のオープンソースプロジェクトが採用しました。CLAUDE.md は Anthropic Claude Code の同等概念です。どちらもプレーンな Markdown ですが、良いものと悪いものの差は大きいです。

3.1 良い AGENTS.md の4つのセクション

良い AGENTS.md は通常この4つを持ちます。

# AGENTS.md

## What this repo is
(エージェントが未知のコードベースで迷わないように — 2〜4行)

## How to build, test, run
(ターミナルコマンド — 正確なコマンド、正確なディレクトリ)

## Conventions
(コードスタイル、命名、ファイル構成 — コードから推測できないもの)

## Boundaries
(エージェントが絶対に触ってはいけないもの)

この構造に従う OpenAI Codex 自体のリポジトリの AGENTS.md は、短く強力です。人間は30秒で読み終え、エージェントは毎回正確に引用します。

3.2 弱い AGENTS.md vs 強い AGENTS.md

before — よく見る弱い AGENTS.md:

# Our Project

This is a Node.js project. We try to follow best practices and write clean code.

## Getting started

You can install dependencies with npm. To run the tests, use the test command.
We use TypeScript and prefer functional patterns when it makes sense.

Please be careful when making changes and try to add tests when appropriate.
If you need to deploy, talk to the platform team.

問題点:

• best practices, clean code — 意味のない signifier
• you can install with npm — 正確なコマンドがない
• when it makes sense — 閾値がない
• when appropriate — 閾値がない

after — 強い AGENTS.md:

# AGENTS.md

## What this repo is
A Next.js 15 app for the customer billing portal. The backend is a separate
service at `api.example.com` — this repo contains only the frontend.

## Setup, build, test
- Install: `pnpm install` (do not use npm or yarn — the lockfile is pnpm)
- Dev server: `pnpm dev` (port 3000)
- Tests: `pnpm test --filter <package>` for a single package, never `pnpm test` for the whole monorepo (it takes 20 plus minutes)
- Typecheck: `pnpm typecheck` — must pass before any commit

## Conventions
- Components: PascalCase files in `src/components/`. One component per file.
- Hooks: `useFoo.ts` in `src/hooks/`. Always return an object, never an array.
- API calls: use `src/lib/api/client.ts` — never call `fetch` directly.
- Styling: Tailwind only. Do not add new CSS files.

## Boundaries
- Never modify `src/generated/` — it is regenerated from OpenAPI in CI.
- Never edit `pnpm-lock.yaml` by hand — use `pnpm install`.
- Never add a dependency without asking — the bundle is already 280 KB and we are tracking it.
- Do not touch `src/billing/legacy/` — it is being deprecated; new features go in `src/billing/v2/`.

パターンは単純です — すべての行が (a) 正確なコマンドまたはパス、(b) 短い why を伴います。why があれば、エージェントはルールがカバーしないエッジケースで一般化できます。

3.3 CLAUDE.md 特有のパターン

CLAUDE.md は Claude Code の全セッションに自動的にロードされます。この点が次の2つのパターンを生みます。

パターン1 — 繰り返しのミスを永久ブロック。 エージェントが同じミスを2回繰り返したら、その教訓を CLAUDE.md に追加します。

## MDX blog rules

Files in `data/blog/` are MDX, pre-rendered at build time. Patterns that
break the build:

- A bare `{identifier}` in prose becomes a JSX expression, which throws a
  ReferenceError. Wrap in backticks or rephrase.
- A `<` followed by a digit makes MDX try to parse a JSX tag. Add a space:
  `< 100`, not `<100`.
- A code fence that opens with stray content after the language identifier
  breaks parsing.

When fixing one variant (.mdx), check all three (.mdx / .en.mdx / .ja.mdx).

パターン2 — painful な操作の明示化。 エージェントはどの作業が遅いか知りません。教える必要があります。

## Slow operations — avoid in agent sessions
- `pnpm install` from a cold cache: 4 minutes
- `pnpm test` for the whole monorepo: 22 minutes
- `next build`: 6 minutes
- E2E tests: 18 minutes — never run them unless explicitly asked

Prefer: `pnpm test --filter <pkg>`, `pnpm typecheck`, `pnpm lint`.

このセクションがあるだけで、エージェントは「テスト一回走らせます」と言って22分を消費する行動を取りません。

4章 · システムプロンプト — プロダクションエージェントのための英語

AGENTS.md が「コードベースについてのコンテキスト」なら、システムプロンプト は「エージェントの役割定義」です。プロダクションで動くエージェントなら、この2つが明確に分離されている必要があります。

4.1 システムプロンプトの5セクション(Anthropic の推奨)

Anthropic の prompt engineering ガイドに従った構造:

1. Role and persona       — 君は誰か
2. Context                — どんな環境で動くか
3. Capabilities and tools — 何ができるか
4. Rules and constraints  — 絶対にやってはいけないこと
5. Output format          — 結果をどう返すか

例 — カスタマーサポートエージェントの骨格:

ROLE
You are the support assistant for Example Corp. You handle questions about
billing, account access, and subscription changes. You do not handle
refunds — those are escalated to a human agent.

CONTEXT
You have access to the user's account through the get_account tool. You do
not have access to payment methods, internal Slack, or engineering tickets.
The current date is in the user message.

CAPABILITIES
- Look up account state with get_account
- Trigger a password reset with send_password_reset
- Open a refund ticket with create_refund_ticket (this hands off to a human)

RULES
- Never reveal another user's data.
- Never tell the user about internal tools or model names.
- If the user asks for a refund, do not promise it — create a ticket and tell
  them a human will follow up within one business day.
- If you are unsure whether an action is allowed, do not do it. Ask.

OUTPUT
Reply in plain English, at most two to four short paragraphs. End with a
single sentence stating what action you took or will take next.

この構造の強み — 各セクションが単一の意図を持ちます。新しいツールが追加されたら CAPABILITIES だけ変更。新しい禁止事項が追加されたら RULES だけ変更。maintainable な英語です。

4.2 システムプロンプトのアンチパターン

アンチパターン1 — 例文の爆発。 初めて書く人は10〜20個の例を詰め込みます。Anthropic の推奨はその逆 — 「diverse で canonical な例3〜5個」が、矛盾だらけの50個に勝ります。例が多すぎると overfitting を起こし、エージェントが一般化する能力を失います。

アンチパターン2 — 形容詞パレード。 Be helpful, professional, friendly, concise, accurate, thoughtful, careful。7つの形容詞は互いに弱め合います。2つ選んで — Direct and concise. No filler. — 正確に定義する。

アンチパターン3 — メタ指示。 Think carefully before answering。人間には意味がありますが、エージェントにはしばしばノイズです。具体的な reasoning step を指示するか(Think step by step about X)、いっそ書かないかのどちらかが良いです。

4.3 system message vs user message

英語をどこに書くかが重要です。セッション一定のルールはシステムプロンプトに。1回のリクエストに固有の情報はユーザメッセージに。

before — すべてをシステムプロンプトに:

You are a code reviewer. The user is reviewing PR #1234, which adds a new
billing flow. The PR description is: "..."

問題 — 次の PR をレビューする時、システムプロンプトを書き直す必要があります。

after — 分離:

SYSTEM
You are a code reviewer for this monorepo. Focus on correctness, security,
and consistency with the patterns in src/lib/. Do not comment on style — a
linter handles that.

USER
Review PR #1234. The diff is below. The author claims it adds a new billing
flow.
[diff]

システムプロンプトは再利用可能、ユーザメッセージは毎回違う。きれいな分離です。

5章 · RFC とデザインドック — 人間とエージェントが同時に読む文書

RFC とデザインドックは技術英語の頂点です。2026年、その文書の audience に エージェントが追加 されました。エージェントは RFC を受け取って作業単位に分解し、一部の作業を自ら実行することもあります。

5.1 人間だけが読んでいた RFC の弱点

伝統的な RFC はしばしば次の弱点を持ちます。

• how を曖昧に残す — 実装者の autonomy を尊重するため
• 決定の why を本文に散在させる — 人間は統合して読む
• non-functional requirements を自由に書く — should be fast enough
• alternatives を短く言及する — we considered X but decided not to

これらすべては人間には十分ですが、エージェントはこのような RFC から明確な作業単位を抽出できません。

5.2 エージェントも読む RFC の新しい構造

1. TL;DR (1 paragraph)         — 人間が30秒で読む
2. Problem                     — なぜ今やるのか
3. Goals / non-goals           — 明示的な境界
4. Proposal                    — 何を作るか
5. Detailed design             — どう作るか
6. Alternatives considered     — なぜ他の道を取らなかったか
7. Open questions              — まだ決まっていないこと
8. Work breakdown (NEW)        — 作業単位(エージェントが行動可能)
9. Acceptance criteria (NEW)   — 完了の定義
10. Non-functional requirements (latency, throughput, error budget — 数字で)

伝統的な RFC に対して2つ追加されます — Work breakdown と Acceptance criteria。どちらもエージェントが直接行動の起点として使えるよう書く必要があります。

before — 曖昧な work breakdown:

We will need to update the API, the frontend, and add some tests.

after — 行動可能な work breakdown:

1. Add POST /v2/billing/preview endpoint
   - Request: BillingPreviewRequest (new schema)
   - Response: BillingPreviewResponse
   - Backed by services.billing.preview()
   - File: services/billing/handlers/preview.ts (new)
   - Estimated diff: ~150 lines

2. Add usePreview hook
   - File: src/hooks/usePreview.ts (new)
   - Wraps the new endpoint with TanStack Query
   - Estimated diff: ~40 lines

3. Wire the hook into BillingScreen
   - File: src/screens/BillingScreen.tsx (modify)
   - Loading and error states required
   - Estimated diff: ~80 lines

4. Tests
   - Unit: services/billing/preview.test.ts
   - Integration: e2e/billing/preview.spec.ts

違いは単純です — 各項目が (a) 動詞で始まり、(b) 正確なファイルを指し、(c) おおよそのサイズを示します。人間も review しやすく、エージェントはそのまま行動できます。

5.3 non-functional requirements は数字で

エージェント時代以前からの良い慣習ですが、エージェントが入ることで重要性が増しました。

before:

The new endpoint should be fast. It should handle our peak traffic.

after:

- p99 latency under 200 ms at 500 requests per second.
- Error rate under 0.5 percent over any 5 minute window.
- The endpoint must not push upstream Postgres CPU above 60 percent during
  peak — current peak is 38 percent.
- If the endpoint fails for more than 30 seconds, fall back to the existing
  billing summary endpoint (graceful degradation).

数字があれば人間も review でき、エージェントは負荷テストを作る時に正確な目標を持てます。

6章 · Issue / ticket — エージェントが行動できる記述

Devin, Codex Cloud, GitHub Copilot Workspace のような ticket ベースのエージェントが2026年の標準になり、issue の書き方が、そのままエージェントの作業を shape する方法 になりました。

6.1 人間用 issue vs エージェント用 issue

人間の開発者が受け取る issue は通常こうです。

Title: Login form looks broken on mobile

Description: Hey, when I try to log in on my phone, the form looks weird.
The button is cut off and I can't really submit. Can you take a look?

人間の開発者はこの issue を受け取ると、自分のスマホを取り出して再現し、デザイナーに意図を尋ね、類似 issue を検索し、ようやく作業を始めます。エージェントにこの issue だけを与えたら、ほぼ何もできません。

同じ問題をエージェントが行動できる形に:

Title: LoginForm submit button truncated on mobile viewport

Reproduction
1. Open http://localhost:3000/login in Chrome
2. Open DevTools and select the "iPhone 14 Pro" viewport (393x852)
3. Observe that the submit button extends past the right edge of the form
4. Expected: the submit button is fully visible and aligned to the form's right edge

Suspected cause
The form container has `max-width: 400px`, but at viewports under 400px
plus the form's padding, content overflows. See `src/components/LoginForm.tsx`
around line 45.

Acceptance criteria
- The submit button is fully visible at all viewports 320 px wide and above
- No visual regression on desktop (1024 px and above)
- The existing Playwright login test still passes

Out of scope
- Do not redesign the form
- Do not change the button text or color
- Do not touch the OAuth button — it is being redone in #1240

長く見えますが — エージェントはこの issue を受け取った直後に正確にスタートでき、人間が review する時にも何が完了し何が抜けているかが明確です。Out of scope が特に重要 です。エージェントの最も多いミスは「道を掃除していたら隣家の庭まで掃除した」型です。境界を明示すれば防げます。

6.2 issue 作成テンプレート

チーム全体で使えるテンプレート:

## Context
(1-3 sentences — why this matters now)

## Reproduction or scenario
(numbered steps for bugs; a concrete user story for features)

## Acceptance criteria
- ...
- ...

## Out of scope
- ...

## Related
- linked issues, ADRs, RFCs

Out of scope が新たな追加です。人間の開発者には暗黙だったものを、エージェントには明示する必要があります。

7章 · Commit message と PR description — AI ファースト workflow

commit message と PR description は、最も頻繁に書く英語であり、エージェントが頻繁に読み、ますます頻繁に書く英語です。

7.1 良い commit message(Conventional Commits + why)

before:

fix bug

after:

fix(billing): prevent double-charge when retry follows a partial failure

The retry path was not idempotent because we generated a new idempotency
key on every attempt. We now reuse the key for the whole transaction
attempt, scoped to the user and order id.

Repro: tests/billing/retry.test.ts::"survives partial gateway failure"

3要素 — (1) type(scope): summary、(2) why の段落、(3) 再現またはテストの場所。人間も読みやすく、次にこの領域を触るエージェントが感謝します。

7.2 AI が書いた PR description vs 人間が書いた PR description

AI が自動生成する PR description には共通する弱点があります。

• 変更行を列挙するだけ(Updated A, B, C)
• why がほぼない
• すべての変更を equal に扱う — 主要と付随の区別がない

良い PR description は、人間が短く書こうとエージェントが長く書こうと、次を持ちます。

## What
(1-2 paragraphs — what changes, in business terms)

## Why
(why now, why this approach)

## How (only if non-obvious)
(design choices that the code does not reveal)

## Risks
(what could break, how you looked)

## Test plan
(how you verified — commands run, screens seen, logs read)

エージェントに PR description を生成させる時 — この5セクションを明示的に要求すれば、結果は劇的に良くなります。

7.3 Co-authored-by と誠実さ

AI が共に書いたコードを正直に記録することは、倫理的にも実用的にも重要です。Co-Authored-By: Claude のような表記は、後でその commit を見返す時に「これは AI が最初に書き、自分が review した」という signal になります。6ヶ月後に同じ領域を debug する時、この signal は大きな価値を持ちます。

8章 · プロンプトライティングを craft として

ここまで読んで一つのことが明らかになっているはずです。エージェントのために英語を書くことは、本質的に良い技術英語を書くことと同じ です。良い RFC を書く人は良いシステムプロンプトを書く可能性が高く、逆もまた然りです。

8.1 良い英語の一般原則 — エージェント時代版

原則1 — 1段落に1意図。 人間も歓迎し、エージェントは必要とします。1段落にコマンドと例外とトーンが混ざると、全員が苦しみます。

原則2 — 明示的コンテキスト。 as discussed yesterday は同僚には明示的ですが、エージェントには空白です。コンテキストを毎回書くか、もっと良いのは永続文書に置くこと。

原則3 — 名前のついた制約。 this should be fast ではなく p99 under 200 ms。secure ではなく no plaintext credentials in logs。名前のついた制約は検証可能です。

原則4 — 衝突時の挙動定義。 良い英語には常に if X conflicts with Y, do Z が含まれます。衝突が定義されていなければ、エージェントはどちらかを arbitrary に選び、その選択はしばしば間違っています。

原則5 — 具体的な例。 抽象的なルール1個より canonical な例3個の方が機能します。ただし — 例は internally consistent である必要があります。

8.2 文章を短くする技術

AGENTS.md とシステムプロンプトは短いほど強いです。短くする5つの技術:

1. 強調語を削除: very, really, quite, somewhat — ほぼ常に削除可能
2. 名詞化を解く: perform a review of ではなく review
3. 能動態を選ぶ: tests are to be written ではなく write tests
4. bullet 1つに command 1つ: 2つ混ざっていたら分割
5. 重複を削除: 同じルールが2回出てきたら、1つ消すか、もう1つは別の側面を扱うように書き直す

良いシステムプロンプトは良い詩のようなもの — 単語を1つ抜くと意味が弱まる状態です。

8.3 canonical な例の curate

Anthropic は「diverse で canonical な例3つ」を推奨します。canonical という単語が重要です。例は単に動くものではなく — 「我々のチームはこう働く」 の標本である必要があります。違和感のある例は違和感のある挙動を一般化させます。

良い例のチェックリスト:

• 変更の意図が明確
• コードスタイルがチームの median と一致
• エッジケースを1つ扱う(0個は単純すぎ、多すぎはノイズ)
• 一般化可能なパターン

9章 · 丁寧さと直接さの trade-off

英語話者にとって直接的なトーンはしばしば失礼に聞こえます。Do this よりも Could you do this の方が自然です。しかしエージェントに書く英語では、その丁寧さがコストになります。

9.1 2つの audience を同時に満たす

AGENTS.md は人間とエージェントが同時に読みます。直接すぎると人間が拒絶感を持ち(「このチーム冷たいな」)、丁寧すぎるとエージェントにノイズになります。中間は可能です。

before — 冷たいトーン:

Do not delete files. Do not modify generated code. Do not add dependencies.

after — 明確だが人間的なトーン:

Working with this repo:
- Files are precious — we prefer marking unused files in a summary over deleting them.
- Generated code lives in `src/generated/` — it is regenerated by CI, so do not edit by hand.
- Dependencies are tracked carefully — please ask before adding a new one. The bundle is at 280 KB and growing.

違い — 命令は同じですが、(1) 短い why を添え、(2) we と please のような人間のトーンを維持します。エージェントは命令を正確に従い、人間は文章を心地よく受け取ります。

9.2 自動化メッセージのトーン

CI が自動で付ける PR コメント、standup bot のメッセージ — これらの自動化メッセージの英語がチーム文化を定義します。Failed と This pull request did not pass the required checks は同じ情報ですが、後者の方が人間的です。エージェント時代こそ、自動メッセージの英語に時間をかける価値があります。

9.3 弱い英語が丁寧であるという神話

Could you maybe consider possibly trying to... のような multi-hedge は丁寧ではなく — 自信のなさです。英語ライティングコーチが長年教えてきたことが、エージェント時代に改めて強調されます: 明確さが最高の丁寧さ。エージェントも人間も、受け手の時間を減らすことが本当の配慮です。

エピローグ — エージェントが読む英語をうまく書くために

チェックリスト — AGENTS.md / システムプロンプトを書く前に

• 読者が誰か書いた — 人間のみ、エージェントのみ、または両方
• すべての行について「これがなければエージェントが間違えたか?」を問うた
• hedging(probably, perhaps, kind of, somewhat)を削除した
• non-functional requirements を数字で書いた(latency, throughput, error rate)
• 重要なルールには if X conflicts with Y, do Z の衝突定義がある
• Out of scope / Boundaries セクションがある
• 例は3つ以下、すべてチーム標準に合致
• 短い — 他人が30秒で最後まで読める
• 丁寧さを短い why で表現し、hedging で表現していない

アンチパターン集

一行要約

2026年の良い開発者英語は、人間とエージェントが同時に30秒で最後まで読み、同じ行動にたどり着く英語である。

次回予告

この記事は英語 — 一つの自然言語 — が人間とエージェントの両方にどう向かうかを扱いました。次回はその英語が呼び出すインターフェース、MCP(Model Context Protocol)とツール設計の craft を扱います。良いツールの説明書がどう良く書かれた function signature に似ているか、ツールの説明での弱い英語がなぜエージェントの失敗を作るか — この記事の自然な後編です。

開発者として英語を上手く書きたいなら、最速の道は — 同僚に向けた英語を一段階減らし、エージェントが読む英語を一段階増やすことです。そこで仕事の形が変わり始めます。

参考文献 / References

• agents.md — open format for guiding coding agents
• Custom instructions with AGENTS.md — OpenAI Codex Developers
• openai/codex — AGENTS.md (repository)
• Best practices for Claude Code — Anthropic Docs
• Writing a good CLAUDE.md — HumanLayer Blog
• How Anthropic teams use Claude Code (PDF)
• Effective context engineering for AI agents — Anthropic Engineering
• Writing effective tools for AI agents — Anthropic Engineering
• Prompting best practices — Claude API Docs
• Use examples (multishot prompting) — Anthropic Docs
• How to Write a Good Spec for AI Agents — O'Reilly Radar
• How to write a good spec for AI agents — Addy Osmani
• How to Build Your AGENTS.md (2026) — Augment Code
• Guides: AI Coding Agents — Next.js Docs
• Optimizing technical documentations for LLMs — DEV Community
• Write LLM-friendly docs — Fern
• OpenAI co-founds the Agentic AI Foundation under the Linux Foundation
• Anthropic's Interactive Prompt Engineering Tutorial — GitHub