Foundry IQとは？従来RAGとの違いと企業導入の判断基準【2026年9月】
【結論】Foundry IQとは、Microsoft Foundry向けのマネージド知識レイヤで、Azure AI Search上にKnowledge Baseを置き、エージェントが権限を意識した社内ナレッジを問い合わせる仕組みです。
- Knowledge Baseがクエリ計画・並列検索・引用付き応答をオーケストレーションする（出典：Microsoft Learn「What is Foundry IQ?」）
- 基盤はAzure AI Searchのagentic retrieval。REST APIはGA（2026-04-01）とpreviewで機能差がある
- エージェント接続はAPI直接呼び出しとMCP（knowledge_base_retrieve）の両方がある
この記事では、Azure／Foundryで社内ナレッジエージェントを検討する開発責任者・情シス・PM向けに、2026年9月時点の公開情報に基づいて定義・構成・使い分け・導入判断を解説します。
Foundry IQとは — 定義
Foundry IQとは、Microsoftのエージェント向けマネージド知識レイヤです。散在する企業コンテンツを、権限を意識した再利用可能なKnowledge Baseにまとめ、エージェントが自然言語で問い合わせられるようにします。公式ドキュメントでは、エージェント単体のモデルには知識カットオフがあり自社データへ直接アクセスできないため、Foundry IQでマルチソースのKnowledge Baseを用意する、と説明されています（出典：What is Foundry IQ? – Microsoft Learn）。
Azure AI Searchのagentic retrieval概要でも、Foundry IQは企業コンテンツを権限を意識した再利用可能なKnowledge Baseへ変換するマネージド知識レイヤとして位置づけられています（出典：Agentic Retrieval Overview）。製品ページでは「context engineering platform」とも呼ばれますが、実務で押さえるのは「エージェントが使うナレッジの置き場と検索オーケストレーション」です。
一般のRAG構築手順はRAG構築の進め方（5ステップ）、Copilot製品横断の進め方はMicrosoft Copilot環境でAgentic RAGを構築するを参照してください。本記事はFoundry IQそのものに絞ります。
構成要素 — Knowledge BaseとKnowledge Source
Foundry IQの中核は次の3つです。Azure AI Searchが索引と検索のインフラを提供します。
| 構成要素 | 役割 | 実務での意味 |
|---|---|---|
| Knowledge Base | agentic retrievalをオーケストレーションする最上位リソース。どのKnowledge Sourceを使うか、reasoning effortなどのパラメータを持つ | 複数エージェントで共有する「社内ナレッジの窓口」 |
| Knowledge Source | 索引付き、またはリモートのコンテンツ接続。KBが1つ以上参照する | SharePoint／Blob／OneLake／Web／索引など、見せるデータの定義 |
| Agentic retrieval | 複雑な問いをサブクエリに分け、並列検索・セマンティック再ランクし、統合応答を返すパイプライン | 従来の「1クエリ1検索」より調査型の問いに向く |
エージェントがKBを問い合わせると、Foundry IQはクエリを処理し、関連情報を取得し、ユーザー権限を適用し、引用付きの根拠つき応答を返します。複数エージェントが同じKBを共有できる点が、アプリごとに検索パイプラインを複製する従来構成との差です。
agentic retrievalの流れ
公式の流れはおおむね次のとおりです（出典：Agentic Retrieval Overview）。
- 開始: アプリまたはエージェントがKnowledge Baseのretrieveを呼び、クエリと会話履歴を渡す
- クエリ計画: reasoning effortが low／medium のとき、LLMが問いをサブクエリに分解する。minimalではこの段階を飛ばし、ソースへ直接発行する
- 並列実行: 各サブクエリをKnowledge Sourceへ同時に送り、キーワード／ベクトル／ハイブリッドで検索し、セマンティック再ランクする
- 合成: 結果を統合する。merged contentは常に返り、参照とactivityログは任意
レイテンシは単一クエリより増えます。一方で、複数条件の問い、会話文脈への依存、言い換えが必要な調査には向きやすい、と公式も説明しています。
従来RAG・semantic・agenticの使い分け
| 観点 | 従来の単一クエリRAG | semantic（高速ハイブリッド） | agentic（Foundry IQの深い経路） |
|---|---|---|---|
| クエリ | 1回の検索が多い | ベクトル＋キーワード＋再ランク | サブクエリ計画・並列・反復 |
| 向き | FAQ・単発の事実確認 | 速度優先の単発検索 | 複数条件・会話文脈のある調査 |
| 再利用 | アプリごとにパイプライン複製しがち | 索引共有は可能 | KBを複数エージェントで共有 |
| コスト／遅延 | 相対的に低い | 中程度 | トークン課金と遅延が増えやすい |
Foundry側のAgent Framework連携では、Azure AI Search Context Providerで mode="agentic"（Knowledge Base）と mode="semantic"（高速ハイブリッド）を用途で切り替える説明があります（出典：Foundry IQ in Microsoft Agent Framework）。全部をagenticに固定する必要はありません。FAQはsemanticや単一クエリのままにし、複雑な問いだけKBのagentic経路に載せる判断が現実的です。
エージェントへのつなぎ方 — APIとMCP
Knowledge Baseの利用経路は大きく2つあります。
- retrieve API: Search Service REST／SDKから直接呼び、groundingデータを受け取って自前のLLMで回答する
- MCP: KBが公開するMCPエンドポイントの
knowledge_base_retrieveツールを、Foundry Agent Serviceなどが呼び出す
Foundry Agent Serviceへの接続手順では、プロジェクトのマネージドIDでRemoteTool接続を作り、KBのMCPへ安全に通信する、とあります。権限フィルタを効かせるには、サインイン中ユーザーのトークンを x-ms-query-source-authorization ヘッダで転送する必要がある、とも明記されています。トークン無しでは権限付きフィルタが期待どおり動かない点に注意してください（出典：Connect Agents to Foundry IQ Knowledge Bases）。
社内システム接続の一般論はMCPサーバー、MCPガバナンスとはも参照してください。StudioとFoundryの役割分担はCopilot StudioとFoundryの切り分けにまとめています。
GAとpreview — 本番前に確認すること
2026年9月時点の公式注記では、次の区分があります。
- 本番向け（例）: Search Service REST
2026-04-01。GAのKnowledge Source種別と、minimal／extractiveな取得など、安定API上の機能セット - preview向け（例）:
2026-05-01-previewや2026-08-01-preview。クエリ計画、answer synthesis、reasoning effortの非minimal、マルチターンmessages、一部のKnowledge Source種別など
AzureポータルとMicrosoft Foundryポータルは、agentic retrieval機能へのアクセスがpreview中心になる場合があります。ポータルで作ったオブジェクトはpreviewスキーマになり、GA RESTへ移すときに移行が必要になり得ます。SLA対象外のpreviewを本番固定にしないこと、移行ガイドを読むことが前提です。
課金は Azure AI Search側のretrievalトークンと、クエリ計画・回答合成に使うAzure OpenAI側のトークンに分かれます。単価・リージョン・無料枠は公式料金ページで確認してください。activityログでどのソースに何本のサブクエリが飛んだかを見て、ソース数とreasoning effortを下げるのがコスト制御の基本です。
導入時の判断チェックリスト
- 文書と権限を先に決める: KBを作る前に、見せてよいサイト／索引と、誰の権限で検索するかを固定する
- FAQはsemanticから: 全部をagenticにするとコストと遅延が増える
- APIバージョンを明示する: 本番はGA REST、検証だけpreview、と分ける
- 評価セットを用意する: 根拠らしさだけでなく、権限・鮮度・セッションを見る（詳細はAgentic RAGの評価設計）
- 観測を入れる: activityログと引用が追える状態で本番に出す
実装支援はAIシステム／AIエージェント開発支援、文書整備から入る場合はAI導入支援（AI BPR）です。Azure AI Search単体のagentic retrievalはAzure AI Searchのagentic retrievalもあわせてご覧ください。
よくある質問（FAQ）
Q1. Foundry IQとは何ですか？
Microsoft Foundry向けのマネージド知識レイヤです。Azure AI Search上のKnowledge Baseを通じ、エージェントが企業ナレッジをagentic retrievalで参照します。
Q2. Azure AI Searchとの関係は？
Foundry IQのKnowledge Baseを使うにはAzure AI Searchリソースが必要です。索引とagentic retrievalのインフラはAzure AI Searchが担います。
Q3. Knowledge BaseとKnowledge Sourceの違いは？
Knowledge Sourceはデータの接続定義、Knowledge Baseはそれを束ねて検索をオーケストレーションする単位です。エージェントは主にKBを問い合わせます。
Q4. semanticとagenticの違いは？
semanticは高速なハイブリッド検索、agenticはクエリ計画を含む深い検索です。用途で切り替えます。単純なFAQはsemanticで足りることが多いです。
Q5. MCPで使えますか？
はい。KBのMCPエンドポイントが knowledge_base_retrieve ツールを公開し、Foundry Agent Serviceなどから呼べます。権限付き検索にはユーザートークンの転送が必要です。
Q6. すぐに本番でagenticにすべきですか？
いいえ。FAQは単一クエリやsemanticから始め、複雑な問いが残る領域だけagenticに広げるのが現実的です。preview機能は本番固定にしないでください。
Q7. 料金の考え方は？
Azure AI Searchのretrievalトークンと、クエリ計画等に使うAzure OpenAIのトークンが別途かかります。単価は公式料金とリージョンで確認してください。
Q8. Copilot Studioとの関係は？
定型業務エージェントはStudio、深いマルチソース検索と再利用KBはFoundry IQ、という分担が現実的です。詳細はStudioとFoundryの切り分け記事を参照してください。
Q9. x3dに相談できますか？
できます。武石幸之助は2017年から対面で1,800社超・受講者5,000名超にAI導入支援を実施しています（認定講師分・オンラインは含まない）。Foundry IQの設計から文書整備・評価まで支援します。
参考文献・出典
- Microsoft Learn「What is Foundry IQ?」
- Microsoft Learn「Agentic Retrieval Overview – Azure AI Search」
- Microsoft Learn「Connect Agents to Foundry IQ Knowledge Bases」
- Microsoft Foundry Blog「Foundry IQ in Microsoft Agent Framework」
- Microsoft Azure「Foundry IQ」製品ページ
本記事は2026年9月時点の公開情報に基づいています。プレビュー機能・料金・リージョン・APIバージョンは変化するため、最新は各公式ドキュメントをご確認ください。
x3d株式会社では、本記事で解説したFoundry IQ／社内ナレッジエージェントの設計・実装に関する企業研修・導入支援・システム開発を提供しています。
まずはお気軽にご相談ください。