「カスタマーサポートの一次対応を AI に任せたい」「営業フォローメールを送り分けたい」——4 月後半から、こうした相談がさらに増えました。きっかけのひとつが、Cloudflare が AI エージェント向けの送受信サービス「Cloudflare Email Service」をパブリックベータで公開したことです。SPF/DKIM/DMARC を含むメール基盤の運用を Cloudflare 側に寄せ、エージェント開発者は「ツール呼び出しでメールを書く・読む・分類する」ことに集中できる構成が、受託案件の現実解として一気に成立しました。
本記事では、メール業務をエージェント化する受託案件で押さえるべき設計ポイントと、HITL（Human-in-the-Loop）を組み込む実装パターンを整理します。
なぜ「メール × AI エージェント」が今再燃しているのか
「メール自動化」は古いテーマに見えますが、2026 年現在の文脈は過去の RPA ブームとは決定的に違います。
| 観点 | 旧来の RPA | エージェント時代 |
|---|---|---|
| 起点 | 人間が定義したフロー | 自然言語のゴール |
| 例外処理 | 人間が分岐を網羅 | エージェントが状況判断 |
| メール認証 | 自前で SPF/DKIM 整備 | Cloudflare 側が抽象化 |
| 監査 | ログを別途集約 | ツール呼び出しが構造化ログ |
特にエージェントから直接メール送信を行う用途では、認証ヘッダーの失敗が「会社全体のメール到達率」を毀損するリスクがあります。Cloudflare Email Service はここを引き受けてくれるため、受託で組む場合の責任分界点が明確になりました。
私たちが 既存 SaaS API を MCP サーバー化する設計パターン で整理した「ユースケース集約型」は、メール基盤との相性も非常に良いアプローチです。
アーキテクチャ全体像
弊社が受託案件で採用するスタンダード構成は、次の 4 層に分けて整理します。
- Cloudflare Email Service — メールの送信 API、受信ルーティング、SPF/DKIM/DMARC 管理
- Workers AI / 外部 LLM — メール分類・要約・返信ドラフト生成
- MCP サーバー（自社） — エージェント向けのドメイン特化ツール（顧客検索・案件参照など）
- HITL UI — Slack / 社内ポータルでの承認画面
エージェントは「受信トリガー → 内容理解 → 返信ドラフト生成 → 承認 → 送信」という一連のフローを、複数ツールを順に呼び出して実行します。
受信側：着信メールの「分解」設計
着信メールはそのまま LLM に渡してはいけません。トークンが膨らみ、添付ファイルや署名で誤解釈が起きます。Cloudflare Workers の Email Routing 上で、次の 3 段階に分解してから渡します。
export default {
async email(message, env) {
const parsed = await parseEmail(message);
const enriched = {
from: parsed.from,
subject: parsed.subject,
thread_summary: await summarizeThread(parsed.history),
latest_body_text: stripQuotedText(parsed.body),
attachments: parsed.attachments.map((a) => ({
name: a.name,
type: a.contentType,
text_preview: a.text?.slice(0, 500),
})),
};
await env.AGENT_QUEUE.send(enriched);
},
};ポイントは次の 3 つです。
- 過去スレッドは要約に圧縮（長尺の引用は AI を混乱させる）
- 本文の引用部は剥がす（最新の発言だけを渡す）
- 添付は本文プレビュー + メタデータのみ（巨大ファイルをそのまま渡さない）
送信側：HITL を「ツール定義」に埋め込む
メール送信は「対外的・取り消し不可」な操作です。MCP ツール側で承認待ち状態を持たせ、UI で確認させてから本送信させます。
server.tool("send_business_email", async (args, ctx) => {
if (!ctx.userApproved) {
return {
kind: "approval_required",
preview: {
to: args.to,
subject: args.subject,
body_md: args.body_md,
},
approval_token: issueApprovalToken(args),
};
}
return await cloudflare.email.send({
from: env.SENDER_ADDRESS,
to: args.to,
subject: args.subject,
text: args.body_text,
html: renderHtml(args.body_md),
headers: { "Reply-To": args.reply_to ?? env.REPLY_TO },
});
});Anthropic Computer Use を業務に組み込むガイド でも触れたように、対外的な操作は 「2 段階呼び出し + 承認トークン」 をデフォルトにしておくのが安全です。
認証ヘッダー（SPF/DKIM/DMARC）の落とし穴
Cloudflare 側が大半を抽象化してくれますが、受託で「自社ドメインから送る」場合、次の 3 点はクライアント側で設定が必要です。
| 項目 | 設定先 | 注意点 |
|---|---|---|
| SPF | DNS（自社ドメイン） | 既存の MTA・SaaS と include の競合に注意 |
| DKIM | DNS（Cloudflare 提供の鍵） | キーローテーションは自動だが TTL の見直し |
| DMARC | DNS（自社ポリシー） | p=quarantine 以上を推奨、rua でレポート集約 |
特に既に Marketing Cloud や HubSpot を使っている企業は、SPF レコードの 10 lookup 制限に引っかかりがちです。受託の初期ヒアリングで、現状の SPF を dig で確認しておくのが鉄則です。
ユースケース別「初手の設計」
メール × エージェント案件で、立ち上げが速いユースケースを 3 つ挙げます。
A. 問い合わせ一次対応エージェント
- 着信を 3 分類（FAQ で返せる / 営業に渡す / 緊急エスカレーション）
- FAQ 対応のみ自動返信、他は担当者にアサイン通知
- 効果が見えやすく、4〜6 週間で MVP 化可能
B. 営業フォローエージェント
- CRM の商談ステータス変化をトリガーに、テンプレ化されないフォロー文を生成
- 必ず HITL で営業担当が確認してから送信
- 担当者の作業時間を週 3〜5 時間削減した実例あり
C. 通知配信のパーソナライズ
- 既存の通知メール（請求・発送・更新）に、AI が状況に応じた一言を追加
- セグメント別 A/B を回すことで開封率を底上げ
マルチモーダル AI × MCP の顧客接点設計 と組み合わせると、メール → チャット → 音声を横断するオムニチャネル受託案件としてスケールします。
受託案件の型と単価帯
| 案件の型 | 期間 | 単価帯 | 提供物 |
|---|---|---|---|
| 一次対応エージェント PoC | 4〜6 週間 | 250〜450 万円 | エージェント・HITL UI・運用ガイド |
| 営業フォロー基盤構築 | 8〜12 週間 | 500〜900 万円 | CRM 連携・テンプレ・効果計測 |
| メール基盤統合（DMARC 含む） | 6〜10 週間 | 400〜800 万円 | 認証設計・移行・モニタリング |
PoC で「効果が見える数字」（返信率・対応時間・誤送信ゼロ）を握れると、運用フェーズの長期パートナー化が成立しやすいテーマです。
まとめ — メール業務は「人がやる前提」から卒業する
これまでメール対応は「人が一通ずつ捌く」ことが前提でした。Cloudflare Email Service と MCP の組み合わせは、「エージェントが下書きまで作り、人は判断と承認だけ行う」 という新しい役割分担を実現します。
弊社では、Cloudflare Email Service を起点としたエージェント設計、HITL UI 構築、CRM 連携、DMARC 移行までをワンストップで提供しています。「問い合わせ対応に追われている」「営業フォローが追いつかない」というご相談は、お問い合わせフォーム からお声がけください。
