AIコーディングエージェントとコンテキストエンジニアリング

コーディングエージェントとは

仕組みは第20章のエージェントループそのものです。違いは道具の種類にあります。コーディングエージェントの道具箱には、たいてい次のようなものが入っています。

• ファイルの一覧を見る、名前や文字列で検索する（grep のようなもの）
• ファイルを読む、部分的に書き換える、新しく作る
• シェルのコマンドを実行する（テスト、ビルド、git など）
• ウェブを検索する、ドキュメントを取ってくる
• MCPで接続した外部の道具（課題管理、データベースなど）

主なツールの現在地

製品の入れ替わりは激しく、名前や提供形態もよく変わります。以下は公式ドキュメントで確認した状況です 2026年10月時点。

いくつか補足します。GitHubの「Copilot coding agent」は「Copilot cloud agent」に改名されました。課題（issue）などから作業を任せると、使い捨てのクラウド開発環境でコードを編集し、テストを走らせ、プルリクエストまで作ります。

Googleは2026年5月、オープンソースのGemini CLIを新しい「Antigravity CLI」へ移行すると発表しました。2026年6月18日以降、Google AI Pro / Ultra などの個人向けプランではGemini CLIが使えなくなり、有料APIキーや企業向けライセンス経由では引き続き使えます。古い解説記事を読むときは注意してください。

どの製品も、手元のパソコンで動かす形と、クラウド上の隔離環境で動かして結果だけを受け取る形の両方に広がりつつあります。

エージェントが1つの作業をこなす流れ

「ログイン画面のテストが落ちるので直して」と頼んだときの典型的な流れを追ってみます。

sequenceDiagram
  participant U as 開発者
  participant A as エージェント
  participant R as リポジトリ
  participant S as シェル
  U->>A: ログインのテストを直して
  A->>R: test と login を検索
  R-->>A: 関係するファイル一覧
  A->>R: テストと実装を読む
  A->>S: テストを実行
  S-->>A: 失敗 期待値と違う
  A->>R: 実装を修正
  A->>S: もう一度テスト
  S-->>A: 成功
  A-->>U: 原因と修正内容を報告

ここで大事なのは、テストやビルド、型チェックのような機械的に正否がわかる確認手段です。エージェントは確認の結果を見て自分の間違いに気づけます。逆に確認手段のない作業では、もっともらしいけれど動かないコードを「完了」と報告してしまうことがあります。テストを書いてから任せる、というのは人間相手と同じく有効な作戦です。

コンテキストエンジニアリング：何を見せるか

エージェントのコンテキストには、さまざまなものが積み上がっていきます。システムプロンプト、道具の説明、指示ファイル、読んだファイルの中身、コマンドの出力、これまでの会話。長い作業ではあっという間に数万〜数十万トークンになります。

Anthropicはこれを「注意の予算（attention budget）」にたとえています。コンテキストが長くなるほど、中の情報を正確に思い出す力は落ちていく傾向があり、同社はこれを「コンテキストの劣化（context rot）」と呼んでいます。だから目標は、望む結果につながる密度の高い情報をできるだけ少なく入れることです。プロンプトの書き方（プロンプトエンジニアリング）を、会話全体に広げた考え方と言えます。

flowchart TD
  W["コンテキストウィンドウ"]
  S["システムプロンプト
道具の説明"] --> W
  I["指示ファイル
AGENTS.md など"] --> W
  F["必要なときに読む
ファイルや検索結果"] --> W
  H["会話と道具の結果
長くなったら圧縮"] --> W
  W --> L["LLMが次の一手を決める"]

指示ファイル：AGENTS.md と CLAUDE.md

毎回「テストは pnpm test で」「このディレクトリは触らないで」と説明するのは面倒です。そこで、リポジトリにエージェント向けの説明書を置いておき、作業開始時に自動で読ませます。

• AGENTS.md: 特定の製品に縛られない共通の形式。公式サイトは「エージェントのためのREADME」と説明し、6万以上のオープンソースプロジェクトで使われているとしています。OpenAIのCodexなど多くのツールが読み込みます。2025年12月にAgentic AI Foundation（第20章）へ寄贈されました。
• CLAUDE.md: Claude Codeが読む指示ファイル。プロジェクト単位、ユーザー単位などで置けます。Claude Codeは既存のAGENTS.mdを読むこともできます。

どちらも中身はただのMarkdownです。書くとよいのは、ビルドやテストのコマンド、コードの書き方の決まり、触ってはいけない場所、よくある落とし穴など、コードを読んでもわからないことです。

# AGENTS.md
## コマンド
- 依存関係のインストール: pnpm install
- テスト: pnpm test（コミット前に必ず実行）
## 決まりごと
- TypeScript は strict モード
- src/generated/ は自動生成。手で編集しない

注意点は2つです。指示ファイルは毎回コンテキストに入るので、長すぎると予算を食います。Codexは既定で合計32KiBまでしか読み込まない、と説明しています。また、Claude Codeのドキュメントが明記しているとおり、指示ファイルは「文脈」であって強制力のある設定ではありません。絶対に禁止したい操作は、後で述べる権限設定やフック（hook）で止めます。

長い作業を支える工夫

コンテキストには限りがあるので、長い作業にはいくつかの工夫が使われます。

• 必要なときに取りに行く: 最初に全ファイルを読み込むのではなく、ファイルのパスや検索手段だけを持っておき、必要になったら読む。Anthropicは「just in time」な文脈の取り方と呼んでいます。コードベース全体を事前にベクトル検索の索引にする方法（第19章のRAG）と組み合わせる製品もあります。
• 圧縮（compaction）: 会話がコンテキストの上限に近づいたら、それまでの内容を要約し、要約から新しいコンテキストで再開する。Claude Codeでは /compact で手動でも行えます。要約で細部が落ちることがあるので、大事な決定はファイルに書き残しておくと安心です。
• メモを取らせる: 進捗や決定事項をエージェント自身にファイルへ書かせ、後で読み返させる。Claude Codeには、利用者の訂正などを自動でメモする「自動メモリ」の仕組みもあります。
• サブエージェント: 調べものなど、大量のファイルを読む作業を別のエージェントに任せる。サブエージェントは自分専用のコンテキストで作業し、要約だけを返すので、親のコンテキストが汚れません。
• スキル: 定型の手順をAgent Skills（第20章）としてまとめ、必要なときだけ読み込ませる。

プロンプトキャッシュ：同じ前置きは読み直さない

エージェントはループのたびに、システムプロンプト、道具の説明、指示ファイル、それまでの会話をまとめてLLMに送り直します。毎回ほぼ同じ長い前置きを最初から計算し直すのは無駄です。

プロンプトキャッシュ（prompt caching） は、前回と先頭から一致している部分（プレフィックス）の計算結果を提供元のサーバーに一時保存し、再利用する仕組みです。中身は第15章のKVキャッシュをリクエストをまたいで使い回すイメージです。AnthropicのAPIでは既定の保存期間は5分（追加料金で1時間も選べる）で、キャッシュから読んだ部分の料金は標準で通常の入力の0.1倍とされています。OpenAIも、一定以上の長さのプロンプトで自動的にキャッシュを使います 2026年10月時点。

キャッシュは「先頭から一致」している部分にしか効きません。変わらないもの（システムプロンプトや道具の定義）を前に、変わるもの（新しい会話）を後ろに置くのが鉄則です。途中で道具の一覧を入れ替えたり、先頭に日時を埋め込んだりすると、キャッシュが外れてコストと待ち時間が増えます。

権限とサンドボックス

シェルを実行できるエージェントは、やろうと思えばファイルを消すことも、秘密の鍵を外部に送ることもできます。善意で動いていても勘違いは起きますし、読んだファイルやウェブページに仕込まれた指示に乗せられること（プロンプトインジェクション、第20章）もあります。そこで2段構えで守ります。

• 承認（permission）: どの操作を確認なしで許すかを決める。Claude Codeでは、読み取りだけを自動で許す default、ファイル編集も許す acceptEdits、変更せずに計画を立てる plan などのモードがあり、すべてを許す bypassPermissions は隔離されたコンテナやVMだけで使うよう案内されています。個別のコマンドを許可・拒否するルールも書けます。
• サンドボックス（sandbox）: OSの機能で、コマンドが触れるファイルや通信先を技術的に制限する。Codexはローカルでは既定でネットワークを切り、作業フォルダに限定したサンドボックスで動きます。Claude Codeにもシェルコマンド用のサンドボックスがあります（既定ではオフ）。

承認は「誰が判断するか」、サンドボックスは「判断を誤っても被害がどこまで広がるか」を決めます。片方だけでは足りません。確認の連続に疲れて何でも許可してしまうのがいちばん危ないので、サンドボックスで安全な範囲を作り、その中では確認を減らす、という組み合わせが現実的です。

リスクと付き合い方

• もっともらしい間違い: 動くように見えて境界条件で壊れる、テストを「通るように」書き換えてしまう、などが起こりえます。差分は必ず人が読みます。
• 秘密情報: .env や鍵ファイルを読ませない設定にし、本番の認証情報を作業環境に置かない。
• 供給網: エージェントが提案したパッケージが実在するか、信頼できるかを確かめる。追加するMCPサーバーやスキルの出所も同様です。
• 理解の空洞化: 任せたコードを誰も説明できない状態は、後で高くつきます。重要な部分ほど、設計の意図を人が説明できるようにしておきます。

エージェントの得意不得意を測るベンチマークもありますが、点数と自分のリポジトリでの使い勝手は別物です（第30章）。小さな作業から任せて、どこまで信頼できるかを自分の手で確かめるのが確実です。