この記事はAgentic RAG実装記事の補足図解版です。本編を読んでいなくても最初から理解できるように書いています。「RAGって何？」というところから始めます。
まず「RAG」って何？という話
AIに社内文書や技術ドキュメントの内容を答えてもらいたいとき、LLM（ChatGPTやClaudeなど）をそのまま使っても限界があります。学習データに入っていない情報は答えられないからです。
そこで使われるのが RAG（Retrieval-Augmented Generation） という仕組みです。日本語にすると「検索してから生成する」方法、くらいに思ってもらえれば十分です。
やっていることはシンプルで、「質問が来たらまずドキュメントを検索して、見つかった内容をLLMに渡してから回答を作らせる」というものです。図書館で「この本の内容をもとに答えてください」と伝えるイメージです。
普通のRAGの弱点：1回調べておしまい
まず普通のRAGとAgentic RAGの構造を並べて見てみます。
| 普通のRAG | Agentic RAG | |
|---|---|---|
| 検索回数 | 1回だけ | 1〜3回（必要なら繰り返す） |
| LLM呼び出し | 1回 | 6〜10回 |
| 速さ・コスト | 速い・安い | 遅い・高い |
| 複合質問への対応 | 苦手 | 得意 |
普通のRAGは、質問が来たら1回だけ検索して、そのまま回答を作ります。
これで十分な場合はたくさんあります。「Pythonでリストに要素を追加するには？」みたいな質問なら、1回の検索で答えは出ます。
問題になるのは「認証とSQLインジェクション対策を両方教えて」のような複合的な質問です。検索は1回しかしないので、うまくいけば両方の情報が取れますが、片方しか取れなかった場合でも「これで行くしかない」と回答してしまいます。
本編の実験では、この質問に対してSQLインジェクション対策は答えられたものの、JWT認証の詳細は「ドキュメントに記載がありません」で終わりました。
Agentic RAGが加えたもの：「足りなければやり直す」
Agenticの最大の違いは、検索した後に「これで足りるか？」を確認するステップが入ることです。
確認するポイントが2か所あります。
evaluate（材料チェック）
「集めてきた文書だけで質問に答えられそうか」を確認します。料理前に冷蔵庫を開けて「材料は揃ってるか」確認するイメージです。0〜1のスコアで判定し、0.7未満なら検索クエリを書き換えてもう一度検索し直します。
reflect（完成品チェック）
「実際に作った回答で質問に答えられているか」を確認します。料理を完成させてから「これ食べられるか」確認するイメージです。こちらでNGが出たら、また検索に戻ります。
全体の流れを図にするとこうなります。
この「材料チェック」と「完成品チェック」という2段構えが、普通のRAGにはない部分です。
実際にQ2でどう動いたか
「WebアプリのAPIを作るとき、認証とSQLインジェクション対策について両方教えてください」という質問を投げたときの実行シーケンスです。
ステップ3の evaluate（材料チェック）で、Claudeが「SQLはOKだけど、JWT実装の詳細が足りない」と判断しました。ただスコアが0.75で0.7以上はあったので「ひとまず回答を作ってみよう」と generate に進みます。
ステップ5の reflect（完成品チェック）で今度は「この回答、JWT実装の詳細がまだ足りてない」とNGを出して、もう一度検索に戻ることにしました。
ここが面白いポイントです。evaluate はOKを出したのに、reflect がNGを出した。 「材料は揃ってそう」と思ったけど、実際に作ってみたら「あ、これ足りてなかった」と気づく、という人間でもよくある現象が起きています。
2回目の検索を経て、最終的には普通のRAGでは「記載なし」と言われていたJWT認証の説明が回答に含まれるようになりました。
正直なところ：万能ではない
Agenticにすれば何でも解決するわけではありません。
「データベースとAPIの設計における一貫性を比較・考察してください」という質問を試したところ、検索を3回繰り返しても点数が 0.30 から上がりませんでした。理由はシンプルで、そういう比較考察がドキュメントに書かれていないからです。何回調べ直しても、ドキュメントに書いていない情報は出てきません。
Agenticが得意なのは「1回の検索で取りきれなかった情報を追加で集める」ことです。ドキュメントの外にある知識を作り出してくれるわけではありません。
また、単純な質問に対しては普通のRAGより検索回数もLLM呼び出し回数も多くなるぶん、速度もコストもかかります。「FAQに答えるだけのシステム」にAgenticを使うのは過剰です。
実用上のコツとして、「2回連続でスコアが変わらなければ早期終了する」ロジックを加えると、無駄なLLM呼び出しを削れます。
どちらを使うか、判断のめやす
| こんなときは | これを選ぶ |
|---|---|
| 質問のパターンが決まっている（FAQ、マニュアル検索など） | 普通のRAG |
| 「AとBを両方教えて」のような複合質問が来る | Agentic RAG |
| 答えが複数のドキュメントに散らばっている | Agentic RAG |
| とにかく速く・安く動かしたい | 普通のRAG |
| ドキュメントにない考察や分析を求める質問が多い | どちらでも解決しない |
コードの実装が気になった方は本編をどうぞ。LangGraph + ChromaDB + Claudeで動くコード一式を公開しています。