コンテキストエンジニアリングとは｜プロンプトエンジニアリングとの違いと実務での設計対象

LLMアプリケーションで回答品質が安定しないとき、原因は「プロンプトの書き方」とは限りません。必要な規程を検索できていない、過去の会話を持ち込みすぎている、ツールの実行結果が長すぎる、ユーザーの権限情報が欠けている、といった問題でも出力は崩れます。

コンテキストエンジニアリングとは、LLMが推論・生成時に参照する情報全体を、目的に合わせて選択・構成・更新する設計です。ここでいうコンテキストは、システム指示、ユーザー入力、会話履歴、検索結果、ツール定義、ツール実行結果など、モデルへ渡すトークンの集合を指します。Anthropicは、コンテキストエンジニアリングを、限られたコンテキストウィンドウへ入れる情報を選び、維持するための戦略として説明しています。Anthropic: Effective context engineering for AI agents

先に結論を述べると、プロンプトエンジニアリングはコンテキストエンジニアリングに含まれる設計対象です。単発の文章生成では指示文の改善が中心になりやすい一方、RAGやAIエージェントのように検索・ツール利用・複数ターンの処理を含む場合は、「何を、いつ、どの形で渡し、何を捨てるか」まで設計対象になります。

コンテキストエンジニアリングの意味

「コンテキストエンジニアリング」という言葉の使い方は資料や製品ごとに異なりえます。本記事では、LLMに望ましい振る舞いをさせるため、推論時に利用可能な情報の構成を継続的に設計する活動として扱います。

重要なのは、コンテキストを「たくさん入れること」ではありません。Anthropicは、コンテキストを有限の資源として扱い、目的達成に必要な高シグナルの情報をできるだけ小さく保つ考え方を示しています。長いコンテキストでは、情報の想起や長距離の推論精度が下がる可能性があるためです。Anthropicの解説

たとえば、社内規程への質問に答えるRAGでは、規程の全文、すべての過去会話、全ツールの結果を毎回そのまま渡す必要はありません。質問に関係する現行規程の箇所、質問者の参照権限、回答形式、必要なら直近の会話上の決定事項を選びます。この選定と更新の仕組みが、コンテキストエンジニアリングの中心です。

プロンプトエンジニアリングとの違い

両者は代替関係ではありません。明確な指示や出力スキーマは必要です。ただし、業務アプリで「回答が的外れ」という症状だけを見てプロンプトを何度も書き換えると、検索・データ整備・ツール連携・履歴管理の問題を見逃すことがあります。

Prompt・Context・Harness・Loop・Graphの関係

LLMアプリの設計対象を漏れなく確認するため、本記事では次の5つをMojiによる実務上の整理として使います。これらは排他的な技術分類ではなく、同じ不具合をどこから診断するかを分けるためのレイヤーです。特にHarness EngineeringとGraph Engineeringは、個別の論文や製品資料に一律の定義を帰属させるものではありません。

Harnessは、モデルの前後にある実行・運用の土台を指すための呼び方です。たとえば、同じプロンプトと検索結果でも、ツールの認証範囲、ログの有無、構造化出力の検証、障害時の処理が異なれば、業務システムとしての振る舞いは変わります。

Loopは、LLMがツールを使いながら複数ステップを進める際の反復制御です。OpenAIのガイドでも、単一エージェントの実行は終了条件に達するまでのループとして説明され、終了条件にはツール呼び出し、構造化された最終出力、エラー、最大ターン数などが挙げられています。OpenAI: A practical guide to building agents

Graphは、分岐や承認を含む処理経路を明示的に設計する対象です。定型の申請処理のように、手順と責任分界を固定したい場合はGraphを先に設計します。一方で、質問ごとに調査対象や探索順が変わる場合は、すべてを固定グラフにせず、必要な範囲だけをLoopとしてモデルに委ねる選択肢があります。Anthropicも、あらかじめ定義したコード経路でLLMとツールを組み合わせる「ワークフロー」と、LLMがツール利用や進め方を動的に決める「エージェント」を区別しています。Anthropic: Building effective AI agents

設計対象になる6種類のコンテキスト

1. 固定指示
   役割、対象業務、禁止事項、出力形式、判断基準です。頻繁に変わらない情報を簡潔に管理します。
2. ユーザー入力とユーザー属性
   依頼内容のほか、部署、契約プラン、言語、閲覧権限などです。回答に必要な属性だけを使い、不要な個人情報を漫然と投入しない設計を検討します。
3. 会話履歴・作業状態
   過去の決定、未解決事項、現在のタスク、すでに実行した操作を保持します。長い履歴をそのまま渡すのではなく、直近の原文と確定事項の要約を分ける方法があります。OpenAIのAgents SDK向け資料には、直近Nターンを保持するセッション実装例が示されています。OpenAI: Context Engineering - Short-Term Memory Management with Sessions
4. 検索結果・参照文書
   社内規程、製品仕様、FAQ、チケットなど、回答の根拠になる情報です。RAGは、事前学習済みの生成モデルと、検索でアクセスする外部メモリを組み合わせる枠組みとして提案されました。RAG原論文: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
5. ツール定義とツール実行結果
   利用可能なAPI、引数、実行条件、取得データです。OpenAIはエージェント向けのツールを、情報を取得するデータ用、外部システムへ働きかけるアクション用、他エージェントをツールとして扱うオーケストレーション用に整理しています。OpenAIのエージェント構築ガイド
6. 信頼性・権限・安全上のメタデータ
   情報源の更新日時、文書の版、参照権限、外部入力か内部承認済みか、といった判断材料です。外部ページやメール本文などの非信頼入力は、上位指示ではなく参照データとして扱う設計を検討します。

実務例：社内問い合わせRAGで何を設計するか

架空の例：人事規程を回答する社内アシスタントを考えます。ユーザーが「在宅勤務の申請期限は？」と質問したとき、必要なのは「親切に答える」ためのプロンプトだけではありません。

• 質問者が参照可能な規程だけを検索対象にする
• 現行版の規程を優先し、旧版・廃止済み文書を除外する
• 検索上位文書から、期限・対象者・例外条件が同居する箇所を渡す
• 根拠が不足する場合は推測せず、担当窓口または原文確認へ誘導する
• 回答に、参照した文書名・版・リンクを付ける

この例で「申請期限を誤る」場合、直すべき場所はプロンプトとは限りません。検索対象の版管理、チャンク分割、メタデータフィルター、検索ランキング、最終的にLLMへ渡す抜粋範囲を順に確認します。RAGの仕組みと導入・評価の全体像は、RAG（検索拡張生成）とは？向く業務・他方式との違い・導入から評価までの実践ガイドも参照してください。

質問が「障害に関係した変更、その承認者、影響したサービスを整理して」のように、複数の対象と関係をたどる必要がある場合は、検索対象の関係構造も設計対象になります。知識グラフを検索・文脈構成に利用する選択肢は、Graph RAGとは？従来RAGとの違い・向く質問・設計上の注意点で解説しています。

出力不良を切り分ける判断表

以下はMojiによる実務上の診断の目安です。モデル、入力品質、評価指標、許容誤差によって結論は変わるため、一般的な設計上の出発点として使ってください。

ツールを使って外部システムを操作する場合は、AIエージェントの委任範囲も別途設計してください。特に更新・送信・購入など、外部への影響が大きい操作では、承認と停止条件を先に決める必要があります。AIエージェントはどこまで任せるべきか｜委任範囲・人の承認・停止条件を設計する実務ガイド

導入・改善の手順

1. 期待する出力を判定可能にする
   「よい回答」ではなく、正答、根拠提示、回答不能時の停止、応答時間などを定義します。
2. 失敗ケースを集める
   実運用または検証用の質問を集め、期待回答・根拠文書・許容しない誤りを記録します。
3. モデルに渡る最終入力を可視化する
   システム指示、履歴、検索結果、ツール定義、実行結果を一つの時系列として確認します。アプリの画面で見える回答だけでは、原因を分離できません。
4. 根拠が消えた最初の地点を特定する
   原文にあったのか、抽出できたのか、検索候補にあったのか、最終入力に採用されたのか、回答で利用されたのかを追います。
5. Prompt・Context以外の制御も確認する
   ツール認証、入力検証、ログ、再試行、終了条件、固定分岐、承認のどこに問題があるかを確認します。定型業務はGraph、探索的な処理はLoopを優先して点検します。
6. 一度に一つの仮説を評価する
   例として、チャンクサイズとモデルを同時に変えるのではなく、まず検索対象の版管理だけを変えて比較します。
7. 更新運用を決める
   規程更新、ツール仕様変更、権限変更、失敗事例の追加を、いつ誰が反映・再評価するかを決めます。

評価データの作り方を深掘りしたい場合は、RAG評価データセットの作り方｜設計・作成・品質確認・更新を実務手順で解説を参照してください。

安全に扱うためのチェックリスト

検索結果、メール、添付ファイル、Webページ、MCPサーバーの応答などには、ユーザーの意図と異なる命令が含まれる場合があります。OpenAIは、非信頼テキストやデータがAIの動作を不正に変えようとする攻撃をプロンプトインジェクションとして説明しています。同ガイドでは、非信頼入力を開発者メッセージへ直接入れないこと、構造化出力、ツール承認、評価を組み合わせる対策を案内しています。OpenAI: Safety in building agents

• 外部取得文書を、システム指示や開発者指示と同じ信頼度で扱っていないか
• 検索文書の本文を「実行すべき命令」ではなく「参照データ」として扱える設計か
• ツールへ渡す値を、自由文ではなく検証可能なスキーマに制限しているか
• 操作権限をタスクに必要な最小範囲に絞っているか
• 送信・更新・削除などの重要操作に、人の承認または明確なポリシー判定があるか
• コンテキスト、ツール呼び出し、最終出力を追跡できるログと評価ケースがあるか

すぐ使えるコンテキスト設計シート

以下はMojiによる提案テンプレートです。新しいLLM機能を追加する前に、1機能につき1枚作成すると、プロンプトだけに改善が偏ることを防ぎやすくなります。

各設計領域を詳しく知る

各領域の意味と具体的な設計方法は、次の解説記事で確認できます。

• 自己改善型システムとは：評価結果からプロンプト・知識・コードなどを更新する仕組み。
• ハーネスエンジニアリングとは：ツール、作業空間、記録、検証、復旧を含む実行環境の設計。
• グラフエンジニアリングとは：ノード、分岐、状態、再開点を使った処理経路の設計。
• ループエンジニアリングとは：一つの作業内での反復、再試行、完了・保留・打ち切りの設計。

まとめ

コンテキストエンジニアリングは、プロンプトを巧みに書くための別名ではありません。LLMに渡る指示、履歴、検索結果、ツール、状態、権限を、タスクごとに選び、更新し、安全に接続する設計です。

改善時は、まずプロンプトを変える前に、正しい根拠がどの段階で失われたかを確認してください。根拠が最終入力にないなら検索・データ・コンテキスト構成、根拠があるのに形式が崩れるならPrompt、操作が止まらないならLoop、承認経路が不明確ならGraph、権限・ログ・安全制御に問題があるならHarnessを優先して見直す、という切り分けが実務上の出発点になります。