サンプル電機のメール確認デモ

想定した課題・業務フロー

総務・経理で受け付けたメールについて、発注・受領・申請番号・登録済み連絡先・過去のやり取りを照合する場面を想定しました。単語だけの分類では、開示を防ぐ研修通知を要確認にしたり、認証コードの開示要求を見落としたりします。分類だけで終わらず、必要な確認と担当者の判断理由を残すことを課題にしました。

実施内容

架空の会社「サンプル電機」のメール20通を、初回はすべて人の確認待ちとして表示します。保存済み候補は通常候補8通・要確認8通・文脈不足4通で、文脈不足の1通は候補なしです。候補・理由・不足情報・確認状態を一覧で見て、単語だけの方式と食い違うメールに絞れます。メールごとに原文と業務記録を照合し、架空の担当者名・区分・必須の理由を保存できます。「AIを見ずに先に判断」では候補を隠し、20通を判断してからAI候補と照合できます。判断履歴はJSONで書き出せます。

使った技術

Node.js、ブラウザの画面、ローカル専用サーバー、JSON。追加の依存・APIキー・DBは不要です。

AIと人の役割

検証で扱った課題・制約

• 元の検証ラボでは、単語の有無だけで研修通知と認証コードの開示要求を分けられませんでした。修正版では要求される行動と業務記録を理由欄に残しました。
• 初版では、過去の相談や承認記録がないメールも通常候補に入りました。修正版では文脈不足の区分と不足情報を残しました。実業務で必要な記録が見つかるかは未確認です。
• 元の検証ラボの修正版には、人の判定との食い違いが9通残りました。担当者1名が1回、AIの想定表・候補・理由を見ずに判定しましたが、人の理由や複数人の判定は未取得です。要確認と文脈不足が重なる場合の基準も未整理で、どちらが正しいかは決めていません。

検証から得た学び

• 分類候補だけでなく、原文・理由・不足情報を添えて人に渡すことを重視しました。通常候補も自動承認せず、すべて確認待ちにします。
• 本文内の「確認済み」やAIへの指示は確認の根拠にしません。元の検証で短い1例を処理できたことは、不正な指示全般への耐性を示しません。
• 元の検証は、同じAIが作った短い架空メール・業務記録と、人1名・1回の判断との照合です。一致件数の増加だけで改善や安全性を断定できず、検出精度・正答率・実業務の効果を示す評価ではありません。

同様の取り組みが向いている条件

• 総務・経理のメール受付後に、照合する業務記録と確認担当者を決め、判断理由を残す流れを検討したい場合。
• 通常候補・要確認・文脈不足の基準を業務に合わせて整理し、人の判断とAI候補の食い違いを確認したい場合。
• 口座変更や情報開示を登録済みの別経路で確認し、分類候補を自動承認につなげない運用を検討できる場合。

補足

2026年10月13日公開の、架空データで業務の流れを試すデモです。実メールの取り込み、送信者認証、添付・長いスレッドの処理や実運用での確認・承認の成果を示すものではありません。向いている条件は想定業務と元の検証ラボから整理したもので、導入適性や効果を実証したものではありません。