Googleの自動連携が1週間ほどで止まるとき｜OAuth同意画面が「テスト」のままだと更新トークンが短期間で失効する仕組みと、本番公開へ切り替える前に確かめる項目
Googleの自動連携が1週間ほどで止まるとき｜OAuth同意画面が「テスト」のままだと更新トークンが短期間で失効する仕組みと、本番公開へ切り替える前に確かめる項目
Google広告の数字を毎朝自動で集計する、Googleアナリティクスのデータをスプレッドシートに取り込む、Googleビジネスプロフィールへ自動で投稿する。こうした仕組みが、作った直後は動いていたのに1週間ほどで急に止まり、認証し直すとまた1週間で止まるなら、まず疑うべき場所は1つです。
結論から書きます。Google Cloudの「OAuth同意画面」の公開ステータスが「テスト」のままになっていると、更新トークン（リフレッシュトークン）は7日で失効します。 これはGoogleの公式ドキュメントに書かれている仕様で、プログラムの不具合ではありません。恒久的に直すには、公開ステータスを「本番環境」に切り替えたうえで、切り替え後にもう一度同意し直して新しいトークンを取る必要があります。
確かめる順番は次のとおりです。
- エラーの本文に
invalid_grantが含まれているかを見る（「Bad Request」だけで判断しない） - 最後に認証した日と、最後に成功した日の差を数える。7日前後なら公開ステータスが最有力
- Google Cloudコンソールで、そのOAuthクライアントの同意画面が「テスト」か「本番環境」かを確認する
- 本番環境へ切り替える前に、ユーザーの種類・使っている権限の範囲・未確認アプリの警告を確認する
- 切り替え後に同意し直し、同じトークンを使っているファイルをすべて更新する
この記事では、広告データの日次集計が7日周期で止まっていた実例をもとに、見分け方と切り替えの判断基準を整理します。Googleの仕様は2026年9月23日時点の公式ドキュメント（Google Identity「Using OAuth 2.0 to Access Google APIs」、Google Cloudヘルプ「Unverified apps」）で確認した内容です。
なぜ「テスト」だと7日で止まるのか
自動連携の仕組みは、最初に一度だけ人がGoogleアカウントで「このアプリにアクセスを許可する」を押し、そのときに受け取った更新トークンを保存しておきます。以後は毎回、この更新トークンを使って短時間だけ有効な鍵（アクセストークン）をもらい直し、人の操作なしでAPIを呼び出します。
Googleの公式ドキュメントには、更新トークンについて次の趣旨の記載があります。
ユーザーの種類が「外部」で、公開ステータスが「テスト」になっているOAuth同意画面のプロジェクトには、7日で失効する更新トークンが発行される。ただし、要求する権限が名前・メールアドレス・プロフィールの範囲だけなら対象外。
広告やアナリティクス、ビジネスプロフィールのAPIは、プロフィール以外の権限を使います。つまり、開発中の「テスト」状態のまま運用に入ると、仕組みそのものは正しく作れていても、7日目に必ず止まることになります。
厄介なのは、作った直後の動作確認ではこの問題が見えないことです。初日も3日目も正常に動くので、完成したと判断して運用に入り、1週間後に初めて止まります。そして再認証すると直るため、「一時的な不調だった」と片付けられやすいのです。
実例：再認証するたびに、ちょうど7日で止まっていた
ある店舗ビジネスの広告運用で、Google広告のAPIから毎朝データを取り、複数アカウントの費用やクリックをまとめて確認する仕組みを動かしていました。この仕組みの取得記録を並べると、次のようになっていました。
| 再認証した日 | 最後に取得できた日 | 間隔 |
|---|---|---|
| 8月9日 | 8月16日 | 7日 |
| 8月29日 | 9月5日 | 7日 |
| 9月20日 | （9月27日ごろに止まる見込み） | ー |
2回続けて、再認証からちょうど7日で取得が止まっていたことになります。9月6日以降の日次ジョブはすべてHTTP 400で失敗しており、エラー本文を確認すると invalid_grant: Token has been expired or revoked.（トークンが期限切れ、または取り消されている）でした。
一方、同じ事業者のGoogleビジネスプロフィールへ投稿する仕組みは、別のGoogle Cloudプロジェクトで作り、運用開始前に同意画面を「本番環境」に切り替えていました。こちらでは7日周期の停止は起きていません。同じ会社・同じGoogleアカウントでも、プロジェクトごとの公開ステータスで結果が分かれるという対比になっています。
この例から分かる判断のポイントは3つです。
- 間隔が毎回7日前後そろっているなら、偶然ではなく仕様による失効を疑う
- 再認証で直るのは対症療法で、放っておけば次の7日目にまた止まる
- 取得できなかった期間の数字は、後から取り直さない限り空白のまま残る。止まったことに気づかず古い数字を見続けるのが一番の損失
手順1：エラーは本文まで見て invalid_grant を確かめる
最初に確かめるのは、止まった原因が本当に認証なのかどうかです。
Google広告のAPIでは、認証トークンが失効していても、画面やログには「HTTP 400」「Bad Request」とだけ出ることがあります。400は本来「送った内容がおかしい」という意味なので、取得条件（どの期間・どの項目を取るか）の書き方を疑ってしまいがちです。
しかし実際には、データを問い合わせる前の「トークンをもらい直す段階」で失敗していることがあります。この場合、エラーの本文に invalid_grant という語が入っています。
- 本文に
invalid_grantがある → 更新トークンが使えなくなっている。取得条件を直しても解決しない - 本文に別の理由がある → 権限不足、取得条件の誤り、利用枠の上限などを個別に調べる
自動処理を作るときは、エラーの種類だけでなく本文も記録に残す設定にしておくと、この切り分けが数秒で終わります。
手順2：最後の認証日と最後の成功日の差を数える
次に、いつ認証して、いつまで動いていたかを並べます。
- 差が7日前後 → 公開ステータスが「テスト」の可能性が高い
- 差がばらばら、または数か月 → 別の原因（後述）を疑う
最後に成功した日時が分からない場合は、仕組みの側で記録を残すところから始めます。「最後に成功した時刻」を毎回画面やレポートに表示しておくと、止まった瞬間に気づけます。監視の考え方は自動処理の監視は「最後に成功した時刻」を見るで詳しく書いています。
手順3：同意画面の公開ステータスを確認する
Google Cloudコンソールで、自動連携に使っているプロジェクトを開き、OAuth同意画面（現在の画面では「Google Auth Platform」の「対象」などの項目）を確認します。ここに「公開ステータス：テスト」と表示されていれば、7日失効の条件に当てはまります。
確認するときの注意点は、プロジェクトを取り違えないことです。長く運用していると、試作用・本番用・別案件用とプロジェクトが増えます。見るべきなのは、今動いている仕組みの設定ファイルに書かれているクライアントIDが属しているプロジェクトです。クライアントIDの先頭の数字（プロジェクト番号）で照合すると確実です。
手順4：本番環境へ切り替える前に確かめる項目
「本番環境へ公開」ボタンを押す前に、次の4点を確かめます。
| 確認項目 | 見るポイント |
|---|---|
| ユーザーの種類 | 「外部」か「内部」か。Google Workspaceを使っていて、利用者が全員同じ組織なら「内部」にでき、7日失効の対象外になる |
| 要求している権限 | 名前・メール・プロフィールだけなら元から対象外。広告・アナリティクス・ビジネスプロフィールなどを使うなら対象 |
| 未確認アプリの警告 | 審査を受けていないアプリを本番環境にすると、同意の前に「確認されていないアプリ」の警告画面が出る。新規ユーザーは100人までに制限される |
| 使う人の範囲 | 自社のアカウントだけで使う社内向けの仕組みか、顧客にも同意してもらう仕組みか |
Google Cloudのヘルプでは、試作や社内の開発用のアプリは、一般に公開しない限り審査は必須ではないとされています。自社のGoogleアカウントだけで使う集計の仕組みなら、警告画面を確認したうえで自分で先へ進めて同意する、という運用が現実的です。
反対に、顧客にも自社のアプリで同意してもらう仕組み（顧客のアカウントのデータを預かる形）を作るなら、警告画面が出たままでは信用を損ねますし、100人の上限にもかかります。この場合は審査の準備を含めて計画し直すべきで、単にボタンを押して済ませる話ではありません。
手順5：切り替えたら同意し直し、トークンの保存先を全部更新する
公開ステータスを「本番環境」に切り替えたら、もう一度同意の手続きを行い、新しい更新トークンを取り直します。テスト中に発行されたトークンは、期限付きのものとして扱われる前提で考えたほうが安全です。切り替えただけで安心せず、新しいトークンで8日目以降も動くことを確かめて完了とします。
ここで起こりやすいのが、同じトークンを複数の場所に保存していて、一部だけ古いまま残ることです。先の実例でも、広告用の設定ファイル2つと、アナリティクス用の設定ファイル1つの計3か所に、同じOAuthクライアントのトークンが保存されていました。1か所だけ更新すると、残りの仕組みが止まったままになります。
- 同じクライアントIDを使っている設定ファイルを検索して、保存先を一覧にしておく
- 再認証の手順を1本の処理にまとめ、一度の同意で全ファイルに書き込むようにする
- 書き換える前に元のファイルを退避し、書き換え後にAPIの疎通を確認する
- トークンが表示されたログや一時ファイルは、書き込み後すぐに削除する
本番環境にしても残る「失効の原因」
公開ステータスを直せば7日周期の停止はなくなりますが、更新トークンが使えなくなる原因はほかにもあります。Googleの公式ドキュメントでは、主に次のものが挙げられています。
| 原因 | 起こりやすい場面 |
|---|---|
| ユーザーがアクセスを取り消した | Googleアカウントのセキュリティ設定で、連携アプリの許可を外した |
| 6か月間使われていない | 季節だけ動かす集計、止めたまま放置した仕組み |
| パスワード変更（Gmailの権限を含む場合） | メールを読む仕組みで、アカウントのパスワードを変えた |
| 発行数の上限を超えた | 同じアカウント・同じクライアントで何度も認証し直した（1アカウント・1クライアントあたり上限100件） |
| 時間を区切った許可が切れた | 期限付きでアクセスを許可していた |
| 管理者による制限 | Google Workspaceの管理者が、該当サービスを制限対象にした |
この中で見落とされやすいのは、同じOAuthクライアントを複数の用途で使い回している場合です。別の担当者や別の作業で同じクライアントに何度も認証をかけると、古いトークンから順に使えなくなる可能性があります。用途ごとにクライアントを分けるか、少なくとも「このクライアントのトークンはどこで使っているか」を記録しておくと、原因の特定が早くなります。
また、停止に気づくのが遅れること自体が大きなリスクです。止まっていた期間が長くなるほど、取り直しの手間も判断の遅れも大きくなります。エラーの本文を記録すること、最後に成功した日時を表示すること、失敗したら通知が届くようにすること。この3つは、公開ステータスとは別に用意しておくべき備えです。
まとめ
- Google APIの自動連携が再認証のたびに約1週間で止まるなら、OAuth同意画面の公開ステータスが「テスト」のままになっている可能性が高い。外部ユーザー向けのテスト状態では、更新トークンは7日で失効するのがGoogleの仕様
- 見分け方は、エラー本文の
invalid_grantと、最後の認証日から最後の成功日までの日数。2回続けて7日なら、最有力の原因として同意画面を確認する - 恒久対策は「本番環境」への切り替え。その前に、ユーザーの種類（内部にできるか）・使う権限・未確認アプリの警告・使う人の範囲を確かめる
- 切り替え後は同意し直して新しいトークンを取り、同じトークンを保存しているファイルをすべて更新する
- 本番環境にしても、取り消し・6か月未使用・発行数の上限などで失効は起こりうる。エラー本文の記録と「最後に成功した時刻」の表示はセットで用意する
自動連携は、作ったときより「止まったときに気づけるか」で価値が決まります。Googleビジネスプロフィールの投稿自動化を始める前の準備についてはBusiness Profile APIの申請手順、広告費の見直しと自動集計の注意点はGoogle広告の費用がいつの間にか増えていたときの棚卸しもあわせて参考にしてください。