『二度と起こらない仕組みを』と社長に頼まれた30分後——非エンジニア総務がVBAでメール誤送信ガードを作った話
はじめに
お客様のメールアドレスが、外注へのメールに流れていった日のことを、今でも覚えています。
社内からの転送メールに混ざっていたお客様のアドレスを、誰かが気づかずにそのままコピーして、外注先にデータを送ってしまった。よくある凡ミスです。でも、起きたのはうちの会社です。
そのあと、社長が私のところに来て、こう言いました。
「このようなミスが、二度と起こらない仕組みを作ってほしい」
私は田舎の工場の総務です。エンジニアではありません。それでも、最初のVBAは30分後には動いていて、3日後にはNASのWebアプリと連携して、5日後には社外に持ち出されたPCでも壊れない仕組みになっていました。
これは、私が**「自分がいなくても回る仕組み」**にたどり着くまでの、5日間の記録です。
「もうできたの？」と社長は驚いていました
社長から相談を受けたのは、事件が起きた日の午後でした。
「やります」と私は答えました。深く考えずに、です。ただ、何かしないと気が済まなかったのです。お客様のアドレスが意図しない場所に流れたという事実が、ずっと頭の中で回っていました。
最初に考えた仕組みは、とてもシンプルでした。
社内ドメイン以外のメールアドレスに送信しようとしたら、警告ダイアログを出す。それだけです。
VBAなら、Outlookで送信ボタンが押された瞬間に割り込んで（こういう割り込みを「フック」と呼びます）、宛先を見て、自社ドメイン以外が含まれていたら警告ダイアログを出す。コード自体は短く、AIに依頼すれば数分で書いてもらえます。
その日のうちに自分のPCで動作確認まで終えました。社長が私の席に来てから、30分後のことです。
「もうできたの？」と社長は驚いていました。
私自身も「思ったより簡単だな」と感じました。これで誤送信は防げる。もう十分じゃないか、と。
でも、動いた夜に不安になった
その日の夜、自宅で動いた仕組みのことを思い返していて、ふと不安になりました。
これ、私のPCでしか動いていない。
他の社員のPCにも配るとなると、VBAファイルをひとつずつ仕込んでいくことになります。それだけならまだ良いのですが、問題はそのあとでした。
自社のドメインが変更になったら、全員のVBAを書き換える
社外秘ワードを追加したくなったら、全員のVBAを書き換える
検知ロジックを改善したら、全員のVBAを書き換える
私が会社にいない時にトラブルが起きたら、誰も対処できない
これでは、せっかく作った仕組みが、私一人に縛られてしまいます。私が止まれば、全員が止まる。それでは仕組みじゃありません。
「二度と起こらない仕組みを」と頼まれたのに、私が辞めたら回らない仕組みを作ってしまうところでした。
3日かけて、作り直すことにした
ちょうど社内向けに別のWebアプリを動かすためのNASを運用していたので、そこに「メール誤送信ガードのサーバー側」を作ることにしました。
構成はこうです。
各PCのVBAは、メール送信時に社内サーバー（NAS）のWebアプリに「この宛先で大丈夫？」と問い合わせる（この通信の仕組みをAPIと呼びます）
自社ドメインや警告ワード、過去の送信実績はNAS側で一元管理
ロジックの変更は、Webアプリの管理画面から私が変えれば全員に反映される
VBAは、軽い「窓口」だけを残して、判断はサーバー側に集約
これなら、ドメインが変わっても、ワードを追加したくなっても、私が席にいなくても、Webアプリの画面から誰かが操作すれば対応できます。
VBAの再配布を、もう永遠にやらなくていい構成です。
3日ほどかけて、APIの設計と、NAS上のWebアプリの実装と、各PCのVBAの軽量化を進めました。コードはほとんどAIに書いてもらいました。動作確認も済ませて、社内の対象PCに配り終えて、私はようやく息をつきました。
これで終わりだ、と。
そう思っていました。
営業が、社外で詰まった
問題が起きたのは、配布したあと、すぐでした。
営業の方が、ノートPCを持って外出していたのです。社内のNASにはVPNや社内LAN経由でしかアクセスできません。社外に出ると、APIに繋がらない。
繋がらないと、VBAは「サーバーから返事がない」という状態でエラーを起こし、メールが送れなくなります。
メールを送れるようにするための仕組みが、メールを送れなくしている。本末転倒もいいところです。
その日のうちに、いくつもの対策を入れました。
API通信にタイムアウトを設定して、一定時間返事がなければ通信を諦める
通信が失敗した場合は、最低限の社外送信チェック（自社ドメイン以外への警告）だけはVBA側で動かす
通信エラーをユーザーに見せない（送信は止めない）
社内に戻ってからログだけサーバーに同期する
「サーバーが繋がらない時に何をするか」を決めることが、一番難しかったです。完璧を目指すと送信できなくなる、緩めると意味がなくなる。そのバランスを、何度も調整しました。
「ミスを防ぎたいのは、わかります。でも——」
社外対応が落ち着いたあと、営業の方からもうひとつ要望が来ました。
「ミスを防ぎたいのは、わかります。でも、社外との連絡が多い私たちは、毎回確認ダイアログが出ると、正直なところ手が止まってしまうのです」
これは、もっともな話でした。
誤送信を防ぐのは大事です。でも、毎日何十通も社外にメールを送る人が、その都度ダイアログをクリックしていたら、業務がきしみます。何より、何度も同じダイアログを見せられると、人は『考えずに次へ』を押すようになります。それでは仕組みの意味がありません。
そこで、「サイレントモード」を追加しました。
通常モード：社外送信のたびにダイアログが出る（誤送信防止が最大）
サイレントモード：ダイアログは出ないが、裏側で警告ログだけは記録される
ボタンひとつでモードを切り替えできるようにして、サイレントモードのまま翌朝Outlookを起動すると「サイレントモードになっています」とリマインダーが出るようにもしました。
ミスを防ぎたい気持ちと、快適に仕事をしたい気持ち。どちらも大事です。使う人を信頼しながら、安全網は外さない。それが落としどころでした。
一番悩んだのは、技術じゃなかった
実は、ここまでの実装より、ずっと長く悩んだことがあります。
「会社に監視されている」と社員に思われない設計にすること、です。
サーバーで一括管理する以上、「メール本文がサーバーに送られている」と疑われる可能性があります。実際、技術的には本文を送ろうと思えば送れます。だからこそ、最初から、送らない設計にしました。
サーバーに送るのは、
宛先のメールアドレス（@以下のドメイン部分が中心）
件名（社外秘などのワードが含まれているかチェックするため）
本文の先頭ごく一部（「添付します」と書いてあるか判定するため）
それだけです。メール本文の中身そのものは、一切収集しません。添付ファイルの中身も見ません。個人のやり取りの記録も保存しません。
そして、これが一番大事だったのですが、この方針を全社員に告知しました。
「サーバーは、こういう情報だけを見ています。本文は読んでいません」と、書面で伝えました。技術的にそう設計しているだけでなく、そう設計していることを、ちゃんと言葉にして共有する。これがなければ、せっかくの仕組みも「監視されている」という疑念に飲み込まれてしまいます。
技術より先に、信頼を設計する。これが、私が一番時間をかけたことでした。
集めたデータが、別の価値を生み始めた
サーバー側で送信ドメインを蓄積していくうちに、面白いことが見えてきました。
「うちの会社が、どのお客様と、どれくらいやりとりしているか」が、勝手に整理されていくのです。
社員それぞれが普段からどのドメインに送っているかを記録していくと、
いつもA社のXさんに送っていた人が、急にA社の別の方に送ろうとした
B社のドメインが入っているメールに、間違ってA社のドメインのアドレスを足してしまった
こういう「いつもと違う」を、自動的に検知できるようになります。今のところ警告は基本パターンだけですが、この蓄積データは将来の自動学習の燃料になります。
ところで、データを集める仕組みが整うと、他のうっかりミスにも応用が効きます。たとえば添付忘れです。
「添付忘れ防止機能」も追加しました。本文の先頭に「添付します」「添付ファイル」「ファイルをお送りします」のような言葉があるのに、添付ファイルが付いていなかったら警告する、というシンプルなものです。完璧ではありません。でもビジネスメールの定型文は概ね捕まえられます。
ここでも、本文の中身そのものは保存していません。先頭数行を見て、判定して、捨てる。それだけです。
コードは、ぜんぶAIが書いた
ここまで読んでいただいて、「結局あなた、けっこう詳しいんでしょ？」と思われたかもしれません。違います。
VBAのコードは、ほぼ全部AIに書いてもらっています。
私がやったのは、
何を作りたいか、AIに伝える
出てきたコードを試して、動かなかったら状況を伝えて直してもらう
どのモジュールに入れるか、フォームをどう作るかを判断する
設計の方針（集約するか/分散するか、本文を送るか/送らないか）を決める
それだけです。
VBAの基礎知識——モジュールの種類、フォームの作り方、マクロの設置場所——は確かに必要でした。でもそれもAIに聞けば教えてくれます。「自分で書ける」必要はもうないのです。「自分で判断できる」ことだけが必要になりました。
5日でこの仕組みを作れたのは、私が優秀だったからではなく、AIに頼れる時代になったからです。
振り返って気づいた、4つのこと
5日で作って、その後の運用も含めて、振り返って気づいたことが4つあります。
集約できるところは集約する——VBAを各PCに配り続ける運用は、いつか必ず破綻します。判断ロジックは、できるだけ1箇所にまとめる
障害時のフォールバックを決めておく——サーバーが繋がらない時、どこまで動かすか・どこから諦めるかを最初に決める
使う人のモードを尊重する——「常時厳格」では、使う人が考えずにクリックするだけになる。状況に応じて切り替えられる余白を残す
信頼を設計に組み込む——「監視されている」と思われた瞬間、仕組みは敵になる。何を見ていないかを、技術と言葉の両方で示す
5日で作って、その後の運用で見えてきたことです。技術書には載っていない、現場で動かしてみないと気づけなかったことでした。
おわりに——「コードは差し上げません」
ここまでお読みいただき、ありがとうございました。
もし「自社でも作ってみたい」と思った方へ。
コードは差し上げません。
私の会社のために作ったものなので、あなたの会社にそのまま入れてもフィットしないからです。それに、人が作ったものを動かしていると、何かあった時にその人のせいにしたくなるじゃないですか。私もそうです。だから、自分で作ったほうがいいのです。
でも、ゼロからは大変です。だから、私が5日の実装と、その後の運用で気づいた「AIに何を聞くか」「どこで悩むか」「どこで失敗するか」を、別の記事にまとめました。
完成品ではなく、あなたの会社に合わせて、AIと一緒に自分で作るための地図です。プロンプト集と、設計判断の論点リストと、私のつまずき記録の3部構成。
→ 伴走編「自社用メール誤送信ガードを、自分で作る人のための実装地図」を公開しました（¥980）：
読んでみて、それでも詰まった時は、メールで一言ご相談ください。今は無料テスト中です。一人ずつ、丁寧にお返事します。
この記事が、同じことで困っている誰かの背中を、少しでも押せたら嬉しいです。
「うちでも作れるかも」と思っていただけたなら、それが私の一番欲しかった反応です。
もっと読みたい方へ（関連記事）
見積もり300万円のシステムを、月1.5万円で自作した——中小製造業の総務がAIで社内DXをやっている話
社内システムを自作するときの費用感と、決裁を取るときの考え方NASでWebアプリを動かす方法——中小企業がDocker+AIで社内システムを自作した話
今回登場したNASのWebアプリ基盤の作り方IT人材ゼロ・予算ゼロでも「自分で作る」時代が来ている——中小製造業の現場担当がAIで業務ツールを自作している話
今回の記事と同じ「自分で作る」哲学の背景にあるもの
質問・感想・「うちはこうしてるよ」のお話、コメントで遠慮なくお聞かせください。
この記事が参考になったら、スキ・フォローお願いします。
いいなと思ったら応援しよう！
気が向いたらコーヒー奢ってください。泣きながら喜びます。また奢ってくれた人いたら感謝しながら拝み奉ります。