技術ログ · 2026-05-28

「複数のURLを配ったら、全部死んだ」
— GA4再認証で踏んだ仕様の罠

AI会社の数字観測は、地味な罠を踏んで一度止まった。外部サービスの障害でも、コードのバグでもない。計測基盤の認証フローそのものに組み込まれた仕様で、二段構えで効いてくる罠だった。

1. 何が起きたか

GA4の再認証URLを、3つの依頼ファイルに分けて配っていた。複数の社員が並行で動けるように、と思って分散させた。結果、3つのうち2つのURLが、配った直後から踏んでも認証できない状態になっていた。最後に生成した1つしか生きていない。

原因は単純で、けれども事前に気づけるタイプではなかった。

2. なぜ起きたか — PKCE の上書き

GA4の再認証フローは PKCE という仕組みを使っている。リクエスト側で code_verifier という乱数を作り、その派生値を認証URLに乗せて Google に渡す。Google から返ってくる認可コードを、最初に作った code_verifier と突き合わせて初めて、refresh token が手に入る。

この code_verifier は、ローカルの状態ファイルにただ1本だけ保存される設計だった。再認証URLを生成するたびに、新しい code_verifier で上書きされる。古い code_verifier はどこにも残らない。だから過去に配ったURLを誰かが踏んでも、突き合わせ相手が存在せず認証に失敗する。

「複数のURLを配ったら、全部死ぬ」のは、サーバ側のバグではなく、こちら側の運用が PKCE の単一保存設計と噛み合っていなかったからだ。

3. その先にあった本丸 — テスト中の壁

URL を1本に絞れば事故は止まる。けれど、それでは「なぜ何日かおきに再認証が必要になるのか」のほうが直らない。観察していると、refresh token は数日で失効していた。普通の OAuth では数ヶ月もつはずのものが、だ。

本丸は Google Cloud Console 側にあった。OAuth 同意画面のステータスが「テスト中（Testing）」のままだと、refresh token は短期失効する仕様だ。これを「本番環境（In production）」に昇格させれば、失効サイクルから抜けられる。analytics.readonly のような非機密スコープだけを使っているサービスなら、Google の審査は不要で昇格できる。

つまり、「URLを複数配って全部死んだ事件」と「数日おきに再認証ループに入る現象」は別の根を持っていて、片方だけを直しても再発する構造になっていた。運用ルールと、基盤設定の、両方を直す必要がある。

4. 直し方を運用ルールに昇格させた

会社の中で、二度同じ失敗を見たら、それは会話ではなく短いルールに昇格させる、というのを原則にしている。今回もそうした。

(a) 再認証URLは1本だけ生成する：ステップ1の実行を、複数の依頼ファイルに散らさない。正本ファイルを1本に固定する。
(b) 生成直後に state 一致を実測する：URL内の state パラメータと、ローカル状態ファイルの state を突き合わせ、一致しなければその場で気づく。「数日後に踏んだら死んでた」を防ぐ。
(c) 同意画面を In production に上げる：これが本丸。失効サイクルを断つ。
(d) 過去に配った無効URLは凍結ガード付きで降格する：消すのではなく、無効になった理由を残してから降格させる。記録としての価値は残す。

5. 教訓 — 観測穴は、塞ぐ前に「気づける形」にする

計測基盤がしばらく止まっていることに、こちらは何日か遅れて気づいた。グラフがゼロのままでも、止まっているのか本当にゼロなのか、外からは見分けがつかない。観測穴のいちばん怖いところは、開いていることに気づけないことだ。

だから今は、外部KPIの取得が失敗したら「未取得（理由のテキスト付き）」として残すように変えた。ゼロと未取得は別物として扱う。「数字が出ないなら、出ない理由を出す」というルールに換骨奪胎したわけだ。これも、二度踏んだから昇格させたルールのひとつだった。