Azure Communication Servicesとは？通話・チャット・SMS・メールをAPIで組み込む方法を実務目線で解説

Azure

自社のアプリに「通話機能」や「ビデオ通話」を組み込みたい。あるいは「予約が入ったらSMSを自動送信したい」。そう考えたとき、多くの人が最初に思うのは「通信基盤をゼロから作るのは無理だ」ということです。実際、音声・映像をリアルタイムでやり取りする仕組みを自前で構築するのは、専門チームでも骨が折れる仕事です。

ここで登場するのがAzure Communication Services（ACS）です。ざっくり言うと、TeamsやZoomの裏側で動いている通信基盤を、部品（API）として自分のアプリに埋め込めるサービス。通話・ビデオ通話・チャット・SMS・メールといった機能を、自前で作らずにAPIコールだけで組み込めます。

「通話やビデオ通話を自分のアプリに載せたいけど、通信の仕組みなんて分からない…。ACSって結局どこまでやってくれるの？」

この記事では、ACSで何ができるのか（チャネル）、ユーザーIDとトークンの考え方、ビデオ通話・電話（PSTN）の実装イメージ、Teams連携・Event Grid連携・通話録音までを、公式ドキュメントの正確さは押さえつつ、初心者がつまずく所を噛み砕いて解説します。私自身、以前医療現場向けにリアルタイム音声翻訳のアプリを一人で本番構築したことがあり、そのとき通話・リアルタイム通信で痛い目にあった実務の勘所も、要所で添えていきます。読み終わるころには「自分のアプリにどう通信機能を足すか」の全体像が描けるようになります。

Azure Communication Servicesとは何か

ACSは、通話・ビデオ通話・チャット・SMS・メールなどの「コミュニケーション機能」を、APIとSDKで提供するマネージドサービスです。「マネージド」というのは、サーバーの用意やスケーリング、通信の中継といった面倒な裏方をMicrosoftが全部やってくれる、という意味です。あなたは自分のアプリからAPIを呼ぶだけでいい。

もう少しイメージを噛み砕きます。TeamsやZoomのようなアプリは、内部に「音声を届ける仕組み」「映像を届ける仕組み」「メッセージを届ける仕組み」を持っています。ACSは、そのTeamsが使っているのと同じ通信基盤（バックエンド）を切り出して、開発者が部品として使えるようにしたものだと思ってください。実際ACSはTeamsと同じMicrosoftのグローバルなネットワーク上で動いています。

だから、たとえば「オンライン診療アプリに医師と患者のビデオ通話を載せたい」「フードデリバリーアプリで配達員と客がアプリ内通話できるようにしたい（電話番号を互いに知られずに）」といったニーズを、通信のプロを雇わなくても実現できるわけです。ここがACSの一番おいしいところです。

課金は「使った分だけ」

ACSは基本的に従量課金（Pay-as-you-go）です。通話なら「1分あたり・1参加者あたり」、SMSなら「1通あたり」、メールなら「送信数あたり」といった具合に、実際に使った通信量で課金されます。月額固定でドンと払うのではなく、使わなければほぼゼロ。小さく始めて、伸びたら伸びた分だけ払う、というスタートアップに優しいモデルです。学習で少し触るくらいなら、ごくわずかな費用で済みます。

チャネル：ACSで何ができるのか

ACSでできることは「チャネル」という単位で整理されています。チャネルとは、要するにコミュニケーションの手段の種類です。自分のアプリにどれを足したいかで、使うSDKやAPIが決まります。主なものを見ていきましょう。

  • 音声通話（Voice Calling）：アプリ内で音声だけの通話をする。IP電話のイメージ。
  • ビデオ通話（Video Calling）：音声＋映像。WebRTCという技術で、ブラウザやアプリ同士を双方向につなぐ。
  • チャット（Chat）：リアルタイムのメッセージング。既読やタイピング中の表示なども扱える。
  • SMS：スマホのショートメッセージ。予約確認や本人確認コードの送信によく使う。
  • Email（メール）：トランザクションメール（自動送信メール）をACS経由で送る。
  • WhatsApp などのアドバンスドメッセージング：WhatsAppを通じた顧客とのやり取り。海外向けサービスで重宝する。

ポイントは、これらを組み合わせられることです。たとえば「アプリ内でビデオ通話しながら、隣でチャットもできて、通話が終わったら結果をSMSで送る」といった複合機能も、同じACSリソースの中で完結します。バラバラのサービスを寄せ集めるより、認証やIDの管理が一本化できるのが効いてきます。

まずは「どのチャネルが欲しいか」を1つ決めて、そこから触るのがおすすめ。全部一気にやろうとすると迷子になります。

土台になる「アイデンティティ」と「アクセストークン」

どのチャネルを使うにしても、最初に必ず通る関門がアイデンティティ（ユーザーID）とアクセストークンです。ここがACSの独特なところで、初心者がまず「?」となる部分なので、丁寧に整理します。

ACSでは、通話やチャットに参加する一人ひとりにACS専用のユーザーIDを発行します。これはあなたのアプリのログインユーザー（DBに入っている会員情報）とは別物で、「ACSの世界での通行手形の持ち主」だと思ってください。そしてそのユーザーが実際に通話・チャットをするには、アクセストークンという時間制限付きの入場券が必要になります。

流れはこうです。

  1. Identity SDKを使って、サーバー側でACSユーザーIDを作成する。
  2. そのユーザーIDに対して、必要なスコープ（voip＝通話、chat＝チャットなど）を指定してアクセストークンを発行する。
  3. 発行したトークンをフロント（ブラウザやモバイルアプリ）に渡す。
  4. フロントのCalling SDKやChat SDKが、そのトークンを使って通話・チャットに参加する。

コードにすると、トークン発行の中核はこれだけです（Node.jsの例）。

const { CommunicationIdentityClient } = require("@azure/communication-identity");

const client = new CommunicationIdentityClient(connectionString);

// 1. ACSユーザーIDを作成
const user = await client.createUser();

// 2. そのユーザーに通話・チャットのトークンを発行
const { token, expiresOn } = await client.getToken(user, ["voip", "chat"]);

console.log(token); // これをフロントに渡す

各部分の意味を補足します。

  • connectionString：ACSリソースの接続文字列。ポータルの「キー」から取得できる、いわばリソースのマスターキー。絶対にフロントに置かない。
  • createUser()：ACSユーザーIDを1つ発行する。あなたのアプリの会員1人につき1つ作り、DBに紐づけて保存しておくのが定番。
  • getToken(user, […])：スコープを指定してトークンを取得。voipは通話、chatはチャット。必要な権限だけ渡すのが安全。

ここで実務上いちばん大事なのは、トークンの発行は必ずサーバー側でやるということです。接続文字列にはリソースを丸ごと操作できる権限があるので、これがフロントに漏れると誰でもあなたのACSを使い放題になります。フロントは「サーバーにトークンをくれと頼む→もらったトークンでSDKを動かす」だけ。この境界線を最初に頭に入れておくと、設計を大きく踏み外しません。

ビデオ通話（WebRTC）を実装するイメージ

ここからが花形、音声・ビデオ通話です。ACSの通話はWebRTCという、ブラウザ同士がサーバーを介さず（正確には最小限のサーバーで）リアルタイムに音声・映像をやり取りする技術の上に成り立っています。難しそうに聞こえますが、ACSがその複雑さをSDKで包んでくれているので、開発者が書くコードは驚くほどシンプルです。

Web（JavaScript）で2クライアント間を音声・映像でつなぐ最小の流れはこうなります。

import { CallClient } from "@azure/communication-calling";
import { AzureCommunicationTokenCredential } from "@azure/communication-common";

// サーバーからもらったトークンで認証
const credential = new AzureCommunicationTokenCredential(token);
const callAgent = await new CallClient().createCallAgent(credential);

// 相手のACSユーザーIDを指定して発信
const call = callAgent.startCall(
  [{ communicationUserId: "相手のACSユーザーID" }],
  { videoOptions: { localVideoStreams: [localVideoStream] } }
);

やっていることは「トークンで認証エージェント（CallAgent）を作る→相手のユーザーIDを指定して発信する」だけ。着信側はcallAgent.on("incomingCall", ...)で受けてaccept()すれば、双方向の通話がつながります。カメラ映像の取得（localVideoStream）まわりは少し手間がありますが、通話の骨格自体はこれだけです。

本番で効いてくる勘所：遅延と帯域

ここは私が実際に医療現場のリアルタイム通信アプリを本番運用して痛感した部分なので、少しだけ突っ込みます。デモが動くと「できた！」と満足しがちですが、本番のリアルタイム通信で本当に難しいのはネットワーク品質の揺れです。

  • 遅延（レイテンシ）：音声が数百ミリ秒遅れるだけで会話は驚くほどぎこちなくなる。特に医療のように「即時のやり取り」が命の現場では、遅延はそのまま使い物にならなさに直結する。
  • 帯域（回線の太さ）：ビデオは音声よりずっと帯域を食う。相手がモバイル回線だと映像がカクつく・止まる。だから回線が細いときは自動で画質を落として音声を優先する設計が要る（ACSは適応的に品質を落としてくれるが、その挙動を前提に作る意識が必要）。
  • 実機・実回線でのテスト：社内Wi-Fiの快適な環境だけで検証すると、本番で泣く。あえて弱い回線でテストしておくと事故が減る。

ACSは通話品質を可視化する仕組み（Call Diagnostics）や、通話後の品質メトリクスも提供しています。本番運用するなら、通話が切れた・音が悪かったという苦情に対して「実際どうだったか」を後から追える状態にしておくと、原因の切り分けが段違いにラクになります。

Teamsとの相互運用

ACSの面白い機能のひとつがTeams相互運用（Interoperability）です。何ができるかというと、あなたのアプリのユーザー（ACSユーザー）を、そのままTeams会議に参加させられるのです。

具体例で考えましょう。あるサービスの顧客サポートで、顧客はブラウザの自社アプリから、担当者は普段使っているTeamsから会議に入って通話する——顧客にTeamsをインストールさせることなく、です。実装としては、Teams会議のリンク（会議URLやMeeting ID）をACSのCalling SDKに渡してjoin()するだけ。ACSユーザーがTeams会議の一参加者として入っていきます。

これが効くのは、すでにTeamsで業務が回っている組織です。社内はTeamsのまま、社外の顧客には自社ブランドのアプリを見せる、という「見た目は自社・裏はTeams」の構成が組めます。ゼロから会議システムを作らずに、既存のTeams資産に相乗りできるわけです。

電話番号の取得とPSTN通話

ここまでの通話は「アプリ内のユーザー同士（ACSユーザー間）」の話でした。ACSはさらに本物の電話網（PSTN）にもつながります。PSTNとは、家や会社にある固定電話・普通の携帯電話がつながっている、いわゆる「電話回線」のことです。

ACSではポータルから電話番号を取得できます。取得した番号を使えば、アプリから実際の電話番号（090-…など）に発信する／その番号への着信を受けることができます。たとえば「アプリのボタンを押すとサポートセンターの固定電話に電話がかかる」「予約リマインドを自動音声で電話する」といったことが実現します。

コードのイメージは、通話先を「ACSユーザーID」ではなく「電話番号」にするだけです。

// 電話番号あて（PSTN）に発信する
const call = callAgent.startCall(
  [{ phoneNumber: "+8109012345678" }],
  { alternateCallerId: { phoneNumber: "+81ACSで取得した番号" } }
);

alternateCallerIdは「相手のスマホに表示される発信元番号」で、ACSで取得した番号を指定します。ここで実務的な注意が1つ。電話番号の取得や利用には、国ごとの規制・本人確認（KYC）が絡むことがあります。日本の番号を取る場合も、用途の申告や審査が必要になるケースがあるので、「番号はワンクリックで即入手」とは限らないと心づもりしておいてください。学習段階では、まずアプリ内通話（ACSユーザー間）で仕組みを掴み、PSTNは要件が固まってから、という順が安全です。

マネージドIDとEvent Grid連携

ACSは単体で動くだけでなく、他のAzureサービスと組み合わせると一気に実用的になります。その要がマネージドIDとEvent Gridです。

マネージドID：接続文字列を卒業する

先ほど「接続文字列は漏らすな」と書きましたが、そもそも接続文字列（=キー）を持ち歩かないのがより安全な設計です。ここでマネージドIDの出番。マネージドIDは「Azureのリソースそのものに与える身分証」で、これを使うとキーをコードや設定ファイルに書かずに、リソース同士が安全に認証し合えます。

たとえばApp Service上のアプリからACSを操作するとき、App ServiceにマネージドIDを付けてACSへのアクセス権を与えておけば、コードは「自分の身分でACSにアクセスする」だけでよくなります。キーの管理・ローテーションから解放されるので、本番運用では強く推奨される方法です。マネージドIDそのものの考え方は、別記事の Entra IDの条件付きアクセス・マネージドID・PIMを噛み砕いて解説 で詳しく触れているので、あわせて読むと理解が深まります。

Event Grid：通信イベントをきっかけに処理を動かす

ACSでは、通話が始まった・SMSを受信した・メールの配信結果が出たといった出来事がイベントとして発行されます。この通知を受け取る仕組みがEvent Gridです。Event Gridは「何かが起きたら、登録しておいた宛先に知らせてくれる郵便配達員」だと思ってください。

これを使うと、たとえば次のような「イベント駆動」の自動化が組めます。

  • SMSを受信したら → Azure Functionsを起動して内容を解析し、自動で返信する。
  • 着信があったら → 担当者に通知を飛ばす／通話の記録をDBに残す。
  • メールの配信が失敗したら → 別チャネル（SMS）で再通知する。

ポイントは、あなたのアプリが「イベントが来たかどうか」を常に監視しなくていいことです。起きたときだけ処理が動くので、無駄がなく、スケールもしやすい。この「イベントで運用をつなぐ」考え方は、通信に限らずAzure運用全般で効いてきます。定期実行やイベント起点の自動化をもっと知りたい方は Azure Automationとは？Runbookによる運用自動化・スケジュール実行・更新管理を実務目線で解説 も参考になります。

通話録音とコンプライアンス

最後に、業務で通話を扱うなら避けて通れない通話録音とコンプライアンスです。ACSにはCall Recording APIがあり、通話・会議の録音を開始・停止して、録音ファイルをストレージに保存できます。カスタマーサポートの応対記録、オンライン診療の記録、金融の「言った言わない」防止など、用途は幅広いです。

実装自体は録音を開始するAPIを叩き、終わったら停止するだけで、録音完了もEvent Gridのイベントで受け取れます。ただ、技術より重いのがコンプライアンス（法令・規約遵守）の側面です。ここは実務で本当に事故りやすいので、はっきり書いておきます。

  • 録音の同意：多くの国・場面で、録音することを相手に事前に知らせ、同意を得る必要がある。「この通話は録音されます」という案内は飾りではなく法的な要件になり得る。
  • 保存場所と暗号化：録音データは機微情報の塊。誰がアクセスできるか（権限）、どこに保管するか（リージョン・データ所在地）、暗号化されているかを設計時に決めておく。
  • 保持期間：いつまで保持し、いつ消すか。特に医療・金融は業界ルールがある。だらだら残すのはリスク。

私が医療系のリアルタイム通信を扱ったときも、いちばん神経を使ったのは通信の技術そのものより「そのデータをどう扱うと安全で、法的に問題ないか」でした。ここは「動けばOK」では済まないので、機能を作る前に誰の・どんなデータを・どこに残すのかを関係者と握っておくことを強くおすすめします。ACSはデータの所在地（リージョン）を選べるので、要件に合わせて設計できます。

まとめ

Azure Communication Services（ACS）を、実務で触る順に一気に見てきました。要点を振り返ります。

  • ACSとは：通話・ビデオ・チャット・SMS・メールをAPIで組み込めるマネージドサービス。TeamsやZoomの通信基盤を「部品」として自分のアプリに載せられる。従量課金で小さく始められる。
  • チャネル：欲しい手段（音声/ビデオ/チャット/SMS/Email/WhatsApp）を選び、組み合わせられる。まず1つに絞って触るのがコツ。
  • アイデンティティ／トークン：ACS専用ユーザーIDを作り、スコープ付きトークンを発行して使う。トークン発行と接続文字列は必ずサーバー側。
  • ビデオ通話（WebRTC）：SDKで数行。ただし本番は遅延・帯域との戦い。弱い回線でのテストと品質可視化が要。
  • Teams相互運用：ACSユーザーをTeams会議に参加させられる。「見た目は自社・裏はTeams」が組める。
  • PSTN通話：番号を取得すれば本物の電話に発着信可能。ただし番号取得には規制・審査が絡む。
  • マネージドID／Event Grid：キーレスで安全に。通信イベントを起点にイベント駆動の自動化が組める。
  • 通話録音／コンプライアンス：録音はAPIで簡単。難所は同意・保存・保持といった法令面。作る前に握る。

「通信機能は専門チームがないと無理」という思い込みは、ACSでかなり崩せます。まずはアプリ内のビデオ通話あたりを一つ動かしてみると、「自分のプロダクトに通話が載る」感覚が一気に掴めるはずです。そこから電話番号・録音・Event Grid連携へと広げていけば、業務レベルの通信機能も十分に射程に入ります。

あわせて読みたい：

タイトルとURLをコピーしました