【Chatworkシリーズ #6】MCP vs GAS — Chatwork自動化の「正解」はどっちか

Last updated at 2026-04-09Posted at 2026-03-13

Chatworkの自動化には2つのルートがある。

MCP（Model Context Protocol） と GAS（Google Apps Script）。どちらもChatwork APIを叩ける。どちらも無料で使える。どちらも「自動化できました！」という記事が書ける。

でも実際に両方を数ヶ月使い倒してみたら、用途がまったく違うことがわかった。「どっちがいいですか？」という問いへの答えは「両方使え、ただし使い分けろ」だ。

この記事では、Chatwork APIをMCP経由とGAS経由の両方で運用してきた経験から、それぞれの得意・不得意と、実際の使い分けパターンを書く。

前提：自分の環境

Chatwork APIトークンは2つ（個人用 + 組織用）
MCP: Claude Code / Cursor / Antigravity など、MCPに対応したAIコーディングツール経由で接続。自分の環境ではClaude Codeで複数アカウントを同時接続
GAS: 5つのスクリプトプロジェクトでChatwork APIを使用。定期実行あり
n8n: VPS上でChatwork Webhook連携。24時間稼働

つまり、MCPもGASもn8nも全部使っている。偏りのない比較ができると思う。

MCPの得意なこと

1. 「今」の状況把握

MCPの最大の強みは対話的にChatworkを操作できること。

「未読メッセージを確認して」
「○○のルームの最新10件を見せて」
「このメッセージに返信して」

Claude Code、Cursor、Antigravityなど、MCP対応ツールから話しかけるだけで、Chatworkの状態がリアルタイムに取れる。17ルームの未読を10秒で片付けられるのはMCPならではだ。

2. 判断を伴う操作

「このメッセージの内容を読んで、緊急度が高ければ別ルームに転送して」のような、AIの判断が必要な操作はMCPが圧倒的に強い。GASでやろうとすると、判断ロジックをコードに書かなければいけない。MCPなら自然言語で指示するだけ。

3. アドホックな調査

「先週、山田さんが言ってた件を探して」「この3つのルームで共通のメンバーは？」のような、一回きりの調査。スクリプトを書くほどでもない作業は、MCPで会話しながら進めるのが速い。

MCPの不得意なこと

1. 定期実行ができない

MCPはClaude CodeやCursorのセッション内でしか動かない。セッションを閉じたら止まる。「毎朝9時にルームの要約を送る」はMCPだけでは実現できない。

2. 複雑なデータ加工

Chatworkから取得したデータをスプレッドシートに書き込む、PDFを生成する、別のAPIに渡す——こういうパイプライン処理はMCPの守備範囲外。できなくはないが、GASの方が圧倒的に安定する。

3. エラーハンドリングが弱い

MCPでAPI呼び出しが失敗したとき、リトライロジックやフォールバックを組むのは難しい。GASならtry-catchで書ける。本番運用では信頼性が重要だ。

4. セッション依存

Claude CodeやCursorを閉じたら終わり。MCP経由の自動化は人間がPCの前にいることが前提になる。夜間バッチ、休日処理はできない。

GASの得意なこと

1. 定期実行（トリガー）

GASの最大の強みはタイムドリブントリガー。「毎朝9時に」「毎月1日に」「5分おきに」が設定画面から1クリックで設定できる。

// 毎朝9時に未読を要約してルームに投稿
function dailySummary() {
  const messages = fetchUnreadMessages();
  const summary = formatSummary(messages);
  postToRoom(ROOM_ID, summary);
}

2. スプレッドシート連携

Chatworkのデータをスプレッドシートに書き出す、スプレッドシートの内容をChatworkに送る。この双方向連携はGASの独壇場。

自分の環境では、請求書データをスプレッドシートで管理し、確定連絡がChatworkに来たらGASがMisoca APIで請求書を生成してPDFをChatworkに送り返している。この一連のパイプラインはGASでなければ組めない。

3. 本番運用の安定性

try-catch、Utilities.sleep()によるレート制限回避、PropertiesServiceによる状態管理。GASは壊れにくい自動化が書ける。

function safeApiCall(url, options, maxRetries = 3) {
  for (let i = 0; i < maxRetries; i++) {
    try {
      const response = UrlFetchApp.fetch(url, options);
      if (response.getResponseCode() === 200) return response;
    } catch (e) {
      Utilities.sleep(1000 * (i + 1));
    }
  }
  throw new Error(`API call failed after ${maxRetries} retries`);
}

4. 無料で24時間動く

Google のインフラ上で動く。サーバー不要。月間の実行時間制限はあるが（無料枠で90分/日）、普通のChatwork自動化なら余裕で収まる。

GASの不得意なこと

1. AIの判断が入れられない

「このメッセージの雰囲気が怒ってたら、丁寧な返信を自動生成して」——GASだけでは無理。外部のAI API（Gemini等）を呼べば不可能ではないが、プロンプト設計・レスポンスパース・コスト管理が全部自分の仕事になる。

2. 開発体験がつらい

GASのエディタは正直しんどい。型補完なし、デバッガは最低限、デプロイのたびに数秒待つ。Claude CodeやCursorで書いてclaspでpushする運用にすれば改善するが、それでもTypeScriptの開発体験には遠く及ばない。

3. multipart/form-dataが地獄

Chatwork APIの/rooms/{id}/files（ファイルアップロード）はmultipart/form-dataを要求する。GASのUrlFetchAppはこれをネイティブサポートしていない。バイト配列を手動で組み立てる必要がある。正直、ここだけで半日溶けた。

使い分けの結論

用途	正解	理由
未読確認・状況把握	MCP	対話的。速い
アドホック調査	MCP	スクリプト不要
判断を伴う操作	MCP	AIが判断してくれる
定期実行（バッチ）	GAS	トリガーが使える
スプレッドシート連携	GAS	独壇場
パイプライン処理	GAS	安定性が必要
外部API連携	GAS or 自動化PF	本番運用向き
24時間自動化	GAS + 自動化PF	セッション不要
AI判断を含む自動化	Dify等 + GAS	RAG/AIワークフロー
メッセージ内容の分析	MCP	AI判断が必要
ファイルアップロード	MCP	GASのmultipartが地獄

一言でまとめると：

MCP = 人間の目と手の延長。今、この瞬間にChatworkを操作する
GAS = 24時間動く自動化基盤。人間がいなくても回る仕組みを作る

実際の運用パターン

自分の環境では、こう使い分けている。

朝: MCPで17ルームの未読を一括確認（10秒）
日中: MCPでアドホックな調査・返信
夜間: GASトリガーで月次リマインド自動送信
定期: GASで請求書自動生成パイプライン
常時: n8nでWebhook待機 → Chatworkメッセージ → 自動処理

MCPとGASは競合しない。レイヤーが違う。MCPは対話レイヤー、GASは自動化レイヤー。両方使うのが正解だった。

実はこの2つだけではカバーしきれない領域がある。自動化プラットフォームを3層目に入れると隙がなくなる。

ツール	得意なこと	Chatwork連携
n8n	Webhookトリガー、セルフホスト、複雑なフロー	ノード標準搭載
Dify	RAG、AIワークフロー、ナレッジベース連携	API経由
Zapier	ノーコード、5000+アプリ連携、導入の手軽さ	公式インテグレーション
Make（旧Integromat）	ビジュアルフロー、コスパ	Chatworkモジュールあり

自分の環境ではn8nをVPSで動かしているが、Zapierの方が導入は圧倒的に楽だ。Difyは「AI判断を含む自動化」で強い。FAQ自動回答のようにナレッジベースを持たせたい場合はDify + GASの組み合わせが効く。

つまり実際のレイヤーは3層ある：

MCP = 対話レイヤー（今、この瞬間の操作）
GAS = 自動化レイヤー（定期実行・スプレッドシート連携）
自動化PF（n8n / Dify / Zapier等） = 連携レイヤー（Webhook・AI判断・外部サービス統合）

「どっちから始めるべきか」

MCPだ。

理由は単純で、始めるのに1分もかからないから。

claude mcp add chatwork -s user -- npx -y @anthropic-ai/chatwork-mcp

これだけ。APIトークンを環境変数にセットすれば、すぐにChatworkをClaude Codeから操作できる。CursorやAntigravityでも同様にMCP設定からChatworkを追加するだけだ。

GASはスクリプトを書いて、トリガーを設定して、デバッグして……と、動くまでに時間がかかる。MCPで「Chatwork APIで何ができるか」を体感してから、定期実行が必要な部分だけGASに移す。この順番が効率的だ。

MCPとGAS、両方使ってる人っていますか？　使い分けのパターンが気になる。コメントで教えてもらえると嬉しい。

Chatworkシリーズ

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up