メールを使えるAIエージェントは、すでに来ています——ただし、その基盤を自分で構築しようとすると話は別です。

2026年4月16日、Cloudflare Agents Week最終日に「Agentic Inbox」がオープンソースとして公開されました。Cloudflare Workers上で完全動作する自己ホスト型のAIメールクライアントです。Email Routing・Email Sending・Workers AI・Agents SDKをひとつのリポジトリにまとめ、「Deploy to Cloudflare」ボタン一つで動き始めます。

この記事でわかること

  • Cloudflare Email Serviceがエージェント向けに解決する課題
  • Agentic Inboxの構成と主な機能
  • Agents SDKで実現する非同期メール処理の仕組み
  • セットアップの手順と必要な設定

https://github.com/cloudflare/agentic-inbox

エージェントとメールの組み合わせが難しかった理由

AIエージェントがユーザーと対話する手段として、チャットUIや専用SDKが普及しています。しかしこれらには「専用アプリを入れた人しか使えない」という制約があります。

メールにはその制約がありません。世界中の人がすでにアドレスを持っており、カスタムアプリもSDKも不要です。エージェントを「顧客」に届けるハードルが限りなく低い。

ただし実際にエージェントからメールを送受信しようとすると、SPF・DKIM・DKIMの設定、Postfixのセットアップ、APIキー管理といった作業が積み重なります。Cloudflare Email Serviceはこの問題全体をまとめて解消するために設計されています。

Cloudflare Email Serviceの構成

エージェント向けのメール基盤として、Cloudflareは以下をワンセットで提供しています。

Email Routingは従来から無料で提供されている受信転送サービスです。カスタムドメインへのメールをWorkerに転送し、エージェントが直接処理できます。

Email Sendingは2026年4月16日からパブリックベータに入ったWorkerネイティブの送信機能です。SPF・DKIM設定はドメイン追加時に自動構成されます。APIキーや秘密鍵の管理が不要で、Workers内から直接env.EMAIL.send()を呼ぶだけでメールを送れます。

Agents SDK onEmailフックは、エージェントがメールを受け取り、状態を保持し、非同期で返信するための仕組みです。Durable Objectsと組み合わせることで、エージェントは会話履歴を外部データベースなしに保持できます。

Email MCPサーバーを使うと、Claude CodeやCursorなどのコーディングエージェントが自然言語のプロンプトからメールを送信・設定できます。

Wrangler CLIメールコマンドはターミナルや自動化スクリプトからメールを送る手段です。MCP toolの定義がコンテキストウィンドウを圧迫する問題を回避しながら、エージェントが--helpで機能を発見できる設計になっています。

Agentic Inboxとは何か

Agentic Inboxは上記の基盤をすべて組み合わせたリファレンス実装です。2026年5月時点でGitHub Stars 2.4k、Forks 307。

各メールボックスはDurable ObjectのSQLiteで独立管理され、添付ファイルはR2ストレージに保存されます。Workers AIがメールを分類し、Agents SDKがステートフルなエージェントロジックを担当します。

Cloudflareが強調するのはセキュアな返信ルーティングです。エージェントが送信したメールへの返信は、HMAC-SHA256で署名されたヘッダーによって元のエージェントインスタンスに確実に戻ります。攻撃者がヘッダーを偽造して任意のインスタンスにメールを誘導する攻撃を防ぐ設計です。

「チャットボット」ではなく「エージェント」として動く

Email Sendingが加わる前、エージェントはメールを受けても即座に返信するか、黙るかしか選べませんでした。Email Sendingとの組み合わせで、エージェントは次のことができます。

メールを受け取り、複数のシステムにアクセスして処理し、1時間後に完全な回答を返信する。条件に応じて別の担当者にエスカレーションを送る。フォローアップを予約する。状態はDurable Objectsが保持するため、会話履歴や顧客情報をベクトルストアなしで引き継げます。

アドレス設計も工夫されています。customer-support@yourdomain.comを設定すれば「support」というAgent instanceに、sales@yourdomain.comなら「sales」instanceにルーティングされます。サブアドレス（agent+namespace@domain.com形式）でインスタンスをさらに細分化することも可能です。

セットアップの手順

GitHubのリポジトリにある「Deploy to Cloudflare」ボタンを押すと、R2・Durable Objects・Workers AIが自動でプロビジョニングされます。プロンプトでDOMAINS（受信したいドメイン）を入力すると設定が始まります。

その後の手順は4ステップです。

  1. CloudflareのWorker Settings > Domains & Routesから「one-click Cloudflare Access」を有効化し、POLICY_AUDとTEAM_DOMAINをWorkerのシークレットに設定する
  2. Cloudflareダッシュボードで対象ドメインのEmail Routingを開き、キャッチオールルールをこのWorkerに向ける
  3. Email Serviceバインディング（send_email）を有効化する
  4. デプロイ済みのアプリにアクセスしてメールボックスを作成する（例: hello@example.com）

Cloudflare無料プランの範囲内で動作します。追加コストはR2のストレージ量とWorkers AIの推論利用量に依存します。

活用できるユースケース

Cloudflareによると、プライベートベータ期間中に開発者が実際に構築していたのは以下のような用途です。

カスタマーサポートエージェントは受信メールを分類して返信し、対応困難な案件を担当者にエスカレーションします。請求書処理パイプラインは添付PDFを解析して会計システムに転記します。アカウント確認フローは登録メールの受信と検証と通知送信を一貫して処理します。マルチエージェントワークフローではエージェント間のメール通知が連携の起点になります。

いずれも「人間がメールを受け取る代わりにエージェントが受け取る」という構造です。Agentic Inboxはその構造をゼロから構築せずに始めるための出発点として設計されています。

まとめに代えて

Cloudflare Agentic Inboxの公開は、AIエージェントとメールという二つの既存インフラをつなぐ接着剤が整ったことを意味します。「エージェントにメールを持たせる」ために必要な送受信・状態管理・セキュリティの要素がひとつのリポジトリにまとまり、フォークして拡張できる状態になりました。エージェントの接点をメールに広げたい開発者にとって、試す価値のある出発点です。