ブログ一覧

サービスアカウントが Search Console に追加できない（email not found）— Google 側バグと gcloud ADC での回避

Web開発者向け

Google Search Console のデータをスクリプトから定期取得するときの定番構成は、サービスアカウント（SA）を作って、そのメールアドレスを Search Console のユーザーとして追加する方法です。ところが 2026 年の春頃から、この構成が新規ではセットアップできなくなっています。

新しく作成したサービスアカウントを Search Console に追加しようとすると「Failed to add user: email not found」で弾かれるのです。GA4 でも同じ症状が報告されています。

本記事では、これが Google 側の既知バグであること、そしてサービスアカウントを諦めてユーザー認証の ADC（Application Default Credentials）で回避する具体的な手順とハマりどころをまとめます。

前提: 2026 年 7 月時点の情報です。Search Console API を Node.js 等のスクリプトから叩く用途を想定しています。

症状: 新規サービスアカウントだけが「email not found」

  • GCP でサービスアカウントを作成（xxx@project.iam.gserviceaccount.com）
  • Search Console の「設定 → ユーザーと権限 → ユーザーを追加」で SA のメールを入力
  • 「ユーザーを追加できませんでした: メールアドレスが見つかりません」

メールアドレスのタイポではありません。何度作り直しても同じです。一方で、昔から存在するサービスアカウントは問題なく追加できる（追加済みのものはそのまま動く）のがこのバグの特徴で、私が確認した範囲では 2026 年 4 月下旬以降に新規作成した SA で発生します。

Google Search Central のコミュニティにも同時期から報告が多数上がっており、Google がバグとして認識していることも報じられていますが、2026 年 7 月時点で修正時期は不明です。

回避策: ユーザー認証の ADC に切り替える

サービスアカウントが使えないなら、Search Console に既にアクセスできる人間の Google アカウントの資格情報でスクリプトを動かせばよい、というのが回避の骨子です。gcloud CLI の ADC（Application Default Credentials）を使います。

gcloud auth application-default login \
  --scopes=cloud-platform,https://www.googleapis.com/auth/webmasters.readonly

ブラウザで同意すると ~/.config/gcloud/application_default_credentials.json に資格情報が保存され、スクリプトからはアクセストークンとして使えます。

TOKEN=$(gcloud auth application-default print-access-token)
curl -s "https://searchconsole.googleapis.com/webmasters/v3/sites" \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-Goog-User-Project: my-project-id"

シンプルに見えますが、実際にやると4 つの罠があります。順に説明します。

罠① scope に cloud-platform が必須

--scopes に webmasters 系だけを指定すると失敗します。gcloud の ADC ログインは `cloud-platform` スコープを必ず含める必要があります（gcloud 側の仕様）。Search Console 用のスコープは、その追加として並べます。

罠② 同意画面のチェックボックスは「全部」チェックする

ブラウザの OAuth 同意画面には、要求したスコープがチェックボックスで並びます。ここで一部だけ許可すると、発行されたトークンのスコープが要求と食い違い、後続の API 呼び出しが分かりにくいエラーで死にます。全部チェックしてください。

罠③ quota project を設定しないと SERVICE_DISABLED になる

ユーザー資格情報で Google API を叩く場合、「この呼び出しの課金・クォータをどの GCP プロジェクトに付けるか」を明示する必要があります。指定がないと、Search Console API 側が `SERVICE_DISABLED`（API を有効化していません）という、原因と全く違う顔のエラーを返してきます。API はプロジェクトで有効化済みなのに、です。

gcloud auth application-default set-quota-project my-project-id

を一度実行すると資格情報ファイルに quota_project_id が書き込まれます。HTTP を直接叩く場合は、リクエストヘッダー `X-Goog-User-Project: my-project-id` で渡します（Google Cloud 公式: Set the billing project）。

注意: ADC を再ログインするたびに quota project の設定は消えます。ログイン手順とセットで覚えておく必要があります。

罠④ 読み取りと書き込みでスコープが違う

Search Analytics の取得やサイトマップ一覧は webmasters.readonly で足ります。しかしサイトマップの送信・削除は書き込みスコープ `https://www.googleapis.com/auth/webmasters` が必要で、readonly のトークンだと 403 になります。サイト移行後に古いサイトマップを消して新しいものを送信する、といった運用をするなら、最初から書き込みスコープでログインしておくのが楽です。

この回避策の割り切り

  • ユーザー ADC は人間のアカウントに紐づくので、無人サーバーでの長期運用には不向きです（トークンのリフレッシュはしてくれますが、組織のセキュリティポリシーによっては定期的に再認証が要ります）。手元マシンや開発環境からの定期レポート用途なら十分実用です
  • バグが解消されたら、サービスアカウント方式に戻すのが本来の形です。コード側は「Bearer トークンで叩く」構造を変えなければ、資格情報の出どころを差し替えるだけで戻せます

まとめ

  • 2026 年 4 月下旬以降、新規作成したサービスアカウントが Search Console / GA4 に「email not found」で追加できない Google 側のバグが発生している（7 月時点で未修正）
  • 回避はユーザー認証の ADC。gcloud auth application-default login に cloud-platform + webmasters 系スコープを指定する
  • ハマりどころは「cloud-platform 必須」「同意画面は全チェック」「quota project（X-Goog-User-Project）を設定しないと SERVICE_DISABLED」「書き込みは webmasters スコープ」の 4 つ

参考リンク

ブログ一覧