問い合わせ対応の属人化、対応漏れ、品質のばらつきは、事業成長の足かせになりやすい課題です。特に、メール、フォーム、チャットなど複数の窓口に寄せられる問い合わせが増えるほど、その管理は複雑化します。
この記事では、単なる問い合わせ管理ツールの導入にとどまらず、AIを活用して「問い合わせの分類→担当者の振り分け→対応状況の追跡」という一連のプロセスを“仕組み”として構築するための設計思想と具体的な手順を解説します。
本記事の目的は、AIをあくまで「判断支援」と位置づけ、最終的な責任は人が担うという現実的な運用を前提に、対応漏れをなくし、返信品質を標準化し、担当者の割り当てを安定させることです。
この記事で扱う範囲と前提
- 対象： メール、Webフォーム、チャットなどから寄せられる問い合わせの一次処理（内容の種別分類、必要情報の回収、担当者アサイン、対応状況の追跡）。
- ゴール： 対応漏れを減らし、返信品質を標準化し、担当者の割り当てを安定させること。
- 前提： AIの役割は、分類の提案や回答文のドラフト作成までとします。顧客への最終的な回答や、契約・法的な判断は、必ず人がレビューし、責任を持つ運用を想定しています。
問い合わせ種別の分類
自動化の第一歩は、多種多様な問い合わせを、意味のあるグループに「分類」することから始まります。この分類が曖昧だと、後続の振り分けルールがうまく機能しません。
自社に合った「種別」を定義する
まず、自社のビジネスに合わせて問い合わせの「種別」を定義します。一般的な例としては以下のようなものが考えられますが、これをそのまま使うのではなく、自社の実態に合わせてカスタマイズすることが重要です。
- 見積依頼
- 製品・サービスの不具合報告
- 請求・支払いに関する確認
- 採用応募
- 協業・アライアンスの提案
- その他（上記に当てはまらないもの）
ポイントは、「誰が対応すべきか」という観点で分けることです。例えば、「製品Aに関する技術的な質問」と「製品Bに関する技術的な質問」で担当チームが異なるなら、これらは別の種別として定義することが考えられます。
AI分類のためのラベル設計
AIに分類を学習させるためには、「ラベル」と呼ばれる教師データが必要です。このラベル設計が、分類精度を大きく左右します。
- ラベルの数は適切か： ラベルが多すぎると、各ラベルに紐づくデータが少なくなり、AIの学習が困難になる傾向があります。また、運用担当者もラベルを覚えきれず、形骸化しやすくなります。最初は5〜8種類程度の主要なラベルから始めるのが一般的です。
- 階層化の検討： 例えば「不具合報告」という大きなラベルの下に、「製品Aの不具合」「製品Bの不具合」といった子ラベルを作ることで、整理しやすくなる場合があります。
- 曖昧なカテゴリの扱い： どのラベルにも当てはまらない問い合わせは必ず発生します。そのために「その他」や「要確認」といったラベルを用意し、これらは必ず人の目で確認するフローに組み込むことが推奨されます。
分類に利用する入力データ
AIは、問い合わせに含まれる様々な情報から内容を推測します。どのような情報をAIに与えるかを設計しておくことが大切です。
- 件名、本文： 最も重要な情報源です。
- 送信元情報： メールアドレスのドメイン（例：既存顧客か、フリーメールか）など。
- フォームの入力項目： 「お問い合わせ種別」のようなプルダウン項目があれば、強力な手がかりになります。
- 過去のやり取り： 同じ送信者との過去のスレッド情報も、文脈を理解する上で有用な場合があります。
- 添付ファイル： 添付ファイル内のテキストを自動で抽出・解析する技術もありますが、セキュリティや個人情報保護の観点から、まずは本文のみを対象とし、添付の有無だけを情報として扱うなど、慎重な検討が求められます。
AIからの出力イメージ
AIによる分類が完了すると、以下のような情報が出力されることが期待されます。
- 分類ラベル： AIが最も適切だと判断した種別（例：「見積依頼」）。
- 確信度： その判断がどの程度確かかを示す指標。確率のような断定的な表現ではなく、「確信度：高」といった形で示されることが一般的です。確信度が低いものは、人の目で再確認するルールを設けます。
- 推奨される次のアクション： 例えば「営業担当Aへアサイン」「一次返信テンプレートBを適用」といった、次のステップの提案。
担当振り分けルール
問い合わせの種別が特定できたら、次はその内容に最もふさわしい担当者へ、迅速かつ正確に割り当てる「振り分け」のフェーズです。ここでは、「ルールベース」と「AI判定」を組み合わせたハイブリッドな設計が効果的です。
「ルールベース」と「AI判定」のハイブリッド設計
まずは、誰が見ても判断に迷わない固定的なルールを定義します。AIは、そのルールだけでは判断が難しい、曖昧なケースの支援に使うのが現実的です。
- ルールベース（優先適用）：
- 「件名に『請求書』とあれば経理担当へ」
- 「フォームの『製品A』が選択されていればAチームへ」
- 「メールアドレスが既存顧客リストにあれば、その顧客の担当営業へ」
- AI判定（ルールに合致しない場合）：
- 自由記述の本文から、内容の緊急度や関連する製品をAIが推測し、担当チームを提案する。
このように、まず固定ルールで処理し、それに当てはまらないものだけをAIの判断に委ねることで、予測不能な動きを減らし、安定した運用を実現しやすくなります。
担当者を決定するための判断キー
担当者を決定する際には、問い合わせの種別以外にも、以下のような様々な情報が判断のキーとなります。
- 顧客種別： 新規顧客か、既存顧客か。
- 案件種別： 緊急のトラブルか、一般的な質問か。
- 緊急度： 本文中の「至急」「困っている」といったキーワードや、顧客の契約プラン（例：プレミアムサポート契約）などから判断。
- 地域や商材： 担当エリアや専門分野で担当者が分かれている場合。
- 対応時間帯： 夜間や休日は、特定の一次対応チームに集約するなど。
例外処理の設計
自動振り分けで最も重要なのが、例外処理の設計です。
- 分類不能・曖昧な問い合わせ： AIの確信度が低い、あるいは複数の部署に関連する可能性がある問い合わせは、特定の担当者に自動で割り振るのではなく、「一次受付担当」や「トリアージ担当」といった専門の窓口に集約する設計が一般的です。この担当者が内容を精査し、手動で適切な担当者へ再割り当てします。
- 一次返信（ドラフト）の自動生成： 担当者が内容を確認する前に、顧客へ「お問い合わせを受け付けました」という一次返信を自動で送る仕組みは有効です。その際、AIが本文を要約し、不足している情報を聞き返すような質問文をドラフトとして生成することで、担当者の負担を軽減できます。
- 含めるべき内容の例：
- 受付完了の旨
- （もし不足していれば）確認したい追加情報（例：「ご利用の製品バージョンをお知らせください」）
- 今後の流れと対応目安（例：「担当者より2営業日以内にご連絡します」など、断定は避ける）
- 含めるべき内容の例：
- 担当者に渡す情報パッケージ： 担当者が一目で状況を把握できるよう、AIが生成した以下の情報をセットで渡すことが理想的です。
- 問い合わせ内容の要約
- 論点（何が問題か）の整理
- 不足している情報
- 推奨される次のアクション（例：返信テンプレート案、担当者候補）
対応漏れを防ぐ設計
担当者を決めるだけでは不十分で、その後の対応が確実に行われ、放置されることがないように「追跡」する仕組みが不可欠です。
ステータス設計
各問い合わせが今どのような状況にあるのかを可視化するため、ステータスを定義します。
- 未着手（New）： 問い合わせが入った直後の状態。
- 一次返信済み（First Reply Sent）： 自動または手動で最初の返信が完了した状態。
- 担当者対応中（In Progress）： 担当者が内容を確認し、本格的な対応を開始した状態。
- 顧客返信待ち（Pending）： 顧客に追加情報を質問し、その返事を待っている状態。
- 完了（Resolved）： 課題が解決し、対応が終了した状態。
- クローズ（Closed）： 完了後、一定期間が経過して完全に終了した状態。
期限（SLA）とエスカレーション
「いつまでに対応するか」という期限の考え方をルール化し、それが守られない場合の対策を講じます。
- 期限の設定： 一般的には、問い合わせの種別や緊急度に応じて、「一次返信までX時間以内」「完了までY日以内」といった目標（SLA: Service Level Agreement）を設定します。これは厳格な契約ではなく、あくまで社内目標として定義することが多いです。
- リマインダーと再通知： 期限が近づいた担当者へ自動でリマインド通知を送ります。
- エスカレーション： 期限を過ぎても対応されない場合、担当者の上長や、別の担当者へ自動で通知が飛ぶ（エスカレーションされる）仕組みを設けることで、放置されるリスクを低減できます。
キュー管理
複数の問い合わせを効率的に処理するための管理方法です。
- 優先度付け： 緊急度の高い問い合わせが、他の問い合わせより先に処理されるようにします。
- 重複問い合わせの統合： 同じ顧客から短時間に複数の問い合わせがあった場合、それらを一つのチケットにまとめることで、対応の重複や混乱を防ぎます。
- 再オープン： 「完了」したはずの問い合わせに対して顧客から返信があった場合、自動でステータスを「担当者対応中」に戻し（再オープン）、担当者に通知します。
監査ログの重要性
誰が、いつ、どのような対応をしたのかを記録する「監査ログ」は、トラブル発生時の原因究明や、対応プロセスの改善に役立ちます。
- 記録すべき情報： 最初の問い合わせ内容、AIによる分類結果、担当者の変更履歴、送受信したメッセージ全文など。
- 利点： 特定の担当者に負荷が偏っていないか、特定の種別の問い合わせ対応に時間がかかりすぎていないか、といった運用上のボトルネックを発見する手がかりになります。
ダッシュボードで見るべき指標
数値を追いかけること自体が目的ではありませんが、対応状況全体を俯瞰するために、以下のような指標をダッシュボードで可視化することが一般的です。
- 未対応件数
- 期限超過の件数
- 問い合わせ種別ごとの件数や滞留時間
最小構成で始める導入手順（スモールスタート）
いきなり全社的に壮大なシステムを導入しようとすると、失敗しやすくなります。まずは限定的な範囲で始め、効果を検証しながら改善していく「スモールスタート」が成功の鍵です。
- 対象チャネルを1つに絞る
- まずは「Webサイトの問い合わせフォーム」だけ、など対象を限定します。複数のチャネルを同時に自動化しようとすると、ルールが複雑になりすぎます。
- 既存の問い合わせを棚卸し、ラベル案を作成する
- 過去1ヶ月分などの問い合わせ履歴を見返し、どのような内容が多いかを分析します。その上で、前述の「問い合わせ種別の分類」を参考に、5〜8個程度のシンプルなラベル案を作成します。
- 手動での分類を試行する
- 新しい問い合わせが入るたびに、作成したラベル案に基づいて手動で分類してみます。このプロセスを通じて、「このラベルでは分けにくい」「新しいラベルが必要だ」といった課題が見えてきます。
- AIによる分類支援を併用する
- 手動分類で得られたデータを教師データとして、AIに分類を学習させます。最初はAIの分類結果を「提案」として表示させ、最終判断は人が行う運用から始めます。AIの精度が安定してきたら、確信度の高いものから徐々に自動化の範囲を広げていきます。
- 運用ドキュメントを作成し、ルールを更新し続ける
- 「誰が」「いつ」「何を確認するのか」（例：毎週月曜に「要確認」ラベルの問い合わせをレビューする）といった最低限の運用ルールをドキュメント化します。運用しながら出てきた例外や課題は、その都度ルールに反映させ、仕組みを陳腐化させないことが重要です。
リスクと対策（個人情報・誤分類・責任分界）
自動化は便利ですが、リスクも伴います。事前にリスクを想定し、対策を講じておくことが不可欠です。
個人情報の取り扱い
- 入力フォームでの注意喚起： 問い合わせフォームに「クレジットカード番号やパスワードなどの機密情報は入力しないでください」といった注意書きを明記することが一般的です。
- 保存と共有範囲の限定： 問い合わせ情報は、対応に必要な担当者だけがアクセスできるように権限を管理し、不要になったデータは適切な期間で削除するルールを定めます。
- 誤送信対策： AIが生成した返信ドラフトに、意図せず個人情報が含まれてしまう可能性もゼロではありません。最終送信前の人間によるレビューは、こうしたリスクを低減する上でも重要です。
誤分類への対策
- 確信度が低い場合の人間への引き渡し： AIによる分類の確信度が一定のしきい値を下回る場合は、自動で担当者を割り当てず、必ず「要確認」キューに入れて人の目でチェックするフローを組み込みます。
- 定期的なレビューと再学習： 誤分類された問い合わせは、なぜ間違えたのかを分析し、正しいラベルを付け直してAIに再学習させることで、継続的に精度を改善していくことが望まれます。
責任分界点の明確化
- AIはあくまで「ドラフト作成者」： AIが生成した一次返信の文面は、そのまま顧客に送信されるべきではありません。必ず担当者が内容を確認し、自らの責任で送信するという原則を徹底します。
- 最終判断は人間が担う： 契約に関する判断や、法的な見解が求められるような問い合わせに対して、AIが自動で回答するような設計は避けるべきです。
セキュリティに関する一般的な注意
- 認証情報の管理： 問い合わせの本文や添付ファイルに、APIキーやパスワードといった認証情報を入力しないよう、ユーザーに注意喚起することが重要です。
- 権限の分離： 問い合わせ対応システムへのアクセス権限は、必要最小限に留めるべきです。
よくある失敗と改善（運用が崩れるポイント）
仕組みを導入しても、運用が形骸化してしまうケースは少なくありません。よくある失敗パターンとその対策を知っておきましょう。
- 失敗：ラベルが増えすぎて誰も使えなくなる
- 原因： 新しい種類の問い合わせが来るたびに、安易にラベルを追加してしまう。
- 改善： 定期的にラベルを見直し、利用頻度の低いものは統合したり、階層化して整理したりします。ラベルの追加は、明確なルール（例：月10件以上発生する場合のみ追加を検討）に基づいて行います。
- 失敗：例外処理が多すぎて、ほとんどが手動対応になる
- 原因： 自動化ルールが単純すぎて、多くの問い合わせが「その他」や「要確認」に分類されてしまう。
- 改善： 「例外」として処理された問い合わせの内容を分析し、共通のパターンを見つけ出して新しいルールとして追加します。例外を減らす努力が、自動化率の向上に繋がります。
- 失敗：一次返信が”それっぽい”だけで、必要な情報が聞き出せない
- 原因： AIが生成する一次返信のテンプレートが汎用的すぎて、顧客が次に何をすればよいか分からない。
- 改善： 問い合わせ種別ごとに、「この種別の場合は、この情報を必ず聞き返す」といった追加質問のテンプレートを強化します。顧客の手間を一度で済ませるための工夫が、結果的に対応全体の効率を上げます。
- 失敗：期限管理のルールが曖昧で、結局対応が漏れる
- 原因： 「なるべく早く」といった精神論に頼ってしまい、具体的な期限やエスカレーションルールが定義されていない。
- 改善： 「一次返信は24時間以内」「期限超過したら上長に通知」といった、誰にでも分かる最低限のルールを定め、システムで強制的にリマインドや通知を行うようにします。
CTA：問い合わせ振り分け設計シート
ここまで読んだあなたは、自社の問い合わせ対応を改善するための具体的なイメージが湧いてきたのではないでしょうか。
しかし、実際に何から手をつければ良いか、どのような項目を決めればよいか、迷ってしまうかもしれません。
そこで、今回解説した内容を元に、自社の問い合わせ振り分けルールを設計するための「問い合わせ振り分け設計シート」のテンプレートをご用意しました。
このシートで手に入るもの：
このExcelシートには、問い合わせ対応の自動化設計に必要な以下の項目がまとめられています。
- 問い合わせ種別（ラベル）定義シート
- 担当者振り分けルール定義シート
- 例外処理ルール一覧
- ステータスと期限（SLA）管理表
- 一次返信テンプレート集
- 承認・レビューフロー整理表
シートの簡単な使い方：
- [Step 1] 棚卸し： まず、過去の問い合わせ履歴を参考に、シート内の「問い合わせ種別定義シート」を自社向けにカスタマイズします。
- [Step 2] ルール設計： 次に、「担当者振り分けルール定義シート」を使って、「もし〜なら、〜へ割り当てる」というルールを具体的に書き出していきます。
- [Step 3] 運用設計： 最後に、ステータスや期限、例外処理のルールを決め、チーム内での運用方法を固めます。
このシートをたたき台としてチームで議論することで、属人化していたプロセスが可視化され、具体的な改善アクションへと繋げることができます。ぜひ、以下のボタンからダウンロードしてご活用ください。
[問い合わせ振り分け設計シートをダウンロードする（リンク）]
