コンテキストとは何か

はじめに

「コンテキストエンジニアリング」という本を読みました。書籍はAIエージェント開発の説明が中心だが、AIエージェントを利用する側としてもコンテキストについての理解が深まったのでこれを機に整理していきたい。

話すこと

• コンテキストとは何か
• AIエージェントの利用側として工夫できるポイント
• まとめ

コンテキストとは何か

https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

コンテキスト＝LLMに渡される入力すべて。具体的には以下のようなもの：

• システムプロンプト
• 事前情報（RAG）
• memory file
• ツール定義 & 出力
• ユーザープロンプト
• 会話履歴
• + 出力形式（structured outputでの指定）
• + APIパラメータ

渡される順序の詳細はベンダーによって異なる。たとえばClaude APIにおいてプロンプトキャッシングの文脈では、

キャッシュプレフィックスは次の順序で作成されます：tools、system、次にmessages。この順序は、各レベルが前のレベルの上に構築される階層を形成します。

と書かれている。

コンテキスト圧迫による精度問題

「ターン数が増加すると精度が悪くなる」は実感している人多いと思う。挙動が不安定になる、最初にできていたことができなくなる、ツールを思った通りに使ってくれなくなる、など。

なぜ精度が悪化するのか

コンテキスト増による精度低下は根本的なアーキテクチャの性質によるもので、現状避けられない。

Context Rot

コンテキストウィンドウに入力されるトークン数が増加するにつれて、モデルがそのコンテキスト内から正確に情報を思い出し、論理的に利用する能力が逓減していく現象。この現象は、基盤となるTransformerアーキテクチャの根本的な性質に起因している。Transformerの自己注意機構（Self-Attention）は、シーケンス内のすべてのトークンが他のすべてのトークンに注意を向けるよう設計されているため、コンテキストが長大になればなるほど注意力の配分が薄く引き伸ばされ、推論の焦点がぼやけてしまう。

参考: Context Rot

Lost in the Middle

LLMは入力コンテキストの「冒頭」と「末尾」に配置された情報は高い精度で抽出・利用できる一方で、コンテキストの「中間」に埋もれた情報を利用する能力は著しく低下することが実証されている。実務上は、最も重要な情報を冒頭と末尾の両方に配置するのが定石。

→ 総じて、モデル性能向上により最大コンテキスト長が伸びてもこれらの問題は付きまとうと考えられる。アーキテクチャレベルでの改善がされればまた変わってくるとは思うが。

"Context is a critical but finite resource for AI agents."

（コンテキストはAIエージェントにとって重要だが有限のリソースである）

── Effective context engineering for AI agents

コンテキストエンジニアリングとは

書籍より：LLMが最も質の高い回答を返すために、限られた入力領域において、何を与え、何を捨て、どう良いコンディションを保ち続けるべきか。これをアプリケーション全体で構築する技術。

プロンプトエンジニアリングからコンテキストエンジニアリングへの流れとして、GPT-3世代では汎用的なテキスト生成器だったものが、2025年のAIエコシステムでは目標を持ち、記憶を維持し、ツールを使用し、自律的に計画を実行するAgentic AIへと進化した。

利用者側としてコンテキストに対してできることは？

LLMアプリケーション開発においてコンテキストをコントロールすることは重要。書籍では以下のような例が紹介されていた：

• 最適なコンテキスト管理のためのRAG基盤や検索システム
• 単一プロンプト→ワークフロー化によるコンテキスト分散やその分類
• Reasoning モデル（Responses API）による中間結果の扱い方
• そのほかコンテキストキャッシングなど実用上のテクニック

AIのアプリやコーディングエージェントを利用する上で応用できる考えもあるはず。大きく分けて、①ミクロ視点（プロンプト設計）と②マクロ視点（コンテキストの流通設計：MCP, Skills, SubAgents）がある。

①有効なプロンプト設計の手法

• 曖昧語の排除、具体性・再現性の確保
  • NG例：「モダンな画面のHTML」（モダンとは？）、「ちゃんと」「できるだけ」「なるべく」という曖昧な副詞、背景・やって欲しいこと・出力形式が文中に散らばっている
  • LLMに添削してもらうのもあり
• 英語の使用：トークン消費の格差がある。ただし細かなニュアンスが含まれる表現や運用管理面でデメリットが大きい場合は日本語を許容
• 否定形を避ける
• 指示を矛盾させない：意外とシステムプロンプトと混ざってたりする
• 複数項目の指示・出力を避ける
• 重要な情報は冒頭と末尾に配置する：Lost in the Middleの知見から、中間部分の情報は見落とされやすい
• フォーマット：基本はMarkdown、表にはXMLやHTML、柔軟なデータ表現ならJSON/YAML

プロンプト＝コンテキストのミクロな単位と言い表すのであれば、ユーザープロンプトはもちろんシステムプロンプト、tool定義やAGENTS.md、参照するdocもこれを応用できるはず。

②コンテキストの流通設計

Function CallingとMCPについて

Function Callingとは、LLMにアプリ側で利用できるツール定義を渡して、何をどのパラメータでいつ利用するかを返却させる機能。

MCPは、このツール接続を安全かつ標準化したプロトコル。MCPを介することで、ツール定義のフォーマットが統一され、複数のツールプロバイダーを一貫した形でLLMに接続できる。

ツール利用とコンテキストの肥大化

Function Callingではモデルに対して「どのようなツールが存在し、どのようなパラメータを受け取り、何を返すのか」というツールのセマンティクスを、実行前にプロンプトの一部として静的に注入しなければならない。多段階のワークフローを自律的に実行するエージェントは、ツールが実行された結果（中間結果）を再びコンテキストウィンドウにパススルーして次の行動を決定する。

https://developers.openai.com/api/docs/guides/function-calling

MCPも同様に、接続されたMCPサーバーから提供されるすべてのツール定義をレジストリから読み込み、それを会話コンテキストの一部としてLLMに自動的に引き渡す。

https://www.anthropic.com/engineering/code-execution-with-mcp

コンテキスト肥大の解決アプローチ ① Code Execution MCP と Tool Search Tool

Code Execution MCP

先述のMCPの課題に対して、「エージェントが呼ぶMCPツール自体をAPIとして実行」させることを求めるもの。中間データはMCPサーバー側で保持して、必要な部分だけLLMは受け取る。Anthropicの記事によれば、150,000トークンから2,000トークンへと98.7%の削減が実現されたとのこと。ツール定義・中間データの削減によりコンテキスト圧迫が大幅に減る。

参考: Code Execution with MCP

Tool Search Tool

大量のツール定義に対して、必要なツールだけをオンデマンドで読み込むClaude API組み込みのtool。必要な時だけロードするため、ツール定義による圧迫がない。

参考: Tool Search Tool

コンテキスト肥大の解決アプローチ ② Agent Skillsによるナレッジのモジュール化

再利用可能なドメイン知識やワークフローをパッケージ化して、必要に応じて段階的にロードするアプローチ。

ポイントは、description部分だけが最初に登録されること。MCPが「何（What）ができるか」を定義するのに対し、Skillsは「どのように（How）実行するか」の位置付け。「あくまで必要が生じたときに」必要なHowを取得していくという意味で、コンテキスト問題に寄与する。ただし基本はメインのエージェントがコンテキストを獲得していくため、Skillの実行が積み上がるほどコンテキストのロードは進んでいく点には注意。

コンテキスト肥大の解決アプローチ ③ Subagentsと階層的コンテキスト分離

Skillsが再利用可能な知識の動的ロードに焦点を当てているのに対し、Subagentsはタスク実行時における「コンテキストの物理的な隔離・分離」を目的としたアーキテクチャ。Skillsでは前述の通りメインのストリーム自体にコンテキストは積み上がるため、利用時の「コンテキスト肥大」の文脈では解決になっていない。

Subagentはメインのエージェント（または会話スレッド）から一時的に派生し、完全に独立したコンテキストウィンドウと独自のシステムプロンプトを持って動作、タスク完了とともに必要な情報だけをメインに渡す。

それぞれのユースケース

• MCP（またはツール利用）：コンテキスト肥大化のリスクが最も高いため比較的シンプルな処理に。Code Execution with MCP や Tool Search Tool が使えるならそれも手。
• Skills：メインエージェントにある程度コンテキストが載ってもいいが、多段で複雑なサブタスク。
• エージェント分割：メインのコンテキストを持たなくてもいい場合。コンテキスト圧迫が許容できないような重厚なサブタスク。

まとめ

最近発表されたOpus 4.6では最大100万トークンの入力に対応、Context Rotに対してベンチマーク上で大幅な改善がされたらしい。今後モデルがこのように向上すると、実感としてのコンテキスト腐敗は薄れていくかもしれない、そうなってほしい。とはいえ、無制限に何でも含めても平気というわけではないため、利用者側としてコンテキストの流れは意識しておきたい。