Azure Communication Services のサービス制限
このドキュメントでは、Azure Communication Services API の制限事項と考えられる解決策について説明します。
調整パターンとアーキテクチャ
サービスが制限に達した場合は、ユーザーに HTTP 状態コード 429 (要求が多すぎます) が返されます。 調整を処理するための一般的なベスト プラクティスを次に示します。
- 要求あたりの操作の数を減らす。
- 呼び出しの頻度を減らします。
- すべての要求が使用制限に加算されるため、すぐに再試行することは避けてください。
調整と制限を処理するようにサービス アーキテクチャを設定する方法に関するより一般的なガイダンスについては、調整パターンに関する Azure Architecture のドキュメントを参照してください。 調整制限を引き上げるには、Azure サポートに要求する必要があります。
- Azure portal を開き、サインインします。
- [ヘルプとサポート] を選択します。
- [新しいサポート リクエスト] をクリックします。
- [問題の説明] テキスト ボックスに「
Technical」と入力し、[検索] をクリックします。 - [サービスの選択] ドロップダウン メニューから、[サービスとサブスクリプションの制限 (クォータ)] を選択し、[次へ] をクリックします。
- [問題の説明] で、[問題の種類]、[サブスクリプション]、[クォータの種類] を選択し、[次へ] をクリックします。
- [推奨される解決策] が表示された場合はその内容を確認し、[次へ] をクリックします。
- 必要に応じて [追加の詳細] を入力し、[次へ] をクリックします。
- [確認と作成] で、入力内容を確認し、必要があれば修正した後、[作成] をクリックします。
「Azure サポートへのリクエストを作成する」のドキュメントに従うことができます。
電話番号の取得
電話番号を取得する前に、サブスクリプションが地理的およびサブスクリプションの要件を満たしていることを確認してください。 そうでない場合、電話番号を購入することはできません。 電話番号 SDK と Azure portal を使用した番号の購入には、以下の制限事項が適用されます。
| 操作 | Scope | 時間枠 | 制限 (要求の数) |
|---|---|---|---|
| 電話番号を購入する | Azure テナント | - | 1 |
| 電話番号の検索 | Azure テナント | 1 週間 | 5 |
実行するアクション
詳細については、電話番号の種類の概念およびテレフォニーの概念の概要に関するページを参照してください。
番号購入の制限は、Azure サポートへのリクエストを通して引き上げることができます。
- Azure portal を開き、サインインします。
- [ヘルプとサポート] を選択します。
- [新しいサポート リクエスト] をクリックします。
- [問題の説明] テキスト ボックスに「
Technical」と入力し、[検索] をクリックします。 - [サービスの選択] ドロップダウン メニューから、[サービスとサブスクリプションの制限 (クォータ)] を選択し、[次へ] をクリックします。
- [問題の説明] で、[問題の種類]、[サブスクリプション]、[クォータの種類] を選択し、[次へ] をクリックします。
- [推奨される解決策] が表示された場合はその内容を確認し、[次へ] をクリックします。
- 必要に応じて [追加の詳細] を入力し、[次へ] をクリックします。
- [確認と作成] で、入力内容を確認し、必要があれば修正した後、[作成] をクリックします。
ID
| 操作 | 期間 (秒) | 制限 (要求の数) |
|---|---|---|
| ID の作成 | 30 | 1000 |
| ID の削除 | 30 | 500 |
| アクセス トークンの発行 | 30 | 1000 |
| アクセス トークンの取り消し | 30 | 500 |
| createUserAndToken | 30 | 1000 |
| exchangeTokens | 30 | 500 |
実行するアクション
チャット スレッドを作成する前または通話を開始する前に、ID とトークンを取得することをお勧めします。 たとえば、Web ページの読み込み時やアプリケーションの起動時などです。
詳細については、ID の概念の概要に関するページを参照してください。
SMS
大量のメッセージを送信または受信するときに、429 エラーが発生することがあり ます。 このエラーは、サービスが制限に達していることを示します。メッセージは送信待ちのキューに入り、要求の数がしきい値を下回ったときに送信されます。
SMS の転送率の制限:
| 操作 | 数値の種類 | Scope | 期間 (秒) | 制限 (要求数) | 1 分あたりのメッセージ単位 |
|---|---|---|---|---|---|
| メッセージを送信する | フリーダイヤル | 数ごと | 60 | 200 | 200 |
| メッセージを送信する | 短いコード | 数ごと | 60 | 6000 | 6000 |
| メッセージを送信する | 英数字送信者 ID | リソースあたり | 60 | 600 | 600 |
実行するアクション
レート制限を超える要件がある場合は、より高いスループットを実現するための要求を Azure サポートに送信します。
SMS SDK とサービスの詳細については、SMS SDK の概要に関するページまたは SMS の FAQ に関するページを参照してください。
メール
送信できる電子メール メッセージの数には制限があります。 サブスクリプションに応じた以下の制限を超えた場合、要求が拒否されます。 再試行までの時間が経過した後に、これらの要求をもう一度試すことができるようになります。 必要に応じて、送信ボリュームの制限を引き上げるリクエストを行って、制限に達する前に対処してください。
Azure Communication Services のメール サービスは、高スループットをサポートするように設計されています。 ただし、このサービスには、お客様がオンボードを円滑に行い、新しいメール サービスに切り替えるときに発生する可能性のあるいくつかの問題を回避できるように、初期レート制限が設けられています。 メールの配信状態を注意深く監視しながら、2 週間から 4 週間かけて、Azure Communication Services Email を使用するメールの量を少しずつ増やすことをお勧めします。 このように段階的に増やすと、サード パーティのメール サービス プロバイダーはドメインのメール トラフィック用の IP の変更に適応できます。 少しずつ変更すると、送信者評価を保護し、メール配信の信頼性を維持する時間が得られます。
メールのレート制限
ユース ケースの要件、ドメインの評判、トラフィック パターン、障害率に基づいて、お客様の制限の引き上げを承認します。 制限の引き上げの要求は、「メール ドメインのクォータの引き上げ」の手順に従って行ってください。 クォータの引き上げは、検証済みのカスタム ドメインでのみ利用でき、Azure が管理するドメインではできません。
| 操作 | Scope | 時間枠 (分) | 制限 (電子メールの数) |
|---|---|---|---|
| 電子メールの送信 | サブスクリプションあたり | 1 | 30 |
| 電子メールの送信 | サブスクリプションあたり | 60 | 100 |
| 電子メールの状態の取得 | サブスクリプションあたり | 1 | 60 |
| 電子メールの状態の取得 | サブスクリプションあたり | 60 | 200 |
| 操作 | Scope | 時間枠 (分) | 制限 (電子メールの数) |
|---|---|---|---|
| 電子メールの送信 | サブスクリプションあたり | 1 | 5 |
| 電子メールの送信 | サブスクリプションあたり | 60 | 10 |
| 電子メールの状態の取得 | サブスクリプションあたり | 1 | 10 |
| 電子メールの状態の取得 | サブスクリプションあたり | 60 | 20 |
メールのサイズ制限
| 名前 | 制限 |
|---|---|
| 電子メールの受信者の数 | 50 |
| 電子メール要求の合計サイズ (添付ファイルを含む) | 10 MB |
| サブスクリプションあたりの認証済み接続の最大数 | 250 |
すべてのメッセージ サイズの制限に関して、base64 エンコードによってメッセージのサイズが大きくなることを考慮する必要があります。 メッセージの添付ファイルとその他のバイナリ データが Base64 エンコードされた後に発生するメッセージ サイズの増加を考慮して、サイズ値を大きくする必要があります。 Base64 エンコードはメッセージのサイズを約 33% 増加させるため、メッセージ サイズはエンコード前のメッセージ サイズより約 33% 大きくなります。 たとえば、最大メッセージ サイズの値を 10 MB に指定した場合、実際の最大メッセージ サイズの値は約 7.5 MB になることが予想されます。
10 MB を超える添付ファイルを送信する
最大 30 MB の添付ファイルを電子メールで送信するには、サポート リクエストを完了してください。
30 MB を超える添付ファイルを電子メールで送信する必要がある場合は、この代替ソリューションを使用できます。 ファイルを Azure Blob Storage アカウントに格納し、メールにファイルへのリンクを含めます。 Shared Access Signature (SAS) を使用してファイルをセキュリティで保護できます。 SAS を使うと、ストレージ アカウント内のリソースに対してセキュリティ保護された委任アクセスが可能になります。 SAS を使用すると、クライアントがデータにアクセスする方法をきめ細かく制御できます。
Azure Blob Storage アカウントを使用する利点:
- 大規模なファイルを処理できます。
- SAS キーを使用して、ファイル アクセスを正確に管理できます。
詳細については、以下を参照してください:
実行するアクション
メール クォータを増やすには、メール ドメインのクォータの引き上げに関する記事の手順に従ってください。
Note
メール クォータの引き上げ要求の評価と承認には最大で 72 時間かかる可能性があります (金曜日の午後に行われる要求は特に時間がかかります)。
チャット
チャットのサイズ制限
| 名前 | 制限 |
|---|---|
| 通話あたりの参加者数 | 250 |
| 参加者のバッチ - CreateThread | 200 |
| 参加者のバッチ - AddParticipant | 200 |
| ページ サイズ - ListMessages | 200 |
| メッセージ サイズ | 28 KB |
| Azure Bot あたりの Azure Communication Services リソースの数 | 1000 |
チャットのレート制限
| 操作 | スコープ | 10 秒あたりの制限 | 1 分あたりの制限 |
|---|---|---|---|
| チャット スレッドを作成する | ユーザーごと | 10 | - |
| チャット スレッドの削除 | ユーザーごと | 10 | - |
| チャット スレッドの更新 | チャット スレッドごと | 5 | - |
| 参加者の追加/参加者の削除 | チャット スレッドごと | 10 | 30 |
| チャット スレッドの取得/チャット スレッドの一覧表示 | ユーザーごと | 50 | - |
| チャット メッセージを取得する | チャット スレッドあたりのユーザーごと | 50 | - |
| チャット メッセージを取得する | チャット スレッドごと | 250 | - |
| チャット メッセージを一覧表示する | チャット スレッドあたりのユーザーごと | 50 | 200 |
| チャット メッセージを一覧表示する | チャット スレッドごと | 250 | 400 |
| 開封確認メッセージを取得する (20 人の参加者の制限**) | チャット スレッドあたりのユーザーごと | 5 | - |
| 開封確認メッセージを取得する (20 人の参加者の制限**) | チャット スレッドごと | 100 | - |
| チャット スレッドの参加者を一覧表示する | チャット スレッドあたりのユーザーごと | 10 | - |
| チャット スレッドの参加者を一覧表示する | チャット スレッドごと | 250 | - |
| メッセージの送信/メッセージの更新/メッセージの削除 | チャット スレッドごと | 10 | 30 |
| 開封確認メッセージを送信する | チャット スレッドあたりのユーザーごと | 10 | 30 |
| 入力インジケーターの送信 | チャット スレッドあたりのユーザーごと | 5 | 15 |
| 入力インジケーターの送信 | チャット スレッドごと | 10 | 30 |
Note
* 20 名を超える参加者がいるチャット スレッドの場合は、開封確認メッセージと入力インジケーターの機能はサポートされません。
チャットの保存
Azure Communication Services では、チャット スレッドの作成時に設定したアイテム保持ポリシーに従ってチャット メッセージが保存されます。
重要
この記事で説明されている機能は、現在パブリック プレビュー段階にあります。 このプレビュー バージョンはサービス レベル アグリーメントなしで提供されており、運用環境のワークロードに使用することは推奨されません。 特定の機能はサポート対象ではなく、機能が制限されることがあります。 詳しくは、Microsoft Azure プレビューの追加使用条件に関するページをご覧ください。
チャット スレッド作成 API の保持ポリシーを使用して、無期限メッセージ保持と自動削除 (30 日から 90 日) のどちらかを選択できます。 また、チャット スレッドに対してアイテム保持ポリシーを未設定にしておくこともできます。
厳格なコンプライアンス要件に従う必要がある場合は、チャット スレッド削除 API を使用してチャット スレッドを削除することをお勧めします。 新しいアイテム保持ポリシーの適用以前に作成されたスレッドは、そのスレッドに適用するポリシーを変更しない限り影響を受けません。
Note
誤ってメッセージを削除した場合、システムがそのメッセージを復元することはできません。 また、アイテム保持ポリシーによってスレッドが削除された後は、削除済みのチャット スレッドについてサポート リクエストを送信してもスレッドを取得することはできず、スレッドの情報も一切得られません。 必要な場合、スレッドの作成時点から 30 日以内に、できるだけ早くサポート チケットを開けば対応できることがあります。
音声およびビデオによる通話
PSTN 通話の制限事項
| 名前 | スコープ | なし |
|---|---|---|
| 同時発信*呼び出しの既定数 | 番号あたり | 2 |
Note
* 同時着信呼び出しには制限なし。 また、送信同時呼び出しの制限を引き上げる要求を Azure サポートに送信することもできます。この要求は、審査チームによってレビューされます。
呼び出しの最大制限
| 名前 | 制限 |
|---|---|
| 参加者数 | 350 |
Calling SDK ストリーミング サポート
Communication Services Calling SDK では、次のストリーミング構成がサポートされています。
| 制限 | Web | Windows/Android/iOS |
|---|---|---|
| 同時に送信できる発信ローカル ストリームの最大数 | 1 つのビデオまたは 1 つの画面共有 | 1 つのビデオ + 1 つの画面共有 |
| 同時にレンダリングできる着信リモート ストリームの最大数 | 9 つのビデオ + 1 つの画面共有 | 9 つのビデオ + 1 つの画面共有 |
Calling SDK ではこれらの制限は適用されませんが、これらの制限を超えるとパフォーマンスが低下する可能性があります。
Calling SDK のタイムアウト
Communication Services Calling SDK では、次のタイムアウトが適用されます。
| アクション | タイムアウト (秒) |
|---|---|
| 参加者の再接続/削除 | 120 |
| 通話に対する新しいモダリティの追加または削除 (ビデオまたはスクリーン共有の開始/停止) | 40 |
| 通話転送操作に関わるタイムアウト | 60 |
| 1:1 通話確立に関わるタイムアウト | 85 |
| グループ通話確立に関わるタイムアウト | 85 |
| PSTN 通話確立に関わるタイムアウト | 115 |
| 1:1 通話のグループ通話への昇格に関わるタイムアウト | 115 |
実行するアクション
音声およびビデオの Calling SDK とサービスの詳細については、Calling SDK の概要ページまたは既知の問題に関するページを参照してください。 一部の制限を引き上げる要求を Azure サポートに提出することもできます。この要求は審査チームにるレビュー待ちとなります。
Job Router
大量の要求の送信または受信時には、ThrottleLimitExceededException エラーが発生する場合があります。 このエラーはサービスの制限に達していることを示し、要求を処理するバケットのトークンが一定時間後に補充されるまで、要求は失敗します。
Job Router のレート制限:
| 操作 | Scope | 期間 (秒) | 制限 (要求の数) | タイムアウト (秒) |
|---|---|---|---|---|
| 一般的な要求 | リソースあたり | 10 | 1000 | 10 |
実行するアクション
レート制限を超える量のメッセージを送信する必要がある場合は、acs-ccap@microsoft.com へメールでお問い合わせください。
Teams の相互運用性と Microsoft Graph
Teams 相互運用性シナリオを使用している場合は、おそらく、いくつかの Microsoft Graph API を使用して会議を作成することになります。
Microsoft Graph によって提供される各サービスにはさまざまな制限があります。ここでは、サービス固有の制限について詳しく説明します。
実行するアクション
エラー処理を実装するときに、HTTP エラー コード 429 を使用して調整を検出します。 失敗した応答には、Retry-After 応答ヘッダーが含まれます。 クライアントが調整されている間も Microsoft Graph がリソースの使用状況を継続的にログに記録するため、Retry-After 遅延を使用して要求をオフにする方法が、調整から回復する最も簡単な方法です。
Microsoft Graph の調整の制限の詳細については、Microsoft Graph のドキュメントを参照してください。
次のステップ
ヘルプとサポートのオプションを参照してください。