Google Search Console APIとSite Verification APIの開発者向けドキュメント
出典: Google Search Developers (developers.google.com/search)

GSCにサービスアカウントを所有者追加する手順

当サイトは、Amazonアソシエイトおよび各種アフィリエイトプログラムにより適格販売から収入を得ています。

APIを介した自動インデックス送信やSearch Consoleデータの抽出を自動化するとき、Googleのサービスアカウントは必須の道具です。 しかし、Search Consoleの管理画面(UI)から追加しようとして、手が止まる人が多いのがこの設定です。

「ユーザーと権限」の追加ボタンを押してサービスアカウントのメールアドレスを入れても、権限レベルに「オーナー(所有者)」の選択肢が出てきません。 選べるのは「フル」か「制限付き」だけです。そして、「フル」権限のままIndexing APIを叩くと、403 Forbidden のエラー(所有権がない)で処理が失敗します。

2026年4月下旬以降、@iam.gserviceaccount.com のメールアドレスはSearch Console・GA4を含むGoogleサービス全般でUI追加が拒否されるようになりました。 「このメールアドレスはGoogleアカウントと一致しません」というエラーが表示され、どの画面からも追加できません。

この記事では、Search Console用のSite Verification APIとGA4用のGoogle Analytics Admin API、それぞれをOAuth 2.0 Playground経由で実行する手順を解説します。どちらもプログラムを書かずに設定が完了します。

この記事でわかること

  • GSC「ユーザーを追加」UIでは所有者権限を付与できない理由と、Site Verification APIによる委譲手順
  • OAuth 2.0 Playgroundを用いたSite Verification APIの具体的な実行方法
  • GA4とSearch Consoleにおけるサービスアカウント権限追加の違い

サービスアカウント追加方法の比較

項目 Google Search Console (GSC) Google Analytics 4 (GA4)
UIからのサービスアカウント追加 2026年4月下旬以降 UIから不可@iam.gserviceaccount.com はGoogleサービス全般で拒否) 同上 — UIから不可(「このメールアドレスはGoogleアカウントと一致しません」エラー)
解決手段 Site Verification API(OAuth 2.0 Playground経由) Google Analytics Admin APIaccessBindings、OAuth 2.0 Playground経由)
必要な権限レベル 委譲された所有者(Delegated Owner) 分析者(predefinedRoles/analyst)以上
APIエラーの典型例 403 Permission denied (Indexing API等) 403 User does not have sufficient permissions

GSC サービスアカウント 所有者の登録におけるUI制限と背景

Search ConsoleのUIは、通常のGoogleアカウント(Google Workspaceや個人用Gmail)を前提に設計されています。 そのため、独自ドメインのDNSレコードやHTMLファイルアップロードなどの物理的な所有権確認を行えない「サービスアカウント」に対して、UIから直接「所有者」権限を与えることが制限されています。

通常のユーザー追加画面では、以下のような挙動になります。

  1. 「設定」 > 「ユーザーと権限」を開く
  2. 「ユーザーを追加」をクリック
  3. [email protected] を入力
  4. 権限のプルダウンに「オーナー」が表示されない(「フル」または「制限付き」のみ)

Indexing APIなどの書き込み系APIや、GSCの所有者限定機能(他ユーザーの権限管理やサイト追加等)を実行する場合、サービスアカウント側にも「所有者」のステータスが要求されます。 この制限を突破するには、すでにウェブサイトの所有権を証明している既存の「確認済み所有者」のGoogleアカウントを使って、API経由でサービスアカウントへ所有権を「委譲(Delegate)」する必要があります。

解決手順:OAuth 2.0 PlaygroundとSite Verification APIによる権限委譲

プログラムを書くことなくAPIを直接実行できるGoogle公式ツール「OAuth 2.0 Playground」を利用した、最も手軽な委譲手順を解説します。

ステップ1:Google Cloud ConsoleでのAPI有効化

委譲を行う前に、自身のGoogle Cloudプロジェクトで必要なAPIを有効化します。

  1. Google Cloud Console にログイン
  2. 作業対象のプロジェクトを選択
  3. 「APIs & Services」 > 「Library」を開く
  4. Site Verification API および Google Search Console API を検索し、有効化(Enable)をクリック

ステップ2:OAuth認証情報の取得

Playgroundを自身のプロジェクト経由で実行するための認証情報を取得します。

  1. 「APIs & Services」 > 「Credentials」を開く
  2. 「Create Credentials」 > 「OAuth client ID」をクリック
  3. Application type で「Web application」を選択
  4. Name に分かりやすい名称(例:Playground Verification)を入力
  5. Authorized redirect URIshttps://developers.google.com/oauthplayground を追加
  6. 「Create」をクリックし、生成された Client IDClient Secret を手元に控える

ステップ3:OAuth 2.0 Playgroundでのアクセス認可

OAuth 2.0 Playgroundに移動し、設定と認可を行います。

  1. Google OAuth 2.0 Playground を開く
  2. 右上の Gearアイコン (OAuth 2.0 Configuration) をクリック
  3. Use your own OAuth credentials にチェックを入れる
  4. ステップ2で控えた OAuth Client IDOAuth Client Secret を入力し、Closeをクリック
  5. 左側メニューの「Step 1: Select & authorize APIs」の最下部にあるテキストボックスに https://www.googleapis.com/auth/siteverification を入力
  6. Authorize APIs をクリックし、対象のGSCプロパティで「確認済み所有者」になっているGoogleアカウントでログインして権限を許可

ステップ4:Site Verification APIによる所有者の追加(委譲)

認証に成功するとリダイレクトされ、Playgroundの「Step 2: Exchange authorization code for tokens」画面に戻ります。 「Exchange authorization code for tokens」ボタンをクリックして、アクセストークンとリフレッシュトークンを取得します。 その後、「Step 3: Configure request to API」のセクションが有効になります。ここでAPIを叩いてサービスアカウントを追加します。

  1. HTTP MethodPUT を選択
  2. Request URI に以下を入力({id}部分に対象サイトのURLをそのまま、またはDomainプロパティの場合は sc-domain:example.com の形式で入力。URLエンコードが必要)
  3. 例:https://www.googleapis.com/siteVerification/v1/webResource/https%3A%2F%2Fexample.com%2F
  4. Content-Typeapplication/json を指定(Headersボタンから追加、または自動付与を確認)
  5. Request Body に以下のJSONを入力(既存の自分のメールアドレスと、追加したいサービスアカウントのメールアドレスを両方記載)
{
  "owners": [
    "[email protected]",
    "[email protected]"
  ]
}

注意:owners リストには必ず現在の所有者全員のメールアドレスを含めてください。PUT リクエストは「このリストが完全な所有者一覧」として扱われるため、自身を含め忘れると権限が意図せず変更されます。また、Google公式ドキュメントによれば、削除対象の所有者に紐づいた確認トークンが残っている場合は 400 Bad Request エラーが返ります。

  1. Send the request をクリック

レスポンスで HTTP/1.1 200 OK が返り、レスポンスボディの "owners" リストに両方のメールアドレスが含まれていれば、サービスアカウントへの所有者権限の委譲は成功です。 Search Consoleの「ユーザーと権限」画面を再読み込みすると、サービスアカウントの権限グループが「オーナー(委譲された所有者)」に変化していることが確認できます。

仕上げ:サービスアカウントのSearch Consoleへのプロパティ登録

権限の委譲が完了しただけでは、サービスアカウント側のプロパティ一覧にサイトが登録されていない場合があります。 サービスアカウント自身の認証情報(JSONキー)を用いて、Search Console APIの sites.add メソッドを実行することで、サービスアカウントの管理対象として明示的に追加されます。

  • Endpoint: PUT https://www.googleapis.com/webmasters/v3/sites/{siteUrl}
  • Scope: https://www.googleapis.com/auth/webmasters

プログラムやcurlコマンドからサービスアカウントのアクセストークンを用いてこのエンドポイントを叩くことで、サービスアカウント側でのプロパティ準備が完全に完了します。

GA4へのサービスアカウント追加手順(Analytics Admin API経由)

GA4の管理画面(「プロパティのアクセス管理」)からサービスアカウントを追加しようとすると、2026年4月下旬以降は「このメールアドレスはGoogleアカウントと一致しません」エラーが表示されます。 代わりに Google Analytics Admin API の accessBindings リソースを使って追加します。OAuth 2.0 Playgroundから5ステップで完了します。

ステップ1:スコープの指定と認可

  1. Google OAuth 2.0 Playground を開く
  2. 左の入力欄(「Input your own scopes」)に以下のスコープを入力する https://www.googleapis.com/auth/analytics.manage.users
  3. Authorize APIs をクリックし、GA4プロパティの管理者権限を持つGoogleアカウントで認可する

ステップ2:アクセストークンの取得

「Step 2: Exchange authorization code for tokens」画面で 「Exchange authorization code for tokens」 をクリックし、アクセストークンを取得する。

ステップ3:リクエストの設定

  1. HTTP MethodPOST を選択
  2. Request URI に以下を入力する({プロパティID} はGA4のプロパティIDに置き換え。例: 308259408https://analyticsadmin.googleapis.com/v1alpha/properties/{プロパティID}/accessBindings 注意: APIバージョンは必ず v1alpha を使用する。v1beta には accessBindings リソースが存在せず 404 になる。

ステップ4:リクエストボディの入力

Enter Request Body を押し、以下のJSONを入力する(メールアドレスはサービスアカウントのものに置き換え)。

{
  "user": "[email protected]",
  "roles": ["predefinedRoles/analyst"]
}

ロールは用途に応じて変更可能(predefinedRoles/editorpredefinedRoles/admin 等)。

ステップ5:リクエストの送信と確認

Send the request をクリックし、レスポンスに HTTP/1.1 200 OK が返れば成功。GA4管理画面の「プロパティのアクセス管理」にサービスアカウントが表示され、以後はUIから役割の変更も可能になります。

利用後はGoogleアカウントの「サードパーティのアプリとサービス」からPlaygroundのリフレッシュトークンのアクセスを削除しておくと安全です。

セキュリティと運用管理の注意点

APIによる権限の付与は強力なため、プロジェクト終了時や運用体制の変更時には適切なクリーンアップが必要です。

1. 秘密鍵(JSONファイル)の保管

サービスアカウントの秘密鍵(JSON)は、Gitなどのバージョン管理システムに絶対に含めないでください。 本番サーバーの環境変数や、暗号化されたシークレット管理ツール(Google Cloud Secret Managerなど)で運用するのが鉄則です。

2. 権限の削除手順

サービスアカウントの所有者権限を剥奪したい場合は、Search Console UIの「ユーザーと権限」画面のオーナー管理リンクから「委譲された所有者」リストを表示し、対象のサービスアカウントの登録を削除するだけで安全に剥奪できます。 APIを再度叩く必要はありません。

3. トークンの無効化

サービスアカウントそのものが不要になった場合は、Google Cloud Consoleの「IAM & Admin」 > 「Service Accounts」から、アカウント自体を無効化(Disable)または削除(Delete)してください。

実務でSearch Console APIをシステムに組み込む際は、まずこの「委譲プロセス」を完了させてからプログラムのテストに入ると、余計なエラーに悩まされる時間を大幅に削減できます。

Indexing APIの自動化基盤を構築するとき、筆者が最初に詰まったのもこの権限委譲の部分でした。403が返り続ける原因が権限設定にあると気づくまでに、不必要なデバッグ時間を費やした経験があります。UIのどこを見ても「所有者として追加する」ボタンがなく、ドキュメントを掘り下げて初めてSite Verification APIの存在に行き着いた手順は、Googleのドキュメント体系をある程度把握していないと辿り着けません。 この記事がその道筋を短縮するための参照先になれば幸いです。

関連記事: AIコーディングCLI料金比較 関連記事: Ryzen AI MaxでローカルAIを動かすなら 関連記事: Radeon 8060S搭載PCまとめ

関連記事

AMD RYZEN 9000
AMDが最新CPU Ryzen 9 9950X/9900Xを米国で発売!日本での価格と発売日が明らかに
2024年8月16日
Stand & Hub For 2024 M4 Mac Mini
Apple M4 Mac Miniユーザー歓喜!RayCueの多機能ドッキングステーションが発売開始
2024年11月22日
Qualcomm Intel
クアルコムのインテル買収構想、規制と資金面で”不可能”に近い
2024年9月24日