ローカル処理という案が出た背景
結論から言えば、ローカル処理の案はメールの件数や検索速度だけでなく、処理する場所そのものを見直せないかという発想から出てきました。
これは実装済みの機能や現在の正式方針ではなく、2026年6月24日の打ち合わせで検討したアイデアの記録です。
打ち合わせでは、利用する会社やメールの数が増えたときに、すべてを運営側で受け取って処理し続ける形でよいのかを話していました。
その流れで私は「めちゃくちゃ突拍子もないこと言うようで言うんだけどさ」と前置きして、メールを利用者の環境内で扱う案を出しました。
メール量と上限の問題は開発日記#1で扱ったため、今回はその先に出てきた「どこで処理するか」という話に絞ります。
【開発日記#1】受信メールが「とんでもない数」になる問題とどう向き合っているか
利用者の環境内で完結させる発想
検討したのは、利用者が日々受信しているメールを外部へ集めず、その環境内で検索やマッチングに使えないかという案です。
打ち合わせでは「本当のローカル」という言葉を使い、利用者側へ何らかのツールを渡し、月額で使ってもらう形を思い描きました。
利用者のメール環境の中で検索ツールが動けば、運営側へメールを集めてから検索結果を返す構成とは処理の流れが変わります。
利用件数が増えるたびに運営側の処理量が膨らむ問題も、別の分担にできる可能性がありました。
ただし、この時点では具体的な仕様が決まっていたわけではありません。
あくまで「利用者の環境内で処理する形はあり得るか」を話し始めた段階でした。
メール転送への拒否感をどう考えたか
ローカル処理を考えた大きな理由は、受信メールを外部へ転送することに抵抗を感じる方がいると想定したためです。
会社によっては業務用の共通アドレスがなく、個人の業務アドレスへ届くメールを扱わなければならない場合があります。
そのときに「受信メールが全部そちらに届くのではないか」と感じる方がいるのは自然です。
機能として処理できるかどうかだけでなく、利用者が安心してメールを預けられるかという問題が残ります。
利用者の環境からメールを出さずに済むなら、この拒否感を減らせるかもしれません。
一方で、処理場所を変えればそれだけで信頼の問題が解消するわけではないことも、後の議論で見えてきました。
情報を見せない相手を制御する考え方については、別の記事で整理しています。
API案からChrome拡張機能案へ
「APIみたいな形」という私の案に対して、実現方法として近いものに挙がったのがChrome拡張機能でした。
ここでのAPIは完成した技術仕様を指す言葉ではなく、利用者側へ処理手段を渡すイメージを表したものです。
打ち合わせでは、ブラウザでGmailなどのメール画面を開き、拡張機能で検索用のフィルターや操作画面を表示する形を話しました。
メール画面の横に検索ツールが現れ、その場で必要な情報を絞り込めるなら、外部の画面へ移動せずに使える可能性があります。
ただし「できなくはない」という検討段階であり、Chrome拡張機能を作った実績や、各メールソフトで同じように動くことを確認した話ではありません。
ブラウザでメールを開く前提や、どのメール環境まで対応できるかも未整理でした。
処理コストを利用者側へ持たせる可能性
利用者側で処理する構成には、検索やAI処理の費用を利用者側へ持たせられる可能性もありました。
打ち合わせでは、利用者自身がAPIキーを設定し、その利用者のブラウザで処理する案も話題になりました。
この形なら、利用会社やメール件数が増えるほど運営側のAPI費用が増え続ける構造を変えられるかもしれません。
ただし、費用を誰が持つかを変えることは、単なる技術上の調整ではありません。
APIキーの準備や設定を利用者へ求めれば、導入の手間や使い始め方も変わります。
コストを移せるという利点だけで採用を決められる案ではありませんでした。
Chrome拡張機能に残る信頼の壁
Chrome拡張機能には転送を避けられる可能性がある一方で、拡張機能そのものを信頼してもらえるかという課題がありました。
メール画面へアクセスする拡張機能を入れてもらうには「ほかの情報まで見られないか」と不安を持たれる可能性があります。
外部転送への抵抗を減らすための仕組みが、別の不安を生むのであれば、安心の説明を作り直さなければなりません。
また、普段使っているメール画面を拡張機能で変える導入方法が、企業向けサービスとして受け入れられるかもわかりませんでした。
メールを外へ出さないことと拡張機能を信頼できることは別の問題です。
処理場所をローカルへ移すだけでは、導入時の信頼まで自動的に得られるわけではないと感じました。
一旦見送った理由
すぐに着手しなかった最大の理由は、ローカル処理へ寄せるとサービスのコンセプトが大きく変わるためです。
メールを運営側へ集めて処理する考え方と、利用者側へ処理手段を渡す考え方では、設計だけでなく提供方法やコストの持ち方も変わります。
さらにChrome拡張機能の導入、対応するメール環境、APIキーの管理、利用者への説明など、決めるべきことが増えます。
転送への拒否感やコストの問題に対する可能性は感じましたが、その利点だけを見てすぐに方向転換する段階ではありませんでした。
打ち合わせの最後には「ちょっと頭の片隅に入れといてみてください。とりあえずすぐそれやろうって話じゃないけど」とまとめました。
この言葉が、当時の判断をいちばん正確に表しています。
頭の片隅に置くという結論
ローカル処理は却下した案ではなく、利点と課題の両方を認識したうえで保留にした案です。
メールを外部へ転送しない安心感、運営側へ処理を集中させない構成、利用者側にコストを持たせる可能性には検討する価値があります。
一方で、拡張機能への信頼や導入の手間、サービスのコンセプト変更まで含めて判断しなければなりません。
そのため打ち合わせ時点では、すぐに作らず頭の片隅に置くという結論にしました。
実際に採用するなら、転送方式との比較だけでなく、利用者がどちらを安心して使えるかを確かめてから決めたいと考えています。
メールを手入力せず構造化する考え方は、こちらの記事で紹介しています。
