こんにちは、俊介です！
普段は Azure を中心に、企業向けの AI ソリューションを設計・構築する仕事をしています。
今日は、2026年6月に GA（一般提供）となった Microsoft Foundry の「Foundry IQ」を使って何ができるのかを実際に知っていこうと思います。
この記事は、概念の整理と、実際に Azure 環境で手を動かした検証の2段階構成です。
「Foundry IQ」が何者なのか知っている人は飛ばしてもらって大丈夫です！
先に結論
思ってたより長くなったので、まとめを先に置いておきます。
| 観点 | 結論 |
|---|---|
| 何がうれしい？ | 複数の異なるソース（Blob＋Web など）を1つのナレッジベースに集約し、質問を横断・統合して引用付きで回答できる。自前RAGの面倒ごとが少し楽になった |
| 機能は全部使える？ | 全部使えるわけではなさそう。 特にクエリ計画・回答合成・reasoning effort 調整・SharePoint Indexed がプレビュー |
| 実際どうだった？ | 比較的簡単にRAG ChatBotみたいなものができたし、横断・統合回答もされたので驚きはあった。 reasoning effort を下げると取得件数も引用も露骨に減り、検索の頑張り度の価値が数字で見えた。試す価値はある。 |
どんなユーザー向け？
- 自前でRAGを組んだことがあって、あの面倒ごとをマネージドに寄せたい人
- Foundry / Azure AI Search で社内ナレッジ検索を作ろうとしている人
- 「6月にGAされたって聞いたけど、実際どこまで使えるの？」を知りたい人
そもそも Foundry IQ って何者なのか？
ひとことで言うと、「エージェントに、社内のあらゆる知識へアクセスさせるためのマネージドなナレッジ層」です。
エージェントの頭脳にあたる LLM（Foundry のモデル）には知識にも限界があって、皆さんの会社の独自データは知りません。
そこで「自社データを検索して、根拠付きで答えさせる」仕組み（いわゆる RAG ）が必要になるんですが、これを自前で組むと地味にしんどい。
チャンク分割して、ベクトル化して、インデックス作って、権限も考えて……とやることが多いし。
Foundry IQ は、この一連をAzure が丸ごと引き受けてくれるサービスです。しかも「1つのナレッジベースに複数のデータソースを束ねて、複数のエージェントから使い回せる」ということもできます。
※ 出典：What is Foundry IQ? - Microsoft Learn
3つの構成要素
Foundry IQ は、ざっくり3つでできています。
| 構成要素 | 役割 |
|---|---|
| Knowledge Base（ナレッジベース） | 司令塔。どの知識ソースを使うか、検索の挙動（後述の reasoning effort など）をまとめて定義する最上位のリソース。複数エージェントで共有できる |
| Knowledge Sources（知識ソース） | データへの接続。1つのナレッジベースに複数ぶら下げられる |
| Agentic Retrieval（エージェンティック検索） | 実際に検索する多段クエリエンジン。土台は Azure AI Search |
知識ソースは2種類
知識ソースにはIndexed（取り込み型）とRemote（毎回問い合わせる型）の2種類があります。
| 種別 | 挙動 | 対応ソース |
|---|---|---|
| Indexed（取り込み型） | データを検索インデックスに取り込む。チャンク分割・ベクトル化・メタデータ抽出・ACL同期を自動でやってくれる | Azure Blob Storage / OneLake / SharePoint（※プレビュー）/ 既存の検索インデックス |
| Remote（毎回問い合わせる型） | 取り込まず、検索時に外部システムへ問い合わせる | SharePoint（Copilot Retrieval API 経由）/ Web（Grounding with Bing 経由） |
既存の Azure AI Search インデックスをそのまま知識ソースにできるのも地味に嬉しい。すでに検索資産がある人はそのまま流用できます。
※ 出典：Foundry IQ FAQ - Microsoft Learn
エージェンティック検索の中身
RAG ChatBotと何が違うのか。ここが Foundry IQ を利用する上で大事になってきます。
一般的なRAGは1回検索して返してくる。
一方、エージェンティック検索では、ナレッジベースに質問を投げると、内部でこう動きます。
- クエリ計画：LLM が質問を読み、複数のサブクエリに分解する
- 並列検索：サブクエリを複数の知識ソースに対して同時に実行（キーワード / ベクトル / ハイブリッド）
- セマンティック再ランク：集まった結果を関連度で並べ替える
- 統合＆引用付き回答：結果をまとめ、出典（citation）付きで1つの回答に合成する
→「聞き方が難しい複雑な質問」でも、勝手に分解して複数ソースを横断してくれるみたいです。ここが一般的な自前RAGとの一番の体感差だと思います。
reasoning effortについて
ナレッジベースには reasoning effort という設定があり、検索エンジンがどれだけ賢く処理できるかを3段階で調整できます。
| 設定 | 挙動 |
|---|---|
| 最小（minimal） | LLM のクエリ計画なし。複数クエリの結果をマージするだけ |
| 低（low） | LLM がクエリ計画。並列サブクエリ処理あり |
| 中（medium） | さらに、初回の結果が不十分なら繰り返し検索（iterative search）する |
※ ポータルの日本語UIでは「最小 / 低 / 中」と表示されます。今回のハンズオンでは、両端の「最小」と「中」だけを比較します（「低」は割愛）。
※ 出典：Foundry IQ FAQ - Microsoft Learn ／ Create a knowledge base - Microsoft Learn
自前RAG / On Your Data と何が違うのか
RAG を自分で組んだことがある人は気になるポイントだと思うので、比較表にします。
| 観点 | 自前RAG / Azure OpenAI On Your Data | Foundry IQ |
|---|---|---|
| ソース接続 | エージェントごと・ソースごとに個別接続しがち | 1つのナレッジベースに複数ソースを集約し、複数エージェントで共有 |
| クエリ処理 | 基本は単発の検索 | 質問を分解→並列→再ランク→統合する多段パイプライン |
| インデックス更新 | 自前でパイプライン運用 | インデクサーで自動・定期同期 |
| 権限 | 自前で作り込み | ACL同期・機密ラベル・Entra ID での権限フィルタを標準サポート |
| 引用 | 実装次第 | 標準で引用付き回答 |
→簡単にいうと大変なアレコレを代わりにやってくれる
あと気になったのが、「1つのナレッジベースに複数ソースを集約」ってのが、Copilot Studioでも見たなと思っていて、棲み分けだったり何が違うんだろうと感じました。
なので次回以降のブログでどっちも触って比較してみるブログを書いてみたいと思います。
Foundry IQと権限周りについて
エンタープライズで使うなら一番気になるところです。Foundry IQ は権限に忠実です。
- ACL（アクセス制御リスト）の同期：対応ソースでは、ドキュメント単位の権限を同期できる
- Microsoft Purview の機密ラベルを尊重
- 呼び出したユーザーの Microsoft Entra ID で権限フィルタ：クエリ時に、そのユーザーが見てよいコンテンツだけを返す
ただし「権限の効き方は知識ソースによって違う」点は要注意です。ドキュメント単位の権限は、そのソースが対応していて、かつ明示的に同期設定したときだけ効きます。
※ 出典：Foundry IQ FAQ - Microsoft Learn
ここからは実際に触ってみます
ここからは手を動かします。架空のSaaS企業「A社」の社内ナレッジ検索という設定で、Foundry IQ のナレッジベースを実際に作り、Playground で質問を投げてみました。
こんな感じです。
- A社の独自情報（製品ラインナップ・料金プラン・返品/サポートポリシー・FAQ）を Blob に置き、Indexed 知識ソースにする
- Foundry IQ の技術情報を
learn.microsoft.com限定の Web（Remote）知識ソースにする - この2つを1つのナレッジベースに束ねて、横断検索させる
「自社固有の情報（Blob）」と「公開された技術情報（Web）」を1つの質問でまたがせて、回答させる状況を作るのが狙いです。ここが決まると、エージェンティック検索の横断が出来てるといえます。
今回は Microsoft 365 Copilot ライセンスを持っていなかったので、SharePointをデータソースに使えませんでした。
でも触って雰囲気掴むぐらいなのでBlob と Web の2ソースだけで、どこまで賢い体験ができるかを見ていきます。
なお、概念パートで触れた ACL同期や Microsoft Entra ID による権限フィルタも、SharePoint など対応ソースが絡むため、今回の Blob＋Web 構成では検証範囲外です。ここは別の機会に単体で試したいなと考えています。
準備
まずはブログ用のモデルとサンプル文書の準備をしていきます。Foundry プロジェクトに、埋め込みモデル（Blob のベクトル化用）とクエリ計画用の LLM をデプロイしておきます。自分の環境はこんな状態でした。
次に、A社のサンプル文書4枚を Blob コンテナ a-company-docs にアップロードします。
これで素材はそろいました。ここからが本番です。
1. ナレッジベースの器を作る
Foundry ポータル（New Foundry）の左メニュー ナレッジ（Foundry IQ） から始めます。
「ナレッジベースの作成」を押すと、基本構成の入力画面になります。最初はデフォルトで 取得の推論作業＝最小、出力モード＝抽出データになっているのが分かります。
ここを埋めていきます。今回は下記のように設定しました。
※クォータ制限でgpt-5シリーズ入れられなかったのでひとまずgpt-4.1にしました。
| 項目 | 設定値 | ねらい |
|---|---|---|
| 名前 | dev-shunsuke-foundryiq-knowledge | ― |
| チャット入力候補モデル | gpt-4.1 | クエリ計画・回答合成用のLLM |
| 取得の推論作業 | 中 | サブクエリ並列＋繰り返し検索を効かせる |
| 出力モード | 応答の合成 | 抽出データではなく、自然文の合成回答にする |
| 取得の指示 | 下記 | どのソースを優先するかのヒント |
「取得の指示」には、ソースの使い分けを日本語で書いておきました。
A社独自の製品・料金・返品/サポートポリシーに関する質問は Blob ソースを優先。Foundry IQ など技術・仕様に関する質問は Web ソース（learn.microsoft.com）を使う。
先ほど出てきた、「reasoning effort」と「出力モード」が大事です。「抽出データ」のままだと自然文の合成回答になりません。今回のような賢い体験を見たいなら、出力モードは「応答の合成」、取得の推論作業は「中」にするのがおすすめです。
※ この「応答の合成（answer synthesis）」やLLMによるクエリ計画は、執筆時点ではプレビュー扱いの機能です（Foundry ポータル経由で触れる agentic retrieval 機能は、現状まるごとプレビュー提供）。本番採用の際は、この点に注意してください。
2. 知識ソースを2つぶら下げる
次に知識ソースを追加します。「ソースの追加」を開くと、こんな感じで選べます。
2-1. Blob（Indexed）を追加
まず Blob です。ストレージアカウントとコンテナ（a-company-docs）、埋め込みモデル（text-embedding-3-small）を指定して「作成」を押しました。
成功するとこんな感じになります。
2-2. Web（Remote / Bing）を追加
次に Web ソースです。名前を dev-shunsuke-foundryiq-knowledge-web として作成に進むと、はっきりした警告が出ます。
Web ナレッジ ソースの使用には、コストと標準以外の条件が適用されます。（中略）顧客データは Azure コンプライアンス境界の外に流出します。
注意ポイントです。Web ソース（Grounding with Bing）は、①無料トークン枠の対象外で別途課金、②データが Azure のコンプライアンス境界の外に出る、という2点があります。
業界によってはこの一点だけで採用不可になり得るので、事前にしっかり確認した方が良いです。自分も、過去に「使いたいけれど境界の外に出るのが引っかかって諦めた」経験がありました。
Web ソースは「詳細（オプション）」タブで対象ドメインを絞れます。今回は learn.microsoft.com だけに限定しました（サブページを含む）。
ドメインを指定しないとインターネット全体が対象になります。
例えば、「A社が使う技術＝Foundry IQ の公式ドキュメントだけ引かせたい」なら、こうやって絞った方が安定した回答が得られます。
2-3. 2ソースが束なった
これで、1つのナレッジベースに Blob と Web の2ソースがぶら下がりました。
3. エージェントに繋ぐ
作ったナレッジベースを、エージェント shunsuke-for-blog（応答モデル gpt-5）に接続します。
手順に「必ず検索して、その結果を根拠に答えろ」と明示します。
あなたはA社の社内ナレッジアシスタントです。ユーザーの質問には、必ず接続されたナレッジベースを検索し、その結果に基づいて回答してください。自分の一般知識だけで答えず、ナレッジベースの情報を根拠にしてください。回答には必ず出典（引用元）を明示してください。
動作確認
準備が整ったので、Playground で4つの質問を順に投げていきます。
Q1：Blob だけで答えられる質問
A社のStandardプランの月額とSLAは？
回答は一発で正解でした。「Standardプランは月額80,000円（税抜）、SLAは99.9%です。」引用元もちゃんと Blob の 料金プラン.md を指しています。gpt-5 / 16.2秒 / 9,127トークン。まずは Blob 単独ソースが素直に効くことを確認できました。
Q2：Web だけで答えられる質問
Foundry IQ の知識ソースには何種類ある？Indexed と Remote の違いは？
こちらも的確でした。「2種類（Indexed と Remote）」と答えたうえで、Indexed は事前にインデックスへ取り込む方式（問い合わせ時点で必ずしも最新とは限らない）、Remote は都度外部へ問い合わせて最新を取る方式、と整理してくれました。gpt-5 / 19.8秒 / 10,038トークン。引用元を開くと、learn.microsoft.com のページがずらりと並びます。
ちゃんと learn.microsoft.com の中だけを引いています。手順2でドメインを絞った効果が、引用元にそのまま表れました。
Q3：2ソースを横断しないと答えられない質問
ここが今回やりたかったことの一つです。A社の独自情報（Blob）と、Foundry IQ の技術情報（Web）を、1つの質問でまたがせます。
A社の A-Guard を使うにはどのプランが必要？また、その裏側で使われている Foundry IQ はどうやってユーザーの権限を守っているの？
前半（A-Guardのプラン要件）は A社の料金プラン＝Blob にしかありません。後半（Foundry IQ の権限保護の仕組み）は Microsoft の公式ドキュメント＝Web にしかありません。両方を取りに行って統合できて、はじめて満点の答えになります。結果は下記でした。
- プラン要件：A-Guard（権限同期・機密フィルタ）は Standard 以上で利用可能。Starter では不可。Standard は月額80,000円、Enterprise は個別見積り。SharePoint をデータソースにするなら別途 M365 Copilot ライセンスが必要（A社料金には非含）
- Foundry IQ による権限保護：
- A-Guard を有効化すると、検索実行時に「呼び出し元ユーザーの Microsoft Entra ID」でアクセス権を評価し、閲覧権限のあるドキュメントだけを返す
- ドキュメント単位の ACL を Foundry IQ 側で同期・適用
- さらに Microsoft Purview の機密度ラベルにも対応（表示/非表示やマスキング等のポリシーを遵守）
前半は Blob、後半は Web から取ってきて、1つの回答にきれいに合成できています。
これがやりたかったことですし、引用を展開すると、Blob の3ファイルと learn.microsoft.com の4ページ、合わせて14個の出典が混在して並びます。
トレースを確認
回答の下の「トレース」を開くと、内部で何が起きたか追えます。
ツールの呼び出しを見ると、kb-... というツールの中身が operation: knowledge_base_retrieve / type: mcp_call になっています。
Q4：reasoning effort を下げると、どれぐらい変わるのか
最後に、reasoning effort（検索の頑張り度） を実際に動かしてみます。ナレッジベースの設定を 「中」→「最小」 に変更して、まったく同じ Q3 の質問を投げ直しました。
結果が変わりました。
- 回答はぐっと短くなり、引用は4件だけ。しかも4件すべてが Blob（
learn.microsoft.comが消えた） - 権限保護の仕組みについては「ACL の同期により制御している」程度の粒度に後退
- トレースを見ると
Retrieved 8 documents（中のときは22件、最小では8件）
トレースの中間出力には、こんな正直な一文まで残っていました。
具体的な実装方法や追加情報は見つかりませんでした。（中略）該当する詳細な内容は今回の資料からは得られませんでした。
ここが今回いちばんの発見でした。
「最小」だと Web ソースまで手が届かず、Blob だけで答えを組み立てて「詳しいことは分からない」で終わっていた。
一方「中」では22件まで取りに行って、Web も引いて、14出典の統合回答になった。reasoning effort の違いが、取得ドキュメント数と引用の広がりという数字ではっきり見えるわけです。エージェンティック検索の価値は、この差分にあります。
触ってみてわかったこと
概念パートで「質問を複数のサブクエリに分解する」って書きましたが、実際のトレースの queries を見てみると、元の質問がそのまま1つ入っているだけでした。
「分解されたサブクエリがUIにずらっと並ぶ」みたいな見え方ではなかったんですよね。
じゃあ reasoning effort の差はどこに出たの？というと、サブクエリの本数ではなく、取得ドキュメント数（22 vs 8）と引用の広がりのほうに出ていました。内部で分解や反復は動いていそうなんですが、その過程が全部トレースに出るわけではないのかな、という感じです。
検証記事なので、盛らずに「見えた範囲」をそのまま書いておきます。
まとめ
結局 Foundry IQ ってどうなの？かをひととおり触ってみた率直な所感を、◎○△ の推奨度つきで整理しました。
| 観点 | 推奨度 | 所感 |
|---|---|---|
| マルチソース横断の体験 | ◎ | 今回いちばん感動した部分。Blob（A社独自情報）と Web（公式技術情報）を1問でまたいで、引用付きの自然文に統合してくれる。自前RAGで作り込む手間を思うと、設定だけでここまで出るのは素直にすごい |
| マネージドの楽さ | ◎ | チャンク分割・ベクトル化・インデックス作成・権限まわりを丸ごと肩代わり。「下に Azure AI Search がいる」ことさえ意識すれば、あとは本当に楽 |
| reasoning effort の効き | ○ | 「中→最小」で取得件数が 22→8 件、引用も 14→4 件に露骨に減った。検索の頑張り度の価値が数字で見えたのは良い。一方でサブクエリ分解の過程まではトレースに出ず、中身は少しブラックボックス |
| GA/プレビューの線引き | △ | ここが一番モヤった。「6月GA」の実態はGAとプレビューの混在。賢い体験の主要部分はまだプレビューで、本番採用の判断は慎重に |
| Web（Bing）ソース | △ | 便利だが、無料枠外＆データが Azure コンプライアンス境界の外に出る。案件によってはこれだけで採用不可になる |
※ 権限まわり（ACL・Purview・Entra ID）は、今回のライセンス構成では未検証のため、上の評価には含めていません。ここは別途、単体で確かめたいポイントです。
おわりに
Foundry IQ は、「自前RAGの面倒ごとをマネージドで肩代わりしてくれる、よくできたナレッジ層」でした。特にマルチソース横断は、楽さに驚きました。
でもまだまだGAされたばかり＋プレビューもちらほらあるので、ここを確認しながら、今何ができるのかを模索しながら付き合っていくのかなと思います。
まずは無料枠で、皆さんの手元のデータを1つ束ねて、質問を投げてみてください。
少しでも参考になれば嬉しいです！ また書きます！！
