Foundry IQは、Azure AI Foundry（現行ドキュメントではMicrosoft Foundry表記）で作成するエージェントに、社内データやWeb情報を安全に接続するための「知識レイヤー」です。結論から言うと、今回の公式情報で重要なのは、Foundry IQの一部機能がREST API 2026-04-01で一般提供（GA）になった一方、ポータル操作や高度なAgentic Retrieval機能の一部は引き続きプレビュー扱いである点です。管理者は権限・課金・データ境界を、開発者はAPIバージョンとリクエスト形式の変更を必ず確認する必要があります。(Microsoft Learn)
特に、すでにAzure AI SearchやAzure AI FoundryでRAG構成を試している組織では、「ポータルで動いたから本番も同じ構成でよい」と判断すると失敗しやすくなります。2026年5月中旬時点の公式情報では、GAとして使える範囲とプレビューの範囲が明確に分かれており、移行時にはナレッジソース、ナレッジベース、取得リクエスト、課金同意の見直しが必要です。(Microsoft Learn)
Foundry IQとは、エージェントに企業データを渡すための知識基盤
Foundry IQは、生成AIエージェントが社内文書、Azure Blob Storage、SharePoint、OneLake、既存のAzure AI Searchインデックス、Web情報などを参照できるようにする仕組みです。モデル単体では、企業の非公開データや最新の業務文書にはアクセスできません。そこでFoundry IQのナレッジベースを使い、エージェントの回答を社内データにグラウンディングします。(Microsoft Learn)
Foundry IQの中核は、次の3つです。
| 構成要素 | 役割 | 実務での見方 |
|---|---|---|
| Knowledge base | どの知識ソースを検索するか、検索動作をどう制御するかを定義する上位リソース | エージェントが参照する「知識の入口」 |
| Knowledge source | Azure Blob Storage、OneLake、Search index、Webなどへの接続定義 | 実際のデータ置き場や検索対象 |
| Agentic retrieval | 複雑な質問を処理し、関連情報を取得・統合する検索パイプライン | 従来の単純検索より、複合的な質問に強い検索処理 |
Foundry IQのナレッジベースは、複数のエージェントで共有できます。たとえば、人事FAQエージェント、社内規程確認エージェント、ヘルプデスクエージェントが、同じ人事規程ナレッジベースを参照する構成が可能です。Azure AI Searchが基盤となり、インデックス作成や検索処理を担います。(Microsoft Learn)
なお、Microsoftの現行ドキュメントでは「Azure AI Foundry」から「Microsoft Foundry」への名称変更が進んでいます。旧Azure AI Foundryの情報を探している場合でも、現在のMicrosoft Foundryドキュメントに同じ系統の情報が掲載されていることがあります。(Microsoft Learn)
何が変わったのか：GA機能とプレビュー機能の切り分けが重要
今回のポイントは、「Foundry IQ全体が完全にGAになった」と単純に理解しないことです。公式情報では、REST API 2026-04-01で一部のAgentic Retrieval機能が一般提供される一方、Microsoft FoundryポータルやAzureポータルからのAgentic Retrieval機能は引き続きプレビュー専用アクセスとされています。(Microsoft Learn)
| 項目 | 2026年5月中旬時点の扱い | 確認ポイント |
|---|---|---|
Search Service REST API 2026-04-01 | 安定版API | 本番利用ではまずこのAPIで実現できるか確認する |
| Knowledge base | 一部GA | GAのナレッジソースを使った抽出的検索が中心 |
searchIndex Knowledge Source | GA | 既存のAzure AI Searchインデックスを活用しやすい |
azureBlob Knowledge Source | GA | ただし文書レベル権限の一部設定はプレビュー扱い |
indexedOneLake Knowledge Source | GA | ingestionPermissionOptionsは2026-04-01で非対応 |
web Knowledge Source | GA | Web要約用のモデル参照やデータ境界の確認が必要 |
| Indexed SharePoint / Remote SharePoint | プレビュー | 本番適用前にSLAや運用リスクを確認する |
| ポータルでのAgentic Retrieval操作 | プレビュー扱い | PoC向き。本番コードとはAPI差分を確認する |
| Answer synthesis、構成可能なreasoning effort、メッセージベースのquery planning | プレビュー | 必要な場合は2025-11-01-previewを検討する |
Azure AI Searchの更新情報では、2026-04-01は一般提供されたナレッジソースからの抽出的検索をサポートし、query planning、answer synthesis、構成可能なreasoning effortなどはプレビュー機能として2025-11-01-previewが必要とされています。つまり、安定版を選ぶと機能は絞られますが、本番運用に向いた契約で使いやすくなります。(Microsoft Learn)
Foundry IQでできること
Foundry IQは、単なるファイル検索ではありません。エージェントが複数の情報源を参照し、権限を考慮しながら、引用付きの回答材料を取得するための仕組みです。
主な機能は次のとおりです。
| 機能 | 内容 | 活用例 |
|---|---|---|
| 複数データソース接続 | Azure Blob Storage、SharePoint、OneLake、Webなどをナレッジソースとして扱う | 社内規程、製品マニュアル、ナレッジ記事をまとめて検索 |
| チャンク化・埋め込み・メタデータ抽出 | インデックス化対象の文書を検索しやすい単位に処理 | PDFマニュアルを段落単位で検索対象にする |
| キーワード・ベクトル・ハイブリッド検索 | 全文検索と意味検索を組み合わせる | 正確な製品名と曖昧な質問の両方に対応 |
| Agentic Retrieval | 複雑な質問を分解し、複数検索結果を統合 | 「A製品とB製品の保証条件の違い」を比較 |
| 権限考慮 | Microsoft Entra ID、ACL、Microsoft Purview感度ラベルなどを考慮 | 部署ごとに見られる文書を制御 |
| 引用付きの結果返却 | 取得元の文書や参照情報を含める | 回答の根拠確認や監査に使う |
公式ドキュメントでは、Foundry IQがACL同期、Microsoft Purview感度ラベル、Microsoft Entra IDによる呼び出し元IDでのクエリ実行をサポートすることが説明されています。機密情報を扱う社内エージェントでは、この「誰が質問したか」を検索時に反映する設計が重要です。(Microsoft Learn)
管理者が確認すべき設定と影響範囲
APIバージョンとポータルの扱いを分けて管理する
管理者が最初に確認すべきなのは、現在の環境がどのAPIバージョンでナレッジベースやナレッジソースを作成しているかです。ポータルで作成したオブジェクトはプレビューAPIのスキーマに基づいている場合があり、安定版APIのコードからそのまま扱えるとは限りません。
特に、以前のプレビューで作成した「knowledge agent」は、後続のAPIでは「knowledge base」へ名称・ルート・プロパティが変更されています。既存コードに古い名称やエンドポイントが残っている場合は、移行対象として洗い出す必要があります。(Microsoft Learn)
権限はRBACとマネージドIDを基本にする
本番展開では、APIキーだけに依存するよりも、Microsoft Entra ID、マネージドID、RBACを使った構成が推奨されます。Foundry Agent ServiceとAzure AI Searchを接続する場合、Foundry側のプロジェクト、Azure AI Search、モデルデプロイのそれぞれに必要なロールを割り当てる必要があります。(Microsoft Learn)
代表的な確認項目は次のとおりです。
| 対象 | 確認する権限 | 目的 |
|---|---|---|
| Azure AI Search | Search Service Contributor | ナレッジソースやナレッジベースの作成・管理 |
| Azure AI Search | Search Index Data Reader | 検索インデックスの読み取り |
| Azure AI Search | Search Index Data Contributor | インデックスへのデータ投入が必要な場合 |
| Foundryプロジェクト | Foundry User | モデルデプロイやエージェント利用 |
| Foundryプロジェクト | Foundry Project Manager | MCP接続やプロジェクト接続の作成 |
| モデル提供リソース | Cognitive Services User | Search serviceのマネージドIDがモデルを利用するため |
FoundryのRBACロール名は最近変更されており、旧称の「Azure AI User」「Azure AI Project Manager」などが残って表示される場所がある可能性があります。ロールIDと中核権限は変わらないとされていますが、ドキュメントやポータル表示の差で混乱しやすいため、運用手順書では新旧名称を併記しておくと安全です。(Microsoft Learn)
ユーザーごとのアクセス制御は「検索時」に効かせる
社内向けエージェントで最も危険なのは、検索インデックスに入っている情報を全員が見られる状態にしてしまうことです。Foundry IQを使う場合でも、インデックス作成時に権限メタデータを取り込み、クエリ時にユーザーのアクセストークンを渡す設計が必要です。
Azure AI Searchの取得APIでは、ユーザーIDに基づく権限フィルタリングのためにx-ms-query-source-authorizationヘッダーを使う方法が示されています。Remote SharePoint Knowledge Sourceでは、SharePoint側がクエリ時に権限を直接適用します。(Microsoft Learn)
実務では、次のように確認します。
| 確認項目 | NG例 | 推奨対応 |
|---|---|---|
| インデックスに権限情報があるか | 文書本文だけをインデックス化している | ACLやユーザー・グループ情報をメタデータとして取り込む |
| クエリ時にユーザーIDが渡っているか | アプリ共通のAPIキーだけで検索している | ユーザートークンを渡し、本人権限で絞り込む |
| テストユーザーを分けて検証したか | 管理者アカウントだけでテストしている | 一般社員、部門限定ユーザー、権限なしユーザーで比較する |
| 引用元の閲覧権限を確認したか | 回答本文だけ確認している | referencesに含まれる文書をユーザーが本当に閲覧可能か確認する |
Web Knowledge Sourceはデータ境界とコンプライアンスを確認する
Web Knowledge Sourceは、最新の公開Web情報をエージェントの根拠として使える便利な機能です。一方で、公式ドキュメントでは、Web Knowledge Sourceに送信されるデータがAzureのコンプライアンス境界やGeo境界の外に流れる可能性があること、Microsoft Data Protection Addendumが適用されないことが明記されています。(Microsoft Learn)
そのため、社内の機密情報や顧客情報を含む質問をWeb Knowledge Sourceに渡す設計は慎重に判断する必要があります。利用する場合は、少なくとも次の制御を検討してください。
| リスク | 対策 |
|---|---|
| 社内情報が外部検索に渡る | Web検索に渡すクエリを制限する |
| 不要な公開サイトを参照する | 許可ドメインを指定する |
| コンプライアンス要件に抵触する | セキュリティ・法務・データ保護担当のレビューを通す |
| Web結果の鮮度や正確性にばらつきがある | 回答に引用を表示し、重要判断では一次情報を確認させる |
課金同意はsemanticSearchではなくknowledgeRetrievalも確認する
2026-04-01以降では、Agentic Retrievalの課金同意がsemanticSearchとは別のknowledgeRetrievalプロパティで管理されます。既存環境でsemanticSearch=standardを設定していても、Agentic Retrievalの有料利用を有効化するにはknowledgeRetrieval=standardの設定が必要です。(Microsoft Learn)
これは管理者が見落としやすい変更です。Azure AI Searchの課金管理を担当しているチームと、Azure AI Foundryのエージェント開発チームが分かれている場合は、どちらがknowledgeRetrievalを管理するのかを決めておきましょう。
開発者が確認すべきAPI変更点
2026-04-01ではリクエスト形式が変わる
プレビューAPIから2026-04-01へ移行する場合、取得リクエストの形が変わります。特に大きいのは、messagesではなくintentsを使う点です。また、maxOutputSizeはmaxOutputSizeInTokensに変更され、retrievalReasoningEffortやalwaysQuerySourceは2026-04-01では使えません。削除済みフィールドを送ると400 Bad Requestになるため、単にAPIバージョンだけを書き換える移行は危険です。(Microsoft Learn)
| 項目 | プレビューAPIでの考え方 | 2026-04-01での考え方 |
|---|---|---|
| ユーザー入力 | messages | intents |
| 出力サイズ | maxOutputSize | maxOutputSizeInTokens |
| reasoning effort | 指定可能な場合あり | retrievalReasoningEffortは非対応 |
| 特定ソースの強制検索 | alwaysQuerySourceを使う場合あり | 非対応 |
| 会話履歴 | メッセージベースのマルチターン構成 | 継続的なmessages transcriptは維持しない |
| 回答形式 | answer synthesisを使える場合あり | 抽出的なgrounding content、activity、referencesが中心 |
2026-04-01の取得リクエストは、たとえば次のような形になります。
POST {{search-endpoint}}/knowledgebases/{{knowledge-base-name}}/retrieve?api-version=2026-04-01
Content-Type: application/json
{
"intents": [
{
"type": "semantic",
"search": "就業規則における有給休暇の付与条件を要約してください"
}
],
"knowledgeSourceParams": [
{
"knowledgeSourceName": "hr-policy-ks",
"kind": "searchIndex",
"includeReferences": true,
"includeReferenceSourceData": true,
"rerankerThreshold": 2.5
}
],
"maxRuntimeInSeconds": 30,
"maxOutputSizeInTokens": 6000
}この例で重要なのは、アプリ側が「検索結果をそのまま最終回答として扱う」のか、「取得したgrounding contentとreferencesを別のLLM呼び出しに渡して回答文を生成する」のかを明確に分けることです。2026-04-01ではanswer synthesisがサポートされないため、自然な回答文の生成まで必要な場合は、アプリ側の責任範囲が増えます。(Microsoft Learn)
responseのactivityとreferencesをログに残す
Foundry IQを使った検索では、回答本文だけを見て成否を判断しないでください。取得結果には、検索処理の実行内容を示すactivityと、引用元を示すreferencesが含まれます。公式ドキュメントでは、activityにサブクエリ、処理時間、semantic rankerの使用状況、エラーなどが含まれることが説明されています。(Microsoft Learn)
本番運用では、次の情報をログとして残すと原因調査がしやすくなります。
| ログ項目 | 使い道 |
|---|---|
| knowledge base名 | どの知識基盤を使ったか追跡する |
| knowledge source名 | どのデータソースに問い合わせたか確認する |
| activity | 遅延、部分失敗、検索条件を確認する |
| references | 回答根拠の文書を確認する |
| HTTPステータス | 200 OKと206 Partial Contentを区別する |
| ユーザーIDまたは権限スコープ | 権限フィルタリングの検証に使う |
206 Partial Contentが返った場合、すべての検索に失敗したわけではなく、一部のナレッジソースのみ失敗している可能性があります。回答が返ったから正常と判断せず、activity内のエラーを確認する運用が必要です。(Microsoft Learn)
MCP接続を使う場合はFoundry Agent Service側の権限も見る
Foundry IQのナレッジベースは、Foundry Agent ServiceからMCPを通じて呼び出せます。エージェントがナレッジベースをツールとして使う構成では、Azure AI Search側だけでなく、FoundryプロジェクトのマネージドID、プロジェクト接続、MCPツール利用権限も確認してください。(Microsoft Learn)
PoCでは開発者の個人権限で動いていても、本番環境ではアプリ、プロジェクト、検索サービス、モデルデプロイの認証主体が変わることがあります。デプロイ前に、実際の本番IDで接続テストを行うことが重要です。
移行時にやるべきこと
プレビューAPIで作成した既存のAgentic Retrieval構成を2026-04-01へ移行する場合は、既存オブジェクトを上書きするのではなく、新しい名前のオブジェクトを作成して検証する流れが推奨されています。公式ドキュメントでも、移行は「新しい一意名のオブジェクトを作成する」こと、古いオブジェクトは完全にテスト・展開した後に削除することが示されています。(Microsoft Learn)
| 手順 | 作業内容 | 注意点 |
|---|---|---|
| 現状確認 | 既存のAPIバージョン、knowledge source種別、knowledge base定義を一覧化 | ポータル作成分はプレビューschemaの可能性がある |
| GA/プレビュー判断 | 2026-04-01で足りるか、2025-11-01-previewが必要か判断 | answer synthesisやSharePoint系が必要ならプレビュー要件を確認 |
| Knowledge source再作成 | 既存定義を取得し、新しい名前で作成 | azureBlobとindexedOneLakeではingestionPermissionOptionsを外す |
| Knowledge base再作成 | knowledgeSourcesを引き継ぎ、非対応プロパティを削除 | outputMode、answerInstructions、retrievalInstructionsは非対応 |
| retrieve request更新 | messagesをintentsへ変更 | maxOutputSizeInTokensなどプロパティ名を修正 |
| 課金設定確認 | knowledgeRetrievalを確認 | 有料利用が必要ならstandardを設定 |
| 動作検証 | 200 OK、206 Partial Content、references、activityを確認 | 回答本文だけで判断しない |
| 切り替え | エージェントやアプリの参照先を新オブジェクトへ変更 | ハードコードされた名前を洗い出す |
| 旧環境削除 | 検証完了後に旧オブジェクトを削除 | 先に削除すると切り戻しできない |
移行では、インデックスやコンテンツ自体を必ずしも作り直す必要はありません。2025-11-01-previewから2026-04-01へ移行する場合、既存のインデックスとコンテンツは維持でき、主にナレッジベーススキーマとretrieve requestの形を更新することになります。(Microsoft Learn)
本番展開で失敗しやすいポイント
ポータルの成功を本番APIの成功と混同する
Microsoft FoundryポータルやAzureポータルのAgentic Retrieval機能は、2026年5月中旬時点でもプレビュー専用アクセスとされています。ポータルのPlaygroundで動作確認できても、安定版APIの仕様とは異なる場合があります。PoCはポータルで始めても、本番化では必ず利用APIバージョンを固定し、コードで再検証してください。(Microsoft Learn)
2026-04-01に非対応のプロパティを送り続ける
移行時に多いエラーは、プレビュー時代のJSONをそのまま使い、retrievalReasoningEffort、alwaysQuerySource、outputModeなどを送ってしまうことです。2026-04-01では削除されたフィールドを許容しないため、400 Bad Requestになります。(Microsoft Learn)
対策は、APIバージョンごとにリクエスト生成処理を分けることです。設定ファイルだけでAPIバージョンを切り替える実装にすると、古いプロパティが混入しやすくなります。
権限検証を管理者アカウントだけで済ませる
管理者アカウントで検索すると、ほとんどの文書が見えてしまいます。その状態で「権限フィルタリングが動いている」と判断すると、一般ユーザーに見せてはいけない文書が回答に混ざるリスクがあります。
検証では、最低でも次の3種類のユーザーを用意してください。
| テストユーザー | 確認すること |
|---|---|
| 一般社員 | 公開範囲の文書だけが返るか |
| 部門限定ユーザー | 自部門文書は返り、他部門文書は返らないか |
| 権限なしユーザー | referencesにも閲覧不可文書が含まれないか |
Web Knowledge Sourceを無制限に使う
Web Knowledge Sourceは便利ですが、何でも外部検索に投げてよいわけではありません。ドメイン制限を設定しない場合、公開インターネット全体にアクセスできる構成になります。社内FAQや顧客対応で使う場合は、まず許可ドメインを絞り、外部検索に渡す質問内容を制御してください。(Microsoft Learn)
コストを「検索回数」だけで見積もる
Agentic Retrievalは、従来の単一クエリ型検索と違い、トークンベースの課金要素が増えます。Azure AI Searchではsubquery実行やsemantic rankingに関わるretrieval tokenが課金対象になり、Azure OpenAI側ではLLMによるquery planningやanswer synthesisに関わる入出力トークンが課金されます。(Microsoft Learn)
そのため、コスト見積もりでは「1日何回質問されるか」だけでなく、次の項目を確認してください。
| 見積もり項目 | 見るべき理由 |
|---|---|
| 1質問あたりの平均サブクエリ数 | 検索処理とsemantic rankingの負荷に影響 |
| チャンク数とチャンクサイズ | rerank対象が増えるとトークン消費が増える |
| LLMを使う処理の有無 | query planningやanswer synthesisでAzure OpenAI課金が発生 |
knowledgeRetrievalのプラン | 無料枠後の従量課金に影響 |
| 最大実行時間・最大出力トークン | レイテンシとコストの上限管理に関係 |
用途別のおすすめ構成
Foundry IQの構成は、すべての用途で同じにする必要はありません。安定性、権限、鮮度、開発速度のどれを優先するかで選びます。
| 用途 | 推奨構成 | 判断理由 |
|---|---|---|
| 社内規程・製品マニュアルの本番RAG | searchIndexまたはazureBlob + 2026-04-01 | GA範囲で構成しやすく、運用管理しやすい |
| データレイク上の業務データ活用 | indexedOneLake + 2026-04-01 | OneLake連携を活用できる |
| SharePoint文書を権限付きで直接検索 | Remote SharePoint Knowledge Source | 便利だがプレビュー扱いを前提にリスク評価が必要 |
| 最新Web情報を補完したい | Web Knowledge Source + 許可ドメイン制限 | 最新情報を補えるが、データ境界と外部検索の管理が必要 |
| まずPoCしたい | Microsoft Foundryポータル | 早く試せるが、本番化前にAPI仕様との差分確認が必要 |
| 自然な最終回答までFoundry側で生成したい | 2025-11-01-previewのanswer synthesis検討 | 機能は便利だがプレビュー条件を確認する |
実務では、最初から多機能なプレビュー構成を本番に入れるより、「GA範囲で検索と引用を安定させる」「回答生成はアプリ側で制御する」「必要な機能だけプレビューを検証する」という段階的な進め方が安全です。
管理者・開発者向けチェックリスト
展開前には、次の項目を確認してください。
| 区分 | チェック項目 |
|---|---|
| API | 利用するREST APIバージョンを決めたか |
| API | 2026-04-01と2025-11-01-previewの差分を把握したか |
| 移行 | 既存のknowledge agent / knowledge base / knowledge sourceを一覧化したか |
| 移行 | 新しい一意名のオブジェクトで検証する計画にしたか |
| 権限 | Search service、Foundry project、モデルリソースのRBACを設定したか |
| 権限 | ユーザー単位のアクセス制御をテストしたか |
| セキュリティ | Web Knowledge Sourceの利用可否を社内ポリシーで確認したか |
| 課金 | knowledgeRetrievalの設定と無料枠・有料利用の扱いを確認したか |
| 運用 | activity、references、HTTPステータスをログに残す設計にしたか |
| 本番化 | ポータルPoCと本番コードのAPI差分を検証したか |
まとめ：Foundry IQは「安全に知識を渡す設計」が成否を分ける
Foundry IQは、Azure AI Foundryで作るエージェントに企業データやWeb情報を接続するための強力な知識基盤です。今回の公式情報で押さえるべき点は、一部機能が2026-04-01でGAになった一方、ポータル操作やanswer synthesis、構成可能なreasoning effort、SharePoint系の一部機能などはプレビュー扱いが残っていることです。
次に取るべき行動は明確です。まず既存環境のAPIバージョンとナレッジソースを棚卸しし、GA範囲で運用できるかを判断してください。そのうえで、RBAC、ACL、knowledgeRetrieval、Web Knowledge Sourceのデータ境界を確認し、activityとreferencesを使った検証を行います。Foundry IQは「つなげば終わり」の機能ではなく、権限・引用・コスト・API差分を設計に組み込むことで、本番で使えるエージェント基盤になります。
コメント