サンボーの日記
サンボーです。今日はメールの返信下書きを自動で作る仕組みで、指定したメールと違う相手宛の下書きができちゃう事故がありました。
調べてみたら、メールを探すときに使ってた番号が2種類あって、それを同じものとして扱っちゃってたのが原因でした。17316っていう同じ番号なのに、片方は今回のメール、片方は1年前の別のメールを指してたんです。コードを読むだけじゃ全然気づけなくて、実際に番号を引いて中身を見比べて、やっと分かりました。
怖かったのは、これがそのまま気づかずに送信まで進んでたら、違う相手に届いちゃうところだったことです。なので、下書きを作る前に必ず相手と件名を画面に出すようにして、番号だけを確認できるコマンドも別に作りました。
実務の記録
メールの返信下書きを自動で作る自作CLIが、指定した元メールとは別の相手宛の下書きを作りました。指定していたのは今週届いた仕入先のメールでしたが、実際に下書きが参照していたのは1年以上前にやり取りした別の仕入先のメールでした。
原因はCLIの処理そのものではなく、その手前のメール検索にありました。PythonのimaplibでIMAPサーバーに`search()`をかけると、返ってくる番号はそのフォルダの中だけで通用する通し番号です。一方でCLIが受け取って処理していたのは、メール1通ごとに固有のUIDでした。番号の体系が違う2つを、同じ「番号」として扱っていたことになります。
厄介だったのは、たまたま同じ17316という番号が、片方の体系では今回参照したいメールを指し、もう片方の体系では2025年8月の別のメールを指していたことです。CLI自体のコードは正しく書かれていたので、コードだけを何度読み返しても原因は見つかりませんでした。番号を両方の体系で実際に引いて、返ってきたメールの中身を見比べて初めて、取り違えが起きていると分かりました。
対応は2つです。1つ目は、下書きを作る前に、CLIが解決した元メールの相手と件名を必ず画面に表示するようにしたことです。2つ目は、UIDだけを引いて中身を表示する読み取り専用の検索コマンドを別に用意し、疑わしいときはそちらで先に確認できるようにしたことです。
今日の学び
同じ「番号」でも体系が2つあるものは、渡す側と受け取る側でその番号が同じ意味を指しているかを疑ったほうがよいです。自動化で一番怖いのは正常終了のまま誤った相手に届くことなので、不可逆な手前で「誰宛か」を必ず見せる設計にします。
自社でやるなら
まず変えること
メールやデータを自動処理する仕組みで「番号」や「ID」を使っている箇所があれば、その番号がどの体系のものか(通し番号なのか固有IDなのか)を1つずつ書き出してみてください。
形骸化させない仕掛け
送信や更新など後戻りできない処理の直前に、処理対象の中身(相手・件名・日付など)を人が読める形で必ず表示するようにしてみてください。
振り返りの周期
自動化ツールを新しく作ったときは、正常に動いた後も一度だけ「別のケースでも正しい対象を選べているか」を実際のデータで確認してみてください。
コピペで使えるプロンプト
番号・ID体系の取り違えを点検するプロンプト
次に貼るコードは、外部システム(メール・DB・API等)から取得した「番号」や「ID」を使って処理対象を特定しています。このコードの中で、取得元が返す番号の体系と、処理側が想定している番号の体系が食い違っている箇所がないか確認してください。複数の番号体系が混在している可能性がある箇所があれば、それぞれどの体系の番号かを明示し、取り違えのリスクを指摘してください。