Power Apps PAYG（従量課金：使った量に応じて後払いする課金モデル）のコストは、機能の利用量でも処理件数でもなく、**「アプリを開いたユーザー数」**で決まる。入力ゼロ・閲覧のみでも、その月に1回でも開けば1人ぶん課金が発生する。「使った分だけ払えばいい」という前提で導入を進めている場合、この定義を先に確認してほしい。
環境前提を整理しておく。本記事が対象とするのは、Power Platform 環境で PAYG を有効化し、per-user ライセンスを持たないユーザーへアプリを公開する設計判断だ。フロー実行課金（Premium Cloud Flow $0.60/実行）と Dataverse ストレージ課金（$48/GB/月）は別メーターであり、本記事のスコープ外として扱う。課金の全体像については、Power Apps PAYG の課金単位——月間ユニーク利用者数の定義と落とし穴 を参照してほしい。
「開く」が課金イベントである
Microsoft の公式定義は次のとおりだ。
“An active user is someone who opens an app at least once in the given month.”
“Repeat access of an app by a user isn’t counted.”
— Microsoft Learn: Pay-as-you-go meters（2026年時点）
月に何度開いても1カウントのみ。同じユーザーが30回アクセスしても、その月の課金は $10 のまま（本記事公開時点の単価。最新は公式ページで確認してほしい）。逆に言えば、1回でも開けばその月 $10 が確定する。
課金対象と対象外の基本整理は次の表のとおりだ。
| ユーザーの状態 | PAYG メーターの扱い |
|---|---|
| Power Apps per-user ライセンス保有者 | 対象外（カウントされない） |
| Dynamics 365 ライセンスで per-user アクセスを持つ者 | 対象外 |
| M365 ライセンスで標準コネクターのみ使用する者 | 対象外 |
| 上記以外でアプリを開いたユーザー | 対象（$10/アプリ/月） |
さらに、ユーザーがその月に3本の異なるアプリを開いた場合は、3 × $10 が計上される。「ユーザー数 × アプリ数」の掛け算で課金額が決まる構造だ。複数アプリを一括展開するタイミングは、この掛け算が最大値をとる瞬間でもある。
アクセス設計とは、誰がそのアプリを開ける状態にあるかを決める設計だ。
「全社周知・各自入力」がスパイクを生む仕組み
アプリ公開後によく現れるパターンがある。開発が完成したタイミングで全社にメール周知し、各自が業務開始前に一斉にアプリを開く——という立ち上げムーブだ。
このパターンは、使い始め月にコストが最大値へ一気に跳ね上がる構造を内包している。
繰り返しアクセスはカウントされないため、月初に全員が一斉に開けばその月の課金は対象ユーザー全員ぶんで固定される。たとえば、対象ユーザーが200名・公開アプリが3本の場合、使い始め月だけで 200 × 3 × $10 = $6,000 が確定する計算だ。
ただし、この「使い始めスパイク」は構造上、一過性になる。PAYG は月次ユニーク利用者数で課金をリセットするため、翌月からは「実際に使い続けているユーザー」だけがカウントされる（月次リセット構造からの論理的帰結。この挙動を直接示した公式記述はないが、月次ユニークカウントの定義から導かれる）。
怖いのはスパイクそのものではなく、スパイクが設計外で発生することだ。スパイクを予測した上で承認を得ているなら問題ない。設計に組み込まれていないまま請求書が届く状況が問題になる。
設計で制御できる3つの判断軸
設計の順番を変えると、コストの見通しが立つ。以下3つを展開前に確認しておく。
判断軸1：共有範囲を課金範囲として設計する
「共有範囲 = 課金範囲」として考えると、設計判断の精度が上がる。共有設定・ライセンス割当がアクセス権を決め、アクセス権が課金対象者の範囲を決める。
制御点は「開ける前」にある。アプリを有効化・共有する前に、初月コストの上限を計算しておく。
段階的公開はこの制御を使いやすい形にする。
| フェーズ | 対象 | 目的 |
|---|---|---|
| パイロット | 10〜20名の先行チーム | 業務フィット確認・不具合の早期発見 |
| 部署展開 | 関係部署単位 | 利用率と効果の計測 |
| 全社展開 | 全対象ユーザー | 承認済みコスト上限の範囲で実施 |
「全社に一斉公開」を否定するわけではない。展開速度を優先するビジネス判断がある場合は、初月コストを計算した上でその判断を選ぶ。予測外でスパイクが発生することを防ぐのがこの判断軸の目的だ。
判断軸2：初期データはアプリを通さず一括投入する
アプリ公開前の初期データ投入には、アプリを経由しない手段がある。Dataverse API や Dataflows を使い、アプリを介さずデータを直接インポートする方法だ。
per-app メーターの定義が「アプリを開いたユーザー数」であることから、アプリを介さない操作は per-app 課金に計上されないと解釈できる（公式ドキュメントに明示記述なし。論理的推論であり、適用前に要確認）。
注意が必要なのは、「開く人をゼロにする」が「コストゼロ」を意味しない点だ。Dataverse ストレージ（$48/GB/月）やフロー実行（Premium Cloud Flow $0.60/実行）は別メーターとして発生しうる。「アプリ課金を抑える」と「コスト全体を抑える」は分けて設計する。
判断軸3：アクセス頻度でライセンス形態を選択する
per-user ライセンス（$20/ユーザー/月）を保有するユーザーは PAYG メーターの対象外になる。月次コストの比較は次のようになる。
| 月のアプリ利用状況 | PAYG コスト | per-user コスト | 推奨 |
|---|---|---|---|
| 1アプリのみ | $10 | $20 | PAYG |
| 2アプリ | $20 | $20 | 同額（どちらでも可） |
| 3アプリ以上 | $30〜 | $20 | per-user |
| 毎日アクセス・業務基幹利用 | $10〜 | $20 | ケースバイケース（安定性・管理を重視するなら per-user） |
展開前にユーザー別のアクセス頻度を予測し、ライセンス形態を混在させる設計が有効なケースがある。全員を PAYG に統一しなくてよい。
この3つの判断軸を自分のテナント環境で試すなら、Microsoft 365 Developer Program の無料テナントが使いやすい。本番環境に影響を与えずに共有範囲・段階公開の挙動を確認できる。
→ 関連記事：Power Apps PAYG の課金単位——月間ユニーク利用者数の定義と落とし穴
まとめ
Power Apps PAYG のコストは「誰がそのアプリを開ける状態にあるか」で決まる。共有範囲が課金範囲であり、制御点は開ける前にある。
次の一歩
- 公開予定のアプリについて、共有対象ユーザー数 × アプリ数 × $10 で初月コストを計算する
- パイロットグループを定義し、段階公開のタイムラインを設計書に記載する
- 利用頻度が高いユーザーを事前に特定し、per-user ライセンス（$20/月）との比較試算を行う
関連記事
- Power Apps PAYG の課金単位——月間ユニーク利用者数の定義と落とし穴：課金の定義・計算例・フロー課金との関係