問い合わせメール自動仕分け・返信下書きシステム — 受信箱の分類・優先度判定から一次返信まで自動化する

問い合わせ窓口に届いたメールを、カテゴリ分類・優先度判定・自社トーンの返信下書きまで自動で用意するシステムを開発しました。担当者は「確認して送るだけ」。新しいツールへの乗り換えは不要で、いま使っているメール運用にそのまま乗せられます。T-WORKS が自社の問い合わせ窓口でも使っているツールです。

このページでは、何を作ったのか、どう動くのか、そして実装上どこを工夫したのかを紹介します。

効果を示す数値は、中小企業の問い合わせ窓口を想定したモデルケースに基づく想定値です（特定企業の実測ではありません）。入出力サンプルはすべて架空のデータを使用しています。

何を解決するためのものか

問い合わせメールの対応は、1通ごとに「読む → どの種類か仕分ける → 急ぎかどうか見極める → ゼロから返信を書く」という流れを毎回繰り返します。1通あたりは数分でも、毎日積み重なれば相当な時間です。

さらに厄介なのが対応漏れです。受信箱を目視で追っているだけだと、クレームや「至急」と書かれた見積依頼が、後から来た大量のメールに埋もれてしまうことがあります。返信のトーンも、書く担当者や日によってばらつきます。

このシステムは、その「受信箱の仕分け＋一次返信の下書き」を、いま使っているメールにAIの判断を足すだけで「確認して送るだけ」の状態にすることを狙ったものです。

どんなシステムか

ポイントは、メールを完全自動で送ってしまわないことです。AIが分類・優先度判定・返信下書きまでを用意し、最後に人が確認して送る——いわゆる Human-in-the-Loop の構成にしています。

利用者の操作は、受信箱のメールを貼り付けるか、CSVを読み込ませるだけです。システムは届いたメール1通ごとに、次の3つを返します。

• カテゴリ分類 — 見積依頼・サポート・クレーム・営業・採用・スパムなどに振り分ける
• 優先度判定 — 高・中・低を、根拠つきで判定する
• 返信下書き — FAQ・トーンガイドに沿った一次返信を自動生成する

加えて、対応漏れを防ぐための「要対応リスト」を自動で抽出します。要約や分類だけで終わらせず、「次に何をすべきか」まで形にすることに振り切っています。

入力と出力（実際のサンプル）

利用者は新しい画面を覚える必要はありません。受信箱のメールを貼るか、CSVを出すだけです。将来的には Gmail と連携して、受信 → ラベル付与 → 下書き保存 → 要対応通知までをつなげられる設計にしてあります。

入力（問い合わせ受信箱・架空の8件）

ダミーの受信箱として、見積2件・サポート2件・クレーム1件・営業1件・採用1件・スパム1件の計8件を読み込ませます。「至急」と書かれた見積もり、ログインできないというサポート、サービスへの苦情など、現場でよくある雑多な内容が混ざっています。

出力（自動で分類・優先度判定された一覧）

8件はそれぞれカテゴリと優先度に振り分けられ、なぜその優先度なのかの根拠も添えられます。

この8件のうち、「#2 至急の見積依頼」と「#5 クレーム」の2件が要対応として自動でフラグされます。受信箱を目で追わなくても、先に手を付けるべきメールが浮かび上がります。

出力（返信下書き）

各メールには、FAQとトーンガイドに沿った返信の下書きが自動で用意されます。下書きには「どのFAQを参照したか」「なぜこの優先度なのか」という根拠も併記されるので、確認しやすくなっています。なお、スパム（#8）には返信下書きを作りません。

実装で工夫したこと

ここがこのシステムの肝です。設計の中心にあるのは、判断はAIに、ルールと正確さは決まった処理にという役割分担です。

1. 優先度を「AIの気分」で決めない

優先度の判定は、AIの感覚任せにしていません。「クレームは高」「スパム・営業は低」「本文に『至急』や期限の指定があれば高」といった決定的なルールを処理の中核（コア）に置き、ルールで決めきれない曖昧なケースだけAIで補完します。

この分離のおかげで、上のサンプルのように「本文に『至急』を検出したため高」「カテゴリ＝クレームのため高」と、なぜその優先度になったのかを機械的に提示できます。同じ入力なら同じ結果が出る再現性も担保されます。AIに判断させる部分（分類）と、ルールで固める部分（優先度・整形）を core/ と adapter/ として明確に分けてあるのが、このシステムの土台です。

2. 「貼り付け」と「CSV」を1つの入力欄で両立させる

利用者によって、メールをそのまま貼り付ける人もいれば、CSVを出して読み込ませる人もいます。これを別々の画面に分けず、1つの入力欄で受け取れるようにしました。

仕組みとしては、入力されたテキストに「表（CSV）らしさ判定」を入れ、必須のカラムを持つ表形式なら自動でCSVとして解釈し、そうでなければ普通のメール本文として扱います。これにより、サンプルCSVを入力欄に流し込んでも壊れず、かつ普通の問い合わせ文章をCSVと誤認することもありません。利用者は入力形式を意識せずに使えます。

3. ありもしない回答を作らない（ハルシネーション回避）

返信下書きは、登録されたFAQの範囲でだけ生成します。FAQで答えられない内容——クレームやその他の特殊な相談——については、勝手に答えを作らず「要担当者対応」としてフラグを立てます。

これは「それらしい嘘の返信」を防ぐための構造的な工夫です。存在しない価格や期日を約束してしまう事故を、設計の段階で起こさないようにしています。返信のトーンも、挨拶・署名・文体を定めたトーンガイドに沿わせることで、担当者や日によるばらつきをなくしています。

4. 誤送信事故を「構造」で防ぐ

このシステムは完全自動送信をしません。AIが用意するのはあくまで下書きまでで、最後は必ず人が確認して送ります。さらにスパムと判定したメールには下書きすら作りません。

「便利だが、勝手に送られると怖い」という不安は、自動化を業務に入れる上で必ず出てきます。送信の最終判断を人に残すことで、その不安に構造で答えています。処理後には「要対応（高優先度・FAQ外）」を検知してアラートを出すフックも組み込んでおり、Chatwork / Slack / メールへの通知につなげられる設計です（実通知は連携設定後に有効）。

5. モバイル表示まで作り込み、品質をテストで担保している

問い合わせ対応はPCの前にいるときだけとは限りません。スマートフォン（幅375px）での表示でも、優先度バッジの崩れ・通知の重なり・ボタンの折れが起きないよう調整しています。

裏側のロジックは自動テストで品質を固めており（現在 61 件のテストが通過）、AIを呼ぶ部分はモックに差し替えてテストできる構成です。外部APIに毎回つながなくても挙動を検証でき、第三者が同じ手順で同じ結果を再現できます。

成果（想定モデルケース）

問い合わせの件数が多い窓口ほど、積み重なる効果は大きくなります。

上記は、架空の受信箱8件（見積2・サポート2・クレーム1・営業1・採用1・スパム1）をモックで決定的に処理した想定値です。実際の効果は問い合わせの件数・内容・FAQの充実度によって変わります。数値は想定値で、実APIでの実測ではありません。

データの扱い（機密・架空データ）

入出力サンプルはすべて架空・ダミーのデータで、差出人はサンプル用ドメイン（example.com など）です。実在の社名・個人名・取引先・金額・個人情報は含みません。

また、このシステムは完全自動送信をせず、出力は下書きまでにとどめています。画面に表示する動的な値はすべてエスケープ処理を施し、表示まわりの安全性にも配慮しています。

御社の問い合わせ窓口でも

このシステムは特定のメールツールに縛られず、御社のカテゴリ区分・FAQ・返信トーンに合わせて形を変えられます。Gmail などの既存のメール運用に「乗せる」形で導入でき、受信 → 仕分け → 下書き → 要対応通知までをつなげられます。

「問い合わせ対応の一次返信を軽くしたい」「クレームや急ぎのメールを取りこぼしたくない」「返信のトーンを揃えたい」——そんな課題があれば、お気軽にご相談ください。