X（旧Twitter）で「Hermes Agent（AIエージェントCLI）にGoogle Search ConsoleとGoogle Analyticsを接続して、SEO運用を自動化する」という投稿が流れてきました。内容を実際に読み解き、同じ時期に自作していたエージェントループ（AIKnowledgeCMS）と比較しながら、使えるノウハウと注意点をまとめます。
元投稿の要点
投稿者は「Hermes AgentをSEO担当として運用する」設計を提案しています。骨子はこうです。
- Hermesのプロファイルを1つ作る（
hermes profile create seo-agent） - SOUL.md（性格設定ファイル）に役割を書く——「あなたはSEO担当です。検索パフォーマンスを毎日監視し、順位下落と機会をフラグし、Search Consoleのデータに基づいて記事を書いてください」
- GSC/GAをMCP経由で接続する——ComposioまたはClawLinkという2つのマネージドサービスのどちらかを使い、OAuth一発でSearch ConsoleとAnalyticsの両方に接続できるとしています
- cronで定期実行する——週次レポート（月曜朝）、日次インデックス確認（毎朝）、コンテンツ機会スキャン（週次）の3種類
- タスクごとにモデルを使い分ける——ルーティンな監視は安価なモデル、記事執筆は高性能モデル
具体的な自動化指示の文面も紹介されており、たとえば週次レポートは次のような自然言語プロンプトになっています。
過去7日間の検索アナリティクスを取得。前週と比較。5位以上下落したキーワードをフラグ。クリックが20%以上減ったページをフラグ。Telegramにレポートを送信。
コンテンツ機会スキャンはこうです。
自サイトが2ページ目（11〜20位）に表示回数の多いクエリで出ているものを探す。これは良い記事1本で1ページ目に押し上げられるキーワード。トピック案つきでTelegramに送る。
「SEO代行会社（月$1,000〜5,000）・SEOツールサブスク・手動レポート・手動リサーチ」を全部代替する、という謳い文句でした。
自作のAgent Loopと比較してわかったこと
同じ時期に、Webサイト成長のためのループエンジニアリング・フレームワーク（AIKnowledgeCMS）を自作していました。SENSE→RESEARCH→TRIAGE→CREATE→DISTRIBUTEの6ステージを1tickとして回し、Google Search Consoleの検索アナリティクスをセンサーとして取り込み、記事を自動生成・検証・公開するところまで実装していたところでした。
投稿と自作ループを並べると、骨格はほぼ同じであることがわかります。
| 要素 | 投稿の提案 | 自作ループ |
|---|---|---|
| GSC/GA接続 | Composio/ClawLink（外部MCPサービス） | gcloud ADC + Search Console APIを直接呼ぶ（追加サービス不要） |
| 定期実行 | Hermesのcron |
systemdのuser timer（1時間おき） |
| 判断ロジック | SOUL.md＋自然言語プロンプト任せ | ルールベースのTRIAGE＋予算上限＋品質ゲート |
| 記事生成 | Hermes本体（Claude/GPT系） | ローカルLLM（Ollama）、生成者と検証者を別呼び出しで分離 |
| 通知 | Telegram | メール＋SNS投稿 |
「エージェントに検索データを見せて記事を書かせる」という発想自体は同じところに行き着くのだと実感しました。一方で、実装の選び方には明確に違いが出ます。
参考になった点
順位の「帯」で機会を判定する発想は取り入れる価値があります。自作ループの機会検知は「表示回数は多いのにクリック率が低いクエリ」だけを見ていましたが、投稿にあった「2ページ目（11〜20位）に出ているクエリ」という条件は、より的確に「あと一押しで1ページ目に届く」キーワードを拾えます。順位データを取得している以上、この条件を足すのは自然な拡張です。
下落の早期検知という発想も参考になります。「前週比で順位が5位以上下がったキーワード」「クリックが20%以上減ったページ」をアラート条件にする、という具体的な閾値の置き方は、既存の「PV下落検知」ルールに順位下落の軸を追加する形でそのまま使えます。
タスクごとにモデルを使い分けるという考え方も理にかなっています。定型的な監視処理には軽いモデル、実際に人に読ませる記事の執筆には性能の高いモデルを充てる、というのは自作ループでも「生成者と検証者を別モデル呼び出しにする」形で既に取り入れていた発想でしたが、コスト最適化の軸としても改めて有効だと確認できました。
そのままでは採用しなかった点
外部MCPサービス経由の接続は見送りました。ComposioやClawLinkは便利ですが、多くの場合サブスクリプション課金が発生する外部SaaSです。GSCのAPIはサービスアカウントやOAuthのクレデンシャルさえあれば無料で直接叩けるため、わざわざ課金レイヤーを挟む理由がありませんでした。自前運用のコストゼロという利点を手放すことになります。
自然言語プロンプト任せの判断も、SEO運用の主軸には据えませんでした。汎用エージェントに「SEO対策して」と大きく指示すると、何を実行するかの予測可能性が下がります。実際に運用する中でも、モデル名の解釈のずれのような細かい挙動不一致が繰り返し起きました。定期実行かつ自動公開を伴う運用では、予算上限・実行前のドライラン・強制停止スイッチ・生成物を検証してから公開するゲートの4点を、エージェントの裁量ではなく仕組み側に固定しておくほうが安全に運用できます。
Kurageプロジェクトへの応用
このノウハウは今後、次の2点に反映していきます。
- 検索順位（position）のデータを機会検知の条件に追加し、「2ページ目にいる高表示回数クエリ」を優先的に記事化する
- 順位下落・クリック減少をTRIAGEのアラート条件に追加し、既存のPV下落検知と並べて運用する
いずれも「エージェントに丸投げする」のではなく、「エージェントが判断する範囲を絞ったルールの中に、良いアイデアだけを取り込む」形での反映です。
参考
- https://x.com/IBuzovskyi/status/2073490805138812970