この記事の位置づけ
AI活用コンサルタントとして中小企業の現場に入ると、最初の壁はほぼ毎回同じ技術的な問題ではなく、試し方の問題である。営業部門、事務部門、配送管理のような現場では、「AIを使ってみよう」という空気はあっても、何を、どの範囲で、どう判定すれば「使える」と言えるのかの基準がない。基準がないまま試すと、印象論で終わり、導入判断が宙に浮く。
本稿では、非エンジニア部門が最初の検証対象として「受注メールの分類」を選ぶ理由と、2週間で回せる小さな検証の手順を、架空の物流会社の例で示す。技術的な前提知識は不要なように書いた。
なぜメール分類なのか
導入の最初の検証対象には、次の4つの条件を満たす業務が適する。
- 入力がテキストで完結する（紙の帳票の読み取りなど、前処理が不要）
- 人がすでに判断基準を持っている（分類の正解が現場の頭の中に存在する）
- 判断結果が即座に検証できる（翌日に困るような不可逆な処理ではない）
- 量が十分にある（1件ずつ人の手で確認しても、2週間で統計が持つ程度の件数がある）
受注メールの分類は、この4つをほぼ同時に満たす。「新規受注」「変更・修正」「キャンセル」「問い合わせ」「営業の案内、つまり不要」程度の5分類なら、どの現場でもすでに暗黙の基準がある。そして処理を誤っても、人の最終確認が残っていれば取り返しがつく。
逆に、検証の最初の対象として避けたいのは「見積書の自動作成」のような、出力の正解が現場にも固まっていない業務である。正解がない仕事をAIに任せても、正解のない判定を比較するだけになり、検証にならない。
架空の例：中小物流会社A社の受注メール
以下は説明のための架空の例である。実在の企業や数値ではない。
- 従業員40名程度の物流会社。受注窓口は事務2名。
- 取引先からの受注はメールで届く。1日30〜60通。
- メールはまず事務が読んで、「新規受注」「変更」「キャンセル」「問い合わせ」「その他」に仕分けし、新規と変更だけ社内の受注台帳に入力する。
- 悩みの種は2つ。分類の待ち時間と、変更案件の見落としである。変更案件は締め時間との関係で扱いが敏感で、見落としが現場の信頼を直接損なう。
この状況に対し、AIに「分類だけ」を任せてみることを提案する。台帳への入力は任せない。メール本文と件名を渡して5分類を返させるだけである。出力は事務が全件確認し、AIの分類と事務の分類を記録していく。
2週間の検証手順
準備（初日）
- 分類の基準を1枚の文書に書き出す。ここが検証の質を決める。現場が「なんとなく」でやっている判断を言葉にする作業であり、AI以前に価値がある。
- 「変更」と「問い合わせ」の境界を例文で定義する。たとえば「届け日を変えてほしいという本文の有無」のように、言葉ではなく条件で決める。
- 判定の記録表を用意する。列は「メール番号」「事務の分類」「AIの分類」「一致/不一致」「気づいたこと」の5列で足りる。
1週目：AIの出力を観察する
- 1週間、すべての受注メールをAIに分類させ、事務の分類と突き合わせる。この段階ではAIの分類を業務には使わない。
- 不一致のメールを種類分けする。大半は3種に落ちる。(a) 基準が曖昧だったために人も揺れたケース、(b) 長いメールの末尾に別件が紛れていたケース、(c) 基準どおりだがAIが条件を拾えなかったケース。
(a)が多い場合は、AIの前に現場の基準の整備が未了という信号である。(c)が多い場合は、プロンプトの修正か、そもそもその分類をAIに任せない判断になる。
週末：使うか使わないかを分類別に決める
- 一致率を分類別に見る。全体の平均一致率は意思決定に使わない。重要なのは「新規受注」と「変更」だが、それぞれで一致率とリスクが違うからである。
- 架空のA社ではこう判定する、という例を示す。変更案件の一致は高かったが、見落としの許容度が低いため、変更は「AIが分類し、事務が必ず確認」の二重化にする。新規受注は一致が安定していたので「AI分類のまま台帳入力へ進めてよい」の候補に置く。キャンセルと問い合わせは件数が少なく判定材料が不足したため、2週目に持ち越す。
分類ごとに使う/使わないを分けるのが要点である。「AI全体として使えるか」という問いは現場の判断として粗い。
2週目：使うと決めた分類だけ運用に混ぜる
- 使うと決めた分類のみ、AIの出力を業務フローに組み込む。事務はAIの分類を前提に作業し、違和感があれば差し戻す。
- 差し戻しの記録も同じ表に続ける。ここで増える不一致は、運用混載によって生じたものなので、1週目の数値とは混ぜて平均しない。
- 2週間の終わりに、残る項目は3つに絞る。事務の処理時間が変わったか（体感でよい、まず記録した事実として）、変更の見落としの不安が減ったか、AIに渡す前後で個人情報の扱いに問題がなかったか。
検証で共通して失敗する3点
- 一致率の総合値で判断する。 平均は「使う前提のない分類」まで含めて良好に見せがちである。分類別に見ないと、危険な部分が隠れる。
- 基準文書を作らずに始める。 現場の判断が文書化されていないと、不一致が「AIが悪い」のか「人が基準を守っていない」のか分からなくなり、検証が主観に戻る。
- 検証と運用の数値を混ぜる。 1週目は観察、2週目は運用で、条件が違う。混ぜると改善なのか劣化なのか因果が読めない。
導入判断への接続
2週間の検証が終わった時点で、経営側に提出すべきものは3行で足りる。
- どの分類を、どういう確認条件下でAIに任せたか
- 任せていなかった場合と比べ、人の手間と取りこぼしのリスクがどう変わったと現場が判断したか
- 次に同じ手順で試す候補業務は何か
大掛かりなシステム導入の判断ではない。メール分類のような小単位の検証を数こなすことで、「この会社ではAIの判断を使う条件をどう決めるか」という社内の共通言語が先にできる。後の大きな導入判断は、その言語の上に乗る方が安定する。小さい検証から始める最大の理由は、技術の性能ではなく、この判断の型を社内に残すことにある。
水原聡 / AI活用コンサルタント。本稿は架空の例に基づく手順の解説であり、特定の企業・製品の実績の紹介ではない。