こんにちは、サイオステクノロジーの佐藤 陽です。
先日、毎年恒例のMicrosoft Igniteが開催され、様々な機能のリリースが発表されました。

今回は、その中でも個人的にインパクトが大きいと感じた「Foundry IQ」を取り上げます。

なお、本記事は現時点で公開されている紹介記事やドキュメントを読んだうえでの

• 所感ベース
• 自分が気になった点に特化

とした内容になっています。

実際に触ってみての検証は今後別途まとめる予定ですので、その点ご承知おきください。

Foundry IQとは

Foundry IQは 「a unified knowledge layer for agents（エージェントのための統一された知識レイヤー） を提供する」と述べられています。

この定義をパッと聞いただけだと「結局これは何なの？」といった点が分かりづらいですよね。
そこでまず、現状のRAGの課題を整理し、それをFoundry IQがどう解決しようとしているのかを順番に見ていきます。

現状のRAGの課題

これまでRAGにおいて独自のナレッジを扱うにあたっては、以下のような理由から複雑な構成・運用になりがちでした。

• ナレッジの内容ごとのパイプライン設計
• ナレッジに対するアクセス制御の複雑さ  

Foundry IQは、これらの課題を解決するために設計されています。

1.ナレッジごとのパイプライン設計の負担

ナレッジを格納する際、すべてのデータに対して同じ処理を行っていては、期待する回答精度が得られないことが多いです。
例えば、以下のような観点で処理を変えたくなります。

• ファイル形式の多様性：PDF、Office系ファイル、画像、音声 etc.
• データ構造の違い：図表が多いファイル or 文章が多いファイル
• 専門性の違い：専門用語が多いファイル or 一般的な情報が多いファイル

これらの違いによって、データによって前処理の内容やチャンクサイズ、ベクトル化の際の次元数などを適切に切り替えていく必要があります。

また、1つの会社内で導入するにあたって、この「ナレッジの性質」は部署ごとに様々です。

それぞれの部署ごとにこう言ったパイプラインを細かく設計する必要がありますし、
新しくRAGを利用したい部署が出てきた場合、また部署のデータの特性に合わせて新規にパイプラインを設計・構築する必要があります。

また、上記の図はIndexer側の処理の話でしたが、Retrieverも同様です。
ナレッジごとに検索手法（キーワード検索、ベクトル検索、ハイブリッド検索、リランキング方法 etc.）を切り替える必要が出てきます。

このように、データの種別ごとにIndexerやRetrieverをここに設計し、メンテナンスしていくことは
RAGを運用していくチームにとっても非常に大きな負担となっています。

2.アクセス制御の複雑さ

様々なナレッジをナレッジストアに登録したとしても、すべてのユーザーがすべてのナレッジにアクセスしてよいとは限りません。

例えば、役員会議用の資料をナレッジストアに登録した場合、一般社員はそのナレッジをコンテキストとした回答は得られないようにするべきです。
現状、Azure AI SearchなどでEntra IDと連携したアクセス制御を「フルマネージドで」実現することは難しく、
自前でEntra IDの情報とAI Search上のデータを紐づけてアクセス制御を実装・運用していく必要があります。

ただ、社内における部署異動や権限の追加／削除など、IDまわりの運用は日々変化します。
それらをすべてRAG側で追いかけ続けるのは、RAGの運用チームにとって大きな負担になります。

このように、既存のRAGでナレッジを適切に運用していくためにはかなりの時間とエネルギーを要します。
これが、今のRAG開発が持つ一番の「辛み」だと感じています。

Microsoft Igniteで発表されたFoundry IQ

こうした課題を解決してくれるのがAzure Foundry IQです。

一言で言ってしまうと、「ナレッジごとのパイプライン構築」や「複雑なアクセス制御の実装」といった部分を、いい感じに一括してFoundry IQ側で引き取ってくれるサービス、というイメージです。

（※あくまでイメージ図です）

このようにしてFoundry IQ では、RAGまわりの世界観を次のように変えます。

1. 「ナレッジベース（Knowledge Base）」という箱をまず作る
2. そこに、Blob / SharePoint / Web などのデータソースを「つなぐ」
   1. この時点で様々なパイプライン設計・実装をFoundry IQで吸収する
3. 複数のエージェントやアプリケーションから、このナレッジベースを 1つのAPI として参照する

つまり、エージェント側やアプリケーション側でIndexerやRetriverの複雑なパイプラインを考慮数る必要はなく
1つのAPIにアクセスすることで、容易にナレッジを利用できるようになります。

Microsoftが出しているFoundry IQのブログ記事のタイトルも「Unlocking ubiquitous knowledge for agents」となっており、
まさにこういった部分を狙った機能であることがうかがえます。

Foundry IQの注目ポイント

コンセプトは分かったとして、実際何が嬉しいのか？
特徴的だと感じたポイントを3つに絞って見ていきます。

1.データ投入とナレッジ管理

Foundry IQでは、インデックスされたデータとリモートデータをまたいで、同一のナレッジベースとして管理することが可能です。

このうちインデックス型データソースに対しては、コンテンツの取り込み、チャンク戦略、ベクトル化などを一通り自動で行ってくれます。
そして、これらのデータソースごとにパイプラインを構築したり、Retrieverの戦略を個別に設計したりする必要はない、と述べられています。

つまり、「取り込みたいデータソースをポータル上で選ぶだけで、あとはデータの内容に基づいてよしなにやってくれる」ようなイメージです。

また、リモートソースをそのまま読みに行けるのも大きなポイントです。
これまではSharePoint上のデータについても、一度BlobなどにコピーしたうえでAI Searchにインデックスするのが一般的でした。
この場合、元データの更新と同期をとる必要があり、どうしても処理が複雑になりがちでした。

その点、リモートデータを直接見に行き、常に最新のデータを参照できるのは非常に大きな強みだと思います。

余談

これまでのAzure AI Searchにも「データのインポート」機能があり、ワンクリックでデータのインデクシングを行うことができました。
Foundry IQは、これをより強化した機能、というイメージで個人的には捉えています。

公式ドキュメントにもFoundry IQの基盤はAzure AI Searchである旨の記載があります。
おそらく、AI Searchのデータインポート機能にLLMの力を組み合わせることで、より最適なチャンキングなどを行っているのではないかと予想しています。

2.Agentic Retrieval（エージェント型検索）

次のポイントは、検索エンジン自体が「エージェント化」しているという点です。

従来のRAGは、ざっくり言えば、

1. ユーザーの質問をEmbeddingする
2. ベクトルDBから類似ドキュメントをk件取る
3. LLMに「質問＋コンテキスト」を渡して回答させる

というフローが基本でした。

Foundry IQ が掲げている Agentic Retrieval では、ここに「プランニング」と「反復」が入り込みます。

• 質問の意図を解釈し、
  • どのデータソースから
  • どの順番で
  • どの粒度で
    取ってくるべきかを推論する
• 初回検索で十分なコンテキストが得られなければ、クエリを書き換えて再検索する
• 必要に応じて、関連するサブクエリを自動的に発行する

さらに、内部パラメータとして「どの程度深く考えてから答えるか（Retrieval Reasoning Effort）」を調整できるようになっています。

• FAQレベルの簡単な質問 → 浅く・速く
• 複雑な推論や調査タスク → 深く・時間をかけて

といったユースケースごとのチューニングが可能になるイメージです。

3.アクセス制御

最後はアクセス制限に関してです。
普段RAGの開発をしている自分からすると、ここが一番大きなポイントに感じています

Microsoftのブログには、ざっくり次のような点が記載されています（意訳）。

1. 設定済みかつサポートされているナレッジソースに対するユーザー権限を尊重する。
2. リモートSharePointナレッジソースの場合、Microsoft Purviewのデータ分類と機密ラベルが、インデックス作成および検索パイプラインを通じて尊重される。

今まで自前で制御しなくてはならなかったアクセス制御の部分を、Foundry IQ側で巻き取ってくれるのはこの上なくありがたいです。

なお1.の「設定部分」に関してはまだ詳細を追いきれていませんが、Entra ID基盤上に構築されているサービスであることを踏まえると
ここは簡単に設定できる方向で仕上げてくれることに期待したいところです。

ブラックボックス化というトレードオフ

ここまで読むと、

Foundry IQ さえ使っておけば間違いないのでは？

という印象を持たれるかもしれません。
ただ、エンジニア視点で見ると、「チューニングの余地がかなり減ってしまった」という印象も受けました。

RAG の世界には、職人芸に近いチューニングポイントがいくつもあります。

• チャンクサイズとオーバーラップ率
• 階層構造チャンク / セマンティックチャンクの使い分け
• Embeddingモデルの選定（汎用 vs ドメイン特化）
• 再ランキングのON/OFF、スコアのしきい値

Foundry IQ はこういった部分を大幅に巻き取ってくれている一方で、
逆に言えば、これらに直接手を入れる余地は意図的に小さくなっています。

• 極端に専門用語が多い業界
• 規制産業で、誤答率を極限まで下げたい案件

などでは、

もう少しRAGの中身を触らせてほしい…

という欲求が出てくるかもしれません。

FoundryIQのようにブラックボックス的に大半の処理を行ってくれるのは大きな強みですが、同時に「RAG職人の腕の見せ所が減る」という側面もある点は、頭の片隅に置いておいたほうが良さそうです。

とはいえ、最近のAIの進歩を考えると、「RAG職人」が頑張って細かいチューニングをするよりも、AIに任せた方が良いアウトプットを出す可能性も十分にあります。
このあたりは、実際に使ってみて評価していくフェーズかなと思います。

導入時の注意ポイント

最後に、これは Foundry IQ に限らず、すべてのRAGに言える話ですが、

Garbage In, Garbage Out

の原則は、一切変わりません。

• 元のデータソース管理場所がゴミ屋敷状態
  • 新規 (1).docx、最終版_本当に今度こそ最終.pptx が乱立し、どれが最新か分からない
• 権限設定が形骸化
  • 「よく分からないので Everyone にフルアクセスつけました」

といった環境のまま Foundry IQ とつなぐと、
高い確率で「自信満々に間違ったことを言うエージェント」か、
「見せてはいけない情報をさりげなく提案してしまうエージェント」が生まれます。

Foundry IQ は、接続と検索エンジンの負担を大きく軽減してくれる ツールですが、
「データガバナンスそのものを自動で何とかしてくれる魔法」ではありません。

むしろ、Foundry IQ のようなツールを導入したとしても、

• 情報資産の棚卸し
• メタデータ設計
• 権限ポリシーの整理

といった地味だが本質的な仕事は結局必要になる、という印象です。

まとめと今後

今回はMicrosoft Igniteで発表された「Foundry IQ」についてご紹介しました。
Foundry IQを利用することによって、これまで煩雑な設計・管理が必要だった部分が大幅に削減されることが期待できます。

一方で、それによってチューニングポイントがかなり減ってしまうため、
特殊な業界のユースケースなど、マネージドな仕組みだけでは対応しきれないケースも出てくるかもしれません。

今回はMicrosoftの紹介記事を読んでの所感ベースかつ、RAGに特化した内容でした。
次回以降は実際にFoundry IQを使ってみつつ、エージェントとして使うならではの部分や・使ってみた感想などをお伝えできればと思います。
ではまた！

参考文献

• Foundry IQ: Unlocking ubiquitous knowledge for agents
• Foundry IQ: ナレッジを最大限活用する
• Foundry IQ ナレッジ ベースを Foundry Agent Service に接続する