※本記事にはプロモーションが含まれます。
筆者はブログ5サイトをAIで自動運営しています。今回のテーマは、サーチコンソールのAPI自動取得です。検索順位やクリック数のデータを、毎月・毎週まるごと自動で集める仕組みを実際に組みました。手順と設定値、そして半月ほど気づけなかった失敗までまとめます。毎月手作業でCSVを落としている方の参考になればうれしいです。
なぜサーチコンソールのAPI自動取得にしたのか
最初は管理画面から手でCSVをダウンロードしていました。ですが5サイトぶんを毎月やると、地味に手間がかかります。取り忘れも起きます。ここ、面倒に感じやすいところです。手作業と自動取得で、何がどう変わったかを並べてみます。
| 項目 | 手作業（以前） | API自動取得（現在） |
|---|---|---|
| 1サイトあたりの操作 | ログイン・プロパティ選択・期間指定・クエリ別とページ別の2回エクスポート・保存 | なし（スケジューラーが実行） |
| 5サイトぶんの人の手 | 上記を5回くり返す | 0回 |
| 取得の頻度 | 思い出したとき | 毎月1日と毎週月曜の朝5時50分 |
| 分析へのつなぎ方 | CSVを開いて手で読む | 各ブログのデータファイルを月次分析がそのまま読む |
| 取り忘れ | 起きる | 起きない（ただし別の落とし穴あり。後述） |
取得したデータは、記事のリライト候補を選ぶ月次分析にそのまま渡しています。順位が11位から20位でクリックの少ないページを機械的に拾えるので、直す記事を勘で選ばずに済みます。関連する考え方はAIの業務ログ管理術でも触れています。
用意したもの（サービスアカウント方式の手順）
自分ひとりの自動化なら、サービスアカウント（人が毎回ログインしなくても動く専用アカウント）方式が扱いやすいです。人に配るツールを作るのでなければ、OAuth（利用者本人が認証する方式）より手数が少なくて済みます。やることは3つだけでした。
| 手順 | やること | つまずきやすい点 |
|---|---|---|
| 1 | Google Cloudでプロジェクトを作り、Search Console APIを有効化してサービスアカウントとJSON鍵を発行する | APIの有効化を忘れると、鍵は作れても呼び出しで弾かれる |
| 2 | Search Consoleの各サイトに、サービスアカウントのメールアドレスを「制限付き」ユーザーとして追加する | サイトを増やしたら毎回この追加が要る。忘れると403が返る |
| 3 | 鍵ファイルを読み込んでデータを取得するスクリプトを書き、スケジューラーに登録する | 権限は読み取り専用でよい。書き込み権限は不要 |
鍵ファイルはパスワードと同じ扱いです。共有フォルダや公開リポジトリに置かないよう気をつけてください。
実際に設定したパラメータ
スクリプトの中身は、突き詰めると数個の設定に集約されます。筆者の環境で動いている値をそのまま載せます。
| 設定 | 値 | そうした理由 |
|---|---|---|
| 取得期間 | 28日ぶん | 4週間なので曜日のかたよりが出ない |
| 期間の終わり | 実行日の3日前 | サーチコンソールのデータは2〜3日遅れて確定するため |
| 取得の軸 | 検索クエリ別とページ別の2種類 | クエリはタイトル改善、ページはリライト対象の特定に使う |
| 取得行数 | 各25行 | 個人ブログなら上位だけで判断がつく。増やすと読む側が疲れる |
| 再試行 | 最大3回（10秒・20秒待ち） | 通信エラーとサーバー側の一時エラーだけ再試行。権限エラーは即停止 |
| 保存の仕方 | 一時ファイルに書いてから差し替え | 失敗しても前回のデータが残る |
知っておきたい取得上限
APIには上限があります。設計の前に押さえておくと安心です。主な数字を表にまとめました（2026年8月時点で公式ドキュメントを再確認しています）。
| 項目 | 目安の上限 |
|---|---|
| 1日あたりの取得行数 | サイトごと・検索タイプ（ウェブ／画像／動画など）ごとに5万行 |
| 1回の呼び出しで取れる行数 | 最大2万5千行 |
| 1分あたりのクエリ数（サイト単位・ユーザー単位） | 1,200 |
参考：Google for Developers「Search Console API Usage Limits」
個人ブログの規模なら、この上限に当たることはまずありません。2万5千行を超えるサイトだけ、開始行をずらして複数回に分けて取ることになります。あわてなくて大丈夫です。
つまずいた点と対策
ここがこの記事の本題かもしれません。実際に起きた3つを、原因と対策つきで並べます。
| 起きたこと | 原因 | 対策と結果 |
|---|---|---|
| データが返ってこない（403） | Search Console側にサービスアカウントを登録し忘れていた | 登録メールアドレスと鍵の対応を1件ずつ確認。追加直後は反映に2〜3日かかることもある |
| 取得に失敗した回に、前回のデータまで消えた | 取得結果を直接、本番のファイルへ上書きしていた | 一時ファイルに書いてから中身を検証し、問題なければ差し替える形へ変更。以後は失敗しても前回分が残る |
| 予定した時刻にそもそも動かなかった | スケジューラーのログ出力先を外付けHDDにしていた | 出力先を内蔵ディスクへ変更。強制実行で動作を実証し、次の自動実行も成功 |
3つめが厄介でした。少し詳しく書きます。
いちばん気づけなかった失敗：起動前に消えていた
スケジューラーに登録したはずの取得が、予定の朝5時50分に走っていませんでした。困ったのは、失敗の記録すら残っていなかったことです。エラーログが1行もない。スクリプトは、HDDがつながっていなくてもエラーを吐く作りにしてあったので、「起動して失敗した」なら痕跡が残るはずでした。それが無いということは、スクリプトが呼ばれる前の段階で落ちていると考えるしかありません。
原因は、スケジューラーのログ出力先を外付けHDD上に指定していたことでした。この仕組みは、指定されたログファイルを作れないと処理そのものを起動せず、しかも何も書き残しません。早朝のスリープ復帰時にHDDがまだマウントされていないと、無言で落ちる。同じMacで正常に動いていた別の定期処理は出力先が内蔵ディスクで、設計の違いはそこだけでした。
対策は単純で、ログの出力先を内蔵ディスク側へ移しただけです。そのうえで強制実行の機能で1回だけ発火させました。ログファイルが新しく作られること、5サイトとも取得に成功すること、終了コードが0になることを確認しています。ログが生成された時点で、起動できた直接の証拠になります。そして次の定期実行（2026年8月1日の朝5時50分）でも5サイトすべてが更新に成功しました。ここでようやく、対策が効いたと言えます。
教訓は「ログの置き場所を、監視したい仕組みより不安定な場所にしない」ということでした。外付けHDDは容量の面では便利ですが、起動の可否を左右する場所に置くと、失敗そのものが見えなくなります。監視の考え方はAI監視を自動化する仕組みにまとめています。
よくある質問
Q. 無料で使えますか。
A. Search Console APIの利用自体に費用はかかりません。Google Cloudのプロジェクト作成とAPI有効化も、この用途の範囲なら課金は発生しませんでした。ただし料金体系は変わることがあるので、公式の料金ページで最新の扱いを確認してください。
Q. サービスアカウントとOAuthのどちらを選べばよいですか。
A. 自分のサイトのデータを自分のために取るだけならサービスアカウントが手軽です。他の人のサーチコンソールにつなぐツールを配る場合は、利用者本人に認証してもらうOAuthが必要になります。
Q. データが空で返ってきます。
A. サービスアカウントを追加した直後は、反映まで2〜3日かかることがあります。数日おいて再実行してみてください。それでも空なら、サイトURLの末尾スラッシュやwwwの有無が、Search Consoleの登録と一致しているか確認します。
Q. 毎月と毎週、どちらの頻度がよいですか。
A. 筆者は月1回から始めて、途中で毎週月曜も足しました。月1回だと直近3週間に公開した記事がデータに存在せず、リライト提案が古い記事にかたよったためです。記事を毎日出しているなら週1回はあったほうがよいと感じています。
まとめ：小さく自動化して、失敗が見える形にする
サーチコンソールのAPI自動取得は、一度組めば毎月の手作業がまるごと消えます。最初の設定だけ少し手間ですが、あとは静かに動き続けてくれます。まずは1サイトぶんだけ試して、動いたら横展開する。この順番なら、うまくいかなくても被害が小さく済みます。
そして今回いちばんの学びは、自動化そのものより「動かなかったときに気づける形にしておく」ことでした。静かに動く仕組みは、静かに止まります。焦らず、小さく積み上げていきましょう。
集めた検索データを、記事の改善につなげるところまで自動化したい方へ
リテラ（BringRitera）を見てみる
なお、AIとツールをつなぐ仕組みそのものに興味があれば、MCPとは？AIとツールをつなぐ仕組みもあわせてどうぞ。
