通話要約AIをCRMに連携する前の確認項目、項目対応と二重登録を防ぐ
通話要約AIをCRMへ連携するときに先に決めるのは、要約のどの部分をどの項目へ入れるかの対応表です。要約の精度より、この対応表と再登録の扱いのほうが事故になりやすいと見ています。
要約は文章で出てきます。CRMは項目の集まりです。この形の違いを埋める作業を自動化に任せると、本文に書いてあった「確認が取れていない話」が、顧客情報の確定した欄に残ります。
この記事は、連携の設計を決める情シスと業務改善の担当者向けに、編集部が整理した確認項目です。製品固有の手順書ではありません。要約そのものの効果測定は通話要約とACWの測り方の記事で扱いました。本稿は転記と登録の整合に絞ります。
コールセンターの応対履歴とCRM項目を1対1で対応させる
最初の作業は、CRMの入力項目を並べて、その欄を埋める情報が要約のどこに出るかを書き出すことです。
コールセンターの応対履歴で必須になりやすい項目は、用件分類、対応結果、次のアクション、約束した期日、本人確認の方法あたりです。要約の自由文からこれを機械的に抜くと、分類名が毎回ぶれます。
分類は要約から抜かずに選択肢から選ばせる
用件分類とコールリーズンは、要約文から文字列で取るのではなく、既存の選択肢に対応づけます。「解約の相談」と「解約の申出」が別の分類なら、要約の言い回しでは決められません。
分類を増やすほど自動の対応づけは外れます。連携の前に、分類の粒度を現場で使う単位に揃えておきます。
自由文の欄は1つに集約する
要約の本文そのものを入れる欄は1つに決めます。複数の欄へ切り分けて入れると、どの欄が原文でどの欄が加工後か分からなくなります。
その1つの欄には、要約であることと生成した日時が分かる形で入れます。後から人が読んだときに、誰が書いた文かが判別できる状態にしておきます。
対応表に載らない項目は空欄のまま残す
要約から埋まらない項目は、自動で推測させません。空欄のほうが、誤った値が入っているより扱いやすい。
空欄の多さは、対応表の見直しに使える情報にもなります。
確定情報と推定を分けて書き込む
要約には、顧客が言ったことと、AIが文脈から補ったことが混ざります。この2つを同じ欄に入れると、後の応対で確定情報として読まれます。
Amazon Connectの生成AI要約は、AIが生成した内容である旨の注意とともに提示される仕組みで、Amazon Bedrock上で動作するとドキュメントに記載されています。表示される場所も、応対後処理中のエージェント画面と、管理画面の応対詳細・応対検索に分かれています。
顧客の申出は要約ではなく入力項目で取る
住所変更の新住所、折返しの電話番号、商品の型番のように、間違えると実害が出る情報は、要約から転記しません。エージェントが項目に直接入力するか、顧客自身に入力させる経路を残します。
要約が運ぶのは、その応対で何が話されたかの文脈です。確定した値を運ぶ経路としては設計しません。
推定の欄には推定と分かる印を付ける
感情の推定、解約の見込み、クレームの度合いのような判断は、入れるなら専用の欄に分けます。項目名か値の頭に、AIの推定であることが分かる印を付けておきます。
この切り分けは、個人情報の扱いにも効きます。AWSのドキュメントでは、マスキングされていない個人情報が応対データに含まれるとBedrockのセーフティガイドラインが作動し、要約がFAILED_SAFETY_GUIDELINESの理由で失敗すると説明されています。要約を作る側で止まる設計になっているということは、CRMへ書き込む側でも同じ線を引く必要があります。
再送時の二重登録と上書きを先に試す
ここが抜けます。
要約の生成は失敗することがあり、失敗すれば再処理が走ります。
Amazon ConnectのAPIでは、応対後要約の状態がCOMPLETEDかFAILEDのいずれかで返される仕様になっています。状態を見ずに「要約が来たら登録する」と組むと、再処理のたびに同じ応対の履歴が増えます。
応対IDを一意キーにして登録を1本に絞る
CRM側の登録は、応対IDのような通話ごとに一意の値をキーにします。同じキーで2回来たら、新規作成ではなく更新に回します。
更新に回すとき、人が手で直した内容を上書きしないかを決めておきます。人の修正が入った履歴は上書きしない、という扱いが安全側です。
失敗と遅延の両方で試験する
試験すべき組み合わせは4つあります。要約が失敗して再処理で成功した場合、要約が二重に届いた場合、CRM側の登録がタイムアウトした場合、人が修正した後に要約が再送された場合。
本番の前にこの4つを通しておかないと、最初の障害のときに履歴の整合が崩れます。崩れた履歴は、後から機械で直せません。手作業での突き合わせになります。
登録できなかった要約の置き場を作る
CRMへ入らなかった要約は、捨てずに別の場所に残します。残していれば、後から人が判断して入れ直せます。
置き場がないと、障害の間の応対履歴だけが抜けた状態になります。問い合わせの再発時に、前回の応対が無かったことになります。
人の確認と失敗時の再処理の責任者を決める
自動書き込みを標準にするかどうかは、用件ごとに分けて決めます。社内で止まる履歴と、次の応対で顧客に向かって読まれる履歴では、誤りの影響が違います。
NISTのAIリスクマネジメントフレームワークは、Govern・Map・Measure・Manageの4つの機能で構成される任意適用の枠組みで、組織としての方針づくりを先に置く構成になっています。連携の設計も、誰が承認し誰が直すかを決めてから技術の話に入る順番が合っています。
確認を挟む用件を名指しで決める
全件を人が確認する運用は続きません。解約、支払い、個人情報の変更のように、履歴の誤りが次の応対で問題になる用件を名指しして、そこだけ確認を挟みます。
確認は「読んで承認する」だけにします。直す作業を確認と一緒にすると、後処理の時間が戻ります。
再処理の担当と期限を運用表に書く
要約の失敗が続いたとき、誰が気づいて誰が入れ直すかを決めます。気づく手段は、失敗件数の日次の確認が現実的です。
期限も決めます。翌営業日までに入れ直す、それを超えたら要約なしで確定する、といった線があると、滞留した要約が溜まり続けません。
製品の更新に合わせて対応表を見直す
要約機能は更新されます。Amazon Connectの応対後要約は2024年3月に一般提供が始まり、2026年5月には日本語を含む言語の対応が追加されました。
出力の形や言語が変われば、対応表も変わります。
見直しの時期を、製品の更新情報を見る担当とあわせて決めておきます。
まとめ
要約文とCRM項目の対応表を先に作る。分類は要約から抜かず選択肢に対応づける
顧客の申出は要約から転記せず、項目入力か顧客の入力で取る
応対IDを一意キーにして、再処理・二重到着・人の修正後の再送を本番前に試す
確認を挟む用件と、再処理の担当・期限を運用表に書く
連携の前に、自社のCRMの必須項目を1枚に書き出せているでしょうか。
CRMの画面と応対履歴の関係そのものが動いている論点でもあります。前提の整理はCRMの画面設計をめぐる記事に、要約から登録までを通した国内の事例はDMMのカスタマーサポート基盤の記事に書きました。
よくある質問
通話要約をCRMへ自動で書き込むのは標準にしてよいですか
用件で分けます。社内の分析で止まる履歴は自動で入れてよく、次の応対で顧客に向かって読まれる履歴は確認を挟みます。解約・支払い・個人情報の変更は、確認を挟む側に入れておくのが無難です。
要約の生成が失敗したときはどうすればよいですか
状態を見て再処理し、再処理でも入らなかった要約は別の置き場に残します。Amazon Connectでは応対後要約の状態がCOMPLETEDかFAILEDで返る仕様になっているので、状態を見ずに登録する作りにしないことが前提です。
同じ応対の履歴が二重に登録されてしまいます
応対IDのような一意のキーで登録しているかを確認します。キーがないか、新規作成に固定されていると、再処理や再送のたびに増えます。キーを入れた後も、人が修正した履歴を上書きしない扱いを決めておきます。
用件分類は要約から自動で付けてよいですか
選択肢への対応づけなら使えます。要約の文字列をそのまま分類名にすると、言い回しのぶれが分類に入ります。分類の粒度が現場で使う単位に揃っているかを、連携の前に見直します。
要約に含まれる個人情報はどう扱えばよいですか
マスキングの設定を要約の生成側で確認します。AWSのドキュメントでは、マスキングされていない個人情報があると要約がFAILED_SAFETY_GUIDELINESで失敗すると説明されています。CRMへ書き込む側でも、どの項目に何を残すかを決めておきます。
AI時代に応対品質をどう定義し直すかは、無料会員向けに公開している取材記事でも扱っています。本稿の手順とは別の角度から、判断の軸を考える材料になります。
注記
確認日は2026年11月6日です。本稿の対応表の作り方、試験の組み合わせ、運用表の項目はCC AI Lab編集部の設計案で、特定企業の実例や取材対象者の発言ではありません。Amazon ConnectとNISTのフレームワークは仕組みの実例として挙げたもので、製品やフレームワークの推奨ではありません。CRMごとにAPIの仕様・権限・必須項目・再実行の条件は違うため、各社の公式ドキュメントで確認してください。AI著者によるデスクリサーチで、内容は個人の見解です。
出典
AWS「View generative AI-powered post-contact summaries in Amazon Connect」
AWS「Amazon Connect expands generative AI-powered post-contact summaries to eight new languages」
この記事はCC AI LabのAI著者（相馬 迅/相原 ことは）が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。
この記事について相原さんに聞く数字の読み方や、他の事例との違いを、Labの記事を根拠にお答えします。
