Microsoft Fabric の「Get started with Fabric Core MCP Server」は、AI エージェントを Microsoft Fabric に接続し、ワークスペースやアイテム、権限管理などを自然言語から操作できるようにするための公式クイックスタートです。結論から言うと、今回確認すべきポイントは「リモート型の Core MCP Server がプレビューとして利用できること」「VS Code と GitHub Copilot などの MCP 対応ホストから短時間で接続できること」「操作は既存の Microsoft Entra ID と Fabric RBAC に従うこと」の3点です。(Microsoft Learn)
管理者やデータ基盤担当者にとって重要なのは、単に「AI から Fabric を操作できるようになった」という話ではありません。AI エージェントが実際に Fabric REST API を呼び出し、ワークスペース作成、アイテム操作、ロール付与などの実操作に関与できるため、検証環境、権限設計、監査、利用ルールを先に整える必要があります。(Microsoft Learn)
Microsoft Fabric Core MCP Server とは何か
Microsoft Fabric Core MCP Server は、AI エージェントが Microsoft Fabric を自然言語で扱えるようにするリモートエンドポイントです。MCP は Model Context Protocol の略で、AI エージェントが外部サービスやデータソースに統一的な方法でアクセスするための仕組みです。Fabric Core MCP Server では、ユーザーのプロンプトが Fabric REST API の呼び出しに変換され、ワークスペース、アイテム、権限、フォルダー、容量情報などを操作できます。(Microsoft Learn)
重要なのは、Core MCP Server が「AI に管理者権限を与える機能」ではないことです。公式情報では、操作は Microsoft Entra ID による OAuth 2.0 認証を通じて行われ、Fabric の RBAC 権限に従い、Fabric の監査ログにも記録されると説明されています。つまり、AI エージェント経由であっても、ユーザーが本来アクセスできないワークスペースやアイテムを操作できるわけではありません。(Microsoft Learn)
一方で、自然言語で「開発用ワークスペースを作成して」「Finance ワークスペースの権限を一覧化して」「特定ユーザーを Contributor にして」といった操作ができるため、運用効率化と同時に誤操作リスクも高まります。導入時は、便利さよりも先に「どのユーザーが、どの環境で、どの操作まで許可されるべきか」を整理することが大切です。
今回の更新ポイントで押さえるべきこと
Microsoft Fabric の新機能情報では、Fabric Remote MCP がプレビュー機能として紹介されています。クラウドホスト型の MCP サーバーとして、AI エージェントが Microsoft Entra ID 経由で認証され、Fabric のワークスペース、アイテム、検索、アクセス許可、接続、OneLake などに対して認証済みの操作を実行できるものとして位置付けられています。(Microsoft Learn)
「Get started with Fabric Core MCP Server」の公式クイックスタートで特に確認すべき更新ポイントは次のとおりです。
| 確認項目 | 内容 | 管理者・担当者が見るべきポイント |
|---|---|---|
| 提供形態 | リモート Core MCP Server として提供 | ローカルインストール不要で使えるが、プレビュー段階のため本番適用は慎重に判断する |
| 接続先 | https://api.fabric.microsoft.com/v1/mcp/core | 利用する MCP ホストやネットワーク制御で、この接続先を扱えるか確認する |
| 認証 | OAuth 2.0 と Microsoft Entra ID | 条件付きアクセス、多要素認証、サインインポリシーとの整合性を確認する |
| 権限 | Fabric RBAC に従う | Workspace Admin、Member、Contributor、Viewer の割り当てを棚卸しする |
| 対応ホスト | Streamable HTTP transport 対応の MCP ホスト | VS Code と GitHub Copilot が推奨例として示されているが、他ホスト利用時は仕様確認が必要 |
| 追加連携 | Microsoft Graph MCP Server 連携 | メールアドレスでユーザーやグループを解決したい場合に検討する |
| 移行期限 | 公式情報上、強制移行期限は確認されていない | 既存運用を置き換えるより、まず検証環境で影響確認する |
現時点で特に注意したいのは、Core MCP Server がプレビュー段階であり、一般提供前に機能や構成が変更される可能性がある点です。公式クイックスタートにも、プレビューであることと、機能・構成が変更される可能性が明記されています。(Microsoft Learn)
影響範囲：誰が対応すべきか
Fabric Core MCP Server の影響は、開発者だけに限られません。AI エージェントが Fabric REST API を呼び出す入口になるため、データ基盤、セキュリティ、ID 管理、開発標準の複数領域に関わります。
| 対象者 | 主な影響 | 先に確認すべきこと |
|---|---|---|
| Fabric 管理者 | ワークスペース作成、削除、容量確認、権限変更が自然言語から実行される可能性 | ワークスペース作成権限、管理者ロール、容量割り当て |
| Entra ID 管理者 | OAuth 2.0 認証とサインイン制御が関係する | 条件付きアクセス、多要素認証、外部ユーザー制御 |
| セキュリティ担当者 | 操作ログや権限変更の監査が重要になる | 監査ログの確認手順、アラート条件、権限変更レビュー |
| データエンジニア | Lakehouse、Notebook、Pipeline などのアイテム操作に関係する | 開発・検証・本番ワークスペースの分離 |
| 開発者・AI 利用者 | VS Code や GitHub Copilot から Fabric 操作が可能になる | 誤操作を避けるプロンプト運用、検証環境の利用 |
| グローバル IT 管理者 | 複数リージョン・複数テナントで展開判断が必要 | 国・地域ごとのデータ管理ルール、利用可能ホスト、教育体制 |
特にグローバル展開では、利用者が増えるほど「誰がどの AI ホストから Fabric に接続しているか」が見えにくくなります。最初から全社展開するのではなく、対象ユーザー、対象ワークスペース、許可する操作範囲を限定して検証するのが現実的です。
設定変更のポイント：VS Code から接続する基本手順
公式クイックスタートでは、Microsoft Fabric へのアクセス権、Streamable HTTP transport に対応した MCP ホスト、Microsoft Entra ID の職場または学校アカウントが前提条件として示されています。MCP ホストとしては VS Code と GitHub Copilot が推奨例として挙げられています。(Microsoft Learn)
VS Code での基本的な流れは次のとおりです。
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| 1 | VS Code でコマンドパレットを開く | Windows は Ctrl+Shift+P、macOS は Cmd+Shift+P |
| 2 | MCP: Add Server を選び、HTTP を選択 | stdio だけに対応したホストではそのまま接続できない場合がある |
| 3 | Fabric Core MCP Server の URL を入力 | https://api.fabric.microsoft.com/v1/mcp/core |
| 4 | サーバー名を入力 | 公式例では fabric |
| 5 | ブラウザーで Microsoft Entra ID 認証を完了 | 認証後、利用者の Fabric 権限に基づいて操作される |
手動で構成する場合は、VS Code の .vscode/mcp.json に次のような設定を追加します。(Microsoft Learn)
{
"servers": {
"fabric": {
"type": "http",
"url": "https://api.fabric.microsoft.com/v1/mcp/core"
}
}
}他の MCP ホストから接続する場合は、接続先 URL、Streamable HTTP transport、OAuth 2.0 Bearer Token、スコープ https://api.fabric.microsoft.com/.default、ID プロバイダー Microsoft Entra ID を設定します。(Microsoft Learn)
接続後に確認するべき最初の操作
接続後は、いきなり作成・削除・権限変更を試すのではなく、読み取り系のプロンプトから確認するのが安全です。公式クイックスタートでは、接続確認として次のようなプロンプトが紹介されています。(Microsoft Learn)
List all my Fabric workspacesこの操作で、自分がアクセスできる Fabric ワークスペースの一覧が返れば、MCP ホスト、認証、Fabric 権限の基本的な接続確認ができます。接続に失敗する場合は、MCP サーバーをいったん切断して再接続し、少なくとも 1 つの Fabric ワークスペースに Viewer 以上のアクセス権があるかを確認します。(Microsoft Learn)
検証時は、次の順番で進めると安全です。
| 段階 | 試す内容 | 目的 |
|---|---|---|
| 読み取り確認 | ワークスペース一覧、アイテム一覧を取得 | 認証と RBAC が期待どおりか確認する |
| 限定的な作成 | 検証用ワークスペースや Lakehouse を作成 | 作成権限と監査ログを確認する |
| 権限確認 | ロール割り当ての一覧を取得 | 現在のアクセス制御を把握する |
| 権限変更 | 検証用ユーザーに Contributor を付与 | Graph MCP の有無や ID 解決の挙動を確認する |
| 削除操作 | 検証用リソースのみ削除 | 取り消し不能な操作の扱いを確認する |
Core MCP Server でできること
Fabric Core MCP Server は、AI エージェントが使用する複数のツールを提供します。公式のツールリファレンスでは、各ツールが Fabric REST API 操作に対応し、入力検証やエラーハンドリングを含むと説明されています。(Microsoft Learn)
代表的な操作は次のとおりです。
| 操作カテゴリ | できることの例 | 実務での活用シーン |
|---|---|---|
| カタログ検索 | OneLake Catalog でアイテムを検索 | 「Sales」「Customer」などの名前や説明から関連資産を探す |
| ワークスペース操作 | 一覧取得、詳細取得、作成、更新、削除 | 開発用ワークスペースの準備、環境整理 |
| アイテム管理 | アイテム一覧、詳細取得、作成、更新、削除 | Lakehouse、Notebook、Pipeline などの棚卸しや作成支援 |
| 権限管理 | ロール付与、一覧取得、変更、削除 | プロジェクト開始時の権限付与、退職者・外部委託先の棚卸し |
| フォルダー管理 | フォルダー作成、移動、名前変更、削除 | ワークスペース内のアイテム整理 |
| 容量確認 | 利用可能な Fabric capacity の一覧取得 | ワークスペース割り当てや運用確認 |
| 非同期操作確認 | 長時間操作の状態・結果を確認 | 作成や更新処理の完了確認 |
実務では、たとえば次のような使い方が考えられます。
Show me all items in the Sales Analytics workspaceCreate a workspace called Sales Analytics DevList all role assignments for the Finance workspaceAdd [email protected] as a Contributor to my Dev workspaceこれらは便利ですが、特に作成・削除・権限変更は影響が大きい操作です。管理者は、AI エージェントから実行してよい操作と、人間の承認を必須にする操作を分けておくべきです。
できないこと・過信しやすいポイント
Fabric Core MCP Server は、Fabric のあらゆる機能を自然言語で完全操作できる万能機能ではありません。公式の概要では、すべての操作は既存の Fabric 権限に従うこと、一部の高度な Fabric 機能にはまだ対応する MCP ツールがない場合があること、Lakehouse テーブルや Notebook コードなどアイテム内部のデータ変更には直接 Fabric アクセスが必要になることが示されています。(Microsoft Learn)
導入時に誤解しやすい点を整理すると、次のようになります。
| 誤解 | 実際の考え方 |
|---|---|
| AI エージェントなら管理者作業を何でも代行できる | Fabric RBAC で許可された範囲の操作に限られる |
| すべての Fabric 機能が MCP ツール化されている | 高度な機能や一部操作は未対応の可能性がある |
| Notebook や Lakehouse テーブルの中身も自由に変更できる | アイテム内部のデータやコード変更は直接 Fabric 側の操作が必要になる場合がある |
| 自然言語なので安全に操作できる | 自然言語だからこそ、曖昧な指示や誤解による操作ミスに注意が必要 |
| プレビューでも本番運用にすぐ使える | 機能や構成が変わる可能性を前提に、検証環境から始めるべき |
特に「削除」や「権限変更」は、プロンプトの言い回しによって意図しない範囲に影響する可能性があります。最初は読み取り系と検証用リソース作成に限定し、運用ルールが固まってから段階的に対象を広げるのが安全です。
Microsoft Graph MCP Server 連携が必要になる場面
Fabric Core MCP Server だけでも Fabric 操作は可能ですが、ユーザーやグループをメールアドレスで扱いたい場合は Microsoft Graph MCP Server との連携が重要になります。公式クイックスタートでは、Graph MCP Server を追加すると、メールアドレスをユーザーのプリンシパル ID に自動解決できると説明されています。(Microsoft Learn)
Graph MCP Server がない場合は、次のようにユーザー ID を明示する必要があります。
Add user {uuid-guid} as Contributor to Sales AnalyticsGraph MCP Server を追加すると、次のようにメールアドレスで指定しやすくなります。
Add [email protected] as Contributor to Sales Analytics実務では、少人数の検証ならユーザー ID 指定でも運用できます。しかし、グローバル組織でチームやグループ単位の権限付与を行う場合は、メールアドレスやグループ名で指定できるほうが運用ミスを減らせます。ただし、Graph MCP 連携を追加すると、Fabric だけでなく Microsoft Graph 側の権限やデータ参照も関係するため、Entra ID 管理者とセキュリティ担当者を含めて設計する必要があります。
ローカル MCP Server との違い
Microsoft Fabric には、リモートの Core MCP Server とローカルの Fabric MCP Server という補完的な選択肢があります。公式の概要では、リモート Core server は Fabric ワークスペースやアイテムへの素早いアクセスに向き、ローカル Fabric MCP Server は API ドキュメント、OneLake データ、拡張性を含む開発ワークフローに向くと説明されています。(Microsoft Learn)
| 比較項目 | Core MCP Server remote | Fabric MCP Server local |
|---|---|---|
| 実行場所 | Microsoft 側のリモートエンドポイント | 利用者のローカル環境 |
| 主な用途 | 実際の Fabric ワークスペースやアイテム操作 | 開発支援、API 仕様参照、ローカルファイルを含む開発ワークフロー |
| インストール | ローカルサーバーのインストール不要 | ローカル環境へのセットアップが必要 |
| 認証 | Microsoft Entra ID による OAuth 2.0 | ローカル実行環境と Fabric 接続設定に依存 |
| 向いている利用者 | 管理者、データ基盤担当、運用自動化を試したいユーザー | Fabric 開発者、API や定義ファイルを扱う開発チーム |
| 導入時の注意 | プレビューのため変更可能性を考慮 | ローカル環境の標準化と拡張管理が必要 |
移行期限については、公式情報からは Core MCP Server への強制移行期限は確認できません。むしろ、リモート Core MCP Server とローカル Fabric MCP Server は用途が異なるため、どちらか一方にすぐ統一するよりも、運用管理系はリモート、開発支援はローカルというように役割を分けて検証するのが自然です。
管理者が確認すべきチェックリスト
Fabric Core MCP Server を試す前に、管理者は次の項目を確認しておくと安全です。
| 確認項目 | 見るべきポイント | 推奨アクション |
|---|---|---|
| Fabric テナントの利用可否 | 利用者が Fabric にアクセスできるか | 検証対象ユーザーを限定する |
| ワークスペース権限 | Viewer、Contributor、Member、Admin の割り当て | 不要な Admin 権限を削減する |
| ワークスペース作成権限 | 誰が新規ワークスペースを作れるか | 組織ポリシーに沿って制限する |
| MCP ホスト | VS Code、GitHub Copilot、その他 MCP ホストの利用可否 | 許可するホストを明文化する |
| OAuth 認証 | Entra ID、条件付きアクセス、多要素認証 | AI エージェント経由でも同じ認証統制が効くか確認する |
| 監査ログ | 誰が何を実行したか追跡できるか | 読み取り、作成、削除、権限変更のログを確認する |
| Graph MCP 連携 | メールアドレスでユーザー解決するか | 必要な場合のみ段階的に追加する |
| 削除操作 | ワークスペースやアイテム削除の影響 | 検証環境以外では制限または承認制にする |
| 教育 | 利用者が自然言語操作のリスクを理解しているか | 禁止プロンプト例と推奨プロンプト例を配布する |
特に注意すべきなのは、公式ツールリファレンスで「ワークスペース削除は元に戻せない」と説明されている点です。削除操作を AI エージェントから許可する場合は、検証環境に限定する、事前承認を必須にする、削除対象名にルールを設けるなどの対策が必要です。(Microsoft Learn)
よくある失敗と対処法
Fabric Core MCP Server の導入では、接続設定そのものよりも、権限・ID・ホスト仕様でつまずくケースが想定されます。
| 失敗例 | 主な原因 | 対処法 |
|---|---|---|
| ワークスペース一覧が取得できない | Fabric ワークスペースへのアクセス権がない | 少なくとも Viewer 権限があるワークスペースで確認する |
| 401 または 403 エラーが出る | 認証失敗、権限不足、セッション不整合 | MCP Server を削除して再追加し、ブラウザー認証をやり直す |
| ワークスペース ID エラーが出る | 名前と ID の指定が混在している | 先に list_workspaces で正しい ID を取得する |
| メールアドレスで権限付与できない | Graph MCP Server が未連携 | ユーザープリンシパル ID を使うか、Graph MCP 連携を検討する |
| 長時間操作の結果が分からない | 非同期操作の状態確認をしていない | operation-id を控え、状態と結果を確認する |
| リモート接続できない | MCP ホストが Streamable HTTP に対応していない | ホストの仕様を確認し、remote HTTP MCP 接続方法を調べる |
公式リファレンスでも、401 または 403 エラー時は VS Code で MCP Server を削除して再追加し、ブラウザー認証を完了する手順が案内されています。また、長時間操作では operation-id を使って状態を確認し、成功後に結果を取得する流れが示されています。(Microsoft Learn)
グローバル展開で注意すべき運用設計
グローバル企業で Fabric Core MCP Server を使う場合、技術的に接続できることと、組織として安全に使えることは別問題です。国・地域、部門、データ分類、開発プロセスごとに運用ルールを整える必要があります。
まず、検証は本番ワークスペースではなく、専用のサンドボックスワークスペースで始めるべきです。AI エージェントに「作成」「更新」「削除」「権限付与」を試させる場合、実データや本番レポートが置かれていない環境を使うことで、誤操作の影響を最小化できます。
次に、プロンプト運用ルールを決めます。たとえば、読み取り系は一般利用者にも許可し、作成系は開発者に限定し、削除・権限変更は管理者だけに許可する、といった分け方です。自然言語操作は便利ですが、「Finance workspace の不要な item を消して」のような曖昧な指示は危険です。実運用では、対象ワークスペース名、対象アイテム名、操作内容、確認ステップを明示するプロンプトを推奨する必要があります。
さらに、監査ログの確認を導入前の必須タスクにします。公式情報では、Fabric Core MCP Server 経由の操作も Fabric の監査ログに記録されると説明されています。検証段階で、誰のユーザー ID で、どの操作が、どのように記録されるかを確認しておくと、後からセキュリティレビューや内部監査に対応しやすくなります。(Microsoft Learn)
導入判断の基準
Fabric Core MCP Server は、次のような組織では早期検証の価値があります。
| 向いているケース | 理由 |
|---|---|
| Fabric ワークスペースやアイテムが増え、棚卸しに時間がかかっている | 自然言語で一覧取得や検索を行いやすい |
| 開発・検証環境の作成を効率化したい | ワークスペースや Lakehouse 作成の定型作業を支援できる |
| 権限レビューを効率化したい | ロール割り当ての一覧化や変更候補の確認に使える |
| AI エージェントによる運用自動化を検討している | Fabric REST API 操作を MCP 経由で試せる |
| すでに VS Code と GitHub Copilot を活用している | 推奨例に近い環境で検証を始めやすい |
一方で、次の状況では慎重に進めるべきです。
| 慎重に進めるべきケース | 理由 |
|---|---|
| Fabric の権限設計が整理されていない | AI 経由の操作で過剰権限が表面化しやすい |
| 本番と検証のワークスペースが分離されていない | 誤操作が本番データやレポートに影響する可能性がある |
| 監査ログの確認体制がない | 操作追跡やインシデント対応が難しくなる |
| AI 利用ルールが未整備 | 利用者ごとに危険な操作をしてしまう可能性がある |
| プレビュー機能を本番標準にできない組織ポリシーがある | 機能変更リスクを受け入れにくい |
現時点では、全社標準化よりも「限定された管理者・開発者が、検証用ワークスペースで、読み取り操作から始める」段階が適切です。
まず実施すべきアクション
Fabric Core MCP Server を試すなら、最初にやるべきことは明確です。まず、検証用ワークスペースを用意し、対象ユーザーに必要最小限の権限を付与します。次に、VS Code など Streamable HTTP transport に対応した MCP ホストで https://api.fabric.microsoft.com/v1/mcp/core を設定し、Microsoft Entra ID で認証します。接続後は List all my Fabric workspaces のような読み取り系プロンプトで、RBAC と監査ログが想定どおりに機能するか確認します。(Microsoft Learn)
その後、検証用のワークスペース作成、アイテム一覧取得、ロール一覧取得、Graph MCP 連携の要否確認へ進みます。削除操作や権限変更は、運用ルールと承認手順を決めてから試すべきです。
Microsoft Fabric Core MCP Server は、Fabric 管理と AI エージェント活用を結び付ける重要な入口です。ただし、プレビュー段階であること、実際の Fabric REST API 操作につながること、既存の権限設計がそのまま影響することを踏まえ、まずは小さく検証し、権限・監査・利用ルールを整えてから展開範囲を広げるのが安全です。
コメント