Agentic RAGとは？Microsoft Foundryで検索と判断を分ける考え方

複数資料を扱う検索設計

AIを導入しても、答えの根拠が分からない、古い資料を参照する、誰が最終確認するか決まっていない状態では、現場は安心して使えません。Microsoft Foundryは、モデルを試すだけの場所ではなく、社内データ、AIの回答、評価、運用ログをつなぎ、業務で使える形に整えるための基盤です。

この記事では、技術用語を増やすことよりも、業務担当者が何を決め、どこで専門担当と連携すればよいかを重視します。導入の目的は「AIにすべてを任せること」ではなく、必要な情報を集め、判断しやすい状態をつくることです。

最初に決める4つのこと

目的が広すぎると、必要な資料も評価基準も増えます。最初は質問の範囲を一つに絞り、回答が役に立ったかを確認できる業務から選びます。たとえば「社内規程を探す」「引き継ぎ内容を整理する」のように、正解の根拠がある仕事が向いています。

Microsoft Foundryを使う前に確認すること

• 参照させる資料の最新版と更新担当
• 資料ごとの閲覧権限と、AIに渡してよい情報の範囲
• 回答に出典を表示する方法と、分からないときの案内
• テストする質問、誤答と判断する基準、確認の担当者
• 利用量、ログ、エラーを確認する頻度と停止条件

資料を大量に入れることは、品質の保証ではありません。重複した古い資料や、権限の異なる資料を混ぜると、回答の根拠を判断しにくくなります。まず対象資料を一覧にし、更新日、責任者、利用可否を確認します。

活用例

製品仕様、在庫ルール、社内手順を参照して回答候補を作る場合に、どの資料を使ったか残す方法を考えます。

このような仕組みでは、AIは資料を検索し、要点と根拠を示す役割にとどめます。回答を外部へ送る、例外を承認する、個人情報を含む内容を判断するといった行為は、人が行います。AIが答えられないときは、無理に推測させず、担当窓口や元資料を示す設計が安全です。

実装の流れ

1. 現場で繰り返し発生する質問や確認作業を集め、最初の対象を一つ選びます。
2. 参照してよい資料を選別し、更新日・責任者・閲覧範囲を確認します。
3. AIの出力に、回答、参照資料、判断できない場合の案内を含めます。
4. 実際の質問を使ってテストし、正確さだけでなく根拠と権限を確認します。
5. 小規模に使い、失敗例、有人対応に戻した件数、利用量を定期的に見直します。

Microsoft Foundryでは、モデル、検索、エージェント、評価、監視を組み合わせられます。しかし、最初からすべてを使う必要はありません。業務の目的と評価方法を決めてから、必要な機能だけを増やすことが、運用負担を抑える近道です。

注意点

AIの回答が自然でも、業務上正しいとは限りません。出典のない回答、権限外の情報、古い資料に基づく回答は、利用者が気づけるようにします。ログには利用状況だけでなく、回答できなかった質問や、担当者が修正した内容も残すと改善に使えます。

Makeやn8nは、メール、フォーム、CRMなど周辺の作業をつなぐ自動化に向いています。一方、Microsoft Foundryは、AIアプリやAIエージェントを、データの根拠・評価・統制を含めて運用するための基盤です。両者は競合ではなく、AIが情報を整理した後に通知・記録・承認をつなぐ場面で補完できます。

AIが作った回答を、そのまま意思決定に使わないことが重要です。根拠、権限、人の確認を先に設計してから、対象業務を広げます。

関連記事

• Microsoft Foundryとは？旧Azure AI Foundryから理解するAI運用基盤
• Microsoft FoundryとCopilot Studioの違い｜AI導入で選ぶ基準
• Microsoft FoundryのRAGとは？社内資料を根拠に答える仕組み

参考情報

• Microsoft Foundry documentation
• RAG とインデックス
• エージェントRAG設計