通話を途切れさせずにCCaaSへ移行する方法：2026年の7ステップ計画

要点

通話を途切れさせずにCCaaSへ移行するには、まず既存の番号からクラウドプラットフォームの新しい番号へ転送し、番号ポータビリティは最後に行います。番号移転前の作業はすべて、設定を変更すれば元に戻せます。完了した番号移転は戻せません。また、米国での番号移転には、書類が正しくそろってから2 to 4 weeksかかります。そのため、既存システムで大半の通話を処理している間に、棚卸し、再構築、予備番号でのテスト、1つのキューでの試験運用を進めます。

多くの計画ではサポート側が見落とされています。ヘルプデスク自体は移動しませんが、電話との接続は変わります。eeselのAIヘルプデスクチームメイトはヘルプデスク内で動作するため、切り替え中もチケットへの回答を続けます。

このガイドの対象者（と最初に必要なもの）

このガイドは、カスタマーサポートの電話回線をオンプレミスPBXや従来のコールセンター技術基盤から、クラウド基盤（CCaaS、Contact Center as a Service）へ移行するサポート責任者や運用責任者向けです。対象にはAmazon Connect、Genesys Cloud、Talkdesk、Five9、Zendesk Talk、Aircall、Twilio Flexなどが含まれます。まだプラットフォームを選んでいる段階なら、私がまとめたコールセンターソフトウェアの記事で有力候補を紹介しています。Freshdeskを利用している場合は、組み込みのFreshdesk Contact Centerも選択肢です。より軽量な選択肢については、DialpadとAircallの代替サービスの記事で取り上げています。この記事では、移行作業そのものを扱います。

私はeeselのエンジニアで、毎週の仕事の大半を連携機能に費やしています。つまり、他社のヘルプデスクや電話のAPIを扱う時間が多いということです。そこで目にするパターンは共通しています。電話システムにはプロジェクト計画が用意される一方、電話システムからヘルプデスクへの接続は「連携」という1行で済まされます。切り替えが気づかないうちにうまくいかなくなるのは、この接続部分です。

AIエージェントも運用している場合、eesel CLIは、移行中にエンジニアがスクリプトで操作できる別の入口になります。Claude CodeのようなAIコーディングエージェントを使えば、承認済みのナレッジ（エクスポートしたヘルプ記事、マクロ、新しいIVRスクリプト）をアップロードし、エージェントにテスト用の質問をして、本番稼働前に回答を確認できます。ただし、ヘルプデスク自体の接続には、管理者権限を持つ人による承認が必要です。

ステップ1の前に、以下を用意してください。

• すべての通信事業者について、電話料金請求書またはCustomer Service Record（CSR）のコピー。番号移転の書類は、その内容と完全に一致している必要があります。
• 署名できる通信事業者アカウントの責任者。AWSはLOA（委任状）に手書きの署名を求めており、大半の通信事業者は電子署名を受け付けないと説明しています。
• ヘルプデスクとCRMの管理者権限。これらを再接続するために必要です。
• 新しいプラットフォームと比較する基準となる、直近90日間の通話レポート（時間帯別の通話量、放棄率、処理時間）。

なぜ今、これほど多くのコンタクトセンターが移行しているのでしょうか？

多くのチームにとって、移行は任意ではありません。主要なオンプレミスのコンタクトセンター製品はベンダーサポートの終了を迎えており、英国では銅線電話網の廃止が進んでいます。以下は、ベンダーや規制当局自身のページに掲載されている日付です。

こうした期限が移行の理由なら、期限から逆算し、通信事業者側の手続きを早めに始めてください。AWSは、通信事業者が祝日や保守期間中に番号移転を停止するため、"several months before pending go-live dates"に番号移転リクエストを開始する必要があると説明しています。

元に戻せない唯一のステップは何でしょうか？

番号移転です。CCaaS移行のほかのステップはすべて、元に戻せる設定変更です。番号移転では番号が新しい通信事業者へ移り、AWSは完了後について、"the gaining carrier has sole control of the phone number."と明記しています。元に戻すには、新しいLOA、新しい書類、そして新たな番号移転が必要です。

これを踏まえると、作業の順序も変わります。問うべきなのは「いつ切り替えるか」ではありません。「元に戻せない一歩を踏み出す前に、両方のシステムをどれだけ長く並行運用できるか」です。その時間を確保する方法について、AWSとSalesforceは同じ答えを示しています。まず転送することです。

SalesforceのVoiceチェックリストは、番号移転について"is highly regulated, can't be rushed,"と警告し、3つの手順を勧めています。テストと本番運用のために新しい番号を取得し、テストが終わるまで元の番号からその番号へ通話を転送し、その後に元の番号を移転します。AWSの移行ガイドも、同じ転送段階によって"rapid rollback (which depends on a relatively simple change to call forwarding rules) without any dependencies on a carrier."が可能になると説明しています。

転送は無料ではないので、何か月も有効にしたままにしないでください。AWSは、転送中は既存番号への着信、転送のための発信、新しい番号への着信にそれぞれ料金がかかり、すべての通話が発信回線を1つ占有すると指摘しています。私は転送を恒久的な構成ではなく、数週間の保険として扱っています。

ステップ1：既存システムの動作を棚卸しする

移行時の想定外の問題の多くは、誰も記録していなかった既存システムの動作から生じます。これは、チームがヘルプデスクを切り替える際に学ぶ教訓と同じです。何かを設計する前に、すべてを一覧にしてください。

特に注意すべき項目が2つあります。1つ目はSMSです。Genesysは、移転する番号のSMSについて、"will not be automatically transferred along with voice service. In fact, the SMS services will likely be disrupted."と警告しています。サポート番号から注文のテキスト通知や予約リマインダーを送っているなら、今のうちに要注意項目として挙げてください。2つ目は、社内システムを呼び出すIVRのステップです。たとえば「アカウント番号を入力してください」という案内に続いてデータベースを照会する処理が該当します。このロジックは新しいプラットフォームで再構築する必要があり、何年も誰も開いていないフローの中にあるため、見落としがちです。

ステップ2：新しい構成を設計する（コピーせず、再構築する）

通話フローはプラットフォーム間でそのまま移せません。Amazon Connectのコンサルタントは、Hacker Newsで端的に述べています。

"when someone designs a call center with Amazon Connect, they use a GUI flowchart tool and create "contact flows". You can export the flow to JSON. But it isn't portable to other environments without some remapping."

raw_anon_1111、Hacker News

どうせ再構築するのですから、シンプルにしましょう。AWS自身のガイダンスは、既存コールセンターをそのまま移すだけに"don't limit yourself"と述べており、Salesforceはデフォルトのコンタクトフローから始めて作り上げることを勧めています。2014年には理にかなっていた7階層のIVRも、通常は3つの選択肢とコールバックにまとめられます。Zendeskを利用しているなら、私のZendesk Talk IVRガイドで、無駄のない電話メニューの構成を紹介しています。

従来のIVRが担っていた仕事の一部は、今ではAI電話受付が担えます。発信者がキューに入る前に、簡単な質問に回答できます。

このステップで決める設計上の事項は2つです。

1. 新旧システムをどう共存させるか。 担当者は通常グループごとに移行します。AWSは移行段階が"might take several months,"と指摘しており、その間は異なるプラットフォームのチーム同士で通話を転送します。AWSは、プラットフォーム間の転送を個別に測定できるよう、プラットフォーム間に専用の転送番号を設けることを提案しています。
2. 過去の録音をどう扱うか。 AWSは2つの選択肢を示しています。録音とレポートを移行する（まず音声形式を確認してください）か、最低保持期間が終わるまで既存の場所でアーカイブするかです。アーカイブのほうが安く済むことが多いものの、旧アーカイブへのアクセスには責任者が必要です。

新しいプラットフォームには、本格的な管理スキルが必要になると考えてください。同時にZendeskからも移行するなら、私のZendesk移行ガイドでチケット側を扱っています。G2でGenesys Cloud CXをレビューしたシニア電話システムエンジニアは、次のように書いています。

"Genesys Cloud CX is extremely capable, but that capability comes with complexity. There are many situations where something that appears relatively straightforward ends up requiring Architect customization, Data Actions, APIs, or external automation."

Justin H.、シニア電話システムエンジニア、G2レビュー

これはGenesysを含む、大半のエンタープライズ向けCCaaSプラットフォームに当てはまる妥当な見方です。再構築のためのエンジニアリング工数を確保し、身動きが取れない状況に陥らないようにしてください。AIツールに当てはまるベンダーロックインの落とし穴は、電話プラットフォームにも当てはまります。

ステップ3：ヘルプデスク側を再接続する

多くの計画では、このステップが1行に圧縮されています。私なら、皆さんが思う以上に時間をかけるところです。電話システムは移動します。ヘルプデスク、ヘルプセンター、マクロ、CRM、AIエージェントは元の場所に残ります。電話は移動しますが、電話とヘルプデスクの間の接続は再構築しなければなりません。そのすべてに再テストが必要です。

特に次の3つの接続を確認してください。

• 通話のチケット記録。 すべての通話でヘルプデスクのチケットが作成または更新され、録音と発信者が紐づいていますか？ CloudTalkとZendeskのように、ヘルプデスクと連携する電話ツールへ移行するなら、実際の通話でチケットがどう表示されるかをテストしてください。
• 発信者のスクリーンポップ。 電話が鳴ったとき、担当者には顧客レコードが表示されますか？ これは発信者番号の形式がCRMと一致しているかどうかに依存することが多く、その形式は通信事業者によって変わります。
• レポート。 処理時間と放棄率の算出方法は、プラットフォームごとに異なります。Genesys CloudのG2レビュアーは、カスタムレポートを"difficult to navigate."と評価しています。本番稼働前に経営層と新しい定義に合意しておかないと、最初の月次レポートが、実際にはそうでないのに大失敗のように見えてしまいます。

次に、ヘルプデスクの自動化が通話チケットに対して何をするかを確認してください。見落とされがちな細部ですが、適切に運用されているAI環境では、電話チケットを意図的に対象外にしていることがよくあります。2つのZendeskアカウントを運用するレッスンブランド群のLesson Proでは、eeselが月に1,900件のチケットにメモや下書きを残しますが、ボイスメールには手を付けません。Gorgiasを使うLuxedoでは、電話チケット、スパム、アンケートをエージェントの対象外にし、それらに費用をかけないようにしています。新しい電話プラットフォームが通話チケットに付ける名前やタグが以前と異なると、これらのルールは気づかないうちに機能しなくなり、突然AIがボイスメールの文字起こしへの返信を下書きし始めます。通話チケットを条件に絞り込むトリガー、ビュー、自動化を確認してください。

良い点は、メールやチャットのサポートが電話プラットフォームにまったく依存しないことです。ヘルプデスク内で動作するAIエージェントは、移行の全期間を通じて働き続けます。ドイツのローン比較会社smavaは、2つのブランドで共有する1つのZendesk上でeeselを運用しています。1か月で27,000件のチケットを処理し、14,600件を分類し、15,300件の返信下書きを作成しています。このようなキューにとって、電話がどの通信事業者につながっているかは関係ありません。

SamCartも、Freshdeskで同様の運用をしています。1つのエージェントがFreshdeskのチケットを処理し、別のエージェントがWebサイトのチャットを担当するため、テキストによるサポートには独立した経路があります。

ステップ4：予備番号でテストする

一時的な番号で新しい環境を構築し、顧客からの通話が1件でも入る前にテストします。AWSの本番稼働チェックリストでは、対象となるすべてのサービス回線について、一時的な電話番号を使って"successfully run UAT scripts"を満たすよう求めています。

テストスクリプトは、まず障害時の動作を軸に書き、その後に正常系を書いてください。

大規模なテストの前に、容量制限も確認してください。AWSによると、新しいインスタンスは"10 concurrent calls or 5 phone numbers"という低いクォータで始まる場合があるため、早めに引き上げを申請してください。また、担当者が実際に使う環境でテストしてください。AWSはBluetoothよりも有線USBヘッドセットを推奨し、有線Ethernetも勧めています。また、移行開始前にドングルの予算を確保することを提案しています。

ステップ5：転送を使って1つのキューで試験運用する

リスクの低いキュー（一般的な問い合わせ、社内IT窓口、小規模な地域など。IT窓口の特性が異なる理由は、私のコールセンターとサービスデスクの比較記事で説明しています）を選び、その番号を新しいプラットフォームへ転送します。請求窓口のように、通話量が多く重要性も高い回線は、試験運用が問題なく進むまで既存システムに残してください。

開始前に、ロールバックの条件を数値で決めてください。AWSの本番稼働チェックリストは、応答した通話数、放棄率、平均処理時間、キュー内の待機数をリアルタイムで監視し、"until go-live (or rollback) activities have been completed."まで会議回線を開いておくよう指示しています。私なら「放棄率が90日間の基準値の2倍を超える状態が1時間続いたら、転送設定を元に戻す」といった条件を書き、その判断を下す権限を誰が持つかについて合意します。

その後、残りのキューをグループごとに移行します。AWSは、2つのプラットフォームの並行運用期間には費用がかかり、長引くほど"the risk of human errors such as making changes on the wrong platform."が高まると説明しています。ゆっくりではなく、着実に進めてください。

ステップ6：番号を移転する

すべてのキューが転送先の番号で問題なく稼働したら、元の番号を移転します。主要プラットフォームが示す所要期間は次のとおりです。

法令上の所要期間は、これらのどれよりも短く定められています。米国では、FCCが単純な番号移転を1営業日以内、単純でない番号移転を4営業日以内に行うよう義務付けています。ただし、トランク上にまとめられたコンタクトセンターの番号群が「単純」に該当することはまれです。表にある数週間は、実際の切り替えに伴う書類手続き、検証、日程調整にかかる時間です。

番号移転がつまずくのは書類手続きです。AWSは、よくある4つの却下理由を挙げています。未払い残高や転出手数料、CSRと一致しない名前や住所、移転できない番号、署名などの情報の欠落です。LOAが却下されると"resets the porting timelines."となります。また、AWSはLOAの日付が直近15日以内であることを求めているため、1か月前に署名しないでください。

見落としがちなルールが、さらに2つあります。

1. 既存の通信事業者を早まって解約しないこと。 FCCは、既存サービスを終了する前に新しい事業者で番号移転を開始するよう勧めています。Aircallは、解約済みアカウントの番号が永久に失われる可能性があると警告しています。
2. キャンセル可能な期限を把握すること。 AWSでは、キャンセルまたは日程変更に5営業日前の通知が必要です。番号が新しいRespOrgに移った時点で、"the port is complete."となります。

番号移転当日について、AWSは、関係していない通信事業者も含めて事業者間の経路が更新されるため、番号移転は"can be disruptive"であり、安定するまで"in rare cases it can take several hours"と警告しています。通話が少ない平日の午前中に番号移転を行い、担当者を両方のシステムにログインさせ、既存プラットフォームへの通話が減っていくのを監視し、すべてのフローにテスト通話をかけてください。

ステップ7：安定させてから既存システムを停止する

番号移転の翌日に既存PBXを廃止しないでください。レポート（とコールセンターのROIの数値）を比較でき、争いが起きた際に過去の録音を取り出せるよう、丸1請求サイクルと、少なくとも1回の繁忙期を通じて稼働させておきます。費用が重複することを経理に伝えてください。AWSは、新しいコンタクトセンターが本番稼働して初めて、AWS側の請求が増え、旧システム側の費用が減ると指摘しています。

AWSは、技術以外の抜けも指摘しています。"user training, process changes, and service desk changes are often overlooked until the project is close to completion."。既存システムを停止する前に、社内ITまたはサービスデスクが、新しいプラットフォームの責任者とインシデントの起票方法を把握していることを確認してください。AWSは、テスト用のインシデントを起票し、最後まで追跡することを提案しています。

911とリモート勤務の担当者はどうすればよいでしょうか？

米国では、これはあると便利な機能ではなく、法的要件です。Kari's Lawに基づき、2020年2月16日より後に設置されたすべての複数回線電話システムは、新しいクラウド環境も含め、「9」のようなプレフィックスなしで911へ直接発信できなければなりません。また、通知を確認する可能性が高い人に、折り返し番号と所在地を含む通知を送る必要があります。

在宅勤務の担当者には、より厳しい所在地のルールが適用されます。47 CFR 9.16に基づき、事業所外で使用するデバイスは、技術的に可能な場合、出動先を特定できる所在地（検証済みの住所）を自動で提供する必要があります。それができなければ、ユーザーが手動で更新する所在地を提供しなければなりません。実務上、私はこれを次のように捉えています。在宅担当者全員の住所を収集し、転居した際に簡単に更新できる方法を用意し、地域の緊急サービスのテスト手順に従って911への通話経路をテストします。ソフトフォンがこれにどう対応するかは、本番稼働後ではなく、その前にCCaaSベンダーへ確認してください。

切り替え準備チェックリスト

完了した項目にチェックを入れてください。すべてにチェックを入れられないなら、まだ番号移転の日ではありません。

CCaaSへの移行にはどれくらいかかりますか？

1か国で1社の通信事業者を利用するチームなら、2から3か月が現実的な計画です。棚卸しと設計に数週間、再構築とテストに数週間、試験運用を行い、それと並行して番号移転の書類手続きに2 to 4 weeksかかります。複数の国が関わると、期間は延びます。AWSは米国とカナダ以外の番号移転に2から6か月と示しており、10を超える番号範囲または10を超える拠点については、アカウントチームの関与が必要な"a project"として扱います。

ヘルプデスク側は、はるかに速く進められます。それこそが、切り離しておく意味です。ヘルプデスク内で動作するAIエージェントは、電話の移行を待ちません。Luxedoは7月にeeselをGorgiasへ接続し、8月にナレッジと指示を構築し、8月最終週にトリガーを有効にしました。すべてGorgias上で行っています。私のAIサポート導入タイムラインでは、多くのチームが2から8週間で導入できる理由を詳しく説明しています。

電話の移行中にeeselを試してみませんか

CCaaSへの移行中の数か月は、サポートチームにとってストレスの多い期間です。担当者は新しいソフトフォンの使い方を学び、試験運用中のキューは不安定で、経営層はなぜレポートが変わったのかを知りたがります。そんなときに、メールやチャットのキューまで積み上がるのは避けたいところです。eeselのAIヘルプデスクチームメイトは、既存のヘルプデスク（Zendesk、Freshdesk、Gorgiasなど）に加わり、ヘルプセンター、マクロ、過去のチケット（電話担当者が使うのと同じナレッジベース）から学習し、返信を下書きしたり実際に回答したりします。そのため、電話を移行している間もテキスト対応のキューを落ち着いた状態に保てます。誰かに返信する前に、過去のチケットでシミュレーションできます。料金ページに掲載されているプランは、500件のチケットで月額$299からです。

100クレジット付きでeeselを無料で試すことができます。切り替えに合わせた計画づくりのサポートをご希望なら、デモをご予約ください。