--- title: "コールセンターの生成AIとは？通話要約・回答候補・RAGの業務適用と誤回答対策" url: "https://www.issoh.co.jp/column/details/19113/" published: 2026-10-31 updated: 2026-10-31 categories: ["DX"] publisher: "株式会社一創" --- # コールセンターの生成AIとは？通話要約・回答候補・RAGの業務適用と誤回答対策 コールセンターで生成AIが受け持つ仕事は、通話の要約、応対中の回答候補の提示、RAGによるナレッジ検索、FAQやトークスクリプトの下書きの4つに整理できます。どれも文章を「作る」機能なので、従来の音声認識や感情分析と違って誤った内容を書く可能性を前提に設計しなければなりません。この記事では、要約の出力項目とCRMへの書き戻し、回答候補の誤りを顧客へ出さない仕組み、通話データを生成AIへ渡すときのクラウド各社のデータの扱いを公式ドキュメントに沿って確認します。PoCから本番までの進め方と、生成AIを入れても効果が出ない窓口の条件も示します。 ## まとめ：コールセンターの生成AIは要約の下書きから入り、顧客へ直接出さない 最初に載せる業務は、通話後の要約です。オペレーターが下書きを直して保存する形にすれば、誤りは人の確認で止まり、後処理時間（ACW）の短縮という効果も測りやすくなります。回答候補とRAGは、ナレッジが更新されている用件に限って、オペレーターが読み上げる前に確認する使い方から始めます。 通話データには氏名や契約内容が含まれるため、利用するクラウドがプロンプトを学習に使わないこと、保存される条件、マスキングとの組み合わせを契約前に確かめます。ACWがもともと短い窓口や、ナレッジが文書になっていない窓口では、先に別の手当てをするほうが成果に結びつきます。 ## コールセンターで生成AIが担う4つの用途と、従来のAIとの役割の違い コールセンター向けのAI全体の地図は[コールセンターAIの5つの適用領域と導入順序](https://www.issoh.co.jp/column/details/18137/)で整理しています。ここでは、そのうち生成AIが入る部分だけを取り出します。 ### 音声認識や感情分析は判定する層、生成AIは文章を新しく作る層という違い 音声認識は聞こえた音を文字にし、感情分析は発話を「怒り」「安心」などに分類します。出力の候補が決まっているため、誤りは「聞き間違い」「分類違い」の形で表れます。 生成AIは、文字起こしやナレッジを材料に、元のどこにも書かれていない文章を組み立てます。要約に顧客が言っていない約束が入る、回答候補に存在しない手数料が書かれる、といった誤りが起こりうるのはこのためです。導入の設計は、この誤りをどこで止めるかから考えます。 ### 通話要約と回答候補はCTI製品やクラウドの標準機能として提供されている 通話要約は、すでに大手のコンタクトセンター基盤に組み込まれた機能です。Amazon Connectの[生成AIによる通話後要約](https://docs.aws.amazon.com/connect/latest/adminguide/view-generative-ai-contact-summaries.html)はAmazon Bedrock上に構築され、オペレーターがACWを終えるために画面で要約を確認する使い方が想定されています。開発者がAPIから要約を取り出して他のシステムへ渡す経路も用意されています。 Google Agent Assistの[料金表](https://cloud.google.com/agent-assist/pricing?hl=ja)では、文字起こしと要約を含む音声要約が1分0.02米ドル、チャット要約が1件0.006米ドルです。データストアを使う生成ナレッジ支援は、リクエスト1件0.012米ドルで課金されます（いずれも2026年10月時点の公表値）。自前でLLMを組む前に、使っている基盤の同梱機能で足りるかを確かめるのが順当です。 ### FAQとトークスクリプトの下書き生成はSVの作業時間を減らす裏方の用途 通話の外側でも生成AIは働きます。似た問い合わせの通話記録を束ねてFAQの質問文と回答案を作る、新商品の説明資料からトークスクリプトの初稿を作る、通話記録からSVの評価コメントの下書きを作る、といった用途です。 この領域は顧客に直接届かず、公開前にSVが必ず目を通すため、誤りの影響が小さく済みます。オペレーター向けのツールを入れる余力がない窓口でも、SVの作業から試せます。 ## 生成AIの通話要約を業務に載せる出力項目の固定とCRMへの書き戻し設計 要約の効果は、出力された文章の質より「そのまま保存できる割合」で決まります。ここでは、保存できる要約にするための設計を3点に分けます。 ### 要約の項目はCRMの入力欄に合わせて用件・対応・次の作業に固定する 自由文の要約は読みやすくても、CRMの入力欄に転記する手間が残ります。応対履歴の画面にある項目と同じ単位で出力させれば、オペレーターは確認して保存するだけになります。 | 出力項目 | 書き戻し先の例 | 生成させる際の注意 | | ----- | ------- | ------------- | | 用件の分類 | 問い合わせ種別 | 選択肢の中から選ばせる | | 用件の要旨 | 件名 | 40字程度に収める | | 対応内容 | 応対メモ | 案内した手続き名を含める | | 次の作業 | タスク・期日 | 約束が無ければ空欄にする | | 顧客の要望 | VOC欄 | 発言にない推測を書かせない | 項目を固定する方法の一つは、LLMにJSON形式で出力させ、スキーマで型と必須項目を縛るやり方です。仕組みは[LLMの構造化出力とJSON Schemaによる形式の保証](https://www.issoh.co.jp/tech/details/16322/)で解説しています。書き戻し先のCRMで持つべき項目は[コールセンター向けCRMの機能と選び方](https://www.issoh.co.jp/column/details/15585/)が参考になります。 ### 修正率と採用率を録音済み通話100件で測る受け入れ基準の決め方 要約を本番に出すかどうかは、録音済みの通話で判定できます。100件程度を選び、要約をSVが「修正なしで保存できる」「一部修正」「書き直し」の3段階で評価します。 判断の目安は、修正なしと一部修正の合計が8割を超えるかどうかです。書き直しが2割を超えると、オペレーターは下書きを読む時間と書き直す時間の両方を払うことになり、ACWはかえって伸びます。評価用の通話には、クレームや複数用件の通話を意図的に混ぜてください。簡単な通話だけで測ると本番で数字が崩れます。評価データの作り方は[LLM評価の指標とデータセット設計](https://www.issoh.co.jp/tech/details/16319/)で詳しく扱っています。 ### 要約が生成されない通話を前提にした手入力へ戻す例外時の運用ルール 生成AIの要約は、すべての通話で必ず出るわけではありません。Amazon Connectの[通話後要約のドキュメント](https://docs.aws.amazon.com/connect/latest/adminguide/view-generative-ai-contact-summaries.html)には、要約が作られない理由コードが列挙されています。同時実行数の上限超過（QUOTA\_EXCEEDED）、双方の発話が1回以上ない通話（INSUFFICIENT\_CONVERSATION\_CONTENT）、非対応の言語設定（INVALID\_ANALYSIS\_CONFIGURATION）などです。 運用では、要約が出なかった通話を手入力に戻す手順を先に決めておきます。繁忙時間帯に上限へ達すると、最も忙しいときに手入力へ戻ることになります。席数を増やす前に上限値の引き上げ申請を済ませる、という順番も設計に入れてください。 ## 回答候補とRAGで起きる誤回答を顧客へ届けないための3つの設計 回答候補の誤りは、要約の誤りより影響が大きくなります。オペレーターがそのまま読み上げれば、誤った案内が顧客に届くためです。 ### 回答候補は顧客へ直接出さず、オペレーターが読み上げ前に確認する 最初の段階では、生成AIの出力を顧客と直接やり取りさせません。回答候補はオペレーターの画面だけに出し、採用するかどうかは人が決めます。この形なら、誤った候補は「使われない候補」で終わります。 候補の採用率は、ナレッジの質を測る指標にもなります。採用されない候補が多い用件は、元になる手順書が古いか、そもそも書かれていないことが多いからです。ナレッジの整え方は[コールセンターのナレッジ管理とFAQ集約の進め方](https://www.issoh.co.jp/column/details/15664/)で扱っています。 ### 根拠にしたナレッジの文書名と更新日を回答候補の横に並べて表示する RAGは、質問に近い社内文書を検索してからLLMに回答を書かせる仕組みです。検索した文書の名前と更新日を候補の横に出しておけば、オペレーターは「この案内は昨年の料金表が根拠だ」と気づけます。 根拠を表示できない候補は、画面に出さない設定にします。検索に1件も当たらなかったのにLLMが文章を作ると、もっともらしい作り話になりやすいためです。文書の分割単位や検索精度の上げ方は[RAG構築の手順と精度向上の進め方](https://www.issoh.co.jp/column/details/12920/)を参照してください。 ### 料金・契約条件・法令に関わる質問は生成させずナレッジの原文を表示する 金額、解約条件、約款の条項、法令に基づく説明は、一字違いが苦情や返金につながります。これらの用件では、LLMに言い換えさせず、該当するナレッジの原文をそのまま表示する設定に切り替えます。 生成させる用件と原文を出す用件の線引きは、問い合わせ種別の単位で決めると運用しやすくなります。全体の3割程度の用件を原文表示にしても、残りで要約と候補提示の効果は十分に得られます。 ## 通話データを生成AIへ渡すときの個人情報の扱いとクラウド各社の確認事項 通話の文字起こしには、氏名・住所・電話番号・契約内容が含まれます。利用目的の範囲を確かめる考え方は親記事で触れているため、ここでは利用するサービスの仕様として何を確認するかに絞ります。 ### Azure OpenAIとAmazon Bedrockは入力を基盤モデルの学習に使わない 個人情報保護委員会は2023年6月2日の[生成AIサービスの利用に関する注意喚起](https://www.ppc.go.jp/news/careful%5Finformation/230602%5FAI%5Futilize%5Falert/)で、個人データを含むプロンプトを入力する場合に、提供事業者がそのデータを機械学習に使わないことなどを十分に確認するよう求めています。 主要なクラウドの公式文書には、この点についての記載があります。Microsoftの[Azureが販売するモデルのデータとプライバシー](https://learn.microsoft.com/ja-jp/azure/foundry/responsible-ai/openai/data-privacy)では、プロンプトと出力は他の顧客にもOpenAIにも提供されず、許可なく基盤モデルの学習に使われないという説明です。Amazon Bedrockの[Data protection](https://docs.aws.amazon.com/bedrock/latest/userguide/data-protection.html)では、モデル提供者はBedrockのログや顧客のプロンプトと応答にアクセスできないと説明されています。社内の稟議では、これらの記載を根拠資料として添付すると話が早く進みます。 ### Azureの不正使用監視でプロンプトが保存される条件と変更申請の扱い 学習に使わないことと、保存されないことは別の話です。同じMicrosoftの文書では、不正使用監視の仕組みによって、悪用の兆候が検出されたプロンプトと出力がヒューマンレビュー用に保存されうると書かれています。保存場所は、リソースをデプロイした地域（geography）内です。 管理対象の顧客は不正使用監視の変更を申請でき、承認されると保存とヒューマンレビューは行われません。もう1点、「Global」や「DataZone」の種類でデプロイすると、処理が行われる場所が指定地域の外へ広がります。通話データを国内で処理したい窓口では、デプロイの種類まで確認してください。 ### 要約の前に個人情報をマスキングするときの処理順と要約品質への影響 文字起こしの段階で個人情報を伏せてから生成AIに渡せば、クラウドに届く個人データ自体を減らせます。ただし、伏せ方によって要約の質は落ちます。 Amazon Connectの通話後要約では、項目を選んで伏せる設定（granular redaction）が要約に対応しておらず、選ぶと検出したすべての個人情報が「\[PII\]」に置き換わります。逆に、伏せていない個人情報が多い通話では、Bedrockの安全基準が働いて要約の生成が拒否される場合があります（理由コードFAILED\_SAFETY\_GUIDELINES）。日本語で使えるマスキングの範囲は機能ごとに異なるため、対応言語表で自社の言語と機能の組み合わせを確かめてから設計します。 ## PoCから本番までの進め方、録音100件の検証から全席展開までの4段階 生成AIの導入は、通話の録音を使った机上検証から始めると、席に入れる前に止める判断ができます。PoCで何を決めるかは[AI PoCの精度目標の決め方と本番移行の判断基準](https://www.issoh.co.jp/column/details/16003/)での説明は、PoCで決める内容の整理です。要約の出力設計からCRMへの書き戻し、RAGの構築までを一貫して進める場合は、[生成AI導入支援](https://www.issoh.co.jp/service/ai/genai/)として相談を受けています。 ### 第1段階と第2段階は録音の机上検証と一部の席での要約の試行で効果を測る 1. 録音済みの通話100件で要約を作り、SVが3段階で評価する（2〜3週間） 2. 修正なしと一部修正が8割を超えたら、10席程度で要約の下書きを使い始める 3. 導入前4週間のACWと、試行席のACWを比べる 第2段階では、試行席と試行しない席を同じ時間帯・同じ用件で比べます。新人だけを試行席にすると、要約の効果と習熟の効果が混ざって判断を誤ります。 ### 第3段階の回答候補はナレッジが整った用件の受付だけで採用率を測って試す 回答候補とRAGは、要約で効果が確かめられてから入れます。範囲は、ナレッジの更新日が直近半年以内で、原文表示にしない用件に限ります。評価指標は候補の採用率と、採用した候補に誤りが見つかった件数の2つです。 誤りが1件でも顧客に届いた場合は、その用件を原文表示へ戻し、元のナレッジを直してから再開します。このルールを先に決めておくと、現場が安心して候補を使えます。 ### 第4段階で全席に広げる前に試算する月額費用と固定費の比較による判断 月2万件・平均5分の窓口なら通話は月10万分です。Google Agent Assistの音声要約（1分0.02米ドル）で計算すると月2,000米ドル、為替を1米ドル150円とすれば約30万円になります。これに、CRMへの書き戻しや画面の改修といった連携開発の費用が加わります。 比べる相手はACWの削減時間です。1件あたり1分縮めば月2万分、約333時間になります。この時間の人件費が、利用料と連携開発費の月割りを上回るかで全席展開を判断します。 ## 生成AIを入れても効果が出ないコールセンターと見送りの判断条件 次の条件に当てはまる窓口では、生成AIの導入を後回しにします。費用より先に、効果が出る前提が欠けているためです。 ### ACWが1分未満の窓口では要約を読む時間が削減分を上回るため導入を見送る 用件が定型で、応対履歴が選択肢のクリックだけで済む窓口では、ACWはもともと短くなります。ここに要約を入れると、オペレーターは下書きを読んで確かめる時間を新たに払うことになります。要約が効くのは、自由記述の応対メモに時間をかけている窓口です。導入前にACWの実測値を見て、1件1分未満なら見送ります。 ### 手順が文書になっていない窓口でRAGを先に入れると誤回答が増える RAGは、検索する文書が無ければ何も返せません。ベテランの頭の中にしか手順が無い窓口では、LLMが一般論で穴を埋めた候補を出し、誤った案内の原因になります。この場合はRAGを見送り、通話要約から新人向けの手順書を起こす作業に生成AIを回すほうが成果は出ます。 顧客と生成AIが直接やり取りする構成も、本人確認や契約変更が多い窓口では採りません。電話の入口を自動化する判断は、[コールセンターAIの導入順序](https://www.issoh.co.jp/column/details/18137/)の第3段階で扱っているボイスボットの条件に従ってください。 ## よくある質問 コールセンターに生成AIを入れる際によく寄せられる質問をまとめました。 ### 生成AIの通話要約はオペレーターが確認せずに保存してもよいですか？ 本番の初期は確認を挟むべきです。要約には、顧客が言っていない約束や数字が混ざることがあります。録音100件の評価で修正なしの割合が十分に高く、誤りが出ても影響の小さい用件に限って、確認を省く運用へ段階的に移します。料金や解約条件を扱う用件では、確認を外さないでください。 ### ChatGPTの画面に通話内容を貼り付けて要約させてもよいですか？ 個人向けの画面に顧客の氏名や契約内容を貼る運用は避けてください。入力データの扱いが業務利用向けの契約と異なる場合があり、利用目的や委託先の管理を説明できなくなります。Azure OpenAIやAmazon Bedrockのように、学習に使わないことと保存の条件が文書で示されたサービスを、会社の契約で使う形にします。 ### 生成AIの回答候補で誤りが出たときの責任は誰が負いますか？ 顧客から見れば、生成AIが作った候補でも、読み上げたのが自社のオペレーターなら企業の案内です。誤案内の訂正や返金の対応も企業が引き受けることになります。だからこそ、候補は人が確認してから使う、料金や契約条件は原文を出す、という設計で誤りが届く経路を断っておきます。 ### 小規模なコールセンターでも生成AIは導入できますか？ 席数が10席前後でも、利用している基盤に要約機能が同梱されていれば設定だけで試せます。費用が膨らむのは、CRMへの書き戻しなどの連携開発を伴う場合です。通話量が少ない窓口では、まずFAQやトークスクリプトの下書きといったSVの作業から試すと、開発費をかけずに効果を確かめられます。 ### 生成AIの導入で応対品質の評価はどう変わりますか？ 通話記録から評価コメントの下書きを作れるため、SVが聞ける件数の制約が緩みます。ただし、評価の基準そのものを決めるのは、あくまで人の役割です。評価シートの項目ごとに、どの発話を根拠にしたかを下書きに併記させると、SVは根拠の確認だけで済み、評価の偏りにも気づきやすくなります。 ## 関連記事 - [コールセンターAIとは？5つの適用領域と導入順序・効果測定の指標を解説](https://www.issoh.co.jp/column/details/18137/)：生成AI以外の音声認識・ボイスボット・通話分析を含めた全体像と、効果測定の指標を扱います。 - [コールセンターシステムとは？ACD・IVR・CTIの役割分担と導入順序を解説](https://www.issoh.co.jp/column/details/17492/)：生成AIを載せる土台となるシステム構成を確認できます。 - [AIチャットボットとは？生成AI型と従来型の違い・仕組みと導入判断を解説](https://www.issoh.co.jp/column/details/12927/)：電話以外の窓口で生成AIを使う場合の判断に使えます。 - [コールセンターのナレッジ管理とは？属人化と離職を防ぐFAQ集約と応対品質の高め方](https://www.issoh.co.jp/column/details/15664/)：RAGの検索対象になるナレッジの整え方を解説しています。 - [RAG構築の手順とは？データ整備から精度向上・本番運用までの進め方](https://www.issoh.co.jp/column/details/12920/)：回答候補の精度を左右する検索部分の作り方を扱います。 --- 出典: [コールセンターの生成AIとは？通話要約・回答候補・RAGの業務適用と誤回答対策]()（株式会社一創）