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

Azure
2026.07.19

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

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

「通話やチャットを自分のアプリに載せたいけど、通信の仕組みなんて分からない…。ACSって結局どこまでやってくれて、まず何から触ればいいの？」

この記事はACSシリーズの入門編（ハブ記事）です。ACSで何ができるのか（チャネル）、そして最初に必ず通る関門であるアイデンティティ（ユーザーID）とアクセストークンまでを、公式ドキュメントの正確さは押さえつつ、初心者がつまずく所を噛み砕いて解説します。最後には実際にチャットとSMSを送るところまで手を動かして、ACSの手触りを掴んでもらいます。私自身、以前医療現場向けにリアルタイム音声のアプリを一人で本番構築した経験があり、その勘所も要所で添えます。読み終わるころには「自分のアプリにどう通信機能を足すか」の入口が見えるはずです。

なお、ビデオ通話（WebRTC）・Teams相互運用・電話番号（PSTN）・通話録音といった「通話」まわりの応用は、続編の通話・Teams連携編にまとめています（末尾にリンクを置きます）。まずはこのハブで土台を固めましょう。

Azure Communication Servicesとは何か

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

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

だから、たとえば「予約完了時に確認SMSを自動で送りたい」「アプリ内に問い合わせチャットを載せたい」「オンライン診療アプリに医師と患者のやり取りを載せたい」といったニーズを、通信のプロを雇わなくても実現できるわけです。ここがACSの一番おいしいところです。

「アプリの部品」であって「完成品」ではない

ひとつ勘違いしやすい点を先に潰しておきます。ACSはZoomやSlackのような「そのまま使える完成アプリ」ではありません。あくまで通信機能を提供する「部品」で、画面（UI）やユーザー管理は自分のアプリ側で用意します。「Teamsみたいなものが箱で届く」のではなく、「Teamsを作るための通信エンジンが届く」というのが正確なイメージです。ここを取り違えると期待とズレるので、最初に押さえておきましょう。

課金は「使った分だけ」

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の管理が一本化できるのが効いてきます。

「トークンが要るチャネル」と「要らないチャネル」

チャネルを触る前に、実装のパターンが大きく2つに分かれることを知っておくと迷いません。

  • 参加者どうしが「つながる」系（通話・ビデオ・チャット）：一人ひとりにACSユーザーIDとアクセストークンが必要。フロント（ブラウザ・アプリ）がそのトークンでSDKを動かす。
  • アプリから「送りつける」系（SMS・Email）：ユーザーIDやトークンは不要。サーバーから宛先を指定してAPIを叩くだけで送れる。

まずは「どのチャネルが欲しいか」を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を動かす」だけ。この境界線を最初に頭に入れておくと、設計を大きく踏み外しません。

トークンには「有効期限」がある

もう1つ、初心者がハマりやすいのがトークンの有効期限です。アクセストークンは入場券なので、時間が経つと切れます（既定で24時間ほど）。長時間開きっぱなしのアプリだと、途中でトークンが切れて通話やチャットが落ちる、という事故が起きます。

対策はシンプルで、切れる前にサーバーへ新しいトークンを取りに行って差し替えるだけ。フロントのSDKには、期限が近づいたら自動でトークンを取り直す仕組み（リフレッシュ）を渡せるようになっているので、本番では最初から組み込んでおくと安心です。「デモは動いたのに、しばらく置いたら切れる」の原因はたいていこれです。

まず動かす：チャットとSMSを送ってみる

ここまでの話を、いちばん軽いところから手を動かして確かめましょう。チャット（トークンが要る系）とSMS（送りつける系）を、それぞれ最小のコードで送ってみます。ACSリソースはポータルから作成し、接続文字列を控えておいてください（実行はすべてサーバー側です）。

チャット：スレッドを作ってメッセージを送る

チャットは「スレッド（会話の部屋）を作り、そこにメッセージを送る」という流れです。先ほど発行したユーザーIDとトークンを使います。

const { ChatClient } = require("@azure/communication-chat");
const { AzureCommunicationTokenCredential } = require("@azure/communication-common");

// user.token は Identity SDK で発行したトークン
const chatClient = new ChatClient(
  endpointUrl, // 例: https://<resource>.communication.azure.com
  new AzureCommunicationTokenCredential(token)
);

// 1. チャットスレッド（会話の部屋）を作成
const result = await chatClient.createChatThread(
  { topic: "予約に関するお問い合わせ" },
  { participants: [{ id: { communicationUserId: userId } }] }
);
const threadClient = chatClient.getChatThreadClient(result.chatThread.threadId);

// 2. メッセージを送信
await threadClient.sendMessage({ content: "こんにちは、担当の田中です。" });
  • createChatThread()：会話の「部屋」を1つ作る。topicは件名、participantsに参加者のACSユーザーIDを渡す。
  • getChatThreadClient()：作った部屋を操作するためのクライアントを取得する。
  • sendMessage()：その部屋にメッセージを投稿する。相手側は同じスレッドを購読しておけば、リアルタイムに受け取れる。

SMS：宛先を指定して送るだけ

SMSはさらに簡単です。ユーザーIDもトークンも要りません。ACSで取得した送信元番号と宛先番号を指定して、サーバーからAPIを叩くだけ。

const { SmsClient } = require("@azure/communication-sms");

const smsClient = new SmsClient(connectionString);

const results = await smsClient.send({
  from: "+81ACSで取得した番号", // 送信元（ACSで取得した番号）
  to: ["+8109012345678"],       // 宛先（複数可）
  message: "ご予約を承りました。当日お待ちしております。",
});

console.log(results[0].successful); // true なら送信成功

ここで1つ実務的な注意を。SMS送信用の電話番号の取得には、国ごとの規制や用途の審査が絡むことがあります。「番号はワンクリックで即入手」とは限らないので、SMSを本番で使う予定なら、番号取得の要件を早めに確認しておくと安全です。学習段階では、まずチャットで「つながる系」の感触を掴むのがおすすめです。

チャットが動くと「自分のアプリに通信が載る」感覚が一気に掴めます。そこから通話・ビデオへ広げていくと、地に足がついた学習になりますよ。

まとめ

Azure Communication Services（ACS）の入門編として、土台になる考え方を一気に見てきました。要点を振り返ります。

  • ACSとは：通話・ビデオ・チャット・SMS・メールをAPIで組み込めるマネージドサービス。TeamsやZoomの通信基盤を「部品」として自分のアプリに載せられる。完成アプリではなく「通信エンジン」。従量課金で小さく始められる。
  • チャネル：欲しい手段（音声/ビデオ/チャット/SMS/Email/WhatsApp）を選び、組み合わせられる。実装は「つながる系（トークン要）」と「送りつける系（トークン不要）」に分かれる。まず1つに絞るのがコツ。
  • アイデンティティ／トークン：ACS専用ユーザーIDを作り、スコープ付きトークンを発行して使う。トークン発行と接続文字列は必ずサーバー側。トークンには有効期限があるのでリフレッシュを組み込む。
  • まず動かす：チャットは「スレッドを作って送信」、SMSは「宛先を指定して送るだけ」。軽いチャットから触ると手触りが掴める。

「通信機能は専門チームがないと無理」という思い込みは、ACSでかなり崩せます。まずはチャットかSMSを一つ動かしてみるところから始めてみてください。土台となる「ユーザーIDとトークン」の考え方さえ掴めれば、そこからビデオ通話や電話連携へ広げるのは一直線です。

さらに深く学ぶ：ACS 通話・Teams連携編

このハブで土台ができたら、次は「通話」まわりの応用です。ビデオ通話（WebRTC）の実装、Teams会議への相互接続、本物の電話網（PSTN）への発着信、通話録音とコンプライアンス、マネージドID・Event Gridによる本番運用まで、実務で効くテーマを続編にまとめています。

あわせて読みたい：

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