Relay API設計:Cloudflare Workersでメール送信基盤を構築
1. なぜ外部メールプロバイダのAPIを使わなかったのか
メモをメールで送信するアプリを作るとき、最初に思い浮かぶのは大手メールプロバイダの送信APIです。しかし、個人開発者にとってGoogle OAuth審査のハードルは極めて高いものでした。
Google OAuth審査を通過していないアプリには、「このアプリはGoogleで確認されていません」という警告画面が表示されます。メモアプリにとって、この警告は致命的です。ユーザーは自分の考えや個人的な情報をメモとして送信します。その最初の体験で「検証されていません」と表示されたら、誰がこのアプリを信頼するでしょうか。
Google OAuth審査の申請プロセスは、個人開発者にとって険しい道のりです。プライバシーポリシーの準備、スコープの正当性説明、セキュリティ評価——大企業のチームならともかく、一人で開発しているアプリにとっては、メール送信という単一機能のために払うコストとしてはあまりにも大きすぎます。
必要だったのは、OAuth審査の複雑さなしに、ユーザーの信頼を損なわずメールを送信できるソリューションでした。その答えが、自前のRelay APIです。
2. Cloudflare Workers + Resend APIアーキテクチャ
Relay APIのアーキテクチャは、シンプルかつ堅牢です。iOSアプリからのリクエストを受け取り、メール送信サービスに中継する——それだけに特化した設計です。
Cloudflare Workersは、世界中のエッジロケーションでTypeScriptコードを実行するサーバーレスプラットフォームです。Cloudflare の説明では、isolate という軽い実行環境でコードを動かすので、仮想マシン型のサーバーレスで起きるコールドスタートがありません。
Resend APIは、モダンなメール送信サービスです。SPF/DKIM/DMARCを設定しやすく、TypeScriptから簡単に呼び出せます。
費用の面では、Cloudflare Workersの無料プランは1日10万リクエストまで、Resendの無料プランは1日100通・月3,000通まで使えます(2026年10月時点の各社の料金ページ)。小さく始めて、送る量に合わせて有料のプランに移れる構成です。
3. メールアドレス検証(6桁コード方式)
Relay APIは、検証済みのメールアドレスにのみメモを送信します。これは悪用防止の最も基本的な防御層です。
メモ送信を開始する前に、送信先のメールアドレスを検証するフローが必要です。
- ユーザーがアプリにメールアドレスを入力
- Relay APIが6桁の検証コードをそのアドレスに送信
- ユーザーが受信した6桁コードをアプリに入力
- 検証完了。以降、そのメールアドレスへのメモ送信が許可される
この仕組みにより、他人のメールアドレスに無断でメモが送信されることを防ぎます。検証コードはそのアドレスの受信箱に届くので、受信箱を見られない人は、そのアドレスを送信先として確認できません。
検証はメールアドレスごとに一度だけ。一度検証が完了すれば、以降はコード入力なしでメモを送信し続けられます。
4. 多層レート制限の実装
メール送信APIの悪用を防ぐため、複数のレイヤーでレート制限を実装しています。
const RATE_LIMITS = {
devicePerMinute: 30,
devicePerDay: 200,
ipPerHour: 120,
globalPerDay: 300,
};
カウンターはCloudflare KVに保存され、各時間ウィンドウごとにリセットされます。通常の送信は通しつつ、不正な大量アクセスを抑えます。
5. 冪等性:同じメモを二重に送らないための設計
ネットワーク通信には不確実性がつきものです。送信ボタンを押してから応答が返るまでの間に、通信が途切れることがあります。アプリはタイムアウトと判断して再送信を試みますが、実は最初のリクエストはサーバーに届いていた——よくあるシナリオです。
この場面には、冪等性(idempotency)で備えます。
- 各メモに一意のUUID(メッセージID)を付与
- Relay APIは、そのメッセージIDを、メール送信サービス(Resend)への要求の冪等キー(Idempotency-Key)として渡す
- Resendは同じキーを24時間覚えていて、同じ内容の要求がもう一度来たら、メールは送らずに前と同じ応答を返す
- アプリには成功の応答が返る(2回目も1回目と同じ応答)
この設計により、ネットワークが不安定でリトライが起きても、24時間のうちは同じメモが重ねて送られません(Resendがキーを覚えている期間)。それより後の送り直しは見分けられないので、重複を止められるのはこの期間の中です。
6. エッジコンピューティングの利点
Cloudflare Workersをメール送信基盤に採用した最大の理由は、エッジコンピューティングの本質的な利点にあります。
メモアプリにとって、この組み合わせは扱いやすい選択でした。利用者に近い拠点で処理が始まり、サーバーの管理が要らず、小さな規模なら費用も抑えられます。それが、エッジコンピューティングでRelay APIを作った理由です。
この技術基盤の上に構築された「Obsidian連携シンプルメモ」を、ぜひお試しください。
App Storeでダウンロードよくある質問
Q. なぜCloudflare Workersを選んだのですか?
仮想マシン型のコールドスタートが無く、利用者に近い拠点で処理でき、小さな規模なら無料プランから始められるからです。
Q. メールの到達率は?
送信元のドメインにはSPF・DKIM・DMARCを設定しています。それでも、宛先のメールサービスの判断で迷惑メールに振り分けられることがあります。届かないときは、迷惑メールのフォルダと、送信先のアドレスの確認が済んでいるかを見てください。
Q. サーバーにメモの内容は保存されますか?
Relay APIは通過型です。メモ内容の恒常的な保存は行いません。送信処理に必要な範囲でのみ一時的に扱います。
Q. レート制限に引っかかったらどうなりますか?
メモは端末の送信待ち(Outbox)に残り、回線の復帰・アプリを開いたとき・バックグラウンドの処理をきっかけに、自動で送り直します(自動の再送には回数の上限があります)。
関連記事
参考文献
- Cloudflare Workers Documentation — リレーAPIのサーバーレス実行基盤。エッジでのリクエスト処理に使用
- RFC 5321 — Simple Mail Transfer Protocol (SMTP) — メール送信の基本プロトコル仕様。リレーAPIが準拠するSMTP標準
- RFC 6376 — DomainKeys Identified Mail (DKIM) — 送信メールの改ざん防止と送信元認証に使用する電子署名仕様
- RFC 7208 — Sender Policy Framework (SPF) — 送信ドメイン認証。許可されたIPアドレスからのメール送信を検証
- Resend API Documentation — メール送信APIプロバイダー。Cloudflare Workersから呼び出すメール配信サービス