pac solution check をローカルで回す：CIサーバなしでも捨てない納品前検品

CIサーバが使えない環境でも、納品前検品を捨てる理由はない。
pac solution check（Power Platform CLIが提供する静的解析コマンド）はローカルマシンから直接Microsoftのチェッカーサービスに接続して実行できる。CIサーバは要件に含まれていない。
4検査を1本のスクリプトに集約し、全部通ってからzipを渡す——この設計をチェックリストの第1項目に置けば、走らせ忘れを構造的に防げる。

4検査の選択基準：最小十分条件を決める

顧客資産をクラウドに置けない・またはCIを組む余裕がない個人受託環境で、検品に組み込めるツールの組み合わせは自ずと絞られる。実務で機能してきた組み合わせがこの4つだ。

命名規約lint・スクラブ検査・Playwright E2Eの「それで十分か」を示す公的データはない。これは実務経験ベースの組み合わせであり、プロジェクトの規模や契約要件によって調整が必要になる。

pac solution check を実行する前に確認する3点

pac solution checkを使うにはいくつかの前提がある。「顧客資産をクラウドに置かない」方針を取っている場合は、特に3点目を読んでほしい。

1. インターネット接続が必要
pac solution checkはPower Apps Checker Cloud APIにアクセスして静的解析を行う設計になっている。完全オフライン環境では実行できない。
（出典：Microsoft Learn「pac solution - Power Platform CLI reference」2026-02-25 https://learn.microsoft.com/en-us/power-platform/developer/cli/reference/solution）

2. 認証プロファイルが必要
実行前にpac auth createで認証プロファイルを作成する必要がある。作成済みであれば--environmentパラメータは省略可能だ。コマンド例：

pac solution check --path c:\solutions\MySolution.zip --outputDirectory c:\results --geo UnitedStates

3. 解析対象ZIPがMicrosoftサービスに一時送信される
「顧客資産を外部クラウドに置かない」方針と緊張する点がここだ。pac solution checkは解析のためにZIPをCheckerサービスにアップロードする。「保存」ではなく「解析のための一時送信」だが、Microsoftが保存しないことを明示した公式保証文書は今回のリサーチでは確認できていない。顧客のNDAや契約上の機密レベルによっては利用不可のケースもあり得る。送信が発生するという事実を理解した上で、利用可否を判断してほしい。

Solution Checkerの頻出違反3パターン

デフォルトルールセット名は「Solution Checker」で、2024年以降20以上のルールが追加されており動的に更新される設計だ。Critical重大度の違反はManaged Environments設定時にインポートがブロックされる。
（出典：Microsoft Learn「managed-environment-solution-checker」2025 https://learn.microsoft.com/en-us/power-platform/admin/managed-environment-solution-checker）

実際に引っかかりやすいのはこの3つ。

（出典：Microsoft Learn「use-powerapps-checker」「avoid-window-top rule reference」2025 https://learn.microsoft.com/en-us/power-apps/maker/data-platform/use-powerapps-checker / https://learn.microsoft.com/en-us/power-apps/maker/data-platform/powerapps-checker/rules/web/avoid-window-top）

il-specify-columnはデータ量が少ない初期段階では症状が出ず、本番稼働後に顕在化するパターンが多い。web-avoid-window-topのCritical判定はインポートブロックに直結する。これらを納品前に潰しておくことで、顧客環境への展開後の差し戻しリスクを下げられる。

GitHub Actionsを使う場合：ubuntu-latest一択の理由

顧客資産を自分名義のリポジトリに置ける案件でGitHub Actionsを使う場合、ランナーOSはubuntu-latestにする。

GitHub ActionsはOS別に消費係数（Minute Multiplier）が異なる設計になっている。

（出典：GitHub Docs「About billing for GitHub Actions」2025 https://docs.github.com/billing/managing-billing-for-github-actions/about-billing-for-github-actions）

GitHub Freeの月間無料枠は2,000分（Linux換算）。Windowsランナーで使うと実質1,000分相当になる。pac CLIはdotnet toolでクロスプラットフォーム対応のため、ubuntu-latestで問題なく動く。

既定の支出上限は$0で、枠を超えた場合は課金ではなくワークフロー停止になる設計だ。翌月リセットまでprivate repoのActionsは動かなくなる。$0のまま運用する限りサプライズ請求は発生しない。
（出典：GitHub Docs「Managing your spending limit for GitHub Actions」2025 https://docs.github.com/en/billing/managing-billing-for-github-actions/managing-your-spending-limit-for-github-actions）

走らせ忘れをどう防ぐか

CIがない環境では、スクリプトを走らせるかどうかは手動判断になる。走らせ忘れが唯一の穴になる。

実務上の観察として、スクリプトをチェックリストの第1項目に置くと見落としが減る。「zipを作る前に」ではなく「zipを渡す前の最初の手順として」という位置づけにすることで、後回しになりにくくなる。

チェックリストの構成例：

□ 1. check-before-delivery.ps1 を実行し、全項目グリーンを確認
□ 2. ソリューションをエクスポートしてzipを作成
□ 3. zipに変更ログとバージョン番号を付与
□ 4. 顧客の受け取り方式（Teams / メール / ファイルサーバ）で納品

第1項目が検品スクリプトであれば、通過なしでは次に進めない心理的な構造になる。スクリプトを単体で作るだけでなく、このチェックリストとセットにして運用に組み込むところまでが設計の完成形だ。

個人PC上での検証環境構築や設計テンプレートの蓄積については、関連記事「Power Automate と Logic Apps、3年後の保守者で決める」で詳しく扱っている。

まとめ

CIサーバを立てずに検品を維持するなら、4検査を1本のスクリプトに集約し、チェックリストの第1項目に置く。pac solution checkには認証とインターネット接続が必要で、ZIPの一時送信が発生するという構造的制約は案件開始前に顧客と確認しておく。GitHub Actionsを使う場合はubuntu-latestにするだけでコストが半分になる。

次の一歩：pac CLIをローカルに入れ、pac auth createで認証プロファイルを作成し、手元のソリューションzipで一度回してみる。Solution Checkerの出力がどう返るかを確認するだけで、次の案件への転用判断ができる。

関連記事：

• prod-data-masking-boundary（スクラブ検査・実値混入検出の詳細）
• power-automate-loose-coupling（Power Platform設計方針）