AIエージェントのためのコンテキストエンジニアリング実践ガイド（2026年版）
コンテキストエンジニアリングとは何か、プロンプトエンジニアリングとの違い、4つの中核テクニック、主要フレームワークの比較、その測定方法、そしてマルチエージェントシステムへの応用方法を解説します。
An AI agentは、次に何をすべきかを判断する瞬間にそのコンテキストウィンドウ内にある情報と同じだけの性能しか発揮できません——そして、その情報を選び抜くことこそがすべてです。プロンプトエンジニアリングが優れた指示を書くことだとすれば、コンテキストエンジニアリングはモデルが作業する情報環境全体——システム指示、ツール、取得したドキュメント、メモリ、実行中のタスク履歴——を管理することです。 エージェントがより長く、複数ステップにわたる作業を担うようになるにつれ、これはエージェントが成功するか、静かに崩壊するかを左右する最大のレバーとなっています。本ガイドでは、コンテキストエンジニアリングとは何か、プロンプトエンジニアリングとの違い、中核となる手法、そして実際のエージェントシステムへの適用方法について解説します。
なぜコンテキストエンジニアリングが重要なのか
コンテキストエンジニアリングが重要なのは、大規模言語モデルには有限のコンテキストウィンドウがあり、そのウィンドウをどう満たすかがエージェントのあらゆる判断の質を決定するからです。モデルは目の前にある情報と同じだけの性能しか発揮できません——情報が少なすぎればハルシネーションを起こし、多すぎたり種類が誤っていたりすれば精度が低下します。
これは理論上の懸念ではありません。研究者たちは"lost in the middle"効果を記録しています。これは、モデルが長いコンテキストの冒頭と末尾にある情報を確実に利用する一方で、中間に埋もれた事実を見落としてしまう現象です。実務者たちは、これに関連する問題を"context rot"と呼んでいます。会話やエージェントの実行が長くなるにつれて無関係なトークンが蓄積し、シグナル対ノイズ比が低下し、モデルはより悪い選択をするようになります。ウィンドウが小さくなったわけではなく、散らかっただけなのです。
この用語の変化は、実践における本質的な変化を反映しています。2025年、Andrej KarpathyやShopifyのTobi Lütkeを含むAI分野をリードする人々は、本格的なLLMアプリケーションを構築する人々が実際に行っていることを表す言葉として、「コンテキストエンジニアリング」の方が「プロンプトエンジニアリング」よりもはるかに適切だと主張しました。Anthropicはエージェント向けの効果的なコンテキストエンジニアリングに関するガイダンスを公開し、Manusのようなエージェント製品を手がけるチームは、本番環境でコンテキストを管理する中で得た教訓について長文で執筆しました。共通認識はこうです——エージェント型システムにおいては、コンテキストこそが製品なのです。
コンテキストエンジニアリングとは何か
コンテキストエンジニアリングとは、推論時にモデルに対して適切なトークン集合を組み立てる技術であり、モデルが次の正しい行動を取るために必要なものを過不足なく持たせることです。「コンテキスト」には、ウィンドウ内のすべてが含まれます。
- システム指示 — エージェントの役割、制約、行動ルール
- ツールとその定義 — エージェントが取れる行動、そしてそれらがどう記述されているか
- 取得された知識 — このタスクのために引き込まれたドキュメント、検索結果、データベースの行
- メモリ — セッションの前半や過去のセッションから引き継がれた事実
- 会話と行動の履歴 — これまでに言われたこと、行われたことの実行記録
- 現在のユーザーリクエスト — 直近の目標
コンテキストエンジニアリングとは、これら各枠に何を、どのような形で、いつ入れるかについての一連の判断です。コンテキストウィンドウを、注ぎ込み続けるバケツとしてではなく、希少で管理すべきリソースとして扱います。
コンテキストウィンドウは有限のアテンション予算です——コンテキストエンジニアリングは各枠に何を入れるかを決定します。
コンテキストエンジニアリング vs プロンプトエンジニアリング
コンテキストエンジニアリングとプロンプトエンジニアリングの違いは、範囲(スコープ)の違いです。プロンプトエンジニアリングは単一の指示を最適化するのに対し、コンテキストエンジニアリングは複数ステップのタスク全体にわたる動的な情報環境全体を管理します。プロンプトエンジニアリングはコンテキストエンジニアリングの一部です。
| プロンプトエンジニアリング | コンテキストエンジニアリング | |
|---|---|---|
| 範囲 | 1つのプロンプト・指示 | 時間経過を伴うコンテキストウィンドウ全体 |
| 状態 | 概ねステートレス、単発 | ステートフル、多くのステップにわたって進化する |
| 関心事 | 言い回し、例示、フォーマット | 何を含め、取得し、記憶し、破棄するか |
| 典型的な用途 | 単一の補完やチャットのターン | 自律的なエージェント、長時間実行されるタスク |
| 防止する失敗 | 曖昧または誤読された指示 | context rot、注意散漫、矛盾した状態 |
プロンプトエンジニアリングは依然として重要です——よく練られたシステムプロンプトは優れたコンテキストエンジニアリングの一部です。しかし、エージェントが数十ステップにわたって実行され、ツールを呼び出し、履歴が蓄積されると、単一のプロンプトの言い回しはもはやボトルネックではなくなります。重要なのは、それを取り巻くすべてを管理する規律です。
4つの中核となる手法
コンテキストエンジニアリングの作業の大部分は、コンテキストウィンドウに対する4つの操作に集約されます。覚えるのに便利な方法として、**write(書き込み)、select(選択)、compress(圧縮)、isolate(隔離)**があります。
write、select、compress、isolate——あらゆるコンテキストエンジニアリングの判断の背後にある4つの操作。
1. Write(書き込み)— ウィンドウの外にコンテキストを永続化する
エージェントが必要とするすべてがプロンプト内に存在すべきわけではありません。コンテキストを書き込むとは、情報を外部に保存すること——スクラッチパッド、ファイル、メモリストア、タスクリストなど——を意味し、単一のウィンドウを超えて存続させ、意図的に呼び戻せるようにします。自身のプランをファイルに書き出し、それを読み返す長時間実行エージェントは、会話履歴のみに依存するエージェントよりもはるかによく軌道を維持できます。
2. Select(選択)— 今関連するものだけを持ち込む
コンテキストを選択するとは、適切なタイミングで適切な情報——特定のドキュメント、関連する過去の決定、このステップに必要な1つのツール定義——を取得する技術です。ここがretrieval-augmented generation(RAG)、セマンティック検索、賢いツール選択が活躍する場所です。目標は精度であり、300個の隣接する事実ではなく、関連する3つの事実だけを引き出すことです。
3. Compress(圧縮)— シグナルを保ちながらトークンを削減する
コンテキストを圧縮するとは、要約や刈り込みを行うことで、ウィンドウがかさばりではなく意味を保持するようにすることです。一般的な手法には、完了したサブタスクの要約、冗長なツール出力の切り詰め、長い履歴を凝縮した要約への置き換えなどがあります。圧縮によって、エージェントは生のコンテキストウィンドウが本来許容する以上の期間、タスクに取り組むことができます。
4. Isolate(隔離)— エージェントや境界をまたいでコンテキストを分割する
コンテキストを隔離するとは、問題の異なる部分にそれぞれ独自のクリーンなウィンドウを与えることを意味します。例えば、1つのサブタスクに必要なコンテキストのみを持つサブエージェントを生成し、結果だけを返す、といった形です。隔離は、ある部分の作業が別の部分を汚染するのを防ぎ、信頼できるマルチエージェントシステムの基盤となります。
主要フレームワークの整理
混乱の元の1つは、主要な各チームが同じ基盤となる操作に対して独自の用語を使っていることです。Anthropic、LangChain、そしてNeo4jのようなグラフデータベースベンダーは、いずれもコンテキストエンジニアリングを異なる形で説明していますが——それらはすべて上記の4つの操作にきれいに対応しています。以下の表はそれらを整理したものです。
| 操作(本ガイド) | Anthropicの表現 | LangChainの表現 | ナレッジグラフ/GraphRAGの表現 |
|---|---|---|---|
| Write(ウィンドウ外への永続化) | 構造化されたノート取り、エージェントメモリ(NOTES.md、to-doリスト) | Store and State、Command経由で書き込むツール | 長期記憶、永続ストアとしてのグラフ自体 |
| Select(今関連するものの取得) | Just-in-timeコンテキスト、エージェント検索、ハイブリッド検索 | 動的なツール/メッセージ選択、読み込みを行うツール | ハイブリッドRAG、GraphRAG、「最小限有効なコンテキスト」 |
| Compress(トークン削減、シグナル保持) | Compaction、「アテンション予算」の賢明な使い方 | ミドルウェアによるライフサイクル要約 | トークン/コスト予算管理、「context pyramid」 |
| Isolate(クリーンなウィンドウの分離) | 凝縮された要約を返すサブエージェントアーキテクチャ | ライフサイクル境界とサブエージェント | ハンドオフとプロトコル(例:MCP) |
これらの情報源を読んで意見が食い違っているように感じたなら、それはこのためです——それぞれ異なる角度から同じ4つの動きを説明しているのです。自分のスタックに合った用語を選んでください——重要なのは操作そのものです。
マルチエージェントシステムにおけるコンテキストエンジニアリング
マルチエージェントシステムにおいて、コンテキストエンジニアリングは調整の問題になります。各エージェントは自分の仕事をこなすのに十分なコンテキストを必要としますが、共有しすぎるとノイズ、コスト、矛盾した状態を生み出します。支配的なパターンは、高レベルのプランを保持し、狭くスコープされたサブタスクを専門のサブエージェントに委任するオーケストレーターであり、各サブエージェントは隔離されたウィンドウ内で動作します。
各サブエージェントはクリーンで隔離されたウィンドウを持ち、凝縮された結果のみを返します——相互汚染を防ぎます。
これは上述の「isolate」原則によるものです。研究に関する質問と自分自身の調査結果しか見ないリサーチサブエージェントは、兄弟エージェントのコーディングタスクの無関係な履歴もかき分けなければならないエージェントよりも優れた性能を発揮します。オーケストレーターは、各サブエージェントの出力をメインコンテキストに折り込む前に、本質的な結果へと圧縮します。うまく実行すれば、これは単一のコンテキストウィンドウを何度も超えてしまうようなタスクでエージェントを動かす方法となります。
よくあるコンテキストエンジニアリングの失敗パターン
エージェントの失敗の大半は、いくつかの繰り返し現れるコンテキストの問題に起因します。それらに名前を付けることで、それらを避けて設計しやすくなります。
| 失敗パターン | どのように現れるか | 主な対処法 |
|---|---|---|
| Context poisoning(コンテキスト汚染) | ハルシネーションやエラーがコンテキストに入り込み、繰り返し参照されることで誤りが増幅される | 検証済みの事実のみをisolate+write |
| Context distraction(コンテキストによる注意散漫) | ウィンドウが大きくなりすぎて、モデルが蓄積された履歴に過度に集中し、実際の目標について推論しなくなる | Compress |
| Context confusion(コンテキストの混乱) | 無関係な情報がウィンドウを占拠し、モデルを誤った選択へと導く | より狭くSelect |
| Context clash(コンテキストの衝突) | 新たに取得した情報がウィンドウ内に既にある情報と矛盾し、モデルが両者を整合できない | 単一の信頼できる情報源にSelect+write |
4つの中核技術が対処法です。writeでオフロードし、selectで関連性を保ち、compressで散らかりを削り、isolateで相互汚染を防ぎます。
一般的なガイドがほとんど触れない失敗パターンの1つに、セキュリティ上のものがあります。取得したコンテキスト経由のプロンプトインジェクションです。エージェントがWebページ、ドキュメント、ツール結果を取り込むとき、その内容にはエージェントを乗っ取るよう設計された指示が含まれている可能性があります。ウィンドウに選択して取り込むものはすべて信頼できない入力として扱ってください——取得したデータをシステム指示から分離し、信頼できるマシン上で直接実行するのではなく、サンドボックス内でツール実行を行ってください。
コンテキストエンジニアリングが機能しているかをどう測定するか
コンテキストエンジニアリングを測定するには、目標達成に要したトークンと時間に対するタスク成功率を追跡します——優れたコンテキストエンジニアリングは、コストを維持または低下させながら成功率を高めます。多くのガイドは手法を説明するだけで、それが機能しているかどうかをどう知るかについては触れていません。以下はそのギャップを埋める指標です。
- タスク成功率 — 正しく完全な結果に到達した実行の割合。これがアウトカム指標であり、それ以外はすべてこれに至るための手段です。変更前後を比較できるよう、代表的なタスクからなる固定の評価セットに対して追跡してください。
- コンテキスト効率(成功タスクあたりのトークン数) — 消費された総トークン数を成功した完了数で割ったもの。成功あたりのトークン数が低下していくことは、圧縮と選択が効果を上げている最も明確なシグナルです。
- ウィンドウ使用率 — タスク実行中にコンテキストウィンドウがどれだけ埋まっているか。常に上限近くにあることはcontext rotを予兆し、圧縮または隔離が必要であることを示す先行指標です。
- 検索の精度と再現率 — ウィンドウに選択して取り込んだ項目のうち、実際に関連していたものがどれだけあったか(精度)、そして利用可能な関連項目のうち、どれだけを取り込めたか(再現率)。精度が低いということはノイズを追加していることを意味し、再現率が低いということはモデルを飢えさせていることを意味します。
- タスクあたりのレイテンシとコスト — 実用上の天井です。積極的な「just-in-time」探索は精度を向上させる一方でエージェントを遅くする可能性があり、この指標はそのトレードオフを誠実に保ちます。
これらをつなぐ規律は回帰テストです。固定タスクのスイートを維持し、プロンプト、検索、メモリへの変更のたびに実行し、数値の動きを観察してください。評価ループのないコンテキストエンジニアリングは当て推量にすぎません。
Happycapyはコンテキストエンジニアリングをどう適用しているか
Happycapyは、Claude Codeを含むAIエージェントをブラウザ内で直接実行するエージェントネイティブなコンピュータであり、コンテキストエンジニアリングはユーザーに任されるのではなく、これらのエージェントの動作そのものに組み込まれています。3つの設計上の選択がその大部分を担っています。
- スコープ化されたコンテキストとしてのSkills。 すべての機能を1つのプロンプトに詰め込む代わりに、Happycapyはエージェントが特定のskill——デッキのデザイン、スプレッドシートの分析、Webリサーチの実行など——を取り込めるようにしており、そのタスクに関連する指示とツールのみがウィンドウに入ります。これはデフォルトで適用された「select」と「isolate」の原則です。
- メモリとファイルを備えた永続的なサンドボックス。 各エージェントは隔離されたワークスペース内で動作し、そこでプラン、中間結果、メモをディスクに書き込み、後で呼び戻すことができます——これが「write」の原則であり、進捗が単一のコンテキストウィンドウを超えて存続します。
- 150以上のモデルへのアクセス。 ステップごとに必要なコンテキストは異なり、適切なモデルへ作業をルーティングすること自体がコンテキストエンジニアリングの判断です。
実際的な結果として、長く複数ステップにわたるタスクを引き渡し、エージェントがバックグラウンドで自身のコンテキストを管理させ、完成した結果を受け取ることができます——プロンプトを手で調整したり、ウィンドウの面倒を見たりする必要はありません。
コンテキストエンジニアリングを始めるには
スタック全体を作り直す必要はありません。最も効果の高い習慣から始めましょう。
- コンテキストウィンドウを予算として扱う。 何かを追加する前に、それがトークンに見合う価値があるかを問いましょう。
- 状態をプロンプトの外に移す。 エージェントが保持する必要のあるものには、ファイル、スクラッチパッド、メモリストアを使いましょう。
- 狭く検索する。 ドキュメント全体ではなく、そのステップが必要とする特定の事実を引き出しましょう。
- 進めながら要約する。 長い履歴や冗長なツール出力を、簡潔な要約に置き換えましょう。
- サブタスクを隔離する。 特に複数エージェント構成では、それぞれ異なる仕事にはクリーンなコンテキストを与えましょう。
これらを自分で手作業で調整したくない場合、Happycapyはこれらのパターンがすでにエージェントに組み込まれた状態でタスクを実行します。バックグラウンドで自身のコンテキストウィンドウを管理し——選択、圧縮、隔離を行いながら——あなたは結果を記述するだけで、トークン予算に触れる必要は一切ありません。
よくある質問
Q: コンテキストエンジニアリングはプロンプトエンジニアリングと同じですか?
いいえ。プロンプトエンジニアリングは単一の指示を最適化しますが、コンテキストエンジニアリングは複数ステップのタスクにわたってエージェントが目にする情報環境全体——指示、ツール、取得データ、メモリ、履歴——を管理します。プロンプトエンジニアリングはコンテキストエンジニアリングの一部です。
Q: なぜコンテキストエンジニアリングは特にAIエージェントにとって重要なのですか?
エージェントは多くのステップを実行し、ツールを呼び出し、履歴を蓄積するため、コンテキストウィンドウはすぐに埋まってしまいます。積極的な管理がなければ、無関係なトークンがシグナルを押しのけ、エージェントの判断は劣化します——これがcontext rotと呼ばれる問題です。コンテキストエンジニアリングは、ウィンドウを重要なものに焦点を当て続けます。
Q: 主なコンテキストエンジニアリングの手法は何ですか?
4つの中核技術は、write(ウィンドウの外にコンテキストを永続化する)、select(今関連するものだけを取得する)、compress(トークンを節約するために要約する)、isolate(サブタスクに独自のクリーンなコンテキストを与える)です。実践的な作業のほとんどは、これらの何らかの組み合わせです。
Q: コンテキストエンジニアリングは2026年に学ぶ価値のあるスキルですか?
はい。より多くのソフトウェアがLLMと自律的なエージェントの上に構築されるにつれ、コンテキストをうまく管理する能力は、開発者、プロンプトデザイナー、AIプロダクトチームにとって中核的な能力になりつつあります——そしてそれは、うまく機能するエージェントとそうでないエージェントの違いをますます決定づけています。
Q: コンテキストエンジニアリングが機能しているかどうかはどう測定しますか?
評価セットに対するタスク成功率に加え、効率指標を追跡します。成功タスクあたりのトークン数、コンテキストウィンドウの使用率、検索の精度と再現率、タスクあたりのレイテンシ/コストです。優れたコンテキストエンジニアリングは、コストを維持または削減しながら成功率を高めます。変更のたびにスイートを実行し、その調整が改善につながったか悪化させたかを確認しましょう。
Q: AIエージェントを使うために自分でコンテキストエンジニアリングを行う必要がありますか?
必ずしもそうではありません。Happycapyのようなエージェントプラットフォームは、コンテキスト管理をシステムに組み込んでいます——skillsでコンテキストをスコープ化し、サンドボックスで状態を永続化し、サブタスクを隔離します——そのため、コンテキストウィンドウを手動で調整することなく、複数ステップの作業を実行できます。
