Zapier MCP使い分け — MakeとClaude連携の選び方
ZapierのMCP対応・MakeのMCP対応・直接のMCP連携の3方式を、対応アプリ数・料金・カスタム性の軸で比較し、状況別の使い分けをまとめます。
Zapier・Make・直接MCP、Claude連携はどれを選ぶか
ClaudeをSaaSにつなぐ方法は1つではありません。Zapierが提供するMCP対応、MakeのMCP対応、そして特定のSaaSに絞って直接MCPでつなぐ方法の3つがあり、どれも競合というより守備範囲が違います。メール・カレンダー・チャットなど複数のSaaSを同時接続して使う場合の設定・優先順位の考え方はClaude複数SaaS連携で日次業務を一元化するで扱っています。すでにZapierかMakeで自動化を組んでいるなら、その延長でMCP対応を使うのが最短です。1つのSaaSを深く使い込みたい、あるいは対応済みのアプリに無い操作をさせたいなら、直接MCP(ベンダー提供のConnectorか自作サーバー)のほうが向いています。
比較対象: 3つの連携方式
MCP(Model Context Protocol)自体の仕組みはMCPとはで扱っています。本記事はその上で「どの経路でつなぐか」に絞ります。
Zapier MCPは、Zapierが提供するMCPサーバーです。Claude・ChatGPT・Cursorなどのクライアントから、9,000以上のアプリと66,000以上のトリガー・アクションを呼び出せます。使う操作を事前に選ぶ必要はなく、エージェントが目的に合うアクションを検索して実行します。標準のアクションで足りないときは、エージェントがコードを書いて内部APIへの呼び出しやデータの整形を行う仕組みもあります。
Make MCPは、Makeのシナリオと管理機能をClaudeなどから呼び出せるMakeホスト型のMCPサーバーです。Streamable HTTPで動き、OAuthの汎用URL(https://mcp.make.com)かMCPトークン付きURLのどちらかで接続します。シナリオを実行するツールは全プランで使え、シナリオやチームを操作する管理ツールは有料プランで使えます。
直接MCPは、対象のSaaSのベンダーが用意したMCPサーバーやConnectorをそのまま使うか、無ければ自分でREST APIをMCPサーバーとしてラップして使う方法です。自作の手順は業務SaaS MCP連携ガイドにまとめています。
評価軸
3方式を比べる軸は5つです。対応アプリ数、セットアップにかかる手間、料金体系、カスタムロジックをどこまで組み込めるか、そして障害や仕様変更が起きたときに誰が保守するかです。
比較表
| 項目 | Zapier MCP | Make MCP | 直接MCP(ベンダー提供 / 自作) |
|---|---|---|---|
| 対応範囲 | Zapier MCP9,000以上のアプリ・66,000以上のアクション | Make MCP作成済みのシナリオ(+ 有料プランは管理ツール) | 直接MCP(ベンダー提供 / 自作)対象の1SaaSのみ |
| セットアップ | Zapier MCPClaudeなどのクライアントから接続。接続済みアプリは自動で有効化 | Make MCPシナリオの事前作成が前提 | 直接MCP(ベンダー提供 / 自作)ベンダー提供はURLの指定が中心、自作は実装が必要 |
| 料金 | Zapier MCP全プランに含まれ、Zapierプランのタスクを消費 | Make MCP実行ツールは全プランで利用可 | 直接MCP(ベンダー提供 / 自作)料金はベンダーごとに異なる、自作はホスティング費用が別途かかる |
| カスタムロジック | Zapier MCP標準アクション + エージェントが書くコード | Make MCPMakeのルーター・モジュールの範囲内 | 直接MCP(ベンダー提供 / 自作)制約なく実装できる |
| 保守の主体 | Zapier MCPZapier側 | Make MCPMake側 | 直接MCP(ベンダー提供 / 自作)ベンダー提供ならベンダー、自作なら自分 |
呼び出し1回の扱いはZapierとMakeでどう違うか
同じ「Claudeからの1回の呼び出し」でも、数え方と待ち時間の扱いが違います。ここを知らないまま導入すると、請求と動作の両方でつまずきます。
1回の呼び出しの扱い
Zapier MCP
成功したツール呼び出し1回につき、Zapierプランのタスクを2つ使います。失敗した呼び出しはタスクに数えません。自動化と会話からの呼び出しが同じ枠を使うので、月の消費は両方の合計で見ます。
Make MCP
シナリオ実行ツールの応答待ちは、OAuth接続で25秒、MCPトークン接続で40秒です。超えるとタイムアウトの応答が返りますが、シナリオ自体は最大40分まで動き続けます。
Makeのタイムアウト応答にはexecutionIdが含まれ、クライアントはこれで完了後の結果を取りに行けます。取りに行くには、接続時のスコープにscenarios:readを選んでおく必要があります。時間のかかるシナリオを会話から呼ぶなら、最初のスコープ選択で決まる部分です。
Zapierの強みと弱み
強みは対応アプリ数の多さと、操作を事前に選ばなくてよい点です。エージェントが目的から逆算してアクションを探し、足りない入力は聞き返します。アプリの認証情報はZapier側の接続層に残り、モデルには渡されません。実行した操作は履歴で見直せ、アプリ単位・アクション単位でアクセスを絞れます。
Zapier MCPも全プランに含まれますが、弱みは呼び出しのたびにタスクを使う点です。利用量が多い組織では既存の自動化と同じ枠が圧迫されるので、導入前に現在のタスク消費量を見ておきます。接続トークンの扱いにも注意が要ります。接続トークンは長期間有効で、持っている人がそのサーバーのツールを実行して結果を読めるため、共有しない前提です。
Makeの強みと弱み
強みは、操作をシナリオとして固定できる点です。シナリオ実行ツールは全プランで使えます。シナリオの入力と出力がそのままツールの引数と戻り値になり、説明文を丁寧に書くほどClaudeが呼び分けやすくなります。
弱みは、操作を事前に選ばなくてよいZapierと違い、操作をシナリオとして先に組んでおく前提がある点です。単発の問い合わせにその場で対応する用途より、決めた操作を呼び出す用途に向きます。有料プランの管理ツールを使えばシナリオ自体の作成・変更もClaudeから頼めます。接続とシナリオのツール化の具体的な設定はMake MCPサーバーでシナリオをClaudeから実行するで扱っています。
Claude CodeにMake MCPをつなぐ流れ(OAuth)
- 1
サーバーを追加する
この図の下のコマンドをターミナルで実行します。
- 2
Claude Code内で認可する
claudeを起動して/mcpを実行し、Makeのサーバーを選びます。 - 3
組織とスコープを選ぶ
ブラウザの同意画面で組織とスコープを選びます。スコープが、Claudeに見えるツールの範囲になります。
claude mcp add --transport http make https://mcp.make.com同意画面の「Run your scenarios」スコープは、組織内のオンデマンドと有効化済みのシナリオすべてへのアクセスを許可します。範囲をさらに絞りたければ、Teamsプラン以上でチーム単位のユーザーアカウントを作る方法があります。接続がうまくいかないときの代替は、MCPトークン付きのURLです。
直接MCPの強みと弱み
強みはカスタムロジックの自由度です。ZapierやMakeが対応していない操作、複雑な条件分岐、社内システム固有のデータ整形も、自作すれば実装できます。弱みは、公式のMCPサーバーやConnectorが無いSaaSでは自分で実装から保守まで担う点です。
claude mcp add --transport http notion https://mcp.notion.com/mcpベンダー提供のMCPサーバーがあるSaaSなら、上のようにURLを指定するだけで接続できます。Claude Codeは、HTTPで接続できないSSEのみのサーバーにも、v2.1.265以降で自動的にSSEへ切り替えて対応します。自作したサーバーをClaude.ai側でカスタムConnectorとして登録する手順はClaude Connectorsとはが扱います。1つのベンダーが用途別に複数のサーバーを出す例はUpstashのMCPサーバーガイドにあります。
状況別の使い分け早見表
| 状況 | 向いている方式 |
|---|---|
| すでにZapierで他の自動化を組んでいる | 向いている方式Zapier MCP |
| すでにMakeでシナリオを運用している | 向いている方式Make MCP |
| 対象SaaSにベンダー提供のMCPサーバーがある | 向いている方式直接MCP(ベンダー提供) |
| 対象SaaSにAPIはあるがベンダー提供の連携が無い | 向いている方式直接MCP(自作) |
| 1つのSaaSを深く使い込みたい・独自ロジックが必要 | 向いている方式直接MCP |
| 複数SaaSを横断して連携したい、かつノーコードで済ませたい | 向いている方式Zapier MCP・Make MCP |
| 決まった時刻で機械的に処理を流したい | 向いている方式Zapier・Makeの自動化(MCPでなく通常のZap・シナリオ) |
3つを併用するときの設計
実務では3方式を排他的に選ぶより、役割を分けて併用する構成のほうが多くなります。日次・週次の決まった転記や同期はZapierかMakeの通常のシナリオに任せ、Claudeとの対話で都度変わる依頼だけをMCPに投げる形が典型です。1つのSaaSだけ深く使い込みたい場合は、そのSaaSだけ直接MCPに切り替え、残りはZapier・Make経由のままにする部分的な移行も現実的です。
注意したいのは、同じ操作を複数の経路から呼べる状態を作らないことです。あるSaaSへの書き込みをZapier MCP経由でも、直接MCPでもツール化すると、Claudeがどちらを選ぶかは説明文の書き方に左右されます。同一の操作は1つの経路に一本化し、説明文で役割を分けておきます。Zapier・Makeどちらも複数のMCPクライアントから使えるので、Claude CodeとClaude.aiの両方から同じ接続を使い回す構成も取れます。
乗り換えを検討するタイミング
最初はZapier MCPやMake MCPで始めても、直接MCPへの乗り換えを検討する場面が出てきます。目安は2つです。ひとつは、対応済みのアクションだけでは表現できない条件分岐やデータ整形が増えたとき。もうひとつは、Zapierのタスク消費が既存の自動化と競合し、Claudeからの呼び出しのためにプランの引き上げを考え始めたときです。
どちらかに当てはまり始めたら、対象のSaaSだけ直接MCPへ切り替えるコストと、消費枠を増やし続けるコストを比べる価値があります。切り替えてもClaude側の使い勝手(会話の中でツールが呼ばれる体験)は変わりません。変わるのは裏側の実装とコストの構造です。逆に、自作サーバーの保守が重くなったら、対応済みのアプリに限ってZapierやMakeへ戻して保守を預ける選択もあります。
よくあるつまずき
MCPを「定期実行」の手段だと勘違いする
MCPは基本的に、会話の中でClaudeがツールを呼び出す仕組みです。時刻トリガーでの自動実行は担いません。毎日決まった時刻に転記や同期を走らせたい場合は、MCP経由でClaudeに毎回頼むのではなく、ZapierやMakeの通常のシナリオ(トリガー+アクション)を使うほうが適しています。
例外として、MCPサーバーがclaude/channel capabilityに対応し、起動時に--channelsフラグで有効化している場合は、Webhookイベントなどをセッションにプッシュできます。
自作MCPのレート制限とZapier/Makeの消費枠を同一視する
自作MCPサーバーはSaaS側のAPIレート制限を直接受けますが、ZapierやMakeを経由する場合はプラットフォーム側の消費枠が別に発生します。両方を併用する構成では、どちらの上限が先に効くかを事前に整理しておくとトラブルを避けられます。
時間のかかるシナリオが「失敗」に見える
タイムアウトの応答が返った後もシナリオは動き続けているので、同じ依頼をもう一度投げると二重実行になりかねません。再送せず、前掲のexecutionIdで結果を取りに行きます。
よくある質問
直接MCPのほうがセキュリティ的に安全ですか
一概には言えません。ベンダー提供のMCPサーバーやConnectorはベンダー側で保守されますが、自作MCPサーバーは認証情報の管理やアクセス範囲の制御を自分で設計する必要があります。ZapierやMakeを経由する場合は、各プラットフォーム側の権限設定に依存します。どの方式でも、渡す権限の範囲を必要最小限に絞ることが前提です。
試すときの入口はどれですか
ZapierもMakeも全プランで使えます。違いは消費と事前準備で、Zapier MCPは成功した呼び出し1回でタスクを2つ使い、Makeはシナリオを先に1本作る必要があります。直接MCPの料金はベンダーごとに異なり、自作はホスティング費用を別に見込みます。
まとめ
選ぶ前に確かめたいのは3点です。Zapier MCPなら、呼び出し1回2タスクが既存の枠に収まるか。Makeなら、25秒・40秒の待ち上限と接続時のスコープで足りるか。直接MCPなら、保守を自分で持てるか。契約中のツールがあれば、その延長から始めるのが手軽です。