AIエージェント(私の場合はClaude Code)にブログのメンテナンスを任せていると、いずれ「どの記事を残し、どれを非公開にするか」という判断まで任せたくなります。数百・数千の記事を人力で仕分けるのは現実的でないからです。
しかし、この「取捨選択の自動化」には落とし穴があります。AIは記事を一つずつ、その場の基準(文字数、キーワード、テーマ適合)で機械的に判定します。その結果、実際には検索流入を稼いでいる記事を、機械的な基準だけで「消す側」に分類してしまうことが起きます。
実際に私のサイトで起きたことと、それを Google Search Console API で防いだ話を書きます。AIにサイト運用を任せている人には、参考になるはずです。
何が起きたか:機械判定が稼ぎ頭を「非公開候補」にした
記事の自動仕分けを走らせたところ、あるスクリプトが約700記事を「残す/リライト/非公開/削除」に分類しました。判定基準は、テーマがサイトの主軸に合っているか、一次情報(実体験・実験・実測)を含むか、といったものです。
ところが結果を見ると、サイトで最もクリックを稼いでいる記事が「非公開候補」に分類されていました。過去28日で36クリック・726表示という、回復期のサイトでは突出した数字を出している解説記事です。
なぜ消す側に入ったのか。原因は、その記事が「用語を解説するQ&A形式」で、「自分で機械を動かした」といった体験キーワードを含まないため、一次情報スコアがゼロと判定されたからでした。専門知識にもとづく解説であっても、機械判定は「体験の記述」しか価値として拾えなかったのです。
もしこの判定をそのまま実行していたら、サイト最大の資産を自ら非公開にして、貴重な検索流入を失っていました。
解決策:Search Console API を「判定のゲート」に組み込む
問題の本質は、判定がサイト内部の情報(文字数・キーワード)だけで下されていたことです。「Googleが実際にその記事をどう評価しているか」という外部の客観データが、判定に入っていませんでした。
そこで Google Search Console API を接続し、全記事のクリック数・表示回数・平均掲載順位を取得して、判定ロジックに組み込みました。ルールはシンプルです。
機械判定が「非公開」や「削除」でも、Googleが実際にクリックや表示を発生させている記事は、自動的に「要再確認」へ格上げする。
これを入れた結果、機械判定では消す側だった記事のうち17件が、GSC実績によって救済されました。冒頭の稼ぎ頭の記事も、この仕組みで正しく残す側に戻りました。「Googleが評価している」という事実は、こちらが設計した機械基準よりも信頼できる、というのが教訓です。
Search Console API 接続の要点
具体的な接続方法を、つまずきやすい点を中心にまとめます。詳細な画面手順は公式ドキュメントに譲り、ここでは「実際にやって分かったこと」に絞ります。
認証はサービスアカウント方式が扱いやすい
個人アカウントのOAuthではなく、Google Cloudで「サービスアカウント」を作り、そのメールアドレスをSearch Console側の権限に追加する方式が、自動化には向いています。人が毎回ログインする必要がなく、スクリプトから直接叩けます。
手順の骨子は次の通りです。
- Google Cloudで Search Console API を有効化する
- サービスアカウントを作成し、JSONキーを発行する(ロールの付与は不要)
- Search Consoleの「ユーザーと権限」で、そのサービスアカウントのメールアドレスを追加する(読み取りだけなら「制限付き」で十分)
Google Cloud側とSearch Console側で別々のGoogleアカウントでも問題なく連携できます。サービスアカウントのメールアドレスが橋渡しになるためです。
認証情報の扱いは最初に決めておく
JSONキーは、それ一つで自分のSearch Consoleデータにアクセスできてしまう機密ファイルです。私は以前、認証情報の扱いが甘くて痛い目を見たので、今回は最初から次のルールで運用しました。
- JSONキーはプロジェクトフォルダの外(例: ユーザーフォルダ配下の隠しフォルダ)に置く
- キーのパスは環境変数で渡し、コードには直書きしない
- バージョン管理を使うなら、キーやデータCSVは除外設定(
.gitignore)で確実に外す
.gitignoreは最後の防御線であって、そもそも機密ファイルをリポジトリの中に置かないのが安全です。
プロパティ形式の指定に注意
APIに渡すサイトURLの形式は、Search Consoleのプロパティ種別と一致させる必要があります。サイト全体を登録する「ドメインプロパティ」なら sc-domain:example.com、URL単位で登録する「URLプレフィックスプロパティ」なら https://example.com/ です。ここがズレると、権限エラーか空データになります。最初の接続テストでつまずくポイントの筆頭です。
環境変数はプロセスの再起動が必要
環境変数を永続設定しても、既に起動しているツールにはすぐ反映されません。環境変数はプロセス起動時に読み込まれるため、設定後はツール(ターミナルやエディタ)を土台ごと再起動する必要があります。「設定したのに読めない」ときは、たいていこれが原因です。
AIに任せる判定に、必ず「客観データのゲート」を置く
今回の一件で得た、いちばん大事な考え方はこれです。
AIエージェントに記事の取捨選択を任せるなら、その判定に必ず外部の客観データを噛ませる。 AIの判定は、こちらが与えた基準を忠実に実行するだけで、その基準自体が現実とズレていても気づきません。文字数やキーワードは「サイトの内部から見た記事の姿」にすぎず、「検索エンジンから見た記事の価値」とは別物です。
Search Console のクリック・表示・掲載順位は、まさにその「外から見た価値」を数字で教えてくれます。これを判定のゲートに置くだけで、「機械的には消す対象だが、実は価値がある記事」を取りこぼさずに済みます。
AIによる自動化は強力ですが、その判断を鵜呑みにすると、今回のように資産を自ら手放しかねません。自動化するほど、その判断を検算する客観的な足場を用意しておく。これが、AIにブログ運用を任せる時代の実務的な鉄則だと思います。
この記事は、実際に自分のブログ運用でAIエージェントと Search Console API を組み合わせた事例をもとにしています。ツールの仕様や画面構成は変更される場合があるため、API接続の具体手順は各サービスの公式ドキュメントで最新情報を確認してください。
コメント