【n8n】Google Sheets invalid_grantエラーの原因はOAuth2の7日制限だった

「昨日まで動いていたのに、今日になってn8nのGoogle Sheetsノードが急にinvalid_grantエラーで止まってしまった」——そんな状況に戸惑っていませんか？変更した覚えがないのに突然止まるこの現象には、実は明確な理由があり、正しい手順を踏めば数分で解決できます。

そこで今回は、n8nのGoogle Sheets連携環境で「invalid_grant」エラーの原因究明から解決までを行ってみました！仕組みさえ理解すれば再発防止も簡単ですので、ぜひ皆さんも記事を読んで試してみてください！

この記事で分かること

invalid_grantエラーが起きる仕組みとOAuth2のTesting/Productionモードの違い
Testingモードのトークン期限切れとシステムクロックのズレ、2つの原因の切り分け方
OAuth同意画面の切り替え、サービスアカウント移行、API有効化確認という3つの解決方法

invalid_grantエラーが起きる仕組み

n8nでGoogle Sheetsノードを使う際は、Google Cloud ConsoleでOAuth 2.0クライアントIDを発行し、認証を行います。この認証情報の公開ステータスが「テスト」になっていると、発行されるリフレッシュトークンはわずか7日間で失効する仕様です。テストユーザーとして自分のGoogleアカウントを登録していても、この7日間ルールは変わりません。

7日を過ぎると、n8nがリフレッシュトークンを使って新しいアクセストークンを取得しようとした瞬間に「invalid_grant」エラーが発生し、ノードが動かなくなります。一方、公開ステータスを「本番環境」に切り替えると、この7日間の制限がなくなり、リフレッシュトークンは長期間有効なままになります。

つまり、数日前まで動いていたワークフローが突然止まる最大の原因は、テストモードのまま運用していたことにあります。

原因を切り分ける2つのケース

invalid_grantエラーの原因は、大きく分けて2パターンに分類できます。まずは自分のケースがどちらに当てはまるかを確認しましょう。

Testingモードのトークン期限切れが原因のケース

最も多いのが、OAuth同意画面の公開ステータスが「テスト」のまま運用していたケースです。この場合、認証情報を発行してからちょうど7日前後で必ずエラーが再現します。確認手順は次の通りです。

Google Cloud Consoleの左側メニューから「APIとサービス」→「OAuth同意画面」を開く
画面上部の「公開ステータス」欄が「テスト」になっているか確認する
n8nでGoogle Sheets認証情報を作成（または最後に認証）した日付をメモする
エラーが発生した日付との差が7日前後であれば、このケースに該当すると判断する

システムクロックのズレ・リダイレクトURI不一致が原因のケース

7日以内にもかかわらずエラーが出る場合は、別の原因を疑う必要があります。それぞれ次の方法で確認できます。

n8nをホストしているサーバーにSSHでログインし、下記コマンドで現在時刻を確認する

# サーバーの現在時刻を確認
date
# 実際の時刻とのズレがないか目視で比較する（数分でもズレていれば要修正）

Google Cloud Consoleの「APIとサービス」→「認証情報」を開き、対象のOAuthクライアントIDをクリックする
「承認済みのリダイレクトURI」欄に登録されているURIと、n8nのGoogle Sheets認証情報画面に表示されている「OAuth Redirect URL」が完全一致しているか確認する
エラーメッセージに「redirect_uri_mismatch」という文言が含まれていないかもあわせて確認する

解決する3つの方法

Google Cloud ConsoleでOAuth同意画面をProductionに切り替える手順

テストモードが原因だった場合は、公開ステータスを本番環境に切り替えるのが最も簡単な解決方法です。以下の手順で実施してください。

Google Cloud Consoleにログインし、「APIとサービス」→「OAuth同意画面」を開く
画面上部の「公開ステータス」欄にある「アプリを公開」ボタンをクリックする
確認ダイアログが表示されるので「確認」を選択する
公開ステータスが「本番環境」に変わったことを確認する（個人利用や社内利用のみであればGoogleの審査は不要な場合がほとんど）
n8n側で該当のGoogle Sheets認証情報を一度削除する
Google Sheetsノードの認証情報欄から「Create New Credential」を選び、再度OAuth認証をやり直す
Googleアカウントの選択画面が表示されたら再認証を完了させ、新しいリフレッシュトークンが発行されたことを確認する

サービスアカウントを使った恒久的な認証方法への切り替え手順

より確実に長期運用したい場合は、サービスアカウントへの切り替えがおすすめです。手順は以下の通りです。

Google Cloud Consoleの「IAMと管理」→「サービスアカウント」を開く
「サービスアカウントを作成」をクリックし、名前（例：n8n-sheets-bot）を入力する
ロールの選択画面はスキップし、「完了」をクリックする
作成したサービスアカウントをクリックし、「鍵」タブを開く
「鍵を追加」→「新しい鍵を作成」→「JSON」を選択してダウンロードする

{
  "type": "service_account",
  "project_id": "your-project-id",
  "private_key_id": "xxxxxxxx",
  "private_key": "-----BEGIN PRIVATE KEY-----\n...\n-----END PRIVATE KEY-----\n",
  "client_email": "[email protected]"
}

対象のGoogleスプレッドシートを開き、右上の「共有」ボタンをクリックする
JSON内の「client_email」に記載されたメールアドレスを入力し、権限を「編集者」に設定して共有する
n8nの認証情報作成画面で「Google Service Account」を選択する
ダウンロードしたJSONファイルの中身をそのまま「Service Account Email」と「Private Key」の各欄に貼り付ける（もしくはJSONファイルをアップロードする）
「Save」をクリックして接続テストを実行し、正常に接続できることを確認する

Sheets APIが有効化されているか確認する手順

意外と見落としがちなのが、Google Sheets APIそのものが無効化されているケースです。以下の手順で確認・有効化してください。

Google Cloud Consoleの「APIとサービス」→「有効なAPIとサービス」を開く
一覧に「Google Sheets API」が表示されているか確認する
表示されていない場合は、左上の「+ APIとサービスを有効にする」をクリックする
検索窓に「Google Sheets API」と入力し、該当のAPIを選択する
「有効にする」ボタンをクリックする
画面上部のプロジェクト名が、n8nの認証情報に紐づいているプロジェクトと同一であることを必ず確認する（プロジェクトを複数作成している場合、ここでズレが起きやすい）

今後トークン切れを防ぐ運用のコツ

一度解決しても、設定を戻さなければ同じトラブルが再発します。認証情報を作成したら、最初の段階でOAuth同意画面を本番環境に切り替えておくことが最も確実な予防策です。長期的に安定運用したいワークフローには、最初からサービスアカウント方式を採用しておくと、トークン管理そのものが不要になります。加えて、n8nを稼働させているサーバーの時刻同期をNTPで自動化しておくと、クロックのズレによる認証エラーも未然に防げます。

# Ubuntu/Debian系サーバーでのNTP時刻同期設定例
sudo timedatectl set-ntp true
timedatectl status

よくある質問

Q1. invalid_grantエラーはどれくらいの頻度で発生しますか。

テストモードのままだと、認証してから7日ごとに必ず発生します。本番環境に切り替えれば基本的に再発しません。

Q2. サービスアカウントとOAuth認証はどちらを選ぶべきですか。

自動化ワークフローで長期運用する場合は、期限切れのないサービスアカウントが適しています。個人アカウントでの操作履歴を残したい場合はOAuth認証が向いています。

Q3. 公開ステータスを本番環境にすると、Googleの審査が必要になりますか。

利用するスコープが限定的で、外部公開しない個人・社内利用であれば、審査なしで公開ステータスを変更できる場合が多いです。

Q4. サービスアカウントに切り替えても、スプレッドシートが見つからないと表示されます。なぜですか。

サービスアカウントのメールアドレスを、対象スプレッドシートの共有設定に編集者として追加していないことが原因です。共有設定を確認してください。

参考リンク