Microsoft Fabric Git integrationは、Microsoft FabricのワークスペースをGitリポジトリと接続し、Fabricアイテムをバージョン管理・共同開発・復元・CI/CD連携に使えるようにする機能です。結論から言うと、複数人でレポート、Notebook、Lakehouse、Pipeline、SQL databaseなどを開発しているチームは、開発用ワークスペースをGitに接続し、テスト・本番への展開はDeployment pipelinesやREST APIと組み合わせて設計するのが現実的です。(Microsoft Learn)
ただし、Microsoft Fabric Git integrationは「すべてをGitに保存するバックアップ機能」ではありません。対象アイテム、プレビュー機能、テナント設定、権限、ネットワーク制御、初回同期の向きによって、運用上のリスクが大きく変わります。この記事では、2026年5月時点の公式情報をもとに、管理者・開発者が確認すべき変更点、影響範囲、設定、移行・展開時の注意点を整理します。
Microsoft Fabric Git integrationとは
Microsoft Fabric Git integrationは、FabricのワークスペースとGitリポジトリを連携させるソース管理機能です。開発者はFabric上で作成・編集したアイテムをGitへコミットし、必要に応じて以前の状態へ戻したり、ブランチを使って複数人で作業したりできます。公式ドキュメントでは、作業のバックアップ、バージョン管理、以前のステージへの復元、Gitブランチを使った共同作業、使い慣れたソース管理ツールによるFabricアイテム管理が主な用途として説明されています。(Microsoft Learn)
実務で重要なのは、連携が「ワークスペース単位」で行われる点です。1つのワークスペースを1つのGitブランチと接続し、そのワークスペース内のサポート対象アイテムをまとめて管理します。サブフォルダーを含むワークスペース構造もGitリポジトリ側に保持されるため、リポジトリ設計はアイテム単位ではなく、ワークスペースとフォルダー構成を前提に考える必要があります。(Microsoft Learn)
今回の公式情報で押さえるべき変更点と読み解き方
公式のOverviewページは変更履歴そのものではなく、現行仕様を整理したページです。そのため、ここでの「変更点」は、管理者や開発者が従来の運用を見直すべきポイントとして読むのが適切です。
| 確認ポイント | 実務への影響 | まず確認すること |
|---|---|---|
| Git連携はワークスペース単位 | 個別アイテムだけを気軽にGit管理する設計ではなく、ワークスペース構成そのものが重要になる | Dev/Test/Prodのワークスペース分離、接続するブランチ、フォルダー構成 |
| 対応Gitプロバイダーが明確化 | Azure DevOps、GitHub、GitHub Enterpriseを利用できるが、クラウドベースのみ | オンプレミスGitHub Enterprise Serverやプライベートネットワーク利用の有無 |
| 対応アイテムが広い一方、一部はプレビュー | Lakehouse、Notebook、Pipeline、Power BI、SQL databaseなど幅広いが、すべてのFabricアイテムが同じ成熟度ではない | 本番運用するアイテムがサポート対象か、プレビュー扱いか |
| ネットワークセキュリティとの関係が重要 | Private LinkやOutbound Access Protectionを使う環境では、Git操作がブロックされる場合がある | ワークスペースごとの受信・送信制御、Allow Git integration設定 |
| Gitはデータそのものの完全バックアップではない | Git操作で復元されるのは主にアイテム定義であり、データ復旧とは別に考える必要がある | LakehouseやWarehouseなどのデータ保護、バックアップ、復旧手順 |
Microsoft FabricのGit連携で対応するGitプロバイダーは、Azure DevOps、GitHub、GitHub Enterpriseのクラウド版です。GitHub Enterprise Serverのカスタムドメイン、プライベートネットワーク上のGitHub Enterprise Server、IP許可リストなどは制限事項として扱われているため、規制業界や閉域網中心の組織では事前検証が欠かせません。(Microsoft Learn)
また、2026年5月のMicrosoft Fabricの更新情報では、SQL database in Fabricについて、スキーマをSQLファイルとしてGitHubまたはAzure DevOpsにコミットし、Pull Requestでレビューし、Fabricワークスペースへ展開する流れが案内されています。SQL databaseをFabric上で利用しているチームは、BIやデータエンジニアリングだけでなく、データベースDevOpsの観点でもGit統合を確認しておくべきです。(Microsoft Learn)
影響を受ける対象者
Microsoft Fabric Git integrationの影響は、開発者だけに閉じません。ワークスペース、権限、テナント設定、セキュリティ、リリース運用が絡むため、複数の担当者で確認する必要があります。
| 対象者 | 主な影響 | 確認すべきこと |
|---|---|---|
| Fabric管理者 | テナント設定、GitHub連携、クロスリージョン、秘密度ラベル、ネットワーク制御の判断が必要 | 管理ポータルのGit統合設定、許可するユーザー・グループ |
| ワークスペース管理者 | Gitリポジトリ接続、ブランチ切替、切断、初回同期の責任を持つ | どのワークスペースをどのブランチへ接続するか |
| 開発者 | Fabric上の変更をGitへコミットし、Git側の更新をワークスペースへ反映する | 作業ブランチ、コミット粒度、競合解消、更新タイミング |
| リリース担当者 | GitとDeployment pipelinesの使い分けが必要 | DevからTest/Prodへどう昇格するか |
| セキュリティ担当者 | 外部Gitサービスへの通信、メタデータ持ち出し、ラベル付きアイテムの扱いを確認する | Private Link、OAP、感度ラベル、監査ログ |
特に注意すべきなのは、ワークスペースが共有ランタイム環境である点です。ワークスペースに直接加えた変更は同じワークスペースの他ユーザーにも影響します。公式ドキュメントでは、開発者が保護された作業環境を持つ方法として、分岐したワークスペースを使う方法や、Power BI Desktop、VS Codeなどのクライアントツールを使う方法が示されています。(Microsoft Learn)
サポートされるGitプロバイダーとアイテム
Microsoft Fabric Git integrationでサポートされるGitプロバイダーは、クラウドベースのAzure DevOps、GitHub、GitHub Enterpriseです。Azure DevOpsではOAuth2またはService Principalを使った認証、GitHubではPersonal Access Tokenを使った認証が案内されています。(Microsoft Learn)
| 分類 | 主なサポート対象 | 注意点 |
|---|---|---|
| Data Engineering | Environment、GraphQL、Lakehouse、Notebook、Spark Job Definition、User Data Functions | NotebookやLakehouseを含む開発では、参照関係と環境差分に注意 |
| Data Science | Machine learning experiments、Machine learning models、Data Agents | 一部はプレビュー |
| Data Factory | Copy Job、Dataflow Gen2、Pipeline、Mirrored database、Mount ADF、Mirrored Snowflake | Mirrored Snowflakeなど一部はプレビュー |
| Real-Time Intelligence | Activator、Eventhouse、Eventstream、KQL database、KQL Queryset、Real-Time Dashboard、Maps、Anomaly detectionなど | 一部はプレビュー |
| Data Warehouse | Warehouse、Mirrored Azure Databricks Catalog | Warehouseはプレビュー扱いとして記載 |
| Power BI | Metrics Set、Org app、Paginated report、Report、Semantic model | ReportやSemantic modelには例外条件がある |
| Database | SQL database、Cosmos database | Cosmos databaseはプレビュー |
| Graph / Industry solutions | Graph、Healthcare、HealthCare Cohort | プレビュー対象が含まれる |
ワークスペースやGitディレクトリ内にサポート対象外のアイテムがあっても、接続自体は可能です。ただし、サポート対象外アイテムはGitに保存・同期されず、削除もされません。ソース管理パネルには表示されますが、コミットや更新の対象にはできないため、「接続できた＝全アイテムがGit管理された」と判断しないことが重要です。(Microsoft Learn)
管理者が確認すべきテナント設定
Git integrationを使うには、Fabric側とGit側の両方で前提条件を満たす必要があります。Fabric側ではFabric capacityが必要で、Power BI Premium capacityを利用できる場合もありますが、SKUによって扱えるアイテムに制限がある点に注意が必要です。さらに、管理ポータル側のテナントスイッチも確認しなければなりません。(Microsoft Learn)
| 設定 | 確認内容 | 実務上の判断 |
|---|---|---|
| Users can create Fabric items | Fabricアイテムを使う場合に必要 | 開発者グループに限定して有効化するかを検討 |
| Users can synchronize workspace items with their Git repositories | ワークスペースとGitの同期を許可 | 全社許可ではなく、対象グループから開始するのが安全 |
| Create workspaces | Branch outで新しいワークスペースを作る場合に必要 | 開発者が自由にワークスペースを増やせる運用にするか決める |
| Users can synchronize workspace items with GitHub repositories | GitHubを使う場合に必要 | 既定では無効のため、GitHub利用チームは必ず確認 |
| Cross-geo export | ワークスペース容量とAzure DevOpsリポジトリが異なる地理にある場合に必要 | メタデータの越境を許可するか、セキュリティ部門と判断 |
| Sensitivity labels付きアイテムのGit export | 感度ラベルはエクスポートに含まれない | ラベル付きアイテムのGit連携を許可するかブロックするかを決める |
Git integrationのテナント設定は、管理ポータルのテナント設定で構成します。テナント管理者は、容量管理者やワークスペース管理者へ制御を委任できます。GitHubリポジトリとの同期は既定で無効とされているため、GitHubを使う組織ではこの設定を見落とすと接続作業で止まります。(Microsoft Learn)
感度ラベル付きアイテムについては、ラベル自体がエクスポートに含まれません。そのため、管理者は「ラベル付きアイテムのエクスポートをブロックする」か「ラベルなしでのエクスポートを許可する」かを判断する必要があります。機密データを扱う部署では、Gitリポジトリ側のアクセス権限だけでなく、ラベル運用との整合性も確認してください。(Microsoft Learn)
ネットワークセキュリティで注意すべき点
Microsoft Fabric Git integrationは、Fabricワークスペースと外部Gitサービスの間でpull/pushを行うため、外部通信が発生します。Private LinkやWorkspace Outbound Access Protectionを使うワークスペースでは、Git連携がそのまま使えない場合があります。(Microsoft Learn)
Private Linkが有効なワークスペースでは、ユーザーは承認されたVNet経由で接続する必要があります。承認されていないネットワークからGitペインを開いたり、Git操作を行ったりしようとすると、Fabric側でブロックされます。これはUIだけでなくGit APIにも影響します。(Microsoft Learn)
Workspace Outbound Access Protectionが有効な場合、既定ではGit連携はブロックされます。Gitを許可するには、ワークスペースのOutbound networking設定でAllow Git integrationを有効にする必要があります。この許可はワークスペース単位であり、新しく作成した分岐ワークスペースへ自動コピーされるものではありません。(Microsoft Learn)
| 状態 | Git integrationの扱い |
|---|---|
| OAP有効、Allow Git integration無効 | Git連携は利用不可 |
| OAP有効、Allow Git integration有効 | 対象ワークスペースでGit連携を利用可能 |
| OAP無効 | Allow Git integrationのトグルは影響しない |
もう1つ重要なのは、Deployment pipelinesとワークスペースの受信・送信アクセス保護の関係です。公式ドキュメントでは、Deployment pipelinesはワークスペースの受信・送信アクセス保護に現在対応していないとされています。Git、OAP、Deployment pipelinesを同時に使う構成では、セキュリティ要件とリリース要件が衝突しないか事前に設計してください。(Microsoft Learn)
開発者が押さえるべき基本操作
Microsoft Fabric Git integrationの基本操作は、接続、コミット、Gitからの更新、切断です。操作自体はシンプルですが、初回同期と更新方向を誤ると、ワークスペースまたはGit側の内容を上書きする可能性があります。(Microsoft Learn)
| 手順 | やること | 注意点 |
|---|---|---|
| リポジトリ準備 | Azure DevOpsまたはGitHubにリポジトリ、ブランチ、必要に応じてフォルダーを用意 | 1ワークスペースは1ブランチ・1フォルダーに接続する前提で設計 |
| ワークスペース接続 | Workspace settingsからGit integrationを選び、Gitプロバイダーを接続 | 接続はワークスペース管理者が実施 |
| 初回同期 | ワークスペースとGitのどちらを正とするか選択 | 両方に内容がある場合、方向を誤ると上書きが起こる |
| Commit | Fabric上の変更をGitへ反映 | 変更は保存しただけではGitに入らない |
| Update from Git | Git側の最新コミットをワークスペースへ反映 | Updateはブランチ全体が対象で、アイテム単位選択はできない |
| Disconnect | ワークスペースとGitの接続を解除 | 切断はワークスペース管理者が実施 |
開発者が最も誤解しやすいのは、「Fabricで保存した変更が自動的にGitへコミットされるわけではない」点です。変更はまずワークスペースに保存され、Source controlパネルで対象アイテムを選び、コメントを付けてコミットします。逆に、Git側で新しいコミットが作成された場合は、ワークスペース側でUpdate from Gitを実行して反映します。(Microsoft Learn)
Git側に更新がある場合、通常のコミットが無効になることがあります。その場合でも、Commit to new branchを使うと、現在の変更を新しいブランチへコミットできます。ただし、新しく作成されたブランチは既存ワークスペースに接続されず、現在のワークスペース状態も変更されない点に注意してください。(Microsoft Learn)
権限設計で失敗しやすいポイント
Git integrationでは、Fabricワークスペースの権限とGitリポジトリ側の権限の両方が必要です。Fabric側でContributor以上でも、Git側に読み取り・書き込み権限がなければコミットできません。逆にGit側に権限があっても、ワークスペース接続やブランチ切替はFabric側のAdmin権限が必要です。(Microsoft Learn)
| 操作 | Fabric側で必要な代表的権限 | Git側で必要な代表的権限 |
|---|---|---|
| ワークスペースをGitに接続 | Workspace Admin | 対象リポジトリのRead |
| Gitとの同期 | Workspace Admin | Read |
| Gitへコミット | Contributor相当、対象アイテムへのWRITEなど | Read、Contribute、直接コミットを許可するブランチポリシー |
| Gitから更新 | Contributor相当、必要に応じて外部依存へのBUILD | Read |
| ブランチ作成 | Workspace Admin | ブランチ作成権限 |
| Branch out | Admin、Member、Contributor | Read、ブランチ作成権限 |
ViewerロールのユーザーはGit関連情報を表示できず、Git操作もできません。運用開始前に「誰が接続するか」「誰がコミットするか」「誰が本番へ展開するか」を分けて設計すると、権限不足による作業停止を避けやすくなります。(Microsoft Learn)
移行時に確認すべき注意点
既存ワークスペースをGitへ接続する場合、初回同期が最も重要です。ワークスペースまたはGitブランチのどちらか一方が空なら、内容がある側から空の側へコピーされます。一方、両方に内容がある場合は、ワークスペースをGitへコミットするか、Gitの内容でワークスペースを更新するかを選びます。後者を選ぶとワークスペース内容が上書きされるため、事前バックアップや検証用ワークスペースでの確認が必要です。(Microsoft Learn)
移行で特に失敗しやすいのは、既存の本番ワークスペースをそのままGit接続するケースです。本番ワークスペースには、レポート、セマンティックモデル、Pipeline、Lakehouseなど依存関係のあるアイテムが混在しがちです。まずは開発用ワークスペースを作り、対象アイテムがGit integrationのサポート対象か、プレビュー機能を本番運用に含めてよいかを確認してから進めるのが安全です。
| リスク | 起こりやすい状況 | 対策 |
|---|---|---|
| 初回同期で上書き | ワークスペースとGitの両方に既存内容がある | 事前に同期方向を決め、検証環境で試す |
| 非対応アイテムがGit管理されない | ワークスペース内に未サポートアイテムがある | Source controlパネルでUnsupported itemを確認 |
| フォルダー差分で未コミット扱いになる | ワークスペース側にフォルダーがあり、Git側にない | 先にフォルダー変更をコミットする |
| アイテム名重複で失敗 | Power BI側では許容される重複名がある | Git連携前に命名規則を整理 |
| 感度ラベルが保持されない | ラベル付きアイテムをGitへエクスポート | 管理者設定とラベル再設定手順を用意 |
| 削除・復元で重複IDが発生 | Git操作とRecycle bin復元を併用 | どちらの復元手段を使うか手順化 |
公式ドキュメントでは、フォルダー構造は最大10階層まで保持され、空フォルダーの扱いにも制限があります。また、My workspaceはGitプロバイダーへ接続できず、テンプレートアプリがインストールされたワークスペースもGit接続できません。ワークスペース内のアイテム数、ファイルサイズ、パス長、ブランチ名長にも制限があるため、大規模ワークスペースは分割を検討してください。(Microsoft Learn)
Git integrationとDeployment pipelinesの使い分け
Microsoft FabricのALMでは、Git integrationとDeployment pipelinesを混同しないことが重要です。Git integrationは主にソース管理と共同開発、つまりCI寄りの機能です。一方、Deployment pipelinesは、開発、テスト、本番などの環境へコンテンツを展開するCD寄りの機能です。公式ドキュメントでも、効率的なライフサイクル管理として、開発ワークスペースをGitに接続し、その接続済みワークスペースからDeployment pipelinesで展開する流れが示されています。(Microsoft Learn)
実務では、次のような構成が扱いやすいです。
| 環境 | 役割 | Gitとの関係 | 展開方法 |
|---|---|---|---|
| Dev | 開発・レビュー前の変更を集約 | Gitブランチに接続 | 開発者がCommit / Update |
| Test | 動作確認、データ接続確認、権限確認 | 原則として直接Git接続しない構成も選択可 | Deployment pipelinesでDevから展開 |
| Prod | 利用者向け本番環境 | 直接編集を避ける | Deployment pipelinesまたはAPIで展開 |
すべての環境をGitに直接つなぐより、開発ワークスペースをGit管理の起点にして、Test/Prodへの反映はDeployment pipelinesで制御するほうが、権限管理とリリース承認を分けやすくなります。ただし、組織によってはGitブランチ、REST API、Service Principalを組み合わせた自動化を選ぶ場合もあります。Fabric Git REST APIでは、接続、切断、Git status取得、コミット、ワークスペース更新などの操作を自動化できます。(Microsoft Learn)
Azure DevOpsで自動化する場合は、Service Principalを使った構成も選択肢です。Service Principalには、関連するAzure DevOps組織・プロジェクトへのアクセスと、FabricワークスペースのAdmin権限が必要です。人のアカウントに依存しないCI/CDを設計する場合は、接続情報の管理、シークレット保護、権限の最小化をセットで検討してください。(Microsoft Learn)
本番展開前のチェックリスト
Microsoft Fabric Git integrationを導入する前に、次のチェックリストを使って環境を確認してください。
| タイミング | チェック項目 |
|---|---|
| 導入前 | Fabric capacityまたは利用可能なPremium capacityがあるか |
| 導入前 | Git integrationのテナント設定が対象ユーザーまたはグループに対して有効か |
| 導入前 | GitHubを使う場合、GitHub同期のテナント設定が有効か |
| 導入前 | 利用するGitプロバイダーがクラウド版か |
| 導入前 | ワークスペース内のアイテムがサポート対象か、プレビュー扱いか |
| 接続前 | ワークスペースとGitブランチのどちらを初回同期の正とするか決めたか |
| 接続前 | サブフォルダー構成、命名規則、重複名を整理したか |
| 接続前 | 感度ラベル付きアイテムの扱いを管理者と合意したか |
| 接続前 | Private LinkやOAPを使うワークスペースでGit操作が許可されているか |
| 運用前 | Dev/Test/Prodの展開手順をGitとDeployment pipelinesで分けたか |
| 運用前 | コミットメッセージ、PRレビュー、ブランチ命名、リリース承認のルールを決めたか |
| 運用前 | Gitで復元できる範囲と、データ復旧手順を切り分けたか |
ライセンス面も見落とせません。公式ドキュメントでは、有効なPremiumライセンスがない場合、Gitリポジトリへ接続できず、ライセンスが失効またはGit integrationを含まないライセンスへ変更された場合はGit integration機能が停止すると説明されています。試用版で検証している場合も、本番移行前にライセンス継続性を確認しておきましょう。(Microsoft Learn)
管理者・開発者が次に取るべき行動
Microsoft Fabric Git integrationを安全に始めるなら、最初に本番ワークスペースではなく、開発用ワークスペースで小さく検証するのがよい方法です。まず対象アイテムを棚卸しし、サポート状況とプレビュー機能を確認します。次に、テナント設定、Gitプロバイダー、権限、ネットワーク制御を確認し、初回同期の向きを明確にします。
開発チームでは、作業用ブランチ、コミットルール、Pull Requestレビュー、Deployment pipelinesによるTest/Prod展開をセットで設計してください。Git integrationは、FabricアイテムをGitに保存するだけの機能ではなく、Fabric上のデータ分析・BI・データエンジニアリング開発をチーム開発へ移行するための基盤です。だからこそ、最初の接続設定よりも、権限・ブランチ・展開・復旧のルール作りが成功の分かれ目になります。
コメント