どうも、管理人です。
最近、ローカルAIエージェントを使って「ブログ運営そのものを少し自動化できないか」を試しています。
これまで、RTX 5070 Ti 16GB環境でローカルAIエージェントを動かしたり、複数のローカルLLMに同じ実務タスクをさせて比較したりしてきました。
前回のモデル比較では、Google Search Consoleの実データを使ったタスクも試しています。
AIエージェントはモデル選びが重要だった。RTX 5070 Ti 16GBで7つのローカルLLMに同じ実務をさせて比較
そこで見えてきたのが、
「AIに全部任せるより、Pythonで数値処理を行い、曖昧な判断だけAIに任せた方が安定する」
ということでした。
今回はその考え方を実際のブログ運営に使い、Google Search Consoleのデータを毎週取得して、
- アクセスが急に落ちた記事
- 検索順位の割にCTRが低い記事
- 急に検索表示が増えている記事
- 記事内容と検索意図がズレていそうな記事
などを自動的に抽出し、必要な記事だけローカルAIに確認させる仕組みを作ってみました。
最終的にはWindowsのタスクスケジューラから毎週自動実行し、人間は生成されたレポートを見るだけという形まで持っていけました。
最初は「GSCをAIに全部読ませればいい」と考えていた
最初に考えたのは単純でした。
Google Search Consoleのデータを取得して、そのままAIへ渡せば、
「この記事はアクセスが落ちています」
「このタイトルを変えた方がよさそうです」
といった判断までしてくれるのではないか、というものです。
しかし実際に試していくと、この構成には問題がありました。
クリック数、表示回数、CTR、平均順位といった数値は、そもそもAIに判断させる必要がありません。
こうした数値処理までLLMに任せると、計算や比較期間の扱いが不安定になったり、同じデータでも出力が変わったりします。
さらにサイト内の全記事を毎回LLMへ渡せば、処理時間も長くなります。
そこで役割を分離しました。
最終的な構成
現在は次の流れで動いています。
Google Search Console API
↓
Pythonで取得・集計
↓
Pythonで候補記事を絞り込み
↓
必要な記事だけ検索クエリを取得
↓
記事本文・タイトル・見出しを取得
↓
ローカルLLM（Gemma 4 12B）で意味判断
↓
ValidatorでAI出力を検証
↓
状態管理
↓
週次レポート生成
↓
人間が最終判断
つまり、数値はPython、文章や検索意図の意味判断だけAIという役割分担です。
この構成にしてから、かなり安定しました。
Google Search ConsoleはAPIから取得
Search Consoleはブラウザを自動操作するのではなく、Google Search Console APIから取得しています。
権限は読み取り専用です。
比較するのは基本的に、直近7日間とその前の7日間です。
例えば今回のレポートでは、
前7日 2026-08-26 ～ 2026-09-01 直近7日 2026-09-02 ～ 2026-09-08
を比較しています。
Search Consoleのデータは即時確定ではないため、実行日そのものではなく、数日前までの確定データを対象にしています。
最初の候補抽出はPythonだけで行う
サイト内の全記事を毎回AIへ渡すのは無駄なので、まずPython側で候補を絞ります。
例えば、クリック数の大幅減少、表示回数の増減、平均順位の悪化、順位の割にCTRが低い記事、新しく検索結果へ出始めた記事などです。
ここではAIは使っていません。
数値条件なので、普通のプログラムの方が速く、毎回同じ条件で判定できます。
検索クエリは候補記事だけ追加取得する
候補になった記事については、Search Consoleから「どんな検索語で表示されているか」も取得します。
ただし、ここには注意点があります。
Search Consoleに表示される検索クエリは、すべての検索語ではありません。
プライバシー保護などの理由で非表示になるクエリがあるため、
「表示されていない検索語 ＝ 検索需要がない」
とは判断しないようにしています。
この注意点は、生成する週次レポートにも記載しています。
記事本文も取得してAIへ渡す
数値だけでは、検索意図と記事内容が本当にズレているのかまでは判断できません。
そこで候補記事については公開ページから、タイトル、meta description、canonical URL、H1、H2なども取得します。
ここまで準備したうえで、初めてローカルLLMへ渡します。
AIには「意味の判断」だけさせる
現在の週次運用ではGemma 4 12Bを使用しています。
以前行ったローカルLLM比較では、今回のようなGSC関連タスクで速度と安定性のバランスがよかったためです。
AIには主に、
- 検索意図と記事内容に明確なズレがあるか
- CTR改善候補として見るべきか
- 具体的な記事修正を提案できるほど根拠があるか
といった意味面だけを判断させます。
クリック数や順位などの数値判定はPython側の仕事です。
AIの回答をそのまま信用しない
ローカルLLMを実務で使っていてかなり重要だと感じたのが、Validatorです。
AIには決められたJSON形式で回答させます。
例えばdecision、reason_codes、change_targets、evidence_refsといった項目です。
そしてAIが許可されていない理由コードを使ったり、根拠なしで記事修正を提案したりした場合は、そのAI出力を不採用にします。
実際のテストでも、AIが条件に合わない理由を出し、Validatorで弾かれたことがありました。
ただし、その場合でもPython側ですでに「要確認」と判定している記事は消しません。
AIが失敗しても最低限の判定は残るようにしています。
最終判定は3段階
現在の判定は大きく3種類です。
- watch：現時点では対応不要
- inspect：確認する価値はあるが、まだ修正根拠不足
- recommend_change：具体的な修正候補あり
ただし、recommend_changeになっても記事を自動編集することはありません。
最終的には人間が確認してから修正します。
同じ警告を毎週何度も出さない
最初は毎回同じ記事が「要確認」と表示されてしまいました。
そこで状態管理も追加しました。
前回と同じ状態なら通知を抑制し、新しく要確認になった場合、重要度が上がった場合、状態が変わった場合、一定期間が経過した場合などに再通知します。
逆に、候補から外れた記事は「解消」として記録されます。
最終的に人間向けの週次レポートを作った
最初のレポートはAI判断だけが並んでいて、正直かなり分かりにくいものでした。
そこで何度か改良し、現在は各記事について記事タイトル、URL、優先度、クリック数、表示回数、CTR、平均順位、前週比較、主要検索クエリ、AI判断、今週やることまで表示するようにしています。
さらにレポート冒頭には、前回からの変化と「今週の確認優先TOP3」も表示します。
実際のレポートではこうなった
ある週のレポートでは、要確認記事が8件ありました。
その中で優先TOP3になったのが、
- Lossless Scalingの記事
- tModLoaderの記事
- Steamゲームを旧バージョンへ戻す記事
でした。
一方、PSVRの記事もアクセスが大きく落ちていました。
しかしPSVRは現在のブログ運営ではかなり古いテーマです。
そこで、
「検出は続けるが、人間側の運営方針として記事改修の優先対象から外す」
という設定を追加しました。
AIや数値が「問題あり」と判断したからといって、必ず記事を修正する必要はありません。
限られた時間をどの記事へ使うかは、最終的には人間側の運営判断です。
実際に3記事を修正した
今回はレポートを作って終わりではなく、実際に候補になった3記事を修正しました。
Lossless Scalingの記事
Lossless Scalingの記事では、平均順位自体は大きく落ちていないのにCTRが大幅に低下していました。
そこで、以前の短い対処法記事を2026年版として更新しました。
Chromeのグラフィックアクセラレーション設定の最新スクリーンショットを追加し、黒画面になる場合の切り分け、Capture API、DRMとの関係、直らない場合の確認項目まで内容を拡張しました。
Lossless Scalingでアニメを滑らかに見たいのに画面が真っ暗？その原因と対処法
tModLoaderの記事
tModLoaderの記事は2022年当時、「日本語化するために1.3へ戻す」という内容が中心でした。
現在は状況が変わっているため、
「古い1.3用MODを使うために1.3 Legacyへ切り替える方法」
として内容を整理しました。
Steamの現在の画面で「1.3-legacy」を選択するスクリーンショットも撮り直しています。
tModLoaderを1.3 Legacyへバージョンダウンする方法
Steamゲームの旧バージョン化
Steamの旧バージョン取得記事には、2020年当時のDepotDownloader手順が残っていました。
当時はbatファイルへSteamパスワードを書いていましたが、2026年現在はこの方法をおすすめできません。
そこで古い手順を削除し、SteamDBでApp ID・Depot ID・Manifest IDを確認し、現在のDepotDownloaderとQRログインを使う構成へ変更しました。
コマンド操作が難しい人向けには、以前作成したDepotDownloader GUI Helperの記事へ案内するようにしています。
DepotDownloader GUI Helperの使い方
毎週金曜日19時に自動実行
ここまでの処理は、Windowsのタスクスケジューラから毎週自動実行するようにしました。
現在は毎週金曜日19時に実行します。
その時間にPCが起動していなかった場合も考慮しています。
スケジュールされた時刻に実行できなかった場合は、次に実行可能になったタイミングで処理を開始する設定です。
また、処理が長引いた場合に同じタスクが重複起動しないよう、すでに実行中なら新しいインスタンスを開始しない設定にしています。
実行中のPowerShellやHermes Agentなどのウィンドウは表示しないようにしています。
生成された人間向けレポートは別ドライブへまとめています。
K:\BlogReports\SearchConsole\WeeklyReports\
そのため普段は、週末に最新のレポートを見るだけです。
ローカルAIに全部任せない方がうまくいった
今回作ってみて、一番大きかったのはここです。
AIエージェントだからといって、すべてAIに判断させる必要はありません。
現在は、
- 数値比較 → Python
- データ取得 → API
- 状態管理 → Python
- 形式チェック → Validator
- 検索意図や文章の意味 → ローカルLLM
- 最終判断 → 人間
と役割を分けています。
ローカルLLMは便利ですが、毎回必ず意図したJSONを返すとは限りません。
だからこそ、AIが失敗した場合でも分析全体が壊れない設計にしておくことが重要だと感じました。
ローカルAIを使う意味
この程度の分析なら、Search ConsoleのCSVをChatGPTへ渡して分析してもらうこともできます。
単発で深く分析したいだけなら、その方が簡単です。
今回ローカルAIを使った理由は、毎週自動的に繰り返したかったからです。
人間がCSVをダウンロードして毎回AIへアップロードするのではなく、
PCが自動取得 ↓ Pythonで候補抽出 ↓ 必要な部分だけローカルAIが分析 ↓ Validatorで確認 ↓ レポートを保存
まで自動で進みます。
この「毎回人間が操作しなくてよい」という部分が、ローカルAIエージェントを使う大きなメリットだと思います。
まとめ
今回はGoogle Search ConsoleとローカルAIを組み合わせて、ブログ記事を毎週チェックする仕組みを作りました。
最終的な構成は、
Search Console API ↓ Python ↓ 候補記事抽出 ↓ 検索クエリ＋記事内容取得 ↓ Gemma 4 12B ↓ Validator ↓ 状態管理 ↓ 週次レポート ↓ 人間が判断
です。
実際に運用した結果、Lossless Scaling、tModLoader、Steam旧版化の記事が改善候補として浮かび上がり、3記事とも内容を更新しました。
一方、アクセスが落ちていても現在は優先度が低いPSVR記事は、監視だけ残して改修対象から外しています。
AIの判断をそのまま採用するのではなく、数値処理はプログラム、意味判断はAI、運営判断は人間という分担が、今のところ一番使いやすい形になりました。
今後しばらく週次レポートを蓄積し、今回修正した記事のCTRや検索流入が実際に改善するかも追ってみたいと思います。
コメント