Microsoft Foundry IQは、Azure AI FoundryでAIエージェントやCopilot系アプリに社内データを安全に参照させるための「マネージドなナレッジ層」です。2026年6月5日の公式更新では、Microsoft Foundry IQが一般提供、つまり本番利用を前提に扱いやすい段階へ進んだことが示されました。ポイントは、SharePoint、OneLake、Azure Blob、Azure AI Searchインデックス、Webなどのデータを、プロジェクトごとに個別のRAGパイプラインとして作り直さず、再利用可能なナレッジベースとしてエージェントに接続できるようになる点です。(マイクロソフト アジュール)
ただし、「Foundry IQがGAになった」ことと「周辺機能がすべてGAになった」ことは同じではありません。Microsoft Learnでは、一部機能は一般提供、ほかの機能はプレビューのままであり、利用するREST APIバージョンやポータルの扱いによって利用可能範囲が変わると説明されています。管理者や開発者は、導入前にデータソース、権限、APIバージョン、課金、ネットワーク、既存RAGとの役割分担を確認する必要があります。(Microsoft Learn)
Microsoft Foundry IQとは
Microsoft Foundry IQは、Azure AI Foundryで作成するエージェントに、企業内外のデータを根拠として渡すためのナレッジレイヤーです。従来のRAG構成では、SharePoint用、Blob Storage用、OneLake用など、データソースごとに取り込み、チャンク分割、埋め込み生成、検索、再ランキング、引用表示を個別に設計しがちでした。
Foundry IQでは、これらを「ナレッジベース」と「ナレッジソース」として管理します。ナレッジベースは複数のエージェントから共有でき、エージェントが質問を受けると、Foundry IQが関連データの検索、権限確認、根拠付き回答に必要な情報の返却を担います。Microsoftの説明では、Azure Blob Storage、SharePoint、OneLake、パブリックWebデータなどをナレッジソースとして接続でき、ドキュメントのチャンク化、ベクトル埋め込み生成、メタデータ抽出、増分更新も扱えるとされています。(Microsoft Learn)
実務上は、Foundry IQを「AIエージェント向けの共通検索基盤」と考えると分かりやすいです。営業支援エージェント、社内FAQエージェント、製品サポートエージェント、開発者向け技術調査エージェントが、同じナレッジベースを参照できるため、プロジェクトごとに似た検索基盤を作り直す手間を減らせます。
今回のGAで何が変わるのか
今回の更新で最も重要なのは、Microsoft Foundry IQが「実験的なRAG補助機能」ではなく、Azure AI Foundryにおけるエージェントの知識基盤として位置付けやすくなった点です。Azure Updatesでは、Microsoft Foundry IQが一般提供に到達し、開発者がプロジェクトごとに検索パイプラインを再構築せずに、企業データでエージェントをグラウンディングできるマネージドナレッジレイヤーとして説明されています。(マイクロソフト アジュール)
| 観点 | これまで起きやすかった課題 | Foundry IQ GA後の考え方 |
|---|---|---|
| データ接続 | アプリごとにSharePoint、Blob、OneLake向けの取り込み処理を個別実装する | ナレッジソースとして登録し、ナレッジベースから再利用する |
| RAG設計 | 検索対象の選択、チャンク化、引用、権限制御を個別に実装する | Foundry IQとAzure AI Searchの仕組みに寄せて標準化する |
| エージェント展開 | エージェントごとに別々の検索基盤を持ち、保守が増える | 複数エージェントで同じナレッジベースを共有する |
| セキュリティ | 検索インデックスに入れた情報が過剰に見えるリスクがある | ACL、Microsoft Entra ID、Microsoft Purview感度ラベルを前提に設計する |
| 運用 | 検索品質や失敗原因をアプリ単位で追う必要がある | ナレッジベース、ナレッジソース、検索サービス単位で監視する |
特に開発チームにとっては、「まずRAGパイプラインを自作する」から「まず共通ナレッジベースを設計する」へ発想を変えるきっかけになります。もちろん、すべてをFoundry IQに寄せる必要はありません。細かな検索クエリ制御や独自ランキングが重要なシステムでは、Azure AI Searchを直接使う構成も引き続き選択肢になります。
Azure AI FoundryのAI/Copilot更新として見るべきポイント
Azure AI FoundryでエージェントやCopilot系アプリを作る場合、モデル単体の性能だけでは十分ではありません。社内規程、製品仕様、障害履歴、契約条件、手順書、FAQなど、業務で使う情報に正しくアクセスできなければ、回答は一般論に寄りやすくなります。
Foundry IQは、この「社内データをどう安全に読ませるか」という課題に対するMicrosoft側の標準的な答えに近い位置付けです。Microsoft Learnでは、Foundry IQはAzure、SharePoint、OneLake、Webにまたがる構造化・非構造化データを接続し、エージェントが権限を考慮したナレッジへアクセスできるようにするものと説明されています。(Microsoft Learn)
利用者にとっての変化
エンドユーザーから見ると、Foundry IQの価値は「回答が社内データに基づきやすくなること」です。たとえば、社内FAQエージェントに「今年度の出張精算ルールで、宿泊費の上限はいくらですか」と聞いた場合、一般的な旅費規程の説明ではなく、社内SharePoint上の最新規程を根拠にした回答を期待できます。
また、引用や参照元を返せるため、利用者は「AIがそう言っているから」ではなく、「どの文書のどの情報を根拠にしたのか」を確認しやすくなります。これは、社内承認、法務確認、顧客回答、監査対応のように、根拠確認が重要な業務で特に効果があります。
管理者にとっての変化
管理者にとっては、エージェントごとにデータ接続を許可するのではなく、ナレッジベース単位でデータ利用を設計できる点が大きな変化です。誰が、どのエージェントから、どのデータにアクセスできるのかを、Microsoft Entra ID、ACL、Microsoft Purview感度ラベル、Azure AI Searchの構成と合わせて確認する必要があります。
Microsoftのセキュリティ標準では、Foundry IQをAzure AI Searchと同様に扱い、インデックス化するコンテンツは適切に管理された権限またはMicrosoft Purviewの感度ラベルを持つデータソースから取得することが推奨されています。(Microsoft Learn)
開発者にとっての変化
開発者にとっては、検索処理をアプリ内に抱え込む範囲を減らせます。Foundry IQのナレッジベースAPIを呼び出し、返ってきた根拠データや参照情報をエージェントやチャットUIに渡す構成にしやすくなります。
一方で、APIバージョン差分には注意が必要です。2026-04-01はagentic retrievalの最初の安定APIバージョンとされ、searchIndex、azureBlob、indexedOneLake、webのナレッジソース種別が一般提供となっていますが、SharePoint系ナレッジソースはプレビューのままと説明されています。(Microsoft Learn)
Foundry IQの中核はagentic retrieval
Foundry IQの重要な仕組みが、Azure AI Searchのagentic retrievalです。これは、ユーザーの質問を単一の検索クエリとして投げるのではなく、LLMが質問の意図を分解し、複数のサブクエリを作成し、並列に検索し、意味的に再ランキングし、統合された結果を返す仕組みです。(Microsoft Learn)
たとえば、ユーザーが次のように質問したとします。
「4月以降に変更された請求フローと、営業部が使うべき申請テンプレートを教えてください」
従来の単一検索では、「請求フロー」「営業部」「申請テンプレート」が混ざった曖昧な検索になり、目的の文書に届かないことがあります。agentic retrievalでは、質問を複数の観点に分けて検索するため、以下のような探索に近づきます。
| 分解される観点 | 検索対象の例 |
|---|---|
| 4月以降の変更 | 改訂履歴、更新日、告知文書 |
| 請求フロー | 経理部の業務手順書、承認ルート |
| 営業部向けテンプレート | SharePoint上の申請書、OneLake上の部門別データ |
| 回答の根拠 | 該当文書、参照箇所、引用情報 |
この仕組みは、複雑な社内質問に強い一方で、検索処理のステップが増えるため、レイテンシーやコストの設計も重要になります。Microsoft Learnでは、agentic retrievalはAzure AI Searchの検索・再ランキングに関する料金と、クエリ計画や回答生成で使うAzure OpenAIのトークン料金が関係すると説明されています。(Microsoft Learn)
影響範囲：誰が何を確認すべきか
Foundry IQのGAは、単に開発者向けの新機能追加ではありません。社内データをAIエージェントに接続するため、IT管理者、セキュリティ担当、データ管理者、アプリ開発者、業務部門の確認ポイントが分かれます。
| 対象者 | 確認すべきこと | 具体例 |
|---|---|---|
| Azure管理者 | Azure AI Search、Azure AI Foundry、Azure OpenAI、ネットワーク、課金設定 | 対象リージョン、SearchサービスのSKU、knowledgeRetrievalの設定 |
| Microsoft 365管理者 | SharePointやOneDrive上の権限、外部共有、不要な広範囲権限 | 「全社員」権限の文書がAIから見えてよいか |
| セキュリティ担当 | ACL、感度ラベル、Entra ID、監査ログ、データ境界 | 機密文書が誤って一般向けエージェントに使われないか |
| 開発者 | APIバージョン、SDK、ナレッジベース設計、応答テスト | preview APIから2026-04-01へ移行できるか |
| 業務部門 | 回答品質、参照元、文書の鮮度、利用ルール | 古い手順書が検索上位に出ないか |
| データ管理者 | OneLake、Blob、Searchインデックスの分類と更新 | データソースごとの更新頻度や所有者を決める |
特に見落としやすいのは、AI側の設定ではなく、接続元データの整理です。古い規程、重複した手順書、部門ごとの非公式テンプレートが混在していると、Foundry IQを使っても回答品質は安定しません。ナレッジベースを作る前に、「AIに読ませてよい正本」を決めることが重要です。
管理者が最初に確認すべき設定
Foundry IQを本番展開する前に、管理者は少なくとも次の項目を確認してください。
| 確認項目 | 見るべきポイント | 放置した場合のリスク |
|---|---|---|
| データソースの権限 | SharePoint、Blob、OneLake、Searchインデックスのアクセス権 | 本来見せるべきでない文書が検索対象になる |
| Microsoft Entra ID | ユーザーIDでのアクセス制御が想定通り機能するか | 共有資格情報で過剰な検索結果が返る |
| Microsoft Purview | 感度ラベルが付いているか、運用されているか | 機密区分を無視した回答が生成される |
| Azure AI Search | 対応リージョン、SKU、セマンティック構成、インデックス設計 | 検索品質やコストが安定しない |
| APIバージョン | 2026-04-01安定版で要件を満たせるか | preview依存のまま本番化してしまう |
| 課金設定 | agentic retrievalとAzure OpenAIのトークン課金 | PoC後に想定外のコストが発生する |
| ログと監視 | 検索失敗、参照元、応答品質、利用状況 | 誤回答や情報漏えいの調査が難しくなる |
Microsoftの移行ガイダンスでは、2026-04-01以降、agentic retrievalの課金同意はsemanticSearchとは別のknowledgeRetrievalプロパティで制御されると説明されています。既存のAzure AI Search設定だけを見ていると見落とす可能性があるため、Search Management側の設定も確認しましょう。(Microsoft Learn)
開発者が確認すべき移行ポイント
既にプレビュー版のagentic retrievalやFoundry IQ相当の仕組みを使っている場合、GA対応では「APIバージョンを変えるだけ」で済まない可能性があります。
Microsoft Learnでは、2026-04-01はagentic retrievalの最初の安定APIバージョンであり、プレビュー時代のメッセージベースのクエリ計画や回答合成機能が削除され、最小限の抽出的な検索契約になったと説明されています。(Microsoft Learn)
| 移行観点 | 確認内容 |
|---|---|
| ナレッジソース | searchIndex、azureBlob、indexedOneLake、webは2026-04-01でGA対象。SharePoint系はプレビュー扱いに注意 |
| ナレッジベース | 既存定義を取得し、新しい名前で作成して検証する。既存オブジェクトの上書き前提にしない |
| リクエスト形式 | messagesではなくintentsを使う。maxOutputSizeはmaxOutputSizeInTokensへ変更 |
| 回答合成 | 2026-04-01ではanswer synthesisがサポートされない。回答生成はアプリ側またはプレビュー機能の扱いを確認 |
| 推論強度 | retrievalReasoningEffortのlowやmediumに依存している場合、安定版移行可否を確認 |
| SDK | Python、.NET、Java、JavaScript/TypeScriptのSDK変更点を確認 |
| テスト | 同じ質問で、参照元、件数、回答品質、レイテンシー、コストを比較 |
特に注意したいのは、SharePoint接続です。業務利用ではSharePointが主要データソースになるケースが多いですが、2026-04-01のGA対象として明示されているのはsearchIndex、azureBlob、indexedOneLake、webであり、Indexed SharePointやRemote SharePointのナレッジソースはプレビューのままとされています。(Microsoft Learn)
そのため、本番展開でSharePointを使いたい場合は、次のどちらで進めるかを早めに決める必要があります。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| SharePointナレッジソースをプレビューとして使う | PoC、限定部門、検証環境 | SLAや仕様変更、利用条件を確認する |
| SharePoint内容をAzure AI Searchインデックス化して使う | 本番で安定APIに寄せたい | 権限同期、増分更新、メタデータ設計を自前で厳密に管理する |
既存RAGはFoundry IQに置き換えるべきか
既存のRAG構成がある場合、すぐに全面移行する必要はありません。判断基準は、「共通化したいか」「細かく制御したいか」です。
| 判断軸 | Foundry IQが向いているケース | 既存RAGやAzure AI Search直接利用が向いているケース |
|---|---|---|
| 開発速度 | 複数エージェントへ早くナレッジを接続したい | 検索アルゴリズムを細かく作り込みたい |
| データソース | SharePoint、Blob、OneLake、Webなど複数ソースを扱う | 単一DBや独自APIが中心 |
| ガバナンス | 共通のナレッジベースとして管理したい | アプリごとに厳密なデータ境界を持たせたい |
| 回答品質 | 複雑な質問を分解して検索したい | 単純検索で十分、低遅延が最優先 |
| 運用体制 | プラットフォームチームが共通基盤を持つ | アプリチームが検索基盤まで責任を持つ |
おすすめは、全面移行ではなく「共通ナレッジ化しやすい領域」から始めることです。たとえば、社内規程、製品マニュアル、FAQ、サポートナレッジ、営業資料など、複数エージェントで再利用される情報はFoundry IQに向いています。一方、数ミリ秒単位の応答速度が必要な検索、独自スコアリングが売上に直結する検索、複雑な業務トランザクションを伴う処理は、既存の専用実装を残す判断も妥当です。
展開時に失敗しやすいポイント
Foundry IQの導入で失敗しやすいのは、AIモデルやエージェントのプロンプトばかり調整し、ナレッジの品質を後回しにするケースです。回答品質は、検索対象の文書品質、権限設計、メタデータ、更新頻度に大きく左右されます。
古い文書が正本として扱われる
SharePointやBlobに過去版のPDF、旧テンプレート、作業途中のファイルが残っていると、エージェントが古い内容を根拠にする可能性があります。ナレッジソースに入れる前に、正本フォルダー、アーカイブフォルダー、作業用フォルダーを分けましょう。
権限が広すぎる
AIエージェントは、検索できる情報をもとに回答します。人間が普段見に行かないフォルダーでも、権限が付いていれば検索対象になる可能性があります。「誰でも見られるが、実際には見られていなかった」文書がAIによって表面化することがあります。
引用をUIで見せない
Foundry IQが引用や参照元を返せても、アプリ側のUIがそれを表示しなければ利用者は検証できません。業務システムでは、回答本文だけでなく、参照文書名、更新日、該当箇所へのリンク、信頼できない場合の問い合わせ先を表示する設計が必要です。
PoCの無料枠前提で本番コストを見積もる
PoCでは利用者も文書量も少ないため、コストが小さく見えます。本番では、検索対象チャンク数、サブクエリ数、再ランキング、Azure OpenAIのトークン使用量が増えます。Microsoft Learnでも、agentic retrievalではAzure AI SearchとAzure OpenAIの両方の課金が関係すると説明されています。(Microsoft Learn)
プレビュー機能を本番要件に組み込む
「ポータルで動いたから本番でも問題ない」と判断するのは危険です。Microsoft Learnでは、Microsoft FoundryポータルとAzureポータルではagentic retrieval機能へのアクセスがプレビュー扱いのままであること、また一部機能はAPIバージョンによって一般提供とプレビューが分かれることが示されています。(Microsoft Learn)
導入前の実務チェックリスト
Foundry IQを試す前に、次の順番で確認すると手戻りを減らせます。
| 順序 | 作業 | 完了の目安 |
|---|---|---|
| 1 | ユースケースを1つに絞る | 「社内規程回答」「製品FAQ」など、評価しやすい業務に限定する |
| 2 | 正本データを決める | AIに読ませるフォルダー、コンテナー、OneLake領域を明確にする |
| 3 | 権限を棚卸しする | 一般社員、管理職、部門担当者、外部ユーザーで検索結果が変わるか確認する |
| 4 | ナレッジソースを選ぶ | GA対象のsearchIndex、azureBlob、indexedOneLake、webで足りるか確認する |
| 5 | APIバージョンを決める | 2026-04-01安定版で足りるか、プレビュー機能が必要か判断する |
| 6 | テスト質問を作る | 正解が分かっている質問、曖昧な質問、権限境界を試す質問を用意する |
| 7 | コストを測る | 利用者数、質問数、チャンク数、トークン量から月額を見積もる |
| 8 | 引用表示を設計する | 回答と一緒に参照元を表示し、利用者が検証できるようにする |
| 9 | 運用ルールを決める | データ更新、誤回答報告、権限変更、ログ確認の担当を決める |
特に「権限境界を試す質問」は必須です。たとえば、人事部だけが見られる文書を一般社員アカウントで質問し、回答に含まれないことを確認します。Microsoftのガイダンスでも、Azure Searchを使うAIソリューションでは、異なるロールの実ユーザーアカウントで検索クエリをテストし、制限されたコンテンツが本当にフィルターされるか確認することが推奨されています。(Microsoft Learn)
具体的な活用シーン
社内問い合わせエージェント
人事、総務、経理、情報システム部門の問い合わせを、SharePoint上の規程や手順書に基づいて回答します。重要なのは、回答に必ず参照元を付けることです。休暇制度、経費精算、セキュリティ申請などは制度変更が起きやすいため、文書の更新日もUIに出すと安心です。
製品サポートエージェント
Azure BlobやOneLakeに保存された製品マニュアル、サポート履歴、FAQ、リリースノートを検索対象にします。ユーザーの質問が複数要素を含む場合でも、agentic retrievalで関連する観点に分けて検索しやすくなります。
営業支援Copilot
営業資料、提案書テンプレート、競合比較、導入事例をナレッジベース化します。営業担当が「製造業向けに使える最新の提案材料を教えて」と聞いたとき、該当資料を根拠付きで返せる構成が考えられます。ただし、顧客別の機密情報や未公開価格表を混在させる場合は、権限設計を厳密に行う必要があります。
開発者向け技術ナレッジ
社内の設計書、API仕様、障害対応メモ、運用Runbookを対象にします。新任メンバーが「このAPIの認証方式と障害時の切り分け手順を教えて」と聞いたとき、設計書と運用手順をまたいで回答できる可能性があります。
本番展開のおすすめ手順
いきなり全社展開するのではなく、段階的に進めるのが安全です。
| フェーズ | 目的 | やること |
|---|---|---|
| PoC | 技術的に動くか確認する | 限定データでナレッジベースを作り、回答品質と引用を確認 |
| パイロット | 業務で使えるか確認する | 1部門、少人数、実データで権限と運用を検証 |
| 本番準備 | セキュリティと運用を固める | 監査、ログ、コスト、誤回答対応、データ更新ルールを整備 |
| 本番展開 | 利用範囲を広げる | 対象部署やエージェントを増やし、共通ナレッジベースを再利用 |
| 改善運用 | 品質を継続的に上げる | 検索失敗、低評価回答、古い文書を定期的に見直す |
この流れで重要なのは、PoCの成功を「回答がそれらしく返った」だけで判断しないことです。業務で使えるかどうかは、正答率、引用の妥当性、権限境界、レイテンシー、コスト、利用者の再確認負荷まで見て判断します。
管理者と開発者が今すぐやるべきこと
Microsoft Foundry IQのGAは、Azure AI Foundryでエージェントを本格活用する組織にとって、社内ナレッジ基盤を標準化する好機です。一方で、権限やAPIバージョンを曖昧にしたまま導入すると、情報漏えい、古い情報に基づく回答、コスト増、プレビュー依存といった問題が起きやすくなります。
まずは次の3点から始めるのが現実的です。
- AIに読ませたいデータを「正本」「アーカイブ」「対象外」に分ける
- 2026-04-01の安定APIで要件を満たせるか確認する
- 一般社員、管理者、部門限定ユーザーで権限テストを行う
Foundry IQは、単なる検索機能ではなく、AIエージェントに企業データを安全に渡すための共通基盤です。最初の導入範囲を小さく絞り、ナレッジ品質、権限、引用、コストを確認しながら展開すれば、Azure AI Foundryで作るエージェントやCopilot系アプリの実用性を大きく高められます。
コメント