Power Apps の従量課金（PAYG）が数えているのは、回数でも存在でもない。月間にアプリを1回以上開いた、異なる利用者の人数だ。この定義を誤解したまま現場展開すると、見積もりが構造的に外れる。
環境前提：Azure サブスクリプション経由で PAYG を有効化した Power Apps 環境を対象とする（本記事公開時点の情報。単価・課金条件の最新は公式の Power Apps 料金ページを確認）。
「使った分」の正体
PAYG の per-app メーターが数えるのは、月間アクティブユーザー数 × アプリ数だ。
アクティブユーザー（active user）の定義は公式に明確に定まっている。
“An active user is someone who opens an app at least once in the given month.”
（Microsoft Learn / pay-as-you-go-meters より）
その月に1回以上アプリを開いた利用者を1カウントとして計上し、同一ユーザーの2回目以降のアクセスは数えない。この構造から、現場でくり返し見かける3種の誤解が生まれる。
3つの誤解を潰す
誤解1：ヘビーユーザーがいると高くなる
実際には、回数は課金に影響しない。
“Repeat access of an app by a user isn’t counted.”
“Pay-as-you-go billing only counts unique monthly active users of an app. Repeat access of the same app by a user in a single month results in only one charge for that user that month.”
（Microsoft Learn / pay-as-you-go-issues-faq より）
毎日使う社員が20人いても、月1日だけ使う社員が20人いても、その月に同じアプリを使った20人であれば課金は同額だ。「毎日は使わないから安い」という判断は、この定義上は成立しない。
誤解2：アプリを置くだけで課金される
実際には、誰も開かない月の課金はゼロになる。
公式は「アプリを開いた」ことをアクティブユーザーの条件としている。作り置きのアプリがあっても、その月に誰も開かなければカウントに入らない——これはアクティブユーザー定義から導かれる帰結だ（「$0」と直接明示した公式記述は確認できないが、定義上そのように動く）。
誤解3：利用者数さえ少なければ安い
実際には、アプリ本数も課金総額に直接かかわる。
“You’re charged for the number of apps that a unique user accesses in a month. If a user runs three different apps in a month, you’re charged for three active users.”
（Microsoft Learn / pay-as-you-go-issues-faq より）
1ユーザーが3アプリを使った場合、料金は1ユーザー分ではなく3アプリ分（$30）になる。「利用者数を絞ったから安心」という判断がアプリ数を見落とすのは、見積もり段階でよくある構造的なミスだ。
3誤解の対比
| 誤解 | 正しい理解 |
|---|---|
| 何回使っても高い（回数課金） | 月1回でも50回でも同額 |
| アプリを置くだけで課金される | 誰も開かない月は実質ゼロ |
| 1ユーザーが3アプリ使うと$10 | 3アプリ分で$30 |
重複排除と月次リセット
同一ユーザーが同じアプリに複数回アクセスしても1カウントとして処理され、月末にリセットされる。
認証済みユーザーは認証情報で識別される（公式は “unique monthly active users” とのみ記述しており、内部識別子の詳細は明示されていない）。匿名ユーザー（Power Pages / ポータル）はブラウザCookieで識別する。Cookieが削除されたり、異なるブラウザやデバイスでアクセスした場合は別ユーザーとしてカウントされるため（Microsoft Learn / pay-as-you-go-issues-faq より）、匿名アクセスが多い環境では実際のコストがぶれやすい点に注意が必要だ。
見積もりの立て方
課金構造が利用者数 × アプリ数に比例するため、見積もりは次の式に収束する。
月間コスト（目安）= 月間ユニーク利用者数（平均） × アプリ本数 × $10
現行単価は $10/アクティブユーザー/アプリ/月（Azure サブスクリプション経由・本記事公開時点）。
利用者数が月によって変動する場合は、平均値を基準に据え、最大月と最小月の差をリスク幅として把握しておく。ピーク月の数字を通常月にそのまま使うと年間コストの過大推計になりやすい。コスト試算と同時にアプリ本数の計画も確認しておくと、予算の裁量が把握しやすくなる。
設計レバーとしてのアプリ本数と利用者範囲
公式が推奨しているわけではなく、課金構造から導いた設計上の判断軸として提示する。
課金が「利用者数 × アプリ数」に比例する構造を理解すると、設計段階でコントロールできる変数が見えてくる。
- アプリ統合：機能が重複する複数アプリを1本に統合すると、アプリ数分の課金倍率が下がる
- 利用者範囲の定義：全社員ではなく実際に使う部門・役割に対象を限定することで、月間ユニーク利用者数の母数を管理できる
- 段階的ロールアウト：試験的に利用者数を絞って課金実績を確認してから拡張すると、予算管理しやすい
設計慣行として機能比較や要件整理に時間をかける前に、「誰が月に1回以上このアプリを開くか」を先に整理しておくことが、見積もり精度に直結する。
現行単価と per-app plan 廃止
比較対象として参照されることがあった旧 per-app plan（$5/ユーザー/アプリ/月のサブスクリプション型）は2026年初頭に廃止されている（出典：licensing.guide / power-apps-per-app-plan-end-of-sale）。現在の選択肢はPAYG（$10/アクティブユーザー/アプリ/月）か Power Apps Premium（$20/ユーザー/月・年払い、2,000席以上は$12）になる。コスト比較の際は廃止済みの単価を混ぜないよう注意が必要だ。
単価・課金条件は改訂が速いため、本記事の数字は公開時点のものとして参照し、最新情報は必ず公式のPower Apps 料金ページで確認してほしい。
課金から外れるユーザー
混在組織では、PAYG メーターのカウントから除外されるユーザーが存在する。公式の除外リスト（Microsoft Learn / pay-as-you-go-meters より）：
- Power Apps per-user ライセンス保有者：カウントされない
- Dynamics 365 ライセンスで Power Apps 利用権を持つユーザー：カウントされない
- Power Apps for Microsoft 365 プランのユーザー（標準コネクタ利用の範囲内）：カウントされない
別ライセンスを持つユーザーが混在する組織では、PAYG の実効対象者が想定より少なくなり、コストが下がる可能性がある。見積もり前にライセンス保有状況を確認しておくことで、計算の精度を一段上げられる。
まとめ
Power Apps PAYG のメーターは「その月にアプリを開いたユニーク人数 × アプリ本数」で動く。回数は無関係で、存在だけでは課金されない。ただし利用者数とアプリ本数は直接効く。この3点を押さえると、見積もりは「月間ユニーク利用者数 × アプリ本数 × $10」の計算に落ち着く。
次の一歩：展開対象アプリの想定ユニーク利用者数（全社員数ではなく、その月に実際に開く人の数）を書き出す。次に、対象ユーザーのうちすでに別ライセンスを持つ人を除外する。この2ステップで見積もりの精度が一段上がる。