Context Engineering: プロンプトと信頼できるAIプロダクトの間にある層
AIが回答や行動の前に受け取る情報、状態、ツール、制約、評価を設計し、ワークフローを再現可能にする実務。
最終更新
Context Engineeringは、AIが回答や操作の前に受け取る情報を選び、整え、テストする実務です。promptはその環境の一部にすぎません。文書、ユーザーの状態、memory、retrieval、ツールへのアクセス、権限、出力形式、guardrail、評価方法まで含めて設計します。
この言葉が役に立つのは、多くのAIプロダクトの失敗がモデルそのものの能力不足ではないからです。モデルは十分に答えられるのに、誤った契約書を読んでいる、現在のaccount stateを知らない、古いpolicyを取得している、前の判断を失っている、必要な確認なしにtoolを呼んでいる。このような時、promptを少し上手く書いても、存在しない業務情報を作ることはできません。
単発のチャットだけなら抽象的に見えるかもしれません。しかしsupport、repository、顧客データ、複数ステップの作業を扱うと、Context Engineeringは製品の基盤になります。本稿の前提は2026年7月12日に確認しました。
具体例: 返金問い合わせに必要なコンテキスト
「返金についての顧客の質問に、policyに従って答えてください」というpromptだけでは、運用には足りません。
| Assistantに必要なもの | なぜ必要か |
|---|---|
| 現在の返金policy | 古い版では期限や例外が違うことがある |
| 購入日、plan、地域 | 権利、税、契約条件が変わることがある |
| 過去のsupport履歴 | すでに行った約束やescalationを失えない |
| Escalation rule | 人が確認すべき例外を自動で約束しないため |
| 表現の制約 | 法的・契約上の表現を自由に作らないため |
| 引用できる根拠 | 顧客と担当者が正式な条件を確認できるため |
このどれかがない、または古いと、返答は丁寧でも間違う可能性があります。Context Engineeringでは、何を見せたかだけでなく、何を見せるべきだったか、外部文章をどこまで指示として扱わないかも確認します。
四つの作業領域
| 領域 | 問い | 代表的な仕組み |
|---|---|---|
| 情報源の選択 | 何を見せるか | retriever、文書index、DB query、file picker |
| 状態の管理 | 複数ステップで何を保持するか | 利用者の目的、承認、session history、権限 |
| 指示の設計 | 情報とルールをどう使うか | system instruction、task contract、出力形式 |
| 評価 | 追加したcontextは本当に改善したか | test case、trace、review score、regression check |
これらは独立していません。目的がなければretrievalは関係ない文章を増やします。現在の状態がなければ、良い指示も不完全です。正しいデータにアクセスできても、toolの権限が広すぎれば危険です。テストがなければ、新しい情報源が一つのdemoだけを良くしたのか、全体を良くしたのかは分かりません。
近い言葉との違い
| 言葉 | 中心 | 全体での位置 |
|---|---|---|
| Prompt Engineering | 指示文の書き方 | Context Engineeringの一部 |
| RAG | 必要な外部情報を取得する | 情報源を選ぶ一つの方法 |
| Agent workflow | 複数ステップを計画し実行する | context、state、tool、評価を必要とする |
| MCP | toolとdata sourceをつなぐ標準 | 接続を扱いやすくするが、選択の代わりではない |
| Memory | 会話や作業の情報を保持する | 状態管理の層 |
| Observability | input、output、traceを見えるようにする | contextの失敗を見つける基盤 |
この違いは購入判断にも関わります。「良いpromptを作る」だけでは狭い課題です。チームが必要とするのは、なぜAI作業が失敗したのかをdebugすることです。どの情報源が入ったか。必要な情報源はなぜ入らなかったか。指示を無視したのか、そもそも受け取っていないのか。どのtool callが結果を変えたのか。
「Context Platform」より先にTraceを作る
最初の内部ツールやプロダクトは、すべてのmemoryとRAGを解決する必要はありません。再現できるtraceから始められます。
| 手順 | 記録すること | 役立つ理由 |
|---|---|---|
| 仕事 | ユーザーの問い、成功条件、リスク | 実行の目的を固定する |
| 入力 | 使った文書、field、version、出所 | 欠けた、または古い情報源が見える |
| Retrieval | 候補、選んだ理由、使わなかった候補 | ノイズと誤った選択を見つける |
| 状態 | 前の判断、役割、権限、地域 | AIが状態を想像しないようにする |
| Tool | 名前、parameter、結果、承認 | 操作を確認可能にする |
| 出力 | 構造、出典、不確実性、escalation | 人が結果をreviewしやすくする |
| Test | 同じ仕事の変更前後 | 改善と偶然を分ける |
例えばCoding Assistantが誤った設定変更を提案した時、「promptが弱い」とだけ考えません。現在のdocsがcontextに入っていない、古いREADMEが優先された、repository ruleが欠けた、deployment stateを知らないまま外部commandを提案した、という可能性を順に確認します。
日本のチームでの実務シナリオ
| チーム | 仕事 | 欠けやすいcontext | 安全な最初の改善 |
|---|---|---|---|
| B2B support | セキュリティ質問票の回答案 | 承認済み表現、契約例外、顧客の言語 | 根拠を付けた下書きと人の承認 |
| 開発チーム | repositoryのsetup errorを探す | branch、runtime version、社内build rule | 読み取り専用traceと使ったファイル一覧 |
| Ecommerceチーム | 商品説明を市場向けに調整する | 許可されたclaim、catalog、配送地域 | claim flagを付けた構造化下書き |
| Enablementチーム | 学習資料を要約する | 対象者、現在のpolicy、機微な情報 | 許可済み資料だけを使い、私的なメモを残さない |
日本語の購買・support資料と英語の技術docsが共存する場合は、単に「すべての文書を読む」としません。どの日本語ページがsalesと稟議の正式情報か、どの英語資料が技術的に最新か、どの主張は人の確認なしに出してはいけないかを分けます。
見えるようにすべき失敗
Contextを増やしすぎる
文書が多いほど良いわけではありません。長いcontextは現在のruleを埋もれさせ、untrusted textを強くし、仕事を曖昧にします。どの情報源が回答に役立ったかを確認します。
古い、または矛盾する情報源
古いpricingやpolicyを返すretrieverは、同じ誤りを繰り返します。重要な情報源にはversion、owner、確認日を持たせます。
仕事の枠がないtool権限
Agentに利用可能なすべての操作を見せる必要はありません。scope、consent、人の承認もcontextの一部です。
Regression testがない
一つのdemoが良くなっても、他の十件が悪くなることがあります。通常、不完全、悪意ある入力を含む小さなtest setを残します。
小さなチームの始め方
- supportの下書きやdocs検索のように、失敗の影響が分かる繰り返し業務を一つ選ぶ。
- 成功した実行と失敗した実行について、情報源、状態、tool callを記録する。
- 一つの失敗につき、足りない、またはノイズになった情報を一つだけ印にする。
- prompt全体を書き換える前に、選択、version、承認を直す。
- 同じtest caseを繰り返し、業務を知る人が結果をreviewする。
- 基本が追えるようになってからmemoryやtoolを増やす。
Context EngineeringはAIを魔法のように正しくするものではありません。なぜ正しいか、なぜ間違ったかを見える形にし、修正できるようにする仕事です。