pac CLI の導入方式は3つある。どれを選ぶかは後で使うランナー OS と直結していて、好みで決めると後から変えにくい。
dotnet tool を選べば Windows でも Linux でも macOS でも同じコマンドが動く。それが Ubuntu ランナーを選べる前提になる。
Ubuntu ランナーで CI を回せば Windows より分数消費が半分になる——この順番で決めておくと、後で迷わない。

3方式の選び分けと根拠

Microsoft Learn 公式が示す3方式は以下のとおり。

方式手段主な用途
dotnet tooldotnet tool install --global Microsoft.PowerApps.CLI.Tool個人 PC 開発 + CI（クロスプラットフォーム）
Windows MSIGUI インストーラーWindows 端末・認証プロファイルの GUI 確認
VS Code 拡張Power Platform Tools 拡張エディタ統合

3方式は併用可能。開発機に Windows MSI を入れながら、CI ランナー（Linux）では dotnet tool を使う構成も成立する。

個人 PC 開発と CI を両方回すなら dotnet tool が軸になる。理由はクロスプラットフォームの一点で、Ubuntu ランナーを選べる状態を作るには Linux でも動くインストール手順が前提になる。

インストール前に .NET のバージョンを確認する。pac CLI 2.x は .NET 10 必須（pac CLI 1.x は .NET 9）。本記事執筆時点の最新バージョンは 2.9.3（NuGet Gallery・バージョンは随時更新されるため確認してから使う）。

# .NET バージョン確認
dotnet --version

# バージョン固定インストール
dotnet tool install --global Microsoft.PowerApps.CLI.Tool --version 2.9.3

CI ではインストールを省く選択肢がある

CI 環境でグローバルインストールを避けたい場合、.NET 10 以降なら dnx が使える。NuGet キャッシュから自動ダウンロードし、PATH を変更せず使い捨て実行する（Microsoft Learn「dnx CLI」）。

# dnx 経由（インストール不要・.NET 10 以降）
dnx Microsoft.PowerApps.CLI.Tool --yes -- <pac コマンド>

# dotnet tool exec（.NET 10 組み込みコマンド）
dotnet tool exec Microsoft.PowerApps.CLI.Tool --yes -- auth list

GitHub Actions の ubuntu-latest ランナーで .NET 10 が利用可能かを確認してから採用する。.NET バージョンが合わない場合は actions/setup-dotnet で明示指定する。

CI 認証で先に詰めるべきこと

サービスプリンシパルを Power Platform 環境に追加する

省略すると後続操作がすべて失敗する箇所で、手順を省略すると「pac auth create は成功するが後続の pac 操作がすべて失敗する」という状態になる。認証コマンドのエラーではないため原因が見えにくい。

事前に必要な作業を順番で：

  1. Azure AD / Entra ID でアプリケーション登録を作成する
  2. サービスプリンシパル（SP）を対象の Power Platform 環境に追加する（このステップ省略 → auth 成功後に pac 操作が全て失敗）
  3. クライアントシークレットを GitHub Actions Secrets または Azure Pipelines Variable Groups に格納する

認証コマンドと禁止操作

事前手順が揃ったら認証を設定する（Microsoft Learn 公式リファレンス）：

pac auth create \
  --name "CI-SPN" \
  --applicationId  00000000-0000-0000-0000-000000000000 \
  --clientSecret   $CLIENT_SECRET \
  --tenant         00000000-0000-0000-0000-000000000000 \
  --environment    https://<org>.crm.dynamics.com

避けるべき操作：

  • $CLIENT_SECRET を YAML ファイル・コード内に平文で書く → 絶対禁止
  • 有効期限切れのクライアントシークレットをそのまま使い続ける
  • 複数の認証プロファイルが登録された状態で pac auth select を忘れて実行する（意図しない環境への操作事故になる）

pac auth list で接続先を確認する

CI ジョブの前後に pac auth list を実行し、接続先が想定通りかを確認する習慣をつける。複数環境を扱う構成では特に重要になる。

pac auth list

Ubuntu ランナーを選ぶコスト根拠

GitHub Actions のランナーには OS ごとに分数乗数がある（GitHub Docs）。

ランナー OS分数乗数単価（2026年1月以降）
Linux（Ubuntu 2-core）1x（基準）$0.006/分
Windows（2-core）2x$0.010/分
macOS（3-core）10x$0.080/分

2026年1月に全ランナーで最大39%値下げされたが、乗数構造は変わっていない（GitHub Changelog 2026-01-01）。月間 CI 1,000分（無料枠2,000分/月を超えた分）で計算すると：

ランナー実消費分数コスト
Ubuntu1,000分$6.00
Windows2,000分換算$10.00
差額—$4.00/月

無料枠2,000分/月に収まる個人開発であれば、金銭的な差は出ない。 Ubuntu を選ぶ理由は金額より先に「dotnet tool のクロスプラットフォーム採用がそのままランナー OS の選択肢を開いている」という構造にある。Windows にしか動かないインストール手順を踏んでいると、ランナー変更の選択肢が後から消える。

CI に持ち込む前に手元で動作確認する

CI ワークフローを本番で初めて実行するのは避けたい。M365 Developer Tenant に検証環境を用意してあれば、pac auth create → pac solution export の一連を個人 PC 側で確認してから CI に持ち込める。コマンドの挙動を事前に把握していれば、CI 上でのデバッグにかかる時間が減る。

→ 関連記事：個人 PC 開発戦略の全体設計

まとめ

dotnet tool を選んでおくと、ローカル（Windows / macOS）と CI（Ubuntu）で同じインストール手順が使い回せる。Ubuntu ランナーは分数消費が乗数1倍の基準であり、dotnet tool のクロスプラットフォーム採用がその選択肢を開く。方式選択とランナー OS は後から変えにくい決定なので、最初に根拠を持って選ぶと後工程の選択肢が広がる。

次の一歩：

  1. dotnet --version で .NET 10 が入っているか確認する（NuGet Gallery で最新バージョンを確認）
  2. GitHub Actions ワークフローで runs-on: ubuntu-latest を指定する
  3. SP を Power Platform 環境に追加してから pac auth create を実行する（SP 追加前の実行は事故のもと）

関連記事： ai-agent-config-as-code — Git でエージェント定義を管理する