Googleへ接続できないときは、エラーが出た場面と、n8nの接続方式を先に確認します。毎回つなぎ直す前に、初回から失敗するのか、数日後に切れるのかを分けると、直す場所を絞れます。
いまの症状から、最初の確認を選ぶ
| 症状 | 最初に見る場所 | まだ決めつけないこと |
|---|---|---|
| 認証画面でredirect_uri_mismatch | n8nのOAuth Redirect URLとGoogle側の登録 | パスワードの誤りとは限らない |
| 数日後、特に7日ほどで切れる | 自作アプリのExternal・Testing・scope | すべてのGoogle接続が7日で切れるわけではない |
| 特定の操作だけ拒否される | その操作のscope、API、対象ファイルの共有 | 再認証だけで権限が増えるとは限らない |
| invalid_grantが出る | 失効、アクセス取消、管理者制限等の履歴 | エラー名だけで7日期限を原因にしない |
まず一行だけ選び、確認した設定と結果を残してください。複数の設定を一度に変えると、どの変更が効いたのか分からなくなります。
Cloudの管理済み接続と、自作OAuthを分ける
n8n Cloudでは、対応するGoogleノードにManaged OAuth2が用意されています。この方式なら、自分のClient IDを作る操作は不要です。セルフホストや独自の接続設定では、Google側のOAuthアプリを準備する方法を使います。詳しい対応はn8nのGoogle接続資料で確認できます。
ノードの資格情報画面を開き、どちらの方式を使っているかを確かめます。自作アプリの説明を、管理済み接続へそのまま当てはめないようにしてください。
7日で切れる場合は、三つの条件を照合する
Googleの公式仕様では、ユーザー種別がExternal、公開状態がTestingのアプリが発行するrefresh tokenは、原則7日で期限を迎えます。ただし、要求するscopeが名前・メール・プロフィール等の基本情報だけの場合には例外があります。GmailやDriveを扱う接続では、実際に要求したscopeも確認してください。
この条件と例外はGoogleのOAuth仕様に記載されています。公開状態を変える場合は、必要な検証や組織の条件も確認します。設定を変えたあとに認証し直す必要があるかを、使用している資格情報で照合してください。
再接続できた当日だけでは、7日後も続く確認にはなりません。認証日と、次に動作を確かめる日を残します。この記事では7日をまたぐGoogle接続の経過試験は行っていません。
Redirect URLは、実際の画面からコピーする
自作OAuthなら、n8nの資格情報画面に表示されるOAuth Redirect URLをGoogle側の承認済みリダイレクトURIへ登録します。https、ホスト、ポート、パス、末尾の違いを一つずつ比べます。URLを記憶で組み立てず、実際の画面を基準にしてください。
リバースプロキシや公開URLを変えた場合は、n8nが表示するURLも確認します。画面で案内される値が、利用者から見える接続先と違うなら、Google側だけを直し続けずn8nの外部URL設定も調べます。
再認証の前に、秘密値を除いた記録を残す
記録するのは、n8nの版、接続方式、エラーが出た操作、エラー名、公開状態、scope、変更した日時です。Client Secret、token、Application Passwordなどの秘密値は比較票や共有ログへ入れません。
Google接続の確認記録
入力内容は送信されません。残したい記録はCSVで保存してください。
条件を入力すると、ここに結果が出ます。
直した後は、必要な操作を一つ試す
専用の試験シートやフォルダで、読み取りと必要な書き込みを分けて確認します。接続テストが通ることと、対象ファイルの更新が許可されることは別です。Gmailの分類なら、まず合成メールで分類結果を見るところから進めます。
次はGmailの分類とラベル付けへ。認証は通るのにworkflowが止まる場合は、実行の失敗を切り分ける手順を確認してください。