SEOでAIを使う価値は、記事を一度速く書くことだけではありません。検索結果を観測し、次の仕事を選び、制作し、検証し、その結果を次回へ戻すループを作ると、少人数でも改善を止めにくくなります。
ただし、完全自動公開は勧めません。Googleも、生成AIで価値を足さず大量ページを作る行為はスパムポリシーに抵触し得ると案内しています。ここでは、証拠と停止条件を先に置く安全なループを設計します。
不合格なら公開せず修正へ。合格しても、28日後の実測が次の入力になる。
SEOのループエンジニアリングとは何ですか？
AIエージェントが「観測→選定→制作→検証→学習」を繰り返せるよう、入力、道具、合格条件、停止条件、人の承認を設計することです。
プロンプトエンジニアリングが1回の指示を改善するのに対し、ループエンジニアリングは反復する仕事全体を設計します。SEOでは、公開後のGSCデータが次の改善材料になるため相性があります。
HerdrはSEOで何をするツールですか？
Herdrは複数のCLIエージェントをターミナル上で動かし、状態を一覧化し、接続を保ったまま管理するエージェント・マルチプレクサです。 SEOツールそのものではなく、Codex、Claude Code、Grok CLIなどの作業者を並行運用する制御面として使います。
たとえば、調査担当がGSCとAhrefsの候補を整理し、制作担当がMDXを更新し、検証担当がbuild・リンク・モバイル表示を確認する形です。HerdrのローカルAPIからペイン作成、出力確認、完了待ちを行えます。
どのAPIをつなげればよいですか？
| 工程 | データ・道具 | 返すもの |
|---|---|---|
| 観測 | Search Console API | query、page、clicks、impressions、CTR、position |
| 競合確認 | Ahrefs API | Volume、KD、Traffic Potential、競合URL |
| 制作 | リポジトリ／CMS API | 記事差分、メタ情報、内部リンク |
| 検証 | build、Lighthouse、リンク検査 | 成否、エラー、表示証拠 |
| 学習 | 改善ログ | 仮説、変更、28日後の結果 |
Search Console APIは上位データを返す仕組みで、全行を保証しません。したがって「APIに出なかった＝検索需要がない」とは判断しないでください。
実際のループはどう設計しますか？
まず1回の仕事を、次の仕様書にします。
goal: "表示回数がある7〜15位の記事を1本改善する"
inputs:
period: "直近28日と前28日"
minimum_impressions: 100
selector:
- "事業に関連する"
- "既存記事と検索意図が重複しない"
maker:
- "見出し直下に直接回答を置く"
- "一次情報か具体例を1つ追加する"
verifier:
- "build成功"
- "内部リンク切れ0"
- "PCと390pxで表示確認"
human_gate:
- "公開"
stop:
retries: 2
daily_budget_yen: 1000
review_after_days: 28重要なのは、makerより先にverifierとstopを書くことです。「よい記事にする」では合否を判定できません。
MakerとCheckerはどう分けますか？
制作担当は変更し、検証担当は証拠だけを判定します。 同じエージェントに自己採点させる場合も、新しいコンテキストでチェックリストと差分を渡します。
- Maker：構成、本文、図解、内部リンクを変更
- Checker：出典、数値、検索意図、build、表示を確認
- Human：公開、法務、ブランド、費用の例外を承認
自動で再試行させるのは、formatやbuildのように判定が明確な失敗だけにします。事実の食い違いや検索意図の判断は、人へ上げます。
記事量産にならないための停止条件は？
次のどれかに当たったら止めます。
- 独自の証拠や具体例を追加できない
- 既存記事との検索意図の重複が高い
- 出典の取得日・条件を記録できない
- 2回修正しても検証を通らない
- API費またはレビュー時間が上限を超えた
- 公開後の評価日が未設定
最初に自動化するなら何がよいですか？
最初は「候補の抽出」までがおすすめです。GSCから表示回数、CTR、順位を取得し、改善候補を一覧化。人が1本選び、制作と公開を行います。候補選びが安定してから、構成案、差分作成、表示検証へ広げます。
全体の設計はマーケターのAI技術スタック、SEOの優先順位はひとりマーケターのSEO完全ガイドへ続きます。