【AI×DevOps Study #22】AI Agent のための RAG System２（全2回）

■AI×DevOps Study #22の概要
2026年8月26日に開催した「AI×DevOps Study」第22回の勉強会資料です。

「AI×DevOps Study」は、AI駆動開発やそこに関係するマイクロサービスについて理解を深める場になります。
株式会社ScalarではAIを使ったチーム開発を進めており、参画しているメンバーや協力会社の方から、具体的なAI駆動開発を実施する方法、その中で生まれたマイクロサービスアーキテクチャを使用したAI駆動開発の事例や実際に使えるエージェントについてお話頂き、参加者の皆様と知識の共有や交換を目的としています。
（弊社製品であるScalarDBも絡んだお話も一部出てきますが、汎用的な内容となっておりますのでフラットにお楽しみいいただけます）

■今回のテーマ
今回のテーマは、AI Agent のための RAG Systemです。
※本勉強会は全2回で構成されています。※

2回目の今回は「RAGの利用」を軸にRAGの検索と運用についてお話します。
RAGの検索精度をあげるためのポイントや安全な運用について知りたい方、今後RAGの利用を考えている方には必要な知識となります。

■登壇者情報（敬称略）
深津航
株式会社Scalar Founder & CEO。日本オラクル株式会社、決済系のスタートアップを経て、株式会社Scalarを創業。

■関連コンテンツ
・Youtube（過去の勉強会動画も公開中！）
www.youtube.com/@scalar-labs

・Zenn ブログ
https://zenn.dev/p/scalar_sol_blog

・イベントページ（connpass）
https://scalar.connpass.com/

Transcript

1. AIxDevOps AI Agent のための RAG System #2 Agent 時代の RAG 全2回の技術勉強会（第2回・60分） 2026年8月26日 株式会社Scalar 深津航
2. 自己紹介 名前：深津航 所属：株式会社 Scalar CEO, Co-Founder 主な関心事項 • 日本のIT強化 • アーキテクチャ /設計 • DevSecOps, FinOps • AIが与える各種業界へのインパクト ◦ ▪ 株式会社 Scalar としての活動 株式会社Scalarは、分散トランザクションマネージャー のScalarDBと改ざん検知ソフトウェアの ScalarDLを展 開中。マイクロサービス化におけるシステムの課題や AI などのデータ基盤の信頼性を担保するソリューションを 展開しています。 ソフトウェア開発、システム開発、マーケティング、営 業、経営など様々な役割で活動中。 個人的には、 Moltbookが面白い LinkedIn: https://www.linkedin.com/in/wataru-fukatsu-1692655/ AIxDevOps 2 © 2026 Scalar, inc.
3. 本勉強会のゴールと対象者 【ゴール】 【対象者】 RAG の基本構造と限界を理解する AI Agent / RAG を実装するエンジニア 最近の RAG 技術、特に Agentic RAG の⽅向性を理解する エンタープライズ AI 基盤を設計するアーキテクト ⽇本語⽂書‧業務⽂書で RAG を実装する際の課題を理解 する 社内データ活⽤を進める情シス‧DX 部⾨ AI Agent から RAG を使う際の Tool 化‧権限‧監査‧評価 を理解する データ基盤‧DB‧ガバナンスに関⼼がある技術リーダー AI / RAG / Agent 提案を⾏う営業‧プリセールス 企業向け RAG / Agent 基盤の作り⽅を理解する これまで説明してきた RAG の回の元となる技術についての解説回です。 20260416 AI×DevOpsStudy #12 Claude Codeによる製造業向けの RAGとAI Agent開発 2026年07月28日 AI×DevOpsStudy #19 製造業における AIエージェント活用！ RAG/ScalarDBで支える部品選定支援システム AIxDevOps © 2026 Scalar, inc. 2 / 74
4. 前編のふりかえりと後編の問い 【前編でおさえたこと】 ・RAG は5工程（Query / Retriever / Vector / Prompt / Answer）に分解して改善する ・情報量を増やすほど良い訳ではない。ハードネガティブが判断を狂わせる ・Advanced RAG＝Query rewrite / Hybrid search / Rerank で検索品質を上げる ・権限漏れと古い情報は検索アルゴリズムでは解けない。データ設計の問題 ・日本語では前処理が最大の変数。Hybrid 検索と評価セットを標準にする 【後編で扱う4つの問い】 1. 検索が外れたとき、どう気づいてどう回復するか（Self-RAG / CRAG） 2. 断片検索では届かない問いにどう答えるか（RAPTOR / GraphRAG / Multi-Hop） 3. Agent から RAG をどう呼ばせるか（RAG as Tool / Agentic RAG / MCP） 4. 安全に運用し、改善し続けるにはどうするか（セキュリティ/ 評価） AIxDevOps © 2026 Scalar, inc. 2 / 76
5. AIxDevOps Self-RAG と CRAG 第1章 検索するか、検索結果を信用するか AIxDevOps © 2026 Scalar, inc. 3 / 76
6. 検索が外れたときの振る舞い Advanced RAG で検索品質は上がるが、検索が外れたときにどう振る舞うかは別問題として残る。Naive RAG は検索結果をそのまま信 じてしまう。 User Query Retriever Top-k passages Prompt LLM Answer 検索ミス ⽂脈不⾜ 権限 古い情報 表現違い‧曖昧語で正解⽂ 断⽚だけでは意味‧例外条 ⾒せてはいけない⽂書が混 最新版ではない情報で回答 書を取り逃がす 件が分からない ざる する ⽰唆 問いは2つ。「検索は本当に必要か」「検索結果は使ってよいか」。これを実⾏時に判断させるのが Self-RAG / CRAG。 AIxDevOps © 2026 Scalar, inc. 4 / 76
7. Self-RAG：モデル⾃⾝が制御する 検索が必要なときだけ取得し、取得した根拠や⽣成⽂を⾃⼰評価するアプローチ。検索‧⽣成‧批評の制御をモデルの中に埋め込む。 1. Retrieve? 2. Generate 3. Critique 4. Decide 1. Retrieve? 2. Generate 3. Critique 4. Decide 質問を⾒て検索の要否を判 必要なら根拠を取得して⽣ 根拠の関連性と回答の妥当 使う‧再検索‧回答修正を 断する 成する 性を評価する 選ぶ 出典: Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection（ICLR 2024 / arXiv:2310.11511） AIxDevOps © 2026 Scalar, inc. 5 / 76
8. Self-RAG の3つの原則 1. 検索を常に実行しない LLM の既知知識で十分な場合はスキップする。無駄な検索はレイテンシとコストを 増やすだけでなく、無関係な文書を文脈に混ぜて精度を下げる。 2. 検索結果を無条件に使わない 関連性・支持度・有用性を評価してから使う。前編で見たハードネガティブは、 ここで落とせないと最後まで残る。 3. 回答後も自己評価する 生成した回答が、取得した根拠に実際に支えられているかを確認する。 支えられていない主張（unsupported claim）は書き直すか、保留にする。 Self-RAG は単なるプロンプト改善ではなく、「RAG の実行計画」を 生成プロセスの中に取り込む考え方である。 AIxDevOps © 2026 Scalar, inc. 6 / 76
9. Self-RAG の4つの判断軸 「検索するか」から「回答してよいか」まで。RAG 実⾏時の制御信号を増やすことで、失敗の⼿前で⽌められるようになる。 判断軸 何を⾒るか 業務 RAG での意味 検索要否 この質問は外部知識が必要か 既知‧⼀般知識なら検索しない 関連性 取得⽂書は質問に関係するか 関係ない根拠を捨てる ⽀持度 回答は根拠に⽀えられているか ハルシネーションを抑える 有⽤性 回答は利⽤者の⽬的に役⽴つか 冗⻑‧曖昧な回答を避ける ⽰唆 4軸のうち「⽀持度」は評価指標の Faithfulness と同じもの。実⾏時に測るか、事後に測るかの違いでしかない。 AIxDevOps © 2026 Scalar, inc. 7 / 76
10. CRAG：評価して補正を起動する Corrective RAG は「検索が外れたときにどう回復するか」を明⽰する。⽣成の前に、外付けの評価器で根拠の品質を判定する。 Query Retriever Retrieval Evaluator 信頼度で分岐 Correct Incorrect Ambiguous ⼗分信頼できる 信頼できない ⼀部だけ使える → そのまま利⽤する → 外部検索などで補正する → 分解‧再構成する 出典: Corrective Retrieval Augmented Generation（arXiv:2401.15884） AIxDevOps © 2026 Scalar, inc. 8 / 76
11. 制御をどこに置くかが違う 【Self-RAG】 【CRAG】 モデルの中に、検索‧⽣成‧批評の制御を埋め込む 外付けの評価器で、検索結果の信頼度を判定する ‧検索が必要かを動的に判断する ‧Retriever の出⼒を評価する ‧根拠と回答を⾃⼰評価する ‧Correct / Incorrect / Ambiguous で分岐する ‧専⽤学習や実装設計が重め ‧既存 RAG へ組み込みやすい → 制御信号を学習させる必要があるため、導⼊の初期コスト が⾼い → 既存のパイプラインの間に評価器を1つ挟むだけで始めら れる AIxDevOps © 2026 Scalar, inc. 9 / 76
12. 業務 RAG に⼊れるガードレール 検索品質だけでなく、権限‧鮮度‧根拠性を同時に評価する。評価器は「合っているか」だけでなく「使ってよいか」も⾒る。 Query rewrite Hybrid search Rerank Evaluator Answer（引⽤付 き） 権限フィルタ 鮮度フィルタ 根拠検証 再検索‧棄却 ユーザー‧組織‧案件の属性 有効期間‧版‧承認状態‧更 回答⽂が取得根拠に⽀持され 信頼度が低ければ追加検索、 で検索対象を制限する 新時刻をメタデータ化する ているかを確認する 質問確認、回答拒否へ ⽰唆 4つ⽬の「棄却できること」が業務では最も重要。答えないという選択肢を持たない RAG は、必ずどこかで嘘をつく。 AIxDevOps © 2026 Scalar, inc. 10 / 76
13. CRAG 型からの導入ステップ 専用学習なしで始め、評価ログを蓄積して Self-RAG 的に進化させる。 1. 評価ログを取る 質問、検索結果、最終回答、引用、ユーザー評価を保存する。 2. 検索結果を採点する 関連性・鮮度・権限・支持度をスコア化する。 3. 分岐ルールを入れる 低信頼なら再検索、外部検索、質問確認、回答拒否へ分岐させる。 4. データ基盤で一貫管理する 文書・メタデータ・権限・索引状態を整合させる。 5. 継続評価で改善する 誤答パターンから Query rewrite / Rerank / Evaluator を改善する。 まとめ：RAG は「検索する」から「検索を制御する」へ。 業務 RAG のゴールは「それらしい回答」ではなく、検索根拠・権限・鮮度を説明できる回答。 AIxDevOps © 2026 Scalar, inc. 11 / 76
14. AIxDevOps RAPTOR / GraphRAG 第2章 長文・全体傾向・関係探索に強い RAG AIxDevOps © 2026 Scalar, inc. 12 / 76
15. 断⽚検索では届かない問いがある Chunk 検索だけでは、⻑⽂の要約‧全体傾向‧関係の横断探索に弱い。検索対象を「断⽚」から「構造」へ拡張する必要がある。 Advanced RAG の得意領域 残る課題 構造化 RAG の⽅向性 質問に近い断⽚を探す ⻑⽂の全体像が⾒えにくい RAPTOR：要約の階層⽊ Query rewrite / Hybrid / Rerank で精度を 複数⽂書にまたがる関係を辿りにくい GraphRAG：エンティティ‧関係‧コミュ 上げる 「傾向」や「構造」の質問に弱い ニティ ⽰唆 問いの種類が変わる。「この⽂書の要点は？」「全体として何が⾔える？」「A社とB社の関係は？」「どの論点がどの部署に影 響する？」⸺これらは断⽚を1個取ってきても答えられない。 AIxDevOps © 2026 Scalar, inc. 13 / 76
16. RAPTOR：階層的な要約ツリー Recursive Abstractive Processing for Tree-Organized Retrieval。下位の詳細 Chunk をクラスタリングして LLM で要約し、これを再帰 的に繰り返す。 Root 上位要約 考え⽅ 検索時 ⽂書‧⽂書群の抽象 詳細 Chunk だけで 度別インデックスを なく、上位要約も検 作る 索対象にする クラスタ要約 Chunk（原⽂） 出典: RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval（Sarthi et al., 2024 / arXiv:2401.18059） AIxDevOps © 2026 Scalar, inc. 14 / 76
17. RAPTOR の処理フローと注意点 Indexing と Retrieval の両⽅で抽象度の異なる情報を扱う。Indexing は5⼯程、Retrieval は複数階層から取得する。 1. 分割 2. 埋め込み 3. クラスタ 4. 要約 向いている質問 注意点 設計ポイント ⻑い報告書の要約 要約の誤りが上位に伝播する 階層ごとに引⽤元を保持する 章をまたぐ論点整理 更新時に再構築コストがかかる 要約品質を評価する ⽂書群の⼤きなテーマ把握 原⽂への追跡性が重要になる 差分更新の戦略を持つ 5. 再帰 ⽰唆 最⼤のリスクは「要約の誤りが上位に伝播する」こと。上位ノードは原⽂ではないため、必ず引⽤元を保持して原⽂まで戻れる ようにする。 AIxDevOps © 2026 Scalar, inc. 15 / 76
18. GraphRAG：知識グラフとして検索 ⽂書からエンティティと関係を抽出し、ノード‧エッジの知識グラフを構築する。さらに関連ノードの集まりをコミュニティ化し、要 約を作る。 製品X 顧客B 規制Y 作るもの 答えられる問い エンティティ（⼈‧組 「A社と規制Yの関係 織‧製品‧制約）と は？」 関係のグラフ 「部署Zに影響するリ スクは？」 A社 「全体で頻出する論 点は？」 部署Z リスクR 出典: Microsoft GraphRAG documentation / GitHub, Microsoft Research GraphRAG materials AIxDevOps © 2026 Scalar, inc. 16 / 76
19. GraphRAG の処理フローと検索モード テキスト断⽚ではなく、関係とコミュニティを検索コンテキストにする。構築は4⼯程、検索は3モードを使い分ける。 Raw Text エンティティ抽出 Knowledge Graph Community Detection Community Summaries Global Search Local Search Hybrid / Agentic コミュニティ要約を横断し、全体傾向‧主 特定エンティティ周辺のノード‧エッジ‧ 必要に応じてベクトル検索、グラフ探索、 要テーマ‧⽐較を回答する 原⽂を取得し、関係を深掘りする 原⽂参照を組み合わせる 出典: Microsoft GraphRAG docs: graph extraction, community hierarchy, summaries, global/local search AIxDevOps © 2026 Scalar, inc. 17 / 76
20. RAPTOR と GraphRAG の使い分け 【RAPTOR：⻑⽂‧階層要約に強い】 【GraphRAG：関係探索‧全体傾向に強い】 ‧⽂書∕⽂書群を⽊構造にする ‧知識をノード∕エッジにする ‧抽象度別に検索できる ‧関係経路や近傍探索ができる ‧「章をまたぐ要約」「全体像」に向く ‧「誰が何に影響するか」に向く ‧要約品質と更新コストが課題 ‧抽出精度とグラフ更新が課題 例：200ページの報告書から「結局この案件のリスクは何 か」を答える 例：新しい規制が、どの製品‧どの契約‧どの部署に波及す るかを辿る AIxDevOps © 2026 Scalar, inc. 18 / 76
21. どの RAG を選ぶか（質問から逆算） ⼿法から選ぶのではなく、ユースケースの問いから逆算する。実務では併⽤が多い。 質問の性質 推奨アプローチ 理由 単⼀⽂書の該当箇所を探す Advanced RAG Hybrid search + Rerank で⼗分なことが多い ⻑⽂‧章をまたぐ要約 RAPTOR 抽象度の異なる要約を検索できる 全体傾向‧主要テーマ RAPTOR / GraphRAG 階層要約またはコミュニティ要約が効く ⼈物‧組織‧製品‧リスクの関係 GraphRAG ノード‧エッジで関係を辿れる 権限‧鮮度‧監査が重要 データ基盤 + RAG 索引更新とアクセス制御を⼀貫管理する ⽰唆 順序は「まず Advanced RAG で安定化 → ⻑⽂なら RAPTOR → 関係探索なら GraphRAG」。最初から構造化 RAG を作らない。 AIxDevOps © 2026 Scalar, inc. 19 / 76
22. AIxDevOps Multi-Hop RAG 第3章 複数文書を横断して証拠をつなぐ AIxDevOps © 2026 Scalar, inc. 20 / 76
23. 業務の問いは証拠が分散している 業務の質問は、1つの⽂書‧1つの検索結果だけでは答えられないことが多い。条件‧例外‧契約‧更新履歴‧関係者情報が別⽂書に分 散している。 単純な RAG の前提 実務の質問 Multi-Hop の役割 質問に近い⽂書を上位 K 件取れば、答え 条件、例外、契約、更新履歴、関係者情 途中で得た情報を次の検索条件にし、複 に必要な情報が揃う 報が別⽂書に分散している 数の証拠をつないで回答する 具体例 例：「A社向け契約で、2025年改定後の利⽤上限はどの部署に影響し、例外申請は必要か？」 ‧契約書 → 改定履歴 → 部署別利⽤実績 → 例外申請規程 を順に辿る必要がある AIxDevOps © 2026 Scalar, inc. 21 / 76
24. Naive と Multi-Hop の違い 【Naive RAG】 【Multi-Hop RAG】 User Query → Search → Top-k Docs → Answer Query → Hop 1 検索 → 中間証拠 → Hop 2 再検索 → 証拠統 合 → Answer 検索は1回で終わる。 証拠が揃うまで探索を進める。 弱点： ‧必要な⽂書が上位 K 件に全て⼊らないと、結論が⽋ける 強み： ‧途中で⾒つかった固有名詞や条件を使った追加検索ができ ない ‧検索結果を読み、⾜りない情報を判断し、次の検索を作る AIxDevOps ‧複数⽂書に分散した証拠を1つの回答に統合できる © 2026 Scalar, inc. 22 / 76
25. Multi-Hop が効く6つの質問パターン 複数の事実を組み合わせる質問ほど、単発検索では不⾜しやすい。共通点は「最初の検索結果だけでは、次に探すべき情報が⾒えな い」こと。 パターン 質問の例 辿る経路 ⽐較型 A製品とB製品で2026年契約条件が違う点は？ それぞれの契約‧改定‧価格表を横断 条件連鎖型 この規程の例外に該当する顧客は？ 規程条件 → 顧客属性 → 取引履歴 因果‧影響型 新ルールで影響を受ける部署は？ ルール → 業務プロセス → 部署責任 時系列型 以前の説明と今の仕様の差分は？ 過去資料 → 最新資料 → 変更履歴 エンティティ探索型 A社に関係するリスクと根拠は？ A社 → 関連プロジェクト → リスク台帳 計算‧集約型 対象顧客の利⽤上限超過はいくつ？ 契約条件 → 利⽤ログ → 集計 AIxDevOps © 2026 Scalar, inc. 23 / 76
26. Multi-Hop RAG の基本フロー 分解 → 検索 → 中間判断 → 再検索 → 統合 のサイクル。「検索する → 読む → 次を決める」を必要なだけ繰り返す。 1. 質問分解 2. ⼀次検索 3. 証拠の読解 4. 再検索 5. 証拠統合 1. 分解 2-3. 検索と読解 4. 再検索 5. 統合 質問を⼩さなサブ質問に分解 最初の証拠を検索し、固有名 中間情報を使って次のクエリ 証拠を統合し、引⽤付きで回 する 詞‧条件‧不⾜情報を抽出す を書き換える 答する る 出典: Multi-hop QA literature; ChainRAG / EfficientRAG（iterative / progressive retrieval for multi-hop questions） AIxDevOps © 2026 Scalar, inc. 24 / 76
27. 実装パターン： 6つの部品 LLM に丸投げせず、検索計画・停止条件・証拠管理を明示的に設計する。 1. Query Decomposition 大きな質問をサブ質問に分解する。例：「契約条件」「影響部署」「例外申請」の 3つに分ける。 2. Iterative Retrieval Hop 1 で見つけた Entity や条件を使って、Hop 2 のクエリを書き換える。 3. Graph-guided Search 文書間のリンク、メタデータ、Entity 関係を使い、次に辿る候補を絞る。 4. Evidence Memory 各 Hop で見つけた根拠、未解決のサブ質問、除外した候補を保持する。 5. Stop Condition 十分な証拠が揃ったか、矛盾が残るか、追加検索の価値があるかを判定する。 6. Citation Synthesis 最終回答では、どの文書のどの根拠が、どの結論を支えているかを明示する。 5番の停止条件を持たない実装は、無限ループかコスト超過のどちらかで壊れる。 AIxDevOps © 2026 Scalar, inc. 25 / 76
28. Hop を増やすほど誤差も増える Multi-Hop は万能ではない。Hop を増やすほど、検索範囲だけでなく誤差‧遅延‧権限リスクも増える。 誤った分解 エラー伝播 証拠の⽭盾 ⽂脈肥⼤ 遅延‧コスト 権限漏れ サブ質問に重要 Hop 1 の誤情報 ⽂書間で版や前 複数証拠を⼊れ 検索と LLM 呼 途中で権限外の Entity が落ち、 を前提に Hop 2 提が⾷い違う すぎて LLM が び出しの回数が ⽂書に到達する 後続検索が外れ を検索する 迷う 増える る ⽰唆 対策：各 Hop で「根拠」「不⾜」「⽭盾」「次の検索理由」を記録し、検索前に権限‧鮮度‧メタデータで絞る。 AIxDevOps © 2026 Scalar, inc. 26 / 76
29. 評価は Hop ごとに分解して測る Multi-Hop は「最終回答」だけでは測れない。どの段階で崩れたのかを分解して観測する。 観点 ⾒るべき指標 理由 Question Decomposition サブ質問の妥当性 / Entity 保持率 ここで落ちると後続検索が崩れる Retrieval per Hop Hop 別 Recall / Precision / MRR 必要証拠を各段階で拾えているか Evidence Chain 証拠の接続性 / ⽭盾検出率 複数⽂書の論理がつながっているか Answer Grounding 引⽤⼀致率 / 根拠網羅率 回答が証拠に⽀えられているか Operation Latency / Cost / 権限違反ゼロ 本番で継続運⽤できるか ⽰唆 最終回答の正答率だけを⾒ていると、「Hop 1 は完璧だが Hop 2 で崩れている」といった構造が⾒えない。 AIxDevOps © 2026 Scalar, inc. 27 / 76
30. Multi-Hop の導入ロードマップ 最初から複雑な Agent にせず、横断が必要な問いを選んで段階導入する。 Phase 1 質問分類 単発検索で足りる問いと、複数 Hop が必要な問いを分ける。 まず問い合わせログを分類し、 Multi-Hop が必要な割合を測る。 Phase 2 2-Hop の PoC 契約 → 利用実績、規程 → 例外条件など、限定パターンで検証する。 Phase 3 Planner 強化 分解、再検索、停止条件、証拠メモリを実装する。 Phase 4 本番運用 権限・鮮度・監査・索引状態を一貫して管理する。 目標：複数文書に分散した証拠を、権限を守りながら、引用付きで一貫した回答にする。 一言で言うと： Multi-Hop RAG は「検索結果を読む → 次に何を探すか決める → 証拠をつなぐ」 RAG。 AIxDevOps © 2026 Scalar, inc. 28 / 76
31. AIxDevOps Agentic RAG 第4章 RAG as Tool と Planner / Router / Retriever / Verifier AIxDevOps © 2026 Scalar, inc. 29 / 76
32. Agent 視点で RAG を再定義する RAG は「LLM の前処理」ではなく、Agent が使う信頼できる情報アクセス層になる。 ・従来 RAG ― 質問 → 検索 → 文脈投入 → 回答（固定手順） ・Agentic RAG ― Agent が「検索するか」を判断する ・RAG as Tool ― 検索・要約・引用を再利用可能な道具にする 【見るべき論点】 1. Agent はいつ RAG を呼ぶべきか 2. RAG Tool の入出力契約をどう設計するか 3. 権限・鮮度・根拠・評価をどこで担保するか この3つを決めないまま Agent に検索させると、過剰検索・文脈汚染・権限漏れが 同時に起きる。Tool の設計が Agent の品質を決める。 AIxDevOps © 2026 Scalar, inc. 30 / 76
33. パイプラインから Tool へ 【Pipeline RAG】 【RAG as Tool】 User Query → Retriever → Prompt → Answer Agent が Search Docs / Search DB / Verify Evidence / Summarize を選んで呼ぶ 固定⼿順。単純な Q&A では速いが、複雑タスクでは過剰検 索‧⽂脈汚染が起きやすい。 Agent が必要な Tool を選び、結果を検証し、⾜りなければ再 検索する。 ‧検索するかどうかを選べない ‧検索結果を検証する場所がない ‧検索の要否を Agent が判断する ‧失敗しても再試⾏できない ‧複数 Tool の順序を制御できる ‧失敗時に別 Tool へ切り替えられる AIxDevOps © 2026 Scalar, inc. 31 / 76
34. 実⾏ループでの RAG Tool の位置 Agent の実⾏ループは5段階。RAG Tool はそのうち「Call Tool」に⼊るが、返すべきものは検索結果そのものではない。 1. Plan 2. Decide 3. Call Tool 4. Check RAG Tool が返すべきもの Agent が担うべきもの 検索結果そのものではなく「使える証拠」 検索するかどうかの判断 出典、更新⽇時、権限、信頼度、引⽤可能範囲 複数 Tool の順序制御 ⾜りない情報や不確実性 回答に使う根拠の取捨選択 5. Act / Answer 追加検索‧確認‧⼈間確認への分岐 AIxDevOps © 2026 Scalar, inc. 32 / 76
35. RAG Tool の⼊出⼒契約 【Input Contract】 【Output Contract】 ‧query — 検索したい内容 ‧filters / tenant / ACL — 誰として検索するか ‧time range / freshness — いつ時点の情報か ‧topK / rerank policy — どれだけ、どう並べるか ‧required evidence level — どこまでの根拠が必要か ‧answer draft / summary — 回答案または要約 ‧evidence chunks — 根拠となるチャンク ‧citations / source IDs — 引⽤と出典 ID ‧confidence / caveats — 信頼度と留保 ‧permission trace — どの権限で何を⾒たか 呼び出し側が「誰として、いつ時点で、どこまで確実な情報が 欲しいか」を渡せる形にする。 重要：Tool の責務は「検索」だけではない。Agent が安全に判 断できるメタデータを返すことが価値。 AIxDevOps © 2026 Scalar, inc. 33 / 76
36. 3つの代表パターンの使い分け 判断基準：ユーザー質問が「答え」だけを求めるなら単純 RAG。「調べて、⽐較して、実⾏して、説明する」なら RAG as Tool。 ⽅式 向く⽤途 強み 注意点 単純 RAG FAQ‧単⼀⽂書検索 速い / 実装容易 複雑タスクに弱い Agentic RAG 調査‧分析‧判断 必要時だけ検索する 制御と評価が難しい RAG as Tool 業務 Agent の情報アクセス 再利⽤‧権限制御しやすい Tool 契約設計が必要 ⽰唆 3つは排他ではない。同じシステムの中で、FAQ 系は単純 RAG、調査系は Agentic RAG、と経路を分けるのが現実的。 AIxDevOps © 2026 Scalar, inc. 34 / 76
37. Enterprise RAG as Tool Agent が複数の Tool を持つほど、共通の統制層が必要になる。権限‧鮮度‧監査を各 Tool に散らさず、Governance Layer に内蔵す る。 Doc RAG SQL Tool Graph RAG API Tool PDF / Wiki 業務 DB 関係探索 SaaS Governance Layer 認証 / 認可 / テナント分離 / マスキング / 監査ログ / レート制限 ⽰唆 統制を Tool ごとに実装すると、必ずどこかで抜ける。Tool の下に共通層を1枚敷く。 AIxDevOps © 2026 Scalar, inc. 35 / 76
38. Agentic RAG は何を変えるのか 【従来 RAG】 【Agentic RAG】 ‧質問をそのまま検索する ‧⽬的を分解する ‧上位チャンクを投⼊する ‧検索先を選ぶ ‧LLM が回答する ‧結果を検証する ‧失敗しても再探索しにくい ‧不⾜時に再計画する 【Advanced RAG】 【本質】 ‧Query rewrite 固定的な「検索 → 回答」から、判断を含む「計画 → 検索 → 検証 → 再実⾏」へ。 ‧Hybrid search ‧Rerank ‧検索精度を⾼める AIxDevOps RAG を「検索機能」から「意思決定を持つ情報探索プロセ ス」へ拡張する。 © 2026 Scalar, inc. 36 / 76
39. 全体アーキテクチャ：4つの役割 Planner、Router、Retriever、Verifier が役割分担し、状態を持って探索する。不⾜‧⽭盾があれば Planner に戻って再計画する。 User Question Planner Router Retriever Verifier Answer 状態管理 ツール群 計画、検索履歴、根拠、評価結果、再試⾏回数を保持する ベクトル検索、BM25、SQL、Web、社内 API、グラフ検索 ⽰唆 この4つを1つの LLM プロンプトに混ぜないこと。役割を分けておくと、どこが失敗したかを切り分けられる。 AIxDevOps © 2026 Scalar, inc. 37 / 76
40. Planner：探索計画に変換する 複雑な質問ほど、先に検索戦略を立てることで取りこぼしを減らせる。 【Planner の役割】 ・質問意図を分類する（事実確認 / 比較 / 手続き / 集計） ・サブクエリに分解する ・必要な情報源を想定する ・検索順序と終了条件を決める 【例：業務質問】 「A製品の最新 SLA と契約上の例外条件を踏まえ、顧客 X に適用されるか？」 1. 最新 SLA を確認する 2. 契約例外を確認する 3. 顧客 X の契約条件を確認する Planner がない場合： 1回の検索結果に依存し、必要な文書を横断しにくい。 AIxDevOps © 2026 Scalar, inc. 38 / 76
41. Router：どこを検索するかを選ぶ すべてを同じ検索器に投げるのではなく、質問に応じて最適な経路へ振り分ける。Router は検索品質とコスト‧レイテンシ‧権限を同 時に制御する。 ⽂書検索 構造化検索 外部‧更新情報 PDF、規程、議事録、FAQ 顧客 DB、契約 DB、権限 DB Web、API、ナレッジ更新 質問タイプ データ鮮度 権限 コスト 事実確認‧⽐較‧集計など 固定⽂書か、最新情報か 参照可能な範囲か ⾼価な検索をいつ使うか ⽰唆 Routing の判断軸は4つ。権限を Router に持たせると、そもそも⾒えない領域は検索対象にならない。 AIxDevOps © 2026 Scalar, inc. 39 / 76
42. Retriever：道具箱として扱う Agentic RAG では Retriever を単⼀の検索器ではなく「道具箱」として扱う。質問の性質に応じて使い分ける。 Vector / Embedding BM25 / Keyword SQL / Graph / API 意味的に近い⽂章を探す 製品名‧型番‧条⽂番号に強い 構造化データを正確に取得する ⾔い換え‧類似概念に強い 表記ゆれや同義語には弱い 関係探索や集計に強い 固有名詞‧数値条件は弱い場合あり ⽇本語では Analyzer 設計が重要 ツール呼び出しの検証が必要 ⽰唆 実務では「Hybrid search + Rerank + Metadata / ACL filter」が基本形。前編で作ったものが、そのまま道具箱の1つになる。 AIxDevOps © 2026 Scalar, inc. 40 / 76
43. Verifier：信⽤してよいか判定する Agentic RAG の品質は「取ってきた情報を疑う」⼯程で⼤きく変わる。Verifier は Self-RAG / CRAG の判断をアーキテクチャ化したも の。 検索結果の検証 回答の検証 再実⾏判断 質問に答える根拠が含まれるか 主張ごとに出典があるか 追加検索する 古い⽂書や重複が混ざっていないか 数値‧⽇付‧条件を取り違えていないか 別 Retriever に切り替える 権限外‧機密情報が混⼊していないか 根拠不⾜なら「不明」と⾔えるか Planner に戻って質問を分解する ⽰唆 Verifier がない Agentic RAG は、ただ「よく検索する Naive RAG」でしかない。検証こそが⾃律化の前提条件。 AIxDevOps © 2026 Scalar, inc. 41 / 76
44. 制御ループと終了条件 ⼀度の検索で答えを出すのではなく、証拠の不⾜を検知して探索を続ける。重要なのは、失敗したときに戻れること。 1. 計画 2. 経路選択 6. 不⾜検知 3. 検索 4. 検証 7. 再検索 5. 回答⽣成 8. 再計画（Planner へ戻る） 終了条件 1 終了条件 2 終了条件 3 終了条件 4 ⼗分な根拠が集まった 最⼤試⾏回数に達した コスト上限に達した ユーザー確認が必要 AIxDevOps © 2026 Scalar, inc. 42 / 76
45. 実装パターンと避けたい設計 【Step 1：決定的な RAG】 Hybrid search / Rerank / 出典付き回答 / 評価セット作成 【避けたい設計】 【Step 2：限定 Agent 化】 Planner で質問分解 / Router で検索先選択 / Verifier で根拠 チェック / 失敗時のみ再検索 ‧無制限ループ（停⽌条件がない） ‧全ツール常時実⾏（コストとノイズが増える） ‧根拠なし⽣成（引⽤を必須にしていない） ‧権限チェック後付け（設計に組み込んでいない） 【Step 3：業務統合】 権限制御 / 監査ログ / コスト管理 / ⼈間承認 / データ基盤で整合 性管理 【PoC のコツ】 「再検索が必要なケース」を先に明確にし、Verifier の評価指標 から作る。 最初から完全⾃律にせず、制御可能なワークフローとして始め る。 AIxDevOps © 2026 Scalar, inc. 43 / 76
46. 評価は4層に分けて測る RAG 単体ではなく、Agent のタスク完了まで測る。検索が良くても、Tool 選択を誤ればタスクは完了しない。 Retrieval Grounding Agent Business Recall@K / MRR 引⽤⼀致率 Tool 選択精度 タスク完了率 Rerank 精度 Unsupported claim 率 不要 Tool 呼び出し率 ⼈間確認の削減 重複‧ノイズ率 根拠の新鮮度 再検索成功率 監査対応時間 ⽰唆 評価データは「実業務質問‧正解⽂書‧期待 Tool‧許容回答‧禁⽌回答」をセットで管理する。禁⽌回答を持つのが業務 Agent の要件。 AIxDevOps © 2026 Scalar, inc. 44 / 76
47. AIxDevOps MCP と RAG 第5章 外部ツール接続標準としての位置づけ AIxDevOps © 2026 Scalar, inc. 45 / 76
48. MCP は RAG をツール化する層 結論：MCP は RAG を「ツール化」する標準接続層である。 RAG は知識取得、MCP は外部資源・外部操作への共通インターフェース。 ・RAG の役割 業務文書・データから根拠を取り出し、回答に必要な文脈として渡す。 ・MCP の役割 AI アプリが外部データ、アプリ、サービス、ツールへ接続するための標準プロトコル。 ・Agent の役割 タスクに応じて「検索する」「DB を見る」「API を呼ぶ」を選択し、結果を統合する。 RAG as Tool = Retriever / Search / Evidence を、 Agent が呼び出し可能な道具にすること。 MCP はその「呼び出し方」を標準化する。 AIxDevOps © 2026 Scalar, inc. 46 / 76
49. RAG と MCP は責務が違う RAG は「何を根拠に答えるか」、MCP は「どう外部と接続するか」。競合ではなく、担当する層が違う。 観点 RAG MCP 主⽬的 知識取得‧根拠提⽰ 外部ツール接続の標準化 対象 ⽂書、表、DB、ログ、ナレッジ ファイル、DB、SaaS、API、コード実⾏ 出⼒ 検索結果‧抜粋‧根拠 Tool call の結果‧リソース‧プロンプト 設計論点 検索品質、分割、評価、権限 接続仕様、認証、権限、監査 ⽰唆 実装では、RAG 検索器を MCP Server の tool として公開し、Agent が必要な時に呼び出す構成が⾃然になる。 AIxDevOps © 2026 Scalar, inc. 47 / 76
50. N×M の個別接続をやめる 【Before】 【After】 Agent A → DB / SaaS / Search Agent B → DB / SaaS / Search Agent → MCP → Tools / Data 共通プロトコルで接続境界を統⼀する。 Agent の数 × ツールの数だけ個別コネクタが必要になる。 ‧接続仕様がばらばら ‧認証‧認可の実装が重複する ‧ツールを⾜すたびに全 Agent を直す ‧道具の呼び出し⽅がそろう ‧Agent と外部資源の境界が安定する ‧ツールを⾜しても Agent 側は変えなくてよい 境界のポイント：MCP は「道具の呼び出し⽅」をそろえる。 RAG の検索品質‧権限設計は別途作り込む。 AIxDevOps © 2026 Scalar, inc. 48 / 76
51. RAG を MCP Tool として公開する Agent は tool registry を⾒て、必要な検索‧取得‧操作を選ぶ。標準アーキテクチャは3層になる。 User AI Agent（Planner / Router） MCP Server Vector / DB / SaaS MCP Server（RAG Search Tool） MCP Server（Action Tools） 検索‧根拠取得‧引⽤⽣成を tool として公開する 業務システムへの更新‧起票‧ワークフロー起動を公開する ⽰唆 検索系 tool と操作系 tool は Server を分ける。破壊的操作を持つ Server は、許可制と確認フローを別に設計できる。 AIxDevOps © 2026 Scalar, inc. 49 / 76
52. Agent から見た処理フロー RAG は「常に実行」ではなく、計画に応じて呼び出すtool になる。 1. 理解 — 依頼内容、制約、必要な根拠を整理する 2. 選択 — RAG / DB / SaaS / API のどれを呼ぶか決める 3. 取得 — MCP 経由で検索・参照・実行する 4. 検証 — 根拠の十分性、矛盾、権限を確認する 5. 統合 — 回答、次アクション、証跡を生成する 【2つの転換】 ・RAG as Tool ― 「検索してから回答」ではなく「必要なら検索する」へ ・MCP as Standard ― 個別実装の tool calling を共通プロトコルで扱う 5段階のうち「4. 検証」を飛ばすと、標準化されたぶんだけ速く間違える。 AIxDevOps © 2026 Scalar, inc. 50 / 76
53. MCP 化する RAG Tool の設計 「検索 API」を1つ公開するのではなく、Agent が使いやすい粒度で道具を分ける。粒度が粗いと Agent が正しく選べない。 search_knowledge get_evidence verify_answer request_action 質問に関連する候補⽂書‧表 ⽂書 ID‧ページ‧セル範囲か 回答案と根拠を照合し、未根 権限確認後、チケット作成 ‧FAQ を検索する。Top-k、 ら根拠を取得する。引⽤可能 拠‧⽭盾‧不⾜を返す ‧DB 更新‧ワークフロー起動 フィルタ、権限条件を受け取 な形で返す へ接続する る ⽰唆 検索結果は「本⽂」だけでなく、出典‧権限‧鮮度‧信頼度‧取得条件を含めて返す。第4章の Output Contract と同じ。 AIxDevOps © 2026 Scalar, inc. 51 / 76
54. 既存 RAG を MCP 対応に広げる 最初から大規模に作らず、既存の検索API の前に MCP Server を1枚置く。 1. 既存 RAG API 検索・取得・引用生成を API として整理する 2. MCP Server RAG API を tool として公開し、schema と説明を定義する 3. Agent / Host Planner が tool を選択し、結果を文脈に取り込む 4. 評価・運用 検索ログ、tool call、回答根拠を監査・改善する Transport はローカル開発なら stdio、本番連携なら HTTP / remote など、 運用境界に合わせて選ぶ。 AIxDevOps © 2026 Scalar, inc. 52 / 76
55. MCP × RAG の代表ユースケース ・社内ナレッジ回答 規程・設計書・議事録を RAG 検索し、必要なら Slack / Jira / CRM へ展開する ・開発支援 Agent コード検索、仕様確認、Issue 作成、テスト実行を MCP tool として統合する ・データ分析 Agent DB・BI・ログ検索から仮説検証し、根拠つきレポートを生成する ・業務ワークフロー 契約・購買・承認などを、根拠確認後に外部システムへアクションする ・監査・コンプライアンス 回答根拠と tool call 履歴を残し、後から説明できるAgent にする 共通するのは「RAG が調べる、MCP が接続する、Agent が進める」という役割分担。 AIxDevOps © 2026 Scalar, inc. 53 / 76
56. AIxDevOps セキュリティ 第6章 Prompt Injection、権限漏れ、監査 ! AIxDevOps © 2026 Scalar, inc. 54 / 76
57. 安全に検索できることが要件になる RAG は「検索できる」だけでなく「安全に検索できる」ことが要件になる。守るべき対象と設計⽅針を先に決める。 主要リスク 守るべき対象 設計⽅針 Prompt Injection による意図しない指⽰実 検索対象データ ⼊⼒防御 ⾏ 権限‧属性情報 最⼩権限 機密⽂書の権限漏れ プロンプトとツール呼び出し 検索前後の検証 監査証跡不⾜で事故原因が追えない 出⼒と引⽤ 監査ログの完全性 ⽰唆 LLM のガードレールだけでは不⼗分。検索基盤と監査基盤も含めて守る。権限と出典は常に⼀緒に扱う。 AIxDevOps © 2026 Scalar, inc. 55 / 76
58. RAG の攻撃⾯は4つある 攻撃⾯（Attack Surface）は⼊⼒‧検索‧⽣成‧運⽤の4⾯。どこか1⾯だけを守っても意味がない。 ⾯ 含まれるもの 起こりやすい問題 ⼊⼒⾯ ユーザー質問、外部 URL / 添付、会話履歴 悪意ある⽂書が指⽰を埋め込む 検索⾯ インデックス、メタデータ、権限制御の⽋落 閲覧権限のない⽂書が混ざる ⽣成⾯ プロンプト合成、ツール実⾏、引⽤⽣成 出⼒は正しいが根拠が不正 運⽤⾯ ログ、監査、更新整合性 事故時に再現できない ⽰唆 必要な制御は「⼊⼒の隔離」「検索時フィルタ」「出⼒前検証」「改ざん耐性のある監査」の4つ。⾯ごとに対応する。 AIxDevOps © 2026 Scalar, inc. 56 / 76
59. 1. Prompt Injection：2つの型 RAG では、取得文書の中に「モデルへの指示」が混入する可能性がある。 ・直接型 ユーザーが「前の指示を無視して…」と入力する ・間接型 Web ページ / PDF / メモに埋め込まれた指示が、検索経由で注入される ・被害 追加ツール呼び出し、内部プロンプト漏えい、誤回答、権限逸脱 RAG で特に危険なのは間接型。ユーザーは何も悪いことをしていないのに、 検索してきた文書に仕込まれた指示が実行されてしまう。 Agentic RAG では検索結果からツール呼び出しまで繋がっているため、被害が大きい。 AIxDevOps © 2026 Scalar, inc. 57 / 76
60. Prompt Injection への対策 要点：「検索結果 = 信頼できる命令」ではない。 【対策の基本】 ・命令とデータを分離する ・取得文書は「参考情報」であり命令ではないと明示する ・危険なツールは明示的な許可制にする 【実装例】 ・プロンプト中で retrieval context を非命令扱いにする ・HTML・PDF から script / hidden text / URL 指示を除去する ・Verifier で危険な出力やツール要求をブロックする 取り込み時（Ingestion）の除去と、実行時（Runtime）の検査を両方行う。 AIxDevOps © 2026 Scalar, inc. 58 / 76
61. 2. 権限漏れ（Permission Leakage） 最も深刻なのは「検索では⾒えてしまい、回答で漏れる」事故。要約や再ランキングの途中で、本来⾒せてはいけない⽂書が混ざるこ ともある。 原因の例 必要な粒度 インデックスに権限メタデータがない 部⾨‧案件‧顧客‧個⼈情報の単位で stale index（索引が古い） 細粒度に制御する ACL 同期漏れ 検索前 検索中 検索後 認証‧属性取得を⾏う namespace / table / record / tag レベルで 再ランキング前後でも権限を再確認する フィルタする AIxDevOps © 2026 Scalar, inc. 59 / 76
62. 3. 監査（Audit / Traceability） 【なぜ必要か】 【監査で⼤事なこと】 ‧情報漏えい事故の原因究明 ‧回答根拠の再現 ‧後から消せない / 変えられないこと ‧内部不正‧改ざんの検知 ‧時系列が追えること ‧規制‧監査対応 ‧権限変更やインデックス更新も追えること 【最低限残すもの】 監査ログは「ある」だけでなく「真正である」ことが重要。 ‧質問内容とユーザー ID ‧利⽤した⽂書 ID / 版 / ページ ‧検索結果の順位 書き換え可能なログは、事故のときに証拠として使えない。 ハッシュ保全や台帳化を検討する。 ‧出⼒本⽂と引⽤ ‧ツール呼び出し結果 AIxDevOps © 2026 Scalar, inc. 60 / 76
63. セキュア RAG の参照アーキテクチャ 設計原則は4つ。⾮信頼⼊⼒を前提にする∕検索時に最⼩権限を徹底する∕回答前に検証する∕監査ログの真正性を担保する。 Ingestion / Indexing Input Guard Retriever LLM Verifier Ingestion Runtime Data & Audit ⽂書取り込み Input Guard（PI 検知‧正規化） 監査ストア PDF / OCR 正規化 Retriever（ACL filter‧Hybrid） 質問‧根拠‧出⼒ 危険要素の除去 LLM（Context 分離‧引⽤⽣成） 検証結果 権限メタデータ付与 AIxDevOps Audit ハッシュ / 署名 © 2026 Scalar, inc. 61 / 76
64. レイヤー別の実装チェックポイント レイヤーごとにリスクと推奨コントロールを対応づける。設計レビューのチェックリストとして使う。 レイヤー 主なリスク 推奨コントロール Ingest 悪性⽂書混⼊ サニタイズ、OCR 補正、分類、権限タグ付け Index 権限同期漏れ ACL メタデータ、再索引⼿順、版管理 Retrieve 越権検索 属性ベースフィルタ、namespace / table / record 制御 Generate PI / 幻覚 命令とデータの分離、Verifier、引⽤必須 Audit 改ざん‧⽋落 不可逆ログ、検証⽤ハッシュ、時系列追跡 ⽰唆 導⼊は5段階。可視化（分類‧権限モデル‧監査要件）→ 最⼩権限 → 防御強化 → 真正監査 → 継続評価（Red Team‧権限テス ト）。 AIxDevOps © 2026 Scalar, inc. 62 / 76
65. AIxDevOps 評価 第7章 RAG Triad、RAGAS、ARES AIxDevOps © 2026 Scalar, inc. 63 / 76
66. 評価は採点ではなく観測設計 RAG 評価は「回答がそれっぽいか」ではなく、失敗箇所を分解して測る。LLM 単体の評価では、検索起因の失敗を⾒分けられない。 よくある失敗 評価で切り分ける 改善に使う 検索漏れ：正解根拠が Top-k にない Retriever の問題か モデル‧Embedding ⽐較 検索ノイズ：無関係な⽂書が混ざる Chunking の問題か BM25 / Hybrid / Rerank ⽐較 根拠無視：正しい⽂書があるのに別回答 Rerank の問題か チャンクサイズ最適化 質問逸脱：⾃然だが質問に答えていない Prompt / LLM の問題か リリース前の回帰テスト 権限‧鮮度の問題か 本番ログから golden set 化 ⽰唆 評価は「採点」ではなく、改善ループを回すための観測設計。総合点が1つ出ても、次に何を直せばよいかは分からない。 AIxDevOps © 2026 Scalar, inc. 64 / 76
67. RAG 評価の全体像は3層 Retriever 評価、Generator 評価、System 評価の3層に分ける。RAGAS / ARES / RAG Triad は主に上2層を分解して測る。 Retriever 評価 Generator 評価 System 評価 Context Recall Faithfulness / Groundedness Task Success Context Precision Answer Relevance Latency / Cost MRR / nDCG Citation Accuracy Safety / Policy → Top-k に正解根拠が⼊るか → 根拠に沿って答えるか → 業務タスクとして成⽴するか ⽰唆 3層のうち System 評価だけが業務価値に直結する。ただし上2層が測れていないと、System が悪いときに直し⽅が分からない。 AIxDevOps © 2026 Scalar, inc. 65 / 76
68. RAG Triad：3観点で切り分ける Question / Context / Answer の3点間を、3つの関係で評価する。ground truth がなくても診断しやすいのが利点。 Question（ユーザーの質問） Context（検索された根拠） Answer（⽣成された回答） Context Relevance Groundedness Answer Relevance 質問に対して、検索された⽂脈は関連し 回答は検索⽂脈に⽀えられているか 回答は質問に答えているか ているか ⽰唆 どれが低いかで直す場所が決まる。Context Relevance なら検索、Groundedness なら Prompt / Verifier。 AIxDevOps © 2026 Scalar, inc. 66 / 76
69. RAGAS：OSS で体系的に評価する RAGAS は、RAG パイプラインを reference-free に評価する枠組みとして提案された。 現在のドキュメントでは、LLM アプリの評価ループを体系化するライブラリとして説明されている。 質問・回答・検索文脈・必要に応じて正解を使い、検索品質と生成品質を指標化する。 【代表指標（生成側）】 ・Faithfulness：回答が文脈に忠実か ・Answer Relevancy：質問に答えているか 【検索系指標】 ・Context Precision：関連文脈が上位にあるか ・Context Recall：必要根拠を取得できたか ・Context Relevancy：文脈が質問に関係するか 【使いどころ】 PoC 比較、チャンク / Embedding / 検索方式の A/B、リリース前の回帰テスト 注意点：LLM Judge を使うためコストとばらつきがある。閾値運用は別途設計する。 AIxDevOps © 2026 Scalar, inc. 67 / 76
70. ARES：評価そのものを⾃動化する Automated RAG Evaluation System。⼈⼿アノテーションを最⼩化して RAG を評価する。合成データと軽量 Judge、少量の⼈⼿ラベル を組み合わせる。 Synthetic Data Few Human Labels LM Judges PPI Scores 評価軸 強み 注意点 Context Relevance ⼤量評価を⾃動化しやすい Judge の学習‧評価設計が必要 Answer Faithfulness ドメインシフトにも対応しやすい設計 少量でも⼈⼿ラベルは重要 Answer Relevance ⽰唆 PPI（Prediction-Powered Inference）で、少量の⼈⼿ラベルから全体の品質を統計的に推定する。⼤規模評価基盤向け。 AIxDevOps © 2026 Scalar, inc. 68 / 76
71. 3フレームワークの使い分け 3つは競合ではなく、⽬的と規模で使い分ける。設計レビューには Triad、⽇次評価には RAGAS、⼤規模基盤には ARES。 観点 RAG Triad RAGAS ARES 主⽬的 失敗箇所の理解 OSS 指標で定量評価 評価の⾃動化‧⼤規模化 必要データ 質問‧⽂脈‧回答 質問‧回答‧⽂脈‧任意で正解 合成データ + 少量⼈⼿ラベル 強み シンプルで説明しやすい PoC / 回帰テストに使いやすい Judge を適応させやすい 注意点 スコア運⽤は別途設計 LLM Judge のコスト / ばらつき 導⼊の設計負荷が⾼い 向く場⾯ 設計レビュー ⽇次 / リリース評価 ⼤規模評価基盤 AIxDevOps © 2026 Scalar, inc. 69 / 76
72. 評価セット設計：日本語で特に重要 ・実際の業務質問を 50〜200 件から始める ・正解根拠は文書 ID・版・ページ・表／セル位置まで付与する ・表記ゆれ、略語、固有名詞、英日混在、古い版の文書を含める ・「正解がない / 権限上答えてはいけない」質問も含める ・自動評価だけでなく、人手レビューで校正する 【Golden Set の単位】 Question ／ Expected evidence ／ Expected answer or refusal ／ Required policy 【日本語固有の観点】 形態素解析の差分 ／ 表記ゆれ ／ PDF・表の抽出品質 ／ 引用ページの正確性 【運用ルール】 本番ログから定期的に追加し、リリース前に回帰テストする。 4番目の「答えてはいけない質問」を必ず入れること。これがないと、 棄却できない RAG を「精度が高い」と誤って評価してしまう。 AIxDevOps © 2026 Scalar, inc. 70 / 76
73. 評価を改善ループに組み込む RAG は⽂書更新‧権限変更‧モデル変更で劣化する。継続評価が前提であり、⼀度測って終わりではない。 Collect Label Evaluate Diagnose 閾値設計 リリースゲート Context Recall が低いなら検索を改善 前回版より悪化しない Faithfulness が低いなら Prompt / Verifier を改善 重要質問の正答率を維持する Answer Relevance が低いなら質問理解を改善 禁⽌回答はゼロ許容 Improve Release Gate ⽰唆 評価指標は「⼀つの総合点」ではなく、原因別のダッシュボードとして扱う。失敗分類（検索漏れ‧ノイズ‧根拠⽭盾‧回答逸 脱‧古い情報‧権限違反）で並べる。 AIxDevOps © 2026 Scalar, inc. 71 / 76
74. 本番運⽤を⽀える2つの基盤 後編で繰り返し出てきた「権限‧鮮度‧整合性」と「監査の真正性」は、検索アルゴリズムでは解けない。データ層で担保する。 ScalarDB — 安全に取る ScalarDL — 正しく記録し証明する 異種 DB を仮想統合し、認証‧暗号化‧レコードレベルのアクセス制御を データの真正性‧履歴追跡‧改ざん検知を強化する分散台帳ソフトウェア 提供する validate-ledger により、記録されたデータや台帳状態を検証できる ⽂書メタデータ‧権限情報‧更新トランザクションを複数 DB 横断で⼀貫 ⾼リスク回答のみ台帳化し、⽂書原本ハッシュ‧回答ハッシュ‧参照⽂書 管理しやすい ID を記録する Retriever の metadata filter を、業務上の属性‧タグ‧案件 ID と整合させ やすい ⽰唆 役割分担は「ScalarDB = 安全に取る∕ScalarDL = 正しく記録し証明する」。なお Prompt Injection そのものを防ぐ製品ではな い。 AIxDevOps © 2026 Scalar, inc. 72 / 76
75. 設計原則（ 1）検索を強くする RAG は「検索して生成する機能」から「信頼できる情報アクセス基盤」へ進化する。 【検索品質を高める】 ・Naive RAG から Advanced RAG へ ・Query rewrite / Hybrid search / Rerank で検索漏れとノイズを減らす ・正しい根拠が Top-k に入るかを継続評価する 【日本語・実文書に強くする】 ・GiNZA / Sudachi / kuromoji で前処理と Analyzer を設計する ・BM25 + Embedding + Rerank を基本形にする ・PDF・表・表記ゆれ・固有名詞を評価セットに含める AIxDevOps © 2026 Scalar, inc. 73 / 76
76. 設計原則（ 2）検索を制御する 【複雑な問いに答える】 ・Self-RAG / CRAG で検索要否と根拠の信頼性を判断する ・Multi-Hop / RAPTOR / GraphRAG で複数文書・長文・関係探索を扱う ・証拠の不足や矛盾を検知し、再検索する 【信頼して運用する】 ・Agentic RAG は Planner / Router / Retriever / Verifier で構成する ・RAG を MCP tool として公開し、Governance Layer で統制する ・Prompt Injection、権限漏れ、監査を設計に含める ・RAGAS / ARES / RAG Triad で改善ループを回す 業務 RAG のゴールは「それらしい回答」ではなく、説明できる回答。 AIxDevOps © 2026 Scalar, inc. 74 / 76
77. 明日から着手できること 大きく作らず、測れるところから始める。 1. 問い合わせログを分類する 単発検索で足りる問いと、複数 Hop が必要な問いの比率を測る 2. 評価セットを 50 件作る 実業務の質問、正解根拠（文書ID・版・ページ）、答えてはいけない質問を含める 3. 既存 RAG API を 1〜2 個の MCP tool として公開する Agent の tool 選択・根拠提示・監査ログを評価する 4. CRAG 型の外付け評価器を1つ挟む 検索結果の信頼度を判定し、低ければ再検索・棄却へ分岐させる 5. 監査ログの項目を決める 質問・ユーザー ID・文書 ID / 版 / ページ・順位・出力・引用・tool call 順序が大事。2 がないと 1・3・4 の効果を測れない。 AIxDevOps © 2026 Scalar, inc. 75 / 76
78. Please give us a star on GitH ub! udy AIxDevOps St 毎週⽕曜開催 GitHub scalar-labs/scalardb connpass Scalar AIxDevOps © 2026 Scalar, inc.