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アプリからのリクエストを受け取り、メール送信サービスに中継する——それだけに特化した設計です。

iOS App Relay API (Cloudflare Workers) Resend API Email Delivery

Cloudflare Workersは、世界中のエッジロケーションでTypeScriptコードを実行するサーバーレスプラットフォームです。従来のサーバーレスで問題になるコールドスタートがほぼゼロで、リクエストを受けた瞬間から処理が始まります。

Resend APIは、モダンなメール送信サービスです。SPF/DKIM/DMARCの設定が容易で、高い到達率を実現します。開発者フレンドリーなAPIで、TypeScriptからシンプルに呼び出せます。

コスト面でも優れています。メモアプリのトラフィック量であれば、Cloudflare Workersの無料枠(1日10万リクエスト)で十分にまかなえます。Resend APIも月100通まで無料。個人開発のメモアプリにとって、ほぼゼロコストで運用できるインフラです。

3. メールアドレス検証(6桁コード方式)

Relay APIは、検証済みのメールアドレスにのみメモを送信します。これは悪用防止の最も基本的な防御層です。

メモ送信を開始する前に、送信先のメールアドレスを検証するフローが必要です。

  • ユーザーがアプリにメールアドレスを入力
  • Relay APIが6桁の検証コードをそのアドレスに送信
  • ユーザーが受信した6桁コードをアプリに入力
  • 検証完了。以降、そのメールアドレスへのメモ送信が許可される

この仕組みにより、他人のメールアドレスに無断でメモが送信されることを防ぎます。メールアドレスの所有者本人だけが検証コードを受信できるため、なりすまし送信は不可能です。

検証はメールアドレスごとに一度だけ。一度検証が完了すれば、以降はコード入力なしでメモを送信し続けられます。

4. 多層レート制限の実装

メール送信APIの悪用を防ぐため、複数のレイヤーでレート制限を実装しています。

const RATE_LIMITS = {
  devicePerMinute: 30,
  devicePerDay: 200,
  ipPerHour: 120,
  globalPerDay: 300,
};
Device Level
デバイス単位の制限
1台のデバイスからの過剰な送信を防止。1分あたり30件、1日あたり200件の上限を設定。通常のメモ利用では到達しない閾値ですが、自動化による大量送信を確実にブロックします。
IP Level
IPアドレス単位の制限
同一ネットワークからの大量リクエストを制限。1時間あたり120件。複数デバイスを使った攻撃からもインフラを保護します。
Global
グローバル制限
インフラ全体の保護。1日あたり300件のグローバル上限で、いかなる攻撃パターンに対しても最終防衛線として機能します。

カウンターはCloudflare KVに保存され、各時間ウィンドウごとにリセットされます。エッジコンピューティングの利点により、レート制限チェックも数十ミリ秒で完了。正当なリクエストの遅延を最小限に抑えつつ、不正アクセスを確実に遮断します。

5. 冪等性の保証:メモが2通届かない設計

ネットワーク通信には不確実性がつきものです。送信ボタンを押してから応答が返るまでの間に、通信が途切れることがあります。アプリはタイムアウトと判断して再送信を試みますが、実は最初のリクエストはサーバーに届いていた——よくあるシナリオです。

この問題を解決するのが冪等性(idempotency)の保証です。

  • 各メモに一意のUUID(メッセージID)を付与
  • Relay APIは受信したメッセージIDを記録
  • 同一のメッセージIDを持つリクエストが再度届いた場合、メールの重複送信は行わない
  • クライアントには成功レスポンスを返す(すでに送信済みであることを通知)

この設計により、ネットワーク不安定な環境でリトライが発生しても、同じメモが2通届くことは絶対にありません。ユーザーの信頼を守るための重要な設計判断です。

6. エッジコンピューティングの利点

Cloudflare Workersをメール送信基盤に採用した最大の理由は、エッジコンピューティングの本質的な利点にあります。

Latency
世界中のエッジロケーション = 低レイテンシ
Cloudflareは世界300以上の都市にエッジサーバーを展開。ユーザーに最も近いロケーションでリクエストが処理されるため、どの国からでも数十ミリ秒でAPIレスポンスが返ります。
Cold Start
コールドスタートがほぼゼロ
従来のサーバーレス(AWS Lambdaなど)ではコールドスタートに数百ミリ秒〜数秒かかることがあります。Cloudflare Workersはその問題がほぼ存在しません。メモの送信ボタンを押した瞬間に処理が始まります。
Operations
インフラ管理不要のオートスケーリング
サーバーの管理、キャパシティプランニング、スケーリング設定——これらすべてが不要です。リクエストが増えれば自動的にスケールし、アイドル時にはコストが発生しません。

メモアプリにとって、この組み合わせは理想的です。速い、信頼性が高い、安い。ユーザーが世界中どこにいても、メモを送信した瞬間に処理が完了する。それがエッジコンピューティングで構築したRelay APIの強みです。

この技術基盤の上に構築された「Obsidian連携シンプルメモ」を、ぜひお試しください。

App Storeでダウンロード

参考文献