この記事で分かること

n8n（ノーコード）とGoogle Apps Script（コード）の判断軸を「実行環境・データ所在・変更頻度」の3点に整理する
同じ「AI API呼び出し + 定期実行」の処理を両者で実装したコードを比較する
実務での使い分けパターン（どちらに寄せるべきケース）を具体例で確認する

前提：それぞれの立ち位置

n8nはノードを線でつなぐビジュアルワークフローツール、GASはGoogleのインフラ上で動くJavaScript実行環境です。両者とも「HTTPリクエストで外部APIを叩いて、定期実行する」まではほぼ同等の能力があります。違いが効いてくるのは、その先のデータの所在と変更頻度です。

観点	n8n	GAS
実行環境	セルフホスト（Docker）/ n8n Cloud	Googleサーバー（無料枠あり）
主戦場	SaaS間連携・外部API群	スプレッドシート・Gmail・カレンダー
実装方式	ノード接続 + 式	JavaScript（ES2020相当）
定期実行	Schedule Trigger（分単位〜）	時限トリガー（時刻指定・ずれあり）
AI API呼び出し	HTTP Requestノード / OpenAIノード	UrlFetchApp.fetch()
変更のしやすさ	GUIで差し替え容易	コード修正 + デプロイ

この表だけを見ると「全部n8nでよい」ように見えますが、実際はGoogleサービスが絡むと話が変わります。

判断軸1：データの所在

Googleのデータ（スプレッドシート・Gmail・カレンダー）を直接読み書きするならGASが圧勝です。

GASのスプレッドシート操作はSpreadsheetApp一本で完結し、認証も承認ボタンを押すだけ。一方n8nからGoogle Sheetsを扱うにはOAuth2クレデンシャルの設定（クライアントID・シークレット・リフレッシュトークン）が必要で、初回セットアップの手間が一段大きい。

逆に、Google以外のSaaSを複数またぐならn8nが圧勝です。Slack・Notion・GitHub・各種SaaSの専用ノードが用意されており、OAuthの面倒な部分をn8nが引き受けてくれます。GASで同じことをやると、各サービスのOAuthを自前で回すことになる。

判断軸2：ロジックの複雑さ

単純な「取得・変換・送信」ならn8nのノード接続が速い。ただし、ロジックが複雑になるとn8nの式とノード分割がつらくなり始めます。

例えば「メール本文からAIで分類ラベルを取得し、ラベル別に異なる処理をする」場合を考えます。n8nのIFノードでJSONレスポンスを受け取る場合、式は文字列比較になることが多く、レスポンスのゆらぎ（余計な空白、カギカッコ付き等）を吸収するのは式だけでは不十分です。Setノードで正規化してからIFノードに流すのが定石です。

GASなら同じ処理を普通のJavaScriptで書けます。

function classifyLabel(raw) {
  // AI応答のゆらぎを正規化してから判定
  const label = String(raw)
    .trim()
    .replace(/[「」『』"]/g, '')
    .toUpperCase();
  if (label.includes('SUPPORT')) return 'support';
  if (label.includes('SALES'))   return 'sales';
  if (label.includes('OTHER'))   return 'other';
  return 'other'; // 想定外はデフォルトに寄せる
}

この「前処理→正規化→分岐」の流れを1関数に書けるかどうかが、コード側の快適さの分かれ目です。n8nでもCodeノード（JavaScript）を挟めば同等のことはできますが、ロジックの中心がCodeノードになった瞬間、n8nの利点（可視化）が薄れるのは否めません。

実装比較：AI API呼び出し

同じ「AI APIを1回呼ぶ」を両者で書いてみます。例としてChatGPT API。

n8n（HTTP Requestノード）：設定はGUI。Method=POST、URLはapi.openai.com/v1/chat/completions、Authentication=Generic Credential TypeでBearer Token、BodyはJSONで前ノードの出力を式で差し込む。

GAS：

function callChatGPT(prompt) {
  const res = UrlFetchApp.fetch('https://api.openai.com/v1/chat/completions', {
    method: 'post',
    contentType: 'application/json',
    headers: {
      Authorization: 'Bearer ' + PropertiesService.getScriptProperties().getProperty('OPENAI_API_KEY')
    },
    payload: JSON.stringify({
      model: 'gpt-4o-mini',
      messages: [{ role: 'user', content: prompt }]
    }),
    muteHttpExceptions: true
  });
  if (res.getResponseCode() !== 200) {
    throw new Error('ChatGPT API error: ' + res.getResponseCode() + ' ' + res.getContentText());
  }
  return JSON.parse(res.getContentText()).choices[0].message.content;
}

コード量はGASの方が多いですが、失敗時の挙動を1行で明示できる（ステータスコードのチェック・エラー投げ）のがGASの利点です。n8nでも「Continue On Fail」やエラーワークフローで同等のことができますが、失敗時の分岐がワークフロー上に散らばりがちです。

APIキーの管理も差がはっきりします。n8nはCredentials管理が組み込みで安全。GASはPropertiesService（スクリプトプロパティ）に入れるのが基本で、これも仕組みとしては十分ですが、設定は自前です。

実装比較：定期実行

n8n：Schedule Triggerノードを置いて「毎日 9時」等を選ぶだけ。タイムゾーンはワークフロー設定で指定します。

GAS：トリガーはコードで作成します。

function createDailyTrigger() {
  // 重複登録防止のため同名トリガーを先に消す
  ScriptApp.getProjectTriggers()
    .filter(t => t.getHandlerFunction() === 'dailyAiBatch')
    .forEach(t => ScriptApp.deleteTrigger(t));

  ScriptApp.newTrigger('dailyAiBatch')
    .timeBased()
    .atHour(9)
    .everyDays(1)
    .create();
}

注意点として、GASの時限トリガーはatHour(9)でも9時前後の数分のずれが出ます。また、1スクリプトあたりのトリガー総実行時間に上限（1日90分）があるため、AI APIを大量に叩くバッチをGASだけで回すのは非現実的です。大量データのバッチはn8n（セルフホスト）側に寄せ、GASはGoogleサービスの窓口にするのが堅実な分割です。

実務での使い分けパターン

私の実感として、次の3パターンに落ちます。

パターンA：Googleサービス内で完結 → GAS一択
例：スプレッドシートの新規行をAIで要約して隣列に書き戻す。onEditイベントトリガーで動かせるので、外部ツールは不要。

パターンB：複数SaaS + Googleが少しだけ → n8n中心、GASはWebhook受付
例：GitHub Issue作成 → n8nでAI要約 → Slack通知、最終結果だけスプレッドシートに追記。n8nのHTTP RequestノードからGASのWebアプリ（doPost）を叩けば、Google側の認証をGASに一任できます。

パターンC：大量データの定期バッチ → n8n（セルフホスト）
例：数万行のログを毎晩取得→AI分類→DBへ。GASの実行時間上限を回避するため、n8nのSchedule Trigger + ループで処理します。

パターンBの「n8nからGASのWebアプリを呼ぶ」構成は意外と使えます。GASのdoPost(e)をWebアプリとしてデプロイすれば、n8n側は認証なしのURLにPOSTするだけでGoogleサービスを操作できます（実運用ではURLの秘密性を確保するため、パラメータにトークンを持たせて検証します）。

まとめ

状況	推奨
スプレッドシート・Gmail・カレンダー中心	GAS
複数SaaSの連携ハブ	n8n
複雑な分岐・文字列正規化	ロジックは1関数に書ける側（GAS or Codeノード）
大量バッチ・長時間処理	n8n（セルフホスト）
AI APIキーの管理	n8nはCredentials、GASはスクリプトプロパティ

「ノーコード vs コード」を抽象的に議論しても答えは出ません。データがどこにあり、ロジックがどれだけ複雑で、どれだけ頻繁に変わるかで決めるのが実践的です。私は「n8nを連携ハブに、GASをGoogle窓口に」という分割がもっともトラブルが少ないと感じています。

読者特典（無料）

本記事のような実装パターンを横断的にまとめたチートシートと、Obsidian・Notionのテンプレート集を無料配布しています。8冊の内容から「何をどのツールでやるか」の判断チャートも含みます。

🎁 読者特典を受け取る（無料・メール登録）

📗 n8n × AI自動化実践入門 — ノーコードで作るAIワークフロー（Kindle・Kindle Unlimited読み放題対象）

著者: 葉山悠希 — 書籍シリーズは Zenn / Amazon で公開中