Power Platform 従量課金（PAYG）有効化で踏む2つの壁——`japan`≠`japaneast` のポリシー名前体系ズレと環境容量制約

PAYG（従量課金）の有効化は、Power Platform 管理センターでチェックボックスを入れるだけに見える。実際には Azure 側に専用リソースが自動作成される工程を伴い、ガバナンスの効いたテナントでは japan と japaneast という名前体系のズレでポリシーに弾かれる。加えて、Production または Sandbox 環境が存在しない場合や、テナントの Dataverse 容量が 1 GB に満たない場合は、有効化の手前で詰まる。壁の構造が分かれば、回避の判断軸は絞られる。

有効化の裏で何が起きているか

PAYG を有効化すると、Power Platform 側の操作に連動して Azure 側に Microsoft.PowerPlatform/accounts というリソースが自動作成される（Microsoft Learn – pay-as-you-go-set-up、2024）。

Power Platform 管理センター（プラットフォーム側）の操作が、Azure サブスクリプション（クラウド側）への書き込みを誘発する構造だ。この2段構造を意識しないと、エラーの原因が Power Platform にあるのか Azure にあるのかが判断できない。

詰まりやすい壁は、この境界で2種類出現する：

• 壁1：Azure Policy がリソース作成リクエストを拒否する（ポリシーの名前体系ズレ）
• 壁2：対応環境がない、または容量が足りない（環境種別・容量の制約）

壁1——japan と japaneast は別体系

Azure のリージョン名と Power Platform のジオ名（地理区分名）は、別の名前体系で管理されている。

（Microsoft Learn – Azure Regions List、2024）

CAF（Cloud Adoption Framework）のランディングゾーンなど、ガバナンス強化済みの環境では Azure Policy 組み込みポリシー「許可されている場所」（ポリシー ID：e56962a6-4747-49cd-b67b-bf8b01975c4c）でリージョンを制限していることが多い。このポリシーは listOfAllowedLocations パラメーターで ARM リージョン名を文字列マッチングして判定する。

Power Platform が Azure リソースを作成する際に渡すロケーション値は "japan"——地理区分名だ。ポリシーが "japaneast" しか許可していない場合、文字列が一致しないため RequestDisallowedByPolicy エラーが発生して処理が止まる。

japaneast を許可しているのに弾かれる理由は、「別体系」という一点にある。

ログで根本原因を確認する

RequestDisallowedByPolicy というエラーメッセージだけでは、どのポリシーがどの値を拒否したかは特定できない。Azure Portal の Activity Log（アクティビティ ログ）に、拒否されたリクエストの詳細が記録される。

確認の手順：

• リソースプロバイダー Microsoft.PowerPlatform のエラーエントリを検索する
• エラー詳細の policyDefinitionId / policyAssignmentId で該当するポリシー割り当てを特定する
• requestedLocation の実値を確認する（"japan" と表示されれば名前体系ズレが原因）

「ポリシーに弾かれている」という抽象的な情報を、「どの文字列が許可リストに存在しないか」という実値に落とす——これが診断の基本手順になる。

解決策 A vs B：許可リスト追加か Policy Exemption か

原因が特定できたら、回避の選択肢は2つある。

ガバナンス要件が厳しい環境では B の Policy Exemption を選択する方が整合が保てる。A を選択すると、他のリソースも "japan" 指定で作成できる状態になるため、影響範囲の精査が必要になる。

Exemption（適用除外）には2つのカテゴリがある：

• Waiver（免除）：非準拠を一時的に容認する場合
• Mitigated（緩和済み）：別の手段でポリシーの意図を満たしている場合

Power Platform 側では制御できないロケーション指定に起因する問題は、一般的に Waiver が適切だ。

必要権限：Microsoft.Authorization/policyExemptions/write + 対象ポリシー割り当てに対する exempt/Action（付与できる組み込みロール：Resource Policy Contributor、Security Admin）

CLI コマンド例（2024年時点）：

az policy exemption create \
  -n "payg-japan-exemption" \
  --policy-assignment "<ポリシー割り当ての ID>" \
  --exemption-category "Waiver" \
  --scope "<サブスクリプションまたはリソースグループの ID>"

（Microsoft Learn – Exemption Structure、公式 CLI リファレンス、2024）

expiresOn フィールドで有効期限を設定できる。期限切れ後もオブジェクトは残るため、変更管理の監査レコードとして機能する。

壁2——環境種別と容量制約

ポリシー問題を解消しても、PAYG 有効化の前提として適切な環境が必要だ。

PAYG が対応している環境は Production と Sandbox のみ（Microsoft Learn – pay-as-you-go-overview、2024）：

Developer または Trial 環境しか存在しないテナントでは、PAYG は有効化できない。「無料環境で試してから本番へ」という手順が、この制約で成立しない。

さらに、Production / Sandbox 環境を新規作成する場合、テナントレベルで 1 GB 以上の Dataverse データベース容量が事前に必要だ（Microsoft Learn – create-environment、2024）。無料テナントや試用版テナントはこの容量を持たないため、対象環境の作成自体ができず、PAYG 接続の手前で詰まる。

なお、PAYG リンクが完了すると 1 GB データベース + 1 GB ファイルストレージが追加料金なしで付与される。ただしこれは「PAYG を有効化した後に付与される」容量であり、「有効化するために手前で必要な容量」とは別物だ。

「配線成功」と「実課金到達」は別ステップ

Microsoft.PowerPlatform/accounts が Azure 上に作成されても、課金メーターがただちに動き出すわけではない。

PAYG の課金はアプリにアクセスした月間ユニーク利用者数に対して発生する構造だ（詳細：関連記事 – PAYG の課金単位を整理する）。環境が作成されても、誰もアプリを開かない状態では課金は発生しない——これは課金モデルの構造から論理的に導ける。

有効化完了後の確認順序：

1. Microsoft.PowerPlatform/accounts が Azure 上に存在するか
2. PAYG リンクが Power Platform 管理センター上で有効状態になっているか
3. 対象環境でアプリへのアクセス記録があるか

「有効化したのに課金が発生しない」「有効化したら課金が始まった」どちらの疑問も、3段階を分けて確認すれば原因が絞られる。

ガバナンス環境でポリシーの挙動や Exemption の設定を本番前に確認したい場合、個人テナントで一通りのフローを試しておくと段取りがよい。

→ 関連記事：Power Platform 低コード開発を個人 PC 環境で動かす全体戦略

まとめ

Power Platform PAYG 有効化の障害は、ポリシーの名前体系（japan と japaneast の二層構造）と環境種別・容量制約という2種類の境界で発生する——ログで実値を確認し、Policy Exemption でスコープを絞って除外するのが、ガバナンスを維持しながら前進する手順になる。

次の一歩：Azure Portal の Activity Log で Microsoft.PowerPlatform のエラーエントリを検索し、requestedLocation の実値を確認する。ポリシー ID e56962a6-4747-49cd-b67b-bf8b01975c4c が該当する割り当てであれば、許可リスト追加（解決策 A）と Policy Exemption（解決策 B）のどちらが自組織のガバナンス要件に合うかを判断できる。

関連記事：

• PAYG の課金単位——月間ユニーク利用者数の定義と計算
• Power Apps の従量課金コスト設計——誰に開かせるかが請求を決める

本記事の制度・単価情報は公開時点のもの。最新は各公式ページで確認を。