手動のポータルデプロイが週末を奪っている理由

By Mirko Peters · 2026-08-11

金曜日の夕方、ノートPCを閉じて週末に入ろうとしたその時、慌てたメッセージがスマートフォンに届きます。Power Platform ポータルから本番環境へ重要な修正が反映されたところ、ワークフローの半分が動かなくなり、必要なプラグインの登録が欠落し、ユーザーデータベースで静かにエラーが発生している、という状況です。休むどころか、その後48時間は欠落した依存関係を手作業で探し、ZIP ファイルを本番環境にドラッグ＆ドロップし続けることになります。心当たりはありませんか？手動のポータルデプロイだけに頼っていると、デプロイのルーレットを回しているようなものです。

Automatically translated with AI from the original post. Read the English original

Titelbild: Why Manual Portal Deployments Are Costing You Weekends

本記事では、手動の UI によるデプロイをやめ、Power Platform CLI（PAC CLI）を使ったスクリプトベースのコードファーストのアプローチに移行すべき理由を詳しく解説します。これにより、週末を守り、確実なガバナンスを実現し、リリースサイクルの予測可能性を取り戻せます。本記事は、関連するポッドキャストエピソード Build Reusable Components with Power Platform CLI の内容を文章で補足するものです。このツールの活用方法を音声で詳しく知りたい方は、ぜひそちらもお聴きください。

要点まとめ（TL;DR）

ポータルは構築には最適ですが、繰り返し行うデプロイには向いていません。
PAC CLI を使うと、スクリプトによるパッケージ化、依存関係の検証、監査可能なデプロイが可能になります。
ポータルと並行して運用できます。安全な認証プロファイル、マネージドソリューション、自動化されたプラグイン、CI/CD を組み合わせられます。
得られる効果は、予測可能なリリース、ホットフィックスの削減、迅速な復旧、そして実効性のあるガバナンスです。

PAC CLI が重要な理由

エンタープライズのローコード／プロコードソリューションを扱う場合、一貫性がすべてです。手動のデプロイプロセスは、人為的ミス、設定漏れ、監査性の欠如が起きやすいものです。Power Platform コマンドラインインターフェイスを採用すると、チームの運用方法が大きく変わります。

一貫性: DEV から QA、PROD まで同じ手順をスクリプト化できます。「自分の環境では動いた」という問題をなくせます。
移植性: 参照関係を明示したマネージドソリューションにより、「コンポーネントが見つからない」という想定外の事態を未然に防げます。
追跡性: ログと明示的なバージョン管理により、デプロイパイプライン全体を監査に対応できる状態にできます。
安全性を保ったスピード: 手作業による手戻りを大幅に減らし、自動ロールバックと検証ゲートを導入できます。

安全な導入方法（動いている環境を壊さないために）

CLI ベースのワークフローに移行しても、現在の環境設定をすべて捨てる必要はありません。既存のメーカーの運用と並行して安全に実行できます。

PAC CLI をインストールします。サンドボックス VM や開発用コンテナーなど、分離された環境に入れるのが理想です。
テナントと環境ごとに認証プロファイルを作成し、誤って別のデータベースを操作しないようにします。 pac auth create --name "Contoso-DEV" --url https://orgdev.crm.dynamics.com pac auth create --name "Contoso-QA" --url https://orgqa.crm.dynamics.com pac auth select --name "Contoso-DEV" pac auth list
コマンドを実行する前に、ドライランチェックで接続先を確認します。 pac org who pac solution list 何かを変更する前に、必ず正しい環境にいることを確認してください。

ソリューションのパッケージ化ワークフロー（主要コマンド）

予測可能なリリースパイプラインは、ソリューションのビルド、パッケージ化、発行の方法を標準化することに支えられています。習得しておくべき主要コマンドは次のとおりです。

ソリューションリポジトリを初期化します。 pac solution init --publisher-name Contoso --publisher-prefix cts
アプリ、フロー、プラグイン、Web リソースの参照を追加します。 pac solution add-reference --path ./src/plugins/Contoso.Plugins.csproj pac solution add-reference --path ./src/canvasApps/TimeOffApp.msapp
出力ファイルをパッケージ化（ビルド）します。 pac solution pack --zipfile ./out/Contoso.TimeOff_1_2_0_managed.zip --processCanvasApps
メーカーによる変更を取り込む場合は、DEV からエクスポートします。 pac solution export --name Contoso_TimeOff --path ./out --managed true
QA/PRODへの安全なインポート: pac auth select --name "Contoso-QA" pac solution import --path ./out/Contoso.TimeOff_1_2_0_managed.zip --publish-changes true --activate-plugins true

実践のヒント: バージョン管理は厳密に行いましょう(例: 機能追加は1.2.0、ホットフィックスは1.2.1)。ビルドには git でクリーンにタグを付けてください。

プラグインの DevOps(手作業による登録は不要に)

週末のデプロイが失敗する最大の原因の一つが、あの厄介な手動のプラグイン登録ツールです。ステップの登録を忘れたり、古いアセンブリのバージョンを指定したりすると、本番環境がすぐに壊れてしまいます。

自動化されたパイプライン内で、CLI によるビルドと登録を行いましょう: pac plugin init # 初回のみ、雛形を作成 pac plugin push # 構成ファイルからプラグインアセンブリとステップを登録/更新
この方法には、すべての環境で実行ステップが一貫すること、分かりやすいエラーログが得られること、そして以前のビルドを再度 push するだけで簡単にロールバックできることなどの利点があります。

CI/CD の骨組み(Azure DevOps/GitHub Actions)

手作業によるデプロイから本当に脱却するには、自動化されたパイプラインが必要です。以下は Azure DevOps または GitHub Actions に使える標準的なステージ構成です。

ステージ

Build: 依存関係を復元し、プラグインをコンパイルして、pac solution pack を実行します。
Validate: pac solution check(Solution Checker)を実行し、単体テストを行い、コードのリントを実施します。
Deploy to QA: pac solution import を実行し、変更を発行して、自動スモークテストを実施します。
Gate: 手動承認と正常性チェックを適用します。
Deploy to PROD: まったく同じスクリプト化された手順を実行し、git でリリースにタグを付けます。

主要な変数

ENV_URL、CLIENT_ID、TENANT_ID、SECRET(または証明書)は、Key Vault または Actions のシークレットに安全に保存してください。
接続参照と環境変数は、インポート後に自動化スクリプトで設定するべきです。

環境変数と接続参照

ソリューション内に URL や接続情報をハードコーディングするのは、重大な問題を招く典型例です。代わりに次のようにしてください。

環境変数と接続参照はソリューションのペイロードの外に置き、デプロイパイプラインで環境ごとに設定します。
- 接続参照は、本番環境のコネクタに直接マッピングします。
- API の URL、サイト ID、チーム ID、機能フラグは、動的に設定します。
ソリューションのインポート直後に PowerShell または PAC のスクリプトで自動化し、実行時に気付きにくい障害を防ぎます。

よくある落とし穴と対処法

テナントや環境の取り違え → 必ず pac org who で確認し、名前付きの認証プロファイルを使用してください。
依存関係の欠落 → pac solution add-reference を使用してパックし、本番インポートの段階ではなくビルド段階で CLI を早期に失敗させてください。
本番環境での非マネージド → 上位環境ではマネージドソリューションのみを使用してください。アンインストールとロールバックは必ずテストしてください。
手動のプラグイン → 登録をスクリプト化し、ポータルへの単発のアップロードは行わないようにしてください。
ドリフト(DEV ≠ PROD) → すべてのパッケージのバージョンを厳密に管理し、上位環境ではポータル上だけでの変更を禁止してください。
YAML 内のシークレット → Key Vault または Action のシークレットを使用し、可能な場合はクライアントシークレットより証明書を優先してください。

品質ゲート(週末を救う迅速なチェック)

Solution Checker を、pac solution check を通じて CI パイプラインに直接組み込みます。
スモークテストをデプロイ後に実施します。主要なフローを自動的に実行し、テスト用のレコードを作成して、プラグインが正常に動作したかを確認します。
ロールバック計画: 直前の正常なマネージド zip ファイルを必ず手元に保管し、失敗時に再インポートを自動化しておいてください。

ガバナンスのチェックリスト

📦 マネージドソリューションは QA と PROD 環境のみで使用する
🔐 サービス接続には、Key Vault/シークレットと証明書認証を組み合わせる
🧭 環境ごとに名前付きの認証プロファイルを用意し、「default」での指定は行わない
🧩 接続参照と環境変数は、インポート後にスクリプトで設定する
🧪 Solution Checker とスモークテストを、すべてのデプロイで実行する
🗂️ 厳密なバージョン管理、リリースタグ、ソリューションごとの変更履歴を用意する
📜 コンプライアンスと監査のために、デプロイログを保管する

よくある質問

ポータルを使うのをやめる必要はありますか?
いいえ。ポータルはアプリの構築とプロトタイプ作成に引き続き使用し、パッケージ化、デプロイ、エンタープライズ向けのガバナンスには PAC CLI を使用してください。

メーカーは重いDevOpsなしでこれを使えますか?
はい、メーカーはまずシンプルなスクリプトによるエクスポートとインポートから始め、時間をかけて本格的なCI/CDパイプラインへと発展させていけます。

Dataverseプラグインはどうですか?
標準的なソフトウェアのコードと同じように扱ってください。ビルドし、バージョン管理を行い、コアとなるデプロイパイプラインの一部として PAC CLI で登録します。

手作業のポータル操作から離れ、PAC CLI を活用することで、リリースプロセスが堅牢になるだけでなく、ついに週末を取り戻せるようになります。これらのツールのセットアップやローコードアーキテクチャの最適化について詳しく知りたい方は、ぜひエピソード全編をお聴きください。Build Reusable Components with Power Platform CLIです!