はじめに
こんにちは！iOSエンジニアをしている高橋です！
生成AIの活用では、これまで「プロンプトエンジニアリング」が注目されてきました。AIに対して曖昧さの少ない指示をどのように書くか、どのような役割を与えるか、出力形式をどう指定するか。こうした工夫は、現在でも重要です。
しかし、AIが単発の文章生成を超え、社内文書を検索したり、外部ツールを呼び出したり、複数の手順をまたいで業務を進めたりするようになると、プロンプトだけでは解決できない課題が見えてきます。
たとえば、顧客からの問い合わせに回答するAIを考えてみます。適切な回答を行うには、顧客の契約状況、利用履歴、最新版の料金表、返金ポリシー、過去の対応履歴など、さまざまな情報が必要になります。ここで重要なのは、情報をできるだけ多く与えることではありません。その時点のタスクに必要な情報だけを、信頼できる形で、適切な優先順位で渡すことです。
こうした「AIが判断するための情報環境」を設計する考え方が、コンテキストエンジニアリングです。コンテキストには、システム指示だけでなく、会話履歴、検索によって取得した文書、ツールの仕様や実行結果、メモリなども含まれます。(anthropic.com)
AIエージェントの品質は、モデルそのものの性能だけで決まるわけではありません。AIに何を見せ、何を見せないのか。どの情報をいつ取得し、どのように整理・更新するのか。こうした設計が、回答の正確性や再現性、コスト、ユーザー体験を大きく左右します。
本記事では、コンテキストエンジニアリングの基本的な考え方と、プロンプトエンジニアリングとの違い、実務で押さえるべき設計のポイントについて解説します。
なぜ“良いプロンプト”だけでは足りないのか
単発の質問と、長時間・複数手順で動くエージェントの違い
単発の質問に答える生成AIでは、比較的シンプルなやり取りで目的を達成できます。たとえば、「この文章を要約してください」「メールの文面を作成してください」「PythonでCSVを読み込むコードを書いてください」といった依頼です。この場合、AIに必要なのは、ユーザーの指示と、必要に応じて添えられた入力文や条件です。
もちろん、指示の明確さや出力形式の指定は重要です。しかし、扱う情報の範囲は限られており、AIが判断すべきことも比較的少なくなります。適切なプロンプトを用意することで、一定の品質を得やすい場面だと言えます。
一方、AIエージェントは、単に一度回答を返すだけではありません。目標を受け取ったあとに、必要な情報を探し、外部ツールを使い、結果を確認し、次の行動を判断します。場合によっては、処理が数十ステップにわたり、途中で方針を修正することもあります。
たとえば、「来週の営業会議に向けて、担当顧客の状況をまとめてください」という指示を受けたAIエージェントを考えてみます。このタスクを実行するには、顧客管理システムから担当顧客を取得し、商談履歴や問い合わせ履歴を確認し、直近の利用状況や契約更新日を調べ、必要に応じて社内ドキュメントから提案資料や注意事項を参照する必要があります。そのうえで、情報を整理し、会議用の報告書としてまとめなければなりません。
このようなタスクでは、最初に渡すプロンプトが優れているだけでは不十分です。エージェントは処理の途中で、どの情報を参照すべきか、どの情報が古いのか、次にどのツールを使うべきかを判断する必要があります。また、過去の作業内容や途中で得られた重要な事実を保持しながら、不要になった情報は整理しなければなりません。
ここで課題になるのが、コンテキストの量と質です。情報が少なすぎれば、AIは必要な前提を欠いたまま判断してしまいます。反対に、関係のない情報や古い情報まで大量に渡せば、重要な情報を見落としたり、誤った内容を根拠にしたりするおそれがあります。
つまり、単発の質問では「どのように指示を書くか」が中心になりますが、長時間・複数手順で動くエージェントでは、「各時点で何の情報を渡すか」「どの情報を残し、どの情報を要約・削除するか」「情報の信頼性や鮮度をどう管理するか」が重要になります。これが、プロンプトエンジニアリングだけではなく、コンテキストエンジニアリングが求められる理由です。
情報を詰め込むほど精度が上がるわけではない
AIの回答精度を高めようとすると、「できるだけ多くの情報を渡せばよい」と考えがちです。たとえば、関連しそうな社内文書をすべて添付したり、過去の会話履歴を削除せずに残し続けたり、検索結果をそのまま大量に入力したりする方法です。
しかし、情報量を増やすことと、回答品質を高めることは同じではありません。
AIに渡される情報が多すぎると、本当に重要な内容が埋もれてしまうことがあります。たとえば、最新の料金表を確認したいにもかかわらず、過去数年分の料金表や廃止済みのキャンペーン資料まで混在していれば、AIが古い情報を参照する可能性が高まります。情報が存在していても、それが適切な形で見つけられなければ、正しい判断にはつながりません。
また、長い会話履歴にも注意が必要です。過去のやり取りには、すでに解決した話題や、途中で変更された方針、誤った仮説などが含まれている場合があります。これらを無制限に残しておくと、AIが現在の目的とは関係のない情報に引きずられたり、古い決定を現在も有効なものとして扱ったりするおそれがあります。
さらに、情報量が増えるほど、処理にかかるコストや応答時間も大きくなります。多くの情報を毎回読み込ませる設計は、回答が遅くなるだけでなく、運用コストの増加にもつながります。特に複数回の検索やツール利用を繰り返すエージェントでは、この差が積み重なります。
重要なのは、情報を「多く渡す」ことではなく、現在のタスクに必要な情報を選び、信頼できる形で渡すことです。たとえば、検索対象を担当顧客や最新の文書に絞る、古い会話履歴は要点だけを要約して保持する、ツールの実行結果は必要な項目だけを構造化して返す、といった工夫が考えられます。
コンテキストエンジニアリングでは、情報を追加することだけでなく、不要な情報を除外することも重要な仕事になります。AIにとって良いコンテキストとは、情報量が最大のコンテキストではありません。目的に対して、関連性・鮮度・信頼性が高い情報で構成されたコンテキストです。
コンテキストエンジニアリングとは
モデルに渡す情報全体を設計・選別・更新する営み
コンテキストエンジニアリングとは、一言でいえば、AIモデルが判断や行動を行う際に渡される情報全体を設計し、必要に応じて選別・更新する営みです。
ここでいう「コンテキスト」は、ユーザーが入力した質問文だけを指すものではありません。AIの振る舞いを定めるシステム指示、これまでの会話履歴、社内文書やWeb検索から取得した情報、外部ツールの実行結果、ユーザーや案件に関する記憶、現在の作業状況なども含まれます。
たとえば、社内ナレッジを参照して回答するチャットボットの場合、AIに渡す情報として次のようなものが考えられます。
- 回答時のルールや禁止事項を定めたシステム指示
- ユーザーからの現在の質問
- 過去の会話から引き継ぐべき前提条件
- 検索によって取得した関連文書
- 文書の更新日時や情報源
- 回答に利用したツールの実行結果
重要なのは、これらを毎回すべて同じように渡すことではありません。現在の質問に関係する情報は何か、古くなっている情報はないか、信頼できる情報源か、すでに会話の中で確定した内容はあるか、といった点を判断しながら、コンテキストを組み立てる必要があります。
また、コンテキストは一度作れば終わりではありません。AIエージェントが処理を進めるたびに、新しい情報が得られます。検索結果によって前提が変わることもあれば、ツールの実行結果から次に確認すべき事項が見つかることもあります。そのため、不要になった情報を整理し、重要な決定事項を記録し、新しい事実を反映するという更新の仕組みが求められます。
この考え方は、人間が仕事を進める場面にも似ています。会議に参加する際、関係資料をすべて持ち込むのではなく、議題に必要な資料を選び、最新版を確認し、過去の経緯は要点をまとめて共有します。コンテキストエンジニアリングは、AIに対しても同じように、判断に必要な情報環境を整えるための設計だと言えます。
プロンプトエンジニアリングとの違い
コンテキストエンジニアリングとプロンプトエンジニアリングは、似た言葉として扱われることがあります。しかし、両者は対象とする範囲が異なります。
プロンプトエンジニアリングは、AIに対する指示文そのものを設計することです。たとえば、「あなたはカスタマーサポート担当です」「以下の文書だけを根拠に回答してください」「結論を先に述べ、箇条書きで出力してください」といった指示を工夫します。役割を与える、制約を明確にする、出力形式を指定する、具体例を示すといった手法は、プロンプトエンジニアリングの代表例です。
一方、コンテキストエンジニアリングは、指示文を含めたAIに渡す情報全体を設計することです。現在のユーザー入力だけでなく、会話履歴、参照文書、検索結果、ツールの実行結果、ユーザー情報、作業の進捗などを、どのように取得し、選び、整理し、更新するかを扱います。
たとえば、ユーザーから「この顧客に提案すべきプランを教えてください」と質問された場合を考えてみます。
プロンプトエンジニアリングでは、AIに対して「顧客の利用状況と契約条件をもとに、提案理由を3点挙げてください」と指示することが中心になります。
一方、コンテキストエンジニアリングでは、その前段階として「どの顧客データを参照するか」「利用状況はいつ時点の情報を使うか」「最新の料金表はどこから取得するか」「過去の提案履歴を含めるべきか」「閲覧権限のない情報を除外できているか」といった点まで設計します。
つまり、プロンプトエンジニアリングは「AIに何をしてほしいかを、どのように伝えるか」に重点を置く考え方です。コンテキストエンジニアリングは、「AIが適切に判断するために、何を見せるか」を設計する考え方です。
もちろん、両者は対立するものではありません。どれほど適切な情報を集めても、指示が曖昧であればAIの出力は安定しません。反対に、どれほど優れた指示を書いても、AIに渡される情報が不足していたり、古かったり、誤っていたりすれば、正しい回答にはつながりません。
AIを実務で活用するためには、良いプロンプトを設計することに加えて、そのプロンプトが参照する情報環境そのものを設計する必要があります。コンテキストエンジニアリングは、プロンプトエンジニアリングを置き換えるものではなく、より大きな視点から支える考え方だと言えるでしょう。 (anthropic.com)
コンテキストを構成する5要素
コンテキストは、ユーザーの質問だけで構成されるものではありません。AIが適切に判断するためには、主に次の5つの要素を組み合わせる必要があります。
-
システム指示
AIの役割、守るべきルール、回答の形式、禁止事項などを定めます。AIの基本的な振る舞いを決める土台です。 -
ユーザー入力と会話履歴
現在の質問だけでなく、過去のやり取りから引き継ぐべき条件や決定事項も含まれます。ただし、履歴をそのまま残し続けるのではなく、必要に応じて要約・整理することが重要です。 -
外部知識
社内文書、データベース、Web検索結果など、AIがもともと持っていない情報です。RAG（検索拡張生成）は、必要な知識を必要なタイミングで取得する代表的な方法です。 -
ツール定義と実行結果
検索、データ取得、メール送信、ファイル作成など、AIが利用できる機能の説明と、その実行結果です。ツールの返却内容は、必要な情報に絞って構造化すると扱いやすくなります。 -
メモリと作業状態
ユーザーの好み、案件の前提、途中までの作業内容、未解決の課題などを保持します。長いタスクでは、次に何をすべきかを示す作業状態も重要になります。
これらを目的に応じて適切に組み合わせ、不要な情報を減らしていくことが、コンテキストエンジニアリングの基本です。
代表的な実践パターン
コンテキストエンジニアリングでは、必要な情報を適切なタイミングで渡し、不要な情報を増やさないことが重要です。代表的な実践パターンを紹介します。
-
必要なときだけ検索する
すべての関連資料をあらかじめ渡すのではなく、質問や作業内容に応じて必要な情報を検索します。たとえば、料金に関する質問には最新の料金表だけを取得し、技術的な質問には該当する仕様書を参照する、といった設計です。 -
会話履歴を要約する
長い会話をそのまま保持すると、重要な情報が埋もれやすくなります。決定事項、ユーザーの要望、未解決の課題、次に行うべき作業などを短く要約し、必要な前提だけを引き継ぎます。 -
タスクごとにコンテキストを分離する
複数の案件や作業を同時に扱う場合は、情報を混在させないことが重要です。顧客ごと、プロジェクトごと、サブタスクごとにコンテキストを分けることで、別の案件の情報を誤って参照するリスクを減らせます。 -
情報源と更新日時を持たせる
AIに渡す文書やデータには、情報源、更新日時、有効期限などのメタデータを付けます。これにより、古い情報と最新情報が混在した場合でも、AIや利用者が判断しやすくなります。 -
ツールの返却値を小さく、構造化する
ツールの実行結果をそのまま大量に渡すのではなく、必要な項目だけを抽出します。たとえば、顧客情報を取得する場合は、氏名、契約プラン、更新日、直近の問い合わせ内容などをJSON形式のような構造化データで返すと、AIが扱いやすくなります。
これらに共通するのは、AIに渡す情報を増やすことではなく、判断に必要な情報を整理して渡すという考え方です。
失敗例
コンテキストエンジニアリングでは、情報を渡せば渡すほどAIの回答が良くなるとは限りません。設計を誤ると、回答精度の低下やコスト増加、情報漏えいにつながることがあります。
-
関連文書をすべて渡してしまう
「念のため」として大量の資料を毎回渡すと、重要な情報が埋もれます。古い資料や関係のない資料まで含まれると、AIが誤った内容を根拠に回答するおそれもあります。 -
会話履歴を無制限に残す
過去の会話には、すでに解決した話題や変更済みの方針、誤った仮説が含まれていることがあります。履歴をそのまま蓄積すると、現在の目的と関係のない情報に引きずられやすくなります。 -
検索結果をそのまま回答に使う
検索で見つかった情報が、必ずしも正確・最新・信頼できるとは限りません。情報源、更新日時、質問との関連性を確認せずに使うと、もっともらしい誤回答につながります。 -
異なる案件や権限の情報を混在させる
複数顧客や複数プロジェクトの情報を同じコンテキストで扱うと、別案件の内容を誤って参照する危険があります。情報の分離は、精度だけでなくセキュリティの観点でも重要です。 -
ツールの出力をそのまま大量に渡す
データベース検索やAPIの結果を加工せずに渡すと、ノイズが増え、必要な項目を見つけにくくなります。ツール側で必要な項目に絞り、構造化して返す設計が必要です。
失敗を防ぐためには、「何を追加するか」だけでなく、「何を渡さないか」も意識する必要があります。コンテキストは情報の保管場所ではなく、AIがその場で適切に判断するための作業環境です。
評価方法
コンテキストエンジニアリングでは、AIの回答が正しいかどうかだけでなく、どのような情報をもとに、どれだけ安定して回答できたかを評価する必要があります。
まず確認したいのは、回答の正確性です。質問に対して正しい内容を返せているか、必要な条件を満たしているかを確認します。ただし、正しい回答が偶然得られた可能性もあるため、似た条件の質問を複数用意し、再現性も見ることが重要です。
次に、根拠性を評価します。AIが回答の根拠として、適切な文書や最新のデータを参照できているかを確認します。特に社内文書やRAGを利用する場合は、「正しい文書を取得できたか」と「取得した文書を正しく使えたか」を分けて評価すると、問題の原因を特定しやすくなります。
また、コストと応答時間も重要な指標です。大量の文書や長い会話履歴を毎回渡す設計は、精度が上がらないまま処理時間や利用コストだけが増える場合があります。タスクの重要度に見合った情報量になっているかを確認する必要があります。
さらに、安全性も欠かせません。権限のない情報を参照していないか、別の顧客や案件の情報が混ざっていないか、古い情報を最新情報として扱っていないかをテストします。
評価では、実際に起こりうる質問や業務シナリオをあらかじめ用意し、期待する回答と参照すべき情報源を定義しておくと効果的です。回答結果だけを見るのではなく、「どの情報が渡され、どのツールが呼び出され、どの時点で判断を誤ったのか」まで記録・分析することで、コンテキストの設計を継続的に改善できます。
まとめ
コンテキストエンジニアリングは、AIに対して良い指示を書くためだけの技術ではありません。AIが適切に判断し、複数の手順にわたって安定して作業するために、必要な情報環境を設計する考え方です。
重要なのは、情報をできるだけ多く渡すことではありません。現在のタスクに関係する情報を選び、信頼性や鮮度を確認し、不要になった情報を整理しながら渡すことが求められます。
特にAIエージェントでは、システム指示、会話履歴、外部知識、ツールの実行結果、メモリや作業状態など、さまざまな情報が判断に影響します。これらを適切に管理できなければ、優れたモデルやプロンプトを用意しても、期待どおりの結果を得ることは難しくなります。
プロンプトエンジニアリングが「AIに何をしてほしいかを伝える技術」だとすれば、コンテキストエンジニアリングは「AIが適切に判断するために何を見せるかを設計する技術」だと言えます。両者を組み合わせることで、AIはより正確に、より安全に、より実務に役立つ形で活用できるようになります。
生成AIを業務へ本格的に組み込むうえで、モデル選びやプロンプトの工夫だけでは不十分です。AIに渡す情報をどう取得し、どう整理し、どう更新するか。これからのAI活用では、その設計力がますます重要になるでしょう。