ZapierでGoogle Sheetsを自動化する方法

ZapierでGoogle Sheetsを自動化するときは、Sheetを「人が自由に編集する表」として扱うより、automationが読み書きしやすいデータ tableとして整えてから接続するのが基本です。

現在のZapier Google Sheets integrationには、New Spreadsheet Row、New or Updated Spreadsheet Rowなどのトリガーと、Create Multiple Spreadsheet Rows、Update Spreadsheet Row、Lookup Spreadsheet Rowsなどのアクションがあります。

先に結論：Google Sheetsは「表」ではなく自動化のインターフェースとして整える

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

設計項目	例	自動化での意味
1行の単位	1顧客 / 1注文	Recordを固定する
Header	email / status / created_at	Mappingの契約になる
Key	order_id等	Update対象を特定する
Processed	true / false	再処理を防ぐ

Zapierへつなぐ前にSheet構造を安定させると、Trigger・Lookup・Updateの手戻りが減ります。

最小構成を作る

まず1行の意味を決める

1行=1顧客、1問い合わせ、1注文など、rowの単位を固定します。途中に説明行や空の見出しを大量に入れるとautomationで扱いにくくなります。

Headerを固定する

氏名、メール、ステータス、created_atなど、column名を決めます。Zapierで項目 mappingしたあとにheaderを頻繁に変更しない運用にします。

Google SheetsをZapierへ接続する

Google アカウントを接続し、対象spreadsheetとworksheetを選びます。Shared Driveを使う場合は対応するトリガー / アクションを確認します。

Triggerを選ぶ

新しいrowを起点にするならNew Spreadsheet Row、既存rowの変更も拾うならNew or Updated Spreadsheet Rowなど、業務eventに合うトリガーを選びます。

本番運用へつなぐ

Sample rowでmappingする

実際に近いsample rowを用意し、各columnがZapier側で正しく読めるか確認します。日付、空欄、数値、URLなど型が異なる値も見ます。

Actionでrowを追加・更新する

他appからSheetへ記録するならrow create、既存レコードを更新するならUpdate Spreadsheet Row、既存rowを探すならLookup系アクションを使います。

無限loopを防ぐ

Sheetの更新をトリガーにし、同じZapがそのrowを再更新するとloopや重複処理につながります。ステータス columnやprocessed flag、トリガー条件で再処理を防ぎます。

Sheet変更時はZapを再確認する

column追加・名称変更、worksheet差し替えなどをしたらmappingを再確認します。Google Sheetsをautomationの一部にする場合、表構造そのものがinterfaceになります。

AIものさしの判断

ZapierとGoogle Sheetsの連携は、「表へ自動入力する」だけでなく、SheetをSaaS間の軽量なデータ hubとして使うワークフローです。

row design→header→connection→トリガー→mapping→アクション→loop prevention→monitorの順にすると、後から壊れにくいautomationへ近づきます。

AIものさしでは、rowが1件追加されたことではなく、Sheet構造とZapのmappingが対応し、継続的に追加・更新・参照できる状態をこのワークフローの完了条件にします。

実運用へ進む前に、列とTriggerの契約を決める

Zapierは選んだSpreadsheetとWorksheetを監視します。Trigger設定では対象表を選び、必要なら特定のTrigger Columnの変更だけを対象にできます。「New Spreadsheet Row」は新規行を起点にする用途、「New or Updated Spreadsheet Row」は新規作成と既存行変更の両方を起点にする用途です。更新イベントを含めると、後段のZapがSheetを書き戻した際に同じ処理を再度起動する可能性があります。更新列を絞るか、statusをreadyからprocessedへ進める等の状態設計を入れます。

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

設計項目	推奨する決め方	壊れやすい例
1行の単位	問い合わせ1件、注文1件など	1行に複数顧客を詰める
一意キー	外部IDや注文番号	氏名だけで照合する
必須列	固定した列名とデータ型	見た目の都合で毎週headerを変更
再処理状態	未処理・処理中・完了・要確認	Zapが同じ行を再更新してloop
エラー情報	error_code、last_attempt_at	失敗行を削除して原因を失う

読み取り・作成・更新を混同しない

ZapierのGoogle Sheets連携では、行を起点にするTriggerと、別Appから値を書き込むActionは別の段階です。新規記録なら行作成Action、既存レコードを書き換えるなら一意キーで対象を特定してから更新、既存行を探すならLookup系Actionを選びます。複数行の作成やAdvanced系の処理もありますが、実際に選べる名称・必須fieldはZap editor上で確認してください。Action名だけを見て更新対象が一意になるとは限らないため、重複キーが見つかった場合の扱い（停止、先頭のみ、手動確認）も決めます。

サンプル行でmappingを検証する

本番データを流す前に、テスト用Worksheetまたは明示的なテスト行で次の入力を通します。

1. 通常値：文字列、日付、数値を各1件

2. 空欄：任意列を空にしたレコード

3. 文字列境界：カンマ、改行、長いURL、先頭ゼロを含むID

4. 重複：同じ一意キーを2回送った場合

5. 更新：既存行の対象列だけを変更

6. 再実行：Zapの再試行で二重登録されないか

7. 権限：接続ユーザーが対象Sheetを読み取れるか、書き込みActionに必要な編集権限を持つか

テスト後は、Trigger sampleに期待した列が含まれること、更新先rowが狙った一件であること、日付や先頭ゼロが崩れていないことを確認します。列の追加・名前変更をした場合はZapのfield mappingを更新して再テストします。Google Sheetsへの接続や読み書きには、接続するGoogleアカウントの権限と組織の外部アプリ許可も関係します。

停止条件と復旧

行がTriggerされない場合は、対象Worksheet、行が末尾へ追加されたか、Trigger Column、共有権限、Zapが公開状態かを順番に確認します。二重処理が起きたらZapを一時停止し、実行履歴から同じキーが何回処理されたかを確認してから、状態列または一意キー判定を修正します。成功した行を手作業で再送する前に、すでに出力先へ作成済みでないか照合してください。

更新確認日と根拠

2026-10-10時点でZapierのGoogle Sheets Trigger設定と現行連携の説明を確認しました。Trigger/Action名や利用可能条件は変更されることがあるため、実装時はZap editorの説明を優先します。

Zapier：Google Sheets integrations（新しいタブで開く）

Zapier：Set up your Zap trigger（新しいタブで開く）

Zapier：Getting started with Google Sheets（新しいタブで開く）

Zapier：Find and update rows in Google Sheets（新しいタブで開く）

重複行と表の変更に備える

一意キーを持たない運用では、Zapの再試行や同じフォームの再送で同じ内容の行が増えても気づけません。外部IDがない場合は、受付時点で生成したIDを列へ保存し、次回実行でそのIDをLookupして存在を確認します。メールアドレスなど変更・共有される値を唯一キーにする場合は、同じ値が複数件になる条件も決めてください。

SheetをZapier用のdata contractとして使うなら、見た目の装飾より表構造を優先します。headerは1行、データはその下へ揃え、途中に結合セル・説明行・小計行を挟まない設計が扱いやすくなります。計算列を使う場合は、Zapierが読み取る時点で値が反映されることをテストし、空の計算結果を処理済みと誤認しないようにします。