コンテキストエンジニアリングとは：AIエージェントの精度を決める設計論
AIエージェントを導入したのに、なぜか期待通りに動かない。プロンプトを何度書き直しても改善しない。本番に上げた瞬間、精度が落ちる。こうした壁に直面しているチームに共通するのは、「モデルが悪い」という誤診だ。
MITのNANDA研究が300件の企業向け生成AIデプロイメントを調査したところ、95%がP&Lへの測定可能な貢献をゼロのまま終えた。その原因のほとんどはモデルの限界ではなく、コンテキストの設計ミスだった（出典: MIT NANDA, 2025）。
コンテキストエンジニアリングは、2025年6月にShopify CEOのTobi LütkeがX（旧Twitter）で定義し、AIの第一人者Andrej Karpathyが「まさにその通り」と支持したことで急速に広まった概念だ。プロンプトの書き方ではなく、AIが「何を見て判断するか」という情報環境そのものを設計する規律を指す。本稿では、その本質と実務への落とし込みを解説する。
コンテキストエンジニアリングとは何か
定義から入ると、Karpathyはこう言っている。「コンテキストエンジニアリングとは、次のステップのためにコンテキストウィンドウにちょうどいい情報を詰め込む、繊細な技術と科学だ」。Lütkeはさらにシンプルにまとめた。「LLMがそのタスクを解けるよう、すべてのコンテキストを提供する技術」。
少し噛み砕こう。AIモデルは、その瞬間に「見えている」情報しか使えない。昨日何があったか、会社の規則はどういうものか、今どんなツールが使えるのか、直近の会話でユーザーが何を言ったのか。これらすべては、明示的に渡さない限りモデルには見えない。コンテキストエンジニアリングとは、このコンテキストウィンドウに何を、どの順で、どの粒度で渡すかを設計する行為だ。
重要な事実として、現在の主要LLMはそれぞれ巨大なコンテキストウィンドウを持つ。Claude 3.5 Sonnetは200Kトークン、Gemini 1.5 Proは100万トークン超。ただし、ウィンドウを大きく開ければ精度が上がるわけではない。実測でコンテキストウィンドウの60〜70%を埋めた時点から精度が低下し始めることが複数の研究で確認されている（出典: DevTk.AI, 2026）。大きな箱があっても、中身を適切に整理しないと機能しない。
図1: コンテキストウィンドウ使用率と応答精度の関係（概念図）
プロンプトエンジニアリングとの違い
「プロンプトエンジニアリングと何が違うのか」という疑問は正当だ。答えをはっきり言うと、プロンプトエンジニアリングはコンテキストエンジニアリングの一部に過ぎない。
プロンプトエンジニアリングは、LLMへの「命令文」の書き方に集中する。より明確な指示、Few-shotの例示、思考の誘導（Chain of Thought）など。これは1対1の会話やシンプルな問い合わせには有効だ。
一方でコンテキストエンジニアリングは、AIが見る情報環境全体を設計する。単発のプロンプト文面よりも、「どんな社内ドキュメントをRAGで渡すか」「何回前の会話まで含めるか」「どのツールをどの段階で見せるか」「ユーザーの過去行動をどう要約してメモリに保持するか」が精度を決める。Sourcegraph（コード検索・AI開発プラットフォーム）のエンジニアリングブログはこう述べている。「2025年半ばまでに、経験豊富なAIエンジニアの多くは、プロンプトの文言がボトルネックではないことに気づいた」。
| 観点 | プロンプトエンジニアリング | コンテキストエンジニアリング |
|---|---|---|
| 焦点 | 命令文の書き方・構造 | 情報環境全体の設計 |
| 対象 | 1回の入力テキスト | システムプロンプト＋履歴＋ツール＋RAG＋メモリ |
| スケーラビリティ | 属人的・試行錯誤型 | 設計として再現・共有可能 |
| 主な用途 | 日常的な対話・単発タスク | 本番AIエージェント・マルチステップ処理 |
| 位置づけ | コンテキストの一要素 | プロンプトを含む上位概念 |
コンテキストを構成する5つの要素
コンテキストウィンドウに入るものは何か。実務では5つのレイヤーで整理するとわかりやすい。
1. システムプロンプト
AIの「役割」と「ルール」を定義する基盤。「あなたは営業支援AIです。回答は必ず100字以内で」のような指示がここに入る。変わりにくい情報なので、キャッシュ効率も高い。ただし長くなりすぎると他の要素を圧迫するため、必要最小限に絞ることが設計上の鉄則だ。
2. 会話履歴
直近のやり取りをコンテキストに含めることで、AIは文脈を保持できる。問題は「どこまで遡るか」だ。全履歴を毎回渡せばトークンコストが膨らむ。古い会話を要約して圧縮するか、重要な発言だけをピックアップする「選択的インクルード」が実務での標準的な対処法になっている。
3. ツール定義
AIが呼び出せる機能（検索、計算、APIコール、ファイル操作など）の一覧をコンテキストとして渡す。注意点は、全ツールを常に渡す必要はないことだ。「このタスクには関係ないツールを見せない」という動的フィルタリングを実装するだけで、精度が上がり、コストが下がる事例は多い。
4. 検索拡張生成（RAG）
Retrieval-Augmented Generation。ユーザーの質問に関連する社内ドキュメント、FAQ、過去事例などをベクトルDBから検索し、コンテキストとして渡す技術だ。RAGはコンテキストエンジニアリングの実装上の核心に位置づけられる。単にドキュメントを渡せばいいわけではなく、「何をどの粒度でチャンク化するか」「関連スコアのしきい値をどこに置くか」が精度に直結する。
5. メモリ
ユーザーの好み、過去のやり取りの要約、以前のタスク成果など、セッションをまたいで保持したい情報を管理する層だ。毎回コンテキストウィンドウに全部詰め込むのではなく、ベクトルDBやグラフDBに格納して必要時に検索する設計が一般的になっている。
図2: コンテキストウィンドウを構成する5つのレイヤー
本番で失敗するAIの「複利の罠」
ここが最も重要なポイントだ。多くの企業は「精度85%なら十分」と考えてPoCを通過させる。ところが本番でマルチステップの処理が始まると、話が変わる。
1ステップの成功率が85%のAIエージェントが、10ステップのワークフローを完遂する確率を計算してみよう。0.85の10乗は約0.2。つまり20%のケースしか最初から最後まで正常に動かない。残り80%は途中で意図しない動作をする。これが「複利の罠」だ（出典: Inkeep, 2025）。
本番AIが成功率20%で動き続けても、エラーログが膨大で人手対応が追いつかず、結局「使い物にならない」という評価になる。Lat91では実際に、10体のAIエージェントを連携させるシステムを構築・運用する中でこの問題を身をもって経験した。エージェント間の受け渡しで生じるコンテキストの「断絶」が、全体の品質を大きく下げる。
解決策はモデルの精度向上ではなく、コンテキスト設計の見直しだ。具体的には、各ステップで「前のステップの結果を次のステップがどう受け取るか」を明示的に設計する。エージェントAの出力をそのままエージェントBのプロンプトに貼り付けるのではなく、構造化してから渡す。このひと手間が、複利の効果を逆方向に使う鍵になる。
実務での設計ポイント3つ
ポイント1: コンテキスト圧縮でコストを80〜90%削減する
100,000トークンのドキュメントは、適切な要約・チャンキングによって20,000トークンに圧縮できる（情報損失はほぼゼロ）。これを毎回のAPIコールで実施すれば、APIコストは5分の1になる。大手通信会社のカスタマーサポートAI事例では、コンテキスト圧縮と選択的RAGの組み合わせでエスカレーション率が67%低下、初回解決率が45%向上した（出典: MarkTechPost, 2025）。
ポイント2: ツールの「見せすぎ」をやめる
AIに渡すツール定義が多すぎると、モデルは関係ないツールを呼び出すミスが増える。ツール呼び出しの失敗率は本番環境で3〜15%ある（出典: Inkeep, 2025）。タスクの種類に応じて、必要なツールだけを動的に渡す設計に変えるだけで、このミスは大幅に減る。「全部見せる」から「今必要なものだけ見せる」への転換が肝だ。
ポイント3: 失敗したコンテキストをログに残す
プロンプトの改善と違い、コンテキスト設計の改善には「どのコンテキストが渡されたとき失敗したか」のログが必要だ。AIが誤った回答をしたとき、「プロンプトが悪い」で終わらせず、「そのとき何がコンテキストウィンドウに入っていたか」を記録することで、設計の改善サイクルが回り始める。これはエンジニアリング規律の問題であり、ほとんどの企業でまだ実施されていない。
日本企業はなぜ後れを取るのか
日経クロステックは2025年後半の特集記事でこう書いた。「日本企業がコンテキストエンジニアリングで後れを取るのには、根深い理由がある」。
その理由を私たちなりに整理すると、こうなる。日本企業のAI導入は「ツールを入れる」フェーズで止まりやすい。ChatGPTや社内チャットボットを導入した後、「使いこなす」フェーズに入る前に評価が行われ、「思ったほど使えない」という結論が出やすい。
その「思ったほど」の原因の大半は、コンテキスト設計が未整備なことだ。社内ドキュメントをRAGに繋げていない、ツール定義が雑、会話履歴の管理をしていない。こうした状態のまま「モデルのせい」と判断してしまうケースが後を絶たない。
一方、米国の先進事例では状況が違う。MicrosoftのコパイロットAIを活用したソフトウェア開発チームは、コンテキストエンジニアリングの最適化によってタスク完了率が26%向上、新人エンジニアの立ち上がりが55%速くなった（出典: Microsoft, 2025）。使うツールは同じでも、コンテキスト設計の差がそのまま成果の差になっている。
よくある誤解への回答
「コンテキストエンジニアリングはエンジニアの仕事では？」
確かに技術的な側面はある。ただし、「どの社内情報をAIに見せるか」「どんな役割をAIに与えるか」は、現場の業務を知る人間が決めることだ。エンジニアは実装を担うが、設計の判断はビジネスサイドとの協働なしに成立しない。
「GPT-4oやClaude 4なら、コンテキスト管理しなくても賢いのでは？」
モデルが賢くなるほど、コンテキストの質が重要になる逆説がある。高性能モデルは正確な情報があれば正確に答えるが、不完全・矛盾したコンテキストを与えると「自信を持って間違える」精度も上がる。Gartnerが「コンテキストエンジニアリングを80%のAI開発ツールが採用するのは2028年まで」と予測する背景には、モデルが進化するほどコンテキストの制御が競争軸になるという判断がある（出典: Gartner, 2025）。
「プロンプトエンジニアリングはもう要らないのか？」
要る。ただし役割が変わった。「どう命令するか」ではなく、コンテキストの各レイヤー（特にシステムプロンプト）をどう書くかの技術として、プロンプトエンジニアリングの知識は依然として有効だ。上位概念がコンテキストエンジニアリング、その中の要素技術がプロンプトエンジニアリングという整理が正確だ。
まとめ
- コンテキストエンジニアリングとは、AIに「何を命令するか」ではなく「何を見せるか」の設計論だ
- 本番AIの失敗の大半はモデルではなくコンテキストの問題。MIT研究では95%のエンタープライズPoC が成果ゼロで終わった
- コンテキストは5つの要素で構成される：システムプロンプト、会話履歴、ツール定義、RAG、メモリ
- ステップ数が増えるほど精度の「複利」が下方向に働く。コンテキスト圧縮・フィルタリングでこれを防ぐ
- Gartnerは2028年までに80%のAI開発ツールがコンテキストエンジニアリング機能を持つと予測する
- 日本企業はツール導入で止まり、コンテキスト設計に入れていないケースが多い
プロンプトを磨くことに時間を使い続けているチームは、設計の入口を間違えている可能性がある。AIに命令する前に、AIに何を見せるかを設計する。それが、同じモデルを使いながら圧倒的な成果の差を生む。
Lat91では、AIエージェントの設計・導入から運用まで、一気通貫でサポートしています。
「コンテキスト設計から見直したい」「本番で精度が上がらない」という課題をお持ちの方は、まずは無料相談からお気軽にどうぞ。