この記事で分かること
- 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読み放題対象）