RAG 11：エージェント型 RAG ― 探し方そのものを LLM に任せる

1回探しただけでは答えられない質問がある

「先月いちばん問い合わせの多かった製品の、保証期間は？」という質問を考えます。

答えるには、2つのことを順に調べる必要があります。

ポイントは、②の問いに入る製品名（製品X）は、①の答えを読むまで分からないことです。元の質問のまま1回探しても、「保証期間」について書かれた、いろいろな製品のマニュアルが並ぶだけです。どの製品のものを読めばよいのか、LLM には判断できません。

このように、ある答えを手がかりに次を調べる必要がある質問を、多段の質問（マルチホップの質問）と呼びます（第9章）。

第9章の「分解」は、最初に質問を小さな問いに分けました。でも、この例では①の答えが出るまで②の問いが作れないので、最初に一度分解するだけでは足りません。探した結果を読んでから、次の問いを考える必要があります。そのためには、LLM が流れの途中に何度も口を出せる形にしなければなりません。

一言でいうと：LLM に「探す道具」を渡し、使い方を任せる

エージェント型 RAG の考え方は、一言でいうと「検索を、LLM が自分で呼べる道具にする」ことです。

いまの主な LLM の API（プログラムから LLM を呼び出すための窓口）には、道具の使用（tool use、function calling とも呼ばれます。「ツール呼び出し」とも）という機能があります。アプリの側で「こんな道具があります」と LLM に教えておくと、LLM は答えの途中で「この道具を、この引数（道具に渡す入力。検索なら検索する言葉）で呼びたい」と言えるようになります。アプリがその道具を実行し、結果を LLM に返すと、LLM はそれを読んで続きを考えます。料理人（LLM）が「冷蔵庫から卵を2個取って」と頼み、助手（アプリ）が取ってきて渡す、という分担に似ています。

図では、LLM の周りに4つの道具があります。

一本道の RAG では、人が「必ず社内規程を1回探す」と決めていました。エージェント型では、どの道具を、どんな言葉で、何回使うかを LLM が決めます。探さずに答えてよい質問では、1回も探しません。第9章の「振り分け」や「探すかどうか」の判断も、LLM が道具を選ぶ形で自然に行われます。

「エージェント」という言葉は、ここでは「目的のために、自分で次の行動を選んで動く LLM」くらいの意味で使っています。

考える → 探す → 読む → 足りなければもう一度

エージェントの動きは、図の輪で表せます。

足りると判断したら、輪を抜けて答えます。

この「考える」と「行動する」を交互に繰り返す形は、2022年の論文 ReAct（Reasoning と Acting を組み合わせた名前）で広く知られるようになりました。論文では、LLM が Wikipedia を検索しながら、考え・行動・結果を交互に書いて問題を解く様子が示されています。

大事なのは、輪を何周するかが質問によって変わることです。簡単な質問なら1周で終わり、難しい質問なら何周もします。一本道の RAG は、いわば「必ず1周だけする輪」でした。エージェント型は、周回の数を LLM に任せた形です。

最近の LLM は、この輪を回すことを想定して訓練されていて、道具を何度も呼びながら問題を解くのが上手になっています。ただし、任せるということは、止まらない・同じことを繰り返すという危険も生まれます。その対策は後半で見ます。

実際の動き：2回探して、答えにたどり着く

図は、多段の質問「先月いちばん問い合わせの多かった製品の、保証期間は？」を、エージェントが解いたときの記録（ログ）の例です。

2周目の検索の言葉「製品X 保証期間」に注目してください。これは、1周目の結果を読んだから作れた問いです。一本道の RAG には、この動きはできません。

コードにすると、骨組みは次のようになります（llm.chat と runTool は説明用の仮の関数です）。

const messages = [{ role: "user", content: question }];
for (let step = 0; step < 6; step++) {          // 上限を必ず決める
  const res = await llm.chat({ messages, tools });
  if (res.toolCalls.length === 0) return res.text; // 道具を呼ばない＝答え
  messages.push(res.message);
  for (const call of res.toolCalls) {
    messages.push({ role: "tool", id: call.id, content: await runTool(call) });
  }
}
return "調べきれませんでした。わかった範囲では…";

LLM が道具を呼ばなくなったら、それが答えです。ループの回数に上限があることも大事です。

道具は「名前・説明・引数」で LLM に教える

LLM に道具を教えるときは、多くの API で共通して、次の3つを渡します。

図の左は、この3つを書いた例です。query（検索する言葉）は必ず埋める入力、product（製品名）は ? が付いていて省略できる入力です。

LLM は、説明文を読んでどの道具を使うかを決めます。だから、説明文の書き方がとても大事です。「検索する」とだけ書かれた道具が3つあれば、LLM はどれを使えばよいか分かりません。「製品の取扱説明書を検索する。仕様・保証・故障時の対応に使う。社内規程はここには無い」のように、何が入っていて、何が入っていないかまで書くと、選び間違いが減ります。

もう1つ大事なのは、道具を実行するのはアプリの側だということです。LLM は「この引数で呼びたい」と言うだけで、実際に検索したりデータベースを読んだりするのは、あなたのプログラムです。

これは安全の面で重要です。アプリの側で、「この利用者が見てよい資料だけを探す」「データベースは読むだけ」といった制限をかけられるからです。LLM が引数に何を書いてきても、権限の確認はアプリが行います（第13章）。

道具の数は、多ければよいわけではありません。似た道具が増えるほど選び間違いが増えます。まずは少なく、はっきり違う道具から始めます。

探した結果を、自分で確かめてから使う

一本道の RAG は、見つかった資料が的外れでも、それを読んで答えるしかありませんでした。エージェント型なら、読んだ結果を確かめて、だめなら探し直すことができます。

図の輪では、「足りる？」の段階を「確かめる」に強くしています。確かめるのは、主に次の2つです。

この考え方を研究として形にしたものに、Self-RAG（2023年）と CRAG（Corrective RAG、2024年）があります。

Self-RAG は、「そもそも探す必要があるか」「拾った資料は関係あるか」「自分の答えは資料に支えられているか」を、LLM 自身が特別な印（反省トークン。トークンは第1章で見た、LLM が読み書きする文字のかけら）を出して判定するように訓練する方法です。書きながら自分で赤ペンを入れる書き手のようなものです。CRAG は、拾った資料の良し悪しを判定する小さな専用のモデルを検索の後ろに置き、判定が悪ければ Web 検索などで補う、という方法です。こちらは、書き手の横に資料の目利き役を付ける形です。

どちらも論文の名前ですが、考え方は実務でもそのまま使えます。「拾った資料が質問に関係あるかを LLM に判定させ、関係なければ探し直す」という一段を足すだけでも、的外れな答えを減らせます。代わりに、LLM の呼び出しが増えるので、遅く高くなります。

調べ物エージェント：数十回探して、報告書を書く

エージェントの輪を大きく回すと、調べ物そのものを任せられるようになります。2024年の末から2025年にかけて、Google の Gemini や OpenAI の ChatGPT などに、「Deep Research（ディープリサーチ）」と呼ばれる機能が登場しました。

動きは、おおむね図の3段です。

1つの質問に数分から数十分かけ、数十回の検索をすることもあります。人が何時間もかけていた調べ物を、短い時間で下書きにしてくれるのが強みです。

RAG の目で見ると、これは「探す → 読むを大量に繰り返す RAG」です。社内の資料を探せる道具を渡せば、社内向けの調べ物エージェントも作れます。

ただし、使いどころは選びます。「有給は何日？」のような社内のよくある質問に、数分待たせるわけにはいきません。市場調査、技術の比較、論点の洗い出しのような、待ってでも深く調べたい仕事に向いています。

また、出典が付いていても、その出典が本当にその内容を言っているかは別の問題です（第8章）。報告書が長いほど、人が確かめる手間も増えます。

MCP：探す道具を、共通の口で差し込む

エージェントに渡す道具は、社内 Wiki の検索、チケット管理、データベース、ファイル共有…と、どんどん増えていきます。これをアプリごとに作り直すのは大変です。

そこで登場したのが MCP（Model Context Protocol。直訳すると「モデルに文脈を渡すための通信の約束事」）です。2024年11月に Anthropic が公開した、LLM のアプリと、外部の道具やデータをつなぐための共通の決まりです。その後、OpenAI をはじめ多くの会社やツールが対応しました。

図では、前のページと同じ位置の道具の箱が、「MCP サーバー」に変わりました。道具を MCP サーバーとして一度作っておけば、MCP に対応したどのアプリからでも、同じ道具を使えます。コンセントの形が決まっていれば、どの家電もさせるのと似ています。

RAG の目で見ると、MCP は「探す道具を差し込む口」です。第2〜10章で作った検索の仕組みを MCP サーバーとして公開すれば、エージェントがそれを道具として使えるようになります。

注意点もあります。MCP サーバーは、LLM に資料や命令を渡す入口でもあります。信頼できないサーバーをつなぐと、資料に紛れ込んだ命令（第13章）の入口が増えます。どのサーバーをつなぐか、何の権限を渡すかは、慎重に決めます。

限界とトレードオフ：賢くなるが、遅く・高く・読めなくなる

エージェント型 RAG は強力ですが、代償もはっきりしています。

特に見落としやすいのは、「予測しやすさ」と「調べやすさ」です。一本道なら、答えが間違っていたとき、「検索が外れた」か「読み違えた」かを調べればよいだけでした。エージェントでは、「最初の道具の選び方が悪かった」「3周目の検索の言葉がずれた」「十分と判断するのが早すぎた」など、失敗の場所が増えます。

また、評価（第12章）も難しくなります。最後の答えだけでなく、途中の動き（どの道具を何回呼んだか）も見ないと、なぜ良くなったのか、悪くなったのかが分かりません。

一本道の RAG で足りる場面のほうが多い

エージェント型は新しく、話題になりやすい形です。でも、実際の社内の質問の多くは、1回探せば答えられるものです。

おすすめの進め方は、次のとおりです。

まず一本道の RAG で作り、実際の質問で動かします。そして、うまく答えられなかった質問を集めて分類します（第12章）。その中に「多段の質問」や「複数の資料庫をまたぐ質問」が多いと分かったら、そこで初めてエージェント型にします。

間を取る方法もあります。普段は一本道で答え、「確かめる」段で資料が足りないと判断したときだけ、エージェントとして探し直す、という形です。よくある質問は速く安く、難しい質問だけ時間をかける、という使い分けができます。

作るときの手綱：上限・権限・記録

エージェントに探し方を任せるなら、手綱を付けておく必要があります。

最後の点は、エージェント型で特に重要です。一本道の RAG では、資料に紛れ込んだ命令の影響は、答えの文章が変になるくらいで済むことが多いです。ところがエージェントは道具を使えるので、命令に従って別の道具を呼ぶ、つまり「行動」してしまう危険があります。資料や入力に命令を紛れ込ませて LLM を操ろうとする攻撃をプロンプトインジェクション（指示の注入）と呼びます。第13章で詳しく扱うこの攻撃が、エージェントでより深刻になるのはこのためです。

権限の確認は LLM に任せず、道具を実行するアプリの側で必ず行います。

よくある落とし穴

エージェント型 RAG で、よく起きる失敗をまとめます。

どの失敗も、記録を見れば気づけるものです。エージェントを作ったら、最初のうちは、ログを人が読む時間を必ず取りましょう。「この種類の質問では、いつも同じ道具を3回呼んでいる」といった癖が、すぐに見えてきます。