こんにちは、サイオステクノロジーの佐藤です。
今回は、前回のブログでも触れたFoundry IQについて、もう一歩踏み込み、「実際に内部でどのような処理が行われているのか？」という構造面を解説します。

• Foundry IQ便利そうだけどどういう仕組みなの？
• 内部的な動きってどうなっているの？

という方は是非最後までご覧ください！

なお、Foundry IQの概要やコンセプトに関しては前回の記事をご覧ください。

Foundry IQ は RAGにとっての銀の弾丸となりえるか？【Microsoft Ignite 2025 Recap】

Foundry IQの技術基盤

Foundry IQはMicrosoft Foundry上にて作成できるサービスとなっています。
ただし完全に新規で独立したサービスというわけでもなく、内部的な仕組みとしてはAzure AI Searchのサービスが基盤となっています。
またそれと並行してLLMやEmbeddingsといったAIモデルも必要となってきます。
このAzure AI SearchとAIのモデルの2つがFoundry IQを構成する主な要素となります。

そのため、Microsoft Foundry上でFoundry IQを作成しようとすると、まずAzure AI Searchとの接続を求められます。
また、後述するナレッジベースを構築する上では、AIモデルのデプロイメントが必須となります。

AI Searchの役割

AI Searchの役割は高度な検索サービスであり、AI Search上に格納されたデータに対して様々な検索を行えるサービスです。
特に、近年実現されたAgentic Retrievalの検索手法は、今回のFoundry IQの肝となる検索手法と言っても過言ではありません。

また検索手法だけではなく、データのインポート技術にも優れています。
BlobStorageなどを対象として、データの読みとりから、チャンク化・ベクトル化といった加工までを実施可能で、検索に適した形でデータをインポートすることが可能です。

こういったことから、Azure AI SearchはFoundry IQの根幹となるプラットフォームとなっています。

AIモデルの役割

先ほど紹介したAI Searchの検索機能に対してより付加価値を高めるのが、各AIモデルの役割です。
単純にデータのインポート、検索を行うだけであればAI Searchだけで完結しますが ユーザーからの質問の意図の解釈や、質問の分解などに使われ、より検索精度・回答精度を高めるための手段としてLLMが利用されます。

また、LLMによる「思考」だけでなく、Embeddingモデルも非常に重要な役割を果たします。
先ほど述べたように、Foundry IQがデータを自動でインポートする際の「ベクトル化」や、ユーザーの質問をデータベースと照合する際の「意味的マッチング」において、このEmbeddingモデルが裏側で活躍しています。

Foundry IQの構成

実際にFoundry IQの内容についてみていきたいと思います。
Foundry IQのざっくりコンポーネント図としては以下のような形です。

ここで重要なのが以下の2つの要素です。

• ナレッジソース
• ナレッジベース

ナレッジソース

ナレッジソースとは、実際に検索に使われるファイルなどのコンテンツを指定するための概念となります。
上の図でいうと、Storage AccountとSharePoint Onlineといったリソースと連携している形となります。
各ナレッジソースがこれらのリソースと紐づくことで、紐づいたリソースのコンテンツを検索対象とすることができます。

ナレッジソースの対象となっているものは以下の6種類です。

なおここで記載しているタイプについては、以下のような違いがあります。

• インデックス型：事前にデータを取り込んでおき、内部にインデックスを作成・保持しておく
• リモート型：検索が行われた時点で外部のシステムを直接見に行き、常に最新のデータを見に行く

ナレッジベース

ナレッジベースは、複数のナレッジソースを束ねて、エージェントに対する窓口となる概念です。
エージェントからのクエリに対して、どのナレッジソースを利用するべきか、どういった検索を行うか、本当にこのまま検索結果を返してよいかなどを判断するオーケストレーターとしての役割を担います。

また、ナレッジベースは最低一つ以上のナレッジソースから構築されます。

Agentic Retrieval

Foundry IQの重要な機能に、Agentic Retrievalがあります。
とはいいつつ、これはFoundry IQというよりもAzure AI Searchの機能となります。
先ほども述べた通り、実際にエージェントからFoundry IQを呼び出したとしても、検索が行われるのはAI Searchです。

従来の検索手法では、ユーザーからの質問をベクトル化して一度検索を行い、類似度が高いものを結果に返すといった流れでした。(いわゆるSingle-shot)

一方で、Agentic RetrievalではLLMの機能を用いて、

• クエリの内容はどのような内容なのか
• クエリに適したナレッジソースはどれなのか
• 得られた結果が本当に期待する回答なのか
• 必要に応じて再検索を実施 などを自律的に考えた検索が行われます。

そのため、従来のSingle-shotの検索よりも、期待に近い回答が得られやすくなります。

Agentic Retrievalの例

このAgentic Retrievalの例をひとつ見てみたいと思います。

例えばユーザーから以下のようなクエリが飛んできたとします。

サイオス病院の健康診断でB判定となりました。上の血圧が150でした。
今40歳なのですが、病院からは運動することを推奨されました。
どういった運動をしたらいいですか？

この質問には、「B判定の基準」「血圧150の意味」「40歳の適切な運動量」という複数の要素が混ざり合っています。
これを従来のRAGでそのまま検索にかけても、全ての情報が網羅された完璧なドキュメントを引き当てることは困難です。

一方でAgentic Retrievalを利用することで、こちらが解決できる可能性があります。

Foundry IQ(Agentic Retrieval)では、この質問を受け取ると以下の4つのステップを自律的に実行します。

Step 1: クエリの計画と分解

まず、AIが質問の意図を解釈し、回答に必要な情報を集めるために質問を複数の「サブクエリ」に分解します。

• 「サイオス病院のB判定の基準とは？」
• 「血圧150の危険度は？」
• 「40歳に推奨される1日あたりの運動量はどれくらいか？」

このように、システムが自ら「何を調べるべきか」の計画を立てます。

Step 2: ソースの動的選択

次に、分解したサブクエリごとに、接続されている複数のナレッジソースの中から「どこへ探しに行くべきか」を動的に選択して検索を実行します。

• B判定の基準 ➔ 病院内部資料である SharePoint を検索
• 血圧の危険度 ➔ 調査資料が格納された Blob Storage を検索
• 推奨される運動量 ➔ 自社データにない一般知識のため Web（Bing）検索 を実行

このように各データソースの特徴をAIが判断し、最適な場所へ同時に情報を探しに行きます。

Step 3: 自己評価と反復検索

ここがAgentic Retrievalの最も強力なポイントです。
取得した情報をそのまま返すのではなく、システム内部にいる小規模言語モデル（SLM）が「この情報でユーザーの質問に答えられるか？」を自己評価します。

もし「まだ情報が足りない（NG）」と判断した場合は、もう一度ステップ1に戻り、クエリを調整して再検索（反復）を行います。

Step 4: 回答の合成

SLMの評価が「OK」となり、十分な情報が揃ったと判断された段階で、複数のソースからかき集めた情報を統合し、自然な回答文として合成してユーザーに返却します。

retrieval Reasoning Effort

このように自律的に動作するAgentic Retrievalですが、「毎回そんなに深く考えて反復検索しなくていいから、早く答えが欲しい」というケースもあるはずです。
Agentic Retrievalにおいては、この「検索の深さ（レイテンシと品質のトレードオフ）」を開発者がコントロールできるように、「検索推論努力（retrieval Reasoning Effort）」というパラメータが用意されています。

まとめ

今回は、Foundry IQの内部構造や、Agentic Retrievalの自律的なプロセスについて解説しました。
こうして内部の動きを見ると、開発者がこれまで自前で実装する必要があった複雑な検索処理を、Foundry IQがうまく担ってくれていることが分かっていただけたかと思います。

次回は実際にFoundry IQを活用してエージェントを構築する流れをご紹介したいと思います！
ではまた！

余談

本ブログの内容に関しては、以下のYouTubeでもお話ししています。
もしよければこちらもご覧いただければと思います🚴