Claude Media
Claude CodeでPower Platformのソリューションを編集する手順 — pac solution

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.xmlYAML形式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
pac

pac を引数なしで実行すると、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. 1

    開発環境からエクスポートする

    pac solution export でZIPを得ます。対象は開発環境のアンマネージドソリューションです。

  2. 2

    unpackでフォルダーに展開する

    ZIPをフォルダーに展開し、Gitで管理します。

  3. 3

    Claude Codeで編集し、差分を読む

    編集範囲はフォルダー内に限ります。git diff で変更箇所を確認します。

  4. 4

    packでZIPに戻す

    編集後のフォルダーから、取り込み用のZIPを作ります。

  5. 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-src

pack は、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にもそのまま一致します。

だから、文字列の拒否に頼りすぎない構成にします。

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 sync

clone は既存のソリューションを元に、手元にプロジェクトを作ります。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に残さない運用と組み合わせます。

この記事を共有:XはてブLinkedIn