Agentic RAG 導入ガイド｜通常RAG・GraphRAGの使い分け、PoC評価・権限・コスト管理
AI新規事業
AI新規事業のPoC・立ち上げ、何から始めるべきかご相談ください
要件定義からリリースまで、Mojiがワンチームで伴走します。
1992年生まれ鳥取県出身、高専にてソフトウェア開発を学ぶ⚙️ レシピアプリや通話アプリなどのMVP開発を担当し、合計1000万DLを突破。 その経験を経てMojiを創業、生成AIやその周辺システムの開発マネジメントを行っている。 趣味はキャンプと二郎、筋トレ（ベンチ100kg）。
「社内RAGで文書検索はできるようになったが、複数の情報源を調べ、必要なら業務システムを照会し、回答の不足を追加調査するところまで任せたい」。この段階で検討対象になるのが、Agentic RAG（エージェント型RAG）です。
ただし、通常RAGより高度に見えるからといって、最初からAgentic RAGへ移行する必要はありません。固定された手順で十分な業務をエージェント化すると、回答までの時間、モデル呼び出し回数、監視・評価の範囲だけが増えるおそれがあります。Anthropicは、事前定義したコード経路でLLMとツールを動かすものを「ワークフロー」、LLMがプロセスとツール利用を動的に決めるものを「エージェント」と区別し、まず最も単純な解決策から始めることを勧めています。Anthropic: Building effective agents
結論：Agentic RAGを検討するのは、質問ごとに「次に何を調べるか」「どの情報源を使うか」「追加確認が必要か」が変わり、固定フローでは品質または運用負荷を抑えにくい場合です。一方、規程・FAQ・マニュアルを根拠付きで回答する仕事は通常RAG、関係性をまたぐ全体傾向・影響範囲の把握はGraphRAG、在庫・残高・確定価格などの現在値を決める仕事はDB・業務APIへの直接照会を、まず比較対象にしてください。
本記事の判定表、PoC手順、評価ケース、権限設計、コスト測定シートは、特記のない限りMojiによる実務上の提案です。業務の重要度、データ品質、利用するモデル、許容できない誤り、契約・規制要件に合わせて調整してください。
RAGの基本構造、対象業務の選び方、評価の全体像は、RAG（検索拡張生成）とは？導入すべき業務の判断基準・他方式との違い・評価の進め方で解説しています。
Agentic RAGとは：検索を「一度する」だけでなく、調査・照会・検証の経路を選ぶ設計
RAG（Retrieval-Augmented Generation）は、検索でアクセスする外部メモリと生成モデルを組み合わせる枠組みです。原論文では、事前学習済みの生成モデルと、検索で参照する非パラメトリックなメモリを組み合わせる構成が示されています。Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
本記事ではAgentic RAGを、LLMが質問・中間結果・ツールの返却値を踏まえ、検索先、追加照会、検証、終了または人への引き継ぎを選びながら、外部知識を利用するRAG設計として扱います。これは特定ベンダーや単一ライブラリの正式名称ではありません。
典型的には、次のようなループを設計します。
- 依頼を分類する：文書回答でよいか、現在値の照会が必要か、追加調査が必要かを判定する。
- 情報源・ツールを選ぶ：社内文書検索、ナレッジグラフ、CRM、在庫API、チケット管理、Web検索などから、許可された手段だけを選ぶ。
- 中間結果を検証する：取得根拠が足りるか、データが新しいか、権限外の情報が混ざっていないかを確認する。
- 再検索・再計画・引き継ぎを決める：追加の照会を行う、回答範囲を限定する、人へエスカレーションする、または終了する。
重要なのは、モデルに無制限の自律性を与えることではありません。業務に必要な選択肢、権限、予算、停止条件を先に定義し、その範囲で検索・照会・検証を行わせることです。
通常RAG・Agentic RAG・GraphRAG・DB/API直接照会の使い分け
以下は、アーキテクチャを一律に優劣で比較する表ではありません。結論は、質問の型、入力文書の品質、権限設計、評価指標、許容誤差によって変わります。表は一般的な設計上の目安です。
方式 | 向く質問・業務 | 中心となる処理 | 導入前に確認すること |
|---|---|---|---|
通常RAG | 「規程の申請条件は？」「製品Aの設定手順は？」のように、関連文書を見つけて説明できる質問 | 検索→根拠を絞る→回答生成 | 文書の正本、更新管理、検索精度、引用表示、閲覧権限 |
Agentic RAG | 「この顧客の問い合わせに対して、契約・障害履歴・現在の設定を確認し、次の対応案を作成して」のように、調査経路が質問ごとに変わる業務 | 分類→検索・ツール選択→中間確認→追加調査または引き継ぎ | ツール別権限、承認、最大反復回数、停止条件、トレース、業務単位コスト |
GraphRAG | 「複数部門の施策の関係は？」「全資料を通じて共通する課題は？」のように、エンティティ間の関係やコーパス全体の構造が重要な質問 | エンティティ・関係の抽出、グラフ探索、コミュニティ要約など | 関係抽出の誤り、索引作成コスト、更新頻度、グラフが本当に必要な質問か |
DB・業務API直接照会 | 「現在在庫は？」「この顧客の契約状態は？」「今日の確定価格は？」のように、正本となる現在値を確定する業務 | 認可済みクエリ・API呼び出し→値を整形して提示 | 正本データ、鮮度、認可、更新操作の承認、失敗時の業務手順 |
在庫・売上・価格・残高のような値を、検索文書の記述から推測して確定させる設計は避けるべきです。文書を探して説明する処理と、業務システムの正本を照会して現在値を確定する処理を分ける考え方は、RAGにリアルタイムの在庫・売上・価格を任せない設計｜DB・API直接照会との使い分けで詳しく解説しています。
GraphRAGを選ぶ前に確認したいこと
GraphRAGは一つの固定実装を指す言葉ではなく、知識グラフを検索・文脈構成へ使うRAG設計群です。MicrosoftのGraphRAG実装では、非構造テキストからエンティティ、関係、主張を抽出し、コミュニティ検出・要約、ベクトル化を行う標準パイプラインが案内されています。Microsoft GraphRAG: Indexing overview
Microsoftの公式リポジトリは、GraphRAGを研究プロジェクトであり、リポジトリは主に保守モードであると説明しています。また、インデックス作成は高コストになり得るため、小さく試すよう注意を促しています。したがって、GraphRAGを「通常RAGの上位互換」として採用するのではなく、関係の明示・全体俯瞰・横断的な探索が、索引作成と更新の負担を上回るかをPoCで検証してください。Microsoft GraphRAG GitHub repository
GraphRAGの検索方式、通常RAGとの比較、設計上の注意点は、Graph RAGとは？従来RAGとの違い・向く質問・設計上の注意点も参照してください。
Agentic RAGを導入する判断基準：5つ中3つ以上ならPoC候補
次の質問に「はい」が3つ以上ある場合、固定RAGや単一ワークフローと比較するAgentic RAGのPoCを検討する余地があります。ただし、これは採用を自動決定する点数ではなく、検証対象を絞るためのMojiの提案です。
- 調査順序が固定できないか：問い合わせ内容により、参照すべき文書・DB・API・担当部署が変わる。
- 一度の検索で根拠がそろわないか：初回検索後に、追加質問、追加検索、条件変更が頻繁に必要になる。
- 複数の読み取り専用ツールを使う価値があるか：文書、チケット、CRM、製品設定などを横断しないと回答品質が上がらない。
- 中間結果で分岐する必要があるか：不足情報、矛盾、期限切れ、権限不足が起きたとき、決められた分岐だけでは扱いにくい。
- 結果を検証できるか：根拠、API返却値、作業ログ、人の判定、テスト結果などで、成功・失敗を後から確認できる。
反対に、次の条件では、まず通常RAGまたは固定ワークフローを優先します。
- 質問の種類と検索対象がほぼ固定されている。
- 正解手順が明確で、例外が少ない。
- 外部システムの更新や送信を伴い、誤操作の影響が大きい。
- 成功を判定する根拠・テスト・人の確認者がまだ決まっていない。
- 検索品質、文書抽出、権限管理など、通常RAGの基礎課題を切り分けられていない。
社内RAGが的外れな回答を返す場合は、エージェント化の前に、原文・抽出結果・検索候補・LLMへ渡した文脈・最終回答のどこで根拠が落ちたかを確認してください。診断手順は社内RAGが的外れな回答を返す原因と改善方法｜検索・チャンク・抽出・評価の切り分けで解説しています。
PoCから本番までの導入手順
1. 業務を「質問」ではなく「完了条件」まで分解する
「問い合わせ対応を自動化する」のような大きな目的ではなく、対象を一つの業務単位へ狭めます。例えば、架空の例：契約変更に関する社内問い合わせに対して、最新規程と契約管理システムの閲覧可能な情報を根拠付きで要約し、送信前の回答案を作ると定義します。
この時点で、次の項目を記録してください。
- 利用者と対象業務
- 入力してよい情報・入力禁止の情報
- 参照する正本と、更新頻度
- AIが実行してよい操作、実行してはいけない操作
- 人が確認する地点と担当者
- 成功条件、許容できない失敗、停止条件
NIST AI RMFは、AIリスク管理をGOVERN、MAP、MEASURE、MANAGEの4機能で整理し、対象用途、影響、人による監督、測定、対応を継続的に扱う考え方を示しています。NIST AI RMF Core
2. 比較対象を必ず置く
PoCではAgentic RAG単体を評価しません。少なくとも、次の比較対象を同じ質問セットで動かします。
- 人だけで現行業務を行う方法
- 通常RAG
- 固定ワークフロー型RAG
- Agentic RAG
- 必要に応じてGraphRAGまたはDB/API直接照会
比較の目的は「最も高度な方式を選ぶ」ことではなく、許容できる品質・時間・コスト・リスクで業務目的を達成する最小構成を選ぶことです。
3. 評価ケースを、失敗の種類ごとに作る
Agentic RAGは最終回答だけでなく、検索、ツール選択、権限、反復、停止まで評価対象になります。エージェントは複数ターンでツールを呼び、状態を更新し、中間結果に応じて方針を変えるため、評価ではその処理経路を記録・確認することが重要です。Anthropic: Demystifying evals for AI agents
以下は、PoC用の最小評価ケース表です。件数は一律に決めず、実際の問い合わせ分布とリスクに応じて増やしてください。
ケース群 | 確認すること | 合否の見方 |
|---|---|---|
標準ケース | 必要な文書・データへ到達し、根拠付きの回答案を作れるか | 正答だけでなく、根拠の正しさと不足情報の明示を確認する |
曖昧な依頼 | 推測で進めず、確認質問または限定回答へ切り替えるか | 誤った前提でツールを実行していないか |
矛盾・古い情報 | 正本・更新日時・版を区別できるか | 古い文書を確定情報として扱わないか |
権限不足 | 閲覧不可の文書・レコードを検索・引用・推測しないか | 拒否または適切な引き継ぎになるか |
有害な指示の混入 | 文書・Webページ・添付ファイル中の指示に従って権限外の行動をしないか | 情報源の内容を命令ではなくデータとして扱えるか |
ツール障害・上限超過 | 再試行回数、代替経路、人への引き継ぎが意図どおりか | 無限ループ、二重実行、無言の失敗がないか |
RAG評価用データセットを作る際は、質問と期待回答だけで終わらせず、正解根拠、想定する検索対象、許容しない回答、判定者を結び付けてください。具体的な設計方法はRAG評価データセットの作り方｜設計・作成・品質確認・更新を実務手順で解説で紹介しています。
4. 本番前に「権限・承認・停止」を実装する
Agentic RAGのリスクは、誤答だけではありません。ツールを使える設計では、プロンプトインジェクション、過大な権限、過剰な自律性により、想定外のデータ参照や操作が起きる可能性があります。OWASPはLLMアプリケーションの主要リスクとしてPrompt InjectionとExcessive Agencyを挙げ、Excessive Agencyの要因として過剰な機能・権限・自律性を説明しています。OWASP Top 10 for Large Language Model Applications
最初の本番運用では、次の順序を推奨します。
- 読み取り専用：検索・照会・下書き作成だけを許可する。
- 人の承認付き更新：更新候補を作るが、送信・登録・変更は人が承認する。
- 限定的な自動実行：低リスクかつ可逆的な操作だけを、対象・時間・回数を限定して自動化する。
少なくとも、ツールごとに「読み取り」「下書き」「外部送信」「データ更新」「権限変更」「金銭・契約に関わる操作」を別権限にしてください。エージェントへ委任する範囲、承認が必要な操作、停止・復旧の設計は、AIエージェントのガードレール設計｜暴走を防ぎながら自動化を進める権限・承認・停止・監視の実務ガイドで詳しく解説しています。
5. 本番化・限定継続・中止を、開始前に判定できるようにする
PoCはデモの成功を示す場ではなく、次の投資判断を行う実験です。開始前に、品質、安全性、処理時間、1業務あたりの費用、利用者の確認負担について、合格・保留・中止の条件を記録してください。
本番化の判断に必要なKPI、ベースライン、移行ゲート、定着指標は、AI PoCを本番化する進め方｜開始前の合否基準・KPI・移行ゲート・定着指標で整理しています。
権限・承認・停止条件の設計テンプレート
以下はMojiによる提案です。実装前に、ツール単位で表を埋めてください。「使えるツール一覧」だけでは、運用時の責任範囲を判断できません。
項目 | 記入内容 |
|---|---|
ツール名・用途 | 例：架空の例「契約管理API。契約状態の読み取り」 |
許可する操作 | 検索、特定フィールドの読み取り、下書き作成などを操作単位で記載 |
禁止する操作 | 送信、削除、権限変更、金額確定、契約更新など |
利用条件 | 利用者ロール、対象テナント、対象レコード、時間帯、用途 |
承認条件 | 誰が、画面上の何を確認し、どの操作で承認するか |
停止条件 | 権限エラー、矛盾データ、指定回数を超える再試行、予算超過、異常なツール呼び出し |
復旧・引き継ぎ | ログID、途中結果、未完了の作業、担当キュー、利用者への表示文 |
保存する証跡 | 入力の識別子、取得元、ツール引数、返却要約、承認者、実行結果、モデル・プロンプト版 |
停止条件は「エラー時に止める」だけでは不十分です。業務上の完了条件を満たさない、根拠が不足する、許可された予算・反復回数を超える、人の確認が必要な操作へ到達する場合にも、完了ではなく保留または引き継ぎにする設計が必要です。
コスト管理：月額ではなく「業務1件あたりの処理経路」で測る
Agentic RAGでは、初回回答の後に追加検索、再ランキング、ツール呼び出し、検証用モデル呼び出しが発生し得ます。そのため、月間トークンだけでは「どの業務が採算に合うか」を判断しにくくなります。
以下のコストシートはMojiによる提案です。評価ケースと本番トレースの両方で、業務1件ごとに記録してください。
測定項目 | 見る目的 |
|---|---|
依頼種別・難易度 | 単純な質問と複雑な調査を混ぜずに比較する |
モデル呼び出し回数 | 計画、回答、検証、再計画が増えていないか確認する |
入出力トークン | 文脈の過多、長すぎるツール結果、再試行を検知する |
検索回数・取得件数 | 検索が不足しているのか、ノイズを増やしているのかを分ける |
ツール/API呼び出し回数と料金 | 外部サービスの従量課金と異常実行を把握する |
処理時間 | 利用者が待てる時間と、タイムアウト・非同期化の要否を判断する |
人の確認時間・差し戻し率 | AIの出力が確認作業を削減しているか、移しているだけかを確認する |
最終状態 | 完了、保留、失敗、権限拒否、予算停止を分けて分析する |
業務1件あたりの総コストは、モデル利用料、検索・埋め込み・OCRなどの処理料、外部API料金、インフラ費、監視費、人による確認工数を、同じ業務単位に寄せて見ます。特定のモデルの単価だけで比較せず、同じ評価ケースで完了率、許容できない失敗、処理時間、確認時間を並べてください。
対策は、単に最大トークン数を下げることではありません。質問のルーティング、検索候補の絞り込み、ツール返却値の必要部分だけの構造化、モデルの役割分担、最大反復回数、業務別の予算上限を組み合わせます。検索件数を増やしすぎた際の品質低下と、top-k・重複排除・再ランキングの見直し方は、RAGで検索結果を増やしすぎると精度が落ちる理由｜top-k・重複排除・再ランキング・要約の設計を参照してください。
導入前チェックリスト
- 対象業務を、利用者・入力・完了条件・責任者まで定義した。
- 通常RAG、固定ワークフロー、GraphRAG、DB/API直接照会を比較対象に置いた。
- 正本データと、説明用の文書を分けた。
- 通常RAGの抽出・検索・権限の問題を、エージェント化で隠していない。
- 標準、曖昧、矛盾、権限不足、悪意ある指示、障害・上限超過の評価ケースを作った。
- 最終回答だけでなく、検索結果、ツール引数・返却値、承認、停止理由を確認できる。
- ツールごとに最小権限を設定し、送信・更新・権限変更・金銭に関わる操作を分離した。
- 再試行回数、ツール呼び出し回数、トークン、時間、API料金の上限を実装した。
- 品質・安全性・費用・人の確認工数について、PoCの合格・保留・中止条件を開始前に決めた。
- モデル、プロンプト、検索インデックス、ツール仕様、権限を変更したときの再評価条件を決めた。
まとめ：Agentic RAGは「複雑な検索」ではなく、統制された業務経路を設計する取り組み
Agentic RAGの価値は、検索回数を増やすことや、AIを自律的に見せることではありません。質問ごとに異なる調査・照会・確認を、許可されたデータとツールの範囲で進め、根拠・コスト・停止理由を追跡できるようにする点にあります。
まずは、通常RAGで解くべき仕事、関係構造が必要なGraphRAG、正本を直接照会すべきDB/API、柔軟な探索が必要なAgentic RAGを分けてください。そのうえで、低リスクな読み取り専用業務から比較PoCを始め、評価結果をもとに権限と自動化範囲を段階的に広げることが、導入失敗を避ける現実的な進め方です。
AIエージェント全体の対象業務、固定ワークフロー・RPA・チャットボットとの違いは、AIエージェントとは？生成AI・チャットボット・RPAとの違いと導入判断・実践手順もあわせてご確認ください。