最終更新日: 2026-06-23
問い合わせ内容をAIで分類する目的は、AIに返信まで任せることではありません。
目的は、届いた問い合わせを読む順番を整えることです。
料金相談なのか。サポートなのか。採用なのか。取材なのか。営業メールなのか。急ぎなのか。誰に渡すべきなのか。
これを毎回人が全文読んで判断していると、件数が増えたときに対応が遅れます。とはいえ、AIに最終判断まで任せると、本物の問い合わせを誤って除外したり、重要な相手へ雑な返信を送ったりする危険があります。
問い合わせ内容のAI分類とは、問い合わせ本文をカテゴリ、優先度、担当者候補、営業メールらしさ、要確認理由に分け、人間が判断しやすい状態にすることです。
この記事では、問い合わせフォームに届いた自由記述をAIで分類し、対応漏れを減らすための設計を整理します。
まず結論 -- AI分類は5つのラベルから始めます
最初から細かい分類を作りすぎる必要はありません。
まずは、次の5つで十分です。
| ラベル | 何を判断するか | 次のアクション |
|---|---|---|
| category | 料金相談、サポート、採用、取材、その他 | 担当者候補を出す |
| priority | 高、中、低、要確認 | 対応順を決める |
| sales_or_legitimate | 正当、営業、要確認 | 通知や分析からの除外候補 |
| owner_candidate | CS、営業、採用、広報、管理者 | 人間が担当者を確定する |
| reason | なぜそう分類したか | 誤判定を確認する |
重要なのは、分類結果だけを保存しないことです。
理由も残します。
AIが「営業」と言った理由が分からないと、人間が確認できません。AIが「高優先度」と言った根拠がないと、担当者は信用しにくくなります。
AI分類では、ラベルと理由をセットにします。
カテゴリ選択だけでは足りない理由
問い合わせフォームには、カテゴリ選択を置くことがあります。
これは有効です。問い合わせカテゴリがあれば、カテゴリ別に自動振り分けする方法のように、選択肢を条件にして担当者へ通知できます。
ただし、カテゴリ選択だけでは足りない場面があります。
| 状況 | 起きること |
|---|---|
| 回答者が「その他」を選ぶ | 内容を読まないと担当が分からない |
| 営業メールが「お問い合わせ」を選ぶ | 本物の問い合わせと混ざる |
| 緊急度の項目がない | 急ぎの相談が埋もれる |
| 文章が長い | 担当者が全文を読まないと要点が分からない |
| カテゴリが古い | 新しい問い合わせ種別に追いつかない |
AI分類は、カテゴリ選択の代わりではありません。
カテゴリ選択を補助し、自由記述の中から意味を拾うためのものです。
AIに任せること、人間が確認すること
問い合わせ内容のAI分類では、任せる範囲を分けます。
| 領域 | AIに任せやすい | 人間が確認する |
|---|---|---|
| 要約 | 長文の要点、担当者向け3行要約 | 重要情報の抜け |
| カテゴリ | 料金相談、サポート、採用、営業など | 最終カテゴリ |
| 優先度 | 急ぎそう、影響が大きそう、期限が近い | 実際の緊急度 |
| 担当者候補 | 部門候補、確認先候補 | 実担当者 |
| 営業判定 | 営業らしさ、要確認理由 | 除外確定 |
| 返信 | 返信方針、下書き | 実送信 |
AIは、分類候補を出すところで強いです。
ただし、送信、除外、外部連携、重要顧客への対応は人間確認を残します。
この境界を決めずにAI分類を入れると、便利なはずの機能が怖いものになります。
分類プロンプトの型
問い合わせ内容をAIに分類させるなら、自由に「分類して」と頼むより、出力形式を固定します。
以下の問い合わせを分類してください。
出力はJSON風にしてください。
category: 料金相談 / サポート / 採用 / 取材 / 営業 / その他
priority: high / medium / low / needs_review
owner_candidate: sales / support / recruiting / pr / admin / unknown
sales_or_legitimate: legitimate / sales / needs_review
summary: 担当者向けに3行以内
reason: 分類理由を2文以内
human_check: 人間が確認すべき点
重要:
- 実返信はしない
- 個人情報を不要に要約へ含めない
- 判断に迷う場合はneeds_reviewにする
ポイントは、needs_review を用意することです。
AIに白黒を強制すると、誤判定が増えます。迷ったものを人間確認へ回せる設計にした方が、安全に運用できます。
営業メール検知との違い
問い合わせAI分類と、営業メール検知は近いですが、同じではありません。
営業メール検知は、問い合わせフォームに混ざる営業メールを 正当 / 営業 / 要確認 のように分ける機能です。使い方は営業メール自動検知の使い方で扱っています。
問い合わせAI分類は、営業メールだけでなく、正当な問い合わせの中身も分けます。
| 対象 | 営業メール検知 | 問い合わせAI分類 |
|---|---|---|
| 営業メールかどうか | 主役 | 一部 |
| カテゴリ | 限定的 | 主役 |
| 優先度 | 限定的 | 主役 |
| 担当者候補 | 限定的 | 主役 |
| 要約 | 必須ではない | 重要 |
| 人間確認 | 必須 | 必須 |
順番としては、まず営業メールや明らかなノイズを分けます。
そのうえで、正当な問い合わせの中身をカテゴリ、優先度、担当者候補へ分けます。
担当者候補へつなげる
AI分類は、ラベルを付けて終わりではありません。
担当者候補へつなげます。
料金相談 -> sales
導入相談 -> sales
障害/不具合 -> support
採用応募 -> recruiting
取材/掲載 -> pr
請求/契約 -> admin
判断困難 -> owner未設定
ただし、担当者候補をAIが出しても、最終的なownerは人間またはルールで確定します。
FORMLOVAで試すなら、問い合わせ担当者割り当てが入口になります。AI分類で候補を出し、担当者確定と通知は運用ルールに寄せる形が安全です。
緊急度を見つける
問い合わせAI分類で効果が出やすいのは、緊急度の検出です。
本日中に必要
明日のイベントに関係する
支払いができない
ログインできない
キャンセルしたい
クレーム
低評価
こうした表現は、カテゴリ選択だけでは拾えないことがあります。
AIは、本文中の言い回しから緊急度候補を出せます。ただし、本当に緊急かどうかは人間が確認します。
緊急そうなものだけ通知するなら、問い合わせ緊急キーワード通知のように、まずはキーワードと人間確認を組み合わせるのが現実的です。
ステータス管理と組み合わせる
AI分類は、ステータス管理と組み合わせて使います。
分類しただけでは、対応は進みません。
new
triaged
assigned
waiting_customer
in_progress
done
excluded
たとえば、AI分類が終わった回答は triaged にする。担当者が確定したら assigned にする。営業メールとして除外するなら excluded にする。
このように状態を持たせると、問い合わせがどこで止まっているか分かります。
ステータス設計は、フォーム回答のステータス管理で詳しく扱っています。
よくある失敗
問い合わせAI分類でよくある失敗は、次の5つです。
| 失敗 | 起きること | 対策 |
|---|---|---|
| 分類を細かくしすぎる | 誤分類が増える | 最初は5〜7カテゴリにする |
| AI分類だけで通知する | 不要通知や誤通知が増える | priorityとreasonを見る |
| 営業判定を自動除外にする | 本物を落とす | needs_reviewを残す |
| 担当者をAIだけで確定する | 責任が曖昧になる | ownerは人間/ルールで確定 |
| 返信まで自動送信する | 文面事故が起きる | 返信下書きまでにする |
AI分類は、問い合わせ対応を速くします。
でも、最初から全自動に寄せると危険です。
AIは読む。AIは候補を出す。人間が確認する。必要ならワークフローが通知する。
この順番で始めるのが安全です。
FORMLOVAで問い合わせAI分類を始めるなら
FORMLOVAで問い合わせAI分類を始めるなら、次の順番が現実的です。
- 問い合わせフォームにカテゴリ項目を置く
- 自由記述をAIで要約する
- 営業メール、要確認、正当を分ける
- 優先度と担当者候補を出す
- 人間がownerと対応方針を確定する
- ステータスを進める
- 必要なものだけ通知する
問い合わせ運用全体の設計は、問い合わせフォームの対応管理まとめに戻って確認してください。
AI分類を、担当者割り当て、返信下書き、未対応確認まで広げる場合は、問い合わせ対応をAIで自動化する方法で全体の境界を決めてください。
回答データ全般をAIとチャットしながら読む考え方は、回答データとチャットするとはで整理しています。
まとめ
問い合わせ内容をAIで分類する価値は、AIに問い合わせ対応を任せることではありません。
届いた本文を、カテゴリ、優先度、担当者候補、営業メールらしさ、要確認理由に分け、人間が判断しやすい状態にすることです。
カテゴリ選択だけでは拾えない自由記述の意味をAIが読み、担当者やステータス管理へ渡す。
そのうえで、送信、除外、担当者確定、重要判断は人間確認を残す。
この設計なら、問い合わせAI分類は怖い自動化ではなく、対応漏れを減らす実務の補助になります。
関連記事
Disclosure and Verification
- 2026-06-23に、問い合わせフォーム運用、カテゴリ別振り分け、営業メール検知、回答ステータス管理、回答データAI分析の記事群を確認し、本記事を自由記述の問い合わせAI分類に分離しました。
- 本記事は外部ヘルプデスクAIやCRM製品の仕様を断定していません。AI分類のラベル設計、人間確認の境界、担当者候補とステータス管理の接続は、FORMLOVAの既存運用設計とSEO棚卸しに基づいて整理しています。
