アイデンティティの島々：ACS トークンと Azure AD の比較

By Mirko Peters · 2026-08-11

ブログへようこそ。製品ロードマップを前にして、カスタムのコミュニケーション機能を Web アプリに直接組み込むべきか、それともユーザーを Microsoft Teams というエンタープライズの庭へ誘導すべきか迷ったことがあるなら、あなただけではありません。不適切なコミュニケーション アーキテクチャを選ぶと、大きな技術的負債、想定外のライセンス費用、そして利用定着を完全に止めてしまうユーザー オンボーディングの摩擦につながりかねません。この全体像を整理するために、Azure Communication Services (ACS) でアプリ発行のトークンを管理することと、従業員認証に Azure AD を使うことの根本的な違い、そしてコミュニケーション アーキテクチャを構築する際にこの二つの独立した ID システムをどう対応付けるかを詳しく見ていきます。

Automatically translated with AI from the original post. Read the English original

ブログへようこそ。製品ロードマップを前にして、カスタムのコミュニケーション機能を Web アプリに直接組み込むべきか、それともユーザーを Microsoft Teams というエンタープライズの庭へ誘導すべきか迷ったことがあるなら、あなただけではありません。不適切なコミュニケーション アーキテクチャを選ぶと、大きな技術的負債、想定外のライセンス費用、そして利用定着を完全に止めてしまうユーザー オンボーディングの摩擦につながりかねません。この全体像を整理するために、Azure Communication Services (ACS) でアプリ発行のトークンを管理することと、従業員認証に Azure AD を使うことの根本的な違い、そしてコミュニケーション アーキテクチャを構築する際にこの二つの独立した ID システムをどう対応付けるかを詳しく見ていきます。

本記事は最新のポッドキャスト エピソードを深掘りしたものです。こうした実際のトレードオフについて音声で詳しく解説を聴きたい場合は、Azure Communication Services vs Teams APIs もぜひご覧ください。

対象読者

• Web アプリやモバイル アプリに顧客向けのチャット/通話機能を導入するプロダクト リーダー
• Microsoft 365、Azure AD、Graph をまたいで設計するプラットフォーム アーキテクト
• 想定外のコンプライアンス問題やライセンス問題を抱えたくないエンジニアリング マネージャー

重要なポイント

• ID がすべてを左右します。 ACS は外部ユーザーや匿名ユーザーに対して柔軟ですが、Teams API は社内ユーザーについては Azure AD と連携する一方、ゲストのオンボーディングで摩擦が生じます。
• プレゼンスが分岐点になります。 Teams API は Graph を通じて豊富なプレゼンス情報を提供しますが、ACS にはネイティブな Teams プレゼンスがないため、独自の同期や妥協が必要になります。
• チャットの同等性が重要です。 Teams はクライアントの機能（スレッド、リアクション、カード）を備えています。ACS は軽量で組み込みやすい一方、不足している UX は自分で作り込む必要があります。
• 通話には境界があります。 ACS と Teams 会議の相互運用はネイティブでは提供されておらず、Teams 経由でゲストが参加するには多くの場合 Azure AD のゲスト招待が必要です。
• コンプライアンスとコスト。 Teams は Microsoft 365 のコンプライアンス機能（eDiscovery、DLP、リーガル ホールド）を引き継ぎますが、E3/E5 やプレミアム機能、スロットリングという現実がついてきます。ACS は従量課金ですが、ストレージ、保持、監査はご自身で管理する必要があります。
• ハイブリッドは強力ですが、運用コストがかかります。 ID マッピング、メッセージ変換、プレゼンスの同期、ポリシーの適用のためにミドルウェアが必要になることを想定してください。

クイック ガイダンス：ACS、Teams、ハイブリッドのどれを選ぶか？

• ACS を選ぶのは、B2C 規模でのスムーズな運用、匿名/ゲスト チャット、モバイルや Web SDK による迅速な開発、きめ細かなコスト管理が必要で、かつトークンのライフサイクル、ストレージ、保持、監査をご自身で管理する覚悟がある場合です。
• Teams API を選ぶのは、主要ユーザーが従業員で、プレゼンス、スレッド型チャット、会議への参加、テナント ポリシーの下で標準搭載のコンプライアンスが必要な場合です。ライセンスと Graph のアクセス許可の管理負担は受け入れる必要があります。
• ハイブリッドを選ぶのは、外部との会話を Teams の社内エージェントに提示する必要がある場合、または公開チャット/通話を Teams のコンプライアンスやプレゼンスと組み合わせる必要がある場合です。

現場で得られた実際の注意点

• 2 つの ID の島: ACS トークンと Azure AD オブジェクトの間には、マッピング レイヤーが必要です。
• ゲスト体験のコスト: AAD のゲスト招待は、迅速な B2C フローを遅くします。
• プレゼンスの不一致: ACS からは、担当者が Teams 会議中であることを「見る」ことができません。
• 添付ファイルの扱い: Teams は OneDrive/SharePoint を前提としていますが、ACS は多くの場合 Blob や URL を使います。
• 隠れた制限: 規模が大きくなると、Graph のスロットリングやプレミアム エンドポイントが問題になることがあります。
• ACS でのコンプライアンスの負担: 暗号化、保持、監査証跡、リージョンの保証をご自身で管理する必要があります。

機能別の詳細

ID とアクセス

• ACS: アプリ発行のユーザー/トークンは、Web サイトの訪問者や委託業者に適しています。MFA、取り消し、有効期限はご自身で管理する必要があります。
• Teams API: 社員には Azure AD SSO を利用します。ゲストには招待と同意が必要で、テナント ポリシーとの整合も必要です。

プレゼンス

• Teams API: Graph を通じて、テナント全体で豊富な即時プレゼンスを利用できます。
• ACS: ネイティブな Teams プレゼンスはありません。独自のテレメトリや同期が必要です。

チャットと UX

• Teams API: スレッド、リアクション、カード、返信、インラインのファイルに対応しており、Teams に近い機能性を備えています。
• ACS: メッセージング機能は軽量です。スレッド、検索、カスタム絵文字、永続化は自分で追加する必要があります。

通話/会議

• ACS: アプリに音声/ビデオを組み込めます。一般公開のアクセスに適しており、メディアのパスのトラブルシューティングは自分で行う必要があります。
• Teams API: テナントユーザーにはシームレスです。ただし外部ユーザーが参加するには、多くの場合 AAD ゲストのオンボーディングが必要になります。

SDK & 開発者体験

• ACS: Web/iOS/Android で共通の SDK を利用でき、組み込みが簡単です。
• Teams/Graph/Bot: 強力ですが、習得の難易度は高めです (アクセス許可、Webhook、ページングなど)。

コンプライアンス & ライセンス

• Teams: eDiscovery、DLP、訴訟ホールド、データの所在地の要件に最初から対応しています。料金は Microsoft 365 ライセンスで支払い、プレミアム機能や制限が加わる場合があります。
• ACS: 従量課金制です。ストレージの場所、保持、SIEM、監査データのエクスポートはご自身で管理します。

リファレンスアーキテクチャ (思考モデル)

• B2C ポータル (ACS 優先): ACS のチャット/通話 -> 自社のストレージ/保持 -> 必要に応じて、ボットやチャネル経由でエージェント向けに Teams へ中継。
• 社内ヘルプデスク (Teams 優先): Teams のチャット/ボット + Graph のプレゼンス -> スタッフの SSO -> 必要に応じてフォームやゲストのオンボーディングによる一般からの問い合わせ受付。
• ハイブリッドブリッジ: 一般公開ウィジェット用の ACS <-> ミドルウェア (ID マッピング、メッセージ変換、プレゼンス同期、コンプライアンスのフック) <-> Teams のチャネル/エージェント体験。

構築チェックリスト

• 主要ユーザーを定義します: 従業員、委託先の担当者、または一般ユーザーのどれかを決めます。
• データの保存場所と、保持および監査の責任者を決めます。
• コードを書く前に、ID のフロー (SSO、ゲスト、匿名) を整理します。
• プレゼンスの要件は早い段階で検証しましょう。後から付け足すのは避けてください。
• Graph の制限と ACS のメッセージ/通話のスループットを負荷テストします。
• ライセンスと運用の予算を立てます (ミドルウェア、監査、監視を含みます)。
• 次の四半期に要件が変わった場合に備えて、ロールバック/撤退の計画を立てておきます。

よくある質問 (簡易版)

• ACS のユーザーは Teams 会議にそのまま参加できますか? 直接は参加できません。ブリッジ、または AAD ゲストのフローが必要になります。
• ACS のユーザーに Microsoft 365 ライセンスは必要ですか? 不要です。ACS は従量課金制です。
• Teams API は外部の匿名ユーザーを扱えますか? きれいには扱えません。通常は AAD ゲストのオンボーディングが必要です。
• ACS でプレゼンスは利用できますか? Teams ユーザーのプレゼンスは取得できません。カスタムの同期や回避策が必要です。

実行ステップ

1. 必須の要件を上位 3 つ挙げてください (例: 匿名チャット、Teams のプレゼンス、eDiscovery)。
2. 2 つのトラックで短期の検証 (スパイク) を実施します。一般向けチャットは ACS の PoC、社内のエージェントは Teams の PoC です。
3. 両方が必要な場合は、ミドルウェアの MVP の範囲を定めます。ID マッピング、メッセージの中継、最小限のプレゼンス同期、監査ログを含めます。
4. 予算を調整します: Microsoft 365 のシート数 と、ACS の使用量およびコンプライアンス対応の運用人員。

まとめると、Azure Communication Services と Azure AD の間で ID の島を適切につなぐアーキテクチャを設計するには、対象ユーザーを明確に理解することが欠かせません。一般向けのコンシューマー ポータルを作る場合でも、社内の企業向けヘルプデスクを作る場合でも、ID を最優先に考えておくことで、後々の多くの手間を省けます。これらの選択についてさらに詳しく知りたい場合は、関連エピソードの Azure Communication Services vs Teams APIs をぜひお聴きください。Microsoft 365 と Azure のアーキテクチャに関する最新情報も、ぜひ購読してチェックしてください。