Unified CM と Webex Calling に登録されたデバイスの共存を可能にするための移行中に、少なくとも次の要件を満たすように、Unified CM のエンタープライズ ダイヤル プランを変更する必要があります。

• +E.164 Unified CM から Webex Calling へのダイヤル

• Unified CM から Webex Calling への内線ダイヤル（サイト内だけでなく、内線範囲が一意の場合はサイト間も）

• Unified CM から Webex Calling への短縮サイト間ダイヤリング

• Unified CM から Webex Calling への強制オンネット ダイヤリング

• 不在着信ディレクトリから Webex Calling の宛先へのコールバック

• 移行中にオンプレミスの PSTN が Webex Calling に使用されている場合、Webex Calling から PSTN への PSTN 通話

• 移行中にハイブリッド Webex Calling 展開の PSTN トランキングを使用して、オンプレミスの Unified CM ユーザーに Cloud Connect for Webex Calling を通じて PSTN アクセスを提供する場合、Unified CM から Webex Calling への PSTN 通話

• Webex Calling から Unified CM への強制オンネット

• Webex Calling から Unified CM (サイト間) への内線ダイヤル。

上記のいずれかが移行前にサポートされていないダイヤリング習慣である場合 (たとえば、短縮されたサイト間ダイヤリング習慣が存在しない場合)、移行中に必ずしも導入する必要はありません。

図 ベスト プラクティス ダイヤル プラン は、 Cisco Collaboration 12.x Enterprise オンプレミス展開の推奨アーキテクチャ、CVDで説明されているベスト プラクティス ダイヤル プラン アプローチを示しています。このアプローチの主な特徴は次のとおりです。

• 単一パーティション +E.164 電話番号

• コアルーティングは以下に基づいて +E.164 ルートパターン

• すべてのダイヤル習慣を標準化 +E.164 翻訳パターンを使用する

• 変換パターンのコーリング サーチ スペースの継承を使用します (変換パターンにオプション 発信元のコーリング サーチ スペース を設定します)。

たとえば、PSTNダイヤル (9+1+10D) 回線コーリングサーチスペース SJCInternational がプロビジョニングされたSJCのデバイスから、最初に によってマッチングされます。 9.1[2-9]XX[2-9]XXXXXX 着信側番号を正規化する翻訳パターン +E.164. 二次検索では、同じコーリングサーチスペース SJCInternational を再度使用します（コーリングサーチスペースの継承）。 +E.164-digit 文字列は、 +E.164 DN パーティション内のディレクトリ番号、または USPSTNNational または SJCPSTNLocal パーティション内のいずれかの PSTN ルート パターンによって指定されます。サイト内およびサイト間の短縮ダイヤル手順は、 ESN および SJCtoE164 パーティション内の変換によって実装されます。 ESN パーティションはグローバル パーティション (すべての場所の電話機がアクセス可能) ですが、 SJCTOE164 パーティションは SJC の場所のユーザーのみがアクセス可能です。これは拡張範囲が重複していることを想定しています。

Unified CMからWebex Callingへの通話を有効にする最初のステップは、 +E.164 目的地はそれに応じてルーティングされます。これは、ダイヤルプランにWebex Callingパーティションを追加することで実現できます。 +E.164 すべての Webex Calling 宛先のルート パターンをそのパーティションに送信し、最後に、Webex Calling に到達できる必要があるサービス クラスを表すすべての呼び出し検索スペースに Webex Calling パーティションを追加します。Webex Calling からの通話に対して差別化されたサービス クラスの作成を有効にするには、専用の Webex Calling パーティションを作成する必要があります。通話ループを回避するには、ローカル ゲートウェイからのトランクの着信通話検索スペースが Webex Calling パーティションにアクセスできないようにする必要があります。

図に示すように +E.164 Webex Callingへのルーティング、Unified CMからWebex Callingへのルーティングを有効にする +E.164 DID範囲 +1 221 555 2XXXとサイトコード121、これに一致する緊急ルートパターン +E.164 範囲を Webex Calling パーティションに追加する必要があります。

サイト固有のローカル ゲートウェイの選択が必要ない場合は、Webex Calling を指すルート パターンの宛先として Webex Calling ローカル ルート グループを含むルート リストを使用する代わりに、ローカル ゲートウェイを唯一のメンバーとして単一のルート グループをプロビジョニングし、Webex Calling ルート パターンが、この 1 つのルート グループを唯一のエントリとして単一の Webex Calling ルート リストを指すようにすることができます。

Webex Calling サイトへのサイト間短縮ダイヤルを有効にするには、必要なルート パターン 8121.2XXX が Webex Calling パーティションに追加されます。Webex Callingに移行するサイトには、ESNダイヤルを正規化するダイヤル正規化パターン 8121.2XXX +E.164 ESN パーティションに既に存在している可能性があります。その場合、 8121.2XXX は冗長であるように見えますが、それぞれの場所のすべての DN が Webex Calling に移行されるとすぐに 、 8121.2XXX ダイヤリング正規化変換パターンを削除でき、その後、 8121.2XXX ルート パターンによって、その範囲内の内線のみのユーザーに対しても ESN ダイヤリングが有効になります。

これらのダイヤルプランの変更により、Webex Callingロケーションへの通話は、短縮サイト間ダイヤルだけでなく、 +E.164. また、国際および国内PSTNダイヤルは、これらのダイヤル習慣が最初に標準化されているため可能です。 +E.164 既存のダイヤル正規化翻訳パターンを通し、Webex Callingにルーティングされます。 +E.164 Webex Calling パーティション内のルート パターン。

その +E.164 すべての DID が Unified CM でホストされている状態でも、Webex Calling ロケーションの DID 範囲でのルート パターン マッチングをプロビジョニングできます。Unified CMのベストマッチパターンマッチングアルゴリズムは、Unified CMでホストされている番号がダイヤルされたときに、 +E.164 Unified CMでプロビジョニングされたディレクトリ番号は、ワイルドカードで指定されたものよりも一致度が高いです。 +E.164 Webex Calling を指すルート パターン。これにより、通話は Unified CM 上の回線に拡張され、Webex Calling に送信されません。

Webex Callingの各ユーザーには内線番号がプロビジョニングされます and/or 1つの +E.164 電話番号。拡張子の長さは固定のグローバル設定です。Webex Calling 展開内のすべての内線の長さは同じです。内線ダイヤルは、Webex Calling ユーザー間で、同一ロケーション内およびロケーション間で使用できます。サイト間の内線短縮ダイヤル (後者の場合) は、ダイヤルされた内線が一意である場合にのみ機能します。

拠点間での短縮サイト間ダイヤリングが必須であるが、異なる拠点に割り当てられた内線番号が重複している場合は、内線番号の前にアクセス コードとサイト コードを付加して、企業固有の番号計画を作成する必要があります。詳細については、 Cisco Collaboration 15 オンプレミス展開の推奨アーキテクチャ、設計概要 を参照してください。このドキュメントは 、 Cisco Collaboration の推奨アーキテクチャで入手できます。

内線の長さ、ロケーション間内線ダイヤルの動作、ロケーション間ダイヤルのプレフィックスの長さ、およびロケーション間ダイヤルのルーティング プレフィックスのステアリング ディジットは、Control Hub の通話サービス設定で設定されます。

• ロケーションルーティングプレフィックス長: ステアリング桁を含むプレフィックスの長さ。企業の番号計画を代替の短縮企業間拠点ダイヤリング習慣として確立する必要がある場合にのみ必要です。

• ルーティングプレフィックスのステアリングディジット: 短縮された企業間拠点ダイヤリング習慣のステアリング番号。任意の場所の最初の数字と場所の発信ダイヤル数字との重複は避ける必要があります。企業の番号計画を代替の短縮企業間拠点ダイヤリング習慣として確立する必要がある場合にのみ必要です。

• 内部延長長さ: 延長部分の標準長さ。2 から 10 までの任意の値を指定できます。

  オンプレミスのコール制御から Webex Calling への内線ダイヤルまたは企業の重要な番号 (ステアリング コード、サイト コード、内線) を使用したダイヤルが必要であり、オンプレミスのコール制御が発信者 ID として内線を送信する場合は、 Webex Calling とオンプレミス間のコール ルーティング セクション の 不明な内線の最大長 パラメータも設定して、オンプレミスのコール制御から Webex Calling へのアップストリーム コールがオンプレミス コールとして正しく分類されるようにしてください。

• 拠点間の内線通話を許可する: 切り替える enable/disable 拠点間の内線ダイヤル。このオプションは、組織内のすべての内線番号が一意である場合にのみ有効にする必要があります。このオプションが無効になっている場合は、企業の重要な番号 (ステアリング コード、サイト コード、内線番号) または電話番号を場所間でダイヤルする必要があります。

最初の 3 つのパラメータは主に、オフフック ダイヤルの使用時に桁間タイムアウトを最小限に抑えるための電話機のダイヤル プランを構築するために使用されます。これらのグローバル設定からの逸脱は依然として可能です (例: 異なる長さの内線番号をプロビジョニングできます) が、Control Hub に警告メッセージが表示され、電話からのダイヤルでは、事前にロードされたダイヤル プラン内での競合を回避するために、一括ダイヤルが必要になる場合があります。

表 エンタープライズ番号の例 は、NYC と RTP の 2 つの場所の内線範囲が同一である 3 つの場所の例を示しています。サイト間ステアリング数字 8、それに続く 3 桁のサイト コード、および 4 桁の内線番号を使用してエンタープライズ番号方式を確立すると、重複しないサイト間短縮ダイヤル習慣が作成されます。

表2. 企業番号の例

サイト	拡張範囲	サイトコード	エンタープライズ範囲
ニューヨーク	2XXX	202	8 202 2XXX
サンフランシスコ	3XXX	203	8 203 3XXX
RTP	2XXX	204	8 204 2XXX

スムーズな移行を可能にするには、Webex Calling への移行前と移行後のユーザーのダイヤル習慣のセットが同じであることが理想的です。各拠点の移行に備えるために、DID 範囲と内線範囲 (または短縮されたサイト内ダイヤル手順) を文書化する必要があります。この情報に基づいて、サイト間ステアリング数字を選択する必要があります。

表 固定長の Webex Calling 内線範囲 には、3 つの場所と固定長の内線範囲の例が示されています。ダイヤリング習慣の重複を避ける必要があるため、内線番号範囲の最初の数字がサイト間短縮ダイヤリングのステアリング数字と一致しないようにすることが重要です。たとえば、サイト間ダイヤリングのステアリング数字として 8 を選択した場合、どのサイトの内線範囲も 8で始まることはできません。通常、特定の場所の内線番号は、その場所に割り当てられた DID の最後の数桁と一致します。競合を避けるために、拡張子の最初の数字を変更できます。例えば、 +1 408 555 8XXX の範囲が特定の場所で使用されている場合、内線範囲として 8XXX を使用する代わりに、そのサイトの内線に 7XXX を使用することができます。

表3. 固定長の Webex Calling 内線範囲

サイト	拡張範囲	Webex 通話拡張機能	サイトコード	エンタープライズ範囲
ニューヨーク	2XXX	2XXX	202	8 202 2XXX
サンフランシスコ	8XXX	7XXX	203	8 203 7XXX
RTP	1XX	11XX	204	8 204 11XX

米国の Webex Calling ダイヤル プランを使用して Webex Calling デバイスでダイヤルされた 7 桁のダイヤル文字列は、事前にロードされた米国のダイヤル プランのローカル ダイヤルの 7 桁のパターンと重複します。オンネットとオフネット (PSTN) のダイヤル習慣の重複を避けるため、その場所では必須の外部アクセス コードを使用できます。既存のエンタープライズ番号体系とそれに対応する短縮サイト間ダイヤリングが Webex Calling 国内ダイヤルのパターンと重複する場合は、Webex Calling への移行中に、重複を避けるための番号体系をより長い形式または短い形式に変更することもできます。これを実現する最も簡単な方法は、番号付けスキーマに追加の埋め込み数字を追加することです。新しい長いサイト間ダイヤリング スキーマを採用する必要があるのは、すでに Webex Calling に移行しているユーザーのみです。Unified CM を引き続き使用しているユーザーは、7 桁の番号をダイヤルし続けることができます。この場合、Unified CMのエンタープライズダイヤルプランでは、Unified CMからWebex Callingへの短縮7桁ダイヤルが、次のいずれかに変換されることを確認する必要があります。 +E.164 または、Webex Calling で導入された短縮ダイヤル形式を使用します。これは、通話をローカル ゲートウェイに送信する前に実行する必要があります。

表 7 桁のダイヤルの移行 に、この番号変更の例を示します。この例では、Unified CM のサイト間短縮ダイヤリングでは、ステアリング数字 8 の後に 2 桁のサイト コードと 4 桁の内線番号が使用されています。Webex Calling のロケーションで 7 桁の短縮サイト間ダイヤリングを回避するには、Unified CM で使用される 2 桁のサイト コードの前に任意のパディング ディジット (例では8 ) を付加することで、サイト コードを簡単に 3 桁に変更できます。これにより、Webex Calling 電話からのサイト間ダイヤリングでは、ステアリング ディジット 8 に続いてパディング ディジット 8、古い 2 桁のサイト コード、および 4 桁の内線番号が使用されます。Webex Calling のユーザーは新しいサイト コードを覚える必要はなく、Unified CM の 8 の代わりにサイト間ダイヤルのプレフィックスとして 88 を使用することを覚えておくだけで済みます。

表4. 7桁ダイヤルへの移行

		Unified CM		Webex Calling
サイト	内線	サイトコード	エンタープライズ範囲	サイトのオード	エンタープライズアンジュ
ニューヨーク	2XXX	22	8 22 2XXX	822	8 822 2XXX
サンフランシスコ	8XXX	23	8 23 7XXX	823	8 823 7XXX
RTP	1XXX	24	8 24 11XX	824	8 824 11XX

Unified CM と Webex Calling で異なるエンタープライズ番号形式を使用するシナリオでは、Unified CM から Webex Calling への通話の発信者情報としてエンタープライズ番号が表示される場合 (たとえば、DID のないデバイスからの通話)、コールバックが確実に機能するように、発信者情報の異なる番号形式間のマッピングも実装することが重要です。このマッピングは、Unified CM とローカル ゲートウェイ間のトランク上で発信側変換パターンを使用することで実現できます。

適切な通話録音プロバイダーを選択することは、ビジネス目標を達成し、組織全体で機能の整合性を確保するための基本です。

• グローバルプロバイダーの選択: 組織は通常、グローバルレベルで主要な通話録音プロバイダーを指定し、すべての場所で機能セット、コンプライアンス、サポートの一貫性を確保します。

• 場所に基づくオーバーライド: 特定のサイトまたは地域に固有のビジネス ニーズや規制要件があるシナリオでは、グローバル プロバイダーの選択をオーバーライドし、それらの場所に対して代替プロバイダーを指定する必要がある場合があります。この柔軟性により、さまざまなコンプライアンス要件と現地の運用ニーズに対応できます。

• ビジネス要件: プロバイダーの選択は、規制遵守（例：MiFID II、HIPAA）、品質保証、紛争解決、トレーニングのニーズなどのビジネスドライバーの評価に基づいて行う必要があります。

• 機能の可用性: プロバイダーは、リアルタイム監視、検索および再生機能、暗号化、保持ポリシー、分析プラットフォームとの統合、さまざまな通話タイプ (着信、発信、内部) のサポートなど、必要な機能を提供できるかどうかに基づいて評価する必要があります。

通話録音が保存および処理される地域を決定することは、コンプライアンスとパフォーマンスにとって重要です。

• グローバル地域の選択: デフォルトでは、組織は管理とガバナンスを簡素化するために、通話録音の保存に単一のリージョンを選択できます。

• 位置情報に基づく地域のオーバーライド: データ居住法や企業ポリシーで要求される場合、特定の場所のグローバル地域設定を上書きし、通話録音が必要な地理的境界内で保存および処理されるようにする必要があるかもしれません。

• データ保存要件: 設計では、通話録音の保存場所と方法を規定する可能性のある国際的および地域的なデータ保護規制 (GDPR、CCPA、国固有の規制など) を考慮する必要があります。

Webex Calling の通話録音ソリューションの計画と設計中に対処する必要があるもう 1 つの重要な側面は、ストレージ要件の見積もりです。継続的な業務運営をサポートし、コンプライアンスを維持し、サービスの中断を回避するために十分な容量を確保するには、ストレージのニーズを正確に予測することが不可欠です。

予想されるストレージ需要を決定する際には、いくつかの重要なパラメータを考慮する必要があります。

• 録音された通話の音量: 特定の期間内（日、週、月など）に記録される通話の予想数を評価します。これには、外部通話だけでなく、ビジネスポリシーや規制要件で必要な場合は内部通信も含まれます。

• 平均通話時間: 通話時間が長くなると多くのストレージ容量が消費されるため、録音される通話の標準的な長さを計算します。異なる部門やユーザーグループ間での通話時間の変動も見積もりに考慮する必要があります。

• 保持期間: 記録を保持する必要がある期間を定義します。これは、多くの場合、組織のポリシーまたは外部規制 (業界固有のコンプライアンス標準など) によって決定されます。保存期間が長くなると、全体的なストレージ要件が増加する

• 成長予測: ビジネスの拡大、新しい規制要件、または追加のユーザーや場所のオンボーディングの結果として生じる可能性のある、予想される通話量の増加や録音範囲の拡大を考慮してください。

これらのパラメータを徹底的に分析することで、組織は Webex Calling 通話録音ソリューションの拡張性、コスト効率、規制遵守を保証する堅牢なストレージ戦略を策定できます。また、使用パターンは時間の経過とともに変化するため、定期的にストレージの割り当てを確認して調整することをお勧めします。

管理者は、Control Hub インターフェイスを通じて個々のユーザーに Webex Calling ライセンスを手動で割り当てます。

管理者は、個々のユーザーのサービス ライセンスを編集し、通話ライセンスを直接割り当てることができます。

Control Hub のライセンス割り当てテンプレートを使用して、グループまたは組織の設定に基づいてユーザーにライセンスを自動的に割り当てます。

自動ライセンスはディレクトリ同期または手動ユーザー更新を通じて実行できますが、ユーザーには有効な +E.164 フォーマットされた電話番号であり、電話番号はユーザープロビジョニングの前に Webex Calling の場所に存在している必要があります。条件が満たされていない場合 (例: 電話番号の形式が無効)、Webex Calling ライセンスは割り当てられません。

ユーザーの詳細とライセンスの割り当てを含む CSV ファイルをアップロードして、複数のユーザーを一度に追加または変更します。

CSV インポートでは最大 20,000 人のユーザーの追加とライセンスの割り当てがサポートされていますが、Webex Calling ライセンスには電話番号や内線番号などの特定のフィールドが必要です。

Webex API を使用して、プログラムでライセンスを割り当て、ユーザーを管理します。

Webex は、ユーザーとライセンスの管理 (People、SCIM 2.0、ライセンス API) 用の API 操作をサポートしており、ライセンス割り当ての自動化に活用できます。ライセンス API を使用すると、ライセンス、電話番号、内線番号を同時に割り当てることができます。

表 5. ユーザープロビジョニングオプション - 概要

割り当て方法	長所	短所
コントロールハブ経由の手動	少数のユーザー向けにシンプルです。 ライセンスの割り当てを正確かつ詳細に制御できます。	拡張性がなく、時間がかかる 手動入力時に人為的エラーが発生しやすくなります。
自動ライセンステンプレート	スケーラブル 手作業によるエラーを削減 新規ユーザーと既存ユーザーに適用できます。	有効な電話番号と場所が必要です。 セットアップがより複雑 また、同等のライセンス要件を持つユーザー グループごとにユーザー グループも必要です。
一括CSVアップロード	大規模なユーザーセットに効率的 ライセンス、電話番号、内線番号を同時に割り当てることができます。	慎重なCSVフォーマットが必要 電話番号または内線番号が欠落しているか間違っている場合、エラーが発生する可能性があります。
APIベースの割り当て	自動化可能、柔軟性あり。 ライセンス、電話番号、内線番号を同時に割り当てることができます。	開発と API の知識が必要です。

表 ユーザー プロビジョニング オプション - 概要 は、ユーザー プロビジョニング オプションとその長所と短所をまとめたものです。この概要は、顧客組織の規模、自動化機能、ユーザー プロビジョニングのプロセスと要件に基づいて、最適なライセンス割り当て方法を選択するのに役立ちます。

可能な限り、シスコではライセンス テンプレートを使用して通話ライセンスを割り当てることを推奨します。これには、固有のライセンス セット (例: Webex Calling Standard と Professional) を必要とするユーザー グループごとに、それぞれのグループ メンバーシップを持つグループが存在する必要があります。 ユーザー グループ セクションで説明したように、ユーザー グループは Control Hub で手動で定義することも、企業ディレクトリから同期することもできます。両方のアプローチを組み合わせることも可能です。

複数のグループに属するユーザーは、すべてのグループに適用されたすべての割り当てからライセンスを取得します。これにより、エンタープライズ ディレクトリ内の Webex Calling ライセンス固有のセキュリティ グループを使用して、Webex ライセンスの割り当てを管理できるようになり、結果として得られるユーザー ライセンスの割り当ては、グループ メンバーシップの結合によって制御されます。

詳細については、 「 Control Hub で自動ライセンス割り当てを設定する 」および 「 Webex Calling ユーザー用の自動ライセンス割り当てテンプレートを設定する」を参照してください。

このセクションでは、Webex Calling 関連のライセンスのみについて説明します。その他のライセンス タイプ (例: Webex デバイス登録、メッセージング、会議) は対象外です。設計プロセスの一環として、ライセンス要件を決定する必要があります。次のライセンス タイプのライセンス数を計算する必要があります。

• Webex 通話標準: 標準的な電話機能を必要とする個々のユーザーの数。

• Webex 通話プロフェッショナル: 高度なテレフォニー機能を必要とするユーザーとワークスペースの数。仮想回線とグループボイスメールには、 1:1 各専門ライセンスの比率。したがって、まれに、必要な仮想回線またはグループボイスメールの数が、高度なテレフォニー機能を必要とするユーザーおよびワークスペースの数を超える場合は、追加のプロフェッショナル ライセンスを考慮する必要があります。

• 共用エリア向け Webex Calling ワークスペース: 標準的な通話機能を必要とする共有使用または共通エリアの場所の数。

• Webex Calling カスタマーアシスト: Webex Calling Customer Assist 機能を必要とするエージェントとスーパーバイザーの数。Webex Calling カスタマー アシストには、Webex Calling Professional ライセンスが含まれています。

• ルートリスト通話: オンプレミスの Unified CM ユーザー間の必要なクラウド接続 PSTN 通話の数 and/or オンプレミスの専門的なサードパーティ アプリケーション。

• アテンダントコンソール: アテンダント コンソール クライアントへのアクセスを必要とする Webex Calling ユーザーの数。

• シスコ通話プラン（発信通話プラン）: PSTN番号を必要とするユーザーの数 and/or Cisco PSTN サービスの発信 PSTN 通話アクセス。

プロフェッショナル ワークスペース専用のライセンス タイプはありません。プロフェッショナル ワークスペースでは、Webex Calling Professional ライセンスが使用されます。

ホットデスクのみのワークスペースでは、ホットデスク ホスト サービスとホットデスク ホストからの緊急通話が提供され、ライセンスは必要ありません。詳細については、 ホット デスク専用デバイスの追加と管理を参照してください。

必要な機能に基づいて各ユーザーおよびワークスペースに必要なライセンス タイプを決定するには、 Webex Calling のライセンス タイプ別に利用可能な機能を参照してください。

Webex Calling プロフェッショナル ライセンスと組み合わせた Webex Calling コール キューによって提供される機能と、Webex Calling カスタマー アシストとを区別するには、 Webex Calling コール キューとカスタマー アシスト機能の比較を参照してください。

Webex のユーザー グループ管理により、管理者はユーザーをグループに編成して、ライセンス、設定、リソースを効率的に一括管理できます。グループは、ユーザーを個別に管理するのではなく、ポリシー、ライセンス、設定テンプレートを複数のユーザーに同時に適用することで、管理を効率化します。

ユーザー グループ管理には次のようないくつかの利点があります。

• 簡素化された管理: 複数のユーザーのライセンス、設定、ポリシーを一度に管理します。

• 一貫性: 同じグループ内のユーザー全体に均一な設定とライセンスを適用します。

• スケーラビリティ: グループごとに最大 250,000 人のメンバーをサポートします。

• 統合: Microsoft Entra ID (Azure AD) または Active Directory からグループを同期して、ユーザーとグループの管理を自動化します。

• 柔軟性: ローカル グループを作成するか、セキュリティ グループを同期します。グループ メンバーシップを手動で、または CSV ファイルを通じて管理します。

• リソース割り当て: グループ メンバーシップに基づいて、埋め込みアプリとサービスへのアクセスを制御します。

Webex Calling をプロビジョニングする際のユーザー グループの主な使用例は次のとおりです。

• ライセンスの割り当て: グループにライセンスを割り当てて、通話、会議、メッセージング、ハイブリッド サービスなどのサービスをグループ メンバーに自動的にプロビジョニングします。

• 設定テンプレート: 一貫したユーザー エクスペリエンスを実現するために、サービス設定のコレクション (メッセージング、会議、通話など) をグループに適用します。

• 一括ユーザー管理: CSV ファイルまたはディレクトリ同期を通じて、ユーザーを一括で追加または削除します。

• 自動化と統合: API またはディレクトリ同期を使用して、ユーザーとグループのライフサイクル管理を自動化します。

次の表は、Webex でユーザー グループとグループを管理するためのさまざまなオプションをまとめたものです。

表 7 グループとグループメンバーシップを管理するためのオプション

オプション	説明	長所	短所
Control Hub グループのプロビジョニング (Webex グループ)	Control Hub で直接グループを作成および管理します。Add/remove メンバーを手動または CSV 経由で追加します。	グループメンバーシップの完全な制御 ライセンスとテンプレートの即時適用 グループの作成と編集が簡単	手動更新が必要です 手動CSVアップロードにおけるエラーのリスク 外部ディレクトリとの自動同期はありません
Entra ID (Azure AD) または Active Directory からの同期されたグループ	外部ディレクトリ サービスからのセキュリティ グループとメンバーシップを自動的に同期します。	自動同期により手作業が削減されます 企業ディレクトリとの一貫性を確保 大規模組織をサポート	コントロールハブでグループメンバーシップを編集できません 同期遅延は最大12時間 ネストされたグループは手動で選択する必要があります
グループと SCIM 2.0 API (Webex グループ)	プログラムによるグループとメンバーシップの管理には、Webex Groups または SCIM 2.0 API を使用します。	自動化と他のシステムとの統合 大規模または複雑な環境に合わせて拡張可能	開発努力が必要 複雑さはAPIの使用状況によって異なります

同期されたグループは一貫性を確保し、単一の管理ポイントを提供しますが、同期されたグループと Webex グループ (コントロール ハブまたは API 経由で管理) を組み合わせたハイブリッド アプローチも可能です。したがって、たとえば、ライセンス割り当て用のグループは同期されたグループであり、別の Webex グループのセットはユーザーと Webex アプリの通話テンプレートの割り当てに使用できます。

Webex におけるユーザー グループ管理に対するこの包括的なアプローチにより、組織はユーザーのライセンス、設定、ポリシーを効率的に管理し、一貫性と拡張性に優れたコラボレーション エクスペリエンスを実現できます。

Unified CM 上のユーザーの主なデータ ソースは、エンドユーザー情報が含まれる Unified CM データベースです。ただし、Unified CM は通常、ユーザー ID 管理の信頼できるソースではなく、さらに重要なことに、移行の終了時にシャットダウンされるため、ID 情報の長期的な信頼できるソースとしては除外されます。

Cisco では、ユーザー ID の唯一の信頼できるソースとして、Microsoft Entra ID (Azure AD) などの集中型クラウド ディレクトリを使用することを推奨しています。Entra ID から Control Hub にユーザーを同期すると、一貫性が確保され、管理が簡素化され、シングル サインオン (SSO) 機能がサポートされます。

Unified CM のすべてのユーザーが Entra ID にも存在することを確認するには、組織は Unified CM のユーザー アカウントが Entra ID のアカウントに対応していることを確認する必要があります。これは、Unified CM からユーザー リストをエクスポートし、Entra ID ユーザー リストと比較することによって実行できます。

要約すると、推奨されるプロビジョニング方法は、Azure AD ウィザードまたは SCIM アプリを使用して、Microsoft Entra ID (Azure AD) から Webex Control Hub にユーザーを同期することです。手動および CSV 一括プロビジョニングは補助的な方法として使用できますが、大規模な組織ではスケーラビリティが低く、エラーが発生しやすくなります。Entra ID が信頼できるソースであり、すべての Unified CM ユーザーが Entra ID 内に存在することを確認することは、Webex Calling と Unified CM 環境全体での移行の成功と一貫したユーザー エクスペリエンスにとって重要です。

Active Directory などのオンプレミスのディレクトリ サービスから Entra ID (Azure ID) などのクラウド ディレクトリ サービスへの移行は、呼び出しの移行とは無関係です。シスコでは、通話の移行を開始する前に、クラウド ディレクトリ サービスへの移行を完了することを推奨しています。

エンタープライズ ディレクトリをオンプレミスからクラウドに移行した後、ライセンスと機能テンプレートの要件に基づいて必要なユーザー グループを収集します。各グループ ドキュメントについて:

• グループ名: グループの一意の名前。

• ライセンス: このグループに割り当てるライセンス（存在する場合）と範囲（ライセンスを既存のユーザーに割り当てるか、それとも新しいユーザーのみに割り当てるか）

• 設定テンプレート: Webex アプリとユーザーの通話テンプレート。

• ディレクトリ同期: このグループはエンタープライズ ディレクトリから同期されますか、それとも Control Hub または API を通じてプロビジョニングされたローカル Webex グループですか。

• 説明: このグループはどのように使用され、どのユーザーがこのグループのメンバーになるべきか

これらの詳細は、実装フェーズで後でローカル グループまたはエンタープライズ ディレクトリ内のグループを作成し、ユーザーのグループ メンバーシップを管理するために使用されます。

Webex を使用すると、組織は複数の IdP を使用して SSO を設定でき、合併や買収、または異なるグループが異なる IdP を使用する分散型 IT 部門などの複雑な IT 環境に対応できます。複数 IdP のサポートは、Webex の複数 IdP 機能を使用するか、Cisco Duo などのエンタープライズ IAM システムの統合を通じて実装できます。

Webex の複数の ID プロバイダー (IdP) サポートは、組織がさまざまな IT 環境にわたって柔軟で安全な認証を必要とするいくつかの重要なユース ケースに対応します。

Duo Access Gateway (DAG) は、Active Directory (AD) や OpenLDAP などの既存のオンプレミスまたはクラウドベースのディレクトリを使用してユーザーを認証できます。また、Microsoft ADFS、Microsoft Azure、Okta、OneLogin、CAS、Shibboleth などの他の ID プロバイダーとの統合もサポートしています。この柔軟性により、組織は Duo MFA を使用した Webex SSO に現在のディレクトリ インフラストラクチャを使用できます。

Duo は、プライマリ ディレクトリ認証の上に強力な認証レイヤーとして機能します。これは、SAML 2.0 を使用して ID プロバイダー (IdP) として機能し、Webex へのアクセスを許可する前に 2 要素認証 (2FA) を強制します。Duo は、設定可能なポリシーに照らしてユーザー、デバイス、ネットワークのコンテキストを評価し、アクセスを許可または拒否することで、ユーザー名とパスワード以上のセキュリティを強化します。Duo は、一部のアプリではログインのたびに MFA を要求し、他のアプリではそれほど頻繁ではないなど、柔軟なポリシー制御も提供します。

Cisco Duo の利点は次のとおりです。

• 強化されたセキュリティ: フィッシング耐性のある MFA を追加して Webex アクセスを保護し、パスワード侵害によるリスクを軽減します。

• 柔軟なポリシー: アプリケーションまたはユーザー グループごとに認証要件を細かく制御できます。

• 既存のディレクトリとの統合: オンプレミスの AD、OpenLDAP、クラウド ディレクトリ、さまざまな SSO プロバイダーをサポートし、インフラストラクチャの変更を最小限に抑えます。

• ユーザーの利便性: シングル サインオン (SSO) をサポートし、ユーザーが一度ログインするだけで複数のリソースに安全にアクセスできるようにすることで、パスワードの負担を軽減します。

• 信頼できるエンドポイント: Windows および macOS 上の Webex クライアントのデバイス信頼をサポートし、セキュリティ体制を向上させます。

• セルフサービス登録: インライン登録とデュオプロンプトにより、MFA セットアップ中のユーザー エクスペリエンスが向上します。

Webex 向け Duo MFA と SSO は、Active Directory や OpenLDAP、クラウド ID プロバイダーなどの既存のディレクトリを活用してユーザーを認証します。Duo の役割は、SAML 2.0 を通じて統合された、ポリシーに基づく強力な第 2 認証要素を提供し、SSO を通じてユーザーの利便性を維持しながらセキュリティを強化することです。メリットとしては、セキュリティ体制の改善、柔軟なポリシーの適用、シームレスな統合、ユーザー エクスペリエンスの向上などが挙げられます。

Cisco では、Webex ユーザー向けに SSO を実装することを推奨しています。セキュリティを強化するには、Cisco Duo との統合をお勧めします。

Unified CM から Webex Calling への移行を開始する前に、エンタープライズ IAM および SSO 戦略を展開する必要があります。

Webex Callingの自動応答機能により、 24/7 着信コール処理の自動化により、人がすべてのコールに応答する必要がなく、効率的なコール処理が可能になります。

自動応答機能は着信に応答し、発信者に通話をルーティングするオプション メニューを提供します。これは、人、ボイスメール ボックス、または通話サービス (コール キューなど) への発信になります。発信者は電話のダイヤルパッドを使用して、自動応答メニューから番号を入力します。

自動応答は次の主要な機能をサポートしています。

• 営業時間と営業時間外のスケジュール

• 休日スケジュール

• 顧客を必要な場所に誘導するためのダイヤルメニューオプション

• 挨拶をカスタマイズする

• 名前でダイヤルするオプション

• 通話転送のオプション

• コントロールハブの分析とレポート。

詳細については、 自動応答の管理を参照してください。

コール パークを使用すると、ユーザーは簡単に通話を 保留 にして、別のユーザーが対応できるときに簡単に通話を取得できるようになります。また、通話が保留されている間に、元の通話に応答したユーザーは他の通話を発信または受信できるようになります。

Webex Calling では、次の 2 種類のコール パークが利用できます。

1. コールパークダイレクト - 管理者によって定義されたとおり、任意のユーザーが他のユーザーの内線またはコールパーク内線に通話をパークできます。

2. コール パーク グループ - 定義されたユーザー グループが、グループに定義された利用可能なパーク先に対して自動的にコールをパークできるようにします。これらの宛先は、グループ メンバーの内線またはコール パーク内線にすることができます。

設定とパークタイプに基づいて、ユーザーは をダイヤルして通話を取得できます。 *88+><extension of parked call>、コールパーク内線に関連付けられた回線キーを押すか、IP 電話のソフトキーを使用します。

指定された期間後に、通話をパークしたユーザーまたは別のユーザーにパークされた通話を呼び戻すためのリコール オプションが利用可能です。

詳細については、 「 Control Hub でのコール パークの管理」を参照してください。

コールピックアップを使用すると、管理者は他のメンバーの電話への通話に応答できるユーザー (メンバー) のグループを定義できます。これにより、チームメイトが忙しくて着信に応答できない場合でも、ユーザーは通話に応答できるようになります。

グループ内のユーザーは同じ Webex Calling の場所にいる必要があります。

ユーザーは、Webex アプリまたはデスクフォンのいずれかを使用して通話を受けることができます。

• Webex アプリ：

  • 視覚的および音声的な通知をサポート

  • 着信通知

  • FACベース（ダイヤル *98) または通知トースト通話ピックアップ

  • 複数回線の通話ピックアップ通知。

• デスクフォン:

  • 着信通知

  • 音声チャイムとハンドセットの LED による視覚的な通知。6821はオーディオチャイムのみをサポートします

    • コントロールハブで選択された通知タイプが なしではない場合

  • 通話ピックアップ通知はプライマリ回線のみに適用されます。

詳細については、 コールピックアップグループの構成を参照してください。

Webex Calling にはコア機能の一部として音声のみのコール キューが含まれており、Webex Calling Professional ライセンスを持つすべてのユーザーがコール キュー、エージェント、またはスーパーバイザーに参加できます。この機能により、ユーザーは顧客と効率的にやり取りできるようになります。コール キューは、音声キュー、コールバック、スキルまたは優先ルーティング、エージェント キュー管理、分析、レポートなどのコール センターのコア機能のサブセットをサポートします。

Cisco の Microsoft Teams 統合の呼びかけにより、エージェントは Microsoft Teams クライアントから直接コール キューの通話や機能にアクセスできるようになります。

コール キューは次の主要な機能をサポートします。

• 挨拶やメッセージ（歓迎、慰め、ささやきなど）

• 保留音

• コールバック

• キュールーティングポリシー（夜間サービス、休日、転送）

• エージェントキュー login/logout

• エージェントキューステータス管理

• Webex アプリまたはデスクフォンのサポート

• スーパーバイザエージェントによる機能アクセスコード（FAC）を介したコール監視、コーチング、割り込み、または引き継ぎ

• コントロール ハブ (管理者アクセス):

  • キュー管理

  • エージェントとキューの分析とレポート

  • キュー、エージェント、スーパーバイザーの管理。

詳細については、 コールキューの構成を参照してください。

Webex Calling には、追加のコール キュー機能を提供し、エージェントとスーパーバイザーに Webex アプリ内でより優れたユーザー エクスペリエンスを提供する Customer Assist アドオン機能があります。Webex Calling のコール キューと顧客アシスト機能の比較については、 Webex Calling のコール キューと顧客アシスト機能の比較を参照してください。

Webex Calling ハント グループを使用すると、事前に定義された通話ルーティング パターンを通じて、着信通話を特定のユーザー グループにルーティングできます。これにより、通話が適切なユーザー グループによって応答されるか、フォローアップのためにボイスメールに送信されるようになります。

ハント グループとコール キューの大きな違いの 1 つは、ハント グループではコールがキューに入れられないことです。そのため、ハント グループ内のユーザーがコールに応答できない場合は、コールが切断されるか、ボイスメールに送信されるか、別の番号 (ユーザーまたはサービス) に転送されます。

詳細については、「 Control Hub でハント グループを管理する」を参照してください。

動作モード機能を使用すると、企業は通話をさまざまな宛先 (ユーザー、ボイスメール、コール キューなどの通話サービス) に効率的にルーティングできます。通話がルーティングされる場所と時間は、時間帯と曜日のスケジュールに基づいて決定され、どのユーザーにもこれらのモード (スケジュール) を管理して通話ルーティングの変更を制御する権限が与えられます。

たとえば、コール キューへの通話を別のコール キューにルーティングして、営業時間外に異なるタイム ゾーンのエージェントが通話に応答したり、営業時間中にローカル エージェントにルーティングしたり、休日中にエージェントがオフィスに戻った後にフォローアップするためにボイスメールにルーティングしたりできます。

承認されたユーザーは、一定期間着信コールのルーティング先を変更する必要がある場合、これらの異なるコール転送シナリオ (モード) を切り替えることができます。これらのユーザーは、 6800/7800/8800 MPP 電話、9800 電話、または Webex ユーザー ハブの 管理モードで確認できます。

詳細については、 Webex Calling の動作モードに基づいた通話ルーティングを参照してください。

ページング グループを使用すると、ユーザーは一方向通話を行って、ユーザー グループに音声メッセージを送信できます。各グループには最大75人の対象ユーザーを含めることができます and/or 事前に定義された番号または内線番号をダイヤルすることでアクセスされるワークスペース。

ユーザーがページング グループに電話をかけると、グループ内の割り当てられたターゲットすべてに同時に電話をかけ、その時点で発信者はメッセージを話し、話し終わったら電話を切ることができます。

詳細については、「 Control Hub でページング グループを構成する」を参照してください。

Webex Calling は、ユーザーが発信または受信した通話の記録をサポートしています。これは、品質、保証、セキュリティ、またはトレーニングのニーズに応じて必要になる場合があります。デフォルトでは、通話は Webex で記録されますが、他の記録機能やコンプライアンスおよび規制要件が必要な場合は、他のサードパーティの記録プロバイダーも使用できます。

Webex を記録プラットフォームとして使用する場合、記録されたすべての通話は Control Hub 内で管理されます。コンプライアンス担当者の役割を持つ完全な管理者は、録画を再生およびダウンロードできます。コンプライアンス担当者の役割がない場合、管理者は録画の削除のみ可能です。

この機能の詳細とサードパーティの録画のリストについては、 Webex Calling の通話録画の管理を参照してください。

単一番号リーチを使用すると、ユーザーの電話番号への通話を複数のデバイスで鳴らすことができます。これには、携帯電話だけでなく他のデスクフォンも含まれます。これらのデバイスから通話を発信することもでき、ユーザーはこれらのデバイス間で通話をプッシュおよびプルできます。

この機能の詳細と、管理者が Control Hub でこの機能を設定する方法については、 「単一番号リーチ (どこからでもオフィス) を構成する」を参照してください。

ユーザーが Webex ユーザー ハブ (ポータル) でこの機能を自分で管理および構成する方法の詳細については、 「単一番号リーチ (オフィスのどこでも) を構成する」を参照してください。

ボイスメール グループを使用すると、ユーザーまたは通話ルーティング機能に割り当てることができる共有ボイスメール ボックスが可能になります。ボイスメール グループが必要になる理由としては、次のようなものが挙げられます。

• 部門またはワークグループ向けの汎用ボイスメール

• 自動応答またはハントグループにボイスメールオプションを追加する

• コールキューからオーバーフローコールを送信する

• ボイスメールボックスのみを必要とするユーザー。

詳細については、 「 Webex Calling の共有ボイスメールと着信 FAX ボックスの管理」を参照してください。

一部のアドオン機能を含むすべての機能の詳細については、 Webex Calling のライセンス タイプ別に利用可能な機能を参照してください。