Microsoft Power Platformの課金体系「従量課金制プラン」とは？

 

突然ですが、皆さんはローコード・ノーコードツールはご存知でしょうか？その名の通り、プログラミングを用いない、もしくは少ないプログラムで開発することができる開発手法です。

Microsoftでは、それらのサービスをまとめてMicrosoft Power Platformとして展開しており、事例化も近年増えている状況です！

ローコード・ノーコードツールのメリットとは何なのか。

アプリの開発サイクル向上だけでなく、アプリ内製化への期待、そして専門的な知識を持たない非エンジニアでも利用できることから、業務知識を持った現場の方がアプリを開発できることによる生産性向上がメリットとしてよく挙げられます。

専門部署以外の人(市民開発者)も開発することができることから、もしローコード/ノーコードツールを利用する場合に出てくるものとして、どの部署が利用分を課金するのかが話題にあがることがあります。

そういった悩みを解決する手段として、Microsoft Power Platformでは「従量課金制プラン」が用意されているため、その制度を今回ご紹介したいと思います！！

Microsoft Power Platformとは？

本題に入るために、軽くMicrosoft Power Platformについてご紹介します。

Microsoft Platformとは、Microsoft社が開発したローコードツールサービスである

  • PowerApps
  • PowerAutomate
  • Power BI
  • Power Virtual Agent
  • Power Pages

の5つのツールによって構成されています。

Excel・Word・Powerpointのような操作性と式を活用して、いわばパッチワークのようにアプリ開発、データビジュアライゼーションが可能です。

従量課金制プランとは？

さて、Microsoft Power Platformを導入した後、案外困る課題として出てくるのが課金の仕組みです。専門(情報企画系)以外の部署がアプリを開発・運用することになるため、データベース等の容量は開発元の部署がどれほど使っているかで増減します。

そこで容量不足が起きた時、誰が、どれほど負担するかで揉める可能性があります。そこで、従量課金制プランが非常に有効な手段になりえます。

従量制課金制プランとは、Azure サブスクリプションを使用した Power Apps と Power Automateの課金の仕組みで、ライセンス契約や事前購入なしでアプリを構築して共有することができます。

もっとわかりやすく説明するならば、ライセンス/ユーザ単位で支払うのではなく、使った分だけ支払う仕組みになります。

また、従量課金制プランには Microsoft Dataverse ストレージ容量(データベース)が含まれており、必要に応じて追加ストレージ分を支払うという柔軟性を備えています。(※蛇足にはなりますが、ライセンス購入にかかる人件費を含めた費用を削減することも可能です。)

請求ポリシー

組織間での費用を分ける仕組みとして、利用されるのが請求ポリシーです。

請求ポリシーは、Azureサブスクリプションと1つ以上のPower Platformの環境とリンクすることができます。作成はPower Platform管理センターで行いますが、作成が行われると請求ポリシーに関連付けられたAzureサブスクリプションに、ポリシーに対応するAzureリソースが作成されます。

そして、Power Apps、Power Automate、 Dataverse、Microsoft Power Platform 要求の使用料は、Azure サブスクリプションの請求書の Power Platform アカウント リソースに表示されるといった流れです。

注意点として、環境が一度にリンクできる請求ポリシーは 1 つだけです。 いつでも環境がリンクされているポリシーを変更したり、請求ポリシーを削除することができます。削除さえしてしまえば、サブスクリプションへの請求が止まり、元の環境に戻ります。

Azure サブスクリプションにリンクされた請求ポリシー

組織間でコストを分けることができる、といったイメージ掴んでいただくため、下記の図をご覧ください。

Azure サブスクリプションにリンクされた請求ポリシーの例

Marketing team billing policy(マーケティングチーム)とFinance team billing policy(財務チーム)を確認することができるかと思います。

各チーム配下にある環境が、それぞれのAzureサブスクリプションに紐づけることができているのが分かります。

Azureサブスクリプションへの請求になりますから、Power Platformアカウントを独自で管理することができる上に、Azureの機能であるリソースグループやAzureタグを併用することで、他のAzureリソースと同じように区別してコスト管理も可能になります。(Azure Cost Managementとアラート機能の活用も見込めます！）

課金の考え方※2024年3月時点の情報です。

ここでは、多くのお客様で利用しているであろう「PowerApps」と「PowerAutomate」にフォーカスして解説したいと思います。

PowerApps

課金として請求対象となるのが、従量課金制環境における、各アプリの月間アクティブ ユニーク ユーザーの総数になります。アクティブ ユーザーとは、指定された月に少なくとも 1 回アプリを開いたユーザーのことです。

1回アプリを開いてしまえば課金対象になりますが、反対に繰り返しアクセスしたとしても1回分しか請求はされません。また、既にPower Apps ユーザーごとのライセンスが付与されていれば課金対象外となります。

気になるお値段ですが….当月に何かしらのアプリにアクセスしたユーザ(=アクティブユーザ)が課金対象となり、1人当たり月額$10です。

繰り返しアクセスは課金対象とはなりませんので、図の一番右のような請求となります。

3 つのアプリで従量課金制が有効になっている例

PowerAutomate

PowerAutomateのフローは実行回数に基づいて使用料を支払うことになります。

実行できるフローとしては、クラウド、アテンド型のユーザーがいるデスクトップ、非アテンド型のユーザーがいないデスクトップ、またはホスト型コンピューター グループを使用した Microsoft ホスト型コンピューターのいずれかで実行することができます。

金額としては、

  • クラウドまたは有人で実行される Premium フローは、実行ごとに $0.60 の費用がかかります
  • Premium フローは、実行ごとに $3.00 の費用がかかります
  • ホスト型コンピューターとホスト型コンピューター グループを含む、ホスト型 RPA (プレビュー) で実行される Premium フローは、実行ごとに $3.00 かかります (プレビュー)

となっています。

では、PowerAppsに紐づているAutomateフローはどのような扱いになるのか。

  • Power Apps を使用して作成されたアプリから直接トリガーされたフローには、Power App を実行することにより、ユーザーのスタンドアロン Power Apps ライセンスまたは Power Apps PAYG メーターが、Power Automate の使用量をカバーするため、追加料金が発生しません。

PowerAppsトリガーによって動作するフローは、PowerAppsの課金額に含まれていると理解することができます。

PowerAutomateについても、既にライセンスをお持ち(ライセンス権内)であれば、フローを実行したとしても課金されることはありません。

Microsoft社としては、以下の通り使い分けることでコストを最適化できるとしています。あくまでも下記は一例でしかありませんので、しっかりと組織内での検証は必要です。

  • 従量課金制は、3ヵ月1回等の定時フロー、または実行数は少ないがユーザー数が多いフローに最適です
  • プリペイドは、個人の自動フローおよび実行回数の多いフローに最適です

まとめ

今回は部署ごとに分けて請求管理ができるMicrosoft Power Platformの従量課金制プランをご紹介しました。

筆者としては、率直にライセンス毎に付与する方が、結果的にコストは安く済みそうなイメージを持ちました。特に、PowerAutomateの課金体系は複雑で、現場での混乱が容易に想像できます。

しかし、ライセンス付与一辺倒で考える組織よりも、従量課金制との取捨選択できる組織の方が間違いなくコストを抑えられることができるとも考えます。

いかなるクラウドサービスを導入する際も同様ですが、導入は戦略ありきであり、コストを抑えることが目的になるのであれば、固定費(ラインセンス単位)で運用いただくのがベストでしょう。

参照URL：従量課金制プランの概要 – Power Platform | Microsoft Learn

この記事を書いた人

森 信之介
テクニカルマーケターとして、ブログ執筆、セミナー講師を行っております！