プロンプトを10回直してもエージェントが失敗し続けるなら、実はプロンプトのせいじゃないかもしれません。
2025年6月、Andrej KarpathyがXに一言投稿しました。"context engineering is the delicate art and science of filling the context window with just the right information." Shopify CEOのTobi Lutkeもすぐに同意しました。「プロンプトエンジニアリング」という言葉自体が間違いで、本当の戦いはコンテキストで起きているんです。
みんなこう思ってますよね
AIエージェントがおかしな答えを出したとき、多くの人はここから始めます。システムプロンプトをより具体的にして、few-shotの例を追加して、出力フォーマットをより細かく指定する。これを繰り返すと、単一タスクではそれなりに効くんですよね。
でも、エージェントが複数のステップを踏みながらツールを使い、過去の会話を記憶して、社内データを参照しなければならない瞬間 — つまり実際の業務に投入される瞬間 — プロンプトの最適化はどんどん意味を失っていきます。どんなにプロンプトを磨いても、エージェントが知らないことは知りようがないんです。
でもデータは逆を示してる
Firecrawlが分析した研究結果は具体的です。プロンプトを複数の会話ターンに分散して提供すると、まとめて提供した場合と比べて平均パフォーマンスが39%低下します。またDatabricksがLlama 3.1 405bをテストしたところ、コンテキスト窓が32,000トークンを超えた時点から精度が明確に落ち始めました。
コンテキスト窓に何を、どのように入れるかが、プロンプトの表現よりもはるかに大きく影響するということなんです。
Elasticがまとめた核心的な区別がわかりやすいです: "プロンプトエンジニアリングはコンテキスト窓を所与のものとして受け入れる。コンテキストエンジニアリングはそれを能動的に設計する。"
Neo4jがまとめたエージェントのコンテキスト失敗パターン4つ:
| 失敗パターン | 説明 | 症状 |
|---|---|---|
| コンテキスト汚染 | 幻覚が会話履歴に残り参照され続ける | エラーが蓄積して悪化 |
| コンテキスト散漫 | 過去の会話に過度に依存 | 学習知識を無視、誤答を繰り返す |
| コンテキスト混乱 | 不要な情報が応答に影響 | 無関係な内容が混入 |
| コンテキスト衝突 | 矛盾した情報が同時にコンテキスト内に存在 | 答えが一貫しない |
これら4つのうち、プロンプトエンジニアリングで解決できるものは一つもありません。すべてコンテキストに何を入れるか、いつ、どのように入れるかの問題なんです。
コンテキストエンジニアリングって何なんですか?
一言で言うなら: モデルへの質問の仕方を最適化するのではなく、モデルが働ける環境そのものを設計することです。
Neo4jの定義: 検索パイプラインの設計、メモリ戦略の構築、ツールスキーマとポリシーの定義、タスク状態の追跡、推論履歴の管理。直接比較すると:
| プロンプトエンジニアリング | コンテキストエンジニアリング | |
|---|---|---|
| 核心的な問い | どう表現する? | 何を知る必要がある? |
| 対象 | 単一の入力テキスト | 情報アーキテクチャ全体 |
| 適したタスク | 単一ターン、基本的な分類·翻訳 | マルチステップエージェント、長期ワークフロー |
| 失敗時の対応 | 表現を修正 | 検索·メモリ·ツール構造を再設計 |
| スケール | 個人利用、プロトタイプ | 本番AIシステム |
コンテキストエンジニアリングの核心概念はMinimum Viable Context(MVC)です。モデルに必要最小限の高品質情報だけを与えること。多すぎると注意が散漫になり、少なすぎると幻覚が生じます。ちょうど必要な量だけ。
理想的なエージェント呼び出しのコンテキスト5要素
① ユーザーの目標 ② 最も関連性の高い検索結果のみ ③ 必要なツール定義 ④ 関連ポリシー ⑤ 圧縮されたメモリサマリー — この5つで十分です。
GraphRAG: コンテキスト設計の基盤
従来のRAGはベクトル類似度でテキストの断片を取得します。独立した塊なのでマルチホップ推論が苦手で、ノイズも多く入り込みます。
GraphRAGはエンティティと関係性を構造化して保存します。「AがBに影響するとき、Cはどうなる?」のような複雑な質問に答えられ、検索時にアクセス権限を適用でき、どの関係経路を辿って結論を出したかも追跡できます。ベクトル検索とグラフ探索を組み合わせたAgentic GraphRAGが、現在のコンテキストエンジニアリングの核心アーキテクチャです。
今すぐ始める方法
- まず失敗パターンを診断する
エージェントのエラーログと会話履歴を見るとパターンが見えます。4つのうちどれに当てはまるか特定しましょう。 - 核心的な知識ドメインを定義する
エージェントが絶対に知っておくべきドメイン知識を一覧化します。これが後の知識グラフの骨格になります。 - RAGパイプラインを点検する
30個以上のツールを同時に提供しているならRAGでフィルタリングして減らしましょう。30個以下にするだけでツール選択精度が3倍向上するという研究結果があります。 - メモリ戦略を分離する
短期(現在のセッション)、中期(ユーザー履歴)、長期(ドメイン知識)を分けて設計します。すべての過去の会話を積み重ねるとコンテキスト散漫が起きます。 - Minimum Viable Contextにトリミングする
コンテキスト窓に入れる内容を意図的に減らしてみましょう。少なくしたときに性能が上がるなら、それがコンテキスト過負荷だった証拠です。
プロンプトエンジニアリングが無意味だという話ではありません
コンテキストエンジニアリングはプロンプトエンジニアリングを置き換えるのではなく、その上位概念です。単一タスクや素早いプロトタイピングにはプロンプト最適化が依然として効果的です。エージェントが複雑なマルチステップ業務を処理しなければならないとき、そのときにコンテキストエンジニアリングが必要になるんです。
もっと深く知りたい方へ
Context Engineering vs. Prompt Engineering (Neo4j) GraphRAGとMVCの概念が最初にまとめられた公式記事 neo4j.com
Context Engineering for AI Agents (Firecrawl) 32Kトークン限界、4つの失敗パターン、ツール最適化データの深掘り firecrawl.dev
Context Engineering vs. Prompt Engineering (Elastic) コンテキスト窓を能動的に設計するという実用的視点 elastic.co
Andrej Karpathy on Context Engineering このパラダイムシフトの起点となった原本X投稿 x.com
Why GraphRAG and MCP Are the New Standard GraphRAGがエージェントデータアーキテクチャの標準になった理由 hyperight.com
