最終更新日: 2026-10-15
問い合わせAI分類は、カテゴリ・優先度・担当部署候補・根拠を出す前処理です。最初は少数の架空例で、迷う問い合わせが要確認に残るかを試してください。営業検知ラベル、業務カテゴリ、対応ステータスは別々に扱います。
まず結論 -- AI分類は5つのラベルから始めます
以下の列や担当・期限は運用設計の例です。FORMLOVA標準のstatusは new（新規）、in_progress（対応中）、resolved（解決済み）、spam の4値です。担当者、確認待ち、返信期限、AI候補はnotes・既存タグを保持するタグ運用・用途に応じたフォーム項目、または別の運営台帳へ分けます。needs_review は確認用の印で、標準statusではありません。複数回答の状態変更は対象IDごとに実行し、再取得で確認します。
MCPのCSV/Excel書き出しはフォーム項目と送信日時で、回答ID・status・owner・notes・tags列は含みません。フォーム全件を書き出し、必要な絞り込みは管理した作業コピーで行います。IDや状態の分析は対応する回答取得で確認し、生メール照合や存在しないCSV列で結合しません。MCPのメール・電話はマスクされるため、マスク値を宛先やCRMの本人キーへ渡しません。標準Sheets自動同期も送信日時とフォーム項目で、owner/status等は別の作業台帳へ分けます。Freeの所有者向け通知は6時間ダイジェストでメール枠の対象外です。回答者向けメールや、チャットで作る未対応レポートとは別です。
最初から細かい分類を作りすぎる必要はありません。
まずは、次の5つで十分です。
| ラベル | 何を判断するか | 次のアクション |
|---|---|---|
| category | 料金相談、サポート、採用、取材、その他 | 担当者候補を出す |
| priority | 高、中、低、要確認 | 対応順を決める |
| sales_or_legitimate | legitimate、sales、suspicious、junk | 通知や分析からの除外候補 |
| owner_candidate | CS、営業、採用、広報、管理者 | 人間が担当者を確定する |
| reason | なぜそう分類したか | 誤判定を確認する |
重要なのは、分類結果だけを保存しないことです。
理由も残します。
AIが「営業」と言った理由が分からないと、人間が確認できません。AIが「高優先度」と言った根拠がないと、担当者は信用しにくくなります。
AI分類では、ラベルと理由をセットにします。
境界の曖昧な3件で分類を試す
次は未実行の提案例です。まず下書きや架空データで試し、実回答を使う場合はフォーム・期間・扱ってよい情報を決めます。
分析・運営台帳の提案例です。列は実際に用意したものだけを使い、不足は不明とします。実行結果や標準CSVの列ではありません。
カテゴリ選択、相談本文、希望時期のある問い合わせフォームを未公開で下書きにしてください。
私が用意する「料金相談」「宣伝の提案」「判断が難しい提携相談」の架空例を、カテゴリ候補、priority、owner_candidate、根拠、要確認理由に分けてください。営業検知の標準spam_labelとAI独自の分類を混同せず、返信・除外・担当確定はしないでください。
提携相談が機械的に営業除外されないか、根拠が原文にあるかを見ます。カテゴリ候補を確定する人と、確認後にnotesや既存タグを保持して記録する方法を決めます。
この図は運用の考え方を示す既存の概念図です。実画面や動作成功の証拠ではありません。図の自動化範囲も、利用プラン・接続・設定後に成立する設計を示します。
フォーム作成・公開・回答受付・検索・標準status・書き出し・基本分析は無料で使えます。上のAIの整理は接続するAIクライアント側で行い、外部AIの利用条件や費用は別です。カスタム自動返信、リマインド、取り込み、詳細分析、添付、標準のSheets自動同期はスタンダード以上、一斉メールやシーケンスはプレミアム以上です。外部MCPを使うレシピはFreeからでも外部接続・権限・提供元条件がそろえば実行できますが、チャットへ貼るだけで常時監視は始まりません。
分類しやすい問い合わせフォームを作る
上の下書きと確認から無料で試し、運用に必要になった機能を追加できます。
登録してメール確認後、対応AIチャットへ接続し、上の依頼文で下書きを作ります。公開前に内容を確認し、外部AIの利用条件・費用も確認してください。
カテゴリ選択だけでは足りない理由
問い合わせフォームには、カテゴリ選択を置くことがあります。
これは有効です。問い合わせカテゴリがあれば、カテゴリ別に自動振り分けする方法のように、選択肢を条件にして担当者へ通知できます。
ただし、カテゴリ選択だけでは足りない場面があります。
| 状況 | 起きること |
|---|---|
| 回答者が「その他」を選ぶ | 内容を読まないと担当が分からない |
| 営業メールが「お問い合わせ」を選ぶ | 本物の問い合わせと混ざる |
| 緊急度の項目がない | 急ぎの相談が埋もれる |
| 文章が長い | 担当者が全文を読まないと要点が分からない |
| カテゴリが古い | 新しい問い合わせ種別に追いつかない |
AI分類は、カテゴリ選択の代わりではありません。
カテゴリ選択を補助し、自由記述の中から意味を拾うためのものです。
AIに任せること、人間が確認すること
問い合わせ内容のAI分類では、任せる範囲を分けます。
| 領域 | AIに任せやすい | 人間が確認する |
|---|---|---|
| 要約 | 長文の要点、担当者向け3行要約 | 重要情報の抜け |
| カテゴリ | 料金相談、サポート、採用、営業など | 最終カテゴリ |
| 優先度 | 急ぎそう、影響が大きそう、期限が近い | 実際の緊急度 |
| 担当者候補 | 部門候補、確認先候補 | 実担当者 |
| 営業判定 | 営業らしさ、要確認理由 | 除外確定 |
| 返信 | 返信方針、下書き | 実送信 |
AIは、分類候補を出すところで強いです。
ただし、送信、除外、外部連携、重要顧客への対応は人間確認を残します。
この境界を決めずにAI分類を入れると、便利なはずの機能が怖いものになります。
分類プロンプトの型
問い合わせ内容をAIに分類させるなら、自由に「分類して」と頼むより、出力形式を固定します。
分析・運営台帳の提案例です。列は実際に用意したものだけを使い、不足は不明とします。実行結果や標準CSVの列ではありません。
以下の問い合わせを分類してください。
出力はJSON風にしてください。
category: 料金相談 / サポート / 採用 / 取材 / 営業 / その他
priority: high / medium / low / needs_review
owner_candidate: sales / support / recruiting / pr / admin / unknown
spam_label_candidate: legitimate / sales / suspicious / junk
summary: 担当者向けに3行以内
reason: 分類理由を2文以内
human_check: 人間が確認すべき点
重要:
- 実返信はしない
- 個人情報を不要に要約へ含めない
- 判断に迷う場合はneeds_reviewにする
ポイントは、needs_review を用意することです。
AIに白黒を強制すると、誤判定が増えます。迷ったものを人間確認へ回せる設計にした方が、安全に運用できます。
営業メール検知との違い
問い合わせAI分類と、営業メール検知は近いですが、同じではありません。
営業メール検知は、問い合わせフォームに混ざる営業メールを legitimate / sales / suspicious / junk の4ラベルに分ける機能です。使い方は営業メール自動検知の使い方で扱っています。
問い合わせAI分類は、営業メールだけでなく、正当な問い合わせの中身も分けます。
| 対象 | 営業メール検知 | 問い合わせAI分類 |
|---|---|---|
| 営業メールかどうか | 主役 | 一部 |
| カテゴリ | 限定的 | 主役 |
| 優先度 | 限定的 | 主役 |
| 担当者候補 | 限定的 | 主役 |
| 要約 | 必須ではない | 重要 |
| 人間確認 | 必須 | 必須 |
順番としては、まず営業メールや明らかなノイズを分けます。
そのうえで、正当な問い合わせの中身をカテゴリ、優先度、担当者候補へ分けます。
担当者候補へつなげる
AI分類は、ラベルを付けて終わりではありません。
担当者候補へつなげます。
分析・運営台帳の提案例です。列は実際に用意したものだけを使い、不足は不明とします。実行結果や標準CSVの列ではありません。
料金相談 -> sales
導入相談 -> sales
障害/不具合 -> support
採用応募 -> recruiting
取材/掲載 -> pr
請求/契約 -> admin
判断困難 -> owner未設定
ただし、担当者候補をAIが出しても、最終的なownerは人間またはルールで確定します。
FORMLOVAで試すなら、問い合わせ担当者割り当てが入口になります。AI分類で候補を出し、担当者確定と通知は運用ルールに寄せる形が安全です。
Workflowページは再利用できるチャット用プロンプトです。接続中のセッションで必要なツールとプランを確認して実行するもので、回答ごとの監視や定期実行が自動で設置されるわけではありません。定期レポート・リマインドは対応するスタンダード以上の設定か別途のスケジューラーが必要で、外部Slack/Sheets MCPは接続・権限・提供元条件も別に確認します。
緊急度を見つける
問い合わせAI分類で効果が出やすいのは、緊急度の検出です。
本日中に必要
明日のイベントに関係する
支払いができない
ログインできない
キャンセルしたい
クレーム
低評価
こうした表現は、カテゴリ選択だけでは拾えないことがあります。
AIは、本文中の言い回しから緊急度候補を出せます。ただし、本当に緊急かどうかは人間が確認します。
緊急そうなものだけ通知するなら、問い合わせ緊急キーワード通知のように、まずはキーワードと人間確認を組み合わせるのが現実的です。
ステータス管理と組み合わせる
AI分類は、ステータス管理と組み合わせて使います。
分類しただけでは、対応は進みません。
new
in_progress
resolved
spam
分類済みや担当確定はnotes・既存タグを保持するタグ運用・別台帳で残します。実際に作業を始めた回答をin_progress、解決を確認した回答をresolvedにします。営業検知ラベルや分析除外条件はstatusと分け、営業候補だけを理由にspamへ確定しません。
このように状態を持たせると、問い合わせがどこで止まっているか分かります。
ステータス設計は、フォーム回答のステータス管理で詳しく扱っています。
よくある失敗
問い合わせAI分類でよくある失敗は、次の5つです。
| 失敗 | 起きること | 対策 |
|---|---|---|
| 分類を細かくしすぎる | 誤分類が増える | 最初は5〜7カテゴリにする |
| AI分類だけで通知する | 不要通知や誤通知が増える | priorityとreasonを見る |
| 営業判定を自動除外にする | 本物を落とす | needs_reviewを残す |
| 担当者をAIだけで確定する | 責任が曖昧になる | ownerは人間/ルールで確定 |
| 返信まで自動送信する | 文面事故が起きる | 返信下書きまでにする |
AI分類は、問い合わせ対応を速くします。
でも、最初から全自動に寄せると危険です。
AIは読む。AIは候補を出す。人間が確認する。必要ならワークフローが通知する。
この順番で始めるのが安全です。
FORMLOVAで問い合わせAI分類を始めるなら
FORMLOVAで問い合わせAI分類を始めるなら、次の順番が現実的です。
- 問い合わせフォームにカテゴリ項目を置く
- 自由記述をAIで要約する
- 営業検知の4ラベル（legitimate/sales/suspicious/junk）を確認する
- 優先度と担当者候補を出す
- 人間がownerと対応方針を確定する
- ステータスを進める
- 必要なものだけ通知する
問い合わせ運用全体の設計は、問い合わせフォームの対応管理まとめに戻って確認してください。
AI分類を、担当者割り当て、返信下書き、未対応確認まで広げる場合は、問い合わせ対応をAIで自動化する方法で全体の境界を決めてください。
回答データ全般をAIとチャットしながら読む考え方は、回答データとチャットするとはで整理しています。
まとめ
問い合わせ内容をAIで分類する価値は、AIに問い合わせ対応を任せることではありません。
届いた本文を、カテゴリ、優先度、担当者候補、営業メールらしさ、要確認理由に分け、人間が判断しやすい状態にすることです。
カテゴリ選択だけでは拾えない自由記述の意味をAIが読み、担当者やステータス管理へ渡す。
そのうえで、送信、除外、担当者確定、重要判断は人間確認を残す。
この設計なら、問い合わせAI分類は怖い自動化ではなく、対応漏れを減らす実務の補助になります。
関連記事
執筆・確認情報
- 2026-06-23に、問い合わせフォーム運用、カテゴリ別振り分け、営業メール検知、回答ステータス管理、回答データAI分析の記事群を確認し、本記事を自由記述の問い合わせAI分類に分離しました。
- 本記事は外部ヘルプデスクAIやCRM製品の仕様を断定していません。AI分類のラベル設計、人間確認の境界、担当者候補とステータス管理の接続は、FORMLOVAの既存運用設計とSEO棚卸しに基づいて整理しています。
改稿確認（2026-10-15）: 本文の回答操作、プラン境界、書き出し列、提案例を現行リポジトリと照合しました。過去日付の調査は当時の記録であり、架空例は実測成果ではありません。
