MENU

Microsoft FabricのWorkIQ/FabricIQ更新まとめ：A2A・MCP Tools対応で確認すべき変更点

Microsoft

Microsoft FabricでFabric IQやWork IQを使ったエージェント連携を検討している場合、今回まず確認すべきポイントは「ツール定義の形式変更」です。2026年5月5日に作成された Azure REST API Specs のPRでは、WorkIQ/FabricIQのツール設定が、A2AやMCP Toolsとそろう形に調整されています。Fabricの画面だけを使っている利用者への影響は限定的ですが、Microsoft FoundryやSDK、OpenAPI定義、エージェントのマニフェストでWorkIQ/FabricIQを直接扱っている開発者は、早めにスキーマとテストを見直すべき更新です。(GitHub)

目次

今回の更新で何が変わったのか

今回の「Align WorkIQ and FabricIQ Format to A2A and MCP Tools」は、Microsoft Fabricそのものの画面操作が大きく変わる更新というより、Microsoft FoundryのデータプレーンAPI仕様におけるWorkIQ/FabricIQツール定義の整形に近い変更です。

GitHub上のPR #42882では、対象が specification/ai-foundry/data-plane/Foundry 配下のOpenAPI/TypeSpec関連ファイルで、ラベルには data-plane と TypeSpec が付いています。つまり、Fabric IQやWork IQをエージェントのツールとして呼び出すAPI契約、生成SDK、型定義、検証ロジックに影響する可能性があります。(GitHub)

特に重要なのは、従来のように work_iq_preview や fabric_iq_preview の下にパラメーターをネストする形から、project_connection_id をツール定義の直下に置く形へ寄せられている点です。これはA2AやMCPツールの指定方法に近づける意図の変更と見てよいでしょう。

WorkIQとFabricIQの位置づけを整理する

今回の変更を理解するには、WorkIQとFabricIQの役割を分けて考える必要があります。

Work IQは、Microsoft 365のメール、会議、ドキュメント、Teamsメッセージ、人物や組織コンテキストなどを、アクセス許可やコンプライアンス制御を保ったままAIアプリケーションで推論できるようにする仕組みです。Microsoft Learnでは、Work IQ APIがA2A、MCP、RESTなど複数のプロトコルに対応する説明があり、現時点のパブリックプレビューではA2AとローカルMCPが利用可能、RESTとリモートMCPは今後提供予定とされています。(Microsoft Learn)

一方、Fabric IQはMicrosoft Fabricのワークロードで、OneLake上のデータをビジネスの言葉で統一し、分析、AIエージェント、アプリケーションに一貫した意味とコンテキストを提供するプレビュー機能です。Microsoft Learnでは、Ontology、Plan、Graph、Data agent、Operations agent、Power BI semantic modelsなどがFabric IQワークロードの構成要素として説明されています。(Microsoft Learn)

簡単に言えば、Work IQは「人と仕事の文脈」、Fabric IQは「データと業務用語の意味づけ」をエージェントに渡すためのレイヤーです。今回の更新は、この2つをMicrosoft Foundry側のツールとして扱うときの形式を、A2AやMCP Toolsの流儀に近づけるものです。

確認すべき主な変更点

確認項目変更前に多かった形式更新後に確認すべき形式実務上の対応
WorkIQツール定義work_iq_preview オブジェクト内に project_connection_id を持たせるproject_connection_id をツール定義の直下に置くマニフェスト、テストJSON、独自バリデーションを修正する
FabricIQツール定義fabric_iq_preview オブジェクト内にパラメーターを持たせるproject_connection_id、server_label、server_url、require_approval などを直下で扱うMCPサーバー接続情報と承認設定を再確認する
name / description明示されていない、または独自管理WorkIQ/FabricIQのツール設定に任意項目として扱える複数ツールを使う環境では識別しやすい名前を付ける
出力項目の型判定FabricIQ専用のcall/output型を前提にする最新OpenAPIに合わせて型分岐を見直すパーサーやログ整形処理を固定文字列だけに依存させない
SDK生成旧スキーマを前提にしたモデルクラスAPIViewでTypeSpec、Python、JavaScriptのAPIレベル変更が検出生成SDK、型定義、CIのスナップショットを更新する

PR上では、OpenAPI YAML/JSONの差分として、WorkIQ/FabricIQの必須項目がネストされたパラメーターオブジェクトから project_connection_id 中心の形式へ変わっていることが確認できます。また、GitHub ActionsのコメントではAPIレベル変更が検出され、TypeSpec、Python、JavaScriptのAPIレビューが作成されています。(GitHub)

誰が対応すべきか

今回の更新は、すべてのMicrosoft Fabric利用者が急いで作業するタイプの変更ではありません。影響を受けやすいのは、Fabric IQやWork IQをエージェント開発のコードや設定ファイルで直接扱っているチームです。

利用者・チーム対応優先度理由
Fabricの画面、Power BI、Data agentを主に使う業務ユーザー低API仕様を直接触っていなければ、すぐに設定変更が必要になる可能性は低い
Microsoft FoundryでWorkIQ/FabricIQツールをエージェントに追加している開発者高ツール定義のJSONやマニフェストが旧形式のままだと、検証エラーやSDKの型不一致が起きやすい
OpenAPIやTypeSpecからクライアントを生成しているSDK担当者高PR上でAPIレベル変更が検出されており、生成物に差分が出る可能性がある
CIでAPIレスポンスやツール呼び出しログを型チェックしているチーム中〜高fabric_iq_preview_call などの固定文字列に依存していると、差分吸収が必要になる
セキュリティ・管理者中project_connection_id、MCPサーバーURL、承認要否の扱いを確認する必要がある

旧形式のまま使っている場合に起きやすい問題

旧形式の設定をそのまま使っていると、次のような問題が起きる可能性があります。

ツール定義の検証で失敗する

たとえば、WorkIQのツール定義を次のようにネストしたままにしている場合、更新後の仕様に合わせたバリデーションでは不一致になる可能性があります。

{
  "type": "work_iq_preview",
  "work_iq_preview": {
    "project_connection_id": "connection-id"
  }
}

更新後は、次のように project_connection_id を直下に置く形を確認します。

{
  "type": "work_iq_preview",
  "project_connection_id": "connection-id",
  "name": "work-context",
  "description": "Microsoft 365の作業コンテキストを参照するWork IQツール"
}

FabricIQも同様です。旧形式では、次のような定義を使っていた可能性があります。

{
  "type": "fabric_iq_preview",
  "fabric_iq_preview": {
    "project_connection_id": "connection-id"
  }
}

更新後は、MCP Toolsに近い形で接続情報や承認設定を直下で扱う形式を確認します。

{
  "type": "fabric_iq_preview",
  "project_connection_id": "connection-id",
  "server_label": "fabric-iq",
  "server_url": "{fabric-iq-mcp-server-url}",
  "require_approval": "always",
  "name": "fabric-business-context",
  "description": "顧客、注文、在庫などの業務コンテキストをFabric IQから参照する"
}

server_url は必ず手入力する項目とは限りません。更新後のOpenAPI定義では、FabricIQ MCPサーバーURLが指定されていない場合、プロジェクト接続側のURLが使われる説明があります。(GitHub)

SDKのモデル名やプロパティがずれる

現時点のMicrosoft Learn上の.NET APIドキュメントには、WorkIQPreviewTool.WorkIqPreview プロパティが掲載されており、プレビュー情報はリリース前に大きく変更される可能性があると明記されています。(Microsoft Learn)

つまり、古いSDKや生成済みモデルでは WorkIqPreview のようなネストプロパティを参照していても、更新後の仕様では project_connection_id を直接持つ形へ寄る可能性があります。プレビューSDKを使っている場合は、コード上の型名だけでなく、実際に送信されるJSONも確認してください。

出力ログの解析処理が壊れる

PRの差分では、一部の出力項目の許容型から fabric_iq_preview_call と fabric_iq_preview_call_output が削除される変更も見えます。ログやレスポンスを処理するコードで、ツール呼び出しの種類を完全一致の文字列だけで分類している場合は注意が必要です。(GitHub)

実務では、次のような実装が壊れやすいです。

if (item.type === "fabric_iq_preview_call_output") {
  renderFabricIqResult(item.output);
}

プレビュー機能では、出力形式が変わることを前提に、次のような観点で見直すと安全です。

if (item.type?.includes("fabric") || item.toolName === "fabric-business-context") {
  renderToolResult(item);
}

ただし、実際の本番実装では曖昧な includes 判定だけに頼らず、最新のOpenAPIやSDKの型定義に合わせて分岐を設計してください。

A2AとMCP Toolsにそろえる意味

今回の更新で重要なのは、「WorkIQとFabricIQが単体の特殊ツールとしてではなく、エージェント標準の接続方法に寄せられている」という点です。

A2AはAgent-to-Agentの略で、エージェント同士がタスクを委任・連携するための考え方です。Work IQ APIのドキュメントでも、A2Aはマルチエージェントシステムや委任に使うプロトコルとして説明されています。(Microsoft Learn)

MCPはModel Context Protocolの略で、AIモデルやエージェントが外部ツールやデータソースを発見し、利用するための標準的な接続方式です。Microsoft FabricのReal-Time Intelligenceでも、MCPによってAIモデルやエージェントがFabric RTIコンポーネントと自然言語でやり取りできると説明されています。(Microsoft Learn)

この流れで見ると、WorkIQ/FabricIQの形式をA2AやMCP Toolsとそろえることには、次のメリットがあります。

  • エージェントのツール定義を統一しやすくなる
  • project_connection_id を中心に接続情報を管理できる
  • MCPサーバーや承認設定をツール定義の中で扱いやすくなる
  • SDK生成やOpenAPIベースの検証で一貫性を持たせやすくなる
  • Work IQ、Fabric IQ、Foundry側ツールを組み合わせたエージェント設計に移行しやすくなる

移行時に確認する手順

既存コードから旧形式を洗い出す

まず、リポジトリ全体で次の文字列を検索します。

work_iq_preview
fabric_iq_preview
WorkIQPreviewToolParameters
FabricIQPreviewToolParameters
WorkIqPreview
FabricIqPreview
fabric_iq_preview_call
fabric_iq_preview_call_output

検索対象は、アプリケーションコードだけではありません。次のファイルも忘れずに確認してください。

確認対象見落としやすいポイント
エージェント定義JSON旧形式のネスト構造が残りやすい
OpenAPI/TypeSpec生成コードCIでは通っても実行時JSONが旧形式になることがある
テストフィクスチャスナップショットテストが旧レスポンスを前提にしている
ログ整形処理fabric_iq_preview_call_output などの固定文字列に依存しやすい
ドキュメント・手順書開発者が古いサンプルをコピーしてしまう原因になる

WorkIQとFabricIQのツール定義を直下形式に更新する

更新後は、project_connection_id をツール定義の直下に置く形を基本として確認します。特に、独自のJSON Schemaで入力値を検証している場合は、スキーマ側も同時に修正してください。

悪い例は、アプリケーションコードだけ直して、テスト用JSONやCIのスキーマを直し忘れることです。この状態では、開発環境では動くのにCIで落ちる、またはCIは通るのに本番環境でAPIが受け付けない、というズレが起きます。

project_connection_id の管理方法を見直す

今回の形式では、WorkIQ/FabricIQツールで project_connection_id の存在感が大きくなります。

project_connection_id は、エージェントがWork IQやFabric IQ、A2Aサーバー、MCPサーバーなどに接続するためのプロジェクト接続を指します。環境ごとにIDが異なることがあるため、開発・検証・本番で同じ値をハードコードしないようにしてください。

おすすめは、次のように環境変数や設定ストアで管理する方法です。

{
  "type": "fabric_iq_preview",
  "project_connection_id": "${FABRIC_IQ_CONNECTION_ID}",
  "name": "fabric-iq-production",
  "description": "本番環境のFabric IQ接続"
}

特に複数テナント、複数ワークスペース、複数プロジェクトを扱うチームでは、接続IDの取り違えが最も現実的な事故になります。

require_approval を安全側で確認する

FabricIQツールには、require_approval が含まれます。OpenAPI定義では、エージェントがアクション実行前に承認を要求するかどうかを示し、既定値は always とされています。(GitHub)

検証段階で安易に never を使うと、意図しないツール実行やデータ操作のリスクがあります。少なくとも次の条件を満たすまでは、承認を省略しないほうが安全です。

確認項目判断基準
ツールが読み取り専用か書き込み、更新、通知、アクション実行を伴う場合は承認を残す
扱うデータの機密度顧客情報、売上、契約、従業員情報を扱う場合は承認を残す
ログと監査誰が、いつ、どの接続で、何を呼び出したか追跡できる
ロールバック誤実行時に復旧できる手順がある
ユーザーへの説明エージェントが何を実行するか、利用者が理解できる

Work IQ利用時の認証確認ポイント

Work IQを直接またはエージェント経由で使う場合は、認証方式も確認が必要です。Microsoft Learnでは、Work IQはMicrosoft Entra IDの委任認証を使い、要求はサインインユーザーのコンテキストで実行され、OBOフローはサポートされる一方、アプリケーションのみの認証はサポートされないと説明されています。(Microsoft Learn)

そのため、次のような設計は見直し対象です。

設計問題点見直し案
バックエンドのアプリ権限だけでWork IQを呼ぶWork IQの前提と合わない可能性があるユーザー委任またはOBOフローを前提に設計する
管理者アカウントの接続を全ユーザーで使い回すアクセス許可トリミングや監査の観点で危険サインインユーザーの文脈で実行する
秘密度ラベルを無視してプロンプトに投入するコンプライアンス上の事故につながるWork IQの権限制御を前提にしつつ、アプリ側でも出力制御を設ける

Work IQは、Microsoft 365の既存のアクセス許可、秘密度ラベル、コンプライアンス制御を適用する前提で説明されています。エージェント側で「見えてはいけないデータを見えないようにする」処理を後付けするのではなく、認証と接続の段階から権限を正しく設計することが重要です。(Microsoft Learn)

Fabric IQ利用時の設定確認ポイント

Fabric IQはプレビュー機能です。Microsoft LearnでもFabric IQはプレビューとして明記されており、OneLake上のデータを統一されたビジネス用語で整理し、分析、AIエージェント、アプリケーションへ意味とコンテキストを提供するワークロードとして説明されています。(Microsoft Learn)

Fabric IQをエージェントのツールとして利用する場合は、次の点を確認してください。

確認項目実務での見方
対象データLakehouse、Eventhouse、Power BI semantic modelなど、どのデータを意味づけしているか
用語の定義「顧客」「案件」「売上」「在庫」などの業務用語が部署間で一致しているか
オントロジーエンティティ、関係、プロパティが現実の業務を正しく表しているか
Data agent連携エージェントがFabric IQの用語を使って自然に回答できるか
接続情報project_connection_id、MCPサーバーURL、承認設定が環境ごとに正しいか

Fabric IQの価値は、単にデータをAIに渡すことではありません。AIが「そのデータが業務上何を意味するか」を理解できるようにする点にあります。したがって、移行確認ではJSONの形式だけでなく、エージェントの回答が業務用語に沿っているかもテストしてください。

変更対応のチェックリスト

移行作業では、次の順で確認すると抜け漏れを減らせます。

| 手順 | 作業内容 | 完了基準 |
| -: | —————————- | —————————————————– |
| 1 | 旧形式の文字列を検索する | work_iq_preview / fabric_iq_preview のネスト形式が残っていない |
| 2 | ツール定義を直下形式に修正する | project_connection_id がツール定義直下にある |
| 3 | name と description を追加する | 複数ツールがログ上で識別できる |
| 4 | FabricIQのMCP関連項目を確認する | server_label、server_url、require_approval の扱いが明確 |
| 5 | SDKや型定義を再生成する | TypeSpec/OpenAPI由来のモデルが最新化されている |
| 6 | 認証方式を確認する | Work IQでアプリケーションのみ認証に依存していない |
| 7 | CIとスナップショットテストを更新する | 旧レスポンス前提のテストが残っていない |
| 8 | 本番前に最小権限で検証する | 接続ID、権限、承認、ログが想定どおり動く |

実務で特に注意したい失敗パターン

プレビュー仕様を本番前提で固定してしまう

今回のPRは、執筆時点でOpenの状態であり、GitHub Actions上では Swagger BreakingChange のチェック失敗も表示されています。PR上では将来的にブロッキングになる可能性があるため対応が推奨される、という趣旨のコメントも確認できます。(GitHub)

そのため、「このPRの内容がそのまま最終仕様として確定した」と断定するのは避けるべきです。実装では、最新のOpenAPI、Microsoft Learn、SDKリリースノートを合わせて確認してください。

Fabricユーザー全員に影響すると誤解する

今回の変更は、主にMicrosoft FoundryのAPI仕様とエージェントツール定義に関わるものです。Fabricのレポート閲覧、Power BI semantic modelの利用、通常のFabricワークスペース運用だけであれば、すぐに作業が必要になる可能性は高くありません。

ただし、Fabric IQをAIエージェントや外部アプリケーションと接続している場合は別です。ツール定義、MCP接続、プロジェクト接続IDを使っているかを確認してください。

接続IDを環境間で使い回す

project_connection_id が直下に出ることで、設定ファイル内で目立ちやすくなります。その一方で、開発環境の接続IDを本番にコピーしてしまう事故も起きやすくなります。

接続IDは、次のように用途が分かる命名・管理にしておくと安全です。

FABRIC_IQ_CONNECTION_ID_DEV
FABRIC_IQ_CONNECTION_ID_STG
FABRIC_IQ_CONNECTION_ID_PROD
WORK_IQ_CONNECTION_ID_PROD

さらに、接続先のワークスペース、テナント、権限スコープも棚卸ししておくと、監査時に説明しやすくなります。

A2AとMCPを混同する

A2Aはエージェント同士の委任や連携に向いたプロトコルです。MCPは、AIモデルやエージェントが外部ツールやデータソースを利用するための接続方式です。Work IQのドキュメントでも、A2Aはマルチエージェントや委任、MCPはAIアシスタントがWork IQをツールとして呼び出す用途として整理されています。(Microsoft Learn)

設計時は、次のように分けて考えると判断しやすくなります。

使いたいこと適した考え方
別のエージェントに業務文脈の調査を依頼したいA2A
GitHub CopilotやIDE上のAIからFabric/Workコンテキストを参照したいMCP
アプリケーションのバックエンドから会話型に呼び出したいREST。ただしWork IQでは今後提供予定の扱いに注意
Fabricのリアルタイムデータに自然言語で問い合わせたいFabric Real-Time IntelligenceのMCP

今回の更新を受けて次にやるべきこと

今回のMicrosoft Fabric関連更新で、最初にやるべきことはシンプルです。Fabric IQやWork IQをAPI、SDK、マニフェスト、TypeSpec、OpenAPI経由で扱っているかを確認してください。

該当する場合は、次の3点を優先します。

  1. work_iq_preview / fabric_iq_preview の旧ネスト形式を検索する
  2. project_connection_id 直下形式とMCP関連項目に合わせて設定を更新する
  3. SDK生成、型チェック、レスポンス解析、承認設定のテストをやり直す

Fabric IQやWork IQは、MicrosoftのAIエージェント基盤の中で、業務データと作業コンテキストをつなぐ重要な要素になりつつあります。今回の変更は細かなスキーマ修正に見えますが、A2AやMCP Toolsと形式をそろえることで、今後のエージェント連携をより標準的に扱うための下準備と捉えると分かりやすいです。

プレビュー機能を使っているチームは、仕様変更を「壊れたら直す」ではなく、「定期的に仕様差分を取り込む」運用に切り替えることが重要です。まずはリポジトリ内の旧形式を検索し、影響範囲を小さく見積もってから、ツール定義、接続ID、承認設定、SDK生成の順に確認しましょう。

Microsoft
MCP A2A Microsoft Fabric Work IQ Fabric IQ

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次