Zapier MCP使い分け — MakeとClaude連携の選び方

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サーバーで、既存のZapier連携(9,000以上のアプリ)をClaudeから呼び出せるようにします。ガイド付きセットアップで数分で使い始められ、追加のターミナル操作や設定ファイル編集は不要です。

Make MCPは、MakeのMCPサーバー機能とMCPクライアント機能の2つを指します。MCPサーバー機能はMakeのシナリオをClaudeから呼び出し可能なツールとして公開し、3,000以上のアプリと30,000以上のアクションに対応します。MCPクライアント機能は逆方向で、Makeのシナリオ自体が外部のMCPサーバーに接続してツールを呼び出せるようにするものです。

直接MCPは、対象のSaaSのベンダーが用意したMCPサーバーやConnectorをそのまま使うか、無ければ自分でREST APIをMCPサーバーとしてラップして使う方法です。自作の手順は業務SaaS MCP連携ガイドにまとめています。

評価軸

3方式を比べる軸は5つです。対応アプリ数、セットアップにかかる手間、料金体系、カスタムロジックをどこまで組み込めるか、そして障害や仕様変更が起きたときに誰が保守するかです。

比較表

Zapierの強みと弱み

強みは対応アプリ数の多さと導入の速さです。すでにZapierで連携済みのアプリは、追加の認証をやり直さずそのままClaudeから呼び出せます。弱みは、呼び出しが既存のタスク消費枠を使う点です。自動化と会話からの呼び出しを同じ枠で共有するため、利用量が多い組織では枠の圧迫を考慮する必要があります。

Makeの強みと弱み

強みはアクション数の多さと、全プランに無料で組み込まれている点です。フリープランでも試せるため、まず動かしてみる敷居が低くなります。弱みは、Zapier MCPほど「ガイドに沿うだけ」の単純さではなく、対象の操作をシナリオとして事前に組んでおく前提がある点です。単発の問い合わせにその場で対応する用途より、あらかじめ決めた操作をClaudeから呼び出す用途に向きます。

直接MCPの強みと弱み

強みはカスタムロジックの自由度です。ZapierやMakeが対応していない操作、複雑な条件分岐、社内システム固有のデータ整形も、自作すれば実装できます。弱みは、公式のMCPサーバーやConnectorが無いSaaSでは自分で実装から保守まで担う必要がある点です。

claude mcp add --transport http notion https://mcp.notion.com/mcp

対象SaaSにベンダー提供のMCPサーバーがある場合は、上のようにURLを指定するだけで数分で接続できます。無い場合の自作手順は前述の業務SaaS MCP連携ガイドに譲り、ここでは自作したサーバーをClaude.ai側でカスタムConnectorとして登録する手順としてClaude Connectorsとはを挙げておきます。

状況別の使い分け早見表

3つを併用するときの設計

実務では3方式を排他的に選ぶより、役割を分けて併用する構成のほうが多くなります。典型的な組み合わせは、日次・週次で決まった転記や同期はZapierかMakeの通常のシナリオに任せ、Claudeとの対話の中で「今月のデータをこう集計して」のような都度変わる依頼だけをZapier MCPかMake MCPに投げる形です。1つのSaaSだけ特に深く使い込みたい場合は、そのSaaSだけ直接MCPに切り替え、残りはZapier・Make経由のままにする、という部分的な移行も現実的です。

3方式を併用する際に注意したいのは、同じ操作を複数の経路から呼べる状態を作らないことです。たとえばあるSaaSへの書き込みをZapier MCP経由でもできるようにしつつ、同時に直接MCPでも同じ操作をツール化すると、Claudeがどちらを選ぶかは説明文の書き方に左右されます。同一の操作は1つの経路に一本化し、ツールの説明文で役割を明確に分けておくと、意図しない経路が選ばれる事態を防げます。

乗り換えを検討するタイミング

最初はZapier MCPやMake MCPで始めても、運用が進むにつれて直接MCPへの乗り換えを検討したくなる場面が出てきます。目安は2つです。ひとつは、対応済みのアクションだけでは表現できない条件分岐やデータ整形が増えてきたとき。もうひとつは、タスク消費やクレジット消費が既存の自動化と競合し、Claudeからの呼び出しのために追加のプランアップグレードを検討し始めたときです。どちらかに当てはまり始めたら、対象のSaaSに絞って直接MCPへ切り替えるコストと、消費枠を増やし続けるコストを比較する価値があります。

よくあるつまずき

タスク消費・クレジット消費が既存の自動化と競合する

Zapier MCPの呼び出しは既存のタスク枠を、Make MCPの呼び出しは実行クレジットを消費します。すでに他の自動化シナリオでこれらの枠を使い切っている組織では、Claudeからの呼び出しがそこに上乗せされる点を見落としがちです。導入前に現在の消費量を確認しておきます。

MCPを「定期実行」の手段だと勘違いする

MCPは基本的には会話の中でClaudeがツールを呼び出す仕組みで、時刻トリガーでの自動実行は担いません。毎日決まった時刻に転記や同期を走らせたい場合は、MCP経由でClaudeに毎回頼むのではなく、ZapierやMakeの通常のシナリオ(トリガー+アクション)をそのまま使うほうが適しています。なお、MCPサーバーがclaude/channel capabilityに対応し起動時に--channelsフラグで有効化している場合は、Webhookイベントなどをセッションにプッシュしてやり取りが自動的に進むケースもあります。

自作MCPのレート制限とZapier/Makeの消費枠を同一視する

自作MCPサーバーはSaaS側のAPIレート制限を直接受けますが、ZapierやMakeを経由する場合はプラットフォーム側の消費枠が別に発生します。両方を併用する構成では、どちらの上限が先に効くかを事前に整理しておくとトラブルを避けられます。

よくある質問

Zapier MCPとMake MCPは同時に使えますか

使えます。Claude Code・Claude.aiともに複数のMCPサーバーを同時に登録でき、片方をZapier MCP、もう片方をMake MCPとして併用する構成も技術的には問題ありません。ただし対応アプリが重複する場合は、どちらを優先して呼ばせるかツールの説明文で明確にしておくと、意図しないほうが呼ばれる事態を避けられます。

直接MCPのほうがセキュリティ的に安全ですか

一概には言えません。ベンダー提供のMCPサーバーやConnectorはベンダー側で審査・保守されますが、自作MCPサーバーは認証情報の管理やアクセス範囲の制御を自分で設計する必要があります。ZapierやMakeを経由する場合は、各プラットフォーム側の権限設定に依存します。どの方式でも、渡す権限の範囲を必要最小限に絞ることが前提です。

まず無料で試せる方法はどれですか

Make MCPは全プランに無料で組み込まれており、フリープランでも試せます。Zapier MCPは既存のZapierプランに含まれるため、Zapierを契約していなければ別途プランが必要です。直接MCPは、ベンダー提供のConnectorであれば追加費用なしで試せるケースが多く、自作はホスティング費用を別に見込む必要があります。まったく契約が無い状態から試すなら、Make MCPのフリープランがもっとも入口が低い選択肢になります。

途中で方式を変えることはできますか

できます。ZapierやMakeで組んだ連携を後から直接MCPに置き換えても、Claude側での使い勝手(会話の中でツールが呼ばれる体験)は変わりません。変わるのは裏側の実装とコストの構造だけです。逆に、直接MCPで自作したサーバーが保守負担になってきた場合、対応済みのアプリであればZapierやMakeへ乗り換えて保守をプラットフォーム側に委ねる選択もできます。

まとめ

3方式のどれか1つが常に正解になるわけではなく、契約中のツールと連携させたいSaaSの範囲によって最適解が変わります。Zapier MCPとMake MCPは、すでにその自動化ツールを使っているチームにとって導入コストが最も低い選択肢です。対応アプリ数の広さを活かし、複数SaaSを横断する連携をノーコードで組みたい場面に向きます。一方、1つのSaaSを深く使い込みたい、あるいは対応済みのアプリに無い操作が必要な場面では、直接MCP(ベンダー提供のConnectorか自作サーバー)のほうが自由度で勝ります。決まった時刻での自動実行が目的なら、そもそもMCPではなくZapierやMakeの通常のシナリオ機能を使うのが筋です(ただし一部のMCPサーバーはchannel経由でWebhookイベントを受け取れる例外もあります)。3つを排他的に選ぶのではなく、用途ごとに使い分けるのが実務的な落としどころになります。