問い合わせ窓口のメールを担当部署へ振り分ける作業は、多くの中小企業で朝一番の定型業務になっています。件名と本文をざっと読み、営業か、サポートか、請求に関することかを判断して転送する。一件あたりは数十秒でも、日に数十件あれば無視できない時間です。生成AI（文章を理解して分類や要約ができるAI）を使えば、この判断の大半は自動化できます。
ただし、振り分けAIの成否を分けるのは精度そのものではありません。「AIが判断しきれないものを、どういう条件で人に戻すか」を先に決めたかどうかです。ここが曖昧なまま動かすと、精度が高くても現場は安心できず、結局すべてを目視で再確認することになります。この記事では、導入の流れと、人に戻す条件（エスカレーション条件）の決め方を順に整理します。
なぜ「振り分け」はAI導入の入口として向いているのか
AIを業務に入れるとき、いきなり返信文の自動生成まで行こうとすると難易度が跳ね上がります。文面を外部に出す以上、誤った内容を送った時点で取り返しがつかないからです。
これに対して振り分けは、次の条件を満たします。
- 出力が有限の選択肢である（部署名、カテゴリ名、優先度など）。自由な文章ではないため、正誤の判定がしやすい
- 間違えたときのコストが比較的小さい。誤った部署に届いても、転送し直せば回復できる
- 既存の正解データが社内にある。過去に人間が実際に振り分けたメールが、そのまま教師データ兼テストデータになる
この「間違えたときのコスト」と「業務の輪郭のはっきりさ」は、AIを入れる業務を選ぶときの基本的な物差しです。この観点は「とりあえずノーコード」で失敗しないために — AI導入の分かれ目は「業務の輪郭」と「間違えたときのコスト」でも整理しています。
設計の単位は「ラベル」「確信度」「根拠」の3つ
振り分けAIに出させる情報は、カテゴリ名ひとつでは足りません。実務で回すには最低限、次の3つをセットで返す設計にします。
| 出力項目 | 内容 | なぜ必要か |
|---|---|---|
| ラベル | 振り分け先の区分（例：見積依頼、障害報告、請求照会、採用、その他） | 転送先を決めるため |
| 確信度 | その判断にどれだけ自信があるかの度合い | 人に戻すかどうかの判定に使う |
| 根拠 | 判断の決め手になった本文中の記述 | 誤りの原因を後から追うため |
特に確信度は要注意です。大規模言語モデル（大量の文章で学習した言語AI）に「確信度を0から100で出して」と指示すると数値は返ってきますが、その数値が実際の正答率と一致している保証はありません。高い数値を返しながら間違えることもあります。
そのため、確信度はそのまま信じるのではなく、過去メールで実測して閾値を決めるのが現実的です。たとえば確信度90以上と自己申告した分類だけを集めて、実際の正答率がどうだったかを数えます。期待より低ければ、閾値を上げるか、確信度以外の条件（後述）を組み合わせます。
導入の流れ — 5つのステップ
1. 現行の振り分け実態を棚卸しする
最初にやるのは、AIの検討ではなく現状の記録です。直近1〜2か月の問い合わせメールを対象に、実際にどのカテゴリへ何件振り分けたか、人間でも迷ったものが何件あったかを数えます。この段階で「そもそもカテゴリの定義が担当者ごとに違う」という問題が見つかることが珍しくありません。人間が揺れている基準を、AIが安定して再現することはできません。
2. ラベル体系を絞る
カテゴリは多いほど便利そうに見えますが、分類は選択肢が増えるほど難しくなります。まずは5〜8区分程度に抑え、どこにも当てはまらないものは「その他（要人手）」に落とす設計にします。細分類は、運用が安定してから足す方が安全です。
3. 評価用データを先に作る
プロンプト（AIへの指示文）を書く前に、正解ラベル付きのメールを百件単位で用意します。難しいもの、紛らわしいもの、添付ファイルだけで本文が空のものを意図的に混ぜるのがコツです。この評価データがないと、改善したつもりが別のパターンを壊していることに気づけません。評価データの作り方はAI の「良くなった気がする」を卒業する — 評価データセットの作り方と運用で詳しく扱っています。
4. 影の運用（シャドー稼働）で並走させる
いきなり自動転送を始めず、AIの判定結果を記録するだけで、実際の振り分けは従来どおり人が行う期間を設けます。数週間並走させると、カテゴリごとの得意不得意がはっきり見えます。「請求照会は安定しているが、障害報告と仕様質問の区別が弱い」といった傾向が分かれば、自動化する範囲を部分的に決められます。
5. 得意なカテゴリから段階的に自動化する
全カテゴリを一度に自動化する必要はありません。並走期間で安定していた区分だけを自動転送に切り替え、残りは人の確認を挟む。この部分自動化が、現場の納得を得ながら進める最短路になることが多いです。
人に戻す条件は、確信度だけで決めない
エスカレーション条件を「確信度が閾値未満のとき」だけにすると、取りこぼしが出ます。AIが自信満々に間違えるケースを拾えないからです。確信度に加えて、内容そのものの性質で強制的に人へ回す条件を併用します。
| 条件の種類 | 具体例 | 扱い |
|---|---|---|
| 確信度 | 自己申告の確信度が閾値未満 | 人の確認へ |
| 候補の競合 | 上位2つのラベルの差が小さい | 人の確認へ |
| 語句による強制 | 「解約」「クレーム」「弁護士」「個人情報」「訴訟」などの語を含む | 確信度にかかわらず人へ |
| 送信元の属性 | 重要取引先、官公庁、報道関係のドメイン | 確信度にかかわらず人へ |
| 形式の異常 | 本文が極端に短い、添付のみ、文字化け、長文すぎる | 人の確認へ |
| 金額・期限 | 一定額以上の記載、当日中などの期限表現 | 人の確認へ |
重要なのは、これらの条件を誰がいつ見直すかまで決めておくことです。語句リストは放置すると古くなります。月次で誤振り分けの記録を見ながら、条件を足し引きする担当を置きます。
また、人に戻した後の動線も設計対象です。「保留フォルダに入れる」だけでは、誰も見ない箱ができるだけです。戻した件がいつまでに誰の手元へ行くのか、未処理のまま一定時間が過ぎたら誰に通知するのかまで決めます。
実装で詰まりやすい3つの箇所
メールの形式が想定より汚い
実際のメールは、引用の連なった長い返信、HTMLメールのタグ混じり、署名に大量の情報、転送による多重入れ子など、形が整っていません。本文から判断に必要な部分だけを取り出す前処理が、想像以上に工数を食います。見積もり段階で「本文抽出の前処理」を独立した項目として確認しておくと認識のずれが減ります。
個人情報と機密の扱い
問い合わせメールには、氏名、電話番号、取引内容などが含まれます。外部のAIサービスへ本文を送る構成にする場合、個人情報の保護に関する法律（個人情報保護法）の観点から、委託先の管理や利用目的との整合を確認する必要があります。個人情報保護委員会が生成AIサービスの利用に関する注意喚起を公表しているので、自社の運用がそれと矛盾しないかを点検しておくと安心です。送信前にマスキング（氏名や番号を伏せ字に置き換える処理）を入れるか、分類に不要な部分は送らない設計にするかは、早い段階で決めるべき論点です。入力段階での遮断の考え方はAIに渡せない入力を止める手順 — 判定・遮断・案内の設計にまとめています。
ログが足りず、誤りの原因を追えない
「先週、問い合わせが別部署に飛んだ」という指摘を受けたとき、そのメールに対してAIがどのラベルを、どの確信度で、どんな根拠で出したかが残っていないと調査が止まります。入力（前処理後の本文）、出力（ラベル・確信度・根拠）、使用したモデルとプロンプトの版、判定日時は最低限記録します。
効果をどう測るか
導入効果を「削減時間」だけで語ると、評価が感覚的になりがちです。次のような指標を並走期間から取っておくと、後で説明がしやすくなります。
- 自動転送された件数と、その中で後から修正された件数
- 人に戻した件数と、その内訳（確信度不足、強制条件、形式異常）
- 受信から一次対応開始までの時間
- カテゴリ別の誤振り分け率の推移
削減時間は業務量や体制によって大きく変わるため、他社の数字を自社にそのまま当てはめる意味はあまりありません。自社の並走期間の実測値を基準にするのが確実です。
まとめ
問い合わせメールの振り分けは、出力が有限で、間違えても回復でき、過去データが社内にあるという点で、AI導入の入口として扱いやすい業務です。進め方としては、現状の棚卸し、ラベル体系の絞り込み、評価データの準備、並走による実測、得意カテゴリからの段階的な自動化という順序が現実的です。
そして設計の中心は精度ではなく、人に戻す条件です。確信度の閾値だけに頼らず、語句、送信元、形式、金額や期限といった内容面の強制条件を組み合わせ、戻した後の動線と見直しの担当まで決める。ここまで固めて初めて、現場が目視の二重確認をやめられます。
完全自動化を最初のゴールに置かず、「どこまでをAIに任せ、どこからを人が持つか」の線引きを文書として残すこと。それが、止まらずに回り続ける振り分けの仕組みにつながります。