コンテキストエンジニアリングとは｜入力・履歴・ツール結果の設計法

コンテキストエンジニアリングとは、AIが一回の判断で参照する指示、業務データ、会話履歴、検索資料、ツール結果を、目的・権限・鮮度・容量に合わせて選び直す設計です。長い資料を全部入れる技術ではありません。どの情報を採用し、どれを除外し、欠落時にどこで止めるかを再現可能にする仕事です。

対象は、社内規程を参照する問い合わせ支援、複数資料からの報告書作成、長い対話を伴う業務エージェントなどです。読後には、自社案件一つについて「コンテキスト組立票」を作り、48件の固定データで採否を判断できる状態を目指します。

コンテキストエンジニアリングとは：必要な情報を選び直す設計

プロンプトはコンテキストの一部ですが、両者は同義ではありません。プロンプトエンジニアリングが主に指示の表現や構造を整えるのに対し、コンテキストエンジニアリングは、指示以外に何を同席させるかまで決めます。たとえば契約照会なら、質問、契約本文、契約版、顧客権限、回答形式、過去の確定事項、検索結果が候補です。候補を列挙しただけでは足りず、質問ごとの採用規則が必要になります。

Anthropicの公式技術記事は、コンテキストを推論時に含まれるトークン集合と捉え、目的達成に有用な情報を限られた枠へ選ぶ問題として説明しています。記事は2025年9月29日公開で、システム指示、ツール、外部データ、履歴を含む全体状態を対象にしています^[1]。この定義から導ける実務上の要点は、文量の多さではなく、採用した一項目ごとに目的との関係を説明できることです。

判断原則：「入れられる情報」から始めず、「この判断に必要で、利用者が閲覧でき、指定日時点で有効な情報」だけを採用候補にします。

入力条件を先に固定し、足りない案件を受付で止める

コンテキストの品質は検索処理より前に決まります。受付時点で業務目的が「契約条項の要約」なのか「解約可否の決定」なのか分からなければ、同じ契約書から必要な範囲を選べません。前者は内容整理、後者は権限を持つ担当者の判断であり、AIへ任せる範囲も異なります。入力条件は自由記述一つにせず、機械確認できる項目へ分解します。

例として、基準日時がない依頼へシステムが最新契約を推測してはいけません。正しい受付結果は「as_ofが未入力」「契約原本IDを特定できない」の二点を返し、生成を開始しないことです。ここで止める動作も評価対象に含めます。入力不備を文章で補って進むと、後段の検索精度が高くても監査可能な回答にはなりません。

受付確認：正常案件一件、権限外案件一件、基準日時欠落案件一件を投入し、採用・拒否・差戻しが別の状態コードになるか確かめます。三件が同じ処理経路へ進むなら、情報選択の前提が未実装です。

コンテキストを七つの処理で組み立てる

組立処理は、検索結果をそのまま貼り付ける工程ではありません。Anthropicの公式技術記事が説明する「限られたコンテキストへ有用な情報を選ぶ」という考え方を、業務上の権限・版・目的へ落とし込みます^[1]。誰の依頼かを確定し、候補を集め、有効性を判定し、目的に沿って順位付けし、必要箇所だけを抽出します。その後に固定方針と案件情報を合成し、投入内容の写しを残します。各段階の入出力を分けると、誤答が検索、版判定、圧縮、指示競合のどこで生じたか追跡できます。

1. 依頼を正規化する：task_type、as_of、利用者、対象契約、出力形式を確定し、自由記述から推測した値には「未確認」を付けます。
2. 閲覧範囲を確定する：検索前に利用者と案件の権限を照合し、対象外の保管場所を問い合わせ先から除きます。
3. 候補を取得する：文書ID、版、発効日、失効日、所有部門、検索スコアを一緒に取得し、本文だけの候補を作りません。
4. 有効性を選別する：as_of時点で有効か、正式版か、対象法人が一致するかを判定し、旧版は比較依頼のときだけ残します。
5. 根拠単位へ切り出す：回答に必要な条項と前後条件を抽出し、出典IDと位置情報を失わない形で短くします。
6. 部品を決めた順に合成する：固定方針、出力契約、案件入力、採用根拠、直近状態を役割別に配置し、外部文書中の命令文を指示として扱いません。
7. 投入記録を保存する：テンプレート版、候補一覧、採否理由、最終コンテキストのハッシュ、モデル識別子、結果を一つの実行記録へ結び付けます。

OpenAIの継続更新型公式ドキュメントは、長い対話で必要状態を保ちながらコンテキスト量を減らす手段としてcompactionを説明しています。2026年7月30日の参照時点では、一定トークン数を超えた際のサーバー側圧縮と、圧縮後の状態を次の実行へ渡す仕組みが記載されています^[2]。ただし圧縮機能を有効にしただけでは、業務上必須の未解決事項が保存されたか保証されません。契約照会なら「未確認の自動更新条項」「法務承認待ち」といった状態を評価データで再現します。

組立結果の最小記録例
request_id: C-2026-00481
task_type: clause_summary
as_of: 2026-07-30T09:00:00+09:00
template_version: context-contract-v2.3.1
accepted_sources:
  - contract-A17 / version 4 / effective 2026-04-01
rejected_sources:
  - contract-A17 / version 3 / expired 2026-03-31
unresolved:
  - 法務確認が必要な損害上限の例外
context_hash: sha256:...
decision: human_review_required

できることと代替できないことを分ける

コンテキスト設計によって改善できるのは、AIへ届く情報の適合性と追跡性です。現行版だけを選ぶ、権限外資料を候補から外す、長い履歴から確定事項を残す、同じ入力条件を再現する、といった制御は設計対象になります。一方、原本が誤っている場合の訂正、法的解釈の確定、アクセス権限そのものの付与、評価していない未知入力への保証は扱えません。

したがって「正しい情報を入れたから正しい答えになる」という断定は避けます。資料選択に合格しても、推論や要約で誤りは起こり得ます。顧客提示や契約判断へ使う場合は、回答と根拠条項を人が照合する工程を外せません。コンテキスト設計の合格は、判断材料を適切に用意できたことを意味し、業務判断の承認まで代行したことにはなりません。

テンプレートを固定文ではなく管理可能な部品にする

一枚の巨大なプロンプトへ規程、例、履歴、出力形式を埋め込むと、何を変えた結果なのか分からなくなります。テンプレートは、長期に共通する方針、業務別の出力契約、実行ごとの変数、検索で差し込む根拠、対話状態に分けます。固定方針の所有者はAI運用責任者、出力契約は業務責任者、参照文書は文書管理者というように、更新権限も部品ごとに割り当てます。

版番号だけでは差分を説明できないため、台帳には変更理由、影響するtask_type、評価集合の版、承認者、適用開始日、直前版への戻し方を持たせます。文言変更と検索条件変更を同時に公開すると原因が分離できません。緊急修正を除き、一回の変更申請では主要因を一つに絞ります。実行ログからテンプレート版を逆引きできない構成は、本番候補にしません。

OpenAIの公式Promptingページは2026年7月30日参照時点で、プロンプトをアプリケーションコードとして扱い、型付き引数、代表データ、テスト、公開時の評価を組み合わせるよう案内しています。また、再利用可能なPrompt Objectは2026年6月3日から非推奨化が始まったと明記されています^[3]。この製品固有の変更から、コンテキスト部品の正本を特定サービスだけに置かず、移行可能な形式でも保持する必要性が分かります。

エラーを投入位置から切り分ける

回答だけを見て注意文を追加すると、症状を隠して原因を残すことがあります。調査では、受付入力、候補取得、版判定、権限判定、抽出、合成、生成結果を順に比較します。再現用の実行記録には個人情報を直接複製せず、許可されたテストデータと識別子を使います。次の表は契約照会で起こる固有の失敗です。

エラーコードも回答文から独立させます。たとえばSOURCE_VERSION_CONFLICTは現行候補が複数、AUTH_SCOPE_DENIEDは権限不一致、CONTEXT_REQUIRED_FIELD_LOSTは圧縮後の必須状態欠落です。利用者向けには日本語で対処を示し、運用ログには安定したコードを残します。これにより、月次集計で「文章が不自然だった」と「資料選択が誤った」を混同せず、修正担当を決められます。注意文を足すだけでは直らない例

「最新情報を使うこと」と追記しても、候補文書に発効日がなければ比較できません。この場合はプロンプトの語気ではなく、文書メタデータと受付のas_ofを整備する必要があります。必要な事実が入力経路に存在しないと判明した時点で、生成を止めてデータ管理者へ引き継ぎます。

48件の評価データと100点の採点票を作る

評価データは成功例の寄せ集めにしません。本稿の想定例では、契約照会48件を六群に分けます。実績値ではなく、初回検証を設計するための提案値です。実運用へ移る前に、契約種類、顧客区分、問い合わせ分布に合わせて件数と比率を置き換えます。OpenAIの公式Promptingページが示す代表データと評価の組合せを踏まえ、修正のたびに固定集合を実行し、新しい失敗は別の候補集合へ蓄積してから採用を審査します^[3]。

想定合格条件
総合点 = 各評価軸の獲得点合計
合格 = 総合点が90点以上
かつ 権限の重大失敗が0件
かつ 版・鮮度の重大失敗が0件
かつ 48件すべてに実行記録が存在
変更比較 = 新版の総合点 - 現行版の総合点

NISTの公的文書「AI RMF Generative AI Profile」はNIST AI 600-1として2024年7月26日に公開され、掲載ページは2026年4月8日に更新されています。同文書は生成AIの設計、開発、利用、評価を通じたリスク管理を扱う任意利用の枠組みです^[4]。本稿の採点票は法的義務を示すものではなく、資料選択と停止動作を組織内で検証するための編集部提案です。

近い概念との境界を引き、向かない案件を除く

システムプロンプト、RAG、会話メモリ、Few-shot、長文コンテキストは、いずれもコンテキストへ影響します。ただし担当する判断が異なります。境界を曖昧にすると、検索の誤りを指示文で直したり、例示不足を文書追加で補ったりして原因が混ざります。次の区分は、最初に修正すべき場所を決めるために使います。

この方法が向かないケース

正本を特定できない資料群、利用者権限を照合できない共有フォルダー、誤りが直ちに生命・身体へ影響する判断、法的結論を無承認で外部送信する用途には適しません。また、月数件しかなく資料を人が即座に確認できる業務では、複雑な組立基盤よりチェックリストの方が安く確実な場合があります。

向かない案件を技術不足と決め付ける必要はありません。権限管理、文書台帳、承認フローが整うまで人の検索と判断を維持する選択も妥当です。AIを使う場合でも、社内参考の下書きだけに限定し、顧客提示や契約判断を対象外にできます。適用範囲はモデル性能ではなく、失敗時の影響と復旧可能性から決めます。

変更・停止・再開の条件を数値と事象で決める

コンテキストは、モデル、検索インデックス、文書、権限、テンプレートのいずれかが変わると結果も変わります。定期日だけで見直すと、規程改定直後の差分を見逃します。NIST AI 600-1は生成AIの設計・利用・評価を通じたリスク管理を扱う任意利用の公的枠組みであり、本稿ではその考え方を変更申請、即時停止、影響確認へ具体化します^[4]。停止後は直前版へ戻すだけでなく、誤った回答が利用された範囲を確認します。

停止判断を担当者の感覚だけにしないため、システムにはkill_switch、active_template_version、blocked_task_typesを持たせます。権限違反が一件でも出た場合は全体停止、形式崩れだけなら対象業務の限定停止というように範囲を選べる構成が必要です。停止中の依頼は失わず、人手キューへ移し、復旧後に勝手な再実行をしません。

再開承認には、原因、修正箇所、影響期間、影響件数、評価結果、残る制約を記録します。モデルを変えて偶然直っただけでは原因解消と見なしません。同じ失敗入力で旧版が不合格、修正版が合格になることを確認し、別の評価群を悪化させていないか固定集合全体で比較します。

自社に必要かを12点で判定する

最後に、技術導入の可否ではなく、個別業務で情報組立を仕組み化する価値を判定します。計算式は「六つの問いの得点合計」で、各項目を0点、1点、2点で採点します。合計8点以上なら小規模検証、4〜7点なら文書・権限整備を優先、3点以下なら現行手順の改善を先に行う、という使い方です。この区分は編集部の提案であり、組織のリスク許容度に合わせて承認者が確定します。

得点が高くても、権限照合と正本管理ができなければ開始条件を満たしません。逆に得点が低い業務へ大規模な検索・履歴基盤を導入すると、保守費が効果を上回ります。最初の対象は、参照元が複数あり、誤選択を人が検知でき、失敗時に外部送信前で止められる一業務が適しています。

次に取る行動

実案件一件について入力条件票を埋め、採用候補と除外理由を人手で記録してください。その記録を正解例として、通常・版競合・入力欠落・権限境界を各一件ずつ作れば、最小の評価を開始できます。四件で停止動作まで確認できた後に、48件の固定集合へ広げます。

四件の確認では、業務担当者が正しい根拠資料と回答基準を指定し、文書管理者が版と発効日を照合し、AI運用担当者が最終コンテキストの採否記録を保存します。正常例で回答できるだけでなく、旧版を選ばない、権限外候補を取得しない、不足入力を推測で埋めない、という三つの停止動作を個別に確認してください。

最初の成果物は、入力条件票、候補文書一覧、採否理由、期待出力、実際出力、実行IDをまとめた一案件分の組立記録です。どの情報が必要だったかを関係者が説明できなければ、自動検索の実装へ進みません。合意できた項目だけをテンプレート台帳へ移し、未決事項には担当者と回答期限を付けます。

参考文献・出典

1. Anthropic Applied AI Team「Effective context engineering for AI agents」（コンテキストエンジニアリングの定義とAIエージェント向け情報選択を扱う公式技術記事、公開日：2025年9月29日、参照日：2026年7月30日）
2. OpenAI「Compaction」（長い対話におけるLLMの文脈管理と圧縮後の状態引継ぎを説明する公式ドキュメント、版・更新日表記なし、参照日：2026年7月30日）
3. OpenAI「Prompting」（AIコンテキスト設計の一部となるプロンプト部品、代表データ、評価、公開管理を説明する公式ドキュメント、再利用可能プロンプトの非推奨化開始日：2026年6月3日、参照日：2026年7月30日）
4. National Institute of Standards and Technology「Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile」（コンテキスト設計の評価・停止・変更管理へ反映した公的文書NIST AI 600-1、公開日：2024年7月26日、掲載ページ更新日：2026年4月8日、参照日：2026年7月30日）