AIコーディングエージェントがコンテキストを事前ロードする方法と逆効果になるとき

エディタを開いてセッションを始めます。あなたが何かを入力する前に、いや、カーソルが入力欄に落ち着くよりも前に、エージェントはすでにかなりの量を読み終えています。システムプロンプト、呼び出せるすべてのツールの定義、振る舞いの指示、プロジェクトの CLAUDE.md（または .cursorrules、AGENTS.md）、該当するパス単位のルール、そしてメモリファイルの中身まで、すべて取り込んでいます。あなたが最初の一言を発する頃には、エージェントはすでにあなた自身、プロジェクト、そして自分がどう振る舞うべきかについてのモデルを持っています。

素朴なメンタル モデルは「自分が入力し、エージェントが応答する」というものです。実際の順序は「エージェントがあなたのコンテキストを読み、あなたが入力し、エージェントが応答する」です。あなたが口を開く前にエージェントがあなたを読むという、この静かな最初の一歩で、結果の驚くほど多くが決まってしまいます。しかも、与えたコンテキストが本当に役に立つのかという証拠は、私たちの多くが思っているより居心地の悪いものです。

短いバージョン

• AI コーディング エージェントは、あなたの最初のメッセージより前に、あらかじめ書かれたコンテキストを読み込みます。システム プロンプト、ツール定義、そして CLAUDE.md、Cursor のルール、GitHub Copilot の指示、あるいはサポートまたはインポートされている場合の AGENTS.md といったツール固有の指示ファイルです。会話を始めるのはあなたではなく、エージェントの読み込みです。
• この事前読み込みは、あなたが一文字も入力しないうちに、使える文脈ウィンドウのかなりの割合を食い潰します。つまり実際に使える作業枠は、モデルが公称するウィンドウが示唆するより小さいということです。
• 実証結果こそが直感に反する部分です。開発者が書いたコンテキストファイルは、実際のコスト（推論コスト約 +19%）を払って少しだけ効果があります（タスク成功率で約 +4%）。一方、LLM が生成した、あるいはコピー＆ペーストしたコンテキストファイルは、結果をむしろわずかに 悪化.
• モデルをセルフホストすることで、できることが変わる 参照、しなければならないことではなく do。セッション前のアーキテクチャはどこでも同じです。ローカルツールは単にそれを検査・監査できるようにするだけです。実際に理解しているコンテキストを書くという規律は消えません。

単純なモデルは間違っている：エージェントが先に読む

Claude Code のセッションが始まるまさにその瞬間を思い浮かべてください。システムプロンプトが入ります。ツール定義が入ります。そして、あなたがまだ何も言わないうちに CLAUDE.md が届けられます。ここでの仕組み上の細部が重要です。Anthropic 自身のドキュメントは、次の点を明確に述べています。 CLAUDE.md のコンテンツは「システムプロンプトの後にユーザーメッセージとして配信され、」 「すべての会話の開始時」にロードされます。したがって、記録における最初のユーザーターンはあなたではありません。それはあなたのファイルであり、あなたの代わりに話し、あなたが到着する前に条件を設定しています。

その冒頭の瞬間に実際に読み込まれるのは、ひとそろいのスタックです。システムプロンプト、ツール定義、振る舞いの指示、プロジェクトおよびユーザーのコンテキストファイル、対象となっているファイルに一致するパス単位のルール、そしてエージェント自身が管理するメモリファイル。Claude Code では、コンテキストファイルは 4 階層で解決されます（管理ポリシー、次にユーザー（~/.claude/CLAUDE.md）、次にプロジェクト（./CLAUDE.md）、次にローカル（./CLAUDE.local.md））。そしてこの順に連結されます。自動メモリもそれ自身の分を上乗せします。エージェントが自分で書き、自分で読む MEMORY.md の先頭 200 行（または 25KB）が、セッションごとに読み込まれます。

そのどれもタダではありません。インフラ側のオーバーヘッド（システム プロンプト、ツール定義、動作指示）は、あなたの最初のメッセージが届く前に実効的なコンテキスト ウィンドウのかなりの部分を消費します。これはエージェントがエージェントとして振る舞えるようにするための税金であり、自分から探しに行かない限り目には見えません。

これらすべてを管理する分野の周囲に名前が形成されつつあります。Anthropic の応用 AI チームはそれを コンテキストエンジニアリング：「LLM の推論中に、最適なトークン（情報）の集合を選び取り、維持するための一連の戦略」。これは有用な言葉です。あなたが書くファイルを、ロボット宛てのメモから、希少で高価なリソースを何が占めるのかという設計上の判断へと捉え直させてくれるからです。

4 つのエージェント、先にあなたを読む 4 つの方法

すべてのエージェントが同じようにあなたを読むわけではありません。名付ける価値のある2つの軸に沿って分かれています： 何 セッション開始時に読み込まれます（ファイルの精選された階層構造、常時有効なルール、全リポジトリスキャンのいずれか）、そして どれだけ検査できるか、つまりその仕組みが決定論的で監査できる成果物なのか、信じるしかない意味的インデックスなのか、という点です。Claude Code、Cursor、GitHub Copilot、Aider が本当に分かれるのは、この 2 つの軸です。

Cursor の分割が最も示唆に富んでいます。ルールはユーザーが制御できる読み取り可能なファイルに存在しますが、それと同時に コードベース全体のセマンティックインデックス、@codebase検索を動かすベクトル埋め込みで、実際に検査することはできません。Aiderはもう一方の端にいます: gitリポジトリ全体を読み込んで repo-map、決定論的に、埋め込みは一切使いません。モデルに何を渡したかを正確に監査できます。同じアーキテクチャ上の逆転でも、その見通しはまったく違います。ツールごとのより詳しい比較については、エージェント型 CLI の状況を エージェント的コーディングCLIの対決 そして直接対決した OpenCode対Claude Code 他の場所で。

ツールごとの形式の下では、ツールをまたぐ標準が固まりつつあります。AGENTS.md はエージェント ツールのエコシステム全体（OpenAI Codex、Amp、Google の Jules、Cursor、Factory）から生まれ、現在は Linux Foundation傘下のAgentic AI Foundationによって管理されています、6 万を超えるリポジトリで採用されています。これは、セッション前のコンテキストファイルが個々のツールの便利機能から、一級の可搬な成果物へと格上げされたということです。「あなたが話す前にエージェントが読むもの」には独自の標準が必要だと、業界が認めたわけです。

これらが役立つかどうかについて証拠が示すこと

ここで心地よいストーリーが崩れます。ETH Zurich のチーム（Gloaguen、Mündler、Müller、Raychev、Vechev）が制御された評価を実施し、 「AGENTS.md の評価、」 リポジトリ単位のこうしたコンテキストファイルがコーディングエージェントの性能を実際に高めるのかどうかを調べました。調査対象のエージェントとモデル全体で、結果は「コンテキストファイルは効く」でも「コンテキストファイルは効かない」でもありませんでした。現在の要旨は、コンテキストファイルは一般にタスクの成功率を高めず、推論コストを平均で 20% 以上増やすと述べています。論文の詳細な結果では、開発者が書いたファイルが例外でした。平均で約 4% 性能を改善した一方、コストは最大 19% 増えています。LLM が生成したファイルは逆方向に動き、平均で約 3% 性能を下げながら、コストを 20% 以上押し上げました。三つ目の発見はさらに鋭いものです。あるツールがコンテキストファイルに名前として書かれていると、エージェントはそのツールを 1.6～2.5 倍多く呼び出します。それが役に立つか害になるかは、その追加の呼び出しに正当な理由があったかどうかで完全に決まります。

LLM が生成したファイルという一行に、少し立ち止まってみてください。ここが全体を支える一行だからです。自分で書いていないファイルは、モデルが生成したものであれ、「最良の CLAUDE.md 設定集」というコミュニティ配布のパックから落としてリポジトリに放り込んだものであれ、エージェントには、あなたのコードベースを実際には知らない誰かからの指示として読まれます。研究で使われたモデルでは、これは差し引きマイナスでした。トークンを余計に払って、結果はわずかに悪くなったのです。 Augment Code レビュー についての議論はこれをうまく言い当てていて、積み上がった結果を「あなたのエージェントのコンテキストはガラクタ入れの引き出しだ」と表現しています。もっともらしく見える指示をすくい入れるたびにコストが発生し、自分で書いたわけでもなく、対象のコードベースを理解してもいない指示は、たいてい得られるものより高くつきます。

私はこれを「コンテキストファイルは悪い」とも「コンテキストファイルは良い」とも読みません。データに触れた途端に崩れるのは、まさにそうしたオール・オア・ナッシングの枠組みです。もっと狭い読み方はこうです。コンテキストは意図して設計するインフラであり、自分が書いていない、しかも理解していないコードベース向けのファイルは、贈り物ではなくコストです。適用範囲の但し書きも重要です。これはその論文が試験したモデルとエージェントについて見つけた結果であり、あらゆる LLM に当てはまる普遍法則ではありません。それでも方向ははっきり一つを指しており、提供側からも裏づけがあります。Anthropic の応用 AI チーム自身が、すべてを事前に読み込むのではなく、実行時にツール経由でコンテキストを「必要なときに」読み込む流れに触れ、一部のデータは先に取得し、残りは実行時に探索するハイブリッドな方法を説明しています。CLAUDE.md を出している当の会社が事前読み込みを減らす方向に傾いているのなら、巨大なコンテキストファイルをコピーして貼り付ける本能は、もう一度見直す価値があります。

このセクションの要点： 誰が書いたかこそが、コンテキストが割に合うかどうかを予測するシグナルです。トークンコストはどちらでも同じで、リターンを変えるのは、その指示がコードベースを本当に理解している人から来たかどうかです。

消えゆくコンテキスト: セッション開始がすべてではない理由

プリロードは制約を設定します。しかし、その制約を維持してくれるわけではありません。開発者が何度もぶつかるのは物語の後半です。セッション開始時に丁寧に整えたコンテキストは、セッションが進むにつれて摩耗していき、しかもそれは静かに起こります。

これを理解する上で役立つ方法は、Mem0チームの枠組みから来ています。それは コンテキストウィンドウは RAM であり、ストレージではない。それは一時的で上限のあるもので、あなたの指示が住み続ける場所ではありません。最初に何かを読み込めばそこにありますが、使わないまま十分に長く進めれば薄れていきます。参照をやめた変数がいずれ上書きされるのと同じです。研究者が「指示の減衰」と呼ぶパターンの背後にある仕組みが、これです。 Gamage らによる 2026 年の研究 「〜しない」という制約がとりわけ脆いことを見いだしました。あるテスト設定では、遵守率が 5 ターン目の 73% から 16 ターン目にはおよそ 33% まで低下しました。これは実験室での結果であり普遍的な定数ではありませんが、長いセッションで多くの人が感じていることと一致します。

セッション境界こそが、より明確になる場所だ。 Hacker News のディスカッションの開発者たち 生成されたサブエージェントはコンテキストの引き継ぎで問題を抱えることがあると報告しています。つまり、タスクの途中で引き渡された作業は、想定より少ない親セッションのコンテキストしか受け取れない可能性があります。そして待機時間にもそれ自体のコストがあります。あるスレッドでは Anthropic の Boris Cherny が意見を述べた。その議論では、アイドル状態のセッションが何の警告もなく数十万トークン規模のキャッシュ ミスによる再構築を引き起こしうることが取り上げられています。コミュニティが繰り返し報告している共通点は「無言さ」です。圧縮が走り、それまでの推論が刈り取られ、品質が落ちるのに、画面上にはそれが起きたと知らせるものが何もありません。ただ出力が悪くなったと気づくだけです。

セルフホスティングでより多くの制御が得られますか？

すべて自分で動かしてみてください（Ollama と Open WebUI、あるいはローカルモデルに向けた Aider や Continue.dev のようなエージェント）。それでも「これで自分の制御は増えたのか？」への正直な答えはこうです。増えるのは 可視性、より本質的な制御が増えるわけではありません。その区別こそが要点です。

セルフホスティングが本当にもたらしてくれるのは、中身を確認できることです。会話データは自社のインフラから外に出ません。ブラックボックスの独自プロンプトを信じるのではなく、システムプロンプト全体を読むことができます。Aider のような決定論的なツールを使えば、各モデル呼び出しに何が入ったのかを正確に監査できます。repo-map は読めるかたちで残る成果物であり、Cursor の埋め込みインデックスのような意味的ブラックボックスではありません。監査可能性と再現性を重視する人、「エージェントは実際に何を見たのか」に答えられることを重視する人にとって、この確認できるという性質は本物であり、決して小さくありません。

しかし、このアーキテクチャの逆転は、モデルがどこで動くかを気にしません。Ollama でローカルモデルを動かしていても、クラウド API につないだ Claude Code でも、サブスクリプションの Cursor でも、エージェントはあなたが話す前にセッション前のコンテキストを読み、あなたはそのコンテキストを意図して設計しなければなりません。求められる規律は同じです。自前でホストすれば仕組みを覗く窓が澄むだけで、別の仕組みが手に入るわけではありませんし、自分で書いていないコンテキストを読み込むと何が起きるかという ETH Zurich の教訓を免れられるわけでもありません。だからこのすべてから持ち帰る価値のある転換は一つです。コンテキストファイルをエージェントへの贈り物として扱うのをやめ、運用コストのかかるインフラとして扱い始めることです。コードベースについて自分が本当に理解していることを書き、多くよりも少なく読み込ませ、そしてエージェントが最初に読んだのはあなただということを忘れないでください。読まれたその「あなた」は、自分で胸を張れる姿であるべきです。

よくある質問

AIコーディングエージェントは何かを入力する前にファイルを読みますか？

はい。セッション開始時に、AI コーディングエージェントはシステムプロンプト、ツール定義、そしてあなたのコンテキストファイル（CLAUDE.md、.cursorrules、AGENTS.md）に加えて、repo-map やメモリファイルまでを読み込みます。すべてあなたの最初のメッセージより前にです。とくに Claude Code では、CLAUDE.md がシステムプロンプトの直後にユーザーメッセージとして渡されるため、会話は実質的にあなたではなくあなたのファイルから始まります。

CLAUDE.mdのようなコンテキストファイルは実際にエージェントのパフォーマンスを向上させますか？

部分的に、そしてほとんどの人が思うよりも少ない。その ETH Zurich による AGENTS.md スタイルファイルの評価、現在のアブストラクトは、コンテキストファイルは一般にタスクの成功率を高めず、推論コストを平均で 20% 以上増やすと述べています。実務者にとっては詳細な結果のほうが役に立ちます。開発者が用意したファイルは平均で約 4% 性能を改善しましたが、コストは最大 19% 増えました。一方、LLM が生成したファイルは平均で約 3% 性能を下げ、コストは 20% 以上上がりました。実践的な読み方はこうです。自分で書いて理解しているファイルは少し助けになりますが、自分が書いていないファイルは静かにコストだけを増やしかねません。

メッセージを送る前にコンテキストウィンドウのどれだけが使われるか？

かなりの割合です。システム プロンプト、ツール定義、動作指示はユーザーの入力より前に読み込まれ、合わせて実効的なコンテキスト ウィンドウのかなりの部分を消費します。この固定の起動オーバーヘッドがあるため、実際に使える作業用の枠はモデルが公称するコンテキスト ウィンドウより小さくなります。

AIモデルをセルフホスティングするとコンテキストをより制御できますか？

得られるのは可視性の向上であって、本質的な制御力の向上ではありません。セルフホスティングなら、システム プロンプト全体を確認でき、会話データを自社インフラ内にとどめられ、（Aider のような決定論的なツールを使えば）各呼び出しに何が入ったのかを正確に監査できます。しかしセッション前のコンテキスト アーキテクチャはクラウド ツールと同じであり、コンテキストは依然として意図的に設計しなければなりません。

AGENTS.md とは何ですか？

AGENTS.md は、コーディングエージェントにコードベースの扱い方を伝えるためのオープンな形式で、README のエージェント向け対応物です。エージェント関連ツールのエコシステム全体（OpenAI Codex、Amp、Google の Jules、Cursor、Factory）から生まれ、現在は Linux Foundation 傘下の Agentic AI Foundation が管理しています。6 万を超えるリポジトリで採用され、セッション前のエージェントコンテキストにおけるツール横断の標準になりつつあります。