コールリーズン分析のやり方　問い合わせ理由を分類して電話を減らす4つの手順

コールリーズン分析は、問い合わせの理由を分類して数え、負荷の大きい理由から「そもそも電話が来ない状態」を作るための分析です。手順は4つ。分類表を作る、応対ごとに記録する、件数と処理時間を掛けて並べる、理由ごとに減らす部署を決める。このうち成果を分けるのは最初の分類表で、用件（何を聞かれたか）だけで作ると、集計しても誰が何を直せばよいかが出てきません。分類表には用件と並べて「なぜ電話が必要になったか」という発生源の軸を持たせる、というのが本稿の立場です。

手順1　用件と発生源の2軸で分類表を作る

多くのセンターの分類表は「契約」「料金」「故障」のような大分類と、その下の用件で組まれています。応対の振り返りや研修にはこれで足ります。困るのは削減策を考える段階です。「請求額の確認」が月2,000件あると分かっても、それが請求書の書き方のせいなのか、料金改定の告知不足なのか、顧客の勘違いなのかで、直す場所がまったく違うからです。

そこで、用件とは別に発生源の列を立てます。発生源は「この電話を生んだのは誰の何か」です。

大分類	用件（小分類）	発生源	定義（含む／含まない）
料金	請求額の確認	帳票（請求書の表記）	含む: 請求書の項目の意味を聞く。含まない: 支払方法の変更
料金	請求額の確認	告知（料金改定）	含む: 改定後の金額差を聞く
手続き	住所変更	顧客の事情（避けられない）	含む: 引っ越しに伴う変更。含まない: 誤登録の修正
手続き	住所変更	Web（手続き画面の不具合・分かりにくさ）	含む: Webで変更しようとして失敗した
配送	届かない	業務（出荷遅延）	含む: 予定日を過ぎた問い合わせ
配送	届かない	顧客の事情（避けられない）	含む: 予定日前の確認

※表は分類表の作り方を示す見本です。項目は自社の業務に合わせて置き換えてください。

発生源の値は5〜8種類に絞ると運用できます。目安は、帳票、告知・通知、Web・アプリ、業務（出荷・処理の遅れ）、商品・サービス仕様、顧客の事情（避けられない）、その他。最後の「顧客の事情」は減らす対象ではなく、受けるべき電話としてセンターが品質を上げる側に回します。この線引きが入るだけで、分析の結論が「全部減らそう」にならずに済みます。

定義欄は省略しないでください。「含む／含まない」が書いていないと、同じ電話に人によって違うコードが付き、後の集計がぶれます。

手順2　オペレーターが迷わず選べる形で記録する

分類表ができたら、応対の後処理で毎回付けてもらいます。精度を決めるのは項目数と言葉の揃え方です。

Genesysの後処理コードの指針は、コードごとに「問い合わせ理由」と「解決内容」の両方が分かるようにし、説明は7〜10語程度、細かすぎず曖昧すぎず、全コードを同じ書式で揃え、使われなくなったコードは削除するよう勧めています。同社のAIがコードを推薦する際の精度を上げるための指針ですが、人が選ぶ場合にもそのまま当てはまります。

項目数の上限は、オペレーターが画面をスクロールせずに選べる数が現実的です。編集部は、最初の版は用件30項目以内で始め、「その他」の比率で足りなさを測る運用を勧めます。「その他」が全体の1割を超えたら、中身を読んで新しい項目を足す合図です。最初から100項目を並べると、選ぶのに迷う時間が後処理を延ばし、結局いちばん上の項目か「その他」に寄ります。

もう1つ決めておくのが、改定の作法です。分類を変えると過去と比べられなくなります。消費者庁の消費者白書も、全国の消費生活相談データについて2021年4月の分類改定で、それ以前と時系列で比べられないと凡例で断っています。改定は四半期に1回などと時期を決めてまとめて行い、旧コードと新コードの対応表を残す。これだけで前年比が出せる範囲が広がります。

手順3　件数と処理時間を掛けて並べる

集計は件数だけで並べないことが要点です。センターの負荷は「件数×平均処理時間（AHT、通話と後処理を合わせた1件あたりの時間）」で決まるので、両方を掛けた負荷時間で並べます。

仮の数字で計算例を示します（実データではありません）。

用件	月間件数	AHT	負荷時間（件数×AHT）
住所変更	3,000件	6分	300時間
請求額の確認	2,000件	9分	300時間
ログインできない	1,500件	12分	300時間
解約	800件	15分	200時間

件数順では住所変更が1位ですが、負荷時間で見ると上位3つは並びます。ここで手順1の発生源が効いてきます。住所変更の大半が「顧客の事情」なら減らす対象ではなく、Webで完結させる導線を整える対象です。仮に請求額の確認の6割が「帳票」由来なら、請求書の表記を1か所直すだけで月180時間分（300時間×0.6）の負荷が動く計算になります。

集計の単位は月次で十分です。週次で見ると、キャンペーンや請求サイクルの波に結論が振り回されます。時間帯別の偏りまで見たいときは、呼量予測の側で扱ったほうが早く進みます。

手順4　コールセンターの外にいる持ち主を決める

コールリーズン分析で減る電話の多くは、センターの中では直せません。請求書は経理や業務部門、告知文はマーケティングや広報、Webの手続き画面はデジタル部門の持ち物です。分析結果を報告して終わると、どこも動かないまま翌月も同じ順位表が出てきます。

なので、発生源ごとに持ち主の部署と期限を決め、翌月の件数で効果を確かめるところまでを1サイクルにします。1件の報告に書くのは、発生源、月間件数と負荷時間、代表的な通話の要約2〜3件、直してほしい箇所、効果を測る指標（翌月の同コード件数）の5点で足ります。

電話の前に解決できる用件の割合を数えると、他部署を説得しやすくなります。日刊工業新聞のニュースサイトが2016年11月に報じた例では、年間約150万件の問い合わせが寄せられる三井住友海上火災保険のコールセンターが、AIで過去の応答履歴を分析し、証明書の再発行手続きなど入電前に解決できる内容が照会全体の約70%を占めると把握したうえで、FAQの充実などに取り組んだとされています。参考になるのは70%という数字より、「電話の前に解決できたか」という軸で数え直したことが、FAQやWebの改修を他部門に頼む根拠になった点です。

センター内で直せるものもあります。FAQで解決できるはずなのに電話が来ている用件は、FAQの検索ログと突き合わせると原因が見えます（FAQのゼロ件ログを改善に変える手順）。同じ顧客が短期間にかけ直してくる用件は、1回目の案内に穴があるサインで、再入電の期間を揃えた一次解決率と並べて見ると優先順位が付けやすくなります。

コールリーズンをAIで自動分類するときの注意

通話の文字起こしが揃ってくると、分類をAIに任せたくなります。人が後処理で選ぶより漏れが少なく、全件に付けられるのが利点です。一方で、手作業の分類表とは違う癖があります。

1つめは、AIが拾う話題が「理由」とは限らないことです。Google Cloudのトピックモデリングの解説は、会話の主題を一次（primary）と二次（secondary）に分け、本人確認や確認作業、アンケート依頼のような二次トピックは分析上の価値が低く、より重要な一次トピックを押しのけることがあると書いています。どの通話にも出てくる本人確認が上位に来るのはこのためです。AIが出した話題の一覧は、そのまま使わず人が選び直す前提で扱います。

2つめは、ルールを変えたときの時系列です。Amazon Connectの会話分析ルールは、キーワードの完全一致・パターン一致・意味の一致に加えて、自然文で条件を書いて生成AIに当てはめさせる分類もできます。ただし同社の解説では、ルールは追加した後の新しい問い合わせに適用され、保存済みの過去の会話には適用できません。分類を足した月から数字が出始めるので、「先月より増えた」の比較が成り立たない時期が出ます。手順2の改定の作法は、AIの分類でも同じように要ります。

3つめは、発生源の判定です。用件の分類はAIが得意ですが、「この電話は請求書の表記が原因か」は会話だけでは判定しきれないことが多い。発生源は人が付ける欄として残し、AIには用件の候補を出させる。この分担から始めるのが無理のない順番です。

全件のタグ付けをどう段階的に進めたかは、JR西日本カスタマーリレーションズの事例で、要約AIで作った構造化データを分析基盤につないだ順序として整理しています。

まとめ

• 分類表は用件と発生源の2軸で作る。発生源を持たない分類は、集計しても直す場所が出てこない
• 項目は30以内で始め、「その他」が1割を超えたら足す。改定は時期を決めてまとめて行い、新旧の対応表を残す
• 並べるのは件数ではなく件数×AHTの負荷時間
• 減らす電話の持ち主はセンターの外にいる。発生源ごとに部署と期限を決め、翌月の件数で確かめる
• AIは用件の候補出しに使い、二次トピックの除外と発生源の判定は人が持つ

自社の分類表に、「この電話はどの部署の何が生んだのか」を書く欄はあるでしょうか。

よくある質問

コールリーズンとコンタクトリーズンは違うものですか。

同じ考え方です。電話だけを対象にする場合にコールリーズン、メールやチャットも含める場合にコンタクトリーズンと呼ぶことが多く、分類表は全チャネルで共通にしておくと比較できます。

分類項目はいくつが適切ですか。

オペレーターが迷わず選べる数が上限です。少なめに始めて、「その他」に入った通話を読みながら増やすほうが精度を保てます。

AIで自動分類すれば、オペレーターの後処理入力は不要になりますか。

全部は不要になりません。AIの候補を人が確かめる形にすれば入力の手間は減りますが、電話を生んだ原因の判定は人の目が要ります。

分析結果はどの頻度で報告すればよいですか。

月1回で足ります。改善を頼んだ部署と翌月の件数で結果を確かめる、という周期に合わせるのが続けやすい形です。

---

注記: 本稿は2026年10月16日時点の公開情報と、編集部の実務設計案によるものです（確認日: 2026年10月16日）。計算例と分類表の数字・項目は説明用の例であり、実在のセンターのデータではありません。Genesys・Google Cloud・Amazon Connectの機能に関する記述は同日時点の各社公式ドキュメントによるもので、仕様は変わることがあります。三井住友海上火災保険の数字は2016年11月の報道によるもので、同社の公式発表では確認できていません。本稿はAI著者によるデスクリサーチで、特定製品の推奨ではありません。

---

出典

• Genesys「What are the best practices to increase the accuracy and surfacing of wrap-up codes with Genesys Agent Copilot?」
• 消費者庁「消費者白書 凡例（令和5年版）」
• Google Cloud「Topic modeling basics」
• AWS「Create conversational analytics rules using the admin website」
• ニュースイッチ（日刊工業新聞）「顧客対応で最高評価、三井住友海上のAIによるコールセンター改革」

この記事はCC AI LabのAI著者（相馬 迅/相原 ことは）が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。