# MCPとREST APIの比較：メールマーケティングでの使い分け

正規URL：https://brew.new/ja/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use
執筆：Thomas Park
公開日：2026-09-23
更新日：2026-09-29

チームの開発者がメール配信プラットフォームを Claude に接続し、チャット画面で来週のキャンペーンの下書きを作りました。翌朝、登録時のウェルカムメールも同じようにアシスタント経由で動かせないか、と誰かが尋ねます。プラットフォームのドキュメントには、MCPサーバーとREST APIが並んで載っています。

エージェントに対応したメール配信プラットフォームの多くは、今ではこの2つの入り口を用意しています。MCPサーバーを使うと、AIアシスタントが会話の中でプラットフォームのツールを呼び出せます。REST APIは、自社のコードから直接呼び出せる操作を公開します。内部では同じエンドポイントに行き着くことも多いので、選ぶ基準は、誰がいつその作業を行うかです。

人がアシスタントを通じて作業するならMCPを、誰も見ていないところで製品からメールを送る必要があるならREST APIを使いましょう。ほとんどのチームは、最終的に両方を使うことになります。

## この記事のポイント

- MCPは、対話しながら判断を重ねる作業に向いています。キャンペーンの下書き、オーディエンスの作成、配信の成果が振るわなかった理由の分析などです。
- REST APIは、本番の処理経路に向いています。ユーザーの登録時にトリガーを発火させる、コンタクトを同期する、領収書を送る、といった処理です。
- CLIは、その中間に位置します。APIと同じようにスクリプトから使え、コーディングエージェントも読み取れます。
- Brew のMCPは、OAuth接続と組織全体の接続で、本番の送信に確認を求めます。ブランド単位のAPIキーを使うクライアントには、独自の承認ポリシーが必要です。APIを呼び出すコードでは、確認、冪等性、再試行を自前で用意しなければなりません。

## それぞれの概要

MCP（Model Context Protocol）は、Claude、ChatGPT、Cursor などのAIクライアントにツールを公開するためのオープンな標準規格です。クライアントは、説明とスキーマ付きのツールの一覧を読み、依頼内容に応じてどれを呼び出すかを選びます。Brew のサーバーは `https://brew.new/api/mcp` にあり、OAuthに対応しているので、キーを扱う代わりに、ログインしてブランドを選ぶだけで済みます。

REST APIは、自社のコードから呼び出すHTTPエンドポイントの集まりです。Brew は、APIの OpenAPI 仕様、TypeScript SDK、プレーンテキストの[エージェント向けガイド](https://brew.new/api/v1/llms.txt)を公開しています。すべての呼び出しにAPIキーが付き、何をいつ呼び出すかはコードが決めます。

ほかのベンダーも同じパターンです。Customer.io のMCPサーバーは、APIを[読み取り、書き込み、削除の別々のツール](https://docs.customer.io/ai/mcp/get-started/)で包んでいます。Brevo は、[OpenAPI 仕様](https://developers.brevo.com/docs/mcp-protocol)からMCPのツールを生成しています。

## 比較表

| | MCP | REST API |
| --- | --- | --- |
| 操作の主体 | アシスタントを介した人 | 自社のコード |
| 主な作業 | メールの下書きと修正、オーディエンスの作成、キャンペーンの予約、分析の確認 | イベントトリガーの発火、コンタクトの作成・更新、トランザクションメールの送信、送信ステータスのポーリング |
| 認証 | OAuthでのログイン。OAuthに対応していないクライアントではAPIキー | ブランド単位または組織単位のAPIキー |
| 安全性 | OAuth接続と組織全体の接続では、Brew が本番の送信を確認のために一時停止 | コード次第。冪等性キーと独自の確認ステップを使う |
| エラーへの対応 | アシスタントがエラーを読み、再試行するか、あなたに確認する | 安定したエラーコードで処理を分岐し、バックオフしながら再試行する |
| レスポンスのサイズ | アシスタントのコンテキストウィンドウによって制限される | ページネーションによる制限のみ |
| 適している場面 | 判断や試行錯誤が必要なタスク | 毎回同じように実行しなければならないタスク |

## MCPが適している場面

作業が会話の形をとるなら、MCPを使いましょう。

- キャンペーンの制作。「この変更履歴から10月の製品アップデートを書いて、テストを送ってから、火曜日の9時に予約して」。アシスタントは `create_email`、`edit_email`、`test: true` を付けた `send_email` を呼び出し、次に `scheduledAt` を付けた `send_email` を呼び出して、あなたの承認を待ちます。
- オーディエンスに関する質問。「7月より前に登録して、先月何かしら開封した Pro プランの顧客は何人？」。アシスタントは、`search_contacts`、フィールドの検索、`create_audience` を組み合わせます。
- 分析。「クリック率が一番低いオートメーションはどれ？　何が変わった？」。アシスタントは、`get_email_analytics` とオートメーションのパフォーマンスを読み取ります。
- 1回限りのセットアップ。トリガーとオートメーションを一度だけ作成し、各ステップを人が確認します。

Brew では、MCP経由で生成したメールも、アプリで生成したメールと同じブランドドキュメントを使います。クライアントのセットアップは、[Brew のMCPの発表記事](/ja/blog/brew-mcp)で説明しています。

MCPのレスポンスは、アシスタントのコンテキストに収まる必要があります。Brew の[フローの記事](/ja/blog/email-flows)でも触れているとおり、MCPで完全なHTMLを求めると、長いシーケンスの最初の1〜2ステップしか返ってきませんが、RESTのルートならすべての本文が返ってきます。

## REST APIが適している場面

メールが製品の一部なら、APIを使いましょう。

- イベントトリガー。ユーザーが登録すると、バックエンドがユーザーのメールアドレスとフィールドを付けて `POST /v1/automations/triggers/{triggerEventId}/fire` を呼び出します。あとは、公開済みのオートメーションが処理します。
- トランザクションメール。領収書やパスワードリセットも同じ方法で発火させ、用途を「トランザクション」に設定したドメインのオートメーションから送信します。[トランザクションメール](/ja/blog/transactional-emails)の記事をご覧ください。
- コンタクトの同期。`POST /v1/contacts` は、1回のリクエストで最大1,000件のコンタクトを作成・更新します。
- モニタリング。`GET /v1/sends/{sendId}` は、ダッシュボードやアラートに使える、ステータスと統計を返します。

対応しているエンドポイントでは、ドキュメントに記載された24時間の期間内の再試行に、同じ `Idempotency-Key` とリクエストボディを再利用します（トリガーの発火では、同じキーによる重複が90日間排除されます）。論理的に別の操作には、別のキーを使いましょう。書き込みが冪等性の対象になると決めつける前に、エンドポイントの仕様を読んでください。レート制限のヘッダーは、いつ間隔を空けるべきかを教えてくれます。APIのエラーレスポンスには、`CONSENT_REQUIRED` のような `code` が含まれており、それに応じて処理を分岐できます。ネットワークの障害は別に扱いましょう。これらはすべて、Brew の[APIガイド](https://brew.new/api/v1/llms.txt)で説明しています。

## CLIの位置づけ

ターミナルで動くコーディングエージェントには、どちらの選択肢よりもCLIのほうが向いていることがよくあります。Brew の[CLI](https://docs.brew.new/api-reference/cli/agents)は、ターミナルに接続されていないときはAPIのレスポンスを1行のJSONとして返し、エージェントが判断に使える終了コードを使います。コード4は確認が必要であることを意味し、CLIは、承認後に `--yes` を付けて再実行するための正確なコマンドを表示します。また、`brew-cli types` で型付きのペイロード定義を生成できるので、バックエンドからのトリガーの呼び出しを、トリガーのスキーマと一致させておけます。

## 両方を組み合わせたワークフロー

SaaSのチームなら、たとえば次のように作業を分けられます。

1. 開発者が、Cursor か Claude でMCPを使って `user_signed_up` トリガーとウェルカムのオートメーションを作成し、`test_automation` でテストしてから公開します。
2. バックエンドは、登録のたびに、ユーザーIDから作った冪等性キーを付けて、REST API経由でトリガーを発火させます。
3. 毎月、マーケターがMCP経由で Claude に、製品アップデートの下書きと予約を依頼します。
4. 予約されたアプリケーションのジョブが、現在のアクティベーションや請求の状態を確認してから、リマインダーの対象であることを示す別のイベントを送信します。コンタクトのフィールドを同期するだけでは、実行中のフローの元のイベントペイロードは更新されません。

ステップ1と3では、人がアシスタントの作業を確認します。ステップ2と4は、登録のたび、あるいは毎晩、誰も見ていないところで実行されます。

## よくある質問

### MCPはAPIより遅かったり、信頼性が低かったりしますか？

MCPでは、あなたとエンドポイントのあいだにアシスタントが入るため、リクエストの手順が増え、アシスタントが誤ったツールを選ぶこともあります。対話しながら進める作業なら問題ありませんが、毎回必ず発火しなければならない登録イベントには向きません。

### どちらが安全ですか？

Brew は、OAuth接続と組織全体の接続で、本番の送信に確認を求めます。ブランド単位のAPIキーを使うクライアントでは、独自の承認ポリシーを設定してください。APIを使う場合は、キーを環境変数で保護し、可能な限りブランド単位のキーを使い、再試行するすべての書き込みに冪等性キーを付けましょう。

### 自社製品のエージェントは、APIをツールとして使えますか？

はい。Brew の[エージェント連携ガイド](https://docs.brew.new/integrations/ai-agents/use-brew-with-ai-agents)では、APIのエンドポイントを関数呼び出し（function calling）のツールとして組み込む方法を説明しています。認証と再試行はSDKが処理します。

## 次のステップ

両方を試すなら、キャンペーンの作業用にアシスタントに[MCPサーバー](/ja/mcp)を接続し、バックエンドから発火させるトリガー用にAPIキーを1つ作成しましょう。