GSC「生成AIレポート」にロギングバグ、8/13〜17分のインプレッションが過少計上

GSC「生成AIパフォーマンスレポート」でロギングバグ発生——8月13〜17日分のインプレッションが過少計上、Googleは「可視性の変化ではない」と説明

要点: Google Search Consoleの「生成AIパフォーマンスレポート(検索)」で、2026年8月13日〜17日分のデータについてロギング(データ記録)エラーが発生し、インプレッション数が実際より少なく表示される問題が起きた。Googleは公式ヘルプページで「これはデータロギングのみに影響する問題」と説明し、John Mueller氏も「検索での可視性の変化を示すものではない」とコメントしている。

展開されたばかりの新機能で早速データ異常が起きたという事実は、AI検索での自社露出を測る数少ない公式データソースを日々参照しているLLMO/SEO担当者にとって軽視できない実務ニュースだ。本記事では何が起きたのかを整理した上で、パニックにならずに済む理由と、それでも軽視してはいけない理由、そして今すぐ取るべき具体的な対応策を解説する。

最終更新日: 2026年8月27日

---

何が起きたのか

ロギングエラーの内容とGoogle公式の説明

Google Search Consoleのヘルプページ「Data anomalies in Search Console(Search Consoleにおけるデータ異常)」に、2026年8月に新たな異常事例が追記された。該当の記述は次の通りである。

"A logging error caused a decrease in impressions on the Generative AI performance report in Search for data from August 13 - August 17, 2026. This issue affects data logging only." (ロギングエラーにより、2026年8月13日〜8月17日分のデータについて、検索における生成AIパフォーマンスレポートのインプレッション数が減少しました。この問題はデータロギングのみに影響します。)

出典: Google Search Console Help「Data anomalies in Search Console」

このページはGoogleがSearch Console上で確認されたデータ異常を公式に記録・告知するためのもので、過去にも複数のバグ・異常が同様の形式で記載されてきた実績がある(詳細は後述の「Search Consoleの過去のデータ異常事例との比較」セクションで扱う)。今回のポイントは、Googleが原因を「ロギングエラー」、つまりデータを記録する仕組み側の不具合と明言している点だ。検索結果におけるサイトの実際の表示回数(可視性)そのものが減ったわけではなく、その表示回数を集計・記録する過程でカウント漏れが発生した、という切り分けになる。

また、影響範囲についても「この問題はデータロギングのみに影響する」と明記されており、生成AIパフォーマンスレポート以外の通常のSearch Consoleパフォーマンスレポート(通常のウェブ検索、Discoverなど)には影響しないことが示されている。あくまで、2026年8月11〜12日頃に事実上グローバルに全展開されたばかりの新機能である「生成AIパフォーマンスレポート」限定の問題であり、対象期間も8月13日〜17日の5日間に限定されている点は、影響範囲を判断する上で重要な事実だ。

John Mueller氏のコメント

GoogleのSearch Advocateを務めるJohn Mueller氏は、SNS「Bluesky」上でこの件について次のようにコメントしたと報じられている。

"We're aware of this issue and working on resolving it. This is just a logging issue and not representative of visibility changes in Search." (この問題を認識しており、解決に向けて対応中です。これは単なるロギングの問題であり、検索における可視性の変化を表すものではありません。)

Mueller氏はあわせて、Search Console内に今回のデータ異常についての注記(アノテーション)を追加する予定であることも表明している。アノテーション機能は、Search ConsoleのパフォーマンスレポートのグラフにGoogle公式のメモを重ねて表示できる仕組みで、これが実装されれば、実務担当者がグラフ上の数値変動を見た際に「これはGoogle側の既知の問題である」と即座に判断できるようになる。現時点(2026年8月27日)ではこのアノテーション追加が実際にレポート画面へ反映されたかどうかの続報は確認できていないが、Googleが単に口頭・ヘルプページでの説明に留めず、UI上での恒久的な注記という形での対応を計画している点は、今回の問題への対応姿勢として押さえておきたい。

報道の経緯

この問題は業界メディアによって複数報じられている。Search Engine Landは「Google Search Console Generative AI Performance Report in Search data bug」と題する記事で、Googleの公式説明とMueller氏のコメントを取り上げている(Search Engine Land)。あわせて、SEO業界で定評のあるSearch Engine Roundtableもこの件を報じており、Search Console利用者の間で早い段階から話題になっていたことがうかがえる。

実務者向けの分析記事も相次いで公開された。Digital Appliedは「Search Console Is Undercounting. Snapshot the Range Now」という記事で、今回のバグの実務対応として、データのスナップショット取得を強く推奨する内容を発信している(Digital Applied)。また、Mediology Softwareは「Google Search Console Generative AI Report Bug Explained」という記事で、SEO担当者・パブリッシャーにとってこの問題がなぜ重大な懸念事項なのかを整理している(Mediology Software)。

新機能展開の直後に起きたバグという文脈

生成AIパフォーマンスレポートは、Google検索のAI Overviews・AI Mode経由でのサイトの表示(インプレッション)・クリックをSearch Console上で計測できる機能であり、当サイトの既報の通り、2026年8月11〜12日頃に事実上グローバルに全展開されたばかりの、まだ日が浅い新機能である(詳細は「GSC生成AIパフォーマンスレポートが世界展開」の既報記事を参照)。全展開から1〜2週間というごく初期のタイミングでロギングバグが表面化したことになる。新機能のローンチ直後に計測系のバグが起きること自体は、大規模なシステムにおいてはそれほど珍しいことではないが、まさにこのレポートを「AI検索での自社露出を測る数少ない公式データソース」として使い始めたばかりの実務者にとっては、タイミング的に印象に残りやすい出来事だったと言える。

---

aiseo-llmo.com ユーザーへの影響

なぜこのバグが重要なのか

aiseo-llmo.comを利用するLLMO/AI検索対策の担当者にとって、生成AIパフォーマンスレポートは特別な位置づけを持つデータソースだ。AI Overviews・AI Mode経由での自社サイトの露出状況を直接的に確認できる手段は現時点では限られており、多くの現場でこのレポートが「AI検索での可視性を測る唯一に近い公式データ」として扱われている。ChatGPTやPerplexityなど他の生成AI検索サービスでは、そもそも公式のパフォーマンス計測ダッシュボードが提供されていないケースが多く、Google検索のAI Overviews・AI Modeについて公式データが見られるという点自体が、このレポートの価値の核心にある。

そのデータ基盤で計測不具合が起きたというニュースは、単なる技術トラブルの報告ではなく、「自社の施策の効果測定・週次/月次レポーティングの信頼性」に直結する実務的な重要性を持つ。もし8月13日〜17日のインプレッション数の落ち込みを「AI Overviewsでの自社露出が減った」と早合点し、原因分析や対策の見直しに工数を割いてしまえば、それは実在しない問題への対応に時間を浪費することになる。Mediology Softwareの分析記事が指摘する通り、この種の誤解によるリスクは大きく分けて二つある。一つは、実際には可視性が変わっていないにもかかわらず「AI検索での露出が減少した」と誤解し、クライアントや経営層に不正確な報告をしてしまうリスク。もう一つは、存在しない問題の原因究明に時間を浪費するリスクだ(Mediology Software)。

パニックにならなくていい理由

まず押さえておくべきは、Google自身が「ロギングのみの問題であり、可視性の変化を示すものではない」と明言している点だ。John Mueller氏のコメントも同じ趣旨であり、Googleが公式ヘルプページに明記した以上、これは非公式の噂や推測ではなく、Google側が正式に認めた事実である。したがって、8月13日〜17日の期間だけインプレッション数が落ち込んでいるように見えても、それをもって自社の施策が失敗した・AI Overviewsでの評価が下がったと判断するのは早計であり、この期間のデータ単体に基づいた結論を出すべきではない。

影響範囲も限定的だ。生成AIパフォーマンスレポート以外の通常検索・Discoverなどのレポートには影響が及んでおらず、対象期間も5日間に限られている。全体のトレンドを見る際には、この5日間を除いた前後の期間のデータと比較することで、実質的な影響を最小限に抑えることができる。

それでも軽視してはいけない理由

一方で、この件を「よくあるバグの一つ」として軽く流してしまうことにもリスクがある。Digital Appliedの分析記事が指摘している重要な事実として、Search Consoleでは過去にも類似のロギングバグが発生しており、2025年5月から2026年4月頃までの約50週間分のデータが影響を受けたが、バグ修正後もその期間の過去データは遡及的に復元されなかった、という前例がある(Digital Applied)。

この前例が示唆するのは、「Googleがバグを認めて修正すれば、過去のデータも正しい値に修正される」という期待は必ずしも正しくない、ということだ。ロギングエラーによって記録されなかったデータは、ロギングという行為自体が「起きなかった」ことを意味する場合があり、修正後にさかのぼって正しい値を再構成できるとは限らない。今回のケースでも、Googleが「これはロギングのみの問題」と説明していることと、修正後に8月13日〜17日分のデータが遡及的に正しい値へ更新されるかどうかは、別の問題として捉えておく必要がある。

さらに、Search Consoleのデータ保持期間はおよそ16ヶ月に限られている。仮に将来、生成AIパフォーマンスレポートで別のロギング異常が発生し、それが今回よりも長期間・広範囲に及んだ場合、保持期間の制約と相まって、正確な過去データを再取得する手段が失われるリスクがある。「今回は5日間だけの小さな問題だったから大丈夫」と楽観視するのではなく、こうした計測基盤の不安定さそのものを、AI検索領域のレポーティングにおける構造的なリスクとして認識しておくことが、実務上は重要になる。

AI Overviews / AI Mode経由の計測が他の指標より不安定になりやすい構造的背景

なぜ生成AIパフォーマンスレポートは、通常の検索パフォーマンスレポートと比べてこうした計測トラブルが起きやすいのだろうか。いくつかの構造的な要因が考えられる。

第一に、機能自体がまだ新しいという単純な理由がある。生成AIパフォーマンスレポートは2026年8月11〜12日頃に全展開されたばかりであり、長年運用されてきた通常検索・Discoverのレポートと比べて、計測パイプラインの成熟度・テストカバレッジの蓄積が相対的に浅い。新機能のローンチ直後にエッジケースのバグが表面化するのは、大規模なプロダクト開発において一般的に起こりうることだ。

第二に、AI Overviews・AI Modeという表示形式自体の複雑さがある。通常の検索結果は「1つのURLが1つの検索結果として表示される」という比較的シンプルな構造だが、AI Overviews・AI Modeでは、1つの生成AI回答の中に複数のソースが引用され、その引用のされ方(本文中の直接引用か、参照リンク一覧への掲載か等)によって「インプレッション」としてカウントすべき事象の定義そのものが複雑になる。この複雑さは、ロギングロジックの実装難易度を引き上げ、バグの温床になりやすいと考えられる。

第三に、AI Overviews・AI Mode自体の表示ロジックがGoogle側で継続的に調整・実験されているという背景もある。生成AIによる回答の生成プロセス、引用元の選定ロジックは、通常の検索アルゴリズムと比べても変更頻度が高く、それに伴い計測系のコードも頻繁に更新されている可能性が高い。変更頻度の高いシステムほど、意図しない不具合が混入するリスクは相対的に高くなる。

こうした構造的背景を理解しておくと、今回のようなロギングバグが「一過性の珍しい事故」ではなく、「新しい計測基盤にはある程度織り込んでおくべきリスク」であることが見えてくる。これは今回のバグに限らず、今後も同種の計測トラブルが起こりうるという前提でレポーティング運用を設計しておくことの重要性を示唆している。

業種別・サイト規模別の実務インパクト

このバグの実務上の影響度は、サイトの規模やトラフィック特性によって濃淡がある。

大規模サイト・トラフィックの多いサイト

日々のインプレッション数が絶対値として大きいサイトほど、5日間の落ち込みが週次・月次のグラフ上で明確な「谷」として視覚的に目立ちやすい。特に週次レポートを経営層やクライアントに提出する運用を行っている場合、グラフの見た目のインパクトが大きく、質問や懸念の声が上がりやすい。トラフィックの多いサイトほど、瞬間的な数値のブレに反応しやすいという性質があるため、こうしたサイトの担当者は、今回のような既知のバグ情報を先回りして共有しておくことが望ましい。

中小規模サイト・ニッチ分野のサイト

そもそも生成AIパフォーマンスレポートに表示されるインプレッション数の絶対値が小さいサイトの場合、5日間の減少が全体のトレンドに与える視覚的なインパクトは相対的に小さく見えることがある。しかし同時に、サンプル数が少ないレポートは元々のブレ幅(ノイズ)が大きく、「本来の変動なのか、バグによる過少計上なのか」を判別すること自体が難しいという別の課題がある。小規模サイトの担当者は、そもそもレポートの数値の意味を読み違えやすい傾向があることを踏まえ、単月・単週の数値変動だけで一喜一憂しない姿勢がより重要になる。

代理店・複数クライアントを抱える運用者

複数クライアントのSearch Consoleデータを横断的に扱う代理店・コンサルタントにとっては、今回のような既知の異常情報を一括して把握し、影響を受けている全クライアントに同じ説明を提供できる体制を整えておくことが効率的だ。クライアントごとに個別に問い合わせを受けてから都度説明するのではなく、能動的に「8月13日〜17日のデータには既知のGoogle側の問題があります」という一文を定例報告に含めておくことで、無用な不安や問い合わせを未然に防ぐことができる。

EC・BtoB・メディアなど業種を問わない共通点

業種を問わず共通して言えるのは、生成AIパフォーマンスレポートがまだ運用実績の浅い新しい計測ソースである以上、単一の指標・単一の期間だけに依存した意思決定を避け、複数の期間・複数のデータソースを突き合わせて判断する運用を早い段階から定着させておくことの重要性だ。

---

今すぐできる対応策

1. Search Console UIでのデータエクスポート(スナップショット取得)

最も手軽で即座に実行できる対応は、Search Console UI上でのデータエクスポートだ。手順は以下の通り。

1. Search Consoleにログインし、対象プロパティを選択する
2. 左メニューから「検索パフォーマンス」の中の「生成AI」(生成AIパフォーマンスレポート)を開く
3. 画面上部の日付範囲を、確認したい期間(例えば直近16ヶ月分、あるいは少なくとも直近数ヶ月分)まで拡張する
4. 画面右上の「エクスポート」ボタンから、Googleスプレッドシートへの書き出し、またはCSV/Excelファイルとしてのダウンロードを選択する
5. クエリ別・ページ別・日付別など、必要なディメンションの切り口でそれぞれエクスポートしておく

このエクスポート作業を、バグの有無にかかわらず定期的なルーティンとして組み込んでおくことが、Digital Appliedの記事が推奨する「スナップショットを今すぐ取っておく」という助言の実務的な意味だ。Search Consoleのデータ保持期間はおよそ16ヶ月と有限であり、UI上のグラフをその都度眺めるだけでは、過去のデータが保持期間の外に出た時点で参照できなくなる。ロギングバグの有無を問わず、生データを自社側で保存しておくことは、レポーティングの継続性を担保する基本的な備えになる。

2. Search Analytics APIでのスナップショット取得

より大規模・網羅的にデータを保存したい場合は、Search Analytics API(Search Console API)を使ったプログラム的なデータ取得が適している。API経由でのスナップショット取得のポイントは以下の通り。

• 1回のAPIリクエストで取得できる行数の上限は25,000行である
• 対象期間・対象クエリ数が多く25,000行を超える場合は、リクエストパラメータのstartRowを使ってページング処理を行い、複数回のリクエストに分割して全データを取得する(例: 1回目はstartRow=0、2回目はstartRow=25000、3回目はstartRow=50000というように、25,000行ずつオフセットをずらしながら取得を繰り返す)
• 生成AIパフォーマンスレポートのデータをAPI経由で取得する際は、対象の検索タイプ(searchType)のパラメータ指定を確認し、通常のウェブ検索用のクエリと混同しないようにする
• 取得したデータは、日付・クエリ・ページ・デバイスなどのディメンションを保持したまま、社内のデータベースやBigQueryなどのデータウェアハウスに蓄積しておくと、後から柔軟に集計・比較ができる
• 定期実行するバッチ処理として組んでおけば、手動でのエクスポート作業を毎回行う必要がなくなり、日次・週次でのスナップショット取得を継続的に自動化できる

Discoverレポートについても同様の考え方でスナップショットを取得しておくことが望ましい。Digital Appliedの記事も、生成AIレポートとDiscoverレポート双方の生データをスナップショットとして保存しておくべきだとアドバイスしている。Discoverレポートも生成AIパフォーマンスレポートと同様、比較的新しく変動の大きいレポートであり、同種のロギング異常が将来発生する可能性を踏まえた備えとして有効だ。

3. 社内ダッシュボードへの注記(アノテーション)

スナップショットを取得するだけでなく、社内のダッシュボードやレポートテンプレートに「いつ・どの指標が異常だったか」を明記した注記を残しておくことも重要だ。Digital Appliedの記事は、こうした注記を残しておくことで、数か月後に同じ数値を見た担当者が誤解するのを防げると助言している。

注記の書き方の一例としては、次のような形式が実用的だ。

【既知の問題】2026年8月13日〜8月17日の生成AIパフォーマンスレポートのインプレッション数は、Google側のロギングエラーにより実際より過少に表示されている可能性があります。Google公式説明: https://support.google.com/webmasters/answer/6211453?hl=en (「Data anomalies in Search Console」内に記載)。この期間の数値を前後の期間と単純比較しないでください。

このような注記を、ダッシュボードのグラフ上の該当箇所に添えるコメント機能や、レポート資料の脚注として残しておくことで、後任者や他部署のメンバーが同じ数値を見たときに、過去の経緯を知らないまま誤った解釈をしてしまうリスクを減らせる。

4. レポーティング時の注意点

クライアントや経営層への定例報告では、以下の点に注意したい。

• 8月13日〜17日のデータに基づいた単独の結論を出すことを避ける。トレンドの評価は、この期間を除いた前後のデータ、あるいは同期間の他指標(クリック数・掲載順位など、影響を受けていない指標)とあわせて総合的に判断する
• 報告資料には、この期間が「既知のバグ」であることを明記する。Google公式の説明ページへのリンクを添えておくと、報告先が自分で一次情報を確認でき、説明の信頼性が高まる
• Googleが今後追加を予定しているアノテーション機能(Search Console UI上での公式注記)が実装された場合は、その情報も定例報告のテンプレートに反映し、以後は都度手動で説明を加える手間を減らせるようにしておく
• 生成AIパフォーマンスレポートは全展開からまだ日が浅い機能であるため、単月・単週の数値だけで一喜一憂せず、複数ヶ月にわたるトレンドで評価する運用を基本方針として定着させる

---

よくある質問

Q1. 今回のGSCロギングバグは具体的にいつのデータに影響したのか?

Google Search Consoleの生成AIパフォーマンスレポートにおける2026年8月13日〜8月17日の5日間分のデータで、インプレッション数が実際より過少に計上された。Googleの公式ヘルプページ「Data anomalies in Search Console」に明記されている。

Q2. このバグは通常の検索パフォーマンスレポートやDiscoverレポートにも影響しているのか?

Googleは「この問題はデータロギングのみに影響する」と説明しており、影響は生成AIパフォーマンスレポートに限定されている。通常のウェブ検索のパフォーマンスレポートやDiscoverレポートには影響していないとされる。

Q3. インプレッション数が減って見えるのは、実際にAI Overviewsでの自社露出が減ったということか?

いいえ。Google公式の説明およびJohn Mueller氏のコメントによれば、これは純粋なデータロギング(記録)の問題であり、検索における実際の可視性・パフォーマンスの変化を示すものではない。8月13日〜17日のインプレッション数の落ち込みを、実際の露出減少と解釈するのは避けるべきだ。

Q4. Googleはこの問題についてどのように対応すると表明しているか?

John Mueller氏はBluesky上で「認識しており解決に向けて対応中」とコメントし、あわせてSearch Console内に今回のデータ異常についての注記(アノテーション)を追加する予定であることも表明している。記事執筆時点で、このアノテーションが実際にレポート画面へ反映されたかどうかの続報は確認できていない。

Q5. 8月13日〜17日の過去データは、修正後に正しい値へ遡及的に更新されるのか?

現時点でGoogleはその点について明言していない。留意すべき前例として、過去にも類似のロギングバグが発生し、2025年5月〜2026年4月頃までの約50週間分のデータが影響を受けたが、バグ修正後もその期間の過去データは遡及的に復元されなかった、という事例がある。今回も同様に、過去データが修正されない可能性を念頭に置いておくべきだ。

Q6. 自社サイトが今回のバグの影響を受けているかはどう確認すればよいか?

Search Consoleの生成AIパフォーマンスレポートを開き、日付範囲を8月13日〜17日を含む形で表示し、その前後の期間と比較して不自然な落ち込みがないかを確認する。落ち込みが確認できても、それは今回報告されている既知のロギングバグによる可能性が高く、施策上の問題と即断しないことが重要だ。

Q7. 今後同じようなロギングバグが再発した場合に備えて、何をしておくべきか?

Search Console UIでのデータエクスポート、またはSearch Analytics APIを使った定期的なスナップショット取得を運用に組み込んでおくことが有効だ。Search Analytics APIは1リクエストあたり最大25,000行までしか取得できないため、対象データが多い場合はstartRowパラメータでページングしながら複数回リクエストする必要がある。加えて、Search Consoleのデータ保持期間はおよそ16ヶ月に限られる点も踏まえ、生データを自社側に保存しておく習慣を持つことが望ましい。

Q8. なぜAI Overviews / AI Mode経由の計測は、通常の検索指標よりも不安定になりやすいのか?

生成AIパフォーマンスレポート自体が2026年8月に全展開されたばかりの新機能であり、計測パイプラインの成熟度が相対的に浅いことが一因として挙げられる。また、AI Overviews・AI Modeでは1つの回答の中に複数のソースが異なる形で引用されるため、通常の検索結果と比べて「何をインプレッションとしてカウントするか」の定義自体が複雑になりやすく、ロギングロジックの実装難易度が上がる。加えて、AI Overviews・AI Modeの表示ロジック自体がGoogle側で継続的に調整・実験されており、変更頻度の高いシステムほど不具合が混入しやすいという構造的な背景もある。

Q9. クライアントや経営層への報告では、この件をどう扱えばよいか?

8月13日〜17日のデータに基づいた結論を出すことを避け、報告資料にはこの期間が「既知のバグ」であることを明記するのが望ましい。Google公式の説明ページへのリンクを添えておくと、報告先が一次情報を自分で確認でき、説明の信頼性が高まる。Googleが追加を予定しているSearch Console内のアノテーション機能が実装された場合は、その情報もあわせて報告に活用できる。

Q10. Search Consoleの「Data anomalies」ページとは何か?

Googleが公式にSearch Console上で確認されたデータ異常・不具合を記録・告知するためのヘルプページであり、URLは https://support.google.com/webmasters/answer/6211453?hl=en である。今回の生成AIパフォーマンスレポートのロギングバグもこのページに追記される形で公式に告知されている。過去のデータ異常についても同様の形式で記録されており、Search Consoleの数値に不自然な変動を見つけた際にまず確認すべき一次情報源となる。

---

関連記事

ピラー記事

• LLMOとは何か:AI検索最適化の完全ガイド — LLMOの基本概念からGEO・AIOとの関係まで体系的に解説した入門〜実践ガイド
• AI検索最適化ガイド — Google・Perplexity・ChatGPT検索を横断したAI検索最適化の全体戦略

クラスター記事

• GSC生成AIパフォーマンスレポートの使い方ガイド — レポートの見方・活用方法を体系的に解説
• GSC生成AIパフォーマンスレポート初報(2026年7月) — レポートが初めて確認された当初の経緯
• GSC生成AIデータの落とし穴(2026年8月) — マーケターが陥りやすいデータ解釈の注意点
• GSC生成AIパフォーマンスレポートが世界展開(2026年8月12日) — 今回のバグの前提となる全展開の経緯
• Search Consoleの基本 — Search Console全体の基礎知識
• AI Overview計測ツール比較 — 公式データ以外の計測手段の選択肢

用語集

• GSC(Google Search Console)とは — Search Consoleの基本機能・用語解説
• AI Overviewとは — Google AI Overviewsの仕組みと表示条件
• LLMOとは — LLM最適化の基本定義
• GEO(Generative Engine Optimization)とは — 生成AI検索エンジン最適化の基本概念
• GSCのAI掲載順位計測、Mueller氏「仕組み自体が今後も進化する」と発言