Microsoft CCIは何を変えるのか――既存コンタクトセンターにAIを足すときの設計境界

コンタクトセンターのAI導入を考えるとき、最初から電話基盤、顧客管理、オペレーター画面をまとめて刷新する計画にすると、検討すべき範囲は一気に広がります。顧客の待ち時間を減らしたいだけなのに、大規模な移行プロジェクトが先に必要になる。その構図を見直す選択肢が出てきました。

Microsoftは2026年10月21日、Microsoft Contact Center Intelligence（以下、Microsoft CCI）を公開プレビューとして発表しました。Dynamics 365 Contact Centerのエージェント機能などを、既存のコンタクトセンターへ追加する位置づけです。[1]

私がこの発表で注目しているのは、導入範囲を業務単位で切り出せる可能性です。ただし、既存基盤を残すほど、AIと既存システムの間で何を受け渡すのかが重要になります。

本記事では、発表時点の事実を整理したうえで、家電修理の予約変更という架空の業務を使って、その境界を考えます。後半の役割分担やデータ項目は設計上の提案であり、Microsoft CCIの標準実装や実測結果を示すものではありません。

今回の発表で確認できること

公式発表では、Microsoft CCIはオープンコネクタを通じて既存コンタクトセンターへ接続する構成が示され、Five9、Cisco WebEx Contact Center、Avayaが例示されています。顧客対応のCustomer Assist Agent、品質評価のQuality Assurance Agentが説明される一方、Service Operations Agentは今後提供予定です。[1]

ここで、現在使える範囲と将来の構想を分けて読む必要があります。

対象	2026年10月23日時点で、10月21日の公式発表から確認できる状態
Microsoft CCI全体	公開プレビュー。正式提供（GA）の発表ではない
品質評価	過去のセルフサービス会話を評価する機能を説明
リアルタイム評価・コーチング、コンタクトセンターの担当者支援、Service Operations Agent	今後提供予定。現時点の前提機能に含めない

公式記事には、人へ引き継ぐ経路や、決められた手順と生成AIによる対話を組み合わせる考え方も示されています。[1]

ただし、接続先が例示されていることと、自社の構成で業務が完結することは別々に検証します。今回の発表だけで、日本語での利用条件、利用リージョン、既存契約との組み合わせ、自社製品バージョンとの接続可否まで確定したとは扱いません。

「修理予約を変えたい」は、一つの処理ではない

たとえば、冷蔵庫の出張修理を予約している顧客から、次の電話があったとします。

明日の午後に予約していますが、午前中に変えられますか。難しければ、来週の火曜日でも大丈夫です。

自然な会話としては短い依頼です。しかし、業務として見ると複数の判断が含まれています。

対象の予約を特定する。変更できる本人なのか確認する。訪問エリア、修理内容、担当者の条件に合う枠を探す。元の予約をどう保持するか決める。顧客が選んだ枠を確保する。更新結果を確認し、確定した内容を伝える。

このうち、顧客の言い方を理解し、代替案を分かりやすく説明する部分では、会話AIの価値を出しやすいでしょう。一方、変更可能な条件や空き枠の確定は、予約を管理するシステムの責任として残す設計を私は勧めます。

Microsoftが2026年6月25日に公開した音声エージェントの設計ガイドでも、業務システムの情報を根拠にすること、重要な操作の前に内容を確認すること、必要に応じて人へ文脈を渡すことが重視されています。[2]

これを今回の例に当てはめると、要件定義で合意したいのは「自然に予約を変更できる」という一文では足りません。少なくとも、次の責任を分けておきます。

処理	この例で推奨する責任の置き方	完了を判断する根拠
希望を理解する	AIが日時・優先順位を整理し、曖昧な点を聞く	顧客が確認した変更希望
対象と変更権限を確認する	本人確認の仕組みと業務システム	確認結果、対象予約の識別子
候補を出す	業務システムが変更可能な枠を返し、AIが説明する	取得時点の候補と適用条件
変更を確定する	業務システムが条件を再確認し、更新する	更新結果と確定後の予約情報
顧客へ伝える	AIが確定結果を説明する	システムの結果と案内内容の一致

この表は、AIの担当範囲を小さくするためのものではありません。顧客に「変更できました」と約束してよい時点を、関係者全員でそろえるためのものです。

最も厄介なのは、「失敗」より「結果が分からない」状態

予約変更の連携で、私は次の状態を独立して設計します。

更新要求は送ったが、結果を受け取れなかった。

たとえば、予約システムが処理を終えた直後に応答が途切れた場合です。AI側から見るとタイムアウトでも、業務データは変更済みかもしれません。

この状態で、同じ依頼を新しい要求として何度も送ると、実装によっては重複処理が起こります。反対に、すぐ「変更できませんでした」と案内すると、実際の予約内容と顧客の認識がずれる可能性があります。

そのため、連携の設計では、成功と失敗だけでなく、結果未確認を扱うことを提案します。

実装方法は接続先によりますが、一つの変更依頼を識別する番号を付ける、同じ番号の再送を重複処理しない、処理状況を照会できるようにする、といった対策が候補になります。これらをMicrosoft CCIが自動で保証すると解釈せず、接続先APIと連携処理の仕様として確認します。

会話側にも、その状態に対応する案内が必要です。

変更処理の結果を確認しています。現時点では予約の確定状況をご案内できないため、担当者へ確認を引き継ぎます。

ここで大事なのは、流暢な言い換えではありません。業務システム上の確定状態と、顧客に伝える言葉を一致させることです。

また、候補枠を提示したあと、顧客が返答するまでに別の予約が入る場合も想定します。「空きがある」と「確保できた」を別の状態として定義し、最終更新時の再確認や、枠を一時保持する仕組みの有無を詰めておきます。

人へ渡すのは、会話の要約だけでは足りない

Microsoft CCIの発表で人への引き継ぎが示されていても、自社の担当者が対応を再開できる情報まで自然にそろうとは限りません。

「顧客は修理予約の変更を希望しています」という要約だけでは、担当者は最初から聞き直すことになります。さらに、更新の結果が未確認なのに再度変更してしまう可能性もあります。

この例で私が引き継ぎ情報に含めたいのは、次の内容です。

• 対象：問い合わせ番号、対象予約の識別子。
• 確認済みの範囲：本人確認の結果と、その結果で許可される操作。不要な本人確認用の秘密情報は渡さない。
• 顧客の希望：第一希望、代替日、顧客が最後に同意した内容。
• 処理の状態：候補の提示までか、更新要求を送ったか、更新完了を確認できたか。
• 次に行うこと：処理結果を照会する、別枠を提案する、例外承認を受ける、など。

これを、会話ログとは別に業務状態として持つ設計を検討します。担当者が必要な箇所をすぐ確認でき、連携障害の調査にも使えるためです。

Microsoftの2026年5月19日の運用ガイドでも、有人引き継ぎにおける文脈・セッション状態の保持と、本番投入前の検証を重視しています。[3]

コンサルタントとして確認したいのは、「転送ボタンが動くか」だけではありません。引き継いだ担当者が、次の一手を判断できるかです。

最初の対象を「予約変更のすべて」にしない

既存コンタクトセンターへ機能を追加できるなら、導入単位も小さくする価値があります。私なら、今回の業務を次の順で検討します。

最初は、予約日時の照会と変更条件の説明です。更新を伴わない範囲で、対象予約の特定や案内内容の整合性を確認します。

次に、限られた予約種別だけを変更対象にします。たとえば、追加料金がなく、特殊な作業条件もない訪問修理に限定する。対象外の依頼は、人が対応できる既存経路へ渡します。

そのうえで、複数の訪問先を含む予約や、追加費用、担当者の特別な資格など、判断条件の多い業務へ広げます。拡張の順番は、問い合わせ件数だけでなく、更新結果を確かめられるか、例外を処理できるかで決めます。

これは導入の進め方に関する提案です。Microsoft CCIの導入だけで、こうした業務単位の切り替えが自動的に完成するわけではありません。振り分け条件、担当部門、障害時の戻し先まで含めて構成します。

「人につながらなかった」を成功にしない

成否の測り方も、導入範囲と一緒に決めます。

たとえば、人に転送しなかった割合だけを追うと、予約が確定していないまま通話が終わったケースまで、よい結果に見えてしまいます。逆に、必要な情報を整理して適切に担当者へ渡せたケースは、転送が発生していても業務上の価値があります。

この予約変更であれば、私なら「業務システムで変更を確認でき、顧客への案内と一致した件数」を中心に置きます。そのうえで、結果未確認の件数、担当者による修正の発生、同じ予約についての再問い合わせを追います。

対象期間や対象予約種別をそろえ、AIが扱える範囲に入った依頼を分母にすることも必要です。異なる業務を混ぜると、対象を簡単な依頼に絞っただけなのか、体験が改善したのかが分からなくなります。

具体的な目標値は、現行業務の実績を基に決めます。今回の発表から一律の削減率や投資効果を置くことはしません。

既存基盤を生かすなら、境界を業務の言葉で決める

Microsoft CCIの発表は、コンタクトセンターのAI化を、基盤全体の刷新から切り離して検討するきっかけになります。

その選択肢を生かすために、最初の打ち合わせでは「どこまで会話できるか」に加え、次の点を合意しておきたいところです。

何を確認したら処理を開始し、どの結果をもって完了とし、分からないときは誰が引き取るのか。

顧客の希望を理解することと、企業として処理を確定すること。その接点を明確にしておくと、既存システムの強みを残しながら、会話AIに任せる範囲を広げやすくなります。

---

参考情報

製品情報は2026年10月23日に確認。採用した資料はすべて、同日から過去1年以内に公開されたMicrosoftの一次資料です。本文の設計例と推奨事項は筆者の分析です。

番号	一次資料・直接URL	公開日と確認根拠	本文で参照した内容
[1]	Microsoft Contact Center Intelligence: Transforming customer experience at agentic speed	2026年10月21日。記事表示およびページのdatePublishedで確認	公開プレビュー、既存基盤への接続、エージェントの位置づけ、過去会話の評価と今後提供予定の区別
[2]	Building reliable voice agents: A practical guide	2026年6月25日。記事表示およびページのdatePublishedで確認	業務データを根拠にする、重要操作の前に確認する、文脈を伴う有人引き継ぎ
[3]	The in-depth guide to managing real-time voice agents at scale	2026年5月19日。記事表示およびページのdatePublishedで確認	有人引き継ぎの文脈・状態、本番投入前の検証