「プロンプトエンジニアリングはもう古い、これからはコンテキストエンジニアリングだ」——2025 年半ばから 2026 年にかけて、AI 業界の最前線でこの言葉が急速に広まった。Andrej Karpathy（元 Tesla AI ディレクター、現 OpenAI 創業メンバー）と Shopify CEO の Tobi Lütke が 2025 年 6 月に X で公開支持したのが起点で、Anthropic 公式エンジニアリングブログも「Effective context engineering for AI agents」という記事で正式に体系化した。

しかし日本市場での認知はまだ薄く、「プロンプトエンジニアリングとは具体的に何が違うのか」「業務 AI 設計でどう実装すればいいのか」「経営層に何を伝えるべきか」が整理されていない。本稿は、この用語の起源・正確な定義・Anthropic 公式の方法論・AX Boost 独自の3層モデル・業務 AI で起きる4つの失敗パターン を一気通貫で整理した、2026 年版の決定版実装ガイドである。

コンテキストエンジニアリングとは — 30秒で分かる定義

コンテキストエンジニアリング（Context Engineering） とは、LLM が応答を生成するために参照する コンテキスト（文脈）全体を設計・制御する技術 である。具体的には、コンテキストウィンドウに何を入れて何を入れないか、いつ入れていつ捨てるか、どの情報を優先するか、を一連の工学として扱う。

質問 簡潔な答え
コンテキストエンジニアリングとは？ LLM のコンテキストウィンドウに入れる情報全体を設計・制御する技術
プロンプトエンジニアリングと何が違う？ プロンプトエンジニアリングは「指示文」の最適化、コンテキストエンジニアリングは「指示文 + 履歴 + RAG + ツール + メモリ等」全体の最適化
誰が提唱した？ Andrej Karpathy・Tobi Lütke（Shopify CEO）が 2025 年 6 月に X で支持、Anthropic が公式に体系化
なぜ重要？ 長文脈モデルでも「Context Rot」現象で精度が落ちる。情報の取捨選択が業務 AI の成否を分ける
どこで使う？ RAG、AI エージェント、長期メモリ、マルチターン会話、ツール連携の全ての場面

つまり、「プロンプト1本を磨く」段階から、「LLM の情報環境全体を運用する」段階に AI 業界が進化した ことを示す用語である。

用語の起源 — 2025年6月の Karpathy・Tobi Lütke 宣言

「Context Engineering」という用語が定着したのは、2025 年 6 月の出来事が決定的だった。

Andrej Karpathy が X で投稿した内容（要旨）：

「プロンプトエンジニアリングよりも コンテキストエンジニアリング という呼び方を支持したい。人々はプロンプトを、日常的に LLM に与える短いタスク記述と関連付けて捉える。しかし、産業強度（industrial-strength）の LLM アプリでは、コンテキストエンジニアリングこそが、次のステップに必要な正しい情報をコンテキストウィンドウに詰め込む、繊細な技術と科学 なのだ。」

Shopify CEO Tobi Lütke も同時期に支持を表明し、AI コミュニティで急速に広まった。Karpathy の発言の重要なポイントは、「プロンプト = 短い指示」という素朴な理解に対し、本番運用される LLM アプリでは、コンテキスト全体の設計が決定的に重要 であると指摘したことにある。

Anthropic 公式の位置づけ

Anthropic は公式エンジニアリングブログ「Effective context engineering for AI agents」で、コンテキストエンジニアリングを 「プロンプトエンジニアリングの自然な進化形」 と定義した。両者は対立する概念ではなく、プロンプトエンジニアリングはコンテキストエンジニアリングの中核的な構成要素 として包含関係にある。

つまり 2026 年時点では、

コンテキストエンジニアリング ⊃ プロンプトエンジニアリング
   （広い概念）           （その中の一部）

という関係で整理されている。AI エージェント、RAG（RAGとは）、MCP（MCP完全解説近日公開）、長期メモリなどの技術は、すべてコンテキストエンジニアリングの傘下にある。

プロンプトエンジニアリングとの違い — 4軸で整理

両者の違いを4つの軸で整理する。

軸 プロンプトエンジニアリング コンテキストエンジニアリング
対象範囲 プロンプト（指示文）の最適化 プロンプト + 履歴 + RAG + ツール + メモリ全体
時間スコープ 1回の問いかけ単位（静的） セッション全体・複数セッション（動的）
代表手法 Few-shot、Chain of Thought（CoT）、Role Prompting RAG、ツール使用、メモリ管理、Compaction、Multi-Context
設計者の関心 「どう聞くか」 「何を見せて、何を見せないか」

プロンプトエンジニアリング は「1 回の問いかけで最高の回答を引き出す」ことが目的で、Few-shot 例示や CoT 推論などのテクニックが中心。コンテキストエンジニアリング は「LLM が動作する情報環境全体を設計する」ことが目的で、データ取得・履歴管理・ツール連携・メモリ運用までを含む工学領域である。

業務 AI 設計の文脈で言えば、プロンプトエンジニアリングは「個別タスクの精度を上げる」段階で有効、コンテキストエンジニアリングは「継続運用される業務エージェントを設計する」段階で不可欠になる。AI エージェントの全体設計論は AIエージェント業務導入の設計論 で論じている。

Anthropic 公式の方法論 — 4つの実装手法

Anthropic 公式が体系化した、コンテキストエンジニアリングの 4つの主要手法 を整理する。これは Claude を使う場面に限らず、GPT-4o / Gemini / Llama 等の他モデルでも同様に適用できる原則である。

手法1 / Compaction（圧縮）

Compaction（コンパクション）とは、コンテキストウィンドウの上限に近づいた会話を 要約して新しいコンテキストに再開 する手法。会話履歴が長くなりすぎる前に、要点を凝縮した「高密度な要約」を作り、それを次のコンテキストの起点にする。

[長い会話履歴 50,000 トークン]
   ↓ Compaction
[要約 3,000 トークン] + [継続会話のための新しいコンテキスト]

Anthropic 公式は「Compaction はコンテキストエンジニアリングの第一の手段」と位置づけている。ポイントは、要約の品質を最大化するために プロンプトを慎重にチューニングする こと。最初に「Recall（網羅性）を最大化」する要約プロンプトを書き、次に「Precision（精度）を最大化」する方向に反復改善する設計が推奨されている。

手法2 / Tool Result Clearing（ツール結果消去）

AI エージェントが外部ツール（検索 API、計算ツール、データベースクエリ等）を使うと、その結果がメッセージ履歴に蓄積される。長いセッションでは ツールの生結果がコンテキストを圧迫し、ノイズになる。これを定期的に消去するのが Tool Result Clearing。

Anthropic Developer Platform では、これを 最も安全で軽量な圧縮手法 として最新機能で実装している。実装イメージ：

  • 直近 3 ステップのツール結果は保持
  • それより古いツール結果は「ツール名 + 取得済み」のメタデータだけ残し、本体を削除
  • 必要になったら再呼び出し

手法3 / Just-In-Time Context（必要時取得）

事前に全データをコンテキストに詰め込むのではなく、軽量な識別子（ファイルパス、保存済みクエリ、URL 等）だけを保持し、必要なタイミングで動的にロード する手法。

[事前ロード型]
コンテキスト = システムプロンプト + 全データベース内容（10万トークン）
   → Context Rot で精度低下

[Just-In-Time型]
コンテキスト = システムプロンプト + ファイルパス一覧（500トークン）
   → 必要時に "read_file(path)" でロード

これは Claude Code のような長期実行エージェントで標準的に採用されている設計。RAG の世界でも、「全部詰め込む RAG」から「段階的に取得する Agentic RAG」への進化を牽引している考え方である。

手法4 / Multi-Context Window Workflows（複数コンテキスト連携）

1 つのタスクを複数のコンテキストウィンドウに分割し、専門化した複数エージェントが連携する設計。Anthropic は 「Initializer Agent」+「Coding Agent」 の二段構成を例示している。

エージェント 役割
Initializer Agent 初回実行時に環境セットアップ、コンテキスト初期化
Coding Agent 各セッションで漸進的に作業を進め、次セッションのために明確な artifact を残す

これは 「人間チームの分業」を AI エージェントに持ち込んだ設計 で、長時間の複雑タスクで威力を発揮する。MCP（Model Context Protocol）を使うと、各エージェントが共通の文脈・ツールにアクセスできる（MCP完全解説近日公開 参照）。

Context Rot（コンテキスト腐敗）— 知っておくべき現象

Anthropic の研究で確認されている重要な現象が 「Context Rot」。これは コンテキストウィンドウのトークン数が増えるほど、モデルの情報想起精度が落ちる という現象である。

「Needle in a haystack（干し草の中の針）」ベンチマーキングで確認されており、たとえ 100 万トークンの長文脈モデルでも、情報を詰め込みすぎるとモデルが情報を見落とす。「少量の高シグナルトークン」が常に最適解になる、というのが Anthropic 公式の結論。

これは「長いコンテキスト = 高性能」という素朴な前提を否定する重要な知見で、コンテキストエンジニアリングの必要性そのものの根拠になっている。

AX Boost 独自フレーム — コンテキスト3層モデル

業務 AI の実装現場で観察される設計パターンを、AX Boost では 「コンテキスト3層モデル」 として整理している。Static / Dynamic / Retrieved の 3 層に分け、各層の役割と運用ルールを明確化する。

Layer 1 / Static Context（静的層）

特徴: セッション開始時に固定され、原則として変更しない情報。

含まれる内容 例
システムプロンプト エージェントの役割定義、出力フォーマット、禁止事項
ツール定義 利用可能な外部 API・関数のスキーマ
業務ルール 業界用語集、社内ポリシー、コンプライアンス要件
出力スキーマ JSON Schema、レスポンス形式

運用ルール: 慎重に設計し、変更時はバージョン管理。Few-shot 例示はここに含まれる場合と Dynamic 層に置く場合がある。1,000〜5,000 トークン程度 が目安。

Layer 2 / Dynamic Context（動的層）

特徴: セッション中に蓄積される情報で、適切に圧縮・破棄が必要。

含まれる内容 例
会話履歴 ユーザーとエージェントの直近 N ターン
ツール実行結果 API レスポンス、計算結果
中間推論 エージェントが考えたステップ
短期メモリ 「ユーザーが好む形式」「現在の作業対象」等

運用ルール: Compaction（要約による圧縮）と Tool Result Clearing（古い結果の削除）を積極適用。コンテキストウィンドウの 30〜50% に収まるよう自動管理。

Layer 3 / Retrieved Context（取得層）

特徴: 必要時に外部から動的に取得され、使用後は破棄される情報。

含まれる内容 例
RAG で取得した文書チャンク 社内マニュアル、過去案件レポート
データベースクエリ結果 顧客情報、在庫データ
Web 検索結果 最新ニュース、競合情報
MCP 経由のリソース 他社システムの API レスポンス

運用ルール: Just-In-Time で取得、使用後はメタ情報のみ残して本体を破棄。長期メモリに保存すべきものは Dynamic 層に昇格させる。

3層モデルの実装イメージ

[コンテキストウィンドウ 全体]
┌─────────────────────────────────┐
│ Layer 1: Static (固定)           │  ← 1,000-5,000 tok
│  - システムプロンプト              │
│  - ツール定義                     │
│  - 業務ルール                     │
├─────────────────────────────────┤
│ Layer 2: Dynamic (自動圧縮)       │  ← 30-50% of window
│  - 会話履歴 (Compaction 対象)      │
│  - 中間推論                       │
│  - 短期メモリ                     │
├─────────────────────────────────┤
│ Layer 3: Retrieved (Just-In-Time) │  ← 必要分のみ
│  - RAG 取得チャンク                │
│  - DB クエリ結果                  │
│  - Web 検索結果                   │
└─────────────────────────────────┘

この 3 層モデルを設計の起点にすると、「どの情報がどの層に属するか」「いつ追加/破棄するか」を一貫して整理 できる。業務 AI エージェントの全体設計と組み合わせる方法論は AIエージェント業務導入の設計論 で詳しく論じている。

業務 AI で起きる「コンテキストの 4 つの失敗」

実装現場で観察される、コンテキストエンジニアリング不在による典型的な失敗パターンを 4 つに整理する。

失敗1 / 情報過多型 — 「全部入れたら賢くなるはず」の罠

最も典型的な失敗。「100 万トークンの長文脈モデルだから、関連資料を全部入れよう」と考えると、Context Rot で逆に精度が落ちる。実例：法務 AI に過去全契約書 200 件を全部入れた結果、本案件と関係ない条項を引用してしまう、など。

対策: Retrieved 層で 関連度上位 5-10 件のみ をロードする。RAG の検索精度を上げる方が、コンテキストを膨らませるより効果的。RAG 実装の詳細は Fine-tuning vs RAG と ハルシネーション対策の実装論近日公開 を参照。

失敗2 / 古コンテキスト保持型 — 「履歴は全部残しておけば安全」の罠

会話履歴を消さずに溜め続けると、エージェントが 「セッション開始時の話題」に引きずられ続ける。実例：カスタマーサポート AI が、最初の問い合わせ内容を引きずって、新しい問い合わせに的外れな回答をする。

対策: Compaction で 古い履歴を要約、最新 N ターンの生履歴 + 圧縮要約という構造に。Anthropic Developer Platform の自動 Compaction 機能を利用する。

失敗3 / ツール結果蓄積型 — 「全ツール結果を見せれば判断できる」の罠

エージェントが 10 回ツールを呼ぶと、10 回分の結果がメッセージ履歴に積み上がる。ノイズで本質的な判断材料が埋もれる。実例：データ分析 AI が SQL を 20 回実行し、結果の海に溺れて最終回答が支離滅裂になる。

対策: Tool Result Clearing で 直近 3 ステップ以外を消去。必要なら再実行する設計に。

失敗4 / RAG 誤検索型 — 「RAG を入れたから情報は正しい」の罠

RAG の検索ロジックが弱いと、質問と無関係なチャンクを取ってくる。それが Static 層のシステムプロンプトより強く影響して、誤った前提に基づく回答が生成される。実例：医療 AI が古いガイドラインのチャンクを取得し、現行ガイドラインに反する助言をする。

対策: RAG の チャンキング戦略・検索精度・ランキング を継続改善。LLM-as-Judge による評価フレームを組み込む（AI評価フレームの実装論近日公開 参照）。

業務 AI 実装でのフェーズ別アプローチ

コンテキストエンジニアリングを業務 AI 実装で段階的に組み込むためのフェーズ別アプローチを示す。

フェーズ1 / プロトタイプ期（〜1ヶ月）

  • Static 層のシステムプロンプトを丁寧に設計（プロンプトエンジニアリング中心）
  • 簡易 RAG（チャンク 5-10 件取得）で動作確認
  • Dynamic 層は最小限（直近会話のみ）

このフェーズでは 「動くものを作る」が優先。コンテキスト設計は次フェーズで本格化する。

フェーズ2 / PoC 期（1-3ヶ月）

  • 3層モデルを明示的に設計
  • Compaction の試験導入（要約品質を測定）
  • Tool Result Clearing の自動化
  • LLM-as-Judge で出力品質を継続測定

このフェーズで Context Rot が顕在化 することが多い。「長コンテキストにすれば賢くなるはず」という前提が崩れ、3層モデルに移行する転換点。

フェーズ3 / 本番運用期（3-12ヶ月）

  • Just-In-Time Context への移行
  • Multi-Context Window Workflows の検討（複雑タスク向け）
  • メモリ運用ルールの確立（短期/長期の分離）
  • A/B テストでコンテキスト構成を最適化

このフェーズで 「使われ続ける AI」と「使われなくなる AI」が分かれる。Context 設計の品質が、ROI を最終的に決める。AI 定着失敗パターンの詳細は AI定着失敗の典型7パターン を参照。

フェーズ4 / スケール期（1年以降）

  • マルチエージェント・オーケストレーション
  • MCP 経由の組織横断コンテキスト共有
  • 業務領域別に専用 Coordinator Agent
  • Context Window の定常モニタリングと改善 KPI 化

組織として 「コンテキストエンジニアリングを継続改善する体制」 が必要になる。AI CoE の組成と運用は AI Center of Excellence (CoE)近日公開 で論じている。

経営層が知るべきコンテキストエンジニアリングの含意

「これは技術用語だから経営層は関係ない」と思われがちだが、経営判断に直結する含意 がいくつもある。

含意1 / AI 投資の費用構造が変わる

LLM 利用料金は トークン課金 が基本。コンテキストエンジニアリングを適切に行わないと、無駄なトークンを大量消費して AI 利用コストが想定の 3〜5 倍 に膨らむ。逆に Compaction や Just-In-Time が機能すれば、コストを 50〜70% 削減可能。AI 投資の ROI を語る上で必須の論点である（AI ROIの測定方法近日公開 参照）。

含意2 / 「長コンテキスト = 高性能」は誤り

ベンダーの「100 万トークン対応」「200 万トークン対応」というアピールは、それだけでは性能を意味しない。Context Rot を回避できる設計能力こそが、業務 AI の実成果を決める。「モデル選定」だけでなく「コンテキスト設計」を評価軸に入れる べき。

含意3 / 内製 vs 外注の判断軸が変わる

コンテキストエンジニアリングは 継続的な改善が必要な工学領域。一度作って終わりではなく、「使われ方の変化」「データの追加」「業務ルールの更新」に合わせて、コンテキスト設計を磨き続ける必要がある。これを担える内製チームを作るか、FDE 型コンサルで継続支援を受けるかが、長期的な競争力を分ける。判断軸は AI内製化 vs 外注近日公開 を参照。

含意4 / ベンダー選定の質問が変わる

これまでの「どのモデルを使っていますか？」という質問だけでは不十分。「Compaction はどう実装していますか？」「Tool Result Clearing はありますか？」「Just-In-Time Context への対応は？」 といった、コンテキストエンジニアリング能力を見る質問を選定プロセスに組み込むべき。AI コンサル選定の詳細は AIコンサル発注前に確認すべき7つの質問近日公開 と AIコンサル会社の選び方完全ガイド 2026年版 を参照。

よくある質問（FAQ）

Q1. コンテキストエンジニアリングはプロンプトエンジニアリングの置き換えですか？

A. 置き換えではなく 包含関係。プロンプトエンジニアリングはコンテキストエンジニアリングの中核的な構成要素として位置づけられている。「プロンプトを書く能力」は依然として基礎スキルだが、本番運用される AI エージェントでは 「コンテキスト全体の運用設計」 が決定的になる。

Q2. 長文脈モデル（Claude Opus / Gemini 2M context）を使えばコンテキストエンジニアリングは不要では？

A. むしろ逆。Anthropic が確認した 「Context Rot」 現象により、長コンテキストモデルでも情報を詰め込みすぎると精度が落ちる。「使える容量があるから全部使う」のではなく、「必要最小限の高シグナルトークンを選ぶ」 ことが常に最適解。

Q3. Compaction の要約品質をどう担保しますか？

A. Anthropic 推奨は 「Recall 最大化 → Precision 最大化」の二段階チューニング。最初に「全ての関連情報を捕捉できる要約プロンプト」を作り、次に「冗長な情報を削る」方向に反復改善する。LLM-as-Judge で要約後の情報損失を継続測定する仕組みも有効。

Q4. Just-In-Time Context と RAG はどう違いますか？

A. RAG は Just-In-Time Context の 典型的な実装パターンの一つ。広く言えば、「事前ロード」vs「必要時取得」の対立軸で、Just-In-Time が後者を指す総称。RAG 以外にも、ファイルシステム読み込み、DB クエリ、MCP 経由のリソース取得などが含まれる。

Q5. Multi-Context Window Workflows は中小企業でも実装可能ですか？

A. シンプルな用途では過剰投資。複数エージェントの連携設計・状態管理・エラーハンドリングが必要で、実装コストが高い。まずは単一エージェント + 3層モデルで十分、複雑な長時間タスクが必要になってから検討するのが現実的。

Q6. コンテキストエンジニアリングを社内で学ぶには？

A. 第一段階は Anthropic 公式エンジニアリングブログ（"Effective context engineering for AI agents"）の精読。第二段階は Claude / GPT で実際にエージェントを作る。第三段階は LLM-as-Judge での評価フレーム導入。社内研修プログラムへの組み込みは AIリテラシー人材育成近日公開 で論じている。

Q7. AX Boost は具体的にどう支援しますか？

A. AX Boost は FDE 型コンサルとして、(1) 業務要件からの 3 層モデル設計、(2) Anthropic 公式手法の実装、(3) LLM-as-Judge による継続評価、(4) コンテキスト設計の運用 KPI 化、までを現場常駐で一気通貫に支援する。料金体系は月額固定・成果報酬・ハイブリッドから選択可能で、初回相談は無料。

Q8. コンテキストエンジニアリングは AI 規制とどう関係しますか？

A. 経産省・総務省『AI 事業者ガイドライン第 1.1 版』（2025 年 3 月 28 日）が求める 「説明可能性」「監査可能性」 は、コンテキストエンジニアリングの設計品質に直結する。「なぜこの回答が生成されたか」を遡及できるかは、どの情報がコンテキストにあったか をログ化できているかに依存する。詳細は 企業のAIガバナンス実務ガイド近日公開 を参照。

まとめ — コンテキストエンジニアリングは「次のプロンプトエンジニアリング」ではなく、それを包含する新しい工学

コンテキストエンジニアリング は、業務 AI の本番運用フェーズで決定的に重要になる工学領域である。プロンプトエンジニアリングを否定する概念ではなく、それを内包しつつ、LLM が動作する情報環境全体を設計する という、より広い視野の技術体系。

押さえるべきは 5 点：

  1. Anthropic 公式 4 手法（Compaction / Tool Result Clearing / Just-In-Time / Multi-Context）を理解する
  2. Context Rot 現象により「長コンテキスト = 高性能」ではない、を前提にする
  3. AX Boost「コンテキスト3層モデル」（Static / Dynamic / Retrieved）で設計を整理する
  4. 4 つの失敗パターン（情報過多/古コンテキスト保持/ツール結果蓄積/RAG 誤検索）を回避する
  5. 経営層は AI 投資の費用構造・モデル選定軸・ベンダー選定基準 の変化として認識する

業務 AI を本気で運用フェーズに乗せるなら、コンテキストエンジニアリングは避けて通れない。AX Boost では FDE 型コンサルとして、戦略策定〜実装〜定着まで現場常駐で支援している。お困りの方は 無料相談 をご利用いただきたい。

関連記事

  • AIエージェント業務導入の設計論 — エージェント全体設計の方法論
  • RAGとは — 検索拡張生成の基礎と本番アーキテクチャ
  • Fine-tuning vs RAG — 使い分けと最新動向
  • MCP（Model Context Protocol）完全解説近日公開 — エージェント連携の業界標準
  • AIハルシネーション対策の実装論近日公開 — 「もっともらしい嘘」を業務で許容しない設計
  • AI評価フレームの実装論近日公開 — LLM-as-Judge を組み込む評価設計
  • 業務AIインフラの技術選定近日公開 — ベクトルDBとマルチエージェント基盤
  • AIコンサル発注前に確認すべき7つの質問近日公開 — コンテキストエンジニアリング能力を見極める質問

主要参照ソース