RAGだけでは不十分？ AIエージェントの精度を高める「コンテキスト設計」とは

企業で生成AIやAIエージェントの活用が進む中、社内文書を参照するためにRAG（検索拡張生成）を導入する動きが広がっています。しかし、RAGを導入しても、AIが古い規程に基づいて回答するなど、必ずしも業務に適した回答が得られるとは限りません。

こうした問題は、AIモデルの性能を高めたり、参照できる文書を増やしたりするだけでは解決できません。LLM（大規模言語モデル）は、利用者の状況や企業固有の業務情報を自動的に把握しているわけではないためです。

例えば、「今日の天気を教えて」と質問されても、LLMは利用者の所在地や現在の日時を必ずしも把握しているわけではありません。適切に回答するには、所在地や日時、最新の気象情報などを取得し、LLMに渡す必要があります。

閉じる

業務でも同様に、利用者の状況や情報の適用条件、過去のやり取りといった業務の文脈（コンテキスト）をAIに渡すことが重要になります。

本稿では、単純なRAGだけでは補いきれない業務のコンテキストに着目し、AIエージェントが必要な情報を適切に取得・管理・活用するための設計について解説します。

RAGを導入するだけでは企業AIが業務を理解できない理由

例えば、ある顧客から「また接続障害が起きた。今回は補償の対象になるのか」という問い合わせが届いたとします。製品の一般的なFAQを検索すれば、障害時の確認手順や標準的な補償条件は見つかるかもしれません。しかし、それだけではこの顧客に対する回答は決まりません。契約プランや個別の合意、過去の対応履歴、今回の障害の発生状況などを確認する必要があります。

RAGは、外部の情報を検索し、その結果を根拠としてLLMに回答を生成させる手法です。社内固有の知識や更新された情報を参照させるうえで有効ですが、質問に関連する文書を検索して渡すだけで、こうした業務上の前提がすべてそろうわけではありません。

AIが判断に使う情報のまとまりを「コンテキスト」と呼びます。その範囲は、検索で取得した文書にとどまりません。業務上の指示、利用できるツールとその使い方、会話や対応の履歴、現在の作業状態なども含まれます。

つまり、重要なのは「質問に関連する文書を検索できるか」だけではありません。「誰が、どの状況で、何を判断するために使う情報なのか」まで含めて、AIへの入力を設計することが求められます。

AIへの情報の渡しすぎは、回答精度の低下やコスト増につながる

背景情報が足りないなら、関連していると思われる情報をすべて渡せばよいのでしょうか。業務に必要な背景情報をAIに渡すことは重要ですが、情報量を増やせばよいわけではありません。情報量を増やすだけでは別の問題が生まれます。

LLMが一度に扱える情報量には、コンテキストウィンドウという上限があります。また、その範囲に収まる場合でも、入力が長くなれば処理コストや応答時間の負担が増えやすくなります。問い合わせのたびに膨大な資料を読み込む設計では、少数の利用者による検証では問題が見えなくても、処理件数の増加に伴って運用上の制約が表面化します。

また当然ながら、AIに渡す情報が少なすぎる場合だけでなく、多すぎる場合や、無関係・矛盾する情報が含まれる場合にも、回答の品質が低下するおそれがあります。大量の情報を渡すと、モデルがどの情報を重視すべきかを捉えにくくなり、必要な情報を十分に活用できなくなるためです。そのため、コンテキストウィンドウを単に情報で埋めるのではなく、必要な情報を選択し、関連性に応じて絞り込み、優先順位を付けて渡すことが重要になります。

例えば、最新版の製品を使う顧客からの問い合わせに対し、新旧両方のマニュアルを渡した結果、AIが旧仕様の手順を案内してしまうケースです。この場合、必要なのは最新版のマニュアルにある該当手順だけです。情報を多く渡しても、適用すべき情報が埋もれたり、新旧の情報が混同されたりすれば、正しい回答にはつながりません。

コスト面でも、情報量の増加は課題になります。仮に、1件の問い合わせに対して20万トークン（モデルが文章を処理する際の単位）の情報を渡す場合、1日1,000件の問い合わせでは、入力だけで2億トークンに達します。実際の費用や処理時間はモデルや実装によって異なりますが、問い合わせに関係のない情報まで毎回処理する設計では、利用規模の拡大に伴ってコストや応答時間が大きな負担になります。

そのため、コンテキストウィンドウを単に情報で埋めるのではなく、必要な情報を選択し、関連性や優先順位に応じて絞り込むことが重要です。これは回答品質の向上だけでなく、AIを継続的に運用するための費用対効果にもつながります。

質問やタスクに必要な情報を選び、判断に必要な条件を欠かさず、余分な情報に埋もれない形でLLMに渡すことが、コンテキスト設計の基本となります。

必要なコンテキストを管理する4つの戦略

AIエージェントに適切な情報を渡し続けるには、情報を集めるだけでなく、保存や要約、作業ごとの切り分けまで設計する必要があります。その方法は、「選択」「書き込み」「圧縮」「分離」の4つに整理できます。

選択：その判断に必要な情報を取得する

選択とは、その時点の質問や作業に必要な情報を取り出すことです。例えば、顧客から契約の途中解除の条件について問い合わせがあった場合、社内の契約書やFAQをすべてLLMに渡す必要はありません。顧客IDや契約の有効期間などを基に対象の契約を特定し、解除条件や通知期限、違約金など、判断に必要な条項を取得します。その際、一般的なFAQよりも顧客の締結済み契約書を優先するなど、情報の適用条件や優先順位を考慮することが重要です。

書き込み：作業の状態を外部に保存する

書き込みとは、作業の進捗や途中で分かったことを、ファイルやデータベースなどに保存することです。長時間の業務を進めるAIエージェントが、すべての経緯を会話履歴の中だけで保持し続けるのは困難です。

例えば、50件の契約書から更新条件や通知期限を確認する場合、32件まで確認した時点で、確認済み・未確認の件数や確認結果、保留事項、次に確認する契約などを保存します。

作業を再開する際は、この記録を読み込み、必要な原文を参照すれば、最初から32件を読み直す必要がありません。単に「何を読んだか」だけでなく、「何が分かり、何が未解決で、次に何をするか」を残すことが、継続的な業務を支えます。

圧縮：判断に必要な条件を残して要約する

圧縮とは、長い文書や蓄積した会話から、今後の判断に必要な情報を残して情報量を減らすことです。

例えば、過去30件のサポート履歴を要約する場合、「過去6カ月で同じ障害が3回発生し、うち1回はSLAの適用対象外。前回は個別合意に基づき月額料金の10％相当を補償」とまとめれば、判断に必要な情報を簡潔に伝えられます。一方、「過去に複数回の障害があり、補償済み」とだけ要約すると、補償の根拠や適用除外の条件が失われます。

圧縮で重要なのは、単に短くすることではありません。数値、例外条件、判断の根拠、未確認事項を残し、必要に応じて元の履歴に戻れるようにすることです。

分離：タスクごとにコンテキストを分ける

複雑な業務を一つのAIエージェントにすべて処理させると、異なる分野の情報が混ざり、コンテキストが乱雑になります。そこで、タスクごとに担当するエージェントを分け、それぞれが自分の業務に必要な情報だけを扱うようにします。

例えば企業買収の調査なら、契約書を確認するエージェント、財務情報を確認するエージェント、規制リスクを確認するエージェントに作業を分けます。各エージェントは担当分野の資料を調べ、判断の根拠を含む要点を、全体を統括する中心エージェントへ返します。

その際、契約書に記載された解約ペナルティと財務資料に計上された引当金を別々のリスクとして二重計上しないよう、各エージェントの調査結果を照合します。このように、タスクごとに扱う情報を限定し、結果を統合することで、情報の混同を抑えられます。

必要な情報を絞り込む「2段階検索」の仕組み

4つのポイントのうち、企業内に蓄積された情報を活用するうえで、特に重要になるのが「選択」を支える検索です。実用的な方法の一つが、複数の検索方式で候補を広く集めた後、質問との関連性を詳しく評価して絞り込む、2段階の構成です。

第1段階：ハイブリッド検索で候補を抽出

企業内の情報には、顧客IDやエラーコードのように文字列の一致が重要なものと、問い合わせと文書で表現が異なっていても見つけたいものがあります。この両方に対応するため、キーワード検索、関連語を補う語彙拡張検索、意味的な近さを捉える密ベクトル検索などを組み合わせます。

例えば、「エラーE-4021で接続できない。対処方法と契約上の補償を知りたい」という問い合わせを考えてみましょう。この場合、技術的な対処方法と補償条件という、異なる情報を探す必要があります。

技術情報については、キーワード検索で「E-4021」を含む文書を探します。エラーコードは1文字違うだけで別の問題を指す可能性があるため、正確な一致が重要です。併せて、「接続できない」に関連する「接続失敗」などの語彙を補い、関連するトラブルシューティング文書を探します。

補償条件については、「補償」という言葉だけでなく、「サービスクレジット」「サービス水準未達時の対応」といった記述も候補に含めます。語彙拡張やベクトル検索を使うことで、問い合わせと文書の表現が異なる場合も検索対象にできます。ただし、「返金」と「サービスクレジット」は同じものではありません。関連する情報として取得したうえで、具体的な条件は原文で確認します。

このように、文字列を正確に捉える検索と、意味や関連語を捉える検索を組み合わせるのが、ハイブリッド検索です。複数方式の結果は、各方式での順位をもとに統合する手法であるRRFなどで一つの候補リストにまとめます。また検索の前提として、利用者が閲覧できる範囲を守り、顧客固有の契約情報は対象の顧客に絞ることも欠かせません。

第2段階：ランキングで必要な情報を絞り込む

次に、取得した候補をリランキングします。これは、候補となる文書と質問の関係を詳しく評価し、順序を付け直す処理です。代表的な手法であるCross-Encoderは、質問と文書を一緒にモデルへ入力し、両者の関連性を評価します。この手法は高精度に関連性を評価できますが、第1段階の検索と比べて計算コストが高く、処理にも時間がかかります。そのため、全文書ではなく、第1段階で取得した候補に対してのみ適用します。

先ほどの問い合わせであれば、例えば100件の候補から、該当エラーの対処手順、対象サービスのSLA条項、補償の適用除外条件など、回答に必要な5件程度へ絞り込む構成が考えられます。対処方法に関する文書だけで上位が埋まらないよう、技術情報と契約情報をそれぞれ選ぶ設計も必要です。

また、リランキングによる関連性の評価だけで、締結済み契約書が一般的なFAQより優先されるとは限りません。顧客IDや契約の有効期間による絞り込みに加え、締結済み文書を優先するルールなどを組み合わせる必要があります。

第1段階で必要な情報の取りこぼしを抑え、第2段階で質問に関係の深い情報を選ぶ。さらに、文書の適用範囲や優先順位を反映する。この組み合わせによって、限られたコンテキストに、回答の根拠となる情報をそろえやすくなります。

AIエージェントの本番運用に必要な基盤とは

ここまでの設計を業務で継続的に動かすには、データ、コンテキスト、AIエージェントの役割を整理する必要があります。

データレイヤーは、契約書、製品情報、対応履歴などを保存し、検索できる状態にします。そこでは文書の内容に加え、顧客ID、更新日時、有効期間、アクセス権限などの属性も管理します。

その上で、AIが行う作業に合わせて情報を選択し、記憶や進捗を読み出し、必要に応じて要約して提供する役割を担うのが「コンテキストレイヤー」です。本稿では、特定の製品や単一のシステムを指すのではなく、データとAIの間で、判断に必要な文脈を整える機能のまとまりとして捉えています。

AIエージェントは、提供された情報と業務上の指示を基に、回答を作成したり、外部ツールを利用したりします。例えば、契約情報の照会と補償の実行では必要な権限が異なります。何を参照できるかに加えて、何を実行できるか、人の承認をどこで求めるかも、ツール側を含めて設計する必要があります。

本番運用に向けた評価では、回答が自然かどうかだけを見るべきではありません。適用すべき契約を取得できたか、必要な例外条件を残せたか、根拠が不足したときに追加確認や人への引き継ぎができたかを確認します。回答までの時間、問い合わせ1件当たりのコスト、同時利用が増えた際の性能も併せて測ります。

誤回答が発生した場合も、原因を切り分けられることが重要です。元データが古かったのか、検索で取りこぼしたのか、要約で条件が消えたのか、それとも生成時に根拠を正しく扱えなかったのか。参照した情報や処理の記録を残しておけば、改善すべき箇所を特定しやすくなります。

まとめると、AIエージェントを業務で継続的に活用するには、モデルの性能だけでなく、本稿で述べた4つの戦略 ─ 必要な情報を選び（選択）、作業の状態を保存し（書き込み）、重要な条件を残しながら要約し（圧縮）、タスクごとに適切な文脈を渡す（分離）─ を実現する仕組みが必要です。このコンテキストの設計と改善を支える基盤が、AIエージェントを実証実験から本番運用へと進める鍵になります。