「承認したのに、いつの間にか本番にデプロイされていた」——Power Platform の委任デプロイ（Delegated Deployment）を初めて設定した担当者に、この疑問はよく生まれる。管理画面に承認ボタンがなく、どこで実行が走ったのか見えにくい。
結論から言う。承認者に本番環境への書き込み権限は要らない。承認者の役割は「実行してよい」という信号を送ることだけであり、実際の書き込みはサービスプリンシパル（機械 ID）が担う。この構造を把握すると、GUI の見え方と権限設計の両方が整合して見えてくる。
なお、2026 年 2 月より Managed Environments がパイプラインの対象環境に自動有効化されている（Microsoft Learn「Overview of pipelines in Power Platform」2026-01-12）。既存テナントで意図せず委任デプロイが必要になるケースが増えている。
承認は「実行の引き金」であって記録ではない
筆者の整理として提示する。Power Platform Pipelines の委任デプロイは、凍結された状態機械 として動作する。
maker がデプロイを要求すると、パイプラインのステージは「承認待ち（Pending）」で止まる。そこから先に進む唯一の手段が、UpdateApprovalStatus（status: 20 = 承認）の呼び出しだ。これが凍結を解除し、パイプラインを再始動させる制御信号になる。
承認を「台帳に承認印を押す記録行為」として捉えると、権限設計がずれる。委任デプロイで承認が果たすのは、凍結した状態を次のステップに進ませる制御信号としての役割だ。この捉え方が、以降の設計読み解きの出発点になる。
判断する人間と実行する機械 ID を別主体に割り当てる
Power Platform の公式ブログ（2023 年 10 月）は委任デプロイの設計をこう説明している。
“developers of any skill level can request deployments without needing elevated (or any) permissions in target environments.”
開発者（要求者）は本番環境への権限を持たなくていい。本番に書き込むのはサービスプリンシパルだ。
| 役割 | 主体 | 本番環境への書き込み権限 |
|---|---|---|
| デプロイを要求する | maker（開発者） | 不要 |
| 「可」の信号を送る | 承認者（人間） | 不要 |
| 本番に書き込む | サービスプリンシパル | 必要（System Administrator） |
承認者が Power Automate の承認タスク（メール / Teams 通知）をクリックすると、フローの内部でサービスプリンシパルの Dataverse 接続を通じて UpdateApprovalStatus が呼び出される。承認者は本番環境を開かずに承認を完了できる。
GUI に承認ボタンがない理由
Power Platform の管理画面（パイプライン UI）に承認ボタンがない理由を、Microsoft が直接説明した公式文言は確認できていない。ただし、次の技術制約から構造上の帰結として説明できる。
Microsoft Learn（2026 年 2 月）は次のように記している。
“The UpdateApprovalStatus action must use the service principal’s connection.”
サービスプリンシパルの接続（Client ID + 秘密キー）が必須ということは、人間がインタラクティブにクリックするアクション（= ユーザー ID での書き込み）では呼び出せない。書き込みを許された主体が機械 ID に限定されているため、人間のクリックを受け付けるボタンを画面に置けない——これが構造上の帰結だ。
承認操作は Power Automate（または同等の自動化基盤）を経由し、フローの中でサービスプリンシパルの接続を使って UpdateApprovalStatus を呼び出す、という配線が前提になる。
複雑な承認フローは仲介の自動化に閉じ込める
多段承認（部門長 → セキュリティレビュー → CTO）や条件分岐（本番 / テスト環境で承認者を変える）が必要な場合の設計方針はシンプルだ。
複雑な承認ロジックはすべて Power Automate に閉じ込め、実行エンジン（UpdateApprovalStatus）には最終結果の一信号だけを渡す。
UpdateApprovalStatus のインターフェースは意図的にシンプルに設計されている——status: 20（承認）または 30（却下）を受け取るだけだ。多段承認の合議結果・条件判定はすべて Power Automate 側で処理し、最終判断のみをサービスプリンシパル経由で渡す。この分離により、承認ロジックを変更してもデプロイ設定本体に影響しなくなる。
具体的な Power Automate フロー設計パターン（多段承認・複数承認者）については、Microsoft Learn「Extend pipelines in Power Platform」に委ねる。
設計時に残る 3 つの工程
「承認者に本番権限不要」という構造の明快さは、以下の工程を先に済ませることと引き換えに成立する。
1. サービスプリンシパルのロール付与
各 Target Environment（本番含む）に System Administrator のセキュリティロールを付与し、Host Environment に Deployment Pipeline Administrator を付与する。設定が不足している場合、エラーメッセージではなく「デプロイが進まない」という沈黙として現れる傾向がある。セットアップ後は検証環境で承認フローを 1 サイクル通して動作確認を取る。
2. 機械 ID の権限スコープ設計
System Administrator は広い権限だ。権限を絞る場合はカスタムセキュリティロールを検討するが、削りすぎると上記の沈黙に戻る。最小権限で動作することを確認してから本番に持ち込む。過剰な権限は監査ログ上のリスクとして記録される。
3. 完了通知の設計
デプロイ完了後、承認者や関係者への通知は自動では発生しない。「承認 → デプロイ完了 → 通知」のループは Power Automate に別途設計が必要だ。この設計を省くと、デプロイ完了後に「本当に配布された？」という確認の問い合わせが増える。完了通知の公式実装指針は現時点で Microsoft Learn に記載がないため、フロー設計は個別に判断する。
この配線の全体像は、M365 Developer Program の個人テナント（無料）で承認フローを 1 サイクル試すと、構造が手を動かしながら確認できる。
まとめ
承認者に本番権限が要らないのは、委任デプロイが「判断する人間」と「書き込む機械 ID」を別主体に割り当てた設計を採っているからだ。GUI 上の承認ボタン不在も、UpdateApprovalStatus の SP 接続必須も、同じ設計原則の表れとして読める。
→ 関連記事：[Power Platform 環境設計——誰が何を触れるかを先に決める]（access-that-outlives-the-app リンク予定）
次の一歩：Microsoft Learn: delegated-deployments-setup でサービスプリンシパルのセットアップ要件を確認し、開発環境で承認フローを 1 サイクル通す。承認タスクのクリック → UpdateApprovalStatus 呼び出し → ステージ進行の流れを手元で確認するだけで、構造が一気につながる。
関連記事
- [機械 ID が認証を担う：許す側と名乗る側の二面契約]（who-decides-authentication リンク予定）
- [Power Platform 環境設計——誰が何を触れるかを先に決める]（access-that-outlives-the-app リンク予定）
- [DB 接続パスワードを共有しない：機械 ID の最小権限設計]（db-identity-auth-no-shared-password リンク予定）