Cloudflare Workersで動く独自ドメイン向けメールクライアントを導入・改善した
Date: 2026-07-21
## 作ったもの
Cloudflare Workersで動く独自ドメイン向けメールクライアント「agentic-inbox」を導入して、さまざまな機能を追加した。
## 経緯
今月上旬くらいにこんなツイートが流れてきてリポジトリを見てみたら、自分のやりたかったことの多くが実現されていて便利そうだったので、導入してみることにした。
## agentic-inboxについて
agentic-inboxは、Cloudflare Workers上で動作するCloudflareで管理する独自ドメインのためのメールクライアントである。
Cloudflare Email ServiceのEmail Routingでメールを受信して、Email Sendingでメールを送信し、データをCloudflare R2/Durable Objectsに保存して、Web上のメールクライアントで閲覧できるというアプリケーションである。
また、メールの受信に必要なEmail Routing自体は無料だが、メールの送信に必要なEmail SendingはWorkersのPaidプランに加入する必要があり、最低月額5ドルかかる。
## これまでのメールの運用方法
これまでは、Cloudflareで管理している自分のドメイン宛のメールを、CloudflareのEmail RoutingのRouting rulesを使って、私用のGmailに転送して受信していた。
また、Gmailの設定の「別のメールアドレスを追加」から、自分のドメインのメールアドレスを追加することで、
smtp.gmail.com経由でそのアドレスを送信元としてメールを送っていた。この方法だと、GmailのUIでメールを受信できるし、GmailのUIでメールを送信できるので、便利ではあった。
## agentic-inboxを導入した理由
GmailやGoogleドライブやGoogleカレンダーが便利なのは間違いない。
しかし、Googleのサービスに依存している以上、一度GoogleアカウントがBANされたら、メールの送受信ができなくなるうえ、これまでに送受信したメールの内容も見られなくなるというリスクがある。
その便利さゆえに生活の大部分をGoogleのサービスに依存している状況で、もしもBANされたときにGmailやGoogleアカウントを使ってログインしている各種サービスの利用まで危うくなる、というのはソフトウェアエンジニアが個人で使うインフラとして健全であるとは言えない。
これに対して、定期的にGoogle Takeoutでバックアップを取得して、
.mbox形式で保存しておくという手段もなくはないが、Takeoutは増分エクスポートできないため、全データのバックアップを定期的に取って管理するのも面倒であり困っていた。ただし注意点として、agentic-inboxは機能的に未成熟な部分が多く、GitHubを見る限り開発はあまり活発ではなく、2026年7月21日現在、mainブランチは4月17日以降更新されておらずIssueもPRもあまり反応がないように見えるため、現状の機能で満足できるかどうかは人によると思う。
ただ、それを差し引いたとしても、私はこのソフトウェアに強い可能性を感じたので、agentic-inboxをフォークして自分が使いたいように改善しながら使っていこうと決意した。
ただし、いつまでこの決意が続くかは不明。
## agentic-inboxの導入
この記事を参考に、ぽちぽちしてWorkers Paidプランに月額5ドル払って導入した。
「Deploy to Cloudflare」ボタンを押して、Cloudflare側でWorkers周りをいい感じに設定するだけで、GitHubのプライベートリポジトリが作成されて、Cloudflare Workersにデプロイされるので、導入は非常に簡単だった。
## 実装したコード
今回実装したコードは以下のリポジトリのdevelopブランチに置いてある。
mainブランチは、元リポジトリの変更を取り込むために手を付けず、developブランチのコードが本番環境にデプロイされるようにしてある。
よくdevelopブランチに直コミット直プッシュしているが、元々公開するつもりもなく、自分しか見たり使ったりしないつもりのWorkerのコードだったのでまぁこうなっている。
## 実装した機能
以下のような機能を追加して改善してみた。
ここまでやってようやく個人的に使いやすくなった。
実際に私がやったことは、欲しい機能の実現可能性や要件をAIと壁打ちしただけで、設計と実装は全てAIがやってくれた。良い時代だと思う。
### 転送先関連
- - メールボックスごとに転送先を個別に設定
- - 宛先のメールボックスが存在しないメールを受け取るcatch-allメールボックスの設定
- - 転送失敗時の再試行
- - ドメインごとのデフォルトの転送先設定
### Gmailからの移行関連
- - Google Takeoutから
.mbox形式でエクスポートした過去の送受信メールをインポートする機能
### メールボックス関連
- - メールボックス一覧での未読数・保存メール数の表示と、未読が存在するときに背景色を変更
- - メールボックスを最新メール日時順とアドレス名順で並び替え
- - メールボックスをさまざまな条件ごとのカテゴリに分けて表示
- - 正規表現やメールアドレスのリストなどの条件ごとにメールボックスを分類
- - 未読メールがあるメールボックスだけを表示するカテゴリ
- - カテゴリの中にカテゴリを作ることも可能
- -
### メール関連
- - HTMLを含まないプレーンテキストメールの改行を正しく表示するよう修正
- - 同じ会話に属するメールをスレッド形式で表示
- - AI下書きを自動生成せずに、メール閲覧時にボタンを押したときだけ生成するように変更
- - これはもはや「agentic-inboxって呼んでいいのか？」ってくらいの変更だけど、AI下書きは便利とはいえ自動ですべてのメールに下書きが作られるのは邪魔だし計算資源の無駄だし、何より返信する必要のあるメールなんてごく一部しかないので……
- -
## 感想
とりあえず、自分が使う上で必要な機能は実装できたので、今後もこのメールクライアントを改善しながら使っていくつもりである。
もちろん、今回の方法でクラウドへの依存がなくなったわけではなく、GoogleからCloudflareへ依存先を移しただけであり、外部のメールサービスに依存しないようにするには、弊研究室のようにメールサーバをセルフホストするしかない。
実際の運用では、転送先にGmailのアドレスを設定し、各端末で通知を受けながらGmail上でも内容を確認できるようにしている。
これでは当初の目的に反するように見えるかもしれないが、「Gmailを交換可能な通知兼転送先にする」・「Googleアカウントを独自ドメインのメールの単一障害点にしない」という意味でGoogleへの依存度ははるかに低く、精神的に良い。
メールを特定のクラウドに依存したくない一方で、メールサーバを自前で立てて運用するのは辛いという二つの思いの狭間で揺れていた自分にとって、すでにドメイン自体を管理しているCloudflareのEmail Serviceでメールを送受信し、Workers, R2, Durable Objectsで保管・管理するという構成は、十分すぎる妥協点だった。
そのためのWorkers Paidプランの月5ドルなんてドメインの維持費とそう変わらないレベルであり、Cloudflareには本当に頭が上がらない。