編集

Azure Communication Services のアーキテクチャ設計

Azure Communication Services
Microsoft Entra ID
Azure Functions

このガイドでは、Azure Communication Services のデータ フロー図を示します。 これらの図を使用して、あなたのクライアントとサービスがどのようにして Azure とやりとりをしてコミュニケーション体験を提供するかを理解します。

Communication Services はクラウドベースのサービスです。その REST API とクライアント ライブラリ SDK を利用することで、コミュニケーションをアプリケーションに組み込むことができます。 Communication Services では、音声およびビデオ通話、テキスト チャット、SMS、カスタム バイナリ データなど、複数のコミュニケーション形式がサポートされています。

Web アプリやモバイル アプリにコミュニケーション機能を追加したり、カスタム サービスとボットを統合したり、公衆交換電話網 (PSTN) にプログラムでアクセスしたりできます。 電話番号を直接 Azure Communication Services REST API や Azure portal から取得して、これらの番号を SMS や音声通話アプリケーションで使用できます。 Communication Services ダイレクト ルーティングを使用することで、セッション開始プロトコル (SIP) とセッション ボーダー コントローラーを介して、独自のテレフォニー プロバイダーを作り出すことができます。

次のコンポーネントがこれらのデータ フロー図で使用されています。

  • クライアント アプリケーション。 エンド ユーザーがコミュニケーションに使用する Web サイトまたはネイティブ アプリケーション。 Communication Services は、ブラウザーおよびネイティブ アプリ用の SDK クライアント ライブラリを提供します。 これらの SDK 上に構築されたオープン ソースの UI ライブラリには、プログラミング可能な Web (React)、iOS、および Android UI コンポーネントが用意されています。
  • ID 管理サービス。 ユーザーとサービスを Communication Services ID にマップするために構築するサービス。 このサービスは、ユーザーがデータ プレーンにアクセスする必要があるときにトークンも作成します。
  • コミュニケーション コントローラー サービス。 チャット スレッドと音声・ビデオ通話を制御するために構築するサービス。
  • コミュニケーション データ サービス。 チャットや SMS メッセージの送信、音声通話でのオーディオの再生など、コミュニケーション コンテンツと直接やり取りするために構築するサービス機能。

WebRTC のようなコミュニケーションに関する業界標準によって、コミュニケーションが制御およびシグナリング プレーンとデータ プレーンに分離されます。 Communication Services を使用することで、サービス内部の WebRTC の実装を理解することなく、コミュニケーション体験を構築することができます。 しかし、これらの概念は、アプリを設計する際に役立ちます。

システム 機能 プロトコル アクセス モデル
コントロール プレーン 誰が、いつ、どのようにコミュニケーションするかを管理します。 REST Microsoft Entra サービスの資格情報
データ プレーン 人間やアプリとのインターフェイスとなるコミュニケーション コンテンツ、音声、ビデオ、テキスト、データなどです UDP、 RTMP、WebSocket、REST ユーザー アクセス トークンと Microsoft Entra サービスの資格情報

一般的なデータ フローは、クライアント アプリケーションがサービス コントローラーから制御情報を要求してコミュニケーションを開始するときに発生します。

  • 今日は何の会議があるだろうか?
  • 友人のジョセフに電話するにはどの電話番号を使うのか?
  • 私のチームメイトの名前は何でしょう? 現在進行中のチャット スレッドは何でしょう?

あなたの制御サービスはこれらの要求を満たすために、クライアントに Communication Services トークンと、ユーザー、スレッド、電話番号、呼び出しのための識別子を提供します。 そして、クライアントはこれらのトークンと識別子を使用して Azure データ プレーンと対話します。 Communication Services API は、エンド ユーザー エクスペリエンスの設計やコミュニケーションを制御するプロセスを制限しません。

WebRTC 標準では、クライアントが “制御メッセージ“ を “シグナリング“ と呼ばれるプロセスで 送信することで、制御情報をサービスから要求します。 呼び出し ID のような Communication Services 識別子は、WebRTC セッションの説明に匹敵します。

ユーザー アクセス トークンで認証されたユーザー

Communication Services のクライアントはユーザー アクセス トークンを提示することで、Azure の通話およびチャット データ プレーンに、セキュリティを高めて、アクセスします。 ユーザー アクセス トークンの生成と管理は、信頼できるサービスを使用して行う必要があります。 トークンと接続文字列、またはそれらを生成するために必要な Microsoft Entra シークレットは保護する必要があります。 アクセス トークンを適切に管理しないと、リソースの不正使用によって追加料金が発生する可能性があります。

Diagram that shows the user access token architecture.

このアーキテクチャの Visio ファイルをダウンロードします。

データフロー

  1. ユーザーがクライアント アプリケーションを起動します。
  2. クライアント アプリケーションが、ID 管理サービスに接続します。 ID 管理サービスは、アプリケーション ID と Communication Services ID の間のマッピングを維持します。 (アプリケーション ID には、ユーザーと、サービスやボットなどのアドレス指定可能な他のオブジェクトが含まれます。)
  3. ID 管理サービスは、このマッピングを使用して該当する ID のユーザー アクセス トークンを発行します。

Azure App Service と Azure Functions の 2 つが、ID 管理サービスを運用するための選択肢になります。 これらのサービスはスケーリングが簡単で、ユーザーを 認証するための機能が組み込まれています。 これらは、OpenID や、Facebook のようなサードパーティ ID プロバイダーと統合されています。

リソース

ユーザーがアプリまたは電話番号を呼び出す

最もシンプルな音声およびビデオ通話のシナリオは、ユーザーがプッシュ通知なしでフォアグラウンドで他のユーザーに電話をかけるというものです。 Communication Services の音声およびビデオ通話を Web、ネイティブ モバイル、Windows デスクトップ アプリに統合することができます。 オープンソースの UI ライブラリを利用することで、開発を加速させることができます。

Diagram that shows Communication Services calling without push notifications.

このアーキテクチャの Visio ファイルをダウンロードします。

データフロー

  1. 開始側のユーザーは、通話したい相手の Communication Services ID を取得します。 一般的なシナリオでは、ユーザーは ID 管理サービスによって維持されている “友人リスト“ から ID を取得します。 リストには、ユーザーの友人と関連する Communication Services ID が照合されています。
  2. 開始側のユーザーは Call クライアントを起動して、リモート ユーザーを呼び出します。
  3. 受け入れ側のユーザーには、通話の着信が Calling SDK を介して通知されます。 着信呼び出しを受けるためには、アクセプターは Call クライアントを既に初期化している必要があります。
  4. ユーザー同士は、通話の音声と映像でコミュニケーションします。

データフローは、ユーザーが外部の電話番号に電話をかけるときとほぼ同じです。 主な違いは、従来のテレフォニーにアクセスするために、開始側のユーザー クライアントは、ユーザー ID を要求する代わりに、送信元と送信先の電話番号をコントローラー サービスに要求する必要があるということです。

状況によっては、Apple プッシュ通知のようなプラットフォーム サービスを使用して、アプリがバックグラウンドで通話を受け入れるようにするとよいでしょう。 この機能は、Communication Services と Azure Notification Hub を統合することで有効にできます。

リソース

ユーザーが招待なしでグループ通話に参加する

ユーザーが明示的に招待されていなくてもグループ通話に参加できるようにしたくなることもあるでしょう。 あなたのアプリが提供できる永続的な “ソーシャル スペース“ または “クラブ“ には、ユーザーが参加したいときに参加できるビデオ通話チャネルなどがあります。 このデータフローは、最初にクライアントによって作成され、リモート クライアントが明示的な招待がなくても参加できる通話を示します。

Diagram that shows a call without an invitation.

このアーキテクチャの Visio ファイルをダウンロードします。

データフロー

  1. 開始側のユーザーは Call クライアントを初期化してグループ電話をかけます。
  2. 開始側のユーザーは、グループ通話 ID をコミュニケーション コントローラー サービスと共有します。
  3. コミュニケーション コントローラー サービスは、通話 ID を他のユーザーと共有します。 たとえば、アプリケーションがユーザー クラブを提供する場合、グループ通話 ID は、Azure Cosmos DB に格納されているクラブのデータ モデルの属性です。
  4. 他のユーザーが、グループ通話 ID を使用して通話に参加します。
  5. ユーザー同士が、通話の音声と映像でコミュニケーションします。

Microsoft 365 と Teams

多くの組織が Microsoft 365 と Teams をコミュニケーションに使用しています。 Communication Services と Teams は相互運用可能であるため、 次のシナリオが可能になります。

  • 外部のユーザーが Teams 会議に参加できるようにするカスタム アプリケーションを構築する。 このシナリオは、Teams を使用している企業が、カスタム アプリとカスタム ID を使用している外部の消費者を対象とした会議を開催する、仮想訪問シナリオに最適です。 このシナリオの詳細については、 仮想訪問のチュートリアルとサンプル ビルダーをご覧ください。
  • Teams または Microsoft Entra の資格情報を持つ内部ユーザー用のカスタム アプリケーションを構築する。 このシナリオは、従業員用のカスタム Teams クライアントを構築するために設計されています。

これらのカスタム アプリケーションのシナリオでは、 Microsoft Graph API と Communication Services を使用します。 Teams に接続する外部アプリとサービスを構築するときは、一般には Microsoft Graph を “Teams のコントロール プレーン“ として使用します。 このコントロール プレーンを使用して、誰が、いつ、どのようにコミュニケーションするのかを、次の API を使用して構成します。

これらの制御 API から得られる情報 (会議 URL やスレッド識別子など) を使用して、Communication Services の通話クライアントやチャット クライアントを Teams データ プレーンに接続します。

また、Teams に用意されている SDK は、タブ、ボット、自動化のようなカスタム機能を Teams エクスペリエンス “内“ や Teams ストアを通じて追加するためのものです。 これらのシナリオは、この記事の範囲外です。

Communication Services は、Teams チャネルとのやりとりを直接サポートするものではありません。 カスタム アプリケーションの場合は、Microsoft Graph チャット と Channel API を使用して、チャネルにアクセスする従業員用のカスタム クライアントを構築できます。

アプリケーションがスケジュールされた Teams 通話に参加する

Communication Service アプリケーションが、Teams の通話に参加できます。 外部ユーザーの場合、アプリケーションには Teams 会議へのリンクが必要です。 リンクの取得は、Microsoft Graph API で管理されています。 データフローを次に示します:

Diagram showing Communication Services architecture for joining a Teams meeting.

このアーキテクチャの Visio ファイルをダウンロードします。

データフロー

  1. (1A) コミュニケーション コントローラー サービスは、Microsoft Graph API を使用してグループ通話をスケジュールします。 別のユース ケース (1B) では、ユーザーが Outlook または Teams を使用してグループ通話をスケジュールします。
  2. コミュニケーション コントローラー サービスは、Teams 通話の詳細を Communication Services クライアントと共有します。
  3. 通常、Teams ユーザーは Teams UI から通話に参加して、外部ユーザーが Teams 通話前ロビーを通れるようにしなければなりません。 ただし、この要件は、Teams テナントの構成と特定の会議設定によって異なります。
  4. Communication Service ユーザーは、手順 2 で受け取った詳細情報を使用して Call クライアントを初期化し、Teams の会議に参加します。
  5. ユーザー同士が、音声と映像でコミュニケーションします。

リソース

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

  • Chris Palmer | プリンシパル グループ プロダクト マネージャー

その他の共同作成者:

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ