Microsoft Teamsで外線発着信やPBX置き換えを検討しているなら、まず確認すべき答えはシンプルです。Teams Phone features – Microsoft Teamsは「Teamsで電話ができるか」ではなく、「どの通話機能にTeams Phoneライセンス、PSTN接続、電話番号、管理設定が必要か」を整理するための公式情報です。Microsoft Teams Enterpriseだけで使える基本的なTeams通話と、Teams Phoneが必要な電話システム機能を分けて確認することが、移行トラブルを防ぐ第一歩になります。Microsoft Learnでは、Teams Phone機能の利用にはTeams Phoneライセンスだけでなく、機能によってPSTN接続と電話番号も必要になると説明されています。(Microsoft Learn)
Microsoft TeamsのTeams Phone featuresで最初に確認すべき結論
Teams Phone featuresの要点は、Microsoft TeamsをクラウドPBXとして使うための機能一覧です。Teams同士の通話、ボイスメール、転送などの基本機能はMicrosoft Teams Enterpriseライセンスで利用できるものがあります。一方で、PSTN番号への発信、外線着信、自動応答、通話キュー、ダイヤルプラン、緊急通報、複数番号対応などは、Teams PhoneライセンスやPSTNソリューションを前提に考える必要があります。(Microsoft Learn)
| 確認項目 | 実務上の意味 |
|---|---|
| Teams標準通話とTeams Phoneの違い | Teams同士の通話だけで足りるのか、外線・内線番号・PBX機能が必要なのかを切り分ける |
| ライセンス | Teams、Teams Phone、Calling Plan、共有デバイス、リソースアカウント用ライセンスを混同しない |
| PSTN接続 | Microsoft Calling Plan、Operator Connect、Teams Phone Mobile、Direct Routingのどれを使うか決める |
| 電話番号と音声有効化 | ユーザー番号、サービス番号、Enterprise Voiceの有効化を確認する |
| 管理ポリシー | 通話ポリシー、ボイスルーティング、発信者番号、緊急通報、Copilot、録音・文字起こしを設計する |
| 展開後の運用 | 通話品質、デバイス、ヘルプデスク対応、番号変更、利用状況を継続的に管理する |
この公式情報は、単なる機能一覧として読むよりも、Teams Phoneを導入・移行する前のチェックリストとして読むと実務に役立ちます。
Microsoft Teamsの「Teams Phone features」は何が変わるのか
機能追加の告知ではなく、導入判断の基準として重要
Teams Phone featuresのページは、特定の1機能のリリース告知というより、Teams通話とTeams Phone機能の範囲を整理する公式ドキュメントです。本文では、Teams PhoneをPBXの置き換えとして使う方法や、PSTNへ接続するための選択肢を理解するための前提情報として位置付けられています。(Microsoft Learn)
そのため、管理者が見るべき変更点は「新機能が増えたか」だけではありません。むしろ、以下のような運用判断が重要です。
| 見るべき観点 | 確認内容 |
|---|---|
| 既存ユーザーへの影響 | 既にTeams Phoneを使っているユーザーで、ライセンス・番号・ポリシーが正しく割り当てられているか |
| 新規展開への影響 | PBX移行時に、自動応答、通話キュー、緊急通報、番号管理をどの順番で設計するか |
| コストへの影響 | Teams PhoneライセンスとPSTN費用、Calling Plan、オペレーター契約、通話料を分けて見積もる |
| サポートへの影響 | ユーザーから「ダイヤルパッドがない」「転送できない」「外線に出られない」と問い合わせが来た時の切り分けを用意する |
| 開発・連携への影響 | コンタクトセンター、IVR、通話Bot、Graph API連携が対象範囲に入るか確認する |
Teams Phoneライセンスだけでは外線発着信は完結しない
よくある誤解は、「Teams Phoneライセンスを付ければ外線電話がすぐ使える」というものです。公式情報では、PSTNソリューションはTeams Phoneライセンスとは別であり、国内通話・国際通話・緊急通報・電話番号を提供する役割を持つと説明されています。Teams Phoneライセンスは、ユーザーに電話システム機能とPSTNソリューションへのアクセス権を与えるものです。(Microsoft Learn)
つまり、管理者は次の3点をセットで確認する必要があります。
| 必須要素 | 例 |
|---|---|
| ユーザー側のライセンス | Microsoft Teams、Teams Phone、必要に応じてCalling PlanやCopilot |
| PSTN接続 | Microsoft Calling Plan、Operator Connect、Teams Phone Mobile、Direct Routing |
| 管理設定 | 電話番号割り当て、Enterprise Voice有効化、緊急通報、通話ポリシー、ルーティング |
この3つのどれかが欠けると、ユーザーにTeams Phoneライセンスが付いていても、外線発信や着信が期待通りに動かない可能性があります。
対象者と影響範囲
Teams Phone featuresの影響を受けるのは、Teams管理者だけではありません。PBX移行やコンタクトセンター連携を進めている企業では、Microsoft 365管理者、ネットワーク担当、セキュリティ担当、開発者、ヘルプデスクも確認が必要です。
| 対象者 | 確認すべきポイント |
|---|---|
| Teams管理者 | 通話ポリシー、電話番号、音声有効化、自動応答、通話キュー、緊急通報 |
| Microsoft 365管理者 | ユーザーライセンス、リソースアカウント、共有デバイス、管理者ロール |
| ネットワーク担当 | 通話品質、拠点回線、Direct Routing、SBC、QoS、障害時の運用 |
| セキュリティ・法務担当 | 録音、文字起こし、Copilot利用、SMS、保持ポリシー、eDiscovery |
| 開発者・連携ベンダー | Graph API、通話Bot、コンタクトセンター統合、管理者同意 |
| ヘルプデスク | ダイヤルパッド表示、転送、ボイスメール、発信者番号、ユーザー教育 |
特にPBXからTeams Phoneへ移行する場合は、電話番号の移行だけでなく、営業時間外アナウンス、代表番号、部門別キュー、緊急通報、内線番号ルールまで洗い出す必要があります。
管理者が確認すべき設定
ライセンスをユーザー・共有デバイス・リソースアカウントで分ける
Teams Phoneのライセンス設計では、通常ユーザー、共有デバイス、自動応答や通話キュー用のリソースアカウントを分けて考えます。外線用の個人番号を持つユーザーには、TeamsとMicrosoft 365 Phone Systemを含むライセンスが必要です。Microsoft 365 E5系の一部ライセンスではPhone Systemが含まれるため、追加のTeams Phone Standardが不要なケースもありますが、契約体系によって異なるためテナント単位で確認してください。(Microsoft Learn)
リソースアカウントは、自動応答や通話キューなどの音声アプリケーション用に使う特殊なアカウントです。通常ユーザーとしてサインインして使うものではありません。管理者は、リソースアカウント用ライセンスを一般ユーザーに誤って割り当てないよう注意が必要です。(Microsoft Learn)
PSTN接続方式を選ぶ
Teams Phoneで外線通話を使うには、PSTN接続方式を選びます。Microsoft公式情報では、主な選択肢としてMicrosoft Calling Plan、Operator Connect、Teams Phone Mobile、Direct Routingが整理されています。(Microsoft Learn)
| 接続方式 | 向いているケース | 注意点 |
|---|---|---|
| Microsoft Calling Plan | Microsoftを通信事業者として使い、クラウド完結で始めたい | 利用可能な国・地域、料金体系を確認する |
| Operator Connect | 既存または希望する認定オペレーターを使いたい | 対応オペレーター、国・地域、番号移行条件を確認する |
| Teams Phone Mobile | 携帯電話番号をTeamsと連携したい | 対応モバイル事業者と契約条件を確認する |
| Direct Routing | 既存キャリア、SBC、オンプレPBX、アナログ機器連携を残したい | SBC、証明書、DNS、音声ルーティング、障害対応の設計が必要 |
複雑な環境では、複数のPSTN接続方式を組み合わせることもできます。たとえば、一般社員はCalling Plan、拠点や既存PBX連携はDirect Routing、モバイルワーカーはTeams Phone Mobileという設計も考えられます。(Microsoft Learn)
電話番号・Enterprise Voice・緊急通報を確認する
Teams Phoneの展開では、ライセンスを付けるだけでなく、ユーザーへの電話番号割り当てとEnterprise Voiceの有効化が必要です。Teams管理センターではユーザーのアカウント設定からEnterprise Voiceをオンにでき、PowerShellではSet-CsPhoneNumberAssignmentの-EnterpriseVoiceEnabledパラメーターを使います。(Microsoft Learn)
また、緊急通報は後回しにしないでください。公式のセットアップ手順では、Teams Phone導入の流れとして、ライセンス割り当て、PSTN接続、電話番号取得・割り当てに続いて、緊急通報の設定が示されています。緊急位置情報や動的緊急通報は、選択したPSTN接続方式やネットワーク設定によって手順が変わるため、パイロット段階で必ず検証してください。(Microsoft Learn)
代表的な機能と展開時の判断基準
自動応答と通話キュー
自動応答は、代表番号にかかってきた電話をメニューで部署やユーザーへ振り分ける機能です。通話キューは、問い合わせ窓口やサポート窓口のように、空いている担当者へ順番に着信を回すために使います。公式ページでは、自動応答や通話キューはTeams Phoneライセンス側の機能として整理され、通話キューから着信を受けるユーザーは音声有効化が必要と説明されています。(Microsoft Learn)
実務では、次のように設計します。
| 利用シーン | 推奨設計 |
|---|---|
| 代表番号の一次受付 | 自動応答で営業時間、部署選択、オペレーター転送を設定 |
| サポート窓口 | 通話キューで挨拶、保留音、エージェント、あふれ呼処理を設定 |
| 夜間・休日対応 | 営業時間外のアナウンス、ボイスメール、別番号転送を設計 |
| 複数拠点対応 | 拠点別の番号、キュー、緊急位置情報、発信者番号を整理 |
失敗しやすいのは、代表番号の着信だけをテストして、営業時間外、転送先不在、キュー満杯、代理応答、緊急時の連絡ルールを確認しないことです。本番前に、通常時と例外時の両方をテストしてください。
Private LineとMulti-line
Private Lineは、ユーザーに割り当てる2つ目の電話番号です。主に役員や重要連絡先向けの番号として使われ、受信専用で発信には使えません。ユーザーには1つのPrivate Lineのみ割り当てられ、プライマリ番号と同じ番号種別・ライセンス要件を満たす必要があります。(Microsoft Learn)
Multi-lineは、1人のTeams Phoneユーザーに複数の電話番号を割り当てる機能です。公式情報では、プライマリ回線、Private Line、最大9つの代替回線を含め、最大11番号を1つのTeamsアカウントに割り当てられるとされています。複数部署を兼務するユーザー、地域別番号で発信したい営業担当、複数ブランドを扱う窓口で有効です。(Microsoft Learn)
ただし、Multi-lineは「何でも番号単位で独立運用できる」機能ではありません。公式情報では、すべての回線で1つのボイスメールを共有し、通話転送などの通話設定はプライマリ回線と代替回線に一律適用される部分があります。また、代替番号を自動応答や通話キューへ追加する用途はサポート対象外として整理されています。(Microsoft Learn)
Copilot in Teams calls
Microsoft 365 Copilot in Teams callsは、Teams通話中に要点、異なる意見、フォローアップタスクなどを支援する機能です。管理者は通話ポリシーでCopilotの利用を制御でき、Teams管理センターまたはPowerShellで「On」「On with saved transcript required」「Off」を設定できます。(Microsoft Learn)
注意すべき点は、Copilotの設定が録音・文字起こし・保持ポリシーと密接に関係することです。通話後にも要約やトランスクリプトを参照させたい場合は文字起こしの設定が必要です。一方、通話中だけCopilotを使い、通話後に内容を残さない運用も選択できます。コンプライアンスやeDiscoveryの要件がある組織では、既定で有効にする前に法務・セキュリティ部門と方針を決めてください。(Microsoft Learn)
SMS in Teams
Teams Phone featuresにはSMS関連の情報も含まれますが、日本の管理者は特に可用性に注意が必要です。公式情報では、Microsoft Teams Calling PlanのSMSは米国、プエルトリコ、カナダのユーザーを対象としており、米国・カナダ外での送受信はサポートされないと説明されています。(Microsoft Learn)
さらに、SMSを有効化するには、Teams、Teams Phone、Microsoft Teams Calling Planに加えて、米国の10DLCネットワーク向けにBrandとCampaignの承認が必要です。SMSは1対1チャットでサポートされ、MMS、添付ファイル、絵文字、ステッカー、GIFは現時点でサポート外とされています。(Microsoft Learn)
日本企業がグローバル拠点向けに使う場合は、「TeamsにSMS機能がある」という理解で導入を決めず、対象国、契約、料金、承認手続き、送信制限を個別に確認してください。
移行・展開の進め方
Teams Phoneは、既存PBXの番号をTeamsへ移すだけの作業ではありません。Microsoftのセットアップ手順でも、ライセンス、PSTN接続、電話番号、緊急通報、自動応答、通話キュー、その他機能、運用管理という順序で整理されています。(Microsoft Learn)
| フェーズ | 実施内容 |
|---|---|
| 現状調査 | 代表番号、個人番号、内線、転送、営業時間、緊急通報、FAX・アナログ機器、既存PBXを棚卸しする |
| 設計 | ユーザー種別ごとに、個人番号、共有番号、通話キュー、Shared Calling、Private Line、Multi-lineを分ける |
| 接続方式選定 | Calling Plan、Operator Connect、Teams Phone Mobile、Direct Routingを拠点・国・要件ごとに選ぶ |
| パイロット | 少人数で外線発着信、転送、ボイスメール、緊急通報、通話品質、Copilot、デバイスを検証する |
| 本番移行 | 番号移行、利用者案内、ヘルプデスク手順、障害時連絡先を用意して段階的に展開する |
| 運用改善 | 通話品質レポート、利用状況、キュー応答率、問い合わせ内容を見ながらポリシーを調整する |
特にDirect Routingを使う場合は、SBC、証明書、DNS、音声ルート、PSTN使用法、拠点回線まで含めてテストが必要です。単にTeams側で電話番号を設定しても、ルーティングが正しくなければ発信・着信は安定しません。
管理者が失敗しやすいポイント
| よくある失敗 | 原因 | 対策 |
|---|---|---|
| Teams Phoneライセンスを付けたのに外線発信できない | PSTN接続、電話番号、Enterprise Voice、通話ポリシーのいずれかが未設定 | ライセンス、番号、音声有効化、PSTN接続をセットで確認する |
| 自動応答からユーザーへ転送できない | 転送先ユーザーが音声有効化されていない | 自動応答・通話キューの受信対象ユーザーを事前に確認する |
| 代表番号の運用が本番で崩れる | 営業時間外、休日、キュー満杯、不在時の設計がない | 通常時・例外時のコールフローを図にして検証する |
| Multi-lineで番号ごとに別ボイスメールを期待する | 現時点の仕様ではボイスメールは統合される | 代替番号の用途を「発信者番号・着信識別」として設計する |
| SMSを国内ユーザー向けに展開できると思い込む | SMS in Teamsの対象地域・契約条件を確認していない | 国・地域、Calling Plan、10DLC承認、料金を確認する |
| Copilotを有効にしたが監査要件に合わない | 文字起こし、保存、通話後利用の方針が未整理 | 通話ポリシー、録音・文字起こし、保持ポリシーを先に決める |
| リソースアカウント用ライセンスを通常ユーザーに付ける | ライセンス用途を混同している | ユーザー、共有デバイス、音声アプリケーションを分けて管理する |
Teams Phoneのトラブルは、製品不具合よりも「ライセンス・番号・ポリシー・PSTN接続の組み合わせ違い」で起きることが多いです。変更作業の前に、現在の割り当てを一覧化しておくと原因切り分けが早くなります。
開発者・連携ベンダーが確認すべきこと
Teams Phone featuresには、Teams Phone extensibilityとしてコンタクトセンター連携の観点も含まれます。Microsoft Teamsのコンタクトセンター統合では、ネイティブなTeams体験を組み込むモデル、Azure BotとMicrosoft Graph Communication APIを使う拡張モデル、認定SBCとDirect Routingを使う接続モデルが整理されています。(Microsoft Learn)
開発者が通話BotやIVRを扱う場合、Microsoft Graph APIs for calls and online meetingsにより、IVR、通話制御、リアルタイム音声・ビデオストリームへのアクセスなどを実装できます。ただし、Teamsアプリのマニフェスト、Graph権限、管理者同意、Webhook、場合によってはMicrosoft.Graph.Communications.Calls.Media .NETライブラリやWindows環境が必要です。(Microsoft Learn)
開発・連携時の確認ポイントは次のとおりです。
| 確認項目 | 判断基準 |
|---|---|
| 認定ソリューションか | コンタクトセンター用途ではMicrosoft認定済みソリューションを優先する |
| Graph APIでできる範囲か | 通話制御、Bot、会議連携と、Teams Phone管理機能を混同しない |
| 管理者同意が必要か | 本番導入前にEntra ID、Graph権限、同意フローを確認する |
| Multi-line管理 | 現時点の公式情報ではMulti-lineのGraph API管理は未サポートで、Teams管理センターまたはPowerShellを使う |
| コンプライアンス | 録音、文字起こし、Copilot、保存データ、通話ログの扱いを設計する |
「Teams Phoneで電話ができるから、すべてAPIで自由に制御できる」と考えると設計が崩れます。通話体験の拡張、電話番号管理、通話ポリシー管理、コンタクトセンター統合は、それぞれ使うAPIや管理画面が異なるため、最初に責任範囲を分けてください。
GCC High・DoD環境では可用性に注意する
グローバル企業や公共機関向けクラウドを利用している場合、商用クラウドと同じ機能が使えるとは限りません。公式ページでは、GCC HighおよびDoDクラウドで未提供の機能として、セカンダリリンガーやボイスメール関連の一部通話設定、検索バーからの電話番号発信、Microsoft Entra ID逆引き番号参照、Private LineとMulti-line、Shared Callingなどが挙げられています。(Microsoft Learn)
商用テナントで検証した手順を、そのままGCC HighやDoDへ横展開しないでください。機能可用性、管理センターの表示、PowerShellの挙動、ライセンス条件を環境別に確認する必要があります。
Teams Phone導入前のチェックリスト
本番展開前に、最低限次の項目を確認してください。
| チェック項目 | 確認方法の例 |
|---|---|
| ユーザー一覧 | Teams Phone対象者、外線不要ユーザー、共有番号利用者を分類する |
| ライセンス | Teams、Teams Phone、Calling Plan、共有デバイス、リソースアカウントを分ける |
| PSTN接続 | 国・拠点ごとにCalling Plan、Operator Connect、Teams Phone Mobile、Direct Routingを決める |
| 電話番号 | 個人番号、代表番号、サービス番号、代替番号、Private Lineを台帳化する |
| コールフロー | 営業時間、休日、転送先、キュー、ボイスメール、あふれ呼を図にする |
| 緊急通報 | 住所、拠点、ネットワーク位置情報、通知先、テスト手順を確認する |
| ポリシー | 通話、発信者番号、録音、文字起こし、Copilot、ボイスメールを確認する |
| デバイス | PC、モバイル、Teams Phoneデバイス、SIPデバイス、ヘッドセットを検証する |
| ヘルプデスク | よくある問い合わせ、切り分け手順、復旧連絡先を用意する |
| 運用監視 | 通話品質、デバイス状態、キュー応答、SMS利用、通話料を定期確認する |
まとめ：次にやるべきこと
Teams Phone features – Microsoft Teamsで確認すべき中心は、機能名の暗記ではありません。自社の電話業務を、ライセンス、PSTN接続、電話番号、ポリシー、ユーザー体験に分解して確認することです。
まずは、現在のTeams Phone対象ユーザー、電話番号、リソースアカウント、通話ポリシー、PSTN接続方式を一覧化してください。そのうえで、代表番号や問い合わせ窓口など業務影響が大きい番号から、コールフローと緊急通報を優先して検証します。Copilot、SMS、Multi-line、Private Line、コンタクトセンター連携は便利ですが、可用性や制限があるため、必要な部門に絞って段階的に展開するのが安全です。
コメント