Power Platformをご利用の管理者の皆さん、API要求数に制限があることはご存じでしょうか。将来的にこの制限は段階的に強化される予定で、すべての組織がその影響を受ける可能性があります。
この記事では、要求数制限の内容についてご紹介します。
※本記事で案内している設定内容および変更方法は、作成日時点でのものであり、Microsoftの方針により変更される場合があります。
はじめに
Power Platform における「要求」とは
ユーザーがPower AppsやPower Automate、Dataverseなどの操作を通じて送信するバックエンドへのAPI呼び出しのことです。 各サービスにおける消費する主なタイミングは以下です。
- Power Apps
- コネクタ経由のデータ取得・更新要求等、すべてのAPI呼び出しがカウントされます。
- Power Automate（クラウドフロー）
- フロー内のすべてのアクション実行が要求としてカウントされます。
- 各種コネクタの操作、HTTP要求アクション、変数の設定など1つひとつのアクションが1要求であり、成功したか失敗したかに関係なくカウントされます。
- Power Virtual Agents (Microsoft Copilot Studio)
- チャットボットの対話から裏でPower Automateフローを呼び出すごとに1要求が発生します。
- Dataverse
- データベース上での作成・読み取り・更新・削除 (CRUD) 操作、およびレコードの共有や割り当てといった動作はすべて要求に含まれます。
- これらの操作は内部的に複数のAPIコールを伴う場合がありますが、ユーザーから見て一連の操作ならば1要求として処理されます。
今回はこの中から、Power Automateにおける要求数制限についてご説明します。
Power Automate要求数のカウント方法
要求数を消費するケース
- フロー内のすべてのトリガー/アクション
- 実行されたトリガーやアクションは、基本的に1回につき1要求を消費します。
- 1回のアクションで複数レコードを操作する場合
- 例）SharePoint で複数アイテムを取得・更新する「Get items」「Update items」などは、取得・操作したレコード数に応じて要求数が加算されます。
- アクション実行時のリトライ
- 一部のアクションは失敗時に自動リトライされますが、その都度要求数が追加で消費されます。
- 失敗したアクション
- 通信が発生した時点で要求数は消費されるため、結果が失敗でもカウント対象になります。
- ループ内のアクション
- Apply to eachなどのループで繰り返されるアクションは、繰り返し回数文の要求数を消費します。
- ページング処理
- データ取得時にページングが有効な場合、1ページごとに追加の要求数が発生します。
要求数を消費しないケース
- ローカル処理アクション
- 変数の設定、初期化、条件分岐（If、Switch） 、ループ（Apply to each、Do until）内のローカル処理、式（Expression）の評価は要求数を消費しません。
- スキップされたアクション
- 条件分岐で実行されなかったブランチのアクション、事前条件によりスキップされたアクション、無効化されたアクション（手動で無効にしたもの）は要求数を消費しません。
Power Automate / Power Platform 要求数制限 | Japan Dynamics CRM & Power Platform Support Blog
要求数の制限とは
Power Apps や Power Automate などが外部サービスやデータソースと通信する際の API リクエスト数に上限が設けられている仕組みです。
これは、Microsoft がクラウドリソースの公平な利用とサービスの安定性を確保するために導入しているもので、ユーザーのライセンス種別や使用状況に応じて制限値が異なります。
制限を超えると、フローの失敗や遅延、エラーが発生する可能性があるため、設計段階での最適化や、使用状況のモニタリングが重要です。特に大規模な業務自動化を行う場合は、制限の影響を受けにくい構成を意識する必要があります。
要求数超過時の動作
Power Platformでは定められている要求数の制限を超過すると「スロットリング制限」が適用されます。
この制限は、プラットフォームの安定性と公平なリソース配分を保つために設けられており、Power AppsやPower Automateなどの各サービスで発生するAPI要求が対象です。
要求数の上限を超えると、即座にエラーが発生するわけではありませんが、以下のような影響が出る可能性があります。
- 処理速度の低下
- フローの実行時間が大幅に延び、通常の2倍以上かかることもあります。
- 警告通知
- 管理者やユーザーに対して、パフォーマンス警告メールが送信されることがあります。
- 継続的な超過による停止
- 14日間連続して制限を超過すると、該当するクラウドフローが自動的にオフになる可能性があります。
このような事態を防ぐためには、フローの設計を見直して要求数の上限を引き上げることが推奨されます。
なお、制限はユーザーまたはフロー単位で評価されるため、「一人が使いすぎてテナント全体が止まる」ということはありません。この設計により、問題が局所で留まり、他のビジネスプロセスへの波及が抑えられています。
移行期間とは
移行期間とは、新しい要求数制限を本格施行する前に設けられた暫定措置の期間です。
Microsoftは2021年後半に要求数上限を大幅に引き上げましたが、その適用に際して各組織が自社の使用状況を把握し調整するための猶予期間を設けています。
移行期間中はPower Automate に限り要求数制限の厳密な強制を一時的に緩和し、ユーザーが既存のフローやアプリをすぐに停止せずに済むように配慮されています。
この緩和措置によって、想定外の停止や影響を最小限に抑えつつ、組織に利用状況の把握と将来の備えを促す狙いがあります。
※ ただし「上限が無い」わけではなく、通常時より高めではあるものの一定の制限ラインは存在します。
要求の制限と割り当て - Power Platform | Microsoft Learn
移行期間中と移行期間終了後の要求数制限
移行期間中は、基本的な考え方として、ユーザー単位の制限を緩和し、代わりに「フロー単位」での大きな上限を設ける方式になっています。
ライセンスごとの制限値
Power Platformでは、ユーザーに割り当てられたライセンス種別ごとに1日あたりの要求数上限が定められています。
以下は、主要なライセンス種別について、移行期間中と移行期間終了後の上限値の比較です。
| ライセンス種別 | 移行期間中の上限 (24時間) | 移行期間終了後の上限 (24時間) |
|---|---|---|
| Microsoft 365 / Office 365 / Power Automate 試用版 | 10,000件/日（フロー単位） | 6,000件/日（ユーザー単位） |
| Power Apps / Power Automate Premium | 200,000件/日（フロー単位） | 40,000件/日（ユーザー単位） |
| Power Automate Process | 500,000件/日（ライセンス単位） | 250,000件/日（ユーザー単位） |
「移行期間中の上限」は、各ユーザーではなく各クラウドフローやボットごとに適用されるパフォーマンスプロファイル値です。
たとえば、Power Automate有償ユーザーは本来1日40,000件までのところ、移行期間中は個々のクラウドフローごとに200,000件までリクエスト可能という意味になります。
つまり、あるユーザーが複数のフローを持っている場合、それぞれのフローが独立して20万件まで要求でき、結果としてユーザー合計では4万件を超えても直ちには制限超過とみなされません。
要求の制限と割り当て - Power Platform | Microsoft Learn
5分当たりのアクション制限数
移行期間中であっても移行期間終了後であっても、前述の1日あたり要求数上限とは別に、短時間内（直近5分間）での要求実行数にも全体共通の制限があります。
「5分間で100,000件」を超えるような急激なリクエストは、ライセンス種類に関係なく一律で制限されます。
この5分間の10万件という閾値は、ユーザーのライセンス種別に関係なく適用されるグローバルなレート制限で、たとえ1日あたりの余裕があっても、短期間に集中しすぎると抑制されるので注意が必要です。
移行期間中特有の制限
移行期間中には、上限値そのもの以外にも通常時と異なる特別ルールがいくつか存在します。
これらは移行期間ならではの挙動であり、終了後は変更される予定です。
- クラウドフロー単位での上限適用
- 移行期間中、要求数のカウントはユーザー単位ではなくクラウドフロー単位で行われます。
- ユーザーのフローごとに上限が割り当てられ、その範囲内であればユーザー合計が公式上限を超えても直ちにスロットル対象にはなりません。
- ただし全ユーザーの無制限利用を許すわけではなく、1ユーザーにつき1日あたり合計1,000,000アクションという別枠の超大容量制限も設けられています。
- 1人のユーザーが全フロー実行合計で100万アクションを超えない限り、即時停止はされない仕組みです。
- 手動トリガークラウドフロー当たりのアクション数
- 移行期間中、手動実行のクラウドフロー（ユーザーがボタンを押して実行するフロー）は実行者のユーザー上限を消費しません。
- 代わりに、すべての手動フローは一律で「中程度 (100,000件/日)」のパフォーマンスプロファイルとして取り扱われます。
- 手動フロー1つあたり100,000件/日までリクエスト可能で、それは誰の上限とも無関係に許容されます。
- 移行期間終了後は、手動フローも通常のフローと同様に実行者のユーザー上限にカウントされるようになります。
- 複数ライセンスのスタック無効
- ユーザーが複数のPower Platformライセンスを持つ場合、移行期間終了後であれば各ライセンスの権利が合算されます（例: 40k + 40k = 80k件/日）。
- ただし、移行期間中はライセンスのスタッキングがサポートされず、ライセンスを複数持っていてもより上位プランの上限のみが適用されます。
要求の制限と割り当て - Power Platform | Microsoft Learn
移行期間終了後に向けて今できる対策
Microsoftは公式に「移行期間終了後は、要求数上限が厳密に適用される」とアナウンスしています。そのため、今から将来を見据えた準備をすることが大切です。
以下3点については次回の「【Power Platform】要求数制限#2 Power Automateで消費を抑える設計と運用」の記事で紹介します。
- 要求数を減らす設計・運用
- 使用状況のモニタリング
- 必要なライセンス
まとめ
Power Platformの要求数制限は、今後の運用に大きく影響する重要な要素です。
現在は猶予期間中ですが、正式な制限適用に備えて、使用状況の把握や設計の見直し、ライセンス戦略の検討が求められます。
安定したサービス提供のためにも、早めの対応が推奨されます。 移行期間終了後も途切れることなくPower Platformを活用し続けるために、賢いガバナンスと計画的な対応を進めていきましょう。
※今回の内容についてご不明点がございましたら、<#LSB20250819>を添えてお問い合わせくださいますようお願いいたします。
※Live Support for Office 365をご契約いただいているお客様のみお問い合わせいただくことが可能ですのでご了承ください
PR：マイクロソフト製品専門のエンジニアがお客さまの要望に合わせて柔軟かつ幅広く支援するタイムチャージ制サポートサービスのご紹介
JBSサービス"Live Support"は、豊富な構築実績に基づき、各マイクロソフト製品専門のエンジニアがお客さまの要望に合わせて柔軟かつ幅広く支援するタイムチャージ制のサポートサービスです。
情報システム部のお客様向けに、Microsoft 365 の運用で直面する課題に対し、問い合わせ対応の形で技術的なご支援をしております。ただお問い合わせに一問一答形式で回答するだけでなく、Teams会議を通じての技術相談や活用に関するアドバイスなど、柔軟にご利用いただけます。
Live Supportについてご興味がございましたら、下記ページよりお問い合わせください。
