1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Copilot Studioの新しい顧客対応AIとは? 音声・チャット・有人対応をつなぐ仕組み

1
Posted at

執筆している2026年10月25日時点の情報です。Microsoft Copilot Studio は更新が速い製品のため、最新情報は必ず公開情報(本記事末尾の参考リンク)もあわせてご確認ください。

本稿はMicrosoftの公式ブログと公開ドキュメントをもとに整理したものです。実機検証は行っていません。業務シーン、依頼文、確認項目は説明用の仮想例・筆者の提案です。実在の顧客情報や会話記録は使用していません。

1. チャットで説明したことを、電話でもう一度聞かれる

Webサイトで問い合わせた後、「詳しくは電話で」と案内され、電話口で最初から説明し直す。AIの回答では解決せず、担当者につながったら、また同じ質問をされる。

顧客対応では、一つの質問に答えるだけでなく、会話の流れを保ちながら、必要な情報と担当者へつなぐことが重要です。

2026年10月21日、MicrosoftはCopilot Studioで、Customer Conversation harnessのパブリックプレビューを発表しました。

これは、音声とチャットによる顧客対応を想定した、エージェントの作成・実行の仕組みです。公開ドキュメントでは、この仕組みで作るエージェントをCustomer Assist Agentと呼んでいます。

本稿では、音声・チャット・有人対応をどうつなぐのかを整理します。ただし、すべての機能が全環境で利用可能になった、という発表ではありません。

参考情報

2. この記事で分かること

  • 「ハーネス」とは何か、従来のFAQボットとどこが違うのか
  • 音声・チャット・複数の専門エージェントを組み合わせる考え方
  • 生成AIの柔軟な応答と、決められた手順の使い分け
  • 人間の担当者へ引き継ぐ仕組み
  • 作成・テスト・展開の流れと、権限・費用・プレビューの注意点

主な読者は、問い合わせ窓口やコンタクトセンターのAI活用を検討する方、Copilot Studioの作成者、IT管理者です。

本稿の対象は、Copilot Studioの顧客対応向けの新しい体験です。社内利用者が日々の仕事を委任するCopilot Coworkとは、製品と用途を区別して説明します。

3. 「ハーネス」は、AIが仕事を進めるための実行・制御の仕組み

AIモデルだけで、顧客対応が完成するわけではない

AIモデルが自然な返事を作れても、それだけでは顧客対応の仕組みは完成しません。

たとえば、次のような設計が必要です。

  • 問い合わせの内容に応じて、適切な担当へ振り分ける。
  • 回答の根拠になるナレッジや、業務ツールへ接続する。
  • 必須項目の確認など、守るべき手順を実行する。
  • AIでは対応できない場合、人へ引き継ぐ。
  • 音声とチャットに合った伝え方で応答する。

Customer Conversation harnessは、こうした会話の実行・制御を支える仕組みとして紹介されています。日本語では「顧客対応AIを動かすための土台」と考えると分かりやすいでしょう。

用語を整理する

用語 本稿での意味
Customer Conversation harness 顧客向けの音声・チャット対応を支える実行・制御の仕組み
Customer Assist Agent このハーネスを使って作成するエージェント
プライマリエージェント 顧客を迎え、意図を整理し、専門エージェントへ振り分ける中心役
サブエージェント 請求、技術支援など、特定の仕事を担当する専門役
トピック 決められた流れで処理するワークフロー
エスカレーション AIから人や別の対応先へ引き継ぐこと

公開ドキュメントでは、サブエージェントはプライマリエージェントと構成・展開・ライフサイクル管理を共有すると説明されています。

一方、既存の外部エージェントを接続する方法もあります。たとえばFoundry上のエージェントは、独立した構成やライフサイクル管理を保ったまま連携できます。「複数のAIをつなぐ」といっても、管理の単位は同じとは限りません。

参考情報

4. 音声・チャット・有人対応をつなぐ、四つのポイント

① 同じエージェントで、音声とチャットを設計する

このハーネスで作成するエージェントは、既定でSpeechとChatの両方をサポートすると説明されています。

公式ブログは、チャネルをまたいだ文脈や記憶の維持を特徴として紹介しています。ただし、実際にどの情報を、どの認証・接続条件で引き継げるかは、利用環境で確認が必要です。

また、両チャネルに対応することと、同じ回答をそのまま読み上げればよいことは別です。

チャットでは読み返せる一覧でも、電話では聞き取りにくくなります。音声では短く区切る、日付や確認番号を復唱する、といった設計が必要です。作成画面では、SpeechとChatの指示を分けて設定できます。

② 一つの巨大なAIではなく、専門役に分担させる

公式資料では、プライマリエージェントが問い合わせを分類し、専門のサブエージェントへ振り分ける構成が説明されています。

たとえば、窓口役が「請求についての質問」と判断したら、請求を扱う専門役へつなぐ形です。

専門役ごとに、必要なナレッジやツールを設定できます。ただし、エージェントごとのモデル選択は、発表ブログでは一般提供時の予定です。プレビューで既にすべて選べるとは扱いません。

③ 柔軟に会話する部分と、手順を守る部分を分ける

公式ブログでは、一つのエージェントのスキルに、次のような進め方を組み合わせられると説明しています。

進め方 考え方 筆者が考える用途例
生成型のスキル 指示に沿って、AIが会話や判断を進める 問い合わせ内容を聞き取り、状況を整理する
決定的なスキル・トピック 決められた流れで処理する 必須項目や確認の順序をそろえる

すべてを自由な会話に任せるのでも、すべてを固定メニューにするのでもありません。柔軟性が必要な部分と、手順をそろえる部分を分ける考え方です。

ただし、指示文に「必ず守る」と書くことだけで、権限や業務ルールが保証されるわけではありません。公開前に、期待どおりの処理が実行されたかを確認します。

④ 解決できないときは、人へつなぐ

公開ドキュメントには、標準のEscalateツールとして、次の引き継ぎ先が掲載されています。

  • Teams Phone
  • メール
  • Customer Engagement経由の有人対応

Customer Engagementへの引き継ぎでは、会話全体を対応基盤へ送り、対応可能な担当者が文脈を引き継ぐと説明されています。これは、この経路についての説明です。すべての引き継ぎ先が同一の動作をするとは推測しません。

また、公式ブログにある**Teamsチャットへの直接の引き継ぎは「近日予定」**です。Teams Phoneへの引き継ぎと区別します。

参考情報

5. 仮想例:商品の返品について問い合わせる

ここからは、筆者が考えた架空の設計例です。実際の製品デモや、検証済みの会話結果ではありません。

最初は、公開情報だけを使う範囲から始める

架空の販売会社が、返品に関する問い合わせ窓口を作るとします。

段階 担当する役割 設計例
受付 プライマリエージェント 返品条件の確認か、個別注文の対応かを聞き分ける
一般的な案内 返品案内のサブエージェント 公開の返品規約をもとに、条件と必要な手続きを案内する
個別対応の判断 設定した手順とルール 注文確認や例外判断が必要なら、無理に回答を確定しない
有人対応 接続済みの引き継ぎ先 顧客が希望した場合や、条件に該当する場合に担当者へつなぐ

最初から、返金処理や注文情報の更新まで実装する必要はありません。公開規約の案内と、有人窓口への接続を先に確認する方法が考えられます。

作成時の依頼文の例

次は、作成するエージェントの用途を伝えるための仮想例です。実行結果は未確認です。

架空の販売会社の返品問い合わせを案内するエージェントを作成してください。
公開したサンプル返品規約だけを使って、一般的な条件を説明します。
個別の注文照会、返金、例外承認は行いません。
規約だけで判断できない場合や、利用者が担当者を希望した場合は、
設定済みの有人窓口へ引き継ぐ設計にしてください。
チャットでは要点と参照先を示し、音声では短く区切って説明してください。

この依頼文は設計の出発点です。これを入力しただけで、データ接続・転送先・権限・安全策が完成するという意味ではありません。生成された設定と、実際の動作を確認します。

音声とチャットで、別々に確かめる

筆者としては、少なくとも次のケースを試すことをおすすめします。

  • 規約にある質問に、資料に沿って回答できるか。
  • 必要な情報が足りないとき、推測で結論を出さないか。
  • 担当者を希望したとき、設定した経路へ引き継げるか。
  • 接続先が使えないとき、失敗を明示し、別の連絡方法を案内できるか。
  • 音声で話を遮ったときや、聞き取りを誤ったときに、会話を立て直せるか。

「返事が自然だった」だけで合格にせず、どの資料を参照し、どの専門役やツールを使ったかまで確認します。

6. 作成・テスト・展開の流れ

以下は公開資料に基づく操作の概要です。実際の画面の日本語表記・配置は未検証です。

手順1:Customer Conversationの入口を選ぶ

Microsoft Learnでは、Copilot Studioから作成する方法として、次の入口が案内されています。

  • HomeのOther ways to buildからCustomer Conversationを選ぶ。
  • AgentsでNew agentを開き、Customer Conversationのバッジがあるエージェントを選ぶ。

利用したいシナリオを自然言語で説明するか、空のプライマリエージェントから始めます。生成された名前・説明・指示などは、そのまま採用せず確認します。

手順2:Buildで役割・資料・ツールを設定する

Buildでは、主に次の要素を構成します。

  • 受付役の範囲、口調、振り分けのルール
  • 回答の根拠となるナレッジ
  • 必要なツール、生成型スキル、トピック
  • サブエージェントや既存エージェントとの接続
  • 会話開始・終了・エラーなどのイベント

資料を追加するときは、認証の有無と、音声・チャットのどちらで使えるかを確認します。

手順3:PreviewとEvaluateで確認する

タブ 主な役割
Preview Web ChatやVoice Callで、実際に会話して確認する
Evaluate テストセットを作成・実行し、品質を測る
Deploy SpeechとChatのチャネルへ展開する
Monitor 展開後の会話の状況を確認する

公式のテストガイドは、変更を保存し、シナリオごとに新しいセッションで試すよう案内しています。

Activity mapでは、専門役への振り分け、ツール呼び出し、トピックの実行を確認できます。回答文だけでなく処理の流れを見ることで、指示の問題なのか、接続やツールの問題なのかを切り分けます。

音声は、チャットが合格しても別途テストが必要です。聞き取り、割り込み、無音、数字やコードの読み上げなど、音声固有の失敗があります。

手順4:展開先ごとの条件を確認する

Webや音声チャネルへの展開と、既存コンタクトセンターへの接続は、同じ作業ではありません。

作成ガイドでは、コンタクトセンターへの展開はMicrosoft Contact Center Intelligenceポータルから、Omnichannel Adminが実行すると説明されています。Copilot Studioで作成しただけで、既存の電話設備へ自動的につながるとは考えないでください。

参考情報

7. 導入前に確認したい、認証・管理・費用

音声チャネルは、エンドユーザーのサインインに対応しない

ここは重要な制限です。

Microsoft Learnは、Speechチャネルではエンドユーザーのサインインをサポートしないと明記しています。そのため、利用者本人の資格情報が必要なナレッジソースは、Chatの会話でのみ利用できます。

「チャットで読める資料だから、電話でも同じように読める」とは判断しません。公開情報、接続方式、認証が必要な資料を分けて設計します。

声による本人確認と、ナレッジへのアクセス権は別

標準機能として紹介されるBiometric Authenticationは、音声での本人確認を支援する機能です。Microsoft Contact Center Intelligenceの生体認証などとの連携点として説明されています。

しかし、声で本人確認できることを、Microsoft 365などへのエンドユーザーサインインが利用できることや、任意の資料を参照してよいことに読み替えてはいけません。

利用する場合は、本人確認の要件、同意、音声・声紋情報の扱い、失敗時の代替手段を、組織の担当者と確認することをおすすめします。これは筆者の運用上の提案です。

AIの管理と、会話の取り扱いを決める

公式ブログでは、このハーネスで作るエージェントをAgent 365の管理対象として把握し、所有者・チャネル・ツール・権限・使用状況などを確認する構想が説明されています。

管理画面に表示されることだけで、すべてのリスクが解決するわけではありません。筆者としては、次の事項を展開前に決めておくことをおすすめします。

  • エージェントの所有者と、障害時の連絡先
  • 外部の顧客へ公開してよい情報と、業務ツールの権限
  • 引き継ぐ会話記録の範囲、閲覧者、保存・削除のルール
  • AIでは確定しない判断と、人へつなぐ条件
  • 受付停止や有人窓口への切り替え方法

Microsoft 365 Copilotライセンスだけで、顧客対応が使い放題にはならない

製品固有の費用管理資料は、Customer Conversation harnessで処理する顧客会話がCopilot Creditsを消費し、この利用はユーザーのMicrosoft 365 Copilotライセンスではカバーされないと説明しています。

会話の件数だけでなく、複雑さや、デジタル・音声などの方式によって消費量が変わります。概要・作成資料では、作成・テスト・評価もクレジットを消費する場合があると注意されています。

本番公開前でも、予算と環境へのクレジット割り当てを確認してください。

費用管理では、次の違いも重要です。

  • 環境にクレジットを割り当てるだけでは、必ずしも支出の上限にはならない。
  • テナントの残容量や従量課金から、利用が継続する設定がある。
  • エージェント単位の月次上限には、上限到達時のStop usageを設定する方法がある。
  • Azureの予算・アラートは通知であり、それだけでは利用を止めない。

上限で停止させる場合は、顧客対応も影響を受けるため、代替窓口を用意する必要があります。

参考情報

8. プレビューの提供状況と、未確認事項

「発表された」と「手元で使える」を分ける

項目 参照資料での位置付け
Customer Conversation harness 10月21日にパブリックプレビューを発表。ドキュメントもプレビュー扱い
音声・チャット、専門役、有人引き継ぎ 公開資料に構成・利用方法の説明あり。ただし環境ごとの提供状況は要確認
Teamsチャットへの直接の引き継ぎ 発表ブログでは近日予定
エージェントごとのモデル選択 発表ブログでは一般提供時の予定
関連機能全体 発表ブログは、一部を今後数週間で順次展開すると説明

また、既存のCopilot Studioエージェントが、すべてこの新しいハーネスへ自動的に移行するという意味ではありません。本稿は、新しい顧客対応向け体験の説明です。

公開情報の調査と、実機確認は別

本稿では、次の事項を確認できていません。

  • 利用できる地域・言語・テナント条件の網羅的な一覧と、日本語での実際の応答品質
  • 日本の電話番号の取得・利用条件、通話接続、個別事業者との互換性
  • 作成者・管理者・接続サービスを含む、個別契約のライセンスと総費用
  • チャネルをまたぐ会話・記憶の紐付け条件と保持期間
  • 会話録・音声・声紋情報の具体的な保存場所、保存期間、削除条件
  • 既存環境からの移行方法と、すべての接続先における有人引き継ぎの挙動

エージェントの作成、音声通話、チャット、認証、引き継ぎ、上限到達時の停止も、実機では検証していません。プレビューのため、画面や仕様は変更される可能性があります。

参考情報

9. まとめ:「自然に話せる」だけでなく、「正しくつなげる」を設計する

Copilot StudioのCustomer Conversation harnessは、音声・チャット・業務情報・専門エージェント・人の担当者を組み合わせるための、新しい顧客対応向けの仕組みです。

押さえておきたいのは、次の三点です。

  1. 柔軟な会話と、決められた手順を使い分ける。 すべてを自由な生成に任せない設計ができます。
  2. 音声とチャットは別々に確認する。 伝え方だけでなく、認証や利用できるナレッジにも違いがあります。
  3. AIで完結させることだけを目標にしない。 人への引き継ぎ、権限、費用、停止時の運用まで含めて設計します。

まずは、公開のサンプル情報を使う小さな窓口から始め、回答の正しさと有人窓口への接続を確かめる。そのうえで、接続先や処理範囲を段階的に広げる方法が考えられます。

参考リンク

公開情報の確認日は2026年10月25日です。Microsoft Learnの更新日はページ内の更新日表記(ms.date)を記載しており、機能の発表日・提供開始日ではありません。

資料 提供元 公開日・更新日 主な使用箇所
Introducing the customer conversation harness in Microsoft Copilot Studio Microsoft Community Hub 公開日:2026年10月21日 発表、提供段階、機能の概要、予定機能、Agent 365
Agents powered by the Customer Conversation harness overview (preview) Microsoft Learn ページ内更新日:2026年10月8日 用語、アーキテクチャ、作成画面、認証・クレジットの注意
Create a new agent (Customer Conversation) Microsoft Learn ページ内更新日:2026年10月22日 作成手順、サブエージェント、コンタクトセンターへの展開
Preview and test an agent (Customer Conversation) (preview) Microsoft Learn ページ内更新日:2026年10月8日 音声・チャットのテスト、Activity map、確認の進め方
Add knowledge to an agent (Customer Conversation) (preview) Microsoft Learn ページ内更新日:2026年10月22日 ナレッジの認証、SpeechとChatの制限
Prebuilt contact center tools (Customer Conversation) (preview) Microsoft Learn ページ内更新日:2026年10月8日 Escalateの経路、会話の引き継ぎ、音声の本人確認
Manage costs for agents powered by the Customer Conversation harness Microsoft Learn ページ内更新日:2026年10月13日 ライセンスでカバーされない利用、クレジット、上限と通知

本記事について

本記事は、公開情報をもとに内容を整理し、できるだけ分かりやすく解説することを目的として作成しています。記載内容は個人の見解であり、所属組織の公式見解を示すものではありません。少しでもお役に立てればうれしいです。

ご質問・追記要望は本ページのコメント欄までお寄せください。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?