このコンテンツは自動機械翻訳サービスによる翻訳版であり、皆さまの便宜のために提供しています。原本の英語版と異なる誤り、省略、解釈の微妙な違いが含まれる場合があります。ご不明な点がある場合は、英語版原本をご確認ください。
メールは世界で最もアクセスしやすいインターフェースです。経路はユビキタスです。カスタムチャットアプリケーションは不要で、各チャンネルごとにカスタムSDKも必要ありません。誰もがすでにメールアドレスを持っています。つまり、誰でもすでにアプリケーションやエージェントを操作できるのです。エージェントは誰とでも対話できます。
アプリケーション構築の際、すでにメールに依存したサインアップ、通知、請求書を使っていると思います。ますます、このチャンネルを必要とするのはアプリケーションロジックだけではありません。エージェントも同様です。プライベートベータ版の期間中、私たちはまさにこれを構築している開発者たちと話をしました。カスタマーサポートエージェント、請求書処理パイプライン、アカウント確認フロー、マルチエージェントワークフローなどです。すべてをメール上に構築パターンは明らかです。メールはエージェントにとってコアインターフェースになりつつあり、開発者にはそれに特化したインフラが必要です。
Cloudflare Email Serviceはまさにその手段です。Email Routingを使用すると、アプリケーションやエージェントへメールを受信できます。Email Sendingを使用すると、メールに返信したり、アウトバウンドを送信して、エージェントの作業が完了したらユーザーに通知することができます。また、開発者プラットフォームの残りの部分を使用すると、完全なメールクライアントとエージェントSDKをonEmailフックとしてネイティブ機能で構築できます。
本日、Agents Weekの一環として、Cloudflare Email Serviceがパブリックベータ版となり、あらゆるアプリケーションとあらゆるエージェントからのメール送信が可能になります。また、メールネイティブエージェントを構築するためのツールキットも完成しています。
Email Sendingは本日、プライベートベータ版からパブリックベータ版に卒業します。ネイティブのWorkersバインディングで、Workersから直接トランザクションメールを送信できるようになりました。APIキーやシークレット管理は不要です。
export default {
async fetch(request, env, ctx) {
await env.EMAIL.send({
to: "[email protected]",
from: "[email protected]",
subject: "Your order has shipped",
text: "Your order #1234 has shipped and is on its way."
});
return new Response("Email sent");
},
};
あるいは、REST APIとTypeScript、Python、Go SDKを使用して、任意のプラットフォーム、任意の言語から送信することもできます。
curl "https://api.cloudflare.com/client/v4/accounts/{account_id}/email-service/send" \
--header "Authorization: Bearer <API_TOKEN>" \
--header "Content-Type: application/json" \
--data '{
"to": "[email protected]",
"from": "[email protected]",
"subject": "Your order has shipped",
"text": "Your order #1234 has shipped and is on its way."
}'
実際に受信箱に届くメールの送信は、通常、SPF、DKIM、DMARCレコードとのやりとりを意味します。ドメインをEmail Serviceに追加すると、すべて自動的に設定されます。メールは認証され、スパムとしてフラグ付けされることはありません。また、Email ServiceはCloudflareのネットワーク上に構築されたグローバルサービスであるため、メールは世界中どこにいても低遅延で配信されます。
何年にもわたり無料で提供されてきたEmail Routingと組み合わせることで、単一のプラットフォームで完全な双方向メールを実現できます。メールの受信、Worker内での処理、返信まで、Cloudflareを離れることはありません。
For the full deep dive on Email Sending, バースデーウィークの発表をご参照ください。この記事の残りの部分では、エージェント向けのメールサービスの可能性について説明します。
Agents SDK：エージェントはメールネイティブ
Cloudflare上にエージェントを構築するためのAgents SDKには、受信メールを受信し処理するための第一級のonEmail hookがすでに備えられています。しかし、これまでは、エージェントは同期的に返信したり、Cloudflareアカウントのメンバーにメールを送信したりすることしかできませんでした。
Email Sendingでは、その制約はありません。これは、チャットボットとエージェントの違いです。
メールエージェントはメッセージを受信し、プラットフォーム全体の作業を調整し、非同期に応答します。
チャットボットは即座に応答するか、まったく応答しません。エージェントは、自分のタイムラインに沿って考え、行動し、コミュニケーションを行います。Email Sendingにより、エージェントはメッセージを受信し、データ処理に1時間を費やし、他の3つのシステムをチェックし、完全な回答を返信することができます。フォローアップのスケジュールを設定することができます。エッジケースを検出すると、エスカレートすることができます。独立して動作することができます。言い換えれば、質問に答えるだけでなく、実際に働くことができるのです。
サポートエージェントが受信、持続、返信の全パイプラインでどのような形になるかを次に示します。
import { Agent, routeAgentEmail } from "agents";
import { createAddressBasedEmailResolver, type AgentEmail } from "agents/email";
import PostalMime from "postal-mime";
export class SupportAgent extends Agent {
async onEmail(email: AgentEmail) {
const raw = await email.getRaw();
const parsed = await PostalMime.parse(raw);
// Persist in agent state
this.setState({
...this.state,
ticket: { from: email.from, subject: parsed.subject, body: parsed.text, messageId: parsed.messageId },
});
// Kick off long running background agent task
// Or place a message on a Queue to be handled by another Worker
// Reply here or in other Worker handler, like a Queue handler
await this.sendEmail({
binding: this.env.EMAIL,
fromName: "Support Agent",
from: "[email protected]",
to: this.state.ticket.from,
inReplyTo: this.state.ticket.messageId,
subject: `Re: ${this.state.ticket.subject}`,
text: `Thanks for reaching out. We received your message about "${this.state.ticket.subject}" and will follow up shortly.`
});
}
}
export default {
async email(message, env) {
await routeAgentEmail(message, env, {
resolver: createAddressBasedEmailResolver("SupportAgent"),
});
},
} satisfies ExportedHandler<Env>;
Agents SDKのメール機能を初めて使う方のために、内部で何が起こっているかを以下に説明してください。
各エージェントは、単一のドメインから独自のIDを取得します。アドレスベースのリゾルバーは、[email protected]を「support」エージェントインスタンスに、[email protected]を「sales」インスタンスに、といったようにルーティングします。別々の受信箱をプロビジョニングする必要はありません。ルーティングはアドレスに組み込まれているためです。サブアドレス指定（[email protected]）を使用して、異なるエージェントネームスペースやインスタンスにルーティングすることもできます。
状態はメール間で続く。エージェントはDurable Objectsによって支えられているため、this.setState()を呼び出すことで、エージェントはセッション間の会話履歴、連絡先情報、コンテキストを記憶することになります。受信トレイはエージェントのメモリとなり、別のデータベースやベクトルストアを必要としません。
セキュアな返信ルーティング機能を搭載。エージェントがメールを送信し、返信があった場合、HMAC-SHA256でルーティングヘッダーに署名することができ、返信が元のメッセージを送信した正確なエージェントインスタンスに戻るようになります。これにより、攻撃者はヘッダーを偽造して、メールを任意のエージェントインスタンスにルーティングできます。これは、「エージェント向けメール」ソリューションのほとんどが対応していないセキュリティ上の懸念です。
これは、チームがゼロから構築している完全なメールエージェントパイプラインです。メールの受信、解析、分類、状態の保持、非同期ワークフローの開始、返信やエスカレーションなどを行うことができ、すべてが単一のエージェントクラス内で、Cloudflareのネットワーク上でグローバルにデプロイされます。
メールサービスは、Cloudflare上で動作するエージェントだけのものではありません。Claude Code、Cursor、Copilotのようなコーディングエージェントがローカルまたはリモート環境で実行される場合も、コンテナや外部クラウドで実行される本番エージェントであっても、エージェントはあらゆる場所で実行されます。それらのユーザーはすべて、それらの環境からメールを送信する必要があります。実行場所を問わず、あらゆるエージェントがEmail Serviceをアクセスできるようにする3つの統合機能をリリースします。
メールは、Cloudflare MCPサーバーを通じて利用できるようになりました。これは、エージェントがCloudflare API全体にアクセスできるようにするのと同じCode Mode対応サーバーです。このMCPサーバーにより、エージェントはメールエンドポイントを検出して呼び出すことでメールを送信し、設定することができます。簡単なプロンプトでメールを送信できます。
"Send me a notification email at [email protected] from my staging domain when the build completes"
コンピューター上またはbashアクセスのあるサンドボックス上で実行されているエージェントの場合、Wrangler CLIは、Code Modeのブログ記事で説明したMCPコンテキストウィンドウの問題を解決します。ツール定義は、エージェントが1つのメッセージを処理し始める前に、何万ものトークンを消費する可能性があります。Wranglerでは、エージェントはコンテキストオーバーヘッドがほぼゼロで開始され、「--help」コマンドによってオンデマンドの機能を発見します。エージェントがWrangler経由でメールを送信する方法は、次のとおりです。
wrangler email send \
--to "[email protected]" \
--from "[email protected]" \
--subject "Build completed" \
--text "The build passed. Deployed to staging."
エージェントにCloudflare MCPを提供する場合も、Wrangler CLIを提供する場合も、エージェントはプロンプトだけでお客様に代わってメールを送信できるようになります。
また、Cloudflare Email Serviceスキルを公開しています。エージェントに完全なガイダンスを提供します。Workersバインディングの設定、REST APIまたはSDKを使用したメールの送信、Email Routing設定による受信メールの処理、Agents SDKを使用した構築、Wrangler CLIやMCPによるメール管理などです。また、配信到達性のベストプラクティスや、スパムではなく受信箱に届く良質な取引メールの作成方法も取り上げています。貴社のプロジェクトに追加すれば、コーディングエージェントにはCloudflare上で本番環境対応のメールを作成するのに必要なすべての機能が備わっています。
プライベートベータ版では、メールエージェントについても実験を行いました。メールをレビューし、エージェントの行動を確認するために、ヒューマンインザループ要素を維持したいことが多いことは明らかでした。そのためには、エージェント自動化機能が組み込まれた完全機能のメールクライアントを持つことが最善の方法となります。
そこで当社は、完全な対話スレッド、メールのレンダリング、メールと添付ファイルの受信と保存、メールへの自動返信機能を備えたリファレンスアプリケーションである、Agentic Inbox: を開発しました。専用のMCPサーバーが組み込まれているため、外部エージェントがエージェントの受信トレイから送信する前に、レビュー用のメールを下書きすることができます。
インバウンド用Email Routing、アウトバウンド用Email Sending、分類用のWorkers AI、添付ファイル用のR2、ステートフルなエージェントロジックのためのAgents SDKを使用した、完全なメールアプリケーションの構築方法に関するリファレンスアプリケーションとして、Agentic Inboxをオープンソース化します。今すぐデプロイして、ボタンをクリックするだけで、完全な受信箱、メールクライアント、メールエージェントを取得することができます。
当社は、メールエージェントのツールを構成可能かつ再利用可能にしたいと考えています。各チームが同じ受信分類／応答パイプラインを再構築するのではなく、このリファレンスアプリケーションから始めてください。フォークして拡張し、お客様のワークフローに合わせた独自のメールエージェントの出発点としてご利用ください。
メールは世界で最も重要なワークフローが存在する場所ですが、エージェントにとっては、しばしば到達しにくいチャネルです。Email Sendingがパブリックベータ版になったことで、Cloudflare Email Serviceは双方向通信のための完全なプラットフォームとなり、受信トレイはエージェントにとって一流のインターフェースとなります。
受信トレイ内の顧客に対応するサポートエージェントを構築する場合でも、チームの最新情報をリアルタイムで更新するバックグラウンドプロセスなど、エージェントはグローバル規模でシームレスな通信を実現できます。受信トレイはもはやサイロではありません。エージェントが役に立つ場所が増えました。