AMDが最新CPU Ryzen 9 9950X/9900Xを米国で発売!日本での価格と発売日が明らかに
2024年8月16日
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経由で実行する手順を解説します。どちらもプログラムを書かずに設定が完了します。
この記事でわかること
| 項目 | 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 API(accessBindings、OAuth 2.0 Playground経由) |
| 必要な権限レベル | 委譲された所有者(Delegated Owner) | 分析者(predefinedRoles/analyst)以上 |
| APIエラーの典型例 | 403 Permission denied (Indexing API等) |
403 User does not have sufficient permissions |
Search ConsoleのUIは、通常のGoogleアカウント(Google Workspaceや個人用Gmail)を前提に設計されています。 そのため、独自ドメインのDNSレコードやHTMLファイルアップロードなどの物理的な所有権確認を行えない「サービスアカウント」に対して、UIから直接「所有者」権限を与えることが制限されています。
通常のユーザー追加画面では、以下のような挙動になります。
[email protected] を入力Indexing APIなどの書き込み系APIや、GSCの所有者限定機能(他ユーザーの権限管理やサイト追加等)を実行する場合、サービスアカウント側にも「所有者」のステータスが要求されます。 この制限を突破するには、すでにウェブサイトの所有権を証明している既存の「確認済み所有者」のGoogleアカウントを使って、API経由でサービスアカウントへ所有権を「委譲(Delegate)」する必要があります。
プログラムを書くことなくAPIを直接実行できるGoogle公式ツール「OAuth 2.0 Playground」を利用した、最も手軽な委譲手順を解説します。
委譲を行う前に、自身のGoogle Cloudプロジェクトで必要なAPIを有効化します。
Playgroundを自身のプロジェクト経由で実行するための認証情報を取得します。
Playground Verification)を入力https://developers.google.com/oauthplayground を追加OAuth 2.0 Playgroundに移動し、設定と認可を行います。
https://www.googleapis.com/auth/siteverification を入力認証に成功するとリダイレクトされ、Playgroundの「Step 2: Exchange authorization code for tokens」画面に戻ります。 「Exchange authorization code for tokens」ボタンをクリックして、アクセストークンとリフレッシュトークンを取得します。 その後、「Step 3: Configure request to API」のセクションが有効になります。ここでAPIを叩いてサービスアカウントを追加します。
{id}部分に対象サイトのURLをそのまま、またはDomainプロパティの場合は sc-domain:example.com の形式で入力。URLエンコードが必要)https://www.googleapis.com/siteVerification/v1/webResource/https%3A%2F%2Fexample.com%2Fapplication/json を指定(Headersボタンから追加、または自動付与を確認){
"owners": [
"[email protected]",
"[email protected]"
]
}
注意:owners リストには必ず現在の所有者全員のメールアドレスを含めてください。PUT リクエストは「このリストが完全な所有者一覧」として扱われるため、自身を含め忘れると権限が意図せず変更されます。また、Google公式ドキュメントによれば、削除対象の所有者に紐づいた確認トークンが残っている場合は 400 Bad Request エラーが返ります。
レスポンスで HTTP/1.1 200 OK が返り、レスポンスボディの "owners" リストに両方のメールアドレスが含まれていれば、サービスアカウントへの所有者権限の委譲は成功です。
Search Consoleの「ユーザーと権限」画面を再読み込みすると、サービスアカウントの権限グループが「オーナー(委譲された所有者)」に変化していることが確認できます。
権限の委譲が完了しただけでは、サービスアカウント側のプロパティ一覧にサイトが登録されていない場合があります。
サービスアカウント自身の認証情報(JSONキー)を用いて、Search Console APIの sites.add メソッドを実行することで、サービスアカウントの管理対象として明示的に追加されます。
PUT https://www.googleapis.com/webmasters/v3/sites/{siteUrl}https://www.googleapis.com/auth/webmastersプログラムやcurlコマンドからサービスアカウントのアクセストークンを用いてこのエンドポイントを叩くことで、サービスアカウント側でのプロパティ準備が完全に完了します。
GA4の管理画面(「プロパティのアクセス管理」)からサービスアカウントを追加しようとすると、2026年4月下旬以降は「このメールアドレスはGoogleアカウントと一致しません」エラーが表示されます。
代わりに Google Analytics Admin API の accessBindings リソースを使って追加します。OAuth 2.0 Playgroundから5ステップで完了します。
https://www.googleapis.com/auth/analytics.manage.users「Step 2: Exchange authorization code for tokens」画面で 「Exchange authorization code for tokens」 をクリックし、アクセストークンを取得する。
{プロパティID} はGA4のプロパティIDに置き換え。例: 308259408)
https://analyticsadmin.googleapis.com/v1alpha/properties/{プロパティID}/accessBindings
注意: APIバージョンは必ず v1alpha を使用する。v1beta には accessBindings リソースが存在せず 404 になる。Enter Request Body を押し、以下のJSONを入力する(メールアドレスはサービスアカウントのものに置き換え)。
{
"user": "[email protected]",
"roles": ["predefinedRoles/analyst"]
}
ロールは用途に応じて変更可能(predefinedRoles/editor・predefinedRoles/admin 等)。
Send the request をクリックし、レスポンスに HTTP/1.1 200 OK が返れば成功。GA4管理画面の「プロパティのアクセス管理」にサービスアカウントが表示され、以後はUIから役割の変更も可能になります。
利用後はGoogleアカウントの「サードパーティのアプリとサービス」からPlaygroundのリフレッシュトークンのアクセスを削除しておくと安全です。
APIによる権限の付与は強力なため、プロジェクト終了時や運用体制の変更時には適切なクリーンアップが必要です。
サービスアカウントの秘密鍵(JSON)は、Gitなどのバージョン管理システムに絶対に含めないでください。 本番サーバーの環境変数や、暗号化されたシークレット管理ツール(Google Cloud Secret Managerなど)で運用するのが鉄則です。
サービスアカウントの所有者権限を剥奪したい場合は、Search Console UIの「ユーザーと権限」画面のオーナー管理リンクから「委譲された所有者」リストを表示し、対象のサービスアカウントの登録を削除するだけで安全に剥奪できます。 APIを再度叩く必要はありません。
サービスアカウントそのものが不要になった場合は、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まとめ
只今、価格を取得しています。
(2026年5月26日 06:31 GMT +09:00 時点 - 詳細はこちら価格および発送可能時期は表示された日付/時刻の時点のものであり、変更される場合があります。本商品の購入においては、購入の時点で当該の Amazon サイトに表示されている価格および発送可能時期の情報が適用されます。)