AIエージェントに何を渡し、何を渡さないか — コンテキスト設計の基本

AIエージェントに仕事を頼むとき、多くの人が最初に取る戦略は「情報を足す」ことです。うまくいかなければ説明を追加し、関連ファイルを追加し、過去の経緯を追加する。この方向は、ある地点までは効きます。そしてある地点を超えると、足すほど悪くなります。

これは感覚論ではなく、ベンダーの公式ガイダンスと公開されている研究の両方が同じ方向を指しています。この章では、なぜそうなるのかを確認したうえで、渡すものをどう選ぶかを整理します。

コンテキストは有限の資源である

Anthropicは公式のエンジニアリング記事で、コンテキストを貴重で有限な資源として位置づけています。理由として挙げられているのがトランスフォーマーの構造的な性質で、各トークンはコンテキスト内の全トークンと関係を持つため、n個のトークンに対して n² 個の組み合わせが生じます。モデルにはこの関係を処理するための注意の予算があり、トークンが増えるほど1トークンあたりに割ける注意は薄まります。

同記事は、これを人間の作業記憶の容量になぞらえて説明しています。上限まで入るということと、上限まで入れて機能するということは別だ、というのがここでの要点です。

コンテキストウィンドウは「入る量」の上限であって、「性能が保たれる量」の上限ではありません。

長くすると精度が落ちる — context rot

「入れすぎると悪くなる」は測定されています。ベクトルデータベースを開発するChromaが2025年7月に公開した技術レポート Context Rot は、この現象を系統的に検証したものです。

結論は明快で、モデルはコンテキストを一様には使わないというものです。入力長だけを変数にして他を固定しても、長くなるほど性能は不安定になります。注目すべきは、単語をそのまま複製するだけの単純な課題でも劣化が起きる点です。難しい推論だから失敗するのではなく、長いこと自体が失敗の要因になっています。

唯一の原則 — 最小の高シグナルなトークン集合

ではどう設計するのか。Anthropicの記事が示す指針は1文に集約されています。望む結果が得られる確率を最大化する、可能なかぎり小さい高シグナルなトークンの集合を見つけること。

この本で扱うコンテキスト関連の話は、ほぼすべてこの原則の系です。指示ファイルを短く保つのも、ツールを絞るのも、タスクを小さく切るのも、目的は同じです。

コンテキスト設計とは、情報を集める作業ではなく、少ないトークンで判断に足る状態を作る作業です。

何がコンテキストを食っているのか

削るには、まず何に消えているかを知る必要があります。消費先はおおむね5つです。

実務で見落とされがちなのがツールの実行結果です。指示ファイルを数十行削っても、5,000行のファイルを丸ごと読ませた瞬間に帳消しになります。長いログを貼り付ける、巨大なJSONを丸ごと渡す、といった操作は、感覚以上にコンテキストを食います。

Claude Codeには /context コマンドがあり、現在のコンテキストが何にどれだけ使われているかを内訳で確認できます。削る前に、まず何に消えているかを見るのが順序です。

事前に全部渡すか、必要になったら取りに行くか

コンテキストの入れ方には2つの方式があります。Anthropicの記事はこれを対比したうえで、両方を組み合わせるハイブリッドを推奨しています。

同記事はClaude Code自身を例に挙げており、CLAUDE.md は事前に読み込む一方、コードは glob や grep で実行時に探しに行く、という組み合わせになっていると説明されています。

判断の目安はシンプルです。「毎回必ず要るか」と「小さいか」の両方を満たすものだけを事前に置き、それ以外は取りに行かせる。この線引きを間違えると、使うかどうか分からない情報のために毎回の予算を払い続けることになります。

会話が長くなったときの3つの対処

短く保っていても、長時間の作業では必ずコンテキストは埋まります。Anthropicの記事は、この局面での手法を3つ挙げています。

圧縮（compaction） — それまでの内容を要約し、その要約を持って新しいコンテキストで再開します。多くのツールが自動で行います。ただし要約は情報の欠落を伴うため、繰り返すほど元の文脈は薄くなります。

コンテキスト外への記録（structured note-taking） — エージェントがコンテキストの外側にあるファイルへメモを書き出し、必要なときに読み戻します。長い作業の途中経過を、会話履歴ではなく永続的な場所に置く発想です。

サブエージェントへの分離 — 探索や調査といった大量の読み込みを伴う作業を、きれいなコンテキストを持つ別のエージェントに任せ、親は結果の統合に集中します。探索で汚れるコンテキストを親から隔離するのが狙いです。

圧縮が何度も走っている状態は、そのセッションが扱える範囲を超えた合図と考えるほうが実務的です。要約の要約を重ねた文脈で作業を続けるより、区切りをつけて新しいセッションを立てるほうが安定します。

ツール定義もコンテキストである

見落とされやすいのが、登録しているツールそのものがコンテキストを消費しているという点です。Anthropicの記事は、ツールについて自己完結していること・エラーに強いこと・きわめて明確であることを求め、加えて機能の重複を最小にするよう述べています。似た機能のツールが並んでいると、説明文の分だけ枠を食ううえ、どれを使うべきかの判断もぶれます。

サンプル（少数ショット）についても同様で、エッジケースを羅列するのではなく、多様で代表的な例を厳選することが勧められています。網羅は目的になりません。

ツールとMCPの設計は後の章で詳しく扱いますが、入れたツールは使わなくてもコストを払っているという点だけは、ここで押さえておいてください。

よくあるハマりどころ

全部読ませてから質問する。 関係ありそうなファイルをまとめて読ませてから本題に入るやり方は、精度を上げているつもりで下げていることがあります。まず何を知りたいかを伝え、必要なファイルはエージェント自身に探させるほうが、結果的に短く済みます。

巨大な出力をそのまま渡す。 ログ、テスト結果、APIレスポンスを丸ごと貼るのは典型例です。エラー箇所の前後だけを渡す、件数を絞る、といった一手間が効きます。

圧縮を繰り返しながら走り続ける。 前述のとおりです。圧縮が2回、3回と走っているなら、タスクの切り方を疑うべき局面です。

使っていないツールを入れっぱなしにする。 便利そうだから入れたまま忘れているツール群が、毎セッション枠を消費し続けます。定期的に棚卸しします。

ちゃんと使うためのポイント

• コンテキストは有限資源。入る量と、性能が保たれる量は別
• 長さそのものが劣化要因になる。単純な課題でも入力長が伸びれば不安定になることが測定されている
• 原則は1つ。望む結果に必要な、最小の高シグナルなトークン集合を探す
• 消費先で最も見落とされるのはツールの実行結果。削る前に内訳を見る
• 「毎回必ず要る」かつ「小さい」ものだけ事前に置き、残りは実行時に取りに行かせる
• 長時間の作業では、圧縮・コンテキスト外への記録・サブエージェントへの分離を使い分ける
• 圧縮が何度も走るのは、セッションを切り直す合図

次の章では、ここで扱った「毎回渡すもの」を実際にどこへ置くかを整理します。同じ内容でも、チーム全員に届くファイルに書くのか、自分の環境にだけ効くファイルに書くのかで、意味がまったく変わります。

参考リンク

• Effective context engineering for AI agents（Anthropic, 2025-09-29） — 本章の原則・ハイブリッド戦略・3つの対処法の出典
• Context Rot: How Increasing Input Tokens Impacts LLM Performance（Chroma, 2025-07-14） — 18モデルでの長さによる劣化の検証
• Lost in the Middle: How Language Models Use Long Contexts（Liu ら, 2023） — 位置による性能差の研究
• Manage the context window（Claude Code 公式） — 内訳の確認と圧縮の挙動