コンテキストエンジニアリングとは？4つの設計戦略

コンテキストエンジニアリングは、4つの戦略で生成AIの情報環境を整え、実務品質を高める設計手法です。品質は採用するモデルだけでは決まりません。モデルへ何を、いつ、どの順序で渡し、何を渡さないかにも左右されます。

長い指示文や大量の社内文書を入力すれば、回答が必ず改善するわけではありません。古い規程、重複した履歴、権限外の情報が混ざれば、かえって判断を誤る可能性があります。AIエージェントでは、会話の途中で検索結果やツール実行結果が増えるため、情報管理はさらに重要です。

本記事では、コンテキストエンジニアリングの定義を整理したうえで、プロンプトエンジニアリング、RAG、MCPとの違いを解説します。さらに、4つの基本戦略、企業での活用例、7段階の導入手順、評価指標、安全対策までを紹介します。

コンテキストエンジニアリングとは

コンテキストエンジニアリングとは、LLMが推論するときに必要な情報を収集・選択・構成し、適切な状態で維持するための設計手法です。単に入力文を工夫するのではなく、AIを取り巻く情報の流れ全体を対象にします。

Anthropicは公式記事「Effective context engineering for AI agents」で、コンテキストエンジニアリングを、推論時に最適なトークン集合をキュレーションし、維持する戦略として説明しています。

ここでいうコンテキストは、AIが回答や行動を決める際に参照できる情報の総体です。長い文章を作ること自体が目的ではありません。業務目的に関係する情報を、モデルが利用しやすく、かつ安全な形に整えることが目的です。

コンテキストを構成する8つの要素

企業向けシステムで設計対象となる情報は、次の8要素に整理できます。

要素	内容	設計上の論点
システム指示	AIの役割、禁止事項、出力形式	優先順位と変更管理
ユーザー入力	質問、依頼、添付内容	曖昧さ、機密情報、悪意ある命令
会話履歴	過去の質問と回答	保持期間、要約、誤情報の残存
外部データ	規程、製品資料、顧客が利用を許可した情報	鮮度、出所、閲覧権限
短期状態	現在のタスク、途中結果、未完了項目	セッション終了条件
長期メモリ	継続利用する設定や確定事項	保存根拠、更新・削除方法
ツール	検索、データベース、業務APIなど	実行権限、引数、失敗時の処理
実行時情報	時刻、利用者の役割、処理環境	信頼できる取得元、適用範囲

LangChainの公式ドキュメントも、メッセージだけでなく、エージェントの状態、長期保存情報、ツール、実行時コンテキストを設計対象として示しています。

8要素を常にすべて渡す必要はありません。たとえば社内規程への質問なら、利用者が閲覧できる最新版の規程と、回答形式の指示が中心です。一方、申請を実行するエージェントでは、申請者の権限、入力値、承認状態、ツールの実行条件まで必要になります。

AIエージェントで重要性が高まる理由

通常のチャットは、利用者の質問に文章で回答する形が中心です。AIエージェントは、目的に応じて情報を検索し、ツールを呼び出し、その結果を踏まえて次の処理を選ぶ場合があります。処理が続くほど、履歴、検索結果、途中の判断が蓄積します。

Anthropicは「Building effective agents」で、あらかじめ定義したコード経路でLLMとツールを動かすworkflowと、LLMが処理を動的に制御するagentを区別しています。OpenAIも「A practical guide to building AI agents」で、エージェントの基本要素をモデル、ツール、指示として整理しています。

動的に行動する仕組みでは、関連性の低いツールや古い途中結果も判断材料になり得ます。そのため、次の管理が必要です。

• 現在の目的と完了条件を保持する
• 実行できるツールを利用者の権限に応じて限定する
• 検索結果の出所と更新日を確認する
• 途中結果を要約し、不要な詳細を捨てる
• 重要な操作の前に人間の承認を求める
• エラーや矛盾が生じたときに停止する

エージェント化は必須ではありません。定型処理なら、処理経路を固定したワークフローのほうが評価しやすく、統制もしやすい場合があります。目的に対して最小限の構成から始めることが重要です。

プロンプト、RAG、MCPとの違い

コンテキストエンジニアリングは、プロンプト、RAG、MCPの上位概念として捉えると理解しやすくなります。それぞれは競合する手法ではなく、異なる層を担当します。

用語	主な役割	主な設計対象	コンテキスト設計との関係
プロンプトエンジニアリング	指示の伝え方を改善する	役割、制約、例、出力形式	コンテキストの一部を設計する
RAG	外部情報を検索して入力へ加える	文書、分割、索引、検索、再順位付け	必要情報を選択する実装手段
MCP	AIと外部システムの接続方法を標準化する	resources、prompts、tools	情報や機能を取得する接続層
コンテキストエンジニアリング	推論に使う情報環境全体を最適化する	指示、履歴、データ、状態、ツール、権限	各技術を目的に応じて組み合わせる

プロンプトはコンテキストの一部

プロンプトエンジニアリングは、AIへ与える指示の表現や構造を改善する手法です。目的、制約、参考例、出力形式を明確にすることで、期待する回答を得やすくします。

一方、コンテキストエンジニアリングは、その指示に加えて、どの履歴を残すか、どの文書を検索するか、どのツールを許可するかまで扱います。優れたプロンプトがあっても、参照データが古ければ正しい業務回答にはつながりません。

指示設計の基本は「プロンプトエンジニアリングの解説」で詳しく紹介しています。

RAGは必要情報を選ぶ実装手段

RAGは、質問に関連する外部情報を検索し、その結果をLLMへ渡して回答を生成する構成です。OpenAIのFile Search公式ガイドでは、ベクトルストアからセマンティック検索とキーワード検索を行う仕組みが説明されています。

RAGは、コンテキストを「選択する」有力な手段ですが、導入するだけで十分ではありません。検索対象の文書が古い、文書の分割が不適切、利用者の権限を検索条件へ反映していない、といった問題があれば、適切な情報は渡せません。取得件数、引用、更新、アクセス制御も含めて設計する必要があります。

実装時の論点は「RAGとは何か」もあわせてご覧ください。

MCPは外部接続の標準規格

MCP（Model Context Protocol）は、LLMアプリケーションと外部のデータやツールを接続するためのオープンな標準規格です。MCP公式仕様は、host、client、serverの構成と、resources、prompts、toolsなどを定義しています。

MCPは接続方法を共通化しますが、取得した情報が質問に必要か、信頼できるか、どこまで保持するかまでは自動で判断しません。つまり、MCPが「つなぐ仕組み」なら、コンテキストエンジニアリングは「何を、どの条件で使うかを設計する取り組み」です。

詳細は「MCP（Model Context Protocol）の解説」をご覧ください。

情報を増やすだけでは精度が上がらない

コンテキスト設計で起こりやすい誤解は、入力できる範囲まで情報を追加すれば、回答が改善するという考え方です。実際には、量よりも関連性、鮮度、信頼性、配置が重要です。

コンテキストウィンドウは有限

コンテキストウィンドウは、モデルが一度の推論で扱える入力と出力の範囲です。上限内であっても、すべての情報が同じ精度で利用されるとは限りません。また、履歴が長くなれば、必要な指示や根拠が相対的に見つけにくくなります。

モデルごとの上限だけを比較するのではなく、対象業務で必要な情報が安定して選ばれているかを確認すべきです。LLMの基礎とコンテキストウィンドウについては「LLMの解説」でも紹介しています。

context rotとLost in the Middle

Anthropicは、コンテキストが長くなるにつれて情報を正確に想起する能力が低下する現象を「context rot」として説明しています。重要な情報と無関係な情報が同じ入力に混ざると、モデルが判断に必要な部分へ注意を向けにくくなります。

一次研究「Lost in the Middle」は、長い入力の中央に配置された関連情報を利用する性能が低下する傾向を報告しました。入力欄に収まることと、モデルが情報を有効利用できることは同じではありません。

対策は、重要情報を単純に先頭へ置くだけではありません。現在の質問に不要な履歴を除き、検索結果を絞り、重要事項を構造化して提示します。そのうえで、情報の位置を変えた評価も行います。

古い情報と矛盾が品質を下げる

社内規程の旧版と新版、未承認の草案と正式文書が同時に渡されると、AIはどちらを優先すべきか判断できない場合があります。会話履歴に残った利用者の訂正前の発言も、後の回答へ影響し得ます。

情報源には、少なくとも次の属性を持たせます。

• 文書名と管理責任者
• 公開・承認の状態
• 発効日または更新日
• 適用対象と失効条件
• 情報の出所
• 閲覧できる役割

矛盾を検出した場合は、モデルに推測で統合させず、優先規則に従うか、人間へ確認を戻します。正解が一つに決まらない業務では、不確実性と参照元を回答に表示する設計が有効です。

コンテキストエンジニアリングの4つの基本戦略

LangChainは公式ブログ「Context Engineering for Agents」で、戦略をWrite、Select、Compress、Isolateの4つに整理しています。実務では一つを選ぶのではなく、業務の流れに沿って組み合わせます。

戦略	目的	代表的な方法	確認事項
記録する	後で必要な情報を残す	状態、メモ、構造化ログ	保存根拠と更新・削除条件
選択する	今必要な情報だけを取り出す	RAG、フィルター、ツール選択	関連性、鮮度、権限
圧縮する	意味を保ちながら量を減らす	要約、重複除去、構造化	重要事項が欠落していないか
分離する	情報や処理の干渉を抑える	サブタスク、権限境界、サブエージェント	受け渡す情報と責任範囲

記録する（Write）

記録は、処理中に得た情報を、後の推論で利用できる形へ残す戦略です。会話全文を保存することではありません。タスクの目的、確定事項、未解決事項、根拠、次の行動などを構造化して記録します。

たとえば商談準備では、「顧客の課題」「確認済みの要件」「未確認事項」を別項目として保持します。推測を確定事項として保存しないことが重要です。長期メモリへ保存する場合は、利用目的、保持期間、訂正・削除方法も定めます。

選択する（Select）

選択は、保存された情報や利用可能なツールから、現在の処理に必要なものを取り出す戦略です。RAG、メタデータによる絞り込み、利用者の役割に応じたツール選択などが該当します。

検索の関連度だけでなく、文書の正式性、更新日、適用部門を条件にします。検索結果が見つからない場合は、近い文書で回答を埋めず、「根拠を確認できない」と返す条件も必要です。

圧縮する（Compress）

圧縮は、情報の意味を保ちながら、次の推論へ渡す量を減らす戦略です。長い会話の要約、重複した検索結果の除去、ツール出力から必要項目だけを抽出する処理などがあります。

要約は情報を失う処理でもあります。金額、期日、否定表現、例外条件、承認状態など、業務上重要な項目を保持するルールを設けます。要約前の原文へ戻れる参照情報も残し、評価では原文利用時との差を確認します。

分離する（Isolate）

分離は、異なる情報や処理を別の領域へ分け、相互干渉を抑える戦略です。調査と最終回答を別工程にする、部門ごとのデータを権限で分ける、サブエージェントへ限定的な作業を任せる、といった方法があります。

サブエージェントを増やせば自動的に品質が上がるわけではありません。役割ごとの入力と出力、受け渡す要約、失敗時の責任範囲が曖昧なら、全体を追跡しにくくなります。まず単一のワークフローで検証し、分離の必要性が明確な部分だけを独立させます。

自社業務に必要な情報設計や、小規模な検証の進め方を整理したい方は、NexaのAI顧問サービスをご覧ください。業務選定から評価・運用設計まで支援します。

企業での活用例

コンテキストエンジニアリングは、文章生成だけでなく、社内データや業務ツールを使う場面で役立ちます。以下は特定企業の実績ではなく、公開された技術仕様から考えられる一般的な活用例です。

カスタマーサポート

問い合わせ内容に対して、対象製品、契約条件、最新版のFAQ、過去の対応状況を選択して提示します。別の顧客情報が混ざらない権限制御が前提です。解約や補償など影響の大きい判断は、人間の担当者へ引き継ぎます。

営業支援

商談メモ、公開情報、承認済みの提案資料から、次回の確認事項や提案の下書きを作成します。事実、顧客の発言、AIの推測を分けて記録すると、誤った前提が後の提案へ残るリスクを抑えられます。

社内ナレッジ検索

利用者の所属と権限を確認したうえで、正式版の規程やマニュアルを検索します。回答には参照文書と該当箇所を示し、根拠がない場合は回答を保留します。文書更新時に索引を更新する運用も必要です。

ソフトウェア開発

仕様、対象コード、テスト結果、開発規約をタスク単位で選択します。Claude CodeやCodex CLIのようなコーディング支援ツールを使う場合も、リポジトリ全体を無条件に渡すのではなく、変更対象、実行可能なコマンド、承認が必要な操作を限定することが重要です。

契約・文書業務

契約書の種類、社内基準、過去に承認された条項、確認観点を分けて参照し、論点を整理します。ただし、法的判断や締結をAIだけで完結させるべきではありません。参照元を表示し、担当者や専門家が確認する工程を設けます。

導入を7段階で進める

全社共通の基盤を最初から作るより、範囲を限定した業務で正解条件と評価データを整えるほうが、課題を特定しやすくなります。次の7段階で進めます。

1. 対象業務と正解条件を決める

「問い合わせ回答の下書き」のように、入力、出力、利用者、利用場面を具体化します。正解条件は、正確さだけではありません。必須項目、禁止事項、引用の必要性、担当者へ戻す条件も定義します。

2. 情報源と責任者を整理する

AIが参照してよい文書、システム、入力項目を一覧化します。各情報源に、管理責任者、正式版の場所、更新方法を割り当てます。出所が不明な資料は、評価用の候補に含めても、本番の根拠には使わない判断が必要です。

3. 信頼性、鮮度、権限を設定する

正式文書と参考資料の優先順位、発効日、適用範囲をメタデータとして管理します。利用者が元文書を閲覧できない場合、AI経由でも内容を取得できないようにします。権限確認は回答後ではなく、検索やツール実行の前に行います。

4. 検索、メモリ、ツールを設計する

必要な情報の取得方法を決めます。文書検索にはRAG、処理中の状態には短期メモリ、業務操作にはツールを使うなど、目的ごとに分けます。長期メモリには、継続利用する合理的な理由がある情報だけを保存します。

5. 捨てる条件を決める

コンテキストへ追加する条件と同時に、除外・失効・要約する条件を定めます。終了したタスクの途中結果、重複した検索結果、旧版文書、現在の目的と関係しない会話などが候補です。削除できない監査記録と、モデルへ渡す情報は分けて管理します。

6. オフライン評価と実運用評価を行う

過去に正解が確認できる質問や、想定される失敗例を評価セットにします。情報の有無、位置、文書の新旧、権限の違いを変えてテストします。本番では、回答品質だけでなく、人間による修正、処理失敗、引き継ぎの発生も記録します。

7. ログを基に改善する

入力、取得した文書、ツール呼び出し、出力、承認結果を、目的に必要な範囲で追跡できるようにします。失敗がモデル、検索、データ、指示、権限のどこにあるかを分けて分析し、変更後は同じ評価セットで再確認します。ログ自体の閲覧権限と保持期間も必要です。

評価指標と安全対策

コンテキストエンジニアリングは、最終回答だけを見ても改善箇所を特定できません。品質、検索、運用、リスクの4領域を分けて評価します。

領域	評価指標の例	確認すること
品質	正答、必須項目の充足、根拠との整合、人間の修正	業務上の正解条件を満たすか
検索	関連文書の取得、不要文書の混入、引用の一致、最新版の選択	必要な根拠を選べているか
運用	処理時間、失敗、再試行、担当者への引き継ぎ	安定して運用できるか
リスク	権限違反、機密情報の出力、危険なツール実行、承認漏れ	被害につながる行動を防げるか

数値目標は、業務の重要度と現状の人手プロセスを基準に決めます。他社の値をそのまま使うのではなく、誤りが与える影響を踏まえて許容条件を設定してください。

権限付き検索を前提にする

検索結果を生成後に隠すだけでは不十分です。検索前に利用者のIDや役割を検証し、閲覧可能な情報だけを候補にします。ツールについても、読み取りと更新を分け、必要最小限の権限を付与します。

外部データと指示を分離する

Webページ、メール、添付文書などには、AIへの命令に見える文章が含まれる可能性があります。OWASPの「Prompt Injection」は、利用者が直接入力する攻撃だけでなく、外部コンテンツを介した間接的な攻撃も説明しています。

外部データ内の文章を上位の指示として扱わず、信頼境界を明示します。RAGは関連文書を取得する仕組みであり、プロンプトインジェクションを完全に防ぐ仕組みではありません。

人間承認と停止条件を設ける

送信、公開、削除、契約、決済、権限変更など、取り消しが難しい操作は、人間の承認を挟みます。承認画面には、実行内容、対象、根拠、変更点を表示します。

また、根拠が見つからない、情報が矛盾する、権限を確認できない、ツールが想定外の応答を返した場合は停止させます。OpenAIのエージェント構築ガイドも、複数のガードレールを組み合わせる考え方を示しています。

監査ログと組織的な管理を行う

誰が、どの情報を参照し、何を実行し、誰が承認したかを追跡できるログを残します。ただし、すべての入力を無期限に保存すると、個人情報や機密情報のリスクが増えます。目的、保持期間、閲覧権限、削除方法を定めます。

NISTの「Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile」は、生成AIに関するガバナンス、情報の出所と完全性、セキュリティ、プライバシーを含む組織的なリスク管理を整理しています。技術対策だけでなく、責任者、手順、教育、見直しを一体で設計することが重要です。

よくある質問

Q. コンテキストエンジニアリングとは何ですか？

LLMが推論時に参照する指示、履歴、外部データ、状態、ツールなどを選び、構成し、維持する設計手法です。情報を増やすだけでなく、不要な情報の除外、圧縮、権限管理も含みます。

Q. プロンプトエンジニアリングとの違いは何ですか？

プロンプトエンジニアリングは、主に指示文の書き方や構造を改善します。コンテキストエンジニアリングは、プロンプトを含め、検索データ、会話履歴、メモリ、ツール、実行時情報まで扱います。

Q. RAGを導入すれば十分ですか？

十分とは限りません。RAGは関連情報を検索する手段です。文書の鮮度、検索精度、閲覧権限、取得後の圧縮、引用、根拠がない場合の停止条件などは別途設計する必要があります。

Q. MCPとの関係は何ですか？

MCPは、LLMアプリケーションと外部データ・ツールを接続する標準規格です。接続先から何を取得し、どの権限で、どの情報をモデルへ渡すかを決めるのがコンテキストエンジニアリングです。

Q. ファインチューニングは不要になりますか？

両者は目的が異なるため、不要になるとは限りません。コンテキストエンジニアリングは推論時に渡す情報を整えます。ファインチューニングはモデルの振る舞いや特定形式への適応を調整する手段です。まず指示、検索、評価で課題の原因を特定し、必要性を判断します。

まとめ

コンテキストエンジニアリングとは、生成AIへ情報を大量に渡す技法ではありません。業務目的に必要な情報を、関連性、鮮度、信頼性、権限に基づいて整える取り組みです。

実務では、次の原則が重要です。

• プロンプトだけでなく、履歴、外部データ、状態、ツールまで設計する
• 記録・選択・圧縮・分離の4戦略を組み合わせる
• 最新版と正式版を識別し、権限の範囲内で検索する
• 根拠がない場合や情報が矛盾する場合の停止条件を決める
• 回答、検索、運用、リスクを分けて評価する
• 影響の大きい操作には人間の承認と監査ログを設ける

最初の一歩は、小さな業務を一つ選び、入力、期待する出力、正解条件、参照してよい情報を書き出すことです。その評価セットを使って、情報を足す前に、何を選び、何を捨てるべきかを検証しましょう。

AI活用の業務選定、情報設計、導入後の評価や安全対策まで相談したい方は、NexaのAI顧問サービスをご覧ください。自社の目的と運用体制に合わせた導入を支援します。