Search Console確認をAIで5倍速化｜7回の処理時間とトークン推移の実測録
Google Search Console（GSC）の API 連携やインデックス台帳、生成 AI 引用レポートなど、便利な分析ツールを増やしていくと、思わぬ落とし穴にはまります。「今日の GSC 何かある？」と AI エージェントに一言聞いただけなのに、AI が巨大化したレポート群を次々と読み漁り、確認だけで 6 分以上・約 200 万トークンも溶かしてしまう 「レポート肥大化の逆説」 です。
結論からお伝えすると、毎日の定例確認を最速・最小コストに保つ秘訣は、重い集計と異常判定を Pure Rust と macOS launchd の毎朝自動診断へ押し出して 2.4KB の要約 1 枚に凝縮し、生 JSON 直読み禁止と SQLite 階層索引を組み合わせること にあります。実際に全 7 回の確認ターンを生ログから追跡した結果、所要時間は 6.3分 ➔ 1.2分（5.2倍速）、新規入力トークンは 58.2%削減 され、さらに 100 件のライブ URL 検査を走らせた朝でもトークン消費が一切跳ね上がらない構造へ到達しました（なお、もうひとつの定例業務である API自動収集と記事作成の全16回・5世代進化の折れ線グラフ実測録 もあわせて公開しています）。
-
Search Console APIで自動診断｜クリック9割が非開示クエリの罠と無料SEO監査術 : Web 画面のエクスポート制限や匿名化クエリの罠を突破し、無料 API で検索クエリと記事の欠落語を自動突合する基盤設計を解説しています。
-
Search Consoleの更新が1週間〜10日止まる原因と「GoogleOther（29%）」の正体 : Search Console 側の集計確定ラグやクローラー内訳の読み解き方など、毎朝の定期診断とあわせて知っておきたい実測知識です。
-
JavaScriptの型消去はなぜ怖い？2.6万行のツールをPure Rustへ統合した実証録 : 旧 Node.js 版でパッケージ読込だけで 1.3 秒かかっていた GSC 台帳・SVG 生成を、Pure Rust 単一バイナリ化で 0.15 秒（10倍以上高速）へ短縮した前編です。
-
AIのツール呼び出し往復が遅い原因｜Pure Rust前後一括化で出力83%減の実証録 : 個別コマンドのピンポン往復によるクラウド推論ターン税を断ち、
prep gscとfinishの前後 2 発へ集約した設計録です。 -
CLAUDE.md・GEMINI.md・TODO丸読みの罠｜SQLite階層目次で読込99%減の実測録 : 新規入力トークンが増えるほど 1 ステップの応答が最大 10 秒超遅くなる法則と、長大ドキュメント丸読みを根絶した階層索引の仕組みです。
-
AI記事作成が1本6分に短縮した全12回の実測記録｜規模10倍でも速くなるRust基盤 : 記事執筆ワークフロー側の全 12 セッション推移を折れ線グラフで検証した姉妹編です。
-
Search Console やアクセス解析の自動化スクリプトを組んだものの、AI に状況確認を頼むと毎回何分も待たされる方
-
記事数やレポート項目が増えるにつれて、AI コーディングツールの週間クォータや API トークン消費がじわじわ重くなっている方
-
CLI の単体高速化・定期バッチ・SQLite 階層化が 「実際のチャット 1 ターンの時間とトークン」にどう効くのか定量データで見たい方
結論：毎日のGSC確認を蝕む「レポート肥大化」の罠
当サイト（現在公開 706記事）では、Google Search Console API と URL Inspection API を連携させ、検索順位・CTR の変化やインデックス登録状況を毎日チェックしています。ところが、分析機能を充実させていく途中で「ある違和感」に気づきました。
最初はサッと答えが返ってきとったのに、全記事インデックス台帳や 90 日データ、生成 AI 引用レポートを増やしてから、「気になる点あった？」と聞くだけでずいぶん待たされるようになった時期があったんよね。
まさにそこが「自動化ツールの盲点」でした！ プログラム側が親切に何種類もの詳細な Markdown 台帳や CSV・JSON を出力するようになると、真面目な AI ほど「見落としがあってはいけない」と考えて、何百キロバイトもあるレポートを端から順番に read_file でめくり始めてしまうんです。
全7セッションの初回ターン同条件比較ルール
本当に各改修でどれだけ速くなり、どれだけトークンが減ったのかを確かめるには、感覚ではなく生ログの一次計測が欠かせません。ただし、チャット履歴を丸ごと 1 会話単位で比べてしまうと、「確認だけで終わった日」と「確認のあとそのまま記事を 1〜3 本執筆・改修した日」が混ざり、正しい比較ができなくなります。
そこで今回は、Antigravity がローカルに記録している Protocol Buffers（Protobuf）形式の実行ログ（StepMetadata）を Pure Rust 製アナライザ（kb-search brain --max-turn 1）でデコードし、全 7 回のセッションすべてで「最初の質問（GSC 確認依頼）を投げてから初回レポート回答が完了するまでの Turn #1 のみ（サブエージェント 0 体）」 を厳密に切り出して同条件で比較しました。
処理時間と総トークン変化の2軸折れ線グラフ
2026 年 11 月 3 日の API 導入初期（当時 539 本規模）から、本日 11 月 10 日朝（691 本規模）までの全 7 回における 「AI 純稼働時間（左軸：分）」 と 「総プロンプト評価量（右軸：万トークン、キャッシュ読込込み）」 の推移が次の折れ線グラフです。
グラフとあわせて、各ターンのステップ数・ツール呼び出し内訳・新規（Fresh）入力トークン・キャッシュ読込・AI 出力トークンの全実測値も一覧表で整理します。
| 日時 (JST) / ID先頭 | 当時の運用世代・確認内容 | AI純稼働時間 | 推論Steps / Tool数 | 新規Fresh入力 | Cache読込 (Hit率) | 総Prompt評価量 | AI出力tok |
|---|---|---|---|---|---|---|---|
11/03 18:23cefb0c26 |
初期（539本） ：GSC API 初期分析確認 | 3.1 分 | 12 steps / 24 tools | 177,909 tok | 915,959 (83.7%) | 1,093,868 tok | 11,955 tok |
11/04 20:051a7d84f2 |
拡大期 ：クローラー巡回・SEO網確認 | 3.1 分 | 13 steps / 37 tools | 120,570 tok | 1,117,738 (90.3%) | 1,238,308 tok | 13,607 tok |
11/05 09:4911fa8bb2 |
機能追加期 ：URL検査・全記事台帳追加 | 4.3 分 | 13 steps / 22 tools | 111,680 tok | 848,180 (88.4%) | 959,860 tok | 15,500 tok |
11/07 23:037a07e7ff |
肥大化ピーク（650本） ：全レポート横断確認 | 6.3 分 | 14 steps / 43 tools | 265,592 tok | 1,656,037 (86.2%) | 1,921,629 tok | 27,126 tok |
11/09 08:51638720fd |
完成形（オフライン即答） ：朝8:15自動診断後 | 1.2 分 | 9 steps / 20 tools | 110,967 tok | 567,233 (83.6%) | 678,200 tok | 6,696 tok |
11/09 17:05a7999708 |
手動バッチ直後 ：第4〜8弾バッチ結果確認 | 3.0 分 | 13 steps / 38 tools | 186,769 tok | 1,154,074 (86.1%) | 1,340,843 tok | 13,372 tok |
11/10 07:3841b3ded5 |
691本・自動巡回前 ：ライブAPI＋URL検査100件込 | 7.1 分 | 17 steps / 26 tools | 111,879 tok | 922,172 (89.2%) | 1,034,051 tok | 8,932 tok |
11 月 7 日夜（7a07e7ff）には公開記事が 650 本へ増え、1 回で 43 個ものツール（うち read_file 24 回） を叩いて 6.3 分・総プロンプト 192.2 万トークン まで膨れ上がっていました。それが Pure Rust 統合と朝 8:15 自動要約を導入した直後の 11 月 9 日朝（638720fd）には、わずか 1.2 分（75 秒）・9 ステップ・総プロンプト 67.8 万トークン（64.7%減） へと一気に 5 分の 1 以下に縮まっています。
なぜ最終回は時間だけ伸びてトークンが跳ねないのか
ここで先ほどの折れ線グラフの右端（11/10朝）をご覧になると、きっと鋭い疑問が浮かぶはずです。
ちょっと待って！ 11 月 9 日の朝に 1.2 分まで下がったのに、今日の朝（11 月 10 日）は緑色の時間の線がまた 7.1 分に上がっとるじゃないの！ これじゃあ元に戻ってしまったんじゃない？
いいえ、そこが今回の計測で一番面白い大発見だったんです！ クォータ消費の本体である「新規（Fresh）入力トークン」と「AI 出力・思考トークン」だけを抜き出した 2 本目の折れ線グラフを見ると、まったく逆の現象が起きていることが一目でわかります！
新規入力とAI出力トークンの2軸折れ線グラフ
コンテキストキャッシュ（Context Caching）が効かない純粋なコンテキスト増分である 「新規 Fresh 入力トークン（左軸：万トークン）」 と、最も計算コストが重い 「AI 出力・思考トークン（右軸：千トークン）」 の推移をプロットしたのが次のグラフです。
ご覧の通り、青い実線（新規 Fresh 入力）もオレンジの破線（AI 出力）も、11 月 10 日朝はまったく跳ね上がっていません。オフライン最速だった 11 月 9 日朝の 110,967 tok に対し、今朝は 111,879 tok ── その差はわずか +912 tok（誤差 0.8%） で、ピーク時（265,592 tok）と比べて 57.9%削減 された底値にピタリと張り付いています。
朝8時15分の境界線と時間・トークンの完全分離
なぜ今朝だけ「時間は 7.1 分かかったのに、トークンは一切増えなかった」のでしょうか。理由は 声をかけた時刻と外部 API の物理通信時間 にあります。
-
11月9日 08:51 JST（
638720fd：1.2分） : 毎朝 08:15 に macOS のlaunchdがバックグラウンドで自動実行するオンライン定期診断がすでに終わっていたため、AI は生成済みの軽量サマリー（2.4KB）を読むだけで 75 秒で即答完了 しました。 -
11月10日 07:38 JST（
41b3ded5：7.1分） : 自動診断が走る 08:15 より 37 分早く 確認したため、手元のデータは昨晩のままでした。そこで AI がその場でオンライン定期診断を起動し、28 日間・90 日間の検索データ取得に加えて 新着・未登録記事 100 件の URL Inspection API ライブ照会（20 並列でも Google 側の応答待ちに実測40.3秒） とサンドボックス外実行の承認・非同期通知待機を経た上で最新結果を報告しました。 -
時間とトークンの完全分離（デカップリング）に成功 : 以前の設計なら、その場で API バッチを走らせると大量のログや巨大 JSON（
246KB〜1.3MB）がコンテキスト窓へ流れ込み、トークン量まで 26 万超へ爆発していました。現在は「外部通信と全件突合は Pure Rust が裏で済ませ、AI は圧縮された結果サマリーだけを読む」設計になっているため、たとえ 100 件のライブ検査を回しても AI の脳内トークン消費は一切汚れなくなった のです。
数字を劇的に変えた3段階のアーキテクチャ改修
ここまでの改善は、一足飛びに魔法のツールを作ったわけではありません。日々の運用でぶつかったボトルネックを 1 つずつ潰していった 3 段階のボトムアップ改修 が、そのまま折れ線グラフの減少カーブになっています。
旧Node.js版のnpm読込1.3秒を撤廃し、全記事台帳＋2段SVG推移グラフ生成を0.15秒（10倍以上高速）へ短縮。
launchdで毎朝5大SEO健康診断を無人実行し、2.4KBの要約1枚へ凝縮。生JSON丸読みを禁止し確認1.2分化を達成。
SQLite階層目次でルール・コードの丸読みを断ち、GSC改善下調べもprep gsc 1発（出力73%減）へ集約。
第1段階：脱Node.jsで台帳生成を10倍高速化
最初の転機は、Node.js（fetch_gsc_analytics.mjs）で書いていた取得・集計スクリプトを、外部クレート依存ゼロの Pure Rust（kb-search gsc-fetch / gsc-audit）へ統合したことです。
Node.js 版では googleapis と gray-matter の 2 パッケージを import するだけで 1,283.4 ms（約 1.3 秒） かかっていましたが、RAM ディスク上のネイティブ機械語バイナリにしたことで、公開 706記事 すべての URL 台帳・CSV・2 段カラー SVG 推移グラフの生成まで含めて 152.0 ms（0.15 秒） で終わるようになりました。
第2段階：毎朝8時15分の自動診断と2.4KB要約化
ローカル CLI が 0.15 秒になっても、AI が 246KB のクエリ生 JSON や 1.3MB の全記事ステータス JSON を直接 read_file してしまえば、コンテキスト窓は一瞬でパンクします。
そこで macOS 標準の launchd で毎朝 08:15（スリープ時は復帰直後）に kb-search gsc-audit を無人実行させ、以下の 5 大項目と主力エース・お宝候補を _local_db/gsc/gsc_routine_latest.md（わずか 2.4 KB・32 行） へアトミック出力する仕組みに切り替えました。
-
守りの異常ゼロ確認 : URL 検査エラー（404 / Soft404 / noindex 事故）、
.htaccess未対応の未知 URL、内部リンク切れ・孤立記事、フロントマター欠損、7 日間クリック急落（-55%以上）の有無を 1 行で判定し、異常時のみ不具合.txtへ自動起票します。 -
攻めのお宝提案とクールダウン制御 : 検索 1 ページ目圏内で低 CTR の記事を抽出しつつ、直近 14 日以内にタイトル改善済みの記事は「効果測定中」として自動除外し、無駄な連続いじりを防ぎます。
-
大型生 JSON の直読み禁止ルール : AI には「大型生 JSON を直接
read_fileせず、必ず2.4KBの日次サマリーと専用サブコマンドを使うこと」を明文化し、11 月 9 日朝の 1.2 分・67.8 万トークン を達成しました。
第3段階：SQLite階層索引とprep一括カルテ化
さらに 11 月 9 日夕方（a7999708：複数バッチ手動実行後の確認で 3.0分・18.7万tok）のログを振り返ると、複数のレポートやルール文書・記事構造を確認する際にまだ細かな read_file が重なっていました。
そこで同日夜に SQLite 階層ナビゲーション（kb-search tree） と 前後一括サンドイッチコマンド（prep gsc / gemini-gate finish） を投入しました。今朝のセッション（41b3ded5）で GSC 仕様確認が kb-search docs 1 発（21.91ms）で済み、上位 3 記事の改善カルテも prep gsc --top 3 1 発（118.51ms・標準出力 36,288 B ➔ 9,742 B で 73.2%削減）に収まったのは、この第 3 段階が効いているためです。
浮いた余力で即解決！発射台リンクの2ミリ秒解剖
定例確認が軽く・速くなる最大のメリットは、人間も AI も「ただ現状を確認するだけで疲弊せず、その場で一歩踏み込んだ改善まで一気に片付けられること」にあります。
実際に今朝のセッションでも、公開 691 本中 644 本（登録率 93.2%・検証録に限れば 315 本中 309 本で 98.1%！） がインデックス登録済みと確認した直後、「残る未登録記事の発射台リンクを点検しよう」という話になりました。その際もファイルを 1 本ずつ開いて探すのではなく、SQLite の article_links テーブルへ Pure Rust の kb-search sql を投げるだけで、わずか 1.4〜2.8 ミリ秒 で次の 3 つの構造ボトルネックがあぶり出されました。
-
再クロール保留記事の弱点特定 : 昨日 Googlebot が再巡回した上で保留中だったデータセンター記事を調べると、被リンク 9 本中 3 本（親ハブ含む）が未登録記事であり、さらに本文中の公的出典インラインリンクと視覚図解が 0 個だった真因が即判明しました。その場で 4 つの一次出典リンクと比較図解、暖房・電力系主力エース記事からの双方向リンクを補強しました。
-
未登録の「章ハブ片方向ボトルネック」解消 : 未登録記事の 3 割超が特定の 2 つの章に集中していた原因は、親である章ハブ自体が「子記事へ大量に発リンクしているのに、登録済み子記事からの逆リンクが少ない片方向状態」で未登録になっていたためでした。
-
新着クラスタ内循環へのハシゴ架け : 検証録で未登録だった新着 2 本も、リンク元が「今週公開したばかりの新着記事同士」に閉じていたため、検索上位（平均 3.6 位・CTR 22.2%）の既存エース記事から
gemini-gate finish --related-fromで逆リンクを一括注入し、関連 22 記事の検問（379.2ms）から本番デプロイまで数分で完遂できました。
人間が朝からログの海に溺れず、おいしいコーヒーを飲んでいる間に「詰まっている水路」だけをピンポイントで開通できるのが一番にゃ。
母艦マシンの1日単価とAI再現プロンプト
こうした「毎朝の launchd 自動巡回」「SQLite 知識 DB のインメモリ検索」「Pure Rust 2 大バイナリのミリ秒実行」をクラウドの有料バッチサーバーを使わず維持費 0 円で回せているのは、手元の母艦 Mac に十分なメモリ（64GB）と RAM ディスクを持たせているからです。
5年稼働の64GB母艦と技術書の1日あたり快適コスト
大容量メモリの Mac や専門書は購入時の金額だけを見ると高く感じますが、毎日 AI を 24 時間働かせる基盤として耐用年数（5 年＝1,825 日）で割ると、1 日あたりの実質負担はごくわずかです。
-
現行 64GB クラスの Mac mini 母艦（約 30 万円前後想定） ：5 年間毎日稼働させた場合、1 日あたり 約 164 円（自販機の缶コーヒー 1 本分）でクラウド実行枠の課金や I/O 待ちストレスをゼロにできます。
-
中古 27 インチ 5K iMac ＋ Crucial 64GB メモリ増設（合計約 12 万〜15 万円前後・推論試算） ：5K 広大画面で折れ線グラフや Search Console 台帳を並べて確認でき、5 年換算なら 1 日あたり 約 66〜82 円 という圧倒的なコストパフォーマンスになります。
-
Rust の体系的な定番技術書（約 5,000 円前後） ：AI が書いた Rust コードの所有権やメモリ安全性を人間側で監督する一生モノの地図として、5 年換算で 1 日 約 3 円未満 で元が取れます。
最上位AIに定例確認の軽量化を組ませる指示プロンプト
ご自身のブログや Web サイト運用でも、「毎日のアクセス解析や Search Console チェックで AI の応答が重くなってきた」と感じたら、以下のプロンプトを参考に段階的な軽量化を組ませてみてください。ファイル構造や既存スクリプトを壊さないよう、必ず 『Gemini 4 Argon』または同等以上の最上位推論モデル を選び、いきなり書き換えさせず事前調査と計画合意から進めるのが鉄則です。
以下の記事の設計思想（重い API 取得・全件突合の定期バッチ分離、2〜3KB の日次要約 Markdown 化、大型生 JSON 直読み禁止、初回確認ターンのトークン計測）を参考にして、私の現在のプロジェクトの Search Console / 分析確認ワークフローを軽量化したいです。
参考記事：https://lab.chihouzakki.com/blog/review/gsc-daily-check-token-time-linechart-rust-evolution/
【厳守ルール】
- いきなりコードを書き換えたりファイルを削除したりせず、まず現在の私の環境にある分析スクリプト・出力ファイルサイズ・AI が毎回読んでいるファイルを調査して報告してください。
- その上で、①定期実行（launchd / cron 等）で事前生成する軽量サマリー（3KB 以内）の設計案、②生データの誤読込を防ぐルール追記案、③段階的な高速化（必要に応じた Rust / SQLite 化）の実装計画を提示し、私の合意を得てから 1 段階ずつ実装してください。
まとめ：機能を増やすほどAIに読ませる量は減らす
最後に、全 7 回の Search Console 定例確認ターンの追跡から得られた教訓をまとめます。
-
自動化レポートを増やすほど「AI の拾い読みコスト」を疑う : 詳細な CSV や JSON をそのまま AI に探させると、機能追加に比例してツール呼び出しが 40 回超・約 200 万トークンへ膨張します。
-
毎朝の無人診断 ＋ 2.4KB 要約 1 枚で「5.2倍速・トークン58%減」 : 異常判定とクールダウン選別を Pure Rust ×
launchdに任せれば、日常確認は 75 秒・最小トークンで終わります。 -
外部 API の通信待ちと脳内コンテキスト消費を分離する : 生データ直読みを禁じて SQLite 階層索引と
prepカルテを通すことで、朝一番に 100 件のライブ URL 検査を走らせてもトークン消費は0.8%差の横ばいに封じ込められます。
毎日のルーチン確認が 1 分ちょっとで片付くようになると、朝の時間にゆとりが生まれ、本当に頭を使うべき「次の企画」や「構造的なリンク改善」をじっくり楽しめるようになります。ぜひ手元の AI 運用でも、「分析機能を増やしたら、AI に読ませる入り口は逆に小さく絞る」 という引き算の設計を取り入れてみてくださいね！
