外資系SEOスペシャリスト
Takuma Oka (岡 拓馬)
こんにちは、岡 拓馬（おか たくま）です。
このブログでは、海外ノマド×SEO×ストック収入をテーマに、自分の経験や学びを発信しています。
高校卒業後は料理人としてスタートし、その後、航空自衛隊での勤務を経て、2016年からWebライター・SEOコンサルタントとして独立。現在は、海外の外資系企業と契約しながら、フルリモートで働いています。拠点はアジア各国を転々としており、最近はベトナムやタイ、マレーシア、フィリピンなどでノマド生活をしています。
サーチコンソール（GSC）のデータには、意外と知られていない致命的な仕様があります。保存期間が16ヶ月しかないということです。
つまり今日確認できる2年前のデータは、実はもう存在しません。
「去年の今頃と比べてどうだったか」を3年、5年と積み重ねて振り返りたければ、データは自分で貯めておくしかないのです。
この記事では、無料アドオン「Search Analytics for Sheets」を使って、GSCのデータをGoogleスプレッドシートに毎月自動で蓄積する手順を解説します。
Takuma実際に自分のブログ（当サイト）で設定しながら書いているので、解説記事によくある「手順通りに進めたのに画面が違う」「ボタンを押したのに反応がない」といったつまずきポイントも、実体験ベースでカバーしています。
なぜGSCの画面だけでは分析が破綻するのか
データは16ヶ月で消えていく
GSCの検索パフォーマンスレポートで遡れるのは最大16ヶ月です。ブログを2年、3年と運営していくと、初期のデータから順に消えていきます。
SEOの分析で本当に価値があるのは長期の推移です。
特に2025年以降、AI Overviewの拡大で「順位は維持しているのにクリックだけが減る」という現象が広く起きています。
Takumaこの変化を証明するには、変化が起きる前のデータが必要です。消えてからでは遅い。
画面からのエクスポートは1,000行まで
GSCの画面からCSVエクスポートできるのは上位1,000行までです。
記事数が増えてロングテールのクエリが数千件になると、画面上では全体像の一部しか見えません。
Search Analytics for Sheetsを使えば、無料プランでも1リクエストあたり25,000行まで取得できます。個人ブログならまず足ります。
Search Analytics for Sheets の導入
インストール手順
- Googleスプレッドシートで新規ファイルを作成（ファイル名は「GSC_バックアップ」など分かりやすく）
- 上部メニュー「拡張機能」→「アドオン」→「アドオンを取得」
- 検索窓に
Search Analytics for Sheetsと入力してインストール - GSCと連携しているGoogleアカウントでログインし、「許可」
ここで注意したいのが、アカウント選択です。
複数のGoogleアカウントを使い分けている場合、GSCのプロパティにアクセス権のないアカウントでインストールすると、後の手順でサイトが選択肢に出てきません。
【重要】解説記事の多くは旧UIです
「拡張機能」→「Search Analytics for Sheets」→「Open Sidebar」でサイドバーを開くと、メニュー画面が表示されます。
ここで戸惑うかもしれません。ネット上の解説記事の多くは「Request」「Backups」というタブ形式の旧UIで説明されていますが、現在のUIはメニュー選択式に変わっています。
対応関係は次の通りです。
| 旧UI | 新UI |
|---|---|
| Requestタブ | Search Console Requests |
| Backupsタブ | Recurrent Requests (Backups) |
古い記事を参考にしていて「Backupsタブがない」と迷ったら、Recurrent Requestsを探してください。
まずは単発でデータを取得してみる
自動化の前に、一度手動で取得して出力の形を確認しておくのがおすすめです。
サイドバーから「Search Console Requests」を選択し、以下を設定します。
- Verified Site: 対象サイトを選択
- Date Range: まずは直近1〜3ヶ月程度
- Group By:
QueryとPageの両方を指定 - Rows returned: Up to 25,000 rows
- Results Sheet: 出力先シート
Group ByにQueryとPageの両方を指定すると、「どのキーワードで、どのページに流入したか」の組み合わせが1行ずつ出力されます。
クエリ単体・ページ単体で集計すると数字の意味合いが変わってしまうため、蓄積用にはこの粒度が最も潰しが利きます。
「Request Data」を押すと、数十秒でQuery / Page / Clicks / Impressions / CTR / Positionの6列が出力されます。
つまずき①：「Sheet ID not found」エラー
実際にやってみると、初回取得後の再実行で赤いエラーが出ました。
Requesting data failed due to the following error: Error: Error sorting sheet: Sheet ID for sheet “Sheet1” not found.
一瞬焦りますが、すでに出力済みのデータには影響ありません。
同じシートに対して再実行したときにシートの内部参照がずれて起きるエラーのようで、再実行時はResults Sheetを「Create New Sheet」にするか、シートを一度開き直せば回避できます。
本題：毎月の自動蓄積を設定する（Recurrent Requests）
サイドバーのメニューから「Recurrent Requests (Backups)」を開きます。
設定項目は次の通りです。
- Choose site: 対象サイト
- Search Type: Default (Web)
- Choose recurrence interval:
Monthly (runs every 3rd of the month)— 毎月3日に前月分を取得。GSCのデータ確定には数日のラグがあるため、月初すぐではなく3日実行になっているのは理にかなっています - Group By: Query と Page
- Rows returned: Up to 25,000 rows
- Run a cycle right away: Yesに変更するのがおすすめ（理由は後述）
つまずき②：「Run a cycle right away」をNoのままにすると来月まで動作確認できない
この項目はデフォルトでNoになっています。Noのまま有効化すると、最初の実行は来月3日。設定ミスがあっても1ヶ月気づけません。
Yesにしておけば即座に1回実行され、その日のうちに動作確認ができます。設定できたら「Enable Backup」を押します。
自動蓄積の仕組み：シートが月ごとに増えていく
旧UIの解説記事では「Appendで同一シートに追記」という説明が多いのですが、現行版の挙動は違いました。
月ごとに新しいシートタブが自動生成されます。
実行すると「Jun 2026」のような月名のシートが作られ、そこに当月分のデータが格納されます。あわせて「Backup Log」というシートも自動生成され、実行履歴が記録されていきます。
1つのファイルに月次スナップショットが積み上がっていくイメージです。
これでも16ヶ月の壁を超えて蓄積するという目的は達成できますし、月ごとにシートが分かれている方が「◯月と◯月の比較」がしやすい側面もあります。
つまずき③：Enable Backupを押しても見た目が変わらない
これが一番戸惑ったポイントです。
「Enable Backup」ボタンを押しても、ボタンの色も表示も何も変わりません。成功したのか失敗したのか、ボタンからは判断できない仕様です。
確認方法は2つあります。
- Backup Logシートを見る — 「Retrieved data for Jun 2026 in the Jun 2026 sheet.」のような実行記録が追記されていれば、少なくともその回の実行は成功しています
- サイドバー上部のステータスバッジを見る — サイドバーを一番上までスクロールすると、「Recurrent request for current spreadsheet:」の下にバッジがあります。
ここが「Inactive」から「Active」に変わっていれば、月次スケジュールが有効化されています。
単発実行の成功（Backup Logへの記録）とスケジュールの有効化（Activeバッジ）は別物なので、必ず両方確認してください。
運用してわかった注意点
無効クエリのノイズが混ざる
Query×Page粒度で出力すると、srsltid のようなパラメータ由来の無効クエリも行として混ざってきます。
GSCの画面では目立ちませんが、生データを扱うと可視化されます。
集計時にはフィルタで除外する前提でいてください。
1シート（1ファイル）に設定できる自動化は1系統のみ
Recurrent Requestsは1つのスプレッドシートにつき1設定です。
「Query×Page」とは別に「Date×Query」の粒度でも貯めたい場合は、スプレッドシートファイル自体を分ける必要があります。
「完全放置」にはならない
自動化とはいえ、次の2点で定期点検は必要です。
- 認証切れ: Googleアカウントの認証は永続ではなく、数ヶ月単位で再認証が必要になることがあります
- セル数上限: スプレッドシートには1ファイル1,000万セルの上限があります。月2万行ペースで貯めると数年で上限が見えてくるため、年単位でファイルを分ける運用が現実的です
四半期に一度、Backup Logを見て実行が止まっていないか確認する。それだけで「気づいたら半年分欠損していた」という最悪の事態は防げます。
蓄積したデータで何が見えるようになるか
当サイトの場合、蓄積を始めた最大の動機はAI Overviewの影響の定点観測です。
実際、直近1年で平均掲載順位は大きく改善している一方、クリック数は減少しています。
順位とクリックが逆方向に動く、これはAI Overviewがゼロクリックを増やしている典型的なパターンですが、GSCの画面だけでは16ヶ月分しか遡れないため、長期トレンドとして証明できません。
月次で生データを貯めておけば、「どのクエリ群で、いつからCTRが崩れたか」をクエリ×ページ単位で追跡できます。
これはリライト優先度の判断材料として、順位チェックツールよりも確度の高い情報になります。
GA4のデータも同様にスプレッドシートへ自動出力できます（公式アドオンGA4 Reports Builderを使用）。手順と注意点は別記事で解説します。
まとめ：サーチコンソールのデータをスプレッドシートに自動蓄積する方法
- GSCのデータは16ヶ月で消える。長期分析したいなら自分で貯めるしかない
- Search Analytics for Sheetsなら無料・ノーコードで毎月自動蓄積できる
- 現行UIは旧解説記事と画面が違う（Request→Search Console Requests、Backups→Recurrent Requests）
- Run a cycle right awayをYesにして即日動作確認する
- Enable Backup後は必ず「Active」バッジとBackup Logの両方を確認する
Takuma設定自体は15分もあれば終わります。データは今この瞬間も消え続けているので、思い立った日に仕込んでおくのがおすすめです。
