Cloudflare Email Service

Cloudflare Email Serviceとは？

Cloudflare Email Serviceは、メールネイティブなエージェントやアプリケーションを構築するためのインフラストラクチャ層です。Cloudflare開発者プラットフォームのコンポーネントを使って、エージェントがメールの送信、受信、処理を可能にし、別々のチャネルやカスタム統合を作成する代わりに、受信箱をインターフェースとして活用できます。

このサービスは、Cloudflare Agents SDKおよびonEmailスタイルのエージェントフックと連携するよう設計されています。受信メッセージ用のEmail Routingと送信リプライ/通知用のEmail Sendingにより、開発者は同一のCloudflare環境内で双方向メールワークフローを実装できます。

主な機能

• Email Routing（アプリ/エージェントへの受信メール）: メールを受信し、アプリケーションやエージェントにルーティングして処理。受信箱ベースのインタラクションモデルを実現。
• Email Sending（送信トランザクションメール）: エージェント/アプリケーションからユーザーへリプライや通知を送信。非同期処理でトリガーされるメッセージを配信。
• Workers向けEmail Sendingバインディング（パブリックベータ）: Workersからネイティブenv.EMAIL.send(...)バインディングで直接メール送信。APIキーやシークレット管理不要。
• Email Sending用REST API + SDK: Cloudflare REST API経由で任意のプラットフォーム/言語から送信。TypeScript、Python、Go SDK対応。
• 自動ドメイン認証設定（SPF/DKIM/DMARC）: ドメインをEmail Serviceに追加すると、CloudflareがSPF、DKIM、DMARCを自動設定。手動セットアップ不要で認証・配信。
• Cloudflareネットワーク上のグローバル配信: Cloudflareネットワーク構築のグローバルサービスで、世界中で低遅延配信。
• Email Routing + Email Sendingによる完全双方向ワークフロー: メール受信、Workerでの処理、Cloudflare内でリプライ。

Cloudflare Email Serviceの使い方

1. 受信メッセージ用にEmail Routingから開始: Agents SDKのonEmailフックでエージェントにメール受信を設定（受信メールのファーストクラス対応）。
2. 非同期リプライにEmail Sendingを使用: パブリックベータ中、Email Sendingを追加して処理後にエージェントから送信リプライ/通知。
3. ネイティブバインディングでWorkersから送信: Worker内でenv.EMAIL.sendをto、from、subject、メール本文（text使用例）で呼び出し。
4. またはREST APIとSDK経由で送信: Cloudflare Email Serviceの送信エンドポイントでサーバーサイド/クロスプラットフォーム送信。TypeScript、Python、Goの言語SDK利用可能。
5. 送信ドメインを追加・認証: Email Serviceでドメインを設定し、CloudflareがSPF、DKIM、DMARCを自動設定。

ユースケース

• カスタマーサポートエージェントの受信箱ワークフロー: Email Routingで顧客メッセージ受信、Agent/Workerで処理中にチケットデータを永続化、非同期タスク完了後にリプライ送信。
• 請求書処理とユーザー通知: 受信メール（例: ドキュメント/リクエスト）を受け取り、処理完了時にユーザーへステータスや完了通知を送信する請求書パイプライン構築。
• アカウント検証フロー: メールを主ユーザー向けチャネルとした検証インタラクション。エージェントロジックから検証関連メッセージ送信。
• エスカレーション・フォローアップ付きマルチエージェントワークフロー: システム間作業調整、フォローアップメールスケジュール、条件検知時のアウトバウンドメールによるエッジケースエスカレーション。
• 新規クライアントUIなしのマルチチャネルエージェント拡張: ユーザーがメールを確認済みの場合、カスタムチャットインターフェース構築不要で受信箱経由でエージェント公開。

FAQ

• Email Serviceはエージェント専用ですか？ いいえ。ソースでは、Email Serviceを開発者プラットフォーム層の一部として説明しており、パブリックベータ中にアプリケーションやエージェントがメール送信を可能にします。

• ユーザーからのメールをどのように受信しますか？ ソースでは、アプリケーションやエージェントへのメール受信にEmail Routingを指しており、Cloudflare上のエージェント処理と連携します。

• エージェントは長時間実行や非同期処理後にメールを送信できますか？ はい。ソースではチャットボット式の同期返信と対比し、エージェントが時間をかけて処理した後、Email Sendingを使って非同期に応答できると述べています。

• SPF、DKIM、DMARCレコードを手動で管理する必要がありますか？ ソースでは、ドメインをEmail Serviceに追加すると、CloudflareがSPF、DKIM、DMARCを自動設定すると述べています。

• Workerからどのようにメールを送信しますか？ ソースで説明されたネイティブWorkersバインディングを使用：env.EMAIL.send({ to, from, subject, text })。

代替案

• 外部メールプロバイダを使ってカスタムメール統合を構築: 送信を自分で管理したい場合、サードパーティのメールAPIを使用し、インバウンドを独自ルーティングで処理できますが、Cloudflareのルーティング/送信層外でエンドツーエンドのワークフローを多く構築する必要があります。
• 専用メール解析/ルーティングサービス＋別エージェントバックエンドを使用: Cloudflareの統合Email Routing + Email Sendingの代わりに、インバウンドメールを他プロバイダでルーティングし、バックエンドでアウトバウンドメールを生成できます。
• メールネイティブワークフローの代わりにチャットやチケットインターフェースを使用: リアルタイムインタラクション重視のチーム向けに、チャット/チケットシステムでメールを主インターフェースとして置き換えられますが、ソースで説明された受信箱ベースの体験は失われます。
• アウトバウンドトランザクションメールのみ実装（インバウンドルーティングなし）: 通知のみ必要な場合、双方向の受信・返信ワークフローを構築せずにアウトバウンドメールAPIを使用できます。