社内サイトやオウンドメディアの検索データを、管理画面からの手作業ではなく Search Console API の自動記録に切り替えたい担当者向けの記事です。筆者がこのサイトで作った構成を図にし、API の上限に対して何割を使うか、記録の保存に月いくらかかるかを試算しました。読み終わると、お金をかけずに自分で作れるかどうかを判断できるようになります。
この記事で分かること
- 検索の数値を自動で記録する最小の構成（認証・測定・企画へ戻す、の 3 つの操作）
- 記事が 100 件・1,000 件・1 万件の時に、API の 1 日の上限の何割を使うか
- 記録を手元のファイルに置く場合と BigQuery に置く場合の月額
- 鍵の置き方、データが確定するまでの日数、数値が少ない時の扱いなど、つまずきやすい点
成果の数値（表示回数やクリック数の実際の値）は、この記事では書きません。筆者の構成は動き始めたばかりで、判断に使える量の記録がまだ無いためです。
なぜ検索の数値を記録するのか
このサイトでは、記事を公開する前に文章や図を機械で検査しています。しかし、機械の検査に合格したことは、検索で読まれたことの証拠になりません。
読まれたかどうかを知るには、Search Console（Google 検索での表示回数やクリック数を確かめられる Google の無料ツール）の数値を見る必要があります。管理画面で毎回確かめるやり方では、記事が増えるほど手間が増え、見る日もばらばらになります。
そこで、公開から 7 日・28 日・56 日たった日に、記事ごとと検索語ごとの数値を自動で 1 行ずつ記録することにしました。決まった日に同じ条件で測れば、記事どうしを比べやすくなるためです。
Search Console の画面の表は 1,000 行までですが、Search Console API（プログラムから数値を取り出すための窓口）を使うと、より多くの行を取り出せます（Search Console ヘルプ）。1 回の問い合わせで返す行数は 1〜25,000 行の範囲で指定できます（Search Analytics: query）。
構成図：認証・測定・企画へ戻すの 3 操作
筆者がこのサイトの運用で試した構成は、次の 3 つの操作だけでできています。
図 1 のとおり、上から順に流れます。それぞれの役割を表にまとめます。
| 操作 | 何をするか | 実行する頻度 |
|---|---|---|
| auth | 読み取り専用の権限を許可する | 最初の 1 回だけ |
| measure | 区切りの日が来た記事を測る | 毎日 1 回 |
| insights | 成果の出た検索語を表示する | 企画を立てる時 |
認証は読み取り専用の権限にする
auth では、OAuth（パスワードを渡さずに、アプリへ決まった範囲の権限だけを許可する仕組み）で権限を許可します。Search Console API の検索アナリティクスには、読み取り専用の スコープ（許可する権限の範囲）である webmasters.readonly が用意されています（Search Analytics: query）。
数値を読むだけなら書き込みの権限は要りません。権限を最小にしておくと、鍵が漏れた時の被害を数値の閲覧だけに抑えられます。
測定は 1 組あたり API を 2 回呼ぶ
measure は、記事と区切り（7・28・56 日）の組み合わせ 1 つごとに API を 2 回呼びます。1 回目は「ページ」だけでまとめた合計、2 回目は「ページと検索語」でまとめた検索語ごとの数値です。
問い合わせの中身は、公式の説明にある項目を使うと次のような形になります。値はダミーです。
{
"startDate": "2026-11-01",
"endDate": "2026-11-07",
"dimensions": ["page", "query"],
"dimensionFilterGroups": [
{
"filters": [
{ "dimension": "page", "operator": "equals", "expression": "https://www.example.com/blog/sample/" }
]
}
],
"rowLimit": 1000,
"dataState": "final"
}dataState を省略するか final にすると、確定したデータだけが返ります（Search Analytics: query）。all にすると最新の日も含まれますが、まだ集計中の不完全な数値が混ざることがあるため、記録には final を使います。
筆者の構成では、1 回の実行で測るのは 40 組・問い合わせ 100 回・全体 3 分までと決めています。上限を決めておくと、何かの間違いで呼び出しが増えても、1 日の実行が長く止まらずに済むためです。
記録は 1 組 1 行
記録は「記事 × 区切り」ごとに 1 行です。1 つの記事は 3 つの区切りで測るので、記事 1 件につき 3 行になります。
筆者の手元の記録を 2026-11-13 に調べたところ、44 行で、1 行の平均は約 527 バイト（JSON の文字数）でした。検索語を多く含む行は、これより大きくなります。
この構成を毎日決まった時刻に動かす場所の選び方は、毎日の AI 実行を手元の Mac・Cloud Run Jobs・GitHub Actions で比べた記事で月額と止まり方を比べています。
公開から何日後に測るか
測る日は、区切りの日数そのものではありません。数値が確定するのを待ってから測ります。
図 3 のとおり、筆者の構成では各区切りの最後の日から 5 日待って測ります。
| 区切り | 測る日 | 根拠 |
|---|---|---|
| 7 日 | 公開から 12 日後 | 筆者の運用記録 |
| 28 日 | 公開から 33 日後 | 筆者の運用記録 |
| 56 日 | 公開から 61 日後 | 同じ規則で筆者が計算 |
公式によると、収集したデータは通常 2〜3 日以内に使えるようになります（Search Console ヘルプ）。さらに、API の日付は太平洋時間で指定するため（Search Analytics: query）、日本時間の朝に動かすと、太平洋時間ではまだ前の日です。5 日は、この 2 つのずれを見込んで筆者が決めた待ち日数です。
API の上限に対して何割を使うか
Search Console API は無料で使えますが、使用量の上限があります（料金 | Search Console API）。検索アナリティクスの上限は次のとおりです（使用制限 | Search Console API）。
| 上限の種類 | 値 |
|---|---|
| サイトあたり | 1 分 1,200 回 |
| ユーザーあたり | 1 分 1,200 回 |
| プロジェクトごと | 1 日 3,000 万回 |
| プロジェクトごと | 1 分 4 万回 |
記事 100・1,000・1 万件で計算する
最も呼び出しが多くなるのは、全記事を毎日測り直す場合です。この時の 1 日の呼び出しは「2 回 × 記事数」になります。筆者がこの式と上の上限から計算しました。
| 場合 | 1 日の呼び出し | 1 日上限に対する割合 |
|---|---|---|
| 本構成（1 日 6 本公開） | 36 回 | 0.00012% |
| 全件を毎日：100 件 | 200 回 | 0.00067% |
| 全件を毎日：1,000 件 | 2,000 回 | 0.0067% |
| 全件を毎日：1 万件 | 20,000 回 | 0.067% |
本構成の 36 回は、1 日 6 本公開する場合に「6 本 × 3 区切り × 2 回」で計算した値です。区切りの日が来た記事だけを測るので、記事の総数が増えても 1 日の回数はほとんど増えません。
1 分の上限でも見てみます。1 万件を毎日測る 20,000 回を 1 分 1,200 回の上限で流すと、少なくとも約 17 分に分けて呼ぶ必要があります。筆者の構成の 1 回の上限 100 回を仮に 1 分にまとめて呼んでも、1 分の上限の 8.3% です。
Search Console API の回数の上限は、記事が 1 万件あって全件を毎日測っても 1 日上限の 0.067% にとどまるため、気にするのは回数よりも問い合わせの重さです。公式は、回数とは別に読み込み割り当て（問い合わせの重さで数える上限）を設けています。この上限の具体的な数値は公式ページに書かれておらず、筆者は確認できませんでした。
重い問い合わせを避ける
読み込み割り当てには、10 分単位の短期のものと 1 日単位の長期のものがあります。超えると「割り当てを超過した」エラーになり、短期の場合は 15 分待ってから再び試すよう案内されています（使用制限）。
公式によると、ページと検索語の両方でまとめたり絞り込んだりする問い合わせが最も重く、重さは問い合わせる期間の長さに比例します。同じデータ（たとえば先月の全データ）を何度も問い合わせ直すことも避けるよう勧めています（使用制限）。
筆者の構成は、測った結果を 1 行として残し、同じ区切りを測り直しません。期間も区切りの 7〜56 日分に限っています。この作りは、公式の勧めに沿った使い方だと考えられます。
月額の試算：手元のファイルと BigQuery
記録の置き場所は「手元のファイル」と「BigQuery（Google Cloud のデータ分析用のデータベース。保存とクエリの量で料金が決まる）」の 2 通りで考えます。筆者のサイトは今は手元のファイル（JSON）に置いています。
容量を計算する
1 行の平均約 527 バイト × 記事 1 件あたり 3 行で、記事数ごとの容量を筆者が計算しました。
| 記事数 | 行数 | 容量 | 保存の無料枠に対する割合 |
|---|---|---|---|
| 100 件 | 300 行 | 約 154 KiB | 0.0015% |
| 1,000 件 | 3,000 行 | 約 1.5 MiB | 0.015% |
| 1 万件 | 30,000 行 | 約 15 MiB | 0.15% |
BigQuery のストレージは毎月 10 GiB まで、オンデマンド料金のクエリは毎月 1 TiB まで無料です（BigQuery の料金）。10 GiB は、1 行 527 バイトで約 2,000 万行に当たります。
月額は 0 ドルの見込み
記事 1 万件を 3 区切りずつ記録した 3 万行でも約 15 MiB で、BigQuery の無料枠（保存 10 GiB・クエリ 1 TiB）に収まるため、月額は 0 ドルと試算できます。15 MiB の表を毎回まるごと読むクエリでも、1 TiB の無料枠には月に約 7 万回入ります。
| 置き場所 | 月額の試算 | 向いている場面 |
|---|---|---|
| 手元のファイル | 0 円 | 1 人で記録して読む |
| BigQuery | 0 ドル（無料枠内） | 複数人で SQL で読む |
いずれも 2026-11-13 時点の料金ページで確認した値です。料金ページの単価の例は us-central1（アメリカの地域）のもので、東京リージョンの単価は確認できていません。無料枠を超えた場合の保存料金の目安は、1 GiB あたり月約 0.023 ドルです（BigQuery の料金）。
BigQuery の容量は列の型ごとに数えるため、JSON の文字数とは一致しないと考えられます。ここでの容量は目安として見てください。GA4 のデータを BigQuery に入れる場合の無料枠のもち方は、BigQuery の無料枠で GA4 エクスポートが何か月もつかを計算した記事で同じ料金表から試算しています。
公式の一括データエクスポートとの違い
Search Console と BigQuery の連携には、公式の一括データエクスポート（Search Console の数値を毎日 BigQuery へ自動で書き出す機能）もあります。使うには、Cloud のプロジェクトでお支払い情報を設定して BigQuery を有効にし、Search Console 用のサービスアカウントに権限を与えます。書き出しは設定してから最大 48 時間以内に始まり、設定より前の過去のデータは API か画面のレポートで確かめるよう案内されています（新しい一括データのエクスポートを開始する）。
| 比べる点 | 一括データエクスポート | API で自前で作る |
|---|---|---|
| 記録する範囲 | サイトの全データを毎日 | 決めた日・決めた記事だけ |
| 置き場所 | BigQuery だけ | 手元のファイルも選べる |
| 設定前のデータ | 書き出されない | 期間を指定して取れる |
公式は、有効期限を設定しない限りデータは永久にたまると注意しています。全データを残して SQL で自由に集計したいなら一括データエクスポート、公開後の決まった日の数値だけを小さく残したいなら API で自前で作る、という使い分けになります。
測った数値の判定と企画への戻し方
測った数値は、そのまま「良い・悪い」と判定しません。表示回数が少ない記事は、数値が偶然に大きく揺れるためです。
図 4 のとおり、筆者の構成では表示回数が 10 回未満の記事は判定を延ばします。企画に戻す検索語も、表示回数 10 回以上のものに限っています。どちらの 10 回も暫定の値です。
insights は、この条件を満たした検索語を一覧にして、次の記事の企画の材料として渡します。検索で実際に表示された語を企画に戻すと、読者が探している言葉に合わせて記事を作りやすくなります。
つまずきやすい点
筆者がこの構成を作った時に、つまずいた点と注意点をまとめます。
日付は太平洋時間で、確定まで待つ必要がある
API の開始日と終了日は太平洋時間で指定します（Search Analytics: query）。画面の検索パフォーマンスのレポートも、日ごとの数値をカリフォルニア州の現地時間で集計しています（Search Console ヘルプ）。
日本時間の日付のつもりで測ると、1 日ずれた期間を測ることになります。さらに確定前の日を含めると、後から数値が変わります。区切りの最後の日から数日待つのはこのためです。
表示回数が少ない検索語は出てこないことがある
公式によると、実行回数が非常に少ない検索語や、個人情報を含む検索語は記録されないことがあります（Search Console ヘルプ）。検索語ごとの数値を足しても、ページの合計と一致しないことがあるということです。
筆者の構成が合計と検索語を別々に問い合わせているのは、このずれがあるためです。合計の値はページだけでまとめた問い合わせから取ります。
鍵の置き方と権限
更新用の鍵（refresh token。権限を許可した後、毎回の許可なしで新しい通行証を受け取るための値）は、次の場所に置いています。
~/.config/search-console/refresh_tokenファイルは本人だけが読み書きできる権限（600）、フォルダは本人だけが入れる権限（700）にしています。Google 広告など別の用途の鍵とは分けて置いています。鍵を分けておくと、片方を取り消しても、もう片方の自動処理は止まらないためです。自動処理の鍵を用途ごとに分ける考え方は、GitHub のトークン権限を書き込み用と読み取り用に分けた記事でも扱っています。
同意画面は人の操作が必要で、「テスト」のままだと 7 日で止まる
Cloud のプロジェクトで Search Console API を有効にすることと、同意画面（アプリにどの権限を渡すかを利用者が確かめて許可する画面）で許可することは、人が操作する必要があります。プログラムだけでは済ませられません。
Google の公式ドキュメントによると、ユーザーの種類が「外部」で公開の状態が「テスト」の同意画面では、更新用の鍵は 7 日で切れます（OAuth 2.0 を使用して Google API にアクセスする）。同意画面の公開の状態を「テスト」のままにすると、Search Console API の自動記録は更新用の鍵が切れる 7 日後に止まります。名前やメールアドレスだけを求める場合は例外ですが、webmasters.readonly を求める構成はこの例外に当たりません。
筆者の構成では、鍵が切れた時の測定は invalid_grant というエラーで失敗しました。続けて動かすには、公開の状態を「本番」に切り替えるか、7 日ごとに許可し直す必要があります。本番に切り替えると、求める権限の範囲によっては Google の確認（審査）が必要になることがあります（Manage App Audience）。
最初の日は対象がまとめて来る
権限を許可した最初の日は、すでに公開済みの全記事の区切りがまとめて対象になります。筆者のサイトでは、仕組みを作った 2026-11-11 時点で 109 件ありました。
1 回の実行の上限（40 組）を超えた分は次の日に回り、3 日ほどで追いつく見込みです。新しくサイトを Search Console に追加した場合は、データができるまで最長で 1 週間かかることもあります（Search Console ヘルプ）。
まとめ
- 構成は、読み取り専用の権限を許可する auth、区切りの日に測る measure、検索語を企画に戻す insights の 3 操作で作れます。
- API の回数の上限は、記事 1 万件を毎日測っても 1 日上限の 0.067% です。気にするのは、ページ × 検索語の問い合わせの重さと、測り直しを避けることです。
- 記録は記事 1 万件で約 15 MiB で、手元のファイルなら 0 円、BigQuery でも無料枠に収まり 0 ドルと試算できます。
次の一歩
自社のサイトの記事数で上限や容量を見積もり直したい方や、検索の数値を記録する仕組みの作り方を相談したい方は、お問い合わせからご連絡ください。記録を BigQuery に置いて SQL で集計する場合に、読むデータ量や集計の単位が意図どおりかを第三者の目で確かめたい方は、BigQuery SQL レビューパックもご利用いただけます。
参考にした一次情報
いずれも 2026-11-13 に内容を確認しました。
- 料金 | Search Console API（Google for Developers）
- 使用制限 | Search Console API（Google for Developers）
- Search Analytics: query | Search Console API（Google for Developers）
- Search Console のデータについて（Search Console ヘルプ）
- 新しい一括データのエクスポートを開始する（Search Console ヘルプ）
- OAuth 2.0 を使用して Google API にアクセスする（Google for Developers）
- Manage App Audience（Google Cloud Platform Console ヘルプ）
- BigQuery の料金（Google Cloud）