Google Workspace×n8nをあえて使う理由──MCPと何が違うのか
「MCPサーバーがあれば、n8nなんていらないんじゃないか？」という疑問、私も最初は持っていました。AIがツールを直接操作できるMCPが普及してきた今、わざわざn8nをセルフホストして使う意味はどこにあるのか。整理してみたら、役割がそもそも違うということがわかってきました。
この記事では、n8nとMCPのそれぞれの役割を整理しながら、Google Workspaceとn8nを組み合わせると何ができるのか、具体的なユースケースを挙げて解説します。「どこに使うかよくわからない」という疑問を持っている方に向けて書いています。
この記事の内容
n8nとMCPは役割が違う──比較して整理する
まずここを整理しておかないと話が混乱します。n8nとMCPは「自動化」という文脈で語られることがありますが、動く場所と目的がそもそも違います。
| 項目 | n8n | MCPサーバー |
|---|---|---|
| 何をするもの？ | サービス間のデータ連携・ワークフロー自動化 | AIアシスタント（Claude等）に外部ツール操作の能力を与える |
| AIが必要？ | 不要（AIノードを追加することは可能） | 必須（AIがMCPを通じてツールを呼び出す） |
| 主なトリガー | Webhook・定期実行・イベント発生 | ユーザーがAIに話しかけたとき |
| 実行タイミング | バックグラウンドで常時稼働・自動 | AIとの会話中・対話的 |
| ホスト場所 | 自前サーバー or n8n.ioクラウド | ローカルPC or サーバー（AIと通信できる場所） |
一言でいうと、n8nは「人が関与しなくても動き続ける自動化」で、MCPは「AIに道具を持たせる仕組み」です。夜中に誰も操作していなくても、フォームの回答が来たら自動でSlackに流してほしい、という用途はn8nの出番。AIに「このGoogleカレンダーに予定を入れて」と頼めるようにしたい、という用途はMCPの出番です。
n8nとMCPは競合ではなく併用できます。n8nでデータの定型処理を自動化しつつ、MCPでAIが必要な場面に対応する、という使い分けが現実的です。
n8nとGASの使い分けはどこで判断するか
Google Workspaceを使っているなら、GAS（Google Apps Script）がすでに使えます。「GASでもできるのにn8nを使う意味は？」という疑問が出るのは自然で、実際に両方できる処理もあります。見分けるポイントは「Workspace外に出るか」「非エンジニアが触るか」「外部サービスを何個またぐか」の3点です。
| やりたいこと | GAS | n8n |
|---|---|---|
| スプレッドシート集計・データ加工 | ◎ 得意。追加コストゼロ | △ できるが大げさ |
| Gmail→スプレッドシートへ記録 | ◎ 十分できる | ○ できるが使う必要は薄い |
| Gmail受信→Slack+CRM+Notionへ同時送信 | △ 各APIをコードで書く必要あり。認証も手動 | ◎ 既製ノードで認証情報を入れるだけ |
| フォーム回答→複数外部サービスへ即時転送 | △ Webhookで可能だが複数サービス連携は複雑 | ◎ フロー図でつなぐだけ |
| 外部SaaSとの定期データ同期（freee・kintone等） | △ APIコードを自分で書く必要あり | ◎ ノードが用意されている |
| 非エンジニアがフローを管理・修正する | ✕ コードを読む必要がある | ◎ ビジュアルで見えて修正しやすい |
| Google Workspace APIを細かく制御 | ◎ 最も柔軟 | △ カスタムノードが必要な場合も |
整理すると、Workspace内で完結する処理はGASで十分。外部サービスが増えるほど・非エンジニアが触るほど・複数ツールを同時に動かすほど、n8nのほうが設定と管理が楽になります。
GASには1回6分の実行時間制限があります
大量データの処理や複数APIを順番に叩く処理は途中で打ち切られることがあります。n8nは実行時間の上限が柔軟で、長い処理にも向いています。
n8nを選ぶ理由が明確なユースケース
「GASでもできる処理」と「n8nのほうが明らかに楽な処理」を区別して紹介します。各例の冒頭にどちらが向いているかを示しています。
① Googleフォーム → 複数外部サービスへの同時連携
n8n向き問い合わせフォームの回答をスプレッドシートに記録するだけなら、GASで十分です。一方、「スプレッドシートへ記録 ＋ Slackへ通知 ＋ HubSpotに顧客追加 ＋ Notionに転記」を同時にやろうとすると、GASでは各サービスのAPIを個別にコードで書き、OAuth認証もサービスごとに設定する必要があります。n8nなら既製のノードを並べてつなぐだけです。外部サービスが2つ以上になった時点でn8nの優位性が出てきます。
② Gmail受信 → 外部CRMへの自動登録
n8n向きGmailのトリガーでスプレッドシートに記録するだけならGASで作れます。ただし「HubSpot・Salesforce・kintoneなどのCRMに自動登録する」となると、GASではそれぞれのREST APIを自力で叩くコードが必要です。n8nにはHubSpot・Salesforce・kintone等のノードが用意されており、認証情報を入力するだけで接続できます。
③ 外部予約フォーム → Googleカレンダー + 確認メール + スプレッドシート
どちらでも可Googleカレンダーへの登録と確認メール送信はGASでも実装できます。ただし「外部の予約システム（Calendly・Typeformなど）からのWebhookを受けて処理する」場合は、GASのWebhookよりn8nのほうがエラー検知・再試行の仕組みが整っています。また、予約確認メールを送りつつ別のSlackチャンネルにも通知する、という1つのトリガーから複数アクションはn8nが得意です。
④ DriveのファイルアップロードをトリガーにしたSlack通知
どちらでも可GASのDriveトリガーでもSlack通知は実装できます（SlackのIncoming WebhookのURLをGASで叩く）。ただしSlackノードがあるn8nの方が設定が短いです。Slack通知だけで完結するならGASで十分、通知と同時に他のサービスへのアクションも加えたい場合はn8nが楽という判断基準になります。
⑤ スプレッドシート → freee・kintone等への定期同期
n8n向きGASからfreeeやkintoneのAPIを叩くことは技術的には可能ですが、認証トークンの管理・エラー処理・再試行ロジックを全部コードで書く必要があります。n8nにはfreeeやkintoneの専用ノードが用意されており、APIの細かい仕様を知らなくてもフロー設定だけで同期が組めます。定期的にデータを連携するバッチ処理で特に差が出ます。
n8nをセルフホストする意味──コストとデータ管理
n8nにはクラウド版（n8n.io）もありますが、あえてセルフホストする理由もあります。
コスト面
n8n.ioのクラウド版は無料枠が限られており、ワークフロー数やエグゼキューション数が増えると有料プランが必要です。一方でVPS（さくらVPS・ConoHa等）にDockerでセルフホストすれば、月数百〜1,000円程度のサーバー代だけで制限なしに使えます。すでにレンタルサーバーやVPSを持っている場合は特にコストメリットが大きいです。
データの管理
n8nのフロー内を流れるデータ（メールの本文・顧客情報など）が自社管理のサーバー上に閉じている、という点もセルフホストのメリットです。クラウドサービスにデータを預けることへの懸念が社内にある場合、セルフホストが選択肢になります。
レンタルサーバーとVPSは違います。一般的なレンタルサーバーはDockerが使えないためn8nのセルフホストには向きません。VPS（仮想サーバー）であればDockerを動かせるケースがほとんどです。さくらVPS・ConoHa VPS・お名前.com VPS等が選択肢です。
どれを選ぶか迷ったときの判断基準
GAS・n8n・MCPを場面によって使い分けるための簡単な判断基準を整理します。
判断フロー
- Workspace内だけで完結する処理 → GAS（Claude Codeで書く）
- 複数の外部サービスをまたぐ定型的なデータ連携 → n8n
- AIと会話しながら動的にツールを操作したい → MCPサーバー
- AIを使いつつ定型処理も自動化したい → n8n + MCP の併用
「自動化」とひとくちに言っても、人が操作するかどうか・AIが関与するかどうか・どのサービスをまたぐかによって、適したツールは変わります。どれが正解というわけではなく、用途に合わせて組み合わせるのが現実的な使い方です。
個人的に感じているのは、n8nはビジュアルで全体のフローが見えるので、「誰が作ったかわからなくなったコード」になりにくいという点が地味に便利だということです。GASのコードは書いた本人以外が読み解くのが大変な場合もありますが、n8nのフロー図は非エンジニアでも何をやっているかがある程度わかります。チームで自動化を管理する場面では、この可読性が意外と重要になってきます。