n8nとGoogle Sheetsを連携してデータ処理を自動化する方法

n8nとGoogle Sheetsを連携するときは、シートを単なる表ではなく、workflowが読み書きするデータ契約として設計します。まず「どの行を処理対象にするか」「1件をどう識別するか」「どの状態なら完了と見なすか」を決めてください。基本形は、対象行を限定して読む → 必要ならAI処理 → 既存行を更新または新しい行を追加 → 最後に処理状態を記録、です。

この記事では、問い合わせを1行ずつ要約して結果列へ保存する例を使います。n8nのGoogle Sheets nodeには行の取得、追加、更新、Append or Update Rowなどがあり、どの操作を使うかはデータのkeyと再実行方針で決まります。画面上の操作を実演した記事ではなく、公式node仕様に基づく設計例です。

先に決めるシート構造

入力と出力を同じ表に置くなら、列を「人が入力する列」「自動化が書く列」「管理用列」に分けます。

表は横にスクロールできます

列	所有者	例	ルール
request_id	受付側	R-2026-001	空欄不可、重複不可
received_at	受付側	2026-10-08T09:30+09:00	日付形式を統一
subject / body	受付側	件名・本文	入力者が編集できる
status	workflow	pending / processing / done / error	許可値を限定
summary	workflow	要約	元の本文を上書きしない
category	workflow	billing / bug / other	固定選択肢
processed_at	workflow	ISO日時	成功後に記録
error_code	workflow	EMPTY_INPUTなど	secretや本文全文を入れない

header名は作成後に頻繁に変えないでください。ノードが列名や列順を前提にmappingしていると、列削除や名称変更で出力先がずれることがあります。人の入力と自動化出力を同じ列に混ぜると、エラー時にどちらの値が正しいか分からなくなるため、別列に分離します。

対象行を絞る：全行再処理を避ける

最初に毎回シート全体を読み、そのすべてへAIを呼ぶ設計だと、処理時間とAPI費用が増えるだけでなく、完了済みrecordを再度上書きする可能性があります。対象条件は例えばstatus = pending、本文が空でない、request_idが存在する、のように定めます。

一度に読む件数が多いときは、n8n nodeの取得件数やpagination、Google Sheets側の制限とworkflow実行時間を確認します。必要な範囲を区切り、対象件数が上限を超えたら停止または次batchへ回す設計にします。pendingだけで十分か、前回の途中失敗によりprocessingのまま残った行をどう回収するかも決めます。時間経過後のprocessingを自動でpendingへ戻す場合は、同じ行が並行実行されない仕組みが必要です。

一意keyで更新先を特定する

行番号は並べ替えや行挿入で変わるため、業務上の識別子として使うのは不安定です。request_idなど一意性を確認できるfieldを決め、次の条件を満たすか検査します。

• 空欄でない

• シート内で重複していない

• 再実行時も同じrecordを指す

• 個人情報を含まない

• 列名変更の影響を受けにくい

同じIDが複数行にあるなら、AI処理を始める前にエラー扱いにして担当者へ知らせます。最初に見つかった行へ更新する、といった暗黙の動きは誤上書きする恐れがあります。追加・更新の操作でkeyを指定できるか、利用中のn8n nodeの現行仕様を確認します。

推奨する処理の状態遷移

表は横にスクロールできます

状態	条件	次にすること
pending	必須項目がそろい、未処理	1件を取得して処理開始
processing	実行中、または占有中	重複実行を防ぐ
done	出力検査と保存が成功	次回対象から除外
review	AI出力が曖昧、形式不正	自動確定せず人が確認
error	外部API、Sheets書込みなどが失敗	error_codeとIDを記録し調査

処理順序の要点は「AIを呼ぶ前に処理中を記録し、成功後にdoneへ変える」ことです。ただし複数workflow実行が同時に同じpending行を読む場合、Sheetsの読み取りと更新だけで排他制御が保証されるとは限りません。並列実行を許すか、処理を直列化するか、別のqueue / databaseを使うかを件数と重要度で判断してください。Sheetsは小規模な受付・試作には扱いやすい一方、厳密な同時更新や高頻度処理を前提にしたDBと同じ制御を期待しないでください。

読み取りからAI処理まで

1. **Get Row(s)**等で対象行を取得し、statusと必須値を確認する。

2. Edit Fields等で必要fieldだけを次へ渡す。

3. 空欄、長文、重複ID、対象外カテゴリはAIへ渡さず分岐する。

4. AIにはrequest_idを識別子として添え、要約・分類の出力形式と許可値を指定する。

5. 出力を検証し、本文に根拠のない推測や顧客への約束があればreviewへ回す。

たとえば本文「ログインできず、請求は継続しているように見える。昨日から発生。」なら、出力を「summary: ログイン不可。請求状況の確認が必要」「category: account」「evidence: 本文にログイン不可・請求継続の記述」「needs_review: true」のように、文章と根拠に分けて保存できます。例はschemaの説明であり、特定modelの動作保証ではありません。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  n8n

  公式サイトを見るTool詳細を見る

AppendとUpdateを混同しない

表は横にスクロールできます

操作	向いている場面	再実行時の注意
Append Row	1 eventごとに履歴を積み上げる	同じ実行を再送すると重複行ができる
Update Row	既存recordの結果列を更新する	対象行を一意に特定する必要
Append or Update Row	keyが見つかれば更新、なければ追加	検索keyが一意でない場合に誤更新の危険

履歴tableならappendが自然でも、現在状態を保持する表へappendすると「最新結果がどれか」を別途判断しなければなりません。現在値を更新する表でappendすると、再実行のたびに行が増えます。行が追加された場合は元IDとの関係を残し、監査可能な履歴が必要なら別sheetを使います。

途中失敗と再実行

AI生成後にSheets更新が失敗したとき、再実行で同じAPI呼び出しを行うと費用が二重になることがあります。可能なら入力snapshotと処理IDを保存し、同じrequest_idがdoneになっていないか確認してから再試行します。API timeoutは「処理が実行されていない」とは限らないので、曖昧な結果をすぐ再送せず、実行履歴と出力先を照合します。

error_codeは原因を示す短い分類にして、エラー全文や顧客本文をそのまま共有表へ記録しないようにします。再試行可能な通信errorと、入力不正・権限不足・列変更のような修正が必要なerrorを分けます。失敗行を自動でpendingへ戻すなら、再試行回数と最終失敗通知も設定します。

権限とデータ品質のQA

• workflow専用のGoogle接続を使い、必要な共有範囲を確認する

• 共有sheetの編集権限が広すぎないか確認する

• AIへ渡す列を明示し、内部メモ等を誤送信しない

• request_id重複、空欄、長文、文字化け、改行をtestする

• 列追加・列名変更後のmappingをtestする

• API成功後のsheet書込み失敗を想定する

• 2件を同時投入したときの二重処理を確認する

• 完了済み行が次回実行で対象に戻らないことを確かめる

AIものさしの判断

n8nとSheetsの連携で大切なのは、AIの回答を保存することより、どの行を処理し、どの行を一度だけ処理したかを追えることです。まず少数の架空データでstatus遷移と再実行を検証し、処理中行が残る、重複IDがある、保存先が停止した場合に人が復旧できるかを見ます。並行実行や件数が増え、Sheetsの行検索・更新がボトルネックになったら、入力受付は維持しつつ、queueやtransactionが使える保存先へ移すタイミングを検討します。

2行だけのテストデータで確認する

本番シートへ接続する前に、列構造を同じにしたテスト用sheetへ架空の2行を用意します。1行はpendingで正常入力、もう1行は本文空欄または重複request_idにします。実行後、正常行だけがAI処理・保存され、対象外の行は明確なerrorまたはreview状態になったかを照合します。

表は横にスクロールできます

request_id	status	body	期待する結果
DEMO-001	pending	「ログインできない。再設定も失敗」	要約案とcategoryを記録し、検証後done
DEMO-002	pending	空欄	AI nodeへ進まず、EMPTY_INPUTとして人へ通知
DEMO-003	done	既に処理済み	次回実行では再処理しない

実行前後の値を比較し、元のbodyやrequest_idが意図せず置き換わっていないか見ます。出力列の値が更新されても、workflowが完了した証拠としてstatusとprocessed_atが同じ成功条件で更新されている必要があります。別々のノードで順番に書き込む場合、途中で失敗したときにsummaryだけ残る状態を想定し、復旧時にどの列を再計算するか決めておきます。

最初の試験でデータ行を増やしすぎず、リプレイのたびに同じ結果が同じ行へ反映されることを確かめてから実データへ接続します。並べ替えを挟んでもrequest_idで同じ行を更新できること、header追加後に古いmappingがずれていないことも確認してください。