Azure Communication Services

解決する課題

• 音声・ビデオ通話やチャットを自前で実装すると、メディアサーバーや WebRTC、シグナリングの構築が極めて重い
• SMS やメールの一斉送信を各キャリアやメール基盤と個別契約・個別連携するのが煩雑
• 顧客サポートや診療・商談などで、Web/モバイルアプリの中に通話やチャットを直接埋め込みたい
• 電話網（PSTN）との接続や電話番号の取得を、通信事業者との交渉なしに進めたい

これらを、複数のコミュニケーション手段を1つの基盤に束ねた API/SDK サービスとして提供することで解決します。アプリ開発者は通信インフラを意識せず、機能を呼び出すだけで組み込めます。

主要概念と用語

• リソース（Communication Services リソース）: 課金とアクセスの単位。エンドポイントと接続文字列を持ち、ここに各機能がぶら下がる
• Identity（ユーザー ID）: 通話やチャットに参加する利用者を表す内部 ID。Azure 側で発行し、自社の認証基盤のユーザーとマッピングして使う
• アクセストークン: Identity に紐づく短命のトークン。クライアント SDK はこれで各機能（Calling/Chat など）に接続する。発行はサーバー側で行う
• Calling（通話）: 1対1・グループの音声/ビデオ通話。ブラウザやモバイルアプリ内で動作する
• Chat（チャット）: スレッドベースのリアルタイムメッセージング。参加者管理や既読・タイピング通知を備える
• SMS: 取得した電話番号を使ったショートメッセージの送受信
• Email（メール）: 検証済みドメインからのトランザクションメール送信
• PSTN / Calling Plans: 公衆電話網への発着信。電話番号の取得や、固定電話・携帯への通話を可能にする
• Direct Routing: 自社の SBC（Session Border Controller）を介して既存の電話回線と接続する方式
• Teams 相互運用: Microsoft Teams の会議に外部ユーザーとして参加させたり、Teams ユーザーと連携したりする機能

仕様・制限・クォータ

代表的な考え方です（具体値は変動するため定性的に示します）。

• 提供形態: 通話・チャット・SMS・メール・電話番号の取得を、同一リソース上の API/SDKとして利用できる
• SDK: JavaScript/Web、iOS、Android、.NET、Python、Java などの言語・プラットフォーム向け SDK が提供される
• 電話番号: 国・地域や用途（SMS 対応か、通話対応か）によって取得可否や種別が異なる。規制上の要件を満たす必要がある番号もある
• SMS / メール: 送信レートやスループットには**上限（スロットリング）**があり、大量配信は事前の段階的な引き上げ申請やドメイン検証が前提になる
• チャット履歴: メッセージはスレッドに保持されるが、長期アーカイブや保持期間の要件は別途設計する
• データ所在: リソース作成時に**データの保管リージョン（データロケーション）**を選ぶ。コンプライアンス要件に合わせて選定する

内部の仕組み

クライアント（ブラウザやモバイルアプリ）は、サーバーが発行したアクセストークンを使って Communication Services に接続します。Identity の作成とトークン発行は必ずサーバー側で実行し、クライアントには短命トークンだけを渡します。

通話では、クライアント SDK が WebRTC ベースのメディア接続を確立し、メディアの中継やルーティングはサービス側のインフラが肩代わりします。送信側は自前でメディアサーバーを運用する必要がありません。チャットはスレッド単位でメッセージを保持し、リアルタイム通知（受信・既読・タイピング）をクライアントへ配信します。

• SMS/メールは、サーバーから API を呼び出して送信するトランザクション型が基本。配信結果は**イベント（配信レポート）**として受け取れる
• PSTN 接続は、Microsoft 提供の Calling Plans か、自社 SBC 経由の Direct Routing のいずれかでルーティングされる
• Event Grid 連携により、着信・メッセージ受信・配信完了などのイベントを他サービスへ流せる

設計パターン / ベストプラクティス

• トークン発行は専用のバックエンド API に集約し、自社認証で利用者を確認してから Identity とトークンを払い出す
• Identity と自社ユーザーのマッピングを保持し、誰がどの通話・チャットに参加できるかをサーバーで制御する
• イベント駆動で疎結合化する。着信や配信完了は Event Grid 経由で Functions などに流し、業務処理と通信を分離する
• チャネルを使い分ける。即時性が要る通知は SMS、記録性が要る連絡はメール、双方向の対話は Chat/Calling、と性質で選ぶ
• Teams 相互運用を活用し、社内が Teams で運用しているなら会議連携で実装コストを下げる
• リトライと冪等性を前提に、SMS/メール送信の再試行で二重送信が起きないよう送信側で制御する

運用・監視

• Azure Monitor / メトリクス・ログで、通話品質、SMS/メールの送信数と成否、エラー率を監視する
• 通話品質の指標（パケットロス・ジッター・遅延など）を収集し、ユーザー体験の劣化を早期に把握する
• 配信レポートを購読し、SMS やメールのバウンス・失敗を検知してリスト管理に反映する
• 電話番号の状態やメール用ドメインの検証状態を定期確認し、失効による配信停止を防ぐ
• スロットリングに当たった場合は、送信量の平準化や上限引き上げ申請を検討する

コスト

• 課金は主に使った分の従量制で、機能ごとに単位が異なる
  • 通話/ビデオは参加者・分単位、チャットはメッセージや月間アクティブユーザー単位が目安
  • SMS は送受信メッセージ単位、メールは送信通数・データ量単位
  • 電話番号は保有期間（月額）と、PSTN 通話の接続分数
• 検証は小規模な従量で始められるが、本番の大量配信や常時通話はボリュームに比例して増える
• 具体的な単価や無料枠は変動するため、公式の料金ページで最新値を確認する

セキュリティ

• アクセストークンはサーバー側で発行し、クライアントには短命トークンのみを渡す。トークン発行に使う接続文字列やキーをアプリに埋め込まない
• リソースへの管理アクセスは Microsoft Entra ID + RBAC で制御し、運用者ごとに最小権限を割り当てる
• 通信は TLS で暗号化され、保存データも暗号化される
• SMS/メールでは、送信元の正当性（検証済みドメイン・登録済み番号）を担保し、なりすましやスパム判定を避ける
• データロケーションを要件に合わせて選び、コンプライアンス対象データの保管地を管理する

Well-Architected の観点

• オペレーショナル エクセレンス: 通信インフラ（メディアサーバー・キャリア連携）をマネージドに任せ、運用負荷を機能の組み込みと監視に集中できる。配信レポートや通話品質メトリクスの監視を仕組み化することが要点
• 信頼性: SMS/メールはスロットリングや配信失敗を前提に、リトライと冪等性、バウンス処理を設計する。通話品質はネットワーク状況に依存するため劣化検知を用意する
• セキュリティ: トークン発行をサーバー側に閉じ、キーをクライアントに置かない。送信元の検証とデータロケーションの選定でコンプライアンスを満たす

試験で問われるポイント

関連サービス・比較

顧客コミュニケーションを担う Azure サービスと、AWS の相当サービスの守備範囲を整理します。

Azure 内では、モバイルへのプッシュ通知に特化する Notification Hubs や、サービス間イベントを扱う Event Grid が隣接します。Communication Services は「エンドユーザーとの双方向のやり取り（通話・チャット）」と「アウトバウンドの SMS/メール」を1つの基盤で扱う点が特徴で、イベント連携や通知と組み合わせて使われます。

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# Communication Services リソースを作成（データ保管地を指定）
az communication create \
  --name demo-acs-0614 \
  --resource-group demo-rg \
  --location global \
  --data-location japan

# 接続文字列を取得（サーバー側でトークン発行に使う。クライアントには渡さない）
az communication list-key \
  --name demo-acs-0614 \
  --resource-group demo-rg -o json

# Identity 拡張機能を有効化し、ユーザー Identity を作成
az extension add --name communication
az communication identity user create \
  --connection-string "<接続文字列>"

# 作成した Identity に対し、通話とチャットのアクセストークンを発行
az communication identity token issue \
  --scope voip chat \
  --user "<userId>" \
  --connection-string "<接続文字列>"