Claude CodeでPower Platformのソリューションを編集する手順 — pac solution
Power Platformのソリューションをpac solution unpackでファイルに展開し、Claude Codeで編集してpackで戻す手順。環境への取り込みと削除を止めるdenyルールも紹介します。
Power Platformのソリューションは、そのままではZIPファイルです。Claude Codeに触らせるには、Power Platform CLI(pac)の pac solution unpack でファイルに展開し、編集後に pac solution pack でZIPへ戻します。Claude Codeが読み書きするのは手元のフォルダーだけに留め、環境への取り込み(import)と削除(delete)は人が実行する。この線引きが、環境の誤操作を防ぐ要点です。
この記事では、展開から差分レビュー、再パッケージまでの流れと、操作を止めるための権限ルールを順に説明します。
先に押さえる点 — unpackの既定はYAMLではなくXML
pac solution unpack の出力形式には2種類あります。既定はXML形式で、Other\Solution.xml を起点にした階層ができます。YAML形式(ソース管理形式)は、DataverseのGit統合でコミットしたフォルダーや pac solution clone で作ったフォルダーが使う形式です。
| 項目 | XML形式(既定) | YAML形式 |
|---|---|---|
| 目印 | XML形式(既定)Other\Solution.xml と Other\Customizations.xml | YAML形式solutions/ フォルダー配下の *solution.yml |
| 作られ方 | XML形式(既定)ZIPを pac solution unpack した場合 | YAML形式Git統合のコミット、pac solution clone |
| 差分の読みやすさ | XML形式(既定)メタデータが大きなXMLにまとまる | YAML形式コンポーネントごとに分かれ、差分が読みやすい |
キャンバスアプリの .msapp と最新のフロー | XML形式(既定)非対応 | YAML形式対応 |
| 複数ソリューションを1フォルダーに | XML形式(既定)不可 | YAML形式可 |
形式は pack 側で自動判定されます。solutions/ フォルダーに *solution.yml があればYAML、無ければXMLとして読まれます。YAML形式のpackにはPower Platform CLI 2.4.1以降が必要です。
つまり「ZIPをunpackすればYAMLで差分レビューできる」とは限りません。YAMLで差分を見たいなら、Git統合を有効にした環境のリポジトリを使うか、pac solution clone で取得します。ZIPからのunpackなら、Claude Codeが読むのはXMLです。どちらの形式でも、後述の権限ルールとレビューの流れは同じです。
準備 — pacの導入と認証プロファイル
pac の導入方法は3つあります。Visual Studio Code拡張、.NETツール、Windows MSIです。.NETツールだけで入れた場合、pac data と一部の pac package コマンド(deploy と show)は使えません。ソリューションのunpack/packには関係しないので、この記事の手順では問題になりません。
導入できたか、バージョンはいくつかは次のコマンドで確かめます。
which pac
pacpac を引数なしで実行すると、2行目にバージョンが出ます(Windowsでは Get-Command pac | Format-List)。
次に認証プロファイルです。ほとんどの pac コマンドは認証済みの環境を前提にします。
pac auth create --environment "HR-Dev"
pac auth list--environment には環境ID、URL、一意の名前、名前の一部を渡せます。省略すると既定の環境につながります。複数のプロファイルがあるときは pac auth select --index 2 で切り替わります。
ここで誤操作の入口が見えます。アクティブなプロファイルが本番を指していると、--environment を付けないコマンドは本番に向かいます。 pac solution export も import も delete も、--environment が無ければ現在のプロファイルの環境が対象です。
手順 — 展開、編集、再パッケージ
全体の流れを5段で示します。環境に触れるのは1と5だけで、2〜4はローカルのフォルダー内で完結します。
環境からローカルへ、ローカルから環境へ
- 1
開発環境からエクスポートする
pac solution exportでZIPを得ます。対象は開発環境のアンマネージドソリューションです。 - 2
unpackでフォルダーに展開する
ZIPをフォルダーに展開し、Gitで管理します。
- 3
Claude Codeで編集し、差分を読む
編集範囲はフォルダー内に限ります。
git diffで変更箇所を確認します。 - 4
packでZIPに戻す
編集後のフォルダーから、取り込み用のZIPを作ります。
- 5
開発環境へ人が取り込む
pac solution importは人が実行します。取り込み先は開発環境から始めます。
1. エクスポートとunpack
エクスポートでは、ソリューション名を --name に、出力先を --path に渡します。--managed を付けるとマネージドで出力されますが、編集の元にするのはアンマネージドです。SolutionPackagerの仕様として、マネージドとアンマネージドは相互に変換できません。変換する唯一の方法は、アンマネージドを環境に取り込み、あらためてマネージドとして出力することです。
pac solution export --name SampleSolution \
--path ./work/SampleSolution.zip \
--environment "HR-Dev"
pac solution unpack --zipfile ./work/SampleSolution.zip \
--folder ./solution-src
git add solution-src
git commit -m "add: SampleSolution を展開"pac solution unpack の --packagetype は既定が Unmanaged です。Both を指定すると、マネージドとアンマネージドの両方のZIPを1つのフォルダーに展開できます。その場合は両方のZIPが必要です。
展開した直後にコミットしておくと、あとの差分がすべて「Claude Codeの編集分」になります。ZIPは .gitignore に入れておきます。
2. CLAUDE.mdに作業の境界を書く
Claude Codeには、触る場所と触らない操作を先に伝えます。たとえば次のように書きます。
## Power Platformソリューション
- 編集してよいのは solution-src/ 配下だけ
- 変更後は pac solution pack で work/SampleSolution.zip を作り、成功を確認する
- pac solution import / delete / publish / upgrade は実行しない
- 環境に接続するコマンドには必ず --environment を付ける
- 変更したファイルと、変更の理由を最後に一覧で報告する「成功を確認する」を完了条件にしておくと、Claude Codeは編集のたびに pack を走らせ、フォルダーが壊れていないかを確かめられます。YAML形式の場合、rootcomponents.yml に載せたコンポーネントのファイルがフォルダーに無くても、pack は成功します。その場合、出力ZIPからそのコンポーネントが黙って抜けます。たとえば canvasapps/<名前>/ の .msapp が無い場合です。「packが通った」だけでなく、「報告された変更ファイルが想定どおりか」まで確かめる運用が安全です。
3. 差分をレビューする
編集が終わったら git diff でファイルごとの変更を読みます。XML形式では、1ファイルに多くの定義が入るので、差分の周辺行まで読む必要があります。レビューの観点は次の3つです。
- 依頼した変更だけが入っているか。ほかのコンポーネントが書き換わっていないか
- ファイルの追加と削除が、依頼の範囲に収まっているか
- 名前や識別子の書き換えが、他の定義からの参照とずれていないか
rootcomponents.yml や solutioncomponents.yml のように、ソリューションに含まれるコンポーネントを列挙するファイルが動いていたら、意図したものか必ず確認します。
4. packしてZIPに戻す
pac solution pack --zipfile ./work/SampleSolution-edited.zip \
--folder ./solution-srcpack は、ZIPを作るだけで環境には触れません。元のZIPを上書きしない名前にしておくと、取り込み前後の比較ができます。XML形式のフォルダーでは Other\Solution.xml と Other\Customizations.xml が必須です。YAML形式の見分けは solutions/ フォルダーで決まります。YAMLのマニフェストをフォルダー直下に置いてしまうと、YAML形式として検出されません。XMLの経路に落ちて、Customizations.xml が無いという紛らわしいエラーになります。
複数のソリューションが入ったYAMLのリポジトリでは、pac solution pack ではなく SolutionPackager.exe を /SolutionName: 付きで使います。
取り込み前に品質を確かめたいなら、pac solution check が使えます。ソリューションをPower Apps checkerのサービスに送って検査する仕組みです。外部サービスにZIPを送るため、後述の権限ルールでは確認付き(ask)に置いておきます。
5. 取り込みは人が実行する
pac auth list
pac solution import --path ./work/SampleSolution-edited.zip \
--environment "HR-Dev"取り込む前に pac auth list でアクティブなプロファイルを確かめます。--path を省略すると、現在のフォルダーがcdsprojプロジェクトだと見なされるので、ZIPのパスは省略しません。取り込み先に未公開の変更が残っているなら --force-overwrite、取り込み後に公開するなら --publish-changes というスイッチがありますが、どちらも付けるかどうかは取り込む人が判断します。
環境の誤操作を止めるdenyルール
ここからが本題の安全策です。プロジェクトの .claude/settings.json に、pac のうち環境へ書き込むコマンドを止める設定を置きます。
{
"permissions": {
"allow": [
"Bash(pac solution unpack *)",
"Bash(pac solution pack *)",
"Bash(pac auth list *)"
],
"ask": [
"Bash(pac solution export *)",
"Bash(pac solution check *)"
],
"deny": [
"Bash(pac solution import *)",
"Bash(pac solution delete *)",
"Bash(pac solution publish *)",
"Bash(pac solution upgrade *)",
"Bash(pac auth create *)",
"Bash(pac auth select *)"
]
}
}分け方は次のとおりです。
| 区分 | コマンド | 理由 |
|---|---|---|
| allow | コマンドunpack pack auth list | 理由ローカルのファイル操作と、プロファイルの一覧表示だけ |
| ask | コマンドexport check | 理由環境から読み出す、またはZIPを外部サービスへ送る |
| deny | コマンドimport delete publish upgrade | 理由環境の状態を変える |
| deny | コマンドauth create auth select | 理由向き先の環境を切り替える |
評価の順序はdeny、ask、allowです。denyに一致すれば、より具体的なallowがあっても止まります。末尾に空白付きの * を置いた Bash(pac solution unpack *) は、引数なしの pac solution unpack にも一致します。
denyルールが止められないもの
この設定は境界の目印であって、突破できない壁ではありません。Bashの拒否ルールは、Claudeが書いたコマンドの文字列に対して一致します。次の形は一致しません。
- パスを付けた起動(
/usr/local/bin/pac solution import ...) sh -c 'pac solution import ...'のようにシェルを介した起動
一方、単純な前置きは外して判定されます。timeout 30 pac solution import ... や、FOO=bar pac ... のような環境変数の前置きは、denyにもそのまま一致します。
だから、文字列の拒否に頼りすぎない構成にします。
- 作業用のプロファイルは開発環境だけにつなぐ。本番のプロファイルをPCに残さない
- 取り込みはCI、または人のターミナルで行う
- ルールを回避された事例と対策は、Claude Codeの拒否ルールをeval等ですり抜けられる問題と対策に詳しくあります
WindowsのPowerShellで pac を使う構成では、上のルールが対象にするのはBashツール経由の実行です。BashとPowerShellのツールの関係は、Denying BashでPowerShellも止まる警告で説明しています。
つまずきやすい点
落とし穴
環境から消したコンポーネントのファイルがフォルダーに残る
pac solution unpack の --allowDelete は、削除を伴う操作を許すかを決めるスイッチで、既定は false です。環境側で消したコンポーネントのファイルが展開先に残っていないか、unpack後の git status と git diff で確かめます。追加と変更だけでなく、消えるはずのファイルが残っていないかも見ます。
落とし穴
packが成功したのにコンポーネントが足りない
YAML形式で、rootcomponents.yml にあるコンポーネントのファイルが無い場合、pack は成功しますが、そのコンポーネントを除いたZIPができます。確実に揃えるには、環境からソリューション全体をエクスポートし、unpackし直します。
落とし穴
SolutionPackagerを新しく入れてしまう
SolutionPackager ツールは、Power Platform CLIに機能が取り込まれ、アンパックとパックの推奨手段ではなくなっています。新しく始めるなら、pac solution の動詞(unpack pack clone sync)を使います。例外は、複数ソリューションが入ったYAMLのリポジトリをpackするときです。
開発を続けるならcloneとsync
最初の1回だけなら、export、unpack、packの流れで足ります。同じソリューションを何度も直すなら、pac solution clone でソリューションのプロジェクトを作り、以後は pac solution sync で環境の現状に合わせる方法があります。
pac solution clone --name SampleSolution
pac solution syncclone は既存のソリューションを元に、手元にプロジェクトを作ります。sync は、そのプロジェクトを環境のソリューションの現状に揃えます。clone したフォルダーはYAML形式です。差分を読みやすくしたいチームは、こちらが向いています。
DataverseのGit統合も、同じYAML形式で保存します。環境の側で変更をコミットできる構成なら、Claude Codeは「Gitのリポジトリを編集する」だけで済み、ZIPの出し入れが要りません。Capacitorアプリ開発のように、生成コマンドをallowに置いて、実機や外部に出る操作をaskに置く三層の分け方も、pac のコマンドにそのまま当てはまります。
まとめ
ZIPからのunpackで得られるのはXML形式で、YAML形式はGit統合や clone のものです。この違いを知っておくと、差分レビューの前提がそろいます。Claude Codeに任せる範囲は「フォルダーの編集と pack まで」に置き、import delete publish upgrade と認証の切り替えはdenyで止めます。denyは文字列の一致なので、本番につながるプロファイルをPCに残さない運用と組み合わせます。