受信メールには上限が必要だと気づいた日
受信メールを無制限に扱う設計は、利用が広がるほど費用と処理負荷が積み上がるため、長く続けられないと私は考えています。
この問題をはっきり意識したのは、2026年6月の開発打ち合わせでした。
受信メール一覧の画面や絞り込み条件を確認していたとき、私は話題を変えるようにこう言いました。
「これ本当めちゃくちゃあれだよね。ちょっと上限決めてかないとやばいよな。ほんと受信メールって」
続けて出てきたのが「とてつもない数になりそうなんだよ」という言葉でした。
Dot LinkはSES営業担当の方に届く案件・人材メールを解析し、あとで探したりマッチングに使ったりできる形へ整えるサービスです。
受信メールが増えることは、活用できる情報が増えるという意味では前向きです。
一方で、蓄積する量を決めないままでは仕組みの負担も増え続けます。
50,442件が示した件数の重み
処理済みのメール本文データは、2026年8月24日終了時点で50,442件に達しています。
この数字は利用企業数ではなく、Dot Linkが処理して蓄積したメール本文データの件数です。
打ち合わせでは将来の増加を心配していましたが、その後もデータは積み上がりました。
50,442件という数字を見ると、件数上限は先の話ではなく、現在の設計に必要な判断だとわかります。
営業担当の方が日々受け取るメールは、一度処理して終わるとは限りません。
あとで条件に合う案件や人材を探すためには、過去の情報も一定期間は残しておく必要があります。
新しいメールを取り込みながら過去のメールも扱うため、何も決めなければ対象件数は増え続けます。
増えるのは件数だけではない
受信メールが増えると、取り込みや処理にかかる費用と、一度に扱うデータ量の両方が重くなります。
打ち合わせでも私は「その費用もそうなんだけど、その動作も結構時間かかるだろうな」と話しました。
1件ずつの負担が小さくても、対象が数万件になれば合計は無視できません。
さらに利用する企業や受信するメールが増えれば、処理する件数も継続的に増えていきます。
ここで重視しているのは、単に保存できるかどうかではありません。
メールを取り込み、必要な情報を処理し、営業担当の方が使える状態を保つところまで含めて考える必要があります。
費用と処理負荷のどちらか一方だけを見ても、現実的な上限は決められません。
無制限に扱わないという設計判断
件数に上限を設けることは機能を狭めるためではなく、サービスを継続して使える状態に保つための設計判断です。
上限がなければ、メールが増えるほど費用と負荷も増え、いつか使い勝手に影響します。
ただし、上限を小さくすればよいわけでもありません。
対象件数が少なすぎると、過去の案件・人材情報を活かせる範囲まで狭くなります。
私たちが決めたいのは、システム側に都合のよい数字ではありません。
営業担当の方が必要なメールを扱え、費用と処理負荷も維持できる境界です。
この境界は、実際のデータ量と利用環境を見ながら確かめる必要があります。
試作では1000件に区切った
2026年6月の打ち合わせ時点では、試作画面を軽く動かすため、手元の端末で扱うデータを1000件に区切っていました。
これは正式なサービス上限ではなく、使い勝手を確かめるための開発中の割り切りです。
開発担当からは「今1000件持ってるんですよ。このパソコン側に今1000件持たしてるんですよ」と説明がありました。
サーバーへ毎回問い合わせるのではなく、試作では端末側に一定件数を持たせて確認していました。
同じ1000件でも、開発に使う端末と営業担当の方が普段使う端末では動き方が同じとは限りません。
そのため、私の端末でも実際に動かし、負荷と使い勝手を確かめる話になりました。
まず1000件で体験を確認し、件数を広げたときに何が変わるかを見るという順序です。
1000件は答えではなく検証の出発点でした。
上限は利用環境を見ながら決める
最終的な件数上限は、開発環境だけで決めず、営業担当の方が使う端末や必要な過去データの範囲を見ながら決めるべきだと考えています。
開発側の端末で問題なく動いても、すべての環境で同じ結果になるとは限りません。
一方で、処理負荷を恐れて件数を絞りすぎると、蓄積したメールを仕事に活かす価値が薄れます。
だからこそ、費用と負荷だけでなく、どのくらい過去まで探せれば営業に役立つかも確認する必要があります。
検索時の待ち時間も使い勝手を左右しますが、その実現方法は別の開発テーマとして詳しく扱う予定です。
今回の主題は速さそのものではなく、無制限に抱えず必要な範囲を保つという判断です。
次回はローカル処理案を考える
件数問題への向き合い方は、上限を決めるだけでなく、どこで処理するかを見直すところまで広がりました。
打ち合わせでは、営業担当の方の環境に近い場所でメールを処理できないかという案が出ました。
こちらへすべて集めるのではなく、手元に近い場所で処理できれば、件数や費用の持ち方が変わる可能性があります。
ただし、導入方法や安心して使える形まで含めると、簡単に決められる話ではありません。
この案はその場で採用を決めたものではなく、「頭の片隅に入れておく」検討事項として残りました。
開発日記#2では、このローカル処理案がなぜ出てきたのかと、実現するなら何を考える必要があるのかを振り返ります。
受信メールに複数の案件・人材情報が混在するときの見落としについては、こちらで詳しく紹介しています。
メールを手入力せずに構造化する流れについては、こちらで紹介しています。
