# コンテキストエンジニアリング——エージェントのトークン予算設計 > Anthropicが定義するコンテキストエンジニアリングの核心を解説。Attentionスカシティ・Lost in the Middle問題・4段階メモリ階層・3つの長時間タスク戦略をエンタープライズ実装視点で整理する。 - Canonical: https://kuucorp.com/blog/context-engineering-token-budget-design/ - Date: 2026-06-05 - Last modified: 2026-06-05 - Publisher: Kuu株式会社 (https://kuucorp.com) --- エンタープライズのAIエージェントを本番展開してから数週間後、「動いているはずなのに精度が落ちている」「長期タスクの後半でエージェントの指示追従が崩れる」という報告が上がり始める。原因の多くはモデルの能力の問題ではなく、コンテキスト設計の問題だ。入力に何を・どの順序で・どの量含めるか——この設計判断が、エンタープライズ規模のエージェント品質を左右する。 ## コンテキストエンジニアリングとは何か > コンテキストエンジニアリングは推論時にモデルへ渡すすべてのトークン構成を設計する技術領域で、プロンプト設計を包含する上位概念です。 AnthropicはSonnet 4.5の公開に合わせてエンジニアリングブログで定義を示した。「モデルの望ましい振る舞いを最大化するコンテキスト構成を設計すること」——これがコンテキストエンジニアリングの核心だ。従来のプロンプトエンジニアリングが「何を指示するか」を最適化したのに対し、コンテキストエンジニアリングは推論時のトークン総体、すなわちシステムプロンプト・ツール定義・Few-shotサンプル・会話履歴・外部メモリ取得結果の全体構成を対象とする。 2024年から2025年にかけて、プロンプトの平均長さは約1,500トークンから6,000トークン超へほぼ4倍に増加した。この変化はエージェントワークフローと推論タスクの普及が主因だ。コンテキストサイズの拡大はモデルの能力を引き出す一方、適切に設計されなければ精度を系統的に劣化させる。プロンプト設計がステートレスな1ターン最適化であるのに対し、コンテキストエンジニアリングはセッション全体にまたがるステートフルな設計行為だという認識が出発点となる。 本記事は[AIエージェントガバナンス](/ai-governance/)の技術実装レイヤーを扱う。エージェントのアーキテクチャ全体については[エージェントハーネス設計](/blog/agent-harness-architecture/)も参照してほしい。 ## Attentionスカシティとコンテキスト劣化のメカニズム > Transformerのn²計算によりコンテキスト長が増すほどAttentionが希薄化し中間部情報の精度が低下します。 LLMはコンテキスト全体を均等に読まない。Transformerの注意機構はトークン間のすべてのペアを計算するためn²の計算コストがかかる。実用上の帰結として、モデルは先頭と末尾のトークンに注意を集中させ、中間部の情報精度が低下する「Lost in the Middle」現象が発生する。 Anthropicのエンジニアリングブログはこの問題を「LLMはコンテキストをパースする際に有限のAttentionバジェットを消費する」と表現している。各トークンがこのバジェットを少しずつ削るため、長いコンテキストでは特定の情報への注意が希薄になる。研究が示す性能カーブはU字型だ。先頭（Primacy効果）と末尾（Recency効果）の情報は安定して利用されるが、中間部は検索漏れと混同が起きやすい。100万トークンのコンテキストウィンドウを持つモデルでも、有効な高精度利用域は公称の30〜60%程度にとどまるという観測がある。 設計上の含意は明確だ。 - **重要な指示・制約・スキーマは先頭（システムプロンプト）か末尾（直近ユーザーメッセージ）に配置する** - 検索結果などの参照情報を中間に埋め込む場合は、関連性スコアの高い順に配置し、低スコアのノイズを削除してから渡す - 長いコンテキストでの動作はユニットテストではなく、実際のコンテキスト長で統合テストを行う ## トークン予算設計の4段階メモリ階層 > 4段階メモリ階層（作業・短期・長期・世界知識）でトークン予算を配分するのがエンタープライズ標準設計です。 本番環境のプロダクションで検証された設計として、4段階のメモリ階層がある。 **Tier 1: 作業メモリ（直近5〜10ターン、逐語保持）** 直前の会話履歴をそのまま保持する層。整合性が最も重要なため圧縮しない。エージェントが現在実行中のサブタスク状態・ツール実行結果・未解決の問題もここに置く。予算消費が最も大きいが削減対象外のコアレイヤーだ。 **Tier 2: 短期エピソード記憶（セッション要約）** セッション全体の圧縮要約。会話履歴のうちTier1の外側を要約エージェントが処理し、500〜1,000トークン程度のサマリーとして保持する。Anthropicが「Compaction」と呼ぶ操作はこの層で行われる。要約プロンプトには「継続中のタスク状態・決定済み事項・未解決の問題・直近ツール実行結果」を明示的に抽出させる設計が精度を保つ。 **Tier 3: 長期記憶（ベクターストア検索）** ユーザー設定・過去ドキュメント・組織ナレッジをベクターストアに保存し、推論時にクエリで引き出す。近年の主流は「Just-in-Timeリトリーバル」——全データを事前にコンテキストへ展開するのではなく、軽量な識別子を保持し、必要なタイミングでツール呼び出しでロードする設計だ。これはLLMが持つ探索的な認知プロセスに合致し、初期ロード時のトークン浪費を防ぐ。 **Tier 4: 世界知識（モデル重み）** 事前学習済みの知識。コンテキストウィンドウを消費しないが更新できない。最新情報・組織固有情報はTier 3から補完する設計が原則だ。 **コンテキストアセンブリの推奨順序**（本番環境検証済み）: 1. システムプロンプト 2. 長期記憶検索結果（関連度降順） 3. タスク関連チャンク（関連度降順） 4. セッション要約（Tier 2） 5. 直近会話履歴（Tier 1） 6. 現在のユーザーメッセージ この順序は「Lost in the Middle」問題を考慮したものだ。最も重要な指示（システムプロンプト）と最も直近の入力（ユーザーメッセージ）を両端に置き、参照情報を関連度順で中間に配置することで注意の集中を誘導する。 ## 長時間タスク向け3つのコンテキスト戦略 > コンパクション・構造化メモ・サブエージェント分割の3戦略でコンテキスト枯渇なしに長時間エージェントを設計します。 エンタープライズの長時間タスク（多段階審査・大規模コードリポジトリ分析・長期プロジェクト管理など）では、単一セッションでコンテキストウィンドウが枯渇するリスクがある。AnthropicはClaude Codeの設計経験から3つのパターンを定義している。 **1. コンパクション（Compaction）** 会話履歴が一定の使用率（実装例では60〜70%）に達した段階で、現在の会話を要約して再起動する。Claude Codeはこの操作を自動実行し、コンテキスト使用率をエージェント自身が監視して事前バジェットチェックを行う。圧縮前後のセマンティック整合性を保つには、要約プロンプトに抽出すべき構造（タスク状態・決定事項・未解決事項・ツール結果）をスキーマとして定義することが重要だ。 **2. 構造化メモ（Structured Note-Taking）** エージェントが外部ファイルやKey-Valueストアに進捗ノートを書き込み、再起動時にそのノートを読み込む設計。会話履歴には依存せず、「状態の外部化」によってセッション間の継続性を担保する。長期間運用のエージェントには、メモのスキーマをJSONで固定して保存することで検索・差分確認・監査が容易になる。エージェントのメモ書き込みをツール実行としてログに残すことで、[監査ログ設計](/blog/ai-agent-audit-log-management/)との統合も自然に行える。 **3. サブエージェント分割（Sub-Agent Architecture）** 大きなタスクを専門特化した複数のサブエージェントに委譲し、各エージェントは1,000〜2,000トークン程度の要約を返す設計。各エージェントはフレッシュなコンテキストで起動するため、コンテキスト汚染（前のタスクの情報が次のタスクに干渉する問題）が発生しない。オーケストレーター自体のコンテキストも、サブタスク完了後は詳細を要約で差し替えることで長時間稼働を維持する。[サブエージェント・オーケストレーションの設計パターン](/blog/subagent-orchestration-design-patterns/)と組み合わせた構成が有効だ。 ## エンタープライズ実装の3大設計判断 > システムプロンプトのGoldilocks zone・ツール最小化・動的トリミングが3大設計判断です。 **システムプロンプトのGoldilocks zone** Anthropicが定義する「Goldilocks zone」とは、ハードコードされた脆弱なロジックにも曖昧すぎる前提にも陥らないシステムプロンプトのサイズと粒度だ。スコープを過度に絞ると予期しない入力で崩れ、広げすぎるとAttentionが分散する。実用的な指針として、「エンジニアがレビューして5分で全体把握できるシステムプロンプト」を目安にする。1,000トークンを超える場合はセクション分割とアンカー見出しを入れ、長距離参照を防ぐ。 **ツールセットの最小化** ツール定義はコンテキストを消費し、選択肢が増えるほどエージェントの選択精度が落ちる。「人間エンジニアがどちらのツールを使うか一瞬迷う」ならエージェントも迷う——Anthropicのエンジニアリングブログが示すこの原則は実装判断として直接使える。機能が重複するツールは統合し、ツール数は20未満に抑えるのが現実的な上限だ。 **動的トリミングのスコアリング設計** コンテキストアセンブリ時に各コンポーネントの関連性スコアを計算し、トークン予算を超えた場合は低スコア順に削除する設計が本番品質の要件だ。実装上は以下の優先度ルールを設ける。 - **削除禁止**: システムプロンプト、現在のユーザーメッセージ - **高優先**: 直近N件の会話履歴、タスクに直接関連するツール結果 - **低優先**: 古い会話履歴、関連性スコアの低い検索結果 スコアリングロジックはビジネスロジックと同等の決定論的テストカバレッジが求められる（アセンブリ順序・トリミング動作・要約完全性の検証）。これはコンテキスト管理をアドホックな実装ではなく、テスト可能な設計として扱うことを意味する。 エンタープライズ基盤全体のコンテキスト設計・LLMゲートウェイとの統合・複数チームへの展開については、[KuuのRDEサービス](https://kuucorp.com/services/rde/)で実装支援を提供している。 ## 参考 - [Effective context engineering for AI agents — Anthropic Engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) - [LLM Context Window Management: Engineering Patterns for Long-Context Production Systems — Tanuj Garg](https://tanujgarg.com/blog/llm-context-window-management-production) ## まとめ コンテキストエンジニアリングは、プロンプトの書き方ではなく推論時のトークン総体の設計という認識に立つことが出発点だ。Attentionスカシティと「Lost in the Middle」問題を前提に、4段階のメモリ階層でトークン予算を配分し、長時間タスクにはコンパクション・構造化メモ・サブエージェント分割の3戦略を組み合わせる。システムプロンプトのGoldilocks zone・ツール最小化・動的トリミングの設計判断は、後付けが困難な基盤要素として設計段階から組み込む必要がある。 エンタープライズ規模でのコンテキスト設計の見直し、複数チームにまたがるエージェント基盤の整備、LLMゲートウェイとの統合に課題を感じている場合は、[KuuのRDEサービス](https://kuucorp.com/services/rde/)にご相談ください。