Azure REST API／Microsoft Fabric REST APIの運用で今回まず押さえるべき点は、AIエージェントがMicrosoft Fabricを自然言語で操作するための入り口として、2種類のFabric MCP Serverが整理されたことです。すぐ使えるリモート型の「Fabric Core MCP Server」と、開発端末で動かすローカル型の「Fabric MCP Server」があり、どちらを使うかで確認すべき認証、権限、監査、展開方法が変わります。
特に重要なのは、Fabric Core MCP ServerがFabric REST APIをMCPツールとして公開し、Microsoft Entra ID認証とFabricのRBACに従って動作する点です。一方、ローカル版はAPI仕様、OneLake操作、アイテム作成など開発支援に向いています。管理者は「誰がどの権限でAIエージェントからFabricを操作できるか」、開発者は「既存のREST API実装やCI/CDにどう影響するか」を確認する必要があります。(Microsoft Learn)
Azure REST APIの「Fabric MCP Servers overview」で押さえるべき変更点
今回の公式情報は、Microsoft FabricをAIエージェントから扱うためのModel Context Protocol、つまりMCPの利用方法を整理したものです。従来のように開発者がREST APIの仕様を読み、エンドポイントやスコープ、ペイロードを実装するだけでなく、MCP対応のAIエージェントがFabric REST APIに対応する「ツール」を発見し、自然言語の指示をAPI操作に変換できるようになります。(Microsoft Learn)
ただし、これはFabric REST APIが不要になるという意味ではありません。MCP Serverは、Fabric REST APIをAIエージェントから使いやすくするためのレイヤーです。実際の操作はFabric API、Microsoft Entra ID認証、Fabricのワークスペース権限に依存します。
主な変更点を整理すると、次のようになります。
| 観点 | これまでのREST API中心の操作 | Fabric MCP Serverを使う場合 |
|---|---|---|
| 操作方法 | エンドポイント、HTTPメソッド、ペイロードを開発者が指定 | AIエージェントに自然言語で依頼し、MCPツールがAPI呼び出しを補助 |
| 認証 | Microsoft Entra IDアプリ、トークン、スコープを実装側で管理 | Coreリモート版はOAuth 2.0でEntra ID認証を利用 |
| 権限 | Fabricのロール、APIスコープ、管理者設定に依存 | 既存のFabric RBACを尊重し、追加権限は付与しない |
| 監査 | API実行やFabric操作のログを確認 | Coreリモート版の操作もユーザーIDに紐づき監査対象 |
| 開発支援 | ドキュメントやOpenAPI仕様を手作業で参照 | ローカル版でAPI仕様、スキーマ、ベストプラクティスをAIに参照させやすい |
実務上のポイントは、「AIから操作できるようになる」ことよりも、「AIが使う操作権限を既存のID管理・権限設計・監査設計の中にどう組み込むか」です。
Fabric MCP Serverとは何か
Fabric MCP Serverは、MCP対応のAIエージェントがMicrosoft Fabricのデータ、ワークスペース、アイテム、API仕様などにアクセスするための仕組みです。MCPはAIエージェントが外部データソースやサービスに統一インターフェースで接続するためのオープン標準として説明されています。(Microsoft Learn)
Fabricでの処理の流れは、概念的には次のようになります。
- ユーザーがAIエージェントに「Sales AnalyticsワークスペースのLakehouseを一覧表示して」と依頼する
- AIエージェントが利用可能なMCPツールを確認する
- MCP Serverが認証と権限を確認する
- MCP ServerがFabric REST APIを呼び出す
- AIエージェントがAPI応答を自然言語で返す
ここで注意したいのは、AIエージェントが「何でもできる」わけではない点です。Fabric Core MCP ServerはユーザーのFabric権限に従って動作し、Fabricで許可されていないワークスペースやアイテムにはアクセスできません。(Microsoft Learn)
2種類のFabric MCP Serverの違い
公式情報では、Fabric MCP Serverは大きく2種類に分けて説明されています。リモート型のFabric Core MCP Serverと、ローカル型のFabric MCP Serverです。(Microsoft Learn)
| 項目 | Fabric Core MCP Server | Fabric MCP Server local |
|---|---|---|
| 主な用途 | Fabric環境の参照、作成、権限管理などのリモート操作 | API仕様確認、OneLake操作、開発支援、ローカル拡張 |
| 実行場所 | Microsoft側のリモートエンドポイント | 開発者のローカル端末 |
| インストール | 不要 | 必要。VS Code拡張、npm/npx、.NETビルドなど |
| 認証 | Microsoft Entra IDによるOAuth 2.0 | ローカルで構成された資格情報を利用 |
| 対応操作 | ワークスペース、アイテム、権限、フォルダー、容量など | APIドキュメント、OneLakeファイル操作、Fabricアイテム作成など |
| 監査 | Fabric監査ログの対象 | 操作内容により確認方法が異なる |
| 向いている人 | 管理者、運用担当、Fabric管理を自動化したい開発者 | API実装者、データエンジニア、Fabric拡張開発者 |
判断基準はシンプルです。Fabric環境を直接操作したい場合はCoreリモート版、API仕様やスキーマを確認しながら開発したい場合はローカル版を選びます。両方を併用することもできます。
Fabric Core MCP Serverでできること
Fabric Core MCP Serverは、FabricのパブリックAPIをMCPツールとして公開するリモートエンドポイントです。MCP対応のAIエージェントから接続し、Microsoft Entra IDで認証します。公式ドキュメントでは、プレビュー段階であり、一般提供前に機能や構成が変わる可能性があるとされています。(Microsoft Learn)
代表的な操作は次のとおりです。
| 操作カテゴリ | できることの例 |
|---|---|
| カタログ検索 | OneLake Catalogでアイテムを検索 |
| ワークスペース管理 | ワークスペースの一覧、作成、更新、削除 |
| アイテム管理 | Lakehouse、Notebook、Pipelineなどの作成、取得、更新、削除 |
| 権限管理 | ワークスペースロールの付与、変更、削除 |
| フォルダー管理 | フォルダーの作成、一覧、移動、削除 |
| 容量情報 | 利用可能な容量の一覧や操作状態の確認 |
| 非同期操作 | 長時間処理の状態確認、結果取得 |
Core版の接続先は、公式クイックスタートで次のエンドポイントとして示されています。(Microsoft Learn)
{
"servers": {
"fabric": {
"type": "http",
"url": "https://api.fabric.microsoft.com/v1/mcp/core"
}
}
}VS CodeとGitHub Copilotを使う場合は、MCP: Add ServerからHTTPサーバーとして追加し、ブラウザーでMicrosoft Entra ID認証を完了します。接続確認には「List all my Fabric workspaces」のようなプロンプトが例示されています。(Microsoft Learn)
管理者が特に注意すべき操作
Fabric Core MCP Serverでは、ワークスペースやアイテムの作成だけでなく、ロール割り当ての追加や変更も扱えます。つまり、権限管理の運用ルールが曖昧なまま導入すると、AIエージェント経由で意図しない権限変更が起きるリスクがあります。
確認すべきポイントは次のとおりです。
| 確認項目 | 管理者が見るべきポイント |
|---|---|
| ワークスペース作成権限 | 組織内で誰が新規ワークスペースを作成できるか |
| Adminロールの範囲 | Admin権限を持つユーザーが多すぎないか |
| Contributor付与の運用 | 一時的な開発メンバーや外部協力者に過剰権限を与えていないか |
| 監査ログ | MCP経由の操作を含め、ユーザーID単位で追跡できるか |
| 削除操作 | ワークスペースやアイテム削除の前に承認フローを設けるか |
公式のツールリファレンスでも、ワークスペース削除は中のアイテムを含めて削除され、元に戻せない旨が示されています。AIエージェントで操作できるようにするほど、削除・権限変更・名前変更などの破壊的操作には明確なルールが必要です。(Microsoft Learn)
Fabric MCP Server localでできること
ローカル版のFabric MCP Serverは、開発端末上でサブプロセスとして動作するオープンソース実装です。Fabric APIドキュメント、OpenAPI仕様、アイテム定義、OneLake操作などをAIエージェントに提供する用途に向いています。(Microsoft Learn)
主なツールカテゴリは次の3つです。
| カテゴリ | 役割 | 活用例 |
|---|---|---|
| APIドキュメントとベストプラクティス | OpenAPI仕様、JSONスキーマ、推奨パターンを参照 | Notebook作成APIのペイロード例を生成する |
| OneLakeデータ操作 | ワークスペース、アイテム、ファイル、ディレクトリを操作 | Lakehouse内の設定ファイルをダウンロード・更新する |
| Core Fabric操作 | Fabricアイテムの作成など | 開発用LakehouseやNotebookを作成する |
インストール方法は、VS Code拡張が推奨されています。ほかにnpm/npxや.NET SDKからのビルドにも対応します。公式クイックスタートでは、npm/npxの場合はNode.js 20 LTS以降、ソースビルドの場合は.NET 9 SDK以降が前提として示されています。(Microsoft Learn)
{
"mcpServers": {
"fabric-mcp-server": {
"command": "npx",
"args": [
"-y",
"@microsoft/fabric-mcp@latest",
"server",
"start",
"--mode",
"all"
]
}
}
}ローカル版は、API仕様やベストプラクティスの参照であればライブのFabric環境に接続せずに使える一方、OneLake操作は実環境に接続し、認証が必要です。ここを混同すると、「ドキュメント参照だけのつもりがデータ操作も可能な構成になっていた」という運用上のズレが起きます。(Microsoft Learn)
影響範囲：誰が何を確認すべきか
Fabric MCP Servers overviewの影響は、単に開発者向けの新機能にとどまりません。Azure、Microsoft Entra ID、Fabric、データ基盤、セキュリティ運用の境界にまたがります。
| 対象者 | 影響 | まず確認すること |
|---|---|---|
| Fabric管理者 | AI経由でワークスペース、アイテム、権限を操作できる範囲が広がる | Workspaceロール、作成権限、監査ログ |
| Azure／Entra ID管理者 | OAuth認証、同意、アプリ登録、スコープ管理の設計が重要になる | Entra IDの同意ポリシー、条件付きアクセス |
| 開発者 | REST API実装やOpenAPI参照をAI支援で効率化できる | Core版とローカル版の使い分け |
| データエンジニア | OneLakeファイル操作やLakehouse作成をAIから支援できる | 本番データへの接続可否、環境分離 |
| セキュリティ担当 | AIエージェント経由の操作も監査・レビュー対象になる | 操作ログ、権限昇格の有無、データ持ち出し対策 |
| DevOps担当 | 開発環境へのMCP導入、拡張、CI/CDとの役割分担が必要 | VS Code設定、mcp.json、端末標準化 |
特に重要なのは、開発環境と本番環境を分けることです。AIエージェントに「作成」「削除」「権限変更」を任せられるとしても、最初から本番ワークスペースに接続するのは避けるべきです。まずは検証用テナント、検証用ワークスペース、最小権限のユーザーで試すのが安全です。
認証・権限・スコープで確認すべきポイント
Fabric REST APIでは、Microsoft Entra IDの認証、Fabricの権限、APIスコープが組み合わさってアクセスが制御されます。Fabric REST APIのスコープには、汎用スコープとアイテム種別ごとの具体的なスコープがあり、利便性とセキュリティのバランスを考えて選ぶ必要があります。(Microsoft Learn)
Fabric Core MCP Serverを使う場合も、次の考え方は変わりません。
最小権限を前提にする
AIエージェントに接続するユーザーは、必要最小限のFabricロールにします。たとえば、一覧確認だけならViewer、アイテム作成が必要ならContributor、本当に権限管理まで必要な場合だけAdminを検討します。
ワークスペースロールの目安は次のとおりです。
| ロール | MCP利用時の注意点 |
|---|---|
| Viewer | 読み取り中心。検証開始に向いている |
| Contributor | 作成・編集が可能。開発環境向け |
| Member | 編集や削除の範囲が広がるため、対象ワークスペースを限定する |
| Admin | 権限管理や削除に関わるため、本番では特に慎重に扱う |
Microsoft Graph MCPとの併用は便利だが、同意範囲を確認する
Fabric Core MCP Serverでは、ユーザーやグループをメールアドレスで解決するためにMicrosoft Graph MCP Serverを併用できると説明されています。Graph MCPを使うと、ユーザーIDを直接指定する代わりにメールアドレスで権限付与しやすくなります。(Microsoft Learn)
ただし、便利になるほど誤ったユーザーやグループに権限を付与する可能性も高まります。組織では、少なくとも次を確認してください。
- Graph MCPを誰が使えるか
- グループ名やメールアドレスの解決結果を操作前に確認する運用にするか
- 外部ユーザーやゲストユーザーへの権限付与を許可するか
- 権限付与のログをどのチームがレビューするか
既存のREST API実装からの移行で考えるべきこと
Fabric MCP Serverは、既存のREST API実装をただちに置き換えるものではありません。むしろ、既存のAPI設計や運用を補完するものとして考えるのが現実的です。
移行というより、次の3パターンで段階導入するのがおすすめです。
| 導入パターン | 内容 | 向いているケース |
|---|---|---|
| 調査・学習用途 | ローカル版でAPI仕様やスキーマをAIに参照させる | Fabric REST APIに慣れていない開発チーム |
| 開発支援用途 | 検証環境でワークスペースやLakehouseを作成する | PoCやデータ基盤開発 |
| 運用補助用途 | Core版で一覧取得、権限確認、環境棚卸しを行う | 管理者の定型作業を効率化したい場合 |
本番運用でいきなり「AIにワークスペースを作らせる」「権限を変更させる」といった使い方をするのは避けるべきです。まずは読み取り系の操作から始め、次に検証環境で作成系、最後に承認フロー付きで本番の補助操作へ広げると安全です。
展開前に確認したいチェックリスト
導入前には、技術設定だけでなく、運用ルールまで確認しておく必要があります。
| チェック項目 | 確認内容 |
|---|---|
| 利用目的 | 調査、開発支援、運用補助のどれに使うか |
| 対象環境 | 検証環境から始め、本番接続は後段にする |
| ユーザー権限 | MCPを使うユーザーのFabricロールを最小化する |
| Entra ID設定 | OAuth同意、条件付きアクセス、アプリ制御を確認する |
| ログ確認 | Fabric監査ログで操作を追跡できるか確認する |
| 破壊的操作 | delete、update、role変更をどの範囲で許可するか決める |
| 開発端末 | ローカル版を使う端末のVS Code、Node.js、.NETなどを標準化する |
| データ持ち出し | OneLakeファイルのダウンロードやアップロードをどう制御するか |
| プレビュー対応 | Core版はプレビューのため、仕様変更を前提に運用する |
管理者にとって一番の落とし穴は、「AIエージェントの導入」をツール設定だけで済ませてしまうことです。実際には、ユーザー権限、監査、変更管理、データ保護まで含めて設計する必要があります。
開発者が実装時に注意すべきAPI運用の基本
MCP Serverを使っても、Fabric REST APIの基本的な制約は残ります。特に、スロットリング、ページネーション、長時間実行操作は、AI支援を使う場合でも理解しておくべきです。
Fabric REST APIでは、一定時間内のAPI呼び出し数に制限があり、制限を超えるとHTTP 429とRetry-Afterヘッダーが返ります。開発者はAIに生成させたコードであっても、Retry-Afterを尊重するリトライ処理を確認してください。(Microsoft Learn)
また、一覧取得系APIではcontinuationUriやcontinuationTokenによるページネーションが使われます。AIが生成したサンプルコードが最初の1ページだけを処理していないか、必ず確認が必要です。(Microsoft Learn)
ワークスペース作成やアイテム作成など時間がかかる操作では、HTTP 202 Accepted、Locationヘッダー、x-ms-operation-id、Retry-Afterを使ったポーリングが必要になる場合があります。MCP Coreのツールにも長時間操作の状態確認や結果取得が用意されているため、タイムアウト時は「失敗」と即断せず、操作状態を確認します。(Microsoft Learn)
よくある失敗パターンと対策
本番ワークスペースにAdmin権限で接続してしまう
最も避けたいのは、AIエージェントをAdmin権限のユーザーで本番ワークスペースに接続することです。自然言語の指示は便利ですが、曖昧なプロンプトや誤解釈によって意図しない変更が起きる可能性があります。
対策として、最初はViewerまたは検証環境のContributorで接続します。本番環境で使う場合は、削除や権限変更を含む操作に人間の確認手順を入れます。
ローカル版とCore版の役割を混同する
ローカル版は開発支援に強く、Core版はFabric環境のリモート操作に強いという違いがあります。ローカル版だけで全てのワークスペース管理ができると誤解したり、Core版だけでAPI仕様の深い調査を済ませようとしたりすると、期待した結果になりません。
対策は、用途ごとに使い分けることです。API仕様の確認、スキーマ確認、サンプル生成はローカル版。ワークスペース一覧、アイテム操作、権限確認はCore版が基本です。
AI生成コードをそのまま本番投入する
ローカル版はOpenAPI仕様やベストプラクティスをAIに参照させられるため、コード生成の効率は上がります。しかし、生成されたコードが自社の認証方式、例外処理、ログ設計、プロキシ設定、スロットリング対応に合っているとは限りません。
対策として、AI生成コードには次のレビュー観点を設けます。
| レビュー観点 | 確認する内容 |
|---|---|
| 認証 | MSAL、トークン取得、スコープ指定が組織方針に合っているか |
| 例外処理 | 401、403、429、5xxを適切に処理しているか |
| ページネーション | continuationTokenを最後まで処理しているか |
| 非同期処理 | 202 Accepted時にポーリングしているか |
| ログ | 誰が、いつ、どのワークスペースを操作したか残るか |
| セキュリティ | シークレットやトークンをコードやログに出していないか |
まず取るべきアクション
今回のFabric MCP Servers overviewは、Fabric REST APIの使い方を「コードから呼ぶ」だけでなく、「AIエージェントから安全に使う」方向へ広げる内容です。導入を急ぐより、次の順序で確認すると失敗しにくくなります。
まず、管理者はFabricのワークスペースロール、ワークスペース作成権限、監査ログの確認方法を棚卸しします。次に、開発者はローカル版のFabric MCP Serverを検証環境で導入し、API仕様確認やサンプル生成に使ってみます。その後、Core版をViewer権限で接続し、ワークスペース一覧やアイテム一覧など読み取り操作から検証します。
本番環境への展開は、Core版がプレビューであること、仕様変更の可能性があること、削除や権限変更のような影響の大きい操作が含まれることを踏まえて判断してください。最初のゴールは、AIにすべてを任せることではありません。Fabric REST APIの運用を安全に保ちながら、調査・開発・管理の定型作業を少しずつ効率化することです。
コメント