予約・問い合わせ対応をAIで分類するときの失敗回避ポイント
予約フォーム、メール、LINE、電話メモなどから入ってくる問い合わせを、AIで自動分類したい。これは現場ではかなり現実的な使い方です。
ただし、最初から「AIが担当者を決めて、返信方針まで判断する」ところまで任せると失敗しやすくなります。問い合わせ対応で怖いのは、分類ミスそのものよりも、分類ミスに気づかないまま顧客対応が進むことです。
この記事では、予約・問い合わせ対応をAIで分類するときに、事故を避けるための分類軸、例外ルール、有人確認の置き方を整理します。
AIに任せる範囲を「分類」までに絞る
問い合わせ対応には、少なくとも次の4つの工程があります。
- 内容を読む
- 種類を分類する
- 担当者や優先度を決める
- 顧客へ返信する
最初にAIへ任せやすいのは、2の「種類を分類する」部分です。
たとえば、次のような振り分けです。
- 新規予約
- 予約変更
- キャンセル
- 料金・メニュー質問
- アクセス・営業時間質問
- クレーム・不満
- 営業・提案
- その他・要確認
ここで大事なのは、AIが分類した結果をそのまま顧客対応に直結させないことです。最初は「担当者が見る順番を整える」「要確認のものを先に浮かせる」くらいの補助に留めると、現場に入れやすくなります。
分類軸は多くしすぎない
失敗しやすい設計は、最初から細かい分類を作りすぎることです。
たとえば「予約変更」を、日時変更、人数変更、メニュー変更、担当者変更、支払い方法変更のように細かく分けすぎると、AIも人間も迷います。分類の粒度が細かいほど、境界線の説明が必要になるからです。
最初の分類軸は、次の3条件を満たすものに絞ると安定します。
- 担当者の次の行動が変わる
- 優先度が変わる
- 人間が見ても数秒で判断できる
逆に、分類しても対応手順が変わらないものは、最初から分けなくて構いません。
「その他」を逃げ道ではなく安全弁にする
問い合わせ分類AIでは、「その他」が多すぎると役に立ちません。一方で、「その他」をなくすと危険です。
分類に迷う問い合わせを無理に既存カテゴリへ押し込むと、重要な例外が埋もれます。たとえば、予約変更に見える文章の中に「以前の対応が不満だった」という一文が混ざっている場合、単なる変更依頼として処理すると対応を誤ります。
「その他・要確認」は、AIの逃げ道ではなく安全弁として設計します。
目安として、最初のテストでは次のように扱うと実務的です。
- その他が全体の30%以上: 分類軸が粗すぎる、または例文が足りない
- その他が5%未満: 無理に分類している可能性がある
- その他が10〜20%程度: 初期運用では許容しやすい
大事なのは、その他を減らすことではなく、その他に入った問い合わせを見直して分類ルールを育てることです。
有人確認に回す条件を先に決める
問い合わせ分類で一番重要なのは、「AIが自信ありと言ったら通す」ではなく、「この条件なら必ず人間が見る」を先に決めることです。
有人確認に回す条件の例です。
- クレーム、不満、返金、謝罪を含む
- 日時、金額、人数、契約条件が変わる
- VIP顧客、既存大口顧客、紹介案件に関係する
- 本文に複数の要件が混ざっている
- AIの分類理由が本文の一部しか見ていない
- 「至急」「本日中」「困っています」など緊急性がある
この条件を決めずに分類だけ自動化すると、現場は「AIがそう言っているから大丈夫だろう」と流してしまいます。AI導入で必要なのは、信頼することではなく、止める条件を明確にすることです。
例文は成功例だけでなく境界例を入れる
分類AIに渡す例文は、きれいな成功例だけでは足りません。実際の問い合わせは、だいたい曖昧です。
たとえば、次のような境界例を用意します。
問い合わせ文:
明日の予約を別日に変えたいです。あと、前回待ち時間が長かったので今回は早めに案内してほしいです。
期待する分類:
予約変更 + 要確認
理由:
日時変更だけでなく不満が含まれるため、通常の予約変更として自動処理しない。このような例を5〜10件入れるだけで、AIの分類はかなり安定します。特に、予約変更とクレーム、料金質問と契約相談、キャンセルと不満の境界は、先に例文を作っておくと事故を減らせます。
最初の運用は「AI分類 + 人間の差分確認」から始める
いきなり自動振り分けにすると、ミスが見えにくくなります。最初の1〜2週間は、AIの分類結果と人間の最終判断を並べて記録します。
記録する項目は多くなくて構いません。
受付日時:
問い合わせ種別:
AI分類:
人間の最終分類:
一致 / 不一致:
有人確認に回した理由:
ルール修正メモ:この記録を見ると、「AIが苦手な問い合わせ」が見えてきます。たとえば、キャンセル理由に不満が含まれるケース、複数予約をまとめて変更するケース、料金質問に個別条件が混ざるケースなどです。
分類AIの改善は、プロンプトを長くすることではありません。不一致だった問い合わせを見て、分類軸か例外条件のどちらを直すか決めることです。
そのまま使える分類ルールのたたき台
最初のルールは、次のくらいシンプルで十分です。
あなたは予約・問い合わせの一次分類担当です。
問い合わせ本文を読み、次のいずれかに分類してください。
分類:
- 新規予約
- 予約変更
- キャンセル
- 料金・メニュー質問
- アクセス・営業時間質問
- クレーム・不満
- 営業・提案
- その他・要確認
必ず有人確認に回す条件:
- クレーム、不満、返金、謝罪を含む
- 日時、金額、人数、契約条件が変わる
- 複数の要件が混ざっている
- 緊急性がある
- 分類に迷う
出力:
分類:
有人確認: yes / no
理由:
次に人間が見るべき点:ポイントは、分類名だけで終わらせないことです。「理由」と「次に人間が見るべき点」を出させると、現場の確認が速くなります。
導入前チェックリスト
最後に、導入前に確認する項目です。
- 分類カテゴリは8個以内に収まっているか
- 「その他・要確認」を用意しているか
- 有人確認に回す条件を先に決めたか
- 境界例を5件以上用意したか
- AI分類と人間判断の不一致を記録する場所があるか
- 顧客への返信をAI分類だけで自動送信しない設計になっているか
この6つが揃っていれば、問い合わせ分類AIはかなり小さく、安全に始められます。
まとめ
予約・問い合わせ対応のAI分類は、現場の負担を減らしやすい一方で、例外を見落とすと信頼を失いやすい領域です。
最初にやるべきことは、高度な自動化ではありません。分類軸を少なくする、その他を安全弁にする、有人確認の条件を決める、境界例でテストする。この順番です。
AIは問い合わせ対応の責任者ではなく、一次仕分け係として使う。その割り切りが、失敗しにくい導入につながります。
