Google が Search Console の「生成AIパフォーマンスレポート」を発表したのは 2026年6月3日で、この記事を書いている 8月17日の時点でも、公式ヘルプは「一部のサイト所有者に展開中」と書いたままになっている。AI Overviews と AI モードの中でページが表示された分を、専用の画面で切り出して見られるレポートだ。ただ、出てくる指標は表示回数だけで、クリックも掲載順位も検索クエリも入らない。そして発表記事を読むと、この数字は通常の検索パフォーマンスにすでに含まれていると書いてある。足し算してはいけない数字だった。当サイトの28日ぶんを API で取ると表示 398・クリック 11 で、生成AI ぶんはこの 398 の中に混ざっている。切り出す口は API に無く、5通りの type を投げて全部 400 で弾かれた。
目次
発表は6月3日、展開はいまも一部サイト
週次の情報収集がこの件を拾ってきたとき、要約には「8月中旬に全プロパティへ展開された」と書いてあった。一次ソースを2本当たると、そうは書いていない。
Google 検索セントラルの発表記事（2026年6月3日）は、こう書いている。
We are rolling these reports out to a subset of websites, allowing us to thoroughly test them and receive feedback before making them widely available.
出典: Introducing Search Generative AI performance reports in Search Console（Google 検索セントラル ブログ）
公式ヘルプ側も、本稿執筆時点で「一部のサイト所有者に展開中」という注記と、「すべてのプロパティがレポートを使えるわけではない」という記述を残している。全プロパティへの展開を示す記述は、どちらにも見当たらなかった。
この違いは、読者の行動を変える。全プロパティに来ているなら「画面に無い＝自分のサイトは生成AIに出ていない」と読める。段階展開なら、同じ「画面に無い」に別の意味が混ざる。要約の一言を確かめずに書くと、あとで結論ごと外れる。
指標は表示回数の1つだけ。残り4つは分割軸
このレポートで見られるものを、公式ヘルプの区分どおりに並べ直す。指標と分割軸を横並びで「5項目」と書くと、ページ数などが独立した数字として取れるように読めてしまう。
| 区分 | 内容 |
|---|---|
| 指標 | 表示回数のみ。定義は「生成AI機能の中で、自サイトへのリンクがユーザーに表示された回数」 |
| 分割軸 | ページ（リダイレクト後の最終 URL。通常のパフォーマンスレポートと同じく正規 URL に集約）／国／日付（日・週・月。すべて太平洋時間）／デバイス（デスクトップ・タブレット・モバイル） |
| 含まれない | クリック・CTR・掲載順位・検索クエリ |
| 対象機能 | AI Overviews と AI モード。Search Labs の実験のデータは含まない。この一覧は今後更新される見込みと明記されている |
「含まれない」の4つについて、ヘルプに「クリックは含まれない」と否定形で書いてあるわけではない。利用できる指標として表示回数しか挙げていないので、そこからの読み取りになる。断定の中身は同じでも、根拠の性質が違う点は書いておく。
抜けているものを並べると、SEO の判断でふだん使う数字がまとめて無い。クリックが無いので CTR（クリック数を表示回数で割って % で見る指標）は計算できない。掲載順位が無いので、表示回数が増えたときに順位が上がったのか対象クエリが増えたのかを分けられない。検索クエリが無いので、どの検索意図で引かれたのかも追えない。
通常の検索パフォーマンスと足し算してはいけない
本稿でいちばん効いたのが、発表記事のこの一文だ。
This data is included in the overall performance report, where it will continue to be tracked to give site owners an overview of the overall visibility of their site in Google Search.
公式ヘルプ側にも「このレポートはパフォーマンスレポート（検索結果）の Web 検索タイプのデータを含む」という記述があって、向きは揃っている。生成AI機能での表示は、通常の検索パフォーマンスとは別勘定で新設された枠ではない。もともと Web 検索タイプの中に入っていた分を、専用の画面で切り出して見せているだけだ。
実務でこれを間違えると、こうなる。通常の検索パフォーマンスで表示回数 10,000、生成AIレポートで 800 と出たとき、月次の記録に「合計 10,800」と書いてしまう。実際には 10,000 の中に 800 が入っている。増えたのは見え方であって、露出そのものではない。
記録するなら割合にする。10,000 のうち 800 が生成AI機能での表示なら 8% で、この比率が月ごとにどう動くかのほうが読める数字になる。
レポートが出ない理由は2つ。1つには下位の理由がある
「画面に無い」の読み方を、公式ヘルプの「Not seeing the report?」に合わせて整理する。挙がっているのは2つで、2つ目にだけ注記が付いている。
| # | 理由 | 下位の理由 |
|---|---|---|
| 1 | 段階展開がまだ自分のプロパティに届いていない | — |
| 2 | 生成AI機能での表示回数が足りていない | 自サイトを生成AI機能の対象から除外している場合がある。表示させたいなら、除外を解いて対象に含める設定に戻す |
2つ目の下位理由が地味に効く。生成AI機能への露出を絞る設定を過去に入れていると、露出が少ないのは当然で、レポートも出ない。それを「まだ展開が来ていない」と読むと、原因を1つ取り違えたまま待ち続けることになる。しきい値の具体的な数値は公開されていないので、そこは待つ以外にない。
API では取れない
当サイトは Search Console を API 経由で叩く運用を持っていて、URL 検査と検索パフォーマンスの取得はスクリプトから回している。生成AIパフォーマンスに対応するものが API 側にあるか、リファレンスを読んだうえで実際に叩いて確かめた。
リファレンス上、type パラメータが取る値は web（既定）・image・video・news・discover・googleNews の6つで、生成AI用の値は載っていない。ただ、載っていないことと受け付けないことは別だ。未文書の値が通る可能性は残るので、それらしい名前を5通り投げた。
$ python scripts/gsc_api.py perf --days=28
site=https://bugattialpha.com/ 期間=2026-07-19..2026-08-15 (28日・反映遅延 2日を控除)
※ sc-domain: プロパティがあればそちらが優先される。画面を開くときは上の siteUrl と
同じプロパティを選ぶこと（別プロパティの数字と比率を取ると意味が変わる）。
既定(type省略) 表示 398 クリック 11 CTR 2.76% 平均掲載順位 8.31
type=web 表示 398 クリック 11 CTR 2.76% 平均掲載順位 8.31
searchAppearance で分けた行数（この軸から生成AI分を拾えるか）:
0 行
生成AI 用 type の受理可否:
type=aiOverview 拒否 HTTP 400: Invalid value at 'type' (type.googleapis.com/google.searchconsole.v1.searchanalytics.SearchType), "aiOverview"
type=aiOverviews 拒否 HTTP 400: Invalid value at 'type' (type.googleapis.com/google.searchconsole.v1.searchanalytics.SearchType), "aiOverviews"
type=aiMode 拒否 HTTP 400: Invalid value at 'type' (type.googleapis.com/google.searchconsole.v1.searchanalytics.SearchType), "aiMode"
type=generativeAi 拒否 HTTP 400: Invalid value at 'type' (type.googleapis.com/google.searchconsole.v1.searchanalytics.SearchType), "generativeAi"
type=ai 拒否 HTTP 400: Invalid value at 'type' (type.googleapis.com/google.searchconsole.v1.searchanalytics.SearchType), "ai"400 の本文に列挙型の名前まで出るので、受け付ける値が固定であることが読み取れる。拒否 と表示するのは 400 のときだけにしてある。401 や 429 を拒否と数えると、トークンの失効やクォータ超過を「生成AI用の値は存在しない」という仕様の結論にすり替えてしまうからだ。400 以外が返ったときは判定不能として探査を打ち切る。
指定を省いたときと type=web の結果が1桁まで一致しているのも、ここで確かめておきたかった点だ。既定が web であることの裏づけになり、この 398 という表示回数の中に生成AI機能ぶんが混ざっていると言える。分母は API で取れて、分子だけが取れない。
切り出しに使えそうなもう1つの軸が searchAppearance で、リッチリザルトの種類ごとに分けられる。同じ期間で分けたら0行だった。この軸に該当する結果が1件も無いという意味で、当サイトに関してはここからも拾えない。他サイトで AI Overviews がこの軸に出るかどうかは、自分のプロパティが空なので確かめられていない。
プロパティの選び方に1つ落とし穴がある。上のスクリプトは、ドメインプロパティ（sc-domain:）があればそちらを優先する。当サイトはいま URL プレフィックスしか持っていないので https://bugattialpha.com/ が選ばれているが、あとからドメインプロパティを追加すると同じコマンドが黙って別プロパティを測り始める。398 という基準がその時点で比較できなくなるので、出力の site= 行ごと記録しておく。画面を開くときも同じプロパティを選ぶ。分母と分子が別プロパティから来たら、比率に意味が無くなる。
画面にしか無いので、この指標だけ手作業の月次記録になる。レポート画面にはエクスポートボタンがあって、グラフと表の両方を落とせる。数値が ~ や - で表示されている箇所は、ダウンロードすると 0 になる点だけ覚えておくといい。
自動で積めない数字は、積むのを忘れた月から欠測になって、半年後に見返したときに使えない。利用状況の可視化ダッシュボードを判断材料にできるかを考えた回でも、自分で日次を積める形かどうかを気にしていた。取り込み経路の無い指標は、見た日にしか存在しない。
開く前に記録の枠を決めておく
数字を見てから記録項目を決めると、都合のいい期間を選んでしまう。表示回数は日ごとの振れが大きく、期間の取り方1つで「増えた」にも「減った」にもできる。分母は先に埋まったので、残りの枠を固めておく。
測定日 画面を開いた日
プロパティ perf 出力の site= 行をそのまま書き写す（今回は https://bugattialpha.com/）。
画面も必ず同じプロパティで開く。違うと分母と分子が別物になる
測定期間 締め日固定の28日（前月末日を締めとする直近28日。毎回同じ規則で取る）
比較用（実測済）2026-07-19..2026-08-15 の Web タイプ = 表示 398 / クリック 11 /
CTR 2.76% / 平均掲載順位 8.31（API から取得。生成AI分を含む）
レポート有無 出た / 出ない（出ない場合は理由の候補も書く）
表示回数 合計
上位ページ 上位5件と各表示回数
国・デバイス 偏りがあれば上位のみ
生成AI比率 生成AI表示回数 ÷ 同期間の Web タイプ表示回数（足し算はしない）
比較用の行だけ先に埋まったのは、そこが API から取れるからだ。分母を固定しておくと、画面を開いた日に書き写すのは分子だけで済む。仮に生成AI側が 40 と出たなら 398 のうち約10%、4 なら約1%。398 に足して 438 と書いてはいけないという一点さえ守れば、あとは月次で比率を並べるだけになる。
期間を28日にするのは、通常の検索パフォーマンスと同じ物差しにするためだ。生成AI側だけ90日で取ると、数字が大きく見えるだけで比較にならない。上位ページを5件に絞るのも同じ理由で、全ページを写すと差分を追う手間が続かず、翌月の記録が抜ける。
締め日を固定するところが、あとから直せない部分になる。Search Console のデータには反映の遅れがあり、最新のデータは暫定値としてグラフに点線で示される。締めをその都度「今日から28日前」で取ると、月ごとに遅れの影響の受け方が変わって、増減の一部が反映遅れで説明できてしまう。締め日を月末や特定の曜日に固定しておくほうが、翌月と並べたときに読める。
表と期間の制限は通常のパフォーマンスレポートと同じで、1,000行の上限もそのまま適用される。上位5件だけ写す運用なら、この上限に当たることはまずない。
一次ソース
- Introducing Search Generative AI performance reports in Search Console（Google 検索セントラル ブログ・2026年6月3日）
- 生成AIパフォーマンスレポート（Search Console ヘルプ・公式）
- Search Analytics: query（Search Console API リファレンス）
関連記事
現時点の判断
指標の構成から見て、このレポートは施策の合否判定には使えない。クリックと順位が無い以上、タイトルや meta description を書き換えた効果をここで測れないからだ。
使い道として残すのは2つ。月次で表示回数の推移と生成AI比率を記録する観測欄と、「どのページが生成AI機能に出ているか」というページ単位の確認。ページ単位のほうは、記事の題材を選ぶときの材料になる。生成AI機能に一度も出ていないページ群と、繰り返し出ているページ群があるなら、書き方や構成に違いがある可能性を疑える。疑いをこのレポートの中で検証する手段は無いので、あくまで疑いを持つきっかけとして使う。
同じ形で使う読者への最初の一手は、開き方より先に期間の固定になる。通常の検索パフォーマンスで使っている期間と揃えて開き、表示回数の合計と上位ページだけを書き留めて閉じる。1回目の数字には比較対象が無いので、そこから何かを結論づけようとしないほうがいい。判断できるのは2回目の記録が溜まってからだ。
測った範囲と、測っていない範囲を分けておく。測ったのは API 側だ。当サイトの Web タイプ28日ぶん（表示 398 / クリック 11 / CTR 2.76% / 平均掲載順位 8.31）、type 省略と type=web の一致、生成AI 用と思われる5つの type が 400 で弾かれること、searchAppearance で分けると当サイトは0行になること。ここまでは実行結果がある。
測っていないのは画面側になる。レポートが自分のプロパティに出ているかどうかを、まだ見ていない。したがって生成AI機能での表示回数も、その比率も、上位ページも本稿には無い。分母だけ先に確定して、分子を空けたまま出している。次に画面を開いたときの結果は、出た場合も出なかった場合も、理由の候補つきで追記する。
