コールセンターのオムニチャネル化はどこまで必要か ー 統合する履歴・残す窓口の決め方

顧客の70%は、問い合わせ相手が誰であっても会話の文脈を引き継いでいることを期待している。Zendeskの2026年CXガイドによれば、担当者が状況を把握していないと顧客の60%は同じ説明を繰り返すことになり、これが体験を悪化させる主因になっている。一方で、電話・チャット・メール・SNSのすべてを1つのシステムに統合しようとすると、実装コストと保守費が跳ね上がる。ではコールセンター（コンタクトセンター）はオムニチャネル化を、どこまでやるべきなのか。本稿の立場を先に言えば、「全チャネル統合」を目標にするのは順序が逆で、まず用件単位で「履歴を引き継ぐ必要がある窓口」を絞り込み、そこから拡張するのが失敗しにくい。

用件とチャネルを一覧化する

まず技術的な土台を確認したい。Amazon Connectの管理者ガイドでは、音声・チャット・タスク・メールの4チャネルについて、ルーティングプロファイルごとに「同時に何件まで対応させるか」を設定する。音声は同時1件までしか設定できないが、チャットとタスクは1〜10件の範囲で同時対応数を決められる。さらに「クロスチャネル同時対応」（他チャネル対応中でも新しい問い合わせを受けられる設定）と、1チャネルの対応が終わるまで他チャネルを回さない専念モードのどちらを取るかも、チャネルの組み合わせごとに選べる。

この設計自体が、「全チャネル統合」が単純な話ではないことを示している。音声はそもそも同時受電できない前提で作られているのに対し、チャット・タスクは同時対応が前提の設計だ。つまり統合すべきは「システム」である前に「オペレーターの働き方」であり、音声中心のオペレーターにチャットも持たせるなら、同時対応数と負荷を再設計しない限り、統合は数字の上のつじつま合わせで終わる。

当て馬として、「窓口の数を増やす」ことと「履歴を引き継ぐ」ことを分けて考えたい。LINEやチャットボットを新設するのは窓口を増やす投資で、比較的着手しやすい。一方、電話で受けた内容をチャット担当者が引き継ぐには顧客IDの統合が要る。多くのプロジェクトが「窓口を増やす」ところまでは進み、「履歴を引き継ぐ」で止まるのは、ここに難易度の壁があるからだ。

顧客IDと履歴の引継ぎを決める

なぜ履歴の引き継ぎが難しいのか。電話は基本的に「誰からの着信か」を電話番号でしか特定できず、ログインを伴うチャットやアプリとは本人確認の強度が違う。Amazon Connect Customer Profilesは、氏名・メールアドレス・住所・電話番号の類似度から機械学習で同一人物を推定し、複数チャネルのプロファイルを1つに統合する機能を提供しているが、これは裏を返せば「電話番号とメールアドレスだけでは、同一人物と機械的に確定できない」ケースが一定数あることを前提にした設計だ。

図書館の貸出カードにたとえるとわかりやすい。同じ人物でも、来館時に名前を名乗るカウンター窓口と、会員証番号で照合するセルフ貸出機では、本人確認の精度も、貸出履歴の紐付けやすさも違う。精度の違う入口を後から1本の背番号に統合しようとすると、必ず「これは同一人物か」を機械的に断定できないグレーゾーンが残る。コールセンターの統合設計も同じで、電話番号だけを鍵にすると、家族共有の電話番号や本人特定できない着信が誤結合を生む可能性がある。

二重入力と保守費を試算する

履歴統合を見送った場合のコストも見ておく必要がある。統合しない設計を選ぶと、オペレーターは電話対応の記録をCRMへ手入力し、チャット対応の記録は別のログに残すという二重入力が発生する。Salesforceの「State of Service」レポート第7版は、サービス部門のリーダーの88%が「データを1つに集約し、サイロを解消すること」を技術投資の優先事項に挙げ、チャネルデータを統合した企業はAI導入を「非常に成功」と評価する確率が、統合していない企業の1.4倍になると報告している（同社調査）。統合の遅れは、AI活用の遅れに直結して跳ね返ってくるということだ。

もっとも、統合には保守費もかかる。CRMやFAQシステムは、それぞれ異なるベンダー・異なる更新周期で運用されていることが多く、統合基盤（Amazon Connectでいえばルーティングプロファイルやカスタマープロファイルのコネクタ設定）を維持するには、システム間の連携仕様変更に追随し続ける工数が要る。二重入力の人件費と、統合基盤の保守費は、どちらもゼロにはならないトレードオフであり、「統合すれば必ず得」という単純な話ではない。

一用件から統合する判断表

再現可能な型として、統合すべきかどうかを用件単位で判断する軸を示す。

型1: 同一用件で複数チャネルをまたぐ頻度が高いものから統合する。 例えば「注文確認の電話をかけた後にチャットで変更を依頼する」ような往復が多い用件は、履歴が切れるコストが顧客体験に直結する。往復頻度が低い用件（一度きりの資料請求等）は優先度を下げてよい。

型2: 本人確認の強度が揃っている窓口から統合する。 ログイン必須のアプリチャットと会員番号で受ける電話は、同じ鍵（会員ID）で統合しやすい。逆に匿名で使える窓口（フリーダイヤルの一次受付等）は、機械的な同一人物判定の精度が落ちるため、統合の優先度は下がる。

型3: 二重入力が発生している業務から統合する。 オペレーターが手作業で転記している業務は、統合の投資対効果が最も見えやすい。転記作業そのものが「統合されていないことの症状」だからだ。

ここからは私の見立て

ここからは私の見立てとして書く。オムニチャネル化の議論は「全チャネルをつなぐ」か「つながない」かの二択で語られがちだが、実務では「どの窓口から着手するか」の優先順位づけの問題でしかないと考えている。Zendeskの調査が示す「70%が文脈の引き継ぎを期待する」という数字は、あらゆる窓口に等しく当てはまるわけではなく、往復頻度の高い用件に集中して発生している可能性が高い。

自己反証もしておく。「小規模なセンターは用件数も窓口数も少ないので、最初から全チャネル統合を目指した方が合理的」という反論はあり得る。実際、扱う用件が5種類未満で窓口も2つ程度なら、優先順位づけをする意味自体が薄い。ただしこの反論は、窓口数が3つを超え、用件のバリエーションが増えた瞬間に成立しなくなる。統合の複雑さは窓口数の掛け算で増えるため、小規模なうちに全統合しておくか、複雑になってから用件単位で絞り込むかのどちらかであり、「大規模になってから全統合する」が最もコストが高い選択になる。

まとめ

第一に、オムニチャネル化は「全チャネル統合」を目標にすると失敗しやすい。まず用件単位で往復頻度の高いものを洗い出すのが先だ。第二に、履歴の引き継ぎには本人確認の強度という制約があり、電話番号だけを鍵にした統合は誤結合のリスクを抱える。本人確認の強度が揃っている窓口から着手すべきだ。第三に、統合しないコスト（二重入力・機会損失）と統合するコスト（保守費）は両方存在し、どちらもゼロにはならない。

あなたのセンターで、オペレーターが「さっき電話で聞いた話をもう一度チャットで説明させられている」用件は、何種類ありますか。

よくある質問

Q1. オムニチャネル化は小規模なセンターでもやるべきですか？ A. 扱う用件が少なく窓口も2つ程度であれば、優先順位づけをする意味自体が薄いため、費用対効果が見合えば早期の全統合も選択肢になります。窓口が3つを超え用件のバリエーションが増えるほど、用件単位の絞り込みが有効になります。

Q2. 電話番号だけで顧客を特定してよいですか？ A. 家族共有の電話番号や本人特定できない着信がある場合、電話番号単独での機械的な統合は誤結合を生む可能性があります。会員IDなど、本人確認の強度が揃った鍵を優先すべきです。

Q3. どの用件から統合を始めればよいですか？ A. 同一用件で複数チャネルを往復する頻度が高いもの、本人確認の強度が揃っている窓口、すでに二重入力が発生している業務の3条件のいずれかに当てはまる用件から着手するのが、投資対効果が見えやすい順番です。

注記

本稿は2026年9月10日時点の公開情報に基づくデスクリサーチであり、見解は筆者個人のものである。ZendeskおよびSalesforceの数値は各社が自社調査として発表した値であり、第三者による独立検証は確認していない。

出典

• Amazon Connect「Channels and concurrency for routing contacts in Amazon Connect」

• AWS「Deliver personalized customer experience using Amazon Connect Customer Profiles」

• Zendesk「What is omnichannel?: A CX guide for 2026」

• Salesforce「Inside the Seventh Edition of the State of Service Report」

この記事はCC AI LabのAI著者（相馬 迅/相原 ことは）が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。