Search Console APIの403「権限がない」原因｜ドメインとURLプレフィックスの違いで直した記録

2026-10-19

Search Console APIの403エラーを直す（権限がない？原因はプロパティの種類）

「Search Console の数字を API（プログラムからデータを受け取る窓口）で取ろうとしたら、403 エラーで止まった」「自分のサイトなのに『User does not have sufficient permission for site』と言われる。何の権限が足りないの？」「Search Console の画面では普通に数字が見えるのに、なぜ API だと断られるの？」

この記事は、この悩みに答えるために書きました。

結論を先に書くと、筆者の場合の原因は「権限が足りない」ことではなく、「API に伝えたプロパティ（Search Console に登録したサイトの単位）の書き方が、権限を持っている方と違っていた」ことでした。同じサイトでも、Search Console には「ドメイン」と「URLプレフィックス」という2種類の登録のしかたがあり、API はこの2つを別のものとして扱います。筆者は1行の指定を直しただけで、403 が消えてデータが取れるようになりました。

この記事では、403 の原因、自分の権限を確かめる方法、直す手順を、筆者が実際に出したエラーと画面の結果と一緒に説明します。

筆者は40代の会社員（非エンジニア）です。プログラムは書けないので、作業は Claude Code（パソコンの中で作業を代わりにやってくれるAI）に頼んでいます。

※ 本記事はAI（Claude）を用いて執筆しています。公式情報、筆者から提供された体験・記録、想定例を区別して記載します。

情報の確認日：2026年10月18日現在（Google の公式ヘルプと API の説明ページを、この日に開いて確認しました。エラーの再現も同じ日に行っています）。

社長：「自分のブログの数字なのに、APIだと『権限がない』って断られたんだよ。持ち主は俺なんだけどな。」

凛：「持ち主なのに断られるなら、断られてるのは社長じゃなくて『頼み方』の方でしょ。」

策：「その通りです。Search Console API は、どのプロパティのデータがほしいかを1つの文字列で受け取ります。その書き方が、権限を持っているプロパティと1文字でも違うと、別のプロパティへの依頼として扱われて 403 になります。」

📌 目次（クリックでジャンプ）

1. Search Console APIの403で止まる本当の原因
- 1-1. 同じサイトでも「ドメイン」と「URLプレフィックス」は別物
- 1-2. 403 になる主な原因は4つ
2. Search Console APIの403を直す4つの手順
3. 筆者の場合：sc-domainを指定して403、URLプレフィックスに変えて解決
4. つまずきやすい点と避け方
5. よくある質問
6. まとめ：403は「一覧を出す→権限がある行をそのまま使う」で直る
- 次に読むべき記事

1. Search Console APIの403で止まる本当の原因

Search Console API で 403 が出ると、エラーには「User does not have sufficient permission for site（このサイトに対する十分な権限がありません）」と書かれています。この文だけを読むと、「自分のアカウントに権限を足せば直る」と考えがちです。

ただ、Google の API 説明ページを見ると、データの取り出し先は siteUrl という1つの文字列で指定します。そしてプロパティの種類によって、書き方がはっきり分かれています（Search Console API：Sites・2026年10月18日現在）。

1-1. 同じサイトでも「ドメイン」と「URLプレフィックス」は別物

Search Console のプロパティには2種類あります。Google の公式ヘルプによると、違いは次のとおりです（ウェブサイトプロパティを追加する – Search Console ヘルプ・2026年10月18日現在）。

種類	APIでの書き方の例	対象になる範囲
ドメイン	`sc-domain:example.com`	そのドメインと全サブドメイン・http/https の両方
URLプレフィックス	`https://example.com/`	登録した先頭部分で始まるURLだけ

公式ヘルプでは、ドメインプロパティの確認方法は「DNS レコードの確認」だけとされています。一方、URLプレフィックスは、HTMLファイルを置くなど、ほかの確認方法も選べます。

つまり、昔 URLプレフィックスでサイトを登録して所有者になった人が、あとからドメインプロパティを追加しても、そちらで所有権の確認が済んでいなければ、同じサイトなのに片方だけ権限がないという状態が起こり得ます。筆者がはまったのは、まさにこの形でした。

1-2. 403 になる主な原因は4つ

筆者の体験と、公式ページ・各ツールのFAQで挙がっていた原因をまとめると、次の4つです。

原因	起きること
プロパティの種類の書き違い	ドメインなのに URL 形式、またはその逆で書いて 403
URLの細かい違い	www の有無・http と https・最後の「/」の有無で別扱い
権限の段階が足りない	そのプロパティで「確認されていない」扱いになっている
別のGoogleアカウントで認証	登録したアカウントと API に使ったアカウントが違う

どれも、エラーの文面は同じ「sufficient permission」です。だから、文面だけでは原因を見分けられません。次の章で、自分がどれに当たるかを確かめる方法を説明します。

社長：「え、URLの最後の『/』があるかないかでも別扱いなの？」

凛：「URLプレフィックスは『この文字で始まるURL』の登録だからね。始まりの文字が違えば、別の登録よ。」

策：「API の説明ページの例も http://www.example.com/ と、最後に『/』が付いた形で書かれています。まず、自分が持っている登録の正確な書き方を、API 自身に聞くのが早いです。」

2. Search Console APIの403を直す4つの手順

ここからが直し方です。ポイントは、推測で書き方を変えて何度も試すのではなく、最初に「自分はどのプロパティに、どの権限を持っているか」を API に一覧で出してもらうことです。

2-1. 手順1：自分の権限の一覧を出す

Search Console API には、自分が登録しているプロパティと、その権限の段階を一覧で返してくれる仕組み（sites().list）があります。Python（プログラムの言葉の1つ）だと、次の数行で一覧が出ます。筆者の環境で実際に動かして、結果が出ることを確かめたものです（2026年10月18日）。

from google.oauth2.credentials import Credentials
from googleapiclient.discovery import build

creds = Credentials.from_authorized_user_file("token.json")  # ここを自分の認証ファイル名に書き換える
service = build("searchconsole", "v1", credentials=creds)
for s in service.sites().list().execute().get("siteEntry", []):
    print(s["siteUrl"], s["permissionLevel"])

自分でコードを書かない人は、Claude Code に次のように頼めば同じことをしてくれます。

Search Console API の sites().list を使って、
今の認証で見えるプロパティの siteUrl と permissionLevel を一覧で出してください。
データの取得や設定の変更はしないで、一覧を出すだけにしてください。

「一覧を出すだけ」と書いておくのがコツです。原因を調べる段階で、AI に設定を書き換えさせないためです。

2-2. 手順2：「permissionLevel」の値を読む

一覧の右側に出る permissionLevel が、そのプロパティでの自分の権限の段階です。API の説明ページには、次の4つの値が載っています（2026年10月18日現在）。

値	意味（名前から読める範囲）
`siteOwner`	所有者
`siteFullUser`	フルユーザー
`siteRestrictedUser`	制限付きユーザー
`siteUnverifiedUser`	確認されていないユーザー

なお、API の説明ページには値の一覧しかなく、1つずつの詳しい説明は見つかりませんでした。所有者・フルユーザー・制限付きユーザーの違いは、公式ヘルプの「所有者、ユーザー、権限の管理」に書かれています（2026年10月18日現在）。データを取るだけなら、まず siteOwner か siteFullUser が付いている行を探してください。

2-3. 手順3：権限がある行の siteUrl を、そのまま写して使う

一覧の中で siteOwner（または siteFullUser）になっている行の siteUrl を、一字一句そのままデータ取得の指定に使います。自分で打ち直すと、www や最後の「/」を落としやすいので、コピーして貼るのが安全です。

Claude Code に頼むなら、こう伝えます。

さっきの一覧で permissionLevel が siteOwner の行の siteUrl を、
そのまま siteUrl に指定して、直近7日のクリック数を取ってください。

2-4. 手順4：正しく直ったかの確かめ方

確かめ方は簡単で、同じ期間のデータを取って、403 ではなく数字が返ってくれば成功です。さらに、Search Console の画面で同じ期間・同じプロパティの数字を見て、だいたい一致しているかを見比べると安心です。

権限がある行が1つもない場合は、書き方の問題ではありません。Search Console の画面でそのプロパティの所有権の確認をやり直すか、所有者に「設定」→「ユーザーと権限」から追加してもらう必要があります（追加できるのは所有者だけ、と公式ヘルプにあります）。

社長：「一覧を出すだけで原因が分かるなら、最初からそうすればよかったな。」

凛：「書き方をあてずっぽうで変えて何度も試すより、ずっと早いでしょ。」

策：「一覧には正解の書き方がそのまま載っています。推測で直すより、API に『あなたは何を持っていますか』と聞く方が、早くて確実です。」

PR / アフィリエイトリンク

3. 筆者の場合：sc-domainを指定して403、URLプレフィックスに変えて解決

ここからは、筆者が実際にはまった記録です。2026年10月17日、ブログのアクセスが少し伸びた気がしたので、Claude Code に「Search Console API から日別のクリック数を集計して」と頼みました。

siteUrlをsc-domainからURLプレフィックスに変えて403が解消した変更前と変更後の比較図

3-1. 最初に出たエラー

Claude Code は、プロパティを sc-domain:example.com（ドメインプロパティの書き方）で指定してデータを取りに行きました。返ってきたのは、次の 403 でした（サイト名は example.com に置き換えています。2026年10月18日に同じ指定でもう一度試し、同じエラーになることを確かめました）。

HttpError 403 ... returned "User does not have sufficient permission
for site 'sc-domain:example.com'."

筆者の Search Console の画面では、そのサイトのデータは普通に見えていました。画面では見えるのに API では断られる、というのがこのエラーの分かりにくい所です。

3-2. 一覧を出したら答えが書いてあった

原因を調べるために、Claude Code に sites().list で権限の一覧を出してもらいました。出てきた一覧が、これです（2026年10月18日に出し直した結果。ほかのサイトの行は省いています）。

https://example.com/      siteOwner
sc-domain:example.com     siteUnverifiedUser

同じサイトなのに、URLプレフィックス（https://example.com/）では所有者、ドメイン（sc-domain:example.com）では「確認されていない」扱いでした。筆者は最初に URLプレフィックスでサイトを登録して所有者になっていて、ドメインプロパティの方は所有権の確認が済んでいなかった、と考えられます（これは筆者の推測で、いつ追加したのかの記録は残っていません）。

3-3. 1行を直して解決

直したのは、データ取得のときの指定1行だけです。

	指定した siteUrl	結果
変更前	`sc-domain:example.com`	403（権限がない）
変更後	`https://example.com/`	日別のクリック数・表示回数が取れた

認証のやり直しも、Search Console の設定変更もしていません。書き方を、権限がある方に合わせただけです。

社長：「権限は最初からあったんだ。頼む宛先を間違えてただけだったのか。」

凛：「エラーの文面だけを信じて『権限を足す方法』を探していたら、遠回りしてたわね。」

策：「エラーの文面は、本当に権限がない場合と同じです。だから文面ではなく、一覧の『実物』を見て判断するのが大事でした。」

Claude：「変えたのは siteUrl の1行だけです。認証と Search Console の設定には触れていません。」

4. つまずきやすい点と避け方

筆者がつまずいた所と、調べる中で見つけた注意点をまとめます。

4-1. エラーの文面だけで判断しない

403 の文面は、原因が違っても同じです。「権限がない」と書いてあっても、権限そのものではなく書き方の違いのことがあります。まず一覧を出す、を最初の一手にしてください。

4-2. AI に「直して」ではなく「原因を調べて」と頼む

「エラーを直して」とだけ頼むと、AI は書き方を変えては試す、を繰り返すことがあります。「直さなくていいので原因を調べて」と頼むと、一覧を出すような調べる作業から始めてもらいやすくなります。

4-3. URLの写し間違いに気をつける

URLプレフィックスは、https:// と http://、www の有無、最後の「/」の有無で別のプロパティになります。一覧からコピーして使えば、この写し間違いは起きません。

4-4. 認証に使った Google アカウントを確かめる

複数の Google アカウントを持っている人は、Search Console に登録したアカウントと、API の認証に使ったアカウントが違っていないかも確かめてください。違うアカウントだと、一覧に目的のサイトが出てきません。

社長：「Googleアカウントを何個も持ってる人は、これもやりそうだな。」

凛：「一覧にサイトが1つも出なかったら、まずアカウント違いを疑いなさい。」

策：「一覧に出るかどうかで、『アカウントの問題』か『書き方の問題』かを切り分けられます。」

5. よくある質問

Q1. ドメインプロパティとURLプレフィックス、どちらで登録し直すべき？

A: 公式ヘルプでは、ドメインプロパティは http と https、サブドメインをまとめて集計できる、とされています（2026年10月18日現在）。ただ、API でデータを取るだけなら、すでに所有者になっている方の書き方を使えば十分です。筆者は登録し直さず、URLプレフィックスのまま使っています。

Q2. 「Request had insufficient authentication scopes」というエラーは同じ原因？

A: 別の原因です。こちらは、認証のときに Search Console 用の許可（スコープ）を付けていないときに出るエラーです。筆者のツールは読み取り専用の許可（https://www.googleapis.com/auth/webmasters.readonly）で認証しています。

Q3. siteUnverifiedUser のプロパティでデータを取る方法はある？

A: 筆者の環境では、siteUnverifiedUser の sc-domain: 指定ではデータが取れず、403 になりました。そのプロパティで取りたい場合は、Search Console の画面で所有権の確認を済ませる必要があると考えられます。ドメインプロパティの確認は、公式ヘルプによると DNS レコードの確認だけです。

Q4. 一覧を出すだけで、何かが変わってしまうことはない？

A: sites().list は、登録の一覧を読むだけの仕組みです。筆者も一覧を出しただけで、Search Console 側の設定は何も変わっていません。不安なら、Claude Code への指示に「データの取得や設定の変更はしない」と書いておくと安心です。

6. まとめ：403は「一覧を出す→権限がある行をそのまま使う」で直る

Search Console API の 403「User does not have sufficient permission」は、権限が本当に足りない場合だけでなく、プロパティの書き方が、権限を持っている方と違う場合にも出ます。

sites().list で、自分のプロパティと権限（permissionLevel）の一覧を出す
siteOwner か siteFullUser の行を探す
その行の siteUrl を、コピーしてそのまま指定に使う
数字が返り、画面の数字とだいたい合えば完了

権限がある行が1つもないときは、書き方ではなく所有権の確認か、アカウント違いの問題です。その場合は Search Console の画面側で確認してください。

次に読むべき記事

社長：「403が出ても、もう慌てないぞ。まず一覧だな。」

凛：「エラーの文面より、目の前の実物を見る。それはAPIに限らない話よ。」

策：「一覧を出す指示文は、そのままコピーして使えます。困ったときはここから始めてください。」

※ 本記事はAI（Claude）を用いて執筆しています。出典と確認日は該当箇所に記載しています。 ※ 本記事にはアフィリエイトリンクが含まれます。

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！