AIで問い合わせを分析しても、何を直すか決まらない。顧客の声と業務記録をつなぐ方法

AIで顧客の声を見つけた後、業務のどこを変えるか

NTTドコモビジネスは2026年9月30日、顧客接点データの分析機能「docomo business ANCAR Insight」の提供開始を発表しました。通話テキストやCRMの応対記録から要望・不満を抽出して可視化し、対話形式で課題要因や改善案を示すとしています。FAQの自動生成は今後の予定で、提供中の機能とは区別が必要です。

こうした分析を導入するとき、担当者が決めたいのは「どの不満が多いか」の先です。説明文を直せば済むのか、受注と出荷の情報が食い違っているのか。確認先が分からないままでは、レポートが増えても改善の発注範囲は決まりません。

本記事では、顧客の声（VoC）と業務記録をつなぎ、次に直す範囲を決めるSHINJIDAIの設計案を紹介します。図・番号・件数は説明用の架空例で、紹介製品の標準機能や当社の導入実績を再現したものではありません。

• NTTドコモビジネスの公式発表（2026年9月30日） →

「問い合わせ3件」が、3つの問題とは限らない

架空の資材販売会社で、A社から納期の確認がメールで二回、電話で一回届きました。三つの連絡はいずれも注文OD-530に関するもので、確認したい内容も同じです。これを別々の不具合三件として数えると、影響する案件の数を取り違えます。

一方、重複として二件を消すと、顧客が三回連絡した負担が見えなくなります。この例は「連絡3件・案件1件・顧客1社」として残し、各連絡から案件VC-051、注文OD-530へたどれるようにします。同じ顧客でも別注文や別の問題なら、別案件として扱います。

電話の記録をまだ取り込めていない期間は、メールだけの結果と明記します。未取込はゼロ件ではありません。複数の分類を一つの連絡へ付ける場合も、分類別件数を足して全連絡数としないよう、集計の単位を先に決めます。

「出荷が遅い」というAIの推定を、事実に置き換えない

VC-051をAIが「出荷遅れ」と要約したとします。しかし、最新の受注記録では納品予定は翌週水曜、顧客が見ている過去の案内は翌週月曜です。予定の変更履歴はあっても、変更を伝えた記録や顧客との合意が見つからない。この段階で確認できるのは、参照している案内が揃っていないことです。出荷そのものの遅延や、通知漏れが原因とまでは決められません。

元の連絡、予定の変更履歴、出荷状況、案内した内容と時点を関連付けます。顧客対応担当が声の意味を確認し、受注・出荷の担当が実際の状態を確認します。記録が見つからない場合は「連絡していない」と断定せず、未確認として次の確認担当を決めます。

NISTの生成AIリスク管理資料は、生成AIが誤った内容や、その内容を正しいと思わせる説明を出力する場合があると整理しています。AIの要約や原因候補は調査の入口にし、投資や顧客への説明に使う事実とは分けて扱います。

件数の多さだけで、改善の順番を決めない

優先順位は、繰り返している案件、業務や顧客への影響、根拠の確かさを並べて判断します。VC-051なら、案内の不一致を確かめる担当と期限を決めることが先です。原因が未確認のまま、大きな出荷システムの改修を発注する必要はありません。

一件でも業務停止や重要な情報の誤送信につながる声は、件数の順位を待たずに責任者へ渡します。一方、件数が多くても説明の不足と確認できた問題なら、FAQや案内文の修正から試せます。改善案ごとに、誰が判断し、何が確認できたら着手するかを残します。

経営会議では、分類の棒グラフだけでなく、代表する元記録、影響する案件、確認済みの事実、未確認事項、次の対応を一緒に見ます。「調べる」「運用を変える」「仕組みを直す」を分けると、調査不足を開発で埋める判断を避けられます。

FAQ、既存設定、連携、追加開発を同じ問題で比べる

顧客の声を分析する製品には、根拠の参照や改善担当への受渡しなどを備えるものもあります。機能がないと決め付けず、今の製品と契約で、元の声・業務の事実・改善の判断をどこまでつなげられるか確かめます。

VC-051を確かめた結果、案内の更新担当だけが曖昧なら運用を整えます。既存CRMに注文番号や確認状態を設定できるなら、その機能を使います。受注・出荷画面を毎回見に行って転記している部分は参照連携を比較し、固有の分類訂正や権限を扱えない場合に必要な画面を追加します。

連絡数が少なく、担当者が代表例を照合できる段階なら、Excelなどで整理して改善を試す方法もあります。最初からAIの導入や全面的な入替えを決める必要はありません。

• 既存ソフトを活かして、改善する範囲を選ぶ →
• 個々の問い合わせを、回答から実際の処理完了まで追う →

分類の訂正と未取込を残し、同じ条件で改善を確かめる

後からVC-051が別の案件と判明したら、関連付けを訂正し、変更前後の理由を残します。分類を直した場合も、過去の集計を黙って書き換えません。適用した分類ルールと対象期間を保存し、新しい基準で比較するなら比較対象の両期間を再集計します。再集計できない場合は、その差を明示します。

取込が途中で止まったときは、どの窓口・期間が未取込かを表示します。同じファイルの再取込で連絡が二重になるケースや、原文を訂正・削除したときの要約・集計の扱いも決めます。実データを渡す前に、必要な項目、利用目的、閲覧範囲、保存や削除、AI提供者での取扱いを確認します。

変更後は、同じ窓口・分類・期間の長さで比べ、受注などの対象業務量も確認します。問い合わせが減っただけで解決とは言えません。同じ案件への再連絡、社内の聞き直し、未解決の残り方を合わせて確かめます。分類が変わっただけの減少や、窓口が利用しにくくなった影響を成果に混ぜないようにします。

• 元記録がない・分類できない場合は、未確認として担当へ戻るか
• 同じ連絡の再取込と、同じ顧客の別案件を区別できるか
• 分類・関連付けの訂正後も、変更理由と集計条件をたどれるか
• 原文の訂正・削除が、保存した要約や集計へどう反映されるか

• 外部のAIへ情報を渡す前に、データの扱いを確認する →

一種類の問い合わせから、発注する範囲と完成条件を決める

最初は「納期の確認」など、一種類の問い合わせ・一つの窓口・確認できる期間を選びます。現在の受付業務を続けながら、担当者が元記録を照合できる量で試します。正常な分類だけでなく、三回の連絡、注文番号なし、取込漏れ、分類訂正を含め、同じ例を候補の製品や支援先で確認します。

完成条件は、きれいな分類グラフが出ることだけではありません。顧客対応担当が元の声を確かめ、業務担当が事実と未確認を分け、改善責任者が次の調査・運用変更・改修を選べることです。これらの判断は社内の誰が担うかを決め、支援側が実装する取込・照合・表示・訂正の範囲と、双方で検証する内容を合意します。

株式会社SHINJIDAIは、業務課題の相談・解決策の提案から設計・開発・導入まで伴走しています。このテーマでは、問い合わせが集まる場所と、会議で判断が止まる場面を確認。既存の運用・設定を使う案と、必要な情報連携・追加開発を比較します。合意した範囲を実装し、未取込や訂正でも根拠に戻って判断できるかを担当者と確かめます。

費用を左右するのは、記録形式と接続先の数、更新間隔、移す履歴、分類の訂正方法、閲覧権限です。AI・製品の継続利用と保守の範囲も分けて確認します。運用開始後の分類ルール、接続先の変更、権限の更新を誰が担い、変更後に誰が同じ例を再検証するかまで決めます。

業務の課題整理から、設計・開発・導入まで

顧客の声を、次の業務改善へつなぐなら、
SHINJIDAIにご相談ください。

• ?問い合わせの集計が、他部署の改善へ進まない
• ?AIが示す原因と、受注・出荷の事実を照合したい
• ?今のCRMやExcelを活かし、必要な連携・開発を決めたい

課題の整理から伴走

繰り返す問い合わせと業務記録、判断が止まる場面を整理します。運用・既存設定・連携・開発を比較し、合意した範囲を実装。未取込・複数連絡・分類訂正でも元記録に戻れ、担当者が次の対応を判断できるかを確かめます。

顧客の声と業務情報の連携を相談する→

初回は、困っている業務と現在の状況の概要で構いません。調査・設計・開発の範囲と費用は、着手前に合意します。

製品の契約・接続可否、データの取扱い、調査・実装・保守の範囲は個別に確認します。

ID・パスワードや顧客データは、フォームに記載しないでください。

課題整理から導入までの進め方を見る →

• 課題整理から設計・開発・導入までの進め方を見る →

出典

確認日：2026年10月1日。NTTドコモビジネスの発表日と提供開始日は2026年9月30日。FAQ自動生成は発表時点の将来予定として区別しています。利用できる入力・連携・分析の範囲は、実際の製品と契約で確認してください。

NIST AI 600-1は2024年7月公表の背景資料です。2.2 Confabulation（本文6頁）を、生成AIの出力をそのまま事実としない理由として参照しています。個々の製品の評価や、ここで示す設計を指定する資料ではありません。

VC-051・OD-530・A社・連絡3件の例と、分類・確認・改善の役割、比較・完成条件はSHINJIDAIの設計案です。製品の性能や効果、実際の顧客事例を示すものではありません。

• NTTドコモビジネス：ANCAR Insight提供開始の公式発表（2026年9月30日） →
• NIST AI 600-1：生成AIリスク管理プロファイル（2024年7月、2.2節） →