【Microsoft Azure】Ignite 2025で発表されたIQシリーズの中でFoundry IQの立ち位置を改めて確認してみる

こんにちは、MS開発部の渋谷です。

企業のAI活用は、単に質問に答えるだけのチャットボットから、複雑な業務プロセスを自律的に遂行するAIエージェントへと変化してきています。

初期の生成AIブームにおいて、企業はRetrieval-Augmented Generation（以降RAG）と呼ばれる技術に注目し、LLMが保持していない社内の情報をチャットボットに回答させるという取り組みを進めていたと思います。

一方で従来型RAGは、単純なQ&Aには有効であるものの、ビジネスの現場で求められる複雑な意思決定や、複数の情報源を横断した推論には対応しきれない場合があることがわかってきました。

高度な推論を実現しようとすると、開発者はこれまで、複雑なオーケストレーション処理を自前で実装する必要がありました。

「もし検索結果が0件ならキーワードを変えて再検索する」「検索結果の内容が薄ければ別のデータベースも当たる」といったロジックをコードで記述し、LangChainなどのフレームワークを駆使して構築してきました。

これは、保守性やスケーラビリティ、セキュリティの観点で不利になるパターンが多いと思います。

この課題を解決するために、Foundry IQがIgnite 2025で発表され、今回はこれについて考えていきます。

 

Foundry IQ の概念とエコシステム

Foundry IQは、AI開発プラットフォームであるMicrosoft Foundry内で提供される、エージェントのためのマネージドな知識基盤です。

Foundry IQ の特長は企業内に散在するデータ（SharePoint、Azure Blob Storage、Webなど）を単一のインターフェースで統合し、エージェントが安全かつ高度に活用できることがイメージしやすいです。

従来、開発者はデータソースごとに接続処理や権限管理を実装する必要がありましたが、Foundry IQを使用することで、ナレッジベースという抽象化された層を通じて、あらゆるデータに統一的にアクセスできるようになります。

---

なお、Ignite 2025では、Foundry IQのほかにIQシリーズとしてWork IQやFabric IQを発表しており、それぞれの役割は次の通りです。

コンポーネント	対象領域 (Domain)	主なデータソース	役割 (Role)
Work IQ	Microsoft 365	Teamsチャット、メール、カレンダー、Office文書	組織の「活動」と「人間関係」の文脈を理解する（誰が何をしているか）。
Fabric IQ	Microsoft Fabric	OneLake、SQL Database、BIレポート	ビジネスの「事実」と「数値」を理解する（売上、在庫、KPI）。
Foundry IQ	Microsoft Foundry	独自ドキュメント、Web情報、外部SaaS	エージェントのための「知識」と「推論」を提供する（社内規定、技術文書、市場情報）。

Work IQやFabric IQがそれぞれのドメインに特化した知能を提供するのに対し、Foundry IQはどちらかというとその知能を利用するエージェントのための高度な検索や推論を提供するといった立ち位置であることがわかります。

Azure AI Search Agentic Retrievalについて

ここではFoundry IQでも利用されているAzure AI Searchに新しく搭載されたAgentic Retrieval機能を紹介します。

これは従来の検索エンジンとは一線を画す、AI時代のために再設計された検索アーキテクチャです。

 従来型RAGとAgentic Retrievalの決定的違い

従来のRAGシステムは、基本的にキーワード検索またはベクトル類似度検索の延長線上にありました。アプリケーションがクエリを投げ、検索エンジンはそれに類似したドキュメントを返すだけという、受動的な関係です。

これに対し、Agentic Retrievalでは、検索エンジン自体がLLMを内蔵し、能動的なエージェントとして振る舞います。

特徴	Classic RAG	Agentic Retrieval (Foundry IQ)
クエリ処理	アプリ側で作成したクエリをそのまま実行	LLMがクエリを分析・計画し、複数のサブクエリを生成・実行
検索戦略	直列的・単発的	並列的・反復的（必要に応じて再検索）
文脈理解	ステートレス（文脈なし）	会話履歴（Chat History）を入力として受け取り考慮する
結果出力	ドキュメントのリスト	統合・要約された回答、または構造化された根拠データ
開発コスト	オーケストレーションの実装が必要	マネージドサービスにオフロード可能（設定のみ）

エージェント検索の内部動作フロー

ステップ1: クエリ計画

ユーザーからの質問（例：「東京とニューヨークの気候の違いと、それぞれの観光ベストシーズンを教えて」）と、過去の会話履歴を受け取ります。

内蔵されたLLMがこれを分析し、情報を網羅するために必要な「サブクエリ」を計画します。

• サブクエリ1: 「東京 気候 特徴」
• サブクエリ2: 「ニューヨーク 気候 特徴」
• サブクエリ3: 「東京 観光 ベストシーズン」
• サブクエリ4: 「ニューヨーク 観光 ベストシーズン」

このように、複合的な質問を単純な検索タスクに分解することで、取りこぼしを防ぎます。

ステップ2: 並列実行とフェデレーション

計画されたサブクエリは、指定されたナレッジソースに対して並列に実行されます。

ここでの強力な点は、インデックス化されたデータだけでなく、リモートデータソース（SharePointやWeb検索など）に対しても同時に問い合わせを行える点です。

ステップ3: セマンティック・リランク

各ソースから返ってきた膨大な検索結果は、単なるキーワードの一致度ではなく、文脈的な意味の関連性に基づいて再ランク付けされます。

Microsoftの定評あるSemantic Rankerがここで活用され、ノイズを除去し、真に関連性の高い情報だけを抽出します。

ステップ4: 反復と自己評価

検索結果が集まった段階で、システムは「この情報でユーザーの質問に答えられるか？」を自己評価します。

もし情報が不足していると判断された場合（例：ニューヨークの観光シーズンの情報が欠けている）、システムは自動的に追加の検索を実行します。

ステップ5: 回答合成

最終的に集まった情報を統合し、LLMが自然言語で回答を生成します。

この際、情報の根拠となるドキュメントへの引用が自動的に付与され、ハルシネーションのリスクを低減します。

Reasoning Effortについて

Foundry IQの最大の特徴の一つが、エージェントが検索にかける労力を開発者がコントロールできるReasoning Effortという設定です。

これにより、コスト、速度、精度のトレードオフを最適化できます。

レベル	動作メカニズム	コスト・速度	推奨ユースケース
Minimal (最小)	LLMによるクエリ計画を行わず、入力をそのまま並列検索する。最も従来の検索に近い。	低コスト・高速。 LLMトークン消費なし。	単純なキーワード検索、事実確認、スピード最優先の場面。
Low (低) (デフォルト)	1回のクエリ計画（Single-pass）を行う。質問を分解し、最適化して検索するが、再検索はしない。	中コスト・中速度。 回答生成用に5,000トークン予算。	一般的な質問応答、チャットボット、バランス重視の場面。
Medium (中)	クエリ計画に加え、検索結果の自己評価と**反復検索（Reflective Search）**を行う。最大1回の追加検索が可能。	高コスト・低速度。 回答生成用に10,000トークン予算。	複雑な推論、調査業務、コンプライアンス確認、情報の網羅性が必須の場面。

Microsoftによるベンチマーク結果では、Reasoning EffortをMinimalからMediumに上げることで、回答の関連性スコアが平均で36%向上したと報告されています。

特に、複数のドキュメントから情報を繋ぎ合わせる必要がある難易度の高い質問においては、スコアが2倍以上に跳ね上がるケースも確認されており、複雑なタスクにおける「Medium」設定の有効性が実証されています。

SDKを用いて使ってみる方法

Microsoftのブログにも紹介されていますが、Python SDKを用いた実装は非常にシンプルになっています。

コードの実体としては、AzureAISearchContextProviderの中でFoundry IQのエンドポイントやナレッジベースの名前、検索モードを設定することで検索の仕組みをエージェントに与えることができます。

まとめ

今回はIgnite 2025で発表されたFoundry IQについて紹介しました。

これまで開発者が苦労して構築してきたRAGの構成を、よりマネージドな形で利用できるようになってきました。

特に、Work IQやFabric IQと連携し、組織のあらゆるデータを横断して推論する未来像は、様々な可能性を感じることができ、今後も注視していきたい領域になることでしょう。