先に結論を出す。DataverseのGit統合は開発環境と対象環境の両方をManaged Environmentsとして有効化することが前提であり、Developer PlanにはManaged Environmentsの使用権が含まれていない。
環境前提：Managed Environments必須・Developer Planでは使用権外。
Developer Plan環境でALMを組む実務解は pac solution export → pac solution unpack → 普通のgit。純正のGit統合機能を使わなくても、ALMとして十分足りる。
Git統合に何が要るか
Microsoft Learnの公式ドキュメント（Power Platform ALM Git Integration Overview、2025）に次のように明記されている。
“Development and target environments must be enabled as managed environments.”
開発環境だけでなく、対象環境（本番・テスト）も両方をManaged Environments（マネージド環境：Microsoftが提供する高度な管理・ガバナンス機能付きのPower Platform環境）として有効化する必要がある。
同FAQには「All users within the environment must meet license requirements for managed environments」ともある。環境内のすべてのユーザーがライセンス要件を満たしていなければならない。
Git統合を試みる前に確認すべきことは、この2点だ。
| チェック項目 | 確認すること |
|---|---|
| 開発環境 | Managed Environmentsとして有効化されているか |
| 対象環境（本番・テスト） | Managed Environmentsとして有効化されているか |
どちらか1つでも欠けていれば、Git統合は動かない。機能評価より前に、この前提を確認する。
Developer Planでは実質使えない
Managed Environmentsのライセンス要件について、公式ドキュメント（Managed Environment Licensing、2025）は次のように明記している。
“A managed environment isn’t included as an entitlement in the Developer Plan when users run their assets.”
Git統合を使うにはManaged Environmentsが必須で、Managed Environmentsを使うには以下のいずれかのライセンスが必要になる。
| 必要ライセンス（ユーザー1人あたり） |
|---|
| Power Apps Premium |
| Power Automate Premium |
| Dynamics 365 Enterprise（プレミアム使用権を含むもの） |
| Power Pages |
| Microsoft Copilot Studio |
| 容量ベースのプラン（Power Apps per app 等） |
Developer Planのみで開発している場合、Git統合は実質的に使えない。
2027年2月から何が変わるか
Managed Environmentsのライセンス強制化スケジュールは段階的に進んでいる（出典：Managed Environment Licensing、2025）。
- 2026年3月〜：管理者へのMicrosoft 365 Message Center通知開始
- 2026年6月〜：エンドユーザーへのアプリ内通知開始
- 2027年2月〜：ライセンスがない場合、アプリを開けなくなる
Managed Environmentsを有効化した環境でDeveloper PlanのみのユーザーがいるPower Platform環境を運用しているなら、今のうちにライセンス構成を確認しておく価値がある。
Gitプロバイダの現状
Git統合で使えるリポジトリプロバイダについても触れておく。Azure DevOpsはGA（一般提供済み）で使える。GitHubは2026年8月31日にPublic Preview開始（出典：Microsoft Learn Release Plan 2026 Wave 1、2026-03公開）で、2026年9月時点ではGAに達していない。GitHubを前提にGit統合を設計しようとしている場合は、現在のGAステータスを確認してから判断する。
pac CLIで組む代替ワークフロー
Managed Environmentsなし・Developer Planで動く代替ワークフローは3ステップで完結する。
# Step 1: ソリューションをZIP形式でエクスポート
pac solution export --zip ./solution.zip
# Step 2: ZIPをアンパック（数百ファイルのXML/YAMLに展開）
pac solution unpack --zipfile ./solution.zip --folder ./src
# Step 3: 普通のgitでバージョン管理
git add ./src
git commit -m "solution: update"
pac solution unpackの出力は数百ファイルのXML/YAML構造だ。このフォルダをgitで管理することで、変更差分を追える。gitはここでは「チームへの共有」というより、大量XMLの差分可視化とAIとの作業台として機能する道具として有効だ。
canvas appsのアンパックは方式が変わっている
canvas appsをsolution管理している場合、pac canvas pack/unpackコマンドは使わない。Power Platform Build Tools v1.49以降、このコマンドはdeprecated（非推奨）になっている（出典：pac canvas CLI reference、2025）。
現行推奨はSourceCodeレイアウト（*.pa.yaml）だ（出典：Power Apps YAML仕様、2025）。
| ファイル | 用途 |
|---|---|
\Src\App.pa.yaml | アプリ本体 |
\Src\[画面名].pa.yaml | 各画面 |
\Src\Component\[コンポーネント名].pa.yaml | コンポーネント |
JSONファイルはセーブ・ロード間で安定しないため、\Srcフォルダ内の.pa.yamlファイルのみを扱う。なお、Git Integration機能を利用した場合はcanvas appsが自動的に*.pa.yamlとしてリポジトリに格納される（出典：Canvas apps Git integration、2025）。
この代替ワークフローをM365 Developer Programの無料テナントで試す場合の環境構築については、→ 関連記事：個人PC開発環境の全体像と選択肢
まとめ
Power PlatformのGit統合はManaged Environments（開発・対象の両方）が前提で、Developer Planにはその使用権がない。使えない環境での実務解はpac solution export → pac solution unpack → 普通のgitであり、これで機能として十分足りる。ネイティブGit統合と違い変更のたびに手動エクスポート→アンパックが必要になる点は了解しておく。
次の一歩：pac solution export + pac solution unpackを一度動かしてみる。アンパック後のフォルダ構造を確認すると、git管理の粒度感が掴める。pac CLIのセットアップはpac CLIをUbuntu CIで安定動作させるを参照。
関連記事：Power Platform の unmanaged layer がデプロイを阻む仕組み
関連記事：Developer Planで30日非アクティブの自動無効化を踏んだら