コンテキストエンジニアリング：プロンプトエンジニアリングに取って代わったもの
長く「AI を使う」ことはほぼ一つでした：上手なプロンプトを書くこと。2025-2026 年にはそれだけでは足りません。モデルはツールを呼び、RAG で文書を取得し、セッション記憶を持ち、エージェントの連鎖で動きます。品質を決めるのは言い回しの巧みさではなく、コンテキストエンジニアリング - 各ステップでモデルが何を見るかを設計する技術です：指示・事実・履歴・権限・制約。以下では、古典的なプロンプトエンジニアリングをどう置き換え、製品や社内プロセスにどう落とすかを示します。
- プロンプト - 指示テキスト；コンテキスト - あるステップでのモデルへの全入力
- 転換 - 「魔法の一文を探す」から「正しいデータパケットを組み立てる」へ
- 層 - system、retrieval、記憶、tools、タスク状態、ポリシー
- 目的 - 安定性、幻覚の削減、トークンコスト制御
- 実践 - 狭く関連するコンテキストが「全部ウィンドウに突っ込む」に勝つ
- ビジネス向け - プロセスとアーキテクチャが、ChatGPT の幸運な一チャットに勝つ
プロンプトエンジニアリングとは - そして壁
プロンプトエンジニアリング（prompt engineering）は、LLM への依頼を、望ましいスタイル・形式・振る舞いに合わせて書く技術です：役割（「あなたはシニアアナリスト」）、few-shot、chain-of-thought、厳格な出力テンプレート。
向いているのは：
- チャット上の一回限りのタスク；
- 下書き生成；
- チームに「モデルへの聞き方」を教えること；
- 社内データなしのプロトタイプ。
限界はすぐ現れます：
| 状況 | プロンプトだけでは足りない理由 |
|---|---|
| 最新の価格と規程が必要 | 検索なしではモデルは料金表を知らない |
| 長い対話 / ツール付きエージェント | ウィンドウがノイズで埋まり、焦点が消える |
| 複数の役割とシステム | 「万能」system prompt が薄まる |
| リスクとコンプライアンス | ポリシーと PII マスクは「きれいな一文」ではない |
| API コスト | 毎ターン余分なトークン = 直接損失 |
プロンプトはシステムの一部のままです。ただし、品質の主レバーではなくなりました。
コンテキストエンジニアリングとは
コンテキストエンジニアリング（context engineering）は、各呼び出しでモデルへの完全な入力パッケージを設計することです：system に何を入れるか、知識ベースから何を取るか、記憶から何を使うか、どの tool 結果を見せるか、何を捨て、何を禁じるか。
プロンプトが「どう頼むか」なら、コンテキストは「どんな情報環境でモデルが答えるか」です。
典型的なコンテキスト層：
- 指示と役割 - system prompt、回答ポリシー、JSON/Markdown 形式。
- ユーザー課題 - 現在のリクエストと最小限の履歴。
- 取得知識 - wiki、CRM、コード、FAQ の断片（検索/RAG）。
- 状態 - ファネル段階、案件 ID、文書バージョン、前ステップの結果。
- Tool 観測 - API、SQL、ブラウザ、MCP の出力。
- 制約 - 「割引を約束しない」「PII を引用しない」「人にエスカレーション」。
コンテキストエンジニアは、幸運な一文のコピーライターではなく、パイプライン設計者として考えます。
コンテキストが「プロンプトの魔法」を置き換えた仕組み
| 以前（プロンプト中心） | 現在（コンテキスト中心） |
|---|---|
| 「万能」の長い system prompt | 狭い prompt + 入力の動的組み立て |
| PDF 全文をチャットに貼る | Retrieval：関連チャンクだけ |
| 「対話全部を覚えて」 | 圧縮、要約、選択的メモリ |
| 1 モデル - 1 チャット | エージェント、オーケストレータ + サブエージェント、別ウィンドウ |
| 品質 = 言い回しの技 | 品質 = 関連性、鮮度、層の順序 |
| プロンプト文をデバッグ | 出典をデバッグ：retrieval miss、tool 失敗、overflow |
パラダイム転換は、プロンプトの「死」ではありません。retrieval・記憶・tools・ポリシーの横の一層になっただけです - SQL クエリの横にスキーマとインデックスがあるのと同じです。
なぜ 2025-2026 に加速したのか
いくつかの要因が重なりました：
- エージェントと tools - モデルは答えるだけでなく行動する；コンテキストに tool 結果が必要。
- 長いウィンドウ - たくさん入れられるが、選別なしの「多さ」= ノイズと高コスト。
- 企業データ - RAG と文書バージョニングなしではビジネス回答にならない。
- マルチエージェント - 各サブエージェントには共有フルログではなく、独自の狭いブリーフが必要。
- コストとレイテンシ - コンテキストエンジニアはバックエンドが payload を最適化するように token 予算を最適化する。
実務は「prompt engineer」から、コンテキストパイプラインを組む platform/ML とプロダクトへ移りました。
実践：1 ステップ分のコンテキストを組む
LLM 呼び出し前のチェックリスト：
- ステップの目的 - 出力は何か（JSON、判断、下書き）。
- 最小限の指示 - tools とデータが既に与える内容を重複しない。
- Retrieval - メタデータ付き top-k（出典、日付、バージョン）。
- 履歴 - 関連ターンまたは短い要約のみ。スレッド全部は不可。
- Tool 出力 - 生でもよいが切り詰め；秘密や余分フィールドなし。
- トークン予算 - 硬制限；overflow 時は 指示 → タスク → 事実 → 履歴。
- ポリシー - 人がいないときモデルが断言してはいけないこと。
サポート例：
[system] 役割 + 禁止 + 形式
[retrieved] ナレッジベースの 3 チャンク（日付付き）
[state] チケット ID、顧客プラン、言語
[user] 現在の質問
こうしない：
[system] 「親切であれ...」が 4 ページ
[history] 80 メッセージ全文
[files] Notion ワークスペース全体
[user] 質問
コンテキスト vs プロンプト：悪い回答で直す場所
| 症状 | よくプロンプトで直す | よくコンテキストで直す |
|---|---|---|
| トーン / 形式が違う | はい：指示を締める | まれ |
| 捏造事実 | 「捏造するな」は弱い | Retrieval + 出典なしなら拒否 |
| 古い内容 | プロンプトに日付 | 文書バージョン + 鮮度フィルタ |
| モデルが課題を「忘れた」 | 最後に繰り返す | goal/state を別ブロックに |
| 高くて遅い | 丁寧語を削る | 履歴と retrieval ノイズを削る |
| 危険な操作 | 「慎重に」 | tool を外す / human-in-the-loop |
デバッグ原則：まずデータと選別、次に言い回し。
ビジネスにとっての意味
CRM、サポート、社内検索、コードエージェントに AI を入れるなら：
- 予算は「マネージャー向けプロンプト講座」からコーパス品質、索引、ログ、アクセスポリシーへ移る。
- 品質 KPI：retrieval ヒット率、「出典付き」回答比率、シナリオ単価、人へのエスカレーション。
- プロンプトプレイブックは手動チャットにはまだ有用 - 製品級 AI はコンテキストパイプラインとして作る。
- 長いコンテキスト、RAG、ファインチューニングの選択は別のアーキテクチャ判断；解説を参照。
経営者向け成熟度テスト：昨日の顧客ケースで、モデルがどの出典から答えを組んだか説明できるか。できないなら - まだチャット上のプロンプトエンジニアリングであり、システム上のコンテキストエンジニアリングではない。
よくある失敗
- ウィンドウが長いから「あるもの全部」をモデルに渡す。
- 動的組み立てではなく巨大な system prompt を維持する。
- RAG 文書をバージョン管理しない - 自信満々の古い回答。
- 短いブリーフではなくオーケストレータのフルログをサブエージェントに渡す。
- 「モデルに都合がいい」から秘密や PII をコンテキストに隠す。
- 言い回し改善とデータ欠損の修正を混同する。
まとめ
プロンプトエンジニアリングはモデルとの話し方を教えてくれました。コンテキストエンジニアリングは、ステップに必要な情報・ツール・制約だけをモデルに渡すシステムを教えるものです。2026 年の企業 AI 品質は「魔法の一文」ではなく、事実選定・記憶・tools・ポリシー・トークン予算のパイプラインで決まります。プロンプトはそのパイプラインの一部のまま - ただし主役ではありません。
よくある質問
コンテキストエンジニアリングはプロンプトエンジニアリングと何が違う？
プロンプトは指示テキストに焦点を当てます。コンテキストはモデルへの全入力を対象にします：指示 + 取得事実 + 履歴 + 状態 + tool 結果 + 禁止事項。プロンプトは一層；コンテキストはその層と他層を組み立てるシステムです。
2026 年でもプロンプトエンジニアリングは必要？
はい。スキルとしても層としても。 明確な指示、形式、few-shot は今も重要です。ただし製品やエージェントでは、データ選定・記憶・ポリシーなしに「完璧なプロンプト」だけで品質は安定しません。
RAG と同じ？
いいえ。より広い。 RAG はコーパス知識でコンテキストを埋める一つの方法です。コンテキストには対話記憶、ワークフロー状態、tool 出力、役割、安全ポリシーも含まれます。RAG は典型的で重要な部品であり、学科全体ではありません。
会社はどこから始めるべき？
シナリオを一つ選ぶ（サポート、規程検索、営業アシスタント）。真実の出典を固定し、日付/バージョン付き retrieval を入れ、履歴を要約に圧縮し、「コンテキストに何が入ったか」をログする。データが嘘をつかなくなってからプロンプトを詰める。
モデルではなくコンテキストの問題だとどう分かる？
モデル切替（GPT → Claude → Gemini）でエラーがほぼ変わらず、文書 / top-k / 履歴カットで変わるなら、問題は入力の組み立てです。コンテキストパイプラインが透明で計測可能になってからプロバイダを変えるべきです。