3行まとめ
このテーマをもう少し広げて見るなら、Work IQ APIsは6月16日に一般提供へ：Copilot Credits課金、MCP/REST、管理者の確認ポイント と Microsoft 365 Business with Copilotは7月1日に恒久SKUへ：Standard/Premium、23.50ドル/32ドル、既存契約の確認ポイント も合わせて確認してください。Foundry IQの知識ベース、MCP、権限継承を、Microsoft 365側のWork IQ APIと課金条件に接続して読めるため
Foundry IQ knowledge basesは、エージェントが企業データを再利用する知識層として本番候補に入りました。
MCP-compatible hostやclientからknowledge baseへアクセスできる接続口として確認します。
Serverless Developer tierはPoCに向きますが、本番判断ではSLA、リージョン、移行制限を分けて見ます。
Entra ID、RBAC、ACL、network isolation、Azure AI Search側の課金を同じ確認表で追います。
この記事では、便利さより先にGAとpreviewの境界、権限、ネットワーク、料金の確認順を重視します。
- MicrosoftはBuild 2026後の公式整理で、Microsoft IQ、Work IQ、Fabric IQ、Foundry IQを、エージェントへ業務文脈を渡す知識層として位置づけています。Foundry IQはAzure、SharePoint、OneLake、Webなどの企業データを、エージェントが再利用できるknowledge baseとして扱う領域です。
- 2026年6月2日のMicrosoft Foundry Blogでは、Foundry IQ knowledge basesが一般提供と説明されました。GAに含まれる範囲と、Serverless Developer tier、security updates、data pipeline updatesなどのpreview範囲は分けて読む必要があります。
- 導入前に見るべき軸は、MCPでつながるかだけではありません。Azure AI Searchとの関係、Entra ID/RBAC、ACLとSharePoint権限、ネットワーク分離、ServerlessのSLAとリージョン、課金開始時期を同じ確認表で見るのが安全です。
Build 2026の発表群は、単発のAIニュースとして読むと輪郭がぼやけます。GitHub Copilot、Microsoft 365 Copilot、Microsoft Foundry、Azure AI Search、Agent 365、Teamsがそれぞれ進んでいるように見えて、Microsoftが押し出している本筋は「エージェントを企業データ、業務プロセス、統制の中で動かす」方向です。
その中でFoundry IQは、Microsoft Foundry側の知識層です。Microsoft 365の仕事文脈を扱うWork IQとは役割が違います。Work IQ APIsの一般提供予定やCopilot Creditsの読み方は、すでに<a href="https://msft-watch.blog.mo-gmo.com/msft-41-work-iq-apis-ga-copilot-credits-mcp-rest-admin-checkpoints/">Work IQ APIsは6月16日に一般提供へ</a>で整理しました。本稿では、話をFoundry IQに限定します。
確認日は2026年6月12日JSTです。国内外の専門メディアや開発者コミュニティでもBuild 2026のagent platform文脈は続いていますが、この記事で仕様、料金、権限、提供状態の根拠にするのはMicrosoft、Azure、Microsoft Learnの一次情報です。Microsoft Watch JapanはMicrosoft Corporationおよび関係会社とは非提携の独立サイトであり、本記事は製品利用と導入判断の補助を目的としています。
Foundry IQはMicrosoft IQの中で何を担当するのか
優劣ではなく、どのデータを、どのエージェントに、どの統制で渡すかで役割を分けます。
MicrosoftのBuild 2026後の公式発信では、AIを単体のチャットやモデル選択だけで見ない書き方が増えています。Azure Blogの2026年6月11日記事は、Microsoft IQを企業向けのintelligence layerとして紹介し、その中でWork IQ、Fabric IQ、Foundry IQ、Web IQに触れています。
ここで大事なのは、IQという名前が付いているものを同じ機能として扱わないことです。Microsoft LearnのFoundry IQ説明では、Work IQ、Fabric IQ、Foundry IQは、それぞれ違う種類の組織文脈を扱うと整理されています。
Work IQ、Fabric IQ、Foundry IQは同じ知識層ではない
Work IQはMicrosoft 365側の仕事文脈です。メール、ドキュメント、会議、チャット、ワークフローのように、組織の仕事がどう進むかを理解するための層として説明されています。
Fabric IQはMicrosoft Fabric側のビジネスデータの層です。OneLakeやPower BIなど、分析・業務データをセマンティックに扱う文脈で出てきます。
Foundry IQは、エージェントが使う企業知識を管理する層です。Microsoft Learnでは、Foundry IQを「managed knowledge layer」とし、Azure、SharePoint、OneLake、Webにまたがる構造化・非構造化データを接続し、permission-awareな知識としてエージェントへ渡すものと説明しています。
つまり、Foundry IQを「Microsoft 365 Copilotの中の新機能」とだけ見ると狭すぎます。むしろ、Microsoft FoundryやAzure AI Searchを使って、社内データをエージェントアプリへ渡す基盤として見る方が近いです。
Knowledge baseは複数エージェントで共有する前提
Foundry IQの中心はknowledge baseです。Microsoft Learnの説明では、1つのknowledge baseを複数のエージェントへ接続でき、Azure Blob Storage、SharePoint、OneLake、public web dataなどのknowledge sourcesを扱えるとされています。
従来の個別RAG実装では、部署ごと、アプリごと、チャットボットごとに、取り込み、分割、embedding、検索、権限確認、引用表示を作り直しがちでした。Foundry IQの狙いは、その部分をknowledge baseとして再利用し、エージェント側は同じ知識層を呼び出せるようにすることです。
Microsoft Learnは、Foundry IQのcapabilitiesとして、文書chunking、vector embedding generation、metadata extraction、incremental data refresh、keyword/vector/hybrid queries、agentic retrieval、citations、ACL同期、Purview sensitivity labels、callerのMicrosoft Entra identityによるクエリ実行を挙げています。
ここで「callerのEntra identity」と「permission-aware」を見落とさない方がよいです。Foundry IQは、単に検索結果をモデルへ渡す機能ではありません。社内で使うなら、誰がどの文書を検索できるのか、どのラベルやACLが効くのかまで含めて評価する必要があります。
Azure AI Searchとの関係を先に押さえる
Foundry IQは、Azure AI Searchと切り離して読めません。Microsoft Learnは、Foundry IQ knowledge baseがagentic retrievalを処理し、その下のindexingとretrieval infrastructureをAzure AI Searchが提供すると説明しています。Azureの価格ページでも、Foundry IQ knowledge basesにはsubscriptionとstandard agentic retrieval planが必要で、Foundry IQ agentic retrieval activityはAzure AI Searchとして課金されると説明されています。
既存のAzure AI Search利用者にとっては、Foundry IQを「まったく別の箱」と見るより、「Azure AI Search上のagentic retrievalとknowledge baseを、Microsoft Foundryのエージェント運用へつなぐもの」と読んだ方が導入判断に近づきます。
一方で、既存の検索サービスを使っていれば自動的にFoundry IQ運用が完成するわけでもありません。knowledge source、retrieval reasoning effort、MCP接続、権限、課金単位、preview機能の依存を別々に確認する必要があります。
根拠として見る一次情報
このセクションの根拠は、Microsoft Learnの「What is Foundry IQ?」、AzureのFoundry IQ製品ページ、Azure BlogのBuild 2026整理です。Azure Blogは需要と位置づけの根拠、Microsoft Learnと製品ページは仕様と関係性の根拠として分けて読みます。
Knowledge basesのGAで何が変わったのか
Foundry IQ全体が一括で本番級になったという読み方ではなく、項目ごとに状態を確認します。
Microsoft Foundry Blogは2026年6月2日、Foundry IQ knowledge basesがgenerally availableになったと説明しました。記事では、knowledge bases、select knowledge sources、security capabilitiesについて、SLA coverage、compliance certifications、stable APIs、enterprise-grade network isolationといった本番判断に近い言葉が並んでいます。
ただし、ここは一番誤読しやすい場所です。Foundry IQのすべてが一括で本番級になった、という意味ではありません。
GAになった範囲は「本番候補」として読める
Microsoft Foundry BlogがGA範囲として挙げる主な項目は、knowledge bases、agentic retrieval references、output and activity logs、Foundry IQ MCP server、minimal retrieval reasoning effortです。knowledge sourcesではAzure Blob Storage、search indexes、Web、OneLakeが挙がっています。Securityではnetwork isolationとmanaged identity supportが含まれています。
この範囲は、PoCだけでなく本番候補として検討しやすくなりました。特に、knowledge baseを単なる検索設定ではなく、エージェントが参照する運用単位として持てること、MCP serverとして外部のMCP互換ホストから呼び出せることは、複数チームでエージェントを作る企業にとって意味があります。
Microsoft Foundry Blogは、Foundry IQ MCP serverについて、Foundry IQ knowledge basesをremote MCP serverとして公開し、Claude、ChatGPT、LangChain、Microsoft Agent FrameworkなどのMCP-compatible hostやclientから利用できると説明しています。公式ブログ上でこうした名前が並ぶ点は、MicrosoftがFoundry IQをMicrosoft製クライアントの内側だけに閉じない方向で見せている、という需要シグナルにもなります。
Previewとして残る項目を同じ表に混ぜない
同じMicrosoft Foundry Blogの中でも、preview扱いの項目があります。Serverless Developer tierはpublic previewです。Security updates in previewとして、cross-tenant customer-managed keys、Purview sensitivity-label auditing、incremental SharePoint permissions sync、APIM support for Foundry model integrations、knowledge sources内でのPurview sensitivity labelsのsurfacingが挙げられています。
Data pipeline updates in previewでは、SharePointのASPX pagesやListsのfirst-class indexing、画像を含むdocument enrichment、Azure Content Understanding chunking with image verbalizationが紹介されています。
このため、導入資料では少なくとも次のように分けるべきです。
| 項目 | 状態 | 読み方 |
|---|---|---|
| Foundry IQ knowledge bases | GA | 本番候補として評価できる中心機能 |
| Foundry IQ MCP server | GA範囲として公式ブログに記載 | MCP接続の入口。ただし接続先の監査と承認は別途必要 |
| Azure Blob Storage、search indexes、Web、OneLake knowledge sources | GA範囲として公式ブログに記載 | 対象データソースごとに権限と更新方法を確認 |
| Serverless Developer tier | Public preview | PoC、低頻度、変動負荷向け。本番前提には置かない |
| Security updates | Preview | PurviewやCMKなどの詳細は本番設計前に最新状態を再確認 |
| Data pipeline updates | Preview | 画像、図表、SharePoint Listsなどを扱う場合は便利だが依存しすぎない |
Agentic retrievalは「検索して終わり」ではない
Foundry IQの価値は、単に検索結果を返すことだけではありません。Microsoft Learnは、agentic retrieval engineがLLMを使ってquery planningを行い、source selection、parallel searches、results aggregationを行うと説明しています。knowledge baseは、どのknowledge sourcesを検索するか、retrieval reasoning effortをどう設定するかを含む、上位の運用単位です。
そのため、導入前の評価では回答品質だけでなく、引用、検索範囲、権限、ログ、費用をセットで見る必要があります。「RAGの精度が上がるらしい」だけで始めると、後からデータ境界と料金の話で詰まりやすくなります。
Microsoft Foundry Blogは、Foundry IQのretrieval improvementsについて、Microsoftの評価データセット、effort tiers、model sizes全体でanswer quality benchmarksが最大20%改善し、single-shot RAGに比べてknowledge basesがrecallを最大54%改善したと説明しています。これは魅力的な数字ですが、本文中で自社の業務文書にも同じ改善が出るとは断定しない方がよいです。PoCでは、実際の社内文書、アクセス権、質問パターンで評価を作る必要があります。
注意点: GAとpreviewは同じ扱いにしない
導入資料では、GA範囲を本番候補、preview範囲を検証候補として色分けします。特にServerless Developer tier、security updates、data pipeline updatesに依存する設計は、GA後に仕様や制限が変わる前提で逃げ道を残します。
Foundry IQ MCP serverで何ができるのか
- 1MCP-compatible host
Claude、ChatGPT、LangChain、Microsoft Agent Frameworkなどのホストやclientから接続を考えます。
- 2Foundry IQ MCP server
remote MCP serverとしてknowledge baseへの入口を提供します。
- 3Foundry IQ knowledge base
Azure AI Searchやknowledge sourcesを使い、agentic retrievalで根拠を探します。
- 4Permissions / citations / logs
取得できる範囲、引用、output、activity logsを運用上の確認対象にします。
MCPは接続口であり、承認、ユーザー権限、監視、接続先の責任分界を省略できるものではありません。
Foundry IQを追う読者にとって、MCPは大きな関心点です。MCP、Model Context Protocolは、エージェントやクライアントが外部ツールやデータソースへ接続するための標準的な口として注目されています。Microsoft系でも、GitHub Copilot、Copilot Studio、Foundry、Work IQなどの文脈でMCPが繰り返し出てきます。
GitHub Copilot側のMCPやBYOK、AI Creditsの流れを確認したい場合は、<a href="https://msft-watch.blog.mo-gmo.com/msft-28-github-copilot-sdk-ga-mcp-byok-ai-credits/">GitHub Copilot SDKが一般提供</a>も合わせて読むと、Microsoftの開発者向けMCP文脈がつかみやすくなります。
Knowledge baseをMCP互換ホストから呼べる
Microsoft Foundry Blogによると、Foundry IQ MCP serverはFoundry IQ knowledge basesをremote MCP serverとして公開します。これにより、MCP-compatible hostやclientからknowledge baseへアクセスできます。公式ブログは、Claude、ChatGPT、LangChain、Microsoft Agent Frameworkを例に挙げています。
ここでのポイントは、Foundry IQが「Microsoft Foundry内のエージェント専用の検索機能」に閉じていないことです。社内で複数のagent frameworkや開発環境を使っている場合、MCPを経由して共通のknowledge baseを参照する設計が視野に入ります。
ただし、MCPでつながることと、社内で許可してよいことは別問題です。MCPホストがどこで動くのか、ログはどこに残るのか、どのデータを渡せるのか、承認や監査をどうするのかを決める必要があります。
Foundry Agent Serviceとの接続はpreview APIの注意がある
Microsoft Learnの「Connect Agents to Foundry IQ Knowledge Bases」は、Foundry Agent ServiceからFoundry IQ knowledge baseへ接続する手順を示しています。前提として、Azure AI Search service上のknowledge base、Microsoft Foundry project、LLM deployment、認証と権限が必要です。例ではgpt-4.1-miniがLLM deployment例として挙げられています。
接続では、Microsoft Foundry projectにRemoteTool connectionを作成し、project managed identityでknowledge baseのMCP endpointを向けます。Learnのサンプルでは、MCP endpointに2026-05-01-preview API versionが使われています。記事を読む側は、このpreview API表記を本番設計でそのまま固定値にしない方が安全です。
また、Azure AI Search knowledge basesがFoundry Agent Service連携で公開するツールは、現時点のLearnではknowledge_base_retrieveだけと説明されています。MCPだから任意の検索・更新・管理操作を自由にできる、と広げて理解しないことが重要です。
承認と監視はサンプル値から切り離す
Learnのサンプルには、MCP toolの設定例としてrequire_approval = "never"が出てきます。これはサンプルコードを読むための値であり、企業運用で常に推奨される設定と受け取るべきではありません。
本番運用では、allowed tools、承認要否、ユーザーやアプリの権限、監査ログ、インシデント時の停止手順をあらかじめ決めます。MCP接続は便利ですが、エージェントが検索できる情報の範囲を広げる入口でもあります。知識層を共通化するほど、誤った権限設計の影響も広がります。
条件: 接続前に決めること
MCP接続を有効にする前に、接続先ホスト、実行identity、allowed tools、承認要否、ログ保存先、停止手順を決めます。サンプルコードの値をそのまま本番設定にせず、自社の監査要件に合わせて置き換える前提で確認します。
Serverless Developer tier public previewはどう読むべきか
どちらが安いかを先に決めず、負荷の波、文書量、検索の複雑さ、運用条件で見積もります。
Foundry IQで新しく注目されるもう一つの軸が、Serverless Developer tierです。Microsoft Foundry Blogは、Foundry IQ Serverless Developer tierがpublic previewで利用可能になったと説明しています。
この発表は、PoCや低頻度のエージェント検索にとってはかなり実務的です。従来の検索サービスでは、ある程度の容量を先に見積もって作る必要がありました。Serverlessは、イベント駆動で一気に使われ、しばらくアイドルになるようなagent workloadに向けて、scale to zeroやconsumption-based pricingを打ち出しています。
Search UnitとCompute Unitは同じものではない
Microsoft LearnのAzure AI Search pricing model説明では、DedicatedとServerlessを明確に分けています。DedicatedはSearch Units、SUsで固定容量を選び、steadyでpredictableな高利用率ワークロードに向きます。ServerlessはCompute Units、CUsとindexed storageで測る消費ベースで、infrequent、bursty、highly variableなワークロードに向きます。
Learnは、SUsとCUsは同じものではなく、相互に使えるものでもないと注意しています。これはFinOps担当にとって重要です。Dedicatedの見積もりシートをそのままServerlessに当てると、費用感を誤ります。
Foundry BlogのServerless Developer tier表では、compute usageが$0.24 CU/hour、indexed storageが最大$0.29 GB/month、indexed storage per indexが1GB/index、indexes per serviceが30 indexes/service、services per subscription per regionが5 services/subscription/regionと示されています。ただし、GB costはregion dependentで、Compute Unit measurementsはbilling enabled前のestimateであり、変更される可能性があります。
Preview中に請求されなくても、有料tierとして扱う
Azure AI SearchのLearnページは、Serverless Developer tierについて、preview中はbillingがまだ有効ではなく、Azure portalやtelemetryに推定コストが表示されてもAzure billには載らない初期期間があると説明しています。同時に、Microsoftはbilling開始の少なくとも30日前に通知し、このbilling deferralは一時的で、Serverless Developerはpaid tierだとも説明しています。
ここは「今は無料だから大丈夫」と読まない方がよいです。PoC開始時点から、どの程度のCUs、storage、index数、検索頻度、取り込み頻度になるかを記録しておく必要があります。課金開始後に、使用量だけが残って予算上限がない状態になるのが一番危険です。
Microsoft Foundry Blog側でも、billingはlate 2026に始まる見込みで、少なくとも30日前に詳細が提供されると説明されています。公開時点では、価格表とLearnの両方を見て、請求開始時期と数値が変わっていないか確認する運用が必要です。
本番判断ではSLA、リージョン、移行制限を見る
Microsoft Learnは、Serverless Developer tierはpreviewで、service-level agreementなし、本番ワークロードには推奨されないと説明しています。また、Public Preview中はWest Central US、Switzerland North、Japan Eastだけで利用できるとしています。
さらに、Serverless Developer tierは他のpricing tiersとの移行をサポートせず、Public Preview中は一部機能が使えない、または制約される可能性があると説明されています。service limits、supported features、pricing detailsもGA前に変わる可能性があります。
日本の読者にとってJapan Eastが含まれるのは試しやすい材料です。しかし、Japan Eastでpreviewが使えることと、本番で日本リージョンに置けることは同じではありません。SLA、private networking、データ所在、監査、請求開始後の費用を見てから、本番判断に進むべきです。
評価基準: PoCと本番を分ける
PoCでは、検索回数、CUs、indexed storage、回答品質、権限漏れの有無を測ります。本番判断では、SLA、リージョン、tier移行、network isolation、請求開始後の予算上限を別の承認項目にします。
権限継承とネットワークで確認すること
セキュリティは勝敗で比較せず、誰の権限で、どのデータに触れ、どこにログが残るかで判断します。
Foundry IQは、企業データをエージェントへ渡す基盤です。そのため、機能一覧よりも先に、誰が何を検索できるのかを確認する必要があります。ここを曖昧にすると、便利なRAG基盤が、そのまま過剰な情報アクセスの入口になります。
Entra IDとRBACは入口の確認である
Microsoft Learnの接続手順では、production deploymentsにはrole-based access controlが推奨されています。Microsoft Foundry側では、model deploymentsへアクセスしagentを作るためにFoundry User roleが必要です。MCP authentication用のproject connectionを作るにはFoundry Project Manager roleが必要で、MCP toolをagentで使うにはFoundry UserまたはFoundry Project Managerが必要と説明されています。
Azure AI Search側では、projectのsystem-assigned managed identityを作成し、search serviceにSearch Index Data Reader roleを割り当てます。indexへ書き込む場合はSearch Index Data Contributorも関係します。
この段階で見るべきなのは、作成者の権限、agent実行時の権限、検索サービス側の権限が混ざっていないかです。AzureのOwnerで作成できたからといって、利用者ごとの検索権限が正しく制御されるとは限りません。
ACLとSharePoint権限はquery時の動きまで見る
Microsoft LearnはFoundry IQのcapabilitiesとして、supported sourcesのACL同期、Microsoft Purview sensitivity labelsの尊重、query timeでのpermissions enforcementを挙げています。また、callerのMicrosoft Entra identityでqueryを実行し、end-to-end permission enforcementを行うとも説明しています。
ただし、権限継承と一言で済ませるのは危険です。データソースがindexed contentなのかremote sourceなのか、ACL metadata fieldsが入っているのか、SharePointの権限をquery時にどう渡すのかで確認点は変わります。
Foundry Agent ServiceのMCP連携について、Learnはpreview上の重要な注意として、MCP toolsではper-request headersをサポートせず、agent definitionsに設定したheadersはすべての呼び出しに適用され、ユーザーやリクエストごとには変えられないと説明しています。per-user authorizationが必要な場合はAzure OpenAI Responses APIを使うよう案内しています。
Remote SharePoint knowledge sourceを含む場合、MCP tool connectionにx-ms-query-source-authorization headerを含める必要があるとも説明されています。このあたりは、セキュリティ担当が本文だけで判断せず、実装前にLearnの最新手順を確認すべき場所です。
Network isolationは全機能一律ではない
Foundry IQのGA文脈では、network isolationやmanaged identity supportが本番判断の材料になります。Microsoft Foundry Blogでは、Foundry IQとFoundry products間のprivate connectivityがShared Private LinkとNetwork Security Perimeterを通じて一般提供と説明されています。
一方で、Serverless Developer tierはpreviewです。Azure AI SearchのLearnページは、Serverless Developer tierにSLAがなく、本番推奨ではなく、機能制約があり得ると説明しています。つまり、Foundry IQ全体のnetwork isolationの話と、Serverless previewで使えるネットワーク機能を同じものとして扱わない方がよいです。
導入前チェックでは、次を最低限確認します。
| 確認項目 | 見るべきこと |
|---|---|
| Foundry project | 誰がagentを作成し、誰がMCP connectionを作れるか |
| Azure AI Search | project managed identityにSearch Index Data Readerなどのroleがあるか |
| Knowledge source | Blob、SharePoint、OneLake、Webなど、対象ごとの権限モデルが明確か |
| User identity | callerのEntra identityでqueryできる前提か、固定headerになっていないか |
| SharePoint | remote sourceかindexed sourceか、per-user authorizationが必要か |
| Network | private endpoint、Shared Private Link、Network Security Perimeterが必要か |
| Audit | output logs、activity logs、tool call、検索対象、回答引用を追えるか |
確認項目: 誰のIDで検索されるか
最終的に確認すべきなのは、作成者ではなく利用者の権限で検索結果が絞られるかです。固定header、project managed identity、callerのEntra identity、SharePoint authorizationのどれが使われるのかを、データソースごとに書き出します。
料金確認はAzure AI Searchとagentic retrievalを分ける
subscription、standard agentic retrieval plan、DedicatedまたはServerlessの選択を確認します。
agentic retrieval activity、semantic ranker、retrieval effort、検索回数を分けて見ます。
indexed storage、vector data量、文書サイズ、更新後の保持を確認します。
document cracking、image extraction、インデックス更新頻度、pipeline処理を確認します。
remote knowledge sources、SharePoint、Web、OneLakeなど接続先ごとの扱いを確認します。
ログ、監視、ピーク時間帯、試験用環境と本番環境の分離を見積もりに入れます。
価格数値は地域、通貨、提供状態で変わるため、公開前後にAzure pricing detailsとLearnを確認します。
Foundry IQの費用を考えるとき、AIモデルのトークンだけを見ていると足りません。Azureの価格ページは、Foundry IQ agentic retrieval activityがAzure AI Searchとして課金されると説明しています。
つまり、見積もりでは「モデル費用」「検索・retrieval費用」「取り込み・保存費用」「運用監視費用」を分ける必要があります。
Foundry IQの課金はAzure AI Search側で読む
Azure pricing detailsでは、Foundry IQをAzure AI Searchの価格ページ内で扱っています。Foundry IQ knowledge basesにはsubscriptionとstandard agentic retrieval planが必要で、agentic retrieval activityがAzure AI Searchとして課金されます。
Dedicated pricingでは、Search Unitsを選び、予測しやすい負荷に固定容量で備えます。Serverless previewではCompute Unitsとindexed storageを見ます。どちらが安いかは、検索回数だけでなく、文書サイズ、更新頻度、ピーク、retrievalの複雑さ、remote source利用で変わります。
Agentic retrievalは検索回数だけで見ない
Foundry IQのagentic retrievalは、単発の検索クエリとは違います。complex questionをsubqueriesへ分解し、複数検索を並行実行し、semantic rerankingやaggregationを行います。LLMをquery planningに使う場合もあります。
したがって、料金と性能の評価では、次のような観点を分けて見る必要があります。
| 見積もり項目 | 確認すること |
|---|---|
| Retrieval頻度 | 1日あたりの質問数、ピーク時間帯、agentごとの呼び出し回数 |
| Query complexity | 1回の質問が何回のsubqueryやsource selectionを生むか |
| Indexed storage | index数、1 indexあたりの容量、文書更新頻度 |
| Ingestion | chunking、embedding、metadata extraction、incremental refresh |
| Remote sources | SharePointやWebなどremote sourceの扱いと権限確認 |
| Observability | output logs、activity logs、評価ログの保存と確認 |
価格数値は公開直前に再確認する
Serverless Developer tierの数値は、2026年6月12日時点の公式情報ではcompute usageが$0.24 CU/hour、indexed storageが最大$0.29 GB/monthと示されています。ただし、価格は地域や通貨で変わる可能性があり、ServerlessのCompute Unit measurementsもbilling enabled前のestimateです。
記事公開後も、pricing pageとLearnのlast updatedを見直す必要があります。特に、late 2026のbilling開始、30日前通知、supported regions、service limits、feature supportは、導入判断に直結します。
注意点: 月額ではなく利用量で試算する
Serverless previewでは、質問数だけでなく、subqueryの発生、対象source数、index更新、storage、ピーク時間帯を記録します。月額の単純な固定費に落とし込む前に、利用パターンを小さく測ることが大切です。
導入企業と開発者は何から試すべきか
- 1既存RAGと重複を洗う
同じ社内文書を複数エージェントが別々に取り込んでいるかを確認します。
- 2共通知識ベースの価値を見る
引用、権限、ログ、更新スケジュールを統一できるかを評価します。
- 3Serverless previewで小さく試す
PoCでは変動負荷に向く条件を見つつ、本番条件は別の表で管理します。
- 4MCPの責任分界を決める
接続先、認証、承認、監視、障害時の責任を先に決めます。
- 5権限と費用を同時に確認する
使えることだけでなく、誰が見られるか、どれだけ費用が変動するかを確認します。
既存基盤をすぐ置き換える前提ではなく、複数エージェントで安全に知識を使う候補として評価します。
Foundry IQを今すぐ本番基盤として全面採用するかどうかは、企業ごとのデータ、権限、Azure利用状況、エージェント開発体制によります。ただし、試す順番はある程度決められます。
既存RAGを持つ企業は、知識ベースの再利用性から見る
すでにAzure AI Searchや独自RAGを使っている企業は、Foundry IQで「検索精度が上がるか」だけを見るより、knowledge baseの再利用性を見る方がよいです。
同じ社内文書を、問い合わせエージェント、開発者支援エージェント、営業支援エージェント、調査エージェントが別々に取り込んでいるなら、知識ベースを共通化できる余地があります。引用、権限、ログ、更新スケジュールを統一できるなら、運用コストの削減につながります。
一方で、個別RAGがすでに権限、監査、評価、コスト管理まで整っている場合、無理に置き換える必要はありません。Foundry IQは、既存基盤を捨てるためではなく、複数エージェントで安全に知識を使うための候補として評価するのが現実的です。
新規PoCはServerless previewで試せるが、本番条件は別に置く
新しくPoCを始める場合、Serverless Developer tierは入口になり得ます。低頻度、変動負荷、イベント駆動、短期間の検証なら、capacity planningを軽くできる点は魅力です。Japan Eastがpreview対象に含まれる点も、日本の検証チームには使いやすい材料です。
ただし、PoC計画書には最初から本番移行条件を別枠で置くべきです。SLAが必要か、専用容量が必要か、Private LinkやNetwork Security Perimeterが必要か、他tierへの移行が必要か、billing開始後の予算上限をどうするか。これらを後回しにすると、PoCの成功が本番移行の失敗につながります。
MCP連携は接続先の責任分界を先に決める
Foundry IQ MCP serverは魅力的です。Microsoft Agent Frameworkだけでなく、MCP-compatible hostからknowledge baseを呼べるなら、開発者は使い慣れた環境で社内知識を扱いやすくなります。
しかし、接続先が増えるほど、責任分界は複雑になります。MCPホストがMicrosoft管理の環境なのか、社内環境なのか、外部SaaSなのか。どの利用者のidentityで検索されるのか。検索結果や引用、ログがどこに残るのか。allowed toolsを誰が管理するのか。ここを先に決めてから接続する方が、あとで止めるより楽です。
エンタープライズ管理されたMCPやhooks、skillsの運用に関心がある場合は、<a href="https://msft-watch.blog.mo-gmo.com/msft-27-enterprise-managed-plugins-vscode-copilot-mcp-hooks/">GitHub CopilotのEnterprise-managed plugins</a>の記事も参考になります。Foundry IQとは対象製品が違いますが、「MCPを企業で標準化する」ときの管理視点は近いです。
最初のチェックリスト
PoCの前に、最低限この表を埋めておきたいところです。
| 項目 | 先に決めること |
|---|---|
| 対象データ | Blob、SharePoint、OneLake、Web、既存search indexのどれか |
| 対象ユーザー | 誰のEntra IDでqueryし、誰に回答を返すか |
| エージェント | Foundry Agent Service、Microsoft Agent Framework、custom app、MCP hostのどれか |
| 権限 | RBAC、ACL metadata、Purview labels、SharePoint authorizationの確認方法 |
| 料金 | DedicatedかServerless previewか、CUs/SUs、storage、retrieval頻度 |
| リージョン | Japan Eastなどpreview対象と、本番で求めるデータ所在 |
| ネットワーク | private connectivityや境界制御が必要か |
| 評価 | 回答品質、引用、誤検索、権限漏れ、コストをどう測るか |
見送り条件: preview依存が強すぎる場合
本番要件がSLA、固定リージョン、private networking、tier移行、厳格なper-user authorizationを前提にしているなら、Serverless previewやpreviewのsecurity updatesへ強く依存した設計は見送る判断もあります。
公開後に再確認するポイント
2026年6月時点の整理として読み、導入時には必ず現行の公式ページで状態を確認します。
Foundry IQは、2026年6月時点でGAとpreviewが混在しています。この記事を読むタイミングによって、状態が変わっている可能性があります。
LearnとPricingの更新日を見る
特に更新されやすいのは、Microsoft LearnのFoundry IQ記事、Foundry Agent Service接続記事、Azure AI Search pricing model、Azure pricing detailsです。API version、role名、supported regions、Serverless billing、pricing tableは、導入前に必ず現行ページを確認してください。
Foundry RBAC roleは、Learn上でも「最近renameされた」と説明されています。Foundry User、Foundry Owner、Foundry Account Owner、Foundry Project Managerは、以前Azure AI Userなどの名前だったため、portal、docs、社内手順書で表記が混ざる可能性があります。
GAとpreviewの境界が変わったら判断も変わる
Serverless Developer tierがGAになる、対応リージョンが増える、private networking関連の対応が変わる、SharePointやPurview関連のpreviewが進む。このどれかが変わるだけでも、導入判断は変わります。
逆に、preview機能に強く依存したPoCは、GA前に仕様や制限が変わる可能性を見込んでおく必要があります。PoCが成功した理由がServerless previewの一時的な条件に依存していないか、料金開始後も同じ設計で続けられるかを確認してください。
月次トピックとして追う
Microsoftの6月発表は、Foundry IQだけで完結しません。Work IQ、GitHub Copilot SDK、Copilot CLI、Edge、Windows、Surface、Securityなどが同じ月に動いています。関連する公式発表をまとめて追う場合は、<a href="https://msft-watch.blog.mo-gmo.com/monthly-topics-2026-06/">Microsoft 2026年6月重要トピックまとめ</a>に戻ると、発表順と確認済みURLを見渡せます。
仕様の根拠を自分で追いたい場合は、固定ページの<a href="https://msft-watch.blog.mo-gmo.com/source-checks/">資料・確認ログ</a>も参照してください。Microsoft公式ブログ、Learn、価格表、preview表記の読み分けを、記事ごとの確認に使えます。
更新条件: 何が変わったら読み直すか
Serverless Developer tierのGA化、supported regionsの変更、billing開始時期、MCP endpointのAPI version、SharePointやPurview関連のpreview状態、Azure AI Search pricingの表が変わった場合は、この記事の判断も見直します。
次に読むなら
参照した主な情報源
- Microsoft Azure Blog, "3 things leaders need to know from Microsoft Build 2026"。2026年6月12日JST確認。https://azure.microsoft.com/en-us/blog/3-things-leaders-need-to-know-from-microsoft-build-2026/
- Microsoft Foundry Blog, "Foundry IQ: Build smarter agents faster with unified knowledge and serverless retrieval"。2026年6月12日JST確認。https://devblogs.microsoft.com/foundry/build-smarter-agents-faster-with-foundry-iq/
- Microsoft Learn, "What is Foundry IQ?"。2026年6月12日JST確認、Last updated 2026-05-19。https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/what-is-foundry-iq
- Microsoft Learn, "Connect Agents to Foundry IQ Knowledge Bases"。2026年6月12日JST確認、Last updated 2026-06-02。https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/foundry-iq-connect
- Microsoft Azure, "Foundry IQ"。2026年6月12日JST確認。https://azure.microsoft.com/en-us/products/ai-foundry/iq
- Microsoft Azure, "Pricing – Foundry IQ"。2026年6月12日JST確認。https://azure.microsoft.com/en-us/pricing/details/search/
- Microsoft Learn, "Choose a pricing model and service tier in Azure AI Search"。2026年6月12日JST確認、Last updated 2026-06-02。https://learn.microsoft.com/en-us/azure/search/search-sku-tier
- The Official Microsoft Blog, "AI alone won't change your business. The system running it will."。2026年6月12日JST確認。https://blogs.microsoft.com/blog/2026/06/02/ai-alone-wont-change-your-business-the-system-running-it-will/
更新履歴
- 2026年6月12日初回整理
Microsoft Azure Blog、Microsoft Foundry Blog、Microsoft Learn、Azure pricing detailsを確認し、GA範囲とpreview範囲を分けて整理しました。
- 次回確認状態変更の追跡
Serverless Developer tier、security updates、data pipeline updates、料金表、supported regionsの変更を確認します。
Foundry IQは更新が入りやすいため、記事の確認日と公式ページの更新日を分けて見ます。
- 2026年6月12日: Microsoft Azure Blog、Microsoft Foundry Blog、Microsoft Learn、Azure pricing detailsを確認し、Foundry IQ knowledge basesのGA範囲、Foundry IQ MCP server、Serverless Developer tier public preview、権限・ネットワーク・料金確認の要点を整理しました。