この記事の結論
原因はGoogleのログイン（ADC）の期限切れ。再ログイン後に認証ファイルの作り直しとMCPの再起動まで要ります。当社で5回出た記録と、10月4日に鍵方式へ移してから止まっていない再発防止つき。
目次6項目
【実践講座】Claude Code 2daysセミナー（第二の脳構築講座）の詳細を見る →
GA4 の MCP サーバーで 503 Reauthentication is needed が出たら、Google のログイン（ADC）の期限切れです。gcloud auth application-default login でログインし直し、MCP が読む認証ファイルを作り直してから、AI のアプリを再起動します。最後の再起動を飛ばすと、古い認証のまま失敗し続けます。
「503 Reauthentication is needed」とは？GA4 MCPで出る3つの原因
このエラーは「もう一度ログインしてください」という意味です。GA4 の MCP サーバー（AI から GA4 のデータを読むための公式プログラム）は、手元の Google のログイン情報を使って GA4 にアクセスします。そのログインの期限が切れると、GA4 の数字を取りにいった時点でこのエラーが返ります。先頭の「503」に引っ張られて Google の障害を疑いがちですが、当社で出た5回はすべて認証の問題でした。
用語を2つ押さえておきます。ADC（Application Default Credentials）とは、Google のプログラムがログイン情報を自動で探して使う仕組みのことです。公式ドキュメントによると、探す順番は「環境変数 GOOGLE_APPLICATION_CREDENTIALS が指すファイル」「gcloud auth application-default login で作ったファイル」「実行環境に付いたサービスアカウント」の3つです。再認証（reauthentication）とは、一度ログインしていても、期限や会社の設定によって改めてサインインを求められることです。
当社の記録から、原因を多い順に並べます。
| 原因 | 何が起きているか | 見分け方 |
|---|---|---|
| ① ログインの期限切れ | ADC のログインが、会社の Google Workspace の設定や時間の経過で切れた | gcloud auth application-default login をやり直すと直る |
| ② 再ログインしたのに、MCP が別のファイルを読んでいる | 環境変数 GOOGLE_APPLICATION_CREDENTIALS が、再ログインで書き換わったファイルとは別の認証ファイルを指している | ログインし直してもエラーが変わらない |
| ③ MCP サーバーが古い認証を持ち続けている | 起動中の MCP サーバーが、前の認証を持ったまま動いている | ファイルを直しても、アプリを再起動するまで失敗する |
①の背景にあるのが、Google Workspace のセッションの長さの設定です。Google Cloud の公式ドキュメントは、Workspace の管理者がセッションの最大の長さを決められること、そして、ローカルの ADC ファイルの認証もセッションと一緒に切れることを説明しています。Workspace の管理者ヘルプでは、この設定は gcloud コマンドラインツールにも効き、長さは1時間から24時間の範囲で決めると書かれています。会社のアカウントで使っていると、何もしていないのに1〜2日で切れることがあるのはこのためです。
再ログインしても直らないときの対処手順（ADC・認証ファイル・MCPの再起動）
順番が大事です。ログインし直すだけで終わらせず、MCP が実際に読むファイルと、起動中のサーバーまで更新します。
手順1 ADC でログインし直す
自分のアカウントで直接つないでいるなら、GA4 の MCP サーバーの説明にあるとおり、GA4 の読み取りのスコープを付けてログインします。
gcloud auth application-default login \
--scopes https://www.googleapis.com/auth/analytics.readonly,https://www.googleapis.com/auth/cloud-platform \
--client-id-file=YOUR_CLIENT_JSON_FILEサービスアカウントの借用（自分のログインを出発点に、サービスアカウントの短期間のトークンを発行してもらう方式）を使っているなら、--client-id-file の代わりに --impersonate-service-account=SERVICE_ACCOUNT_EMAIL を付けます。
手順2 表示された保存先を控える
ログインが終わると Credentials saved to file: のあとに保存先が出ます。Linux と macOS の既定の保存先は $HOME/.config/gcloud/application_default_credentials.json です。
手順3 MCP の設定の GOOGLE_APPLICATION_CREDENTIALS がそのファイルを指しているか確かめる
公式ドキュメントによると、この環境変数が指す認証は、ほかの認証より優先されます。つまり、環境変数が別の場所のファイル（以前に写したもの・別名で作ったもの）を指していると、いくらログインし直しても MCP は古いファイルを読み続けます。別の場所を指しているなら、そのファイルを新しいログインで作り直すか、環境変数の向き先を変えます。
手順4 AI のアプリを再起動する
起動中の MCP サーバーは、前の認証を持ったまま動いていることがあります。当社では、ファイルを直したあとも再起動するまで同じエラーが続きました。Claude Code なら、アプリ（または起動中のセッション）を一度終了して立ち上げ直します。
手順5 実際に1回データを取って確かめる
プロパティの一覧を出すなど、軽い読み取りを1回だけ試します。「設定した」と「取れた」は別なので、取れたところまでを完了の条件にします。
どうしても急ぐ日は、MCP を通さずに、同じ認証ファイルで GA4 の API を直接呼ぶ手順を用意しておくと、再起動を待たずに数字だけは取れます。当社は2026年7月、再起動までの間この方法でレポートを取得しました。
裏方で5回出た「503 Reauthentication is needed」の記録
僕の会社では、GA4 の公式 MCP サーバーで、自社サイトと案件の LP を合わせた複数のプロパティを会話で分析しています。このエラー文で作業記録に残っているものだけで5回出ました。すべて社内の作業メモと定期タスクのログから転記しています。
| 日付（2026年） | 何をしていて | どう出たか | どう直したか |
|---|---|---|---|
| 7月28日 | ログインし直したあとの分析 | 認証ファイルを作り直しても、MCP が 503 を返し続けた | 再起動までは API を直接呼んで代替。再起動で解消 |
| 8月18日〜20日 | 広告案件の日々の数字の確認 | MCP と gcloud の両方で Reauthentication is needed。前日の未明に直したばかりで、約24時間で再発。3日続いた | 数字はサーバー側の計測で代替し、ログインし直しを依頼 |
| 9月11日 | 同じ案件の確認 | 同じエラーで GA4 の内訳が取れず | GA4 なしで判断し、再認証を待った |
| 10月2日 | 定期タスクを別の Mac へ移した直後の試運転 | GA4 の取得だけが 503 | 僕がログインし直し、認証ファイルを作り直して約10分後の23時36分に復旧 |
| 10月4日 | 朝6時台の定期タスク | GA4 が 503、検索データの取得も invalid_rapt で失敗 | 鍵方式へ切り替え（次の章） |
一番困ったのは、7月28日の「直したのに直らない」です。ログインもやり直し、認証ファイルも作り直したのに、MCP は同じエラーを返し続けました。原因は、起動中の MCP サーバーが古い認証を持ったままだったことでした。この日から、手順の最後に必ず「アプリの再起動」と「1回取って確かめる」を入れています。
もう1つの気づきは、間隔です。8月は直してから約24時間、10月は10月2日23時36分に直して、10月4日の朝6時台にはもう切れていました。10月4日には検索データの取得でも invalid_rapt（再認証が要るという意味の応答）が出ていたので、当社は Workspace の再認証の設定が効いていると判断しました。人がログインし直す運用では、どれだけ急いで直しても1〜2日で同じ所に戻ります。
移行直後に出た10月2日の件は、Claude Codeを新しいMacに移行する方法の「落とし穴」にも書いています。
再認証エラーを繰り返さない再発防止（鍵方式への切り替え）
根本の対処は、無人で動く仕組みを人のログインから切り離すことです。当社は10月4日、GA4 の閲覧しかできないサービスアカウントの鍵で動く形に切り替えました。サービスアカウントとは、人ではなくプログラムが Google のサービスを使うための専用アカウントです。鍵方式なら、Workspace のセッションが切れても影響を受けません。
切り替えたあと、10月5日から9日まで毎朝の GA4 の取得は5日続けて成功しています（定期タスクの取得記録）。それまでの借用方式では、出発点が人のログインだったので、ログインが切れるたびに止まっていました。
ただし、鍵を作るには組織ポリシーの壁があります。2024年5月3日以降に作った組織では、サービスアカウントの鍵の作成が既定で止められています。当社もここで止まり、分析専用のプロジェクト1つだけ例外にしました。手順はサービスアカウントの鍵が作れない時の対処（iam.disableServiceAccountKeyCreation）にまとめています。
鍵方式に移すまでの間、当社で決めていたルールは次の3つです。
- 定期タスクは最初に1回だけ生存確認をする。 GA4 の取得の前に軽い読み取りを1回試し、503 が出たら GA4 の取得を飛ばして、結果の冒頭に「要再認証」と書きます。同じ認証エラーで何度も再試行すると、タスクがそこで固まるためです。
- 失敗した日は、取れた日のデータを上書きしない。 同じ日にすでに成功したファイルがあれば残します。数字を推測で埋めることもしません。
- ログインし直したら、認証ファイルの作り直しと再起動までを1セットにする。 手順書にも、この3つを1つのまとまりとして書いています。
業務でGA4 MCPを使うときの注意（権限・代わりの数字・チーム運用）
GA4 の MCP サーバーは、公式に「実験的（Experimental）」とされています。公式の案内でも読み取り専用で、GA4 の設定を変えることはできません。業務で使うときは、止まる前提で次の3点を決めておくと慌てずに済みます。
1. 権限は読み取りだけにする。 ログインのスコープは analytics.readonly を基本にします。鍵方式に移すときも、鍵を持たせるサービスアカウントは GA4 の閲覧者にとどめます。当社は GA4 の「アカウント」単位で閲覧者を付け、案件が増えても付け直さずに済むようにしています。
2. GA4 が取れない日の代わりの数字を決めておく。 当社の広告案件では、8月の3日間、GA4 の代わりにサーバー側で取っていた計測の数字で日々の判断を続けました。代わりがないと、認証が切れた日はそのまま判断が止まります。
3. 再認証を誰がやるかを決める。 ログインし直しは、その Google アカウントの持ち主にしかできません。AI が夜中に気づいても、直すのは翌朝の人です。チームで使うなら、エラーに気づいたら誰に何を頼むかを手順書に1行書いておきます。会社の Workspace の設定を緩める手もありますが、全社のセキュリティに関わるので、当社は選びませんでした。
MCP の仕組みそのものはMCPとは（AIと業務ツールをつなぐ仕組みと実例）で解説しています。GA4 や広告の数字を AI に読ませる仕組みを自社の業務に合わせて組みたい場合は、下のセミナーで具体的な作り方をお伝えしています。
よくある質問
「503」と出ているのはGoogle側の障害ですか？
当社で出た5回は、どれも障害ではなく認証の期限切れでした。見るべきは数字より後ろの「Reauthentication is needed」です。同じ時間にGoogleのほかのサービスが普通に使えていて、ログインし直すと直るなら、手元の認証の問題と考えてよいです。
ログインし直したのに、まだ同じエラーが出るのはなぜですか？
多いのは2つです。MCPサーバーが読む認証ファイルが、再ログインで書き換わったファイルと別の場所にある場合と、起動中のMCPサーバーが古い認証を持ち続けている場合です。ファイルの場所を確かめて作り直し、AIのアプリを再起動します。
毎日のようにこのエラーが出る場合はどうすればいいですか？
会社のGoogle Workspaceで、Google Cloudのセッションの長さが決められている可能性があります。その場合は何度ログインし直しても1〜2日で切れます。無人で動かすなら、人のログインに頼らない認証（サービスアカウントの鍵など）へ移すのが根本の対処です。