順位モニターが週に 40 件のアラートを送ってくるなら、あなたはそれを読まなくなる。逆に 1 件も送ってこないなら、順位の下落は商談の電話で初めて知ることになる。どちらも失敗の形は同じです。どの変化が対応に値するのかを、誰も定義していないのです。
これは監視ループの解説記事ではありません。週次の Hermes ループの回し方はすでに公開していますし、その内容に今も変わりはありません。この記事が扱うのはもっと狭く、そしてはるかに合わせにくい部分、つまりアラートの設計です。帯の切り方を間違えると、ループはただの儀式になります。
おそらく起きている問題
あなたのモニターは壊れていない可能性が高い。問題は、間違った対象を間違った量で報告していることです。
スキルファイルに手を入れる前に、この 4 つの症状を確認してください。
症状 | 通常意味すること |
|---|---|
週に 10 件以上のアラートが来て、そのどれにも対応していない | しきい値の帯がない。モニターが変更履歴であって、アラートの仕組みになっていない |
順位は安定して見えるのにクリックが減っている | 順位だけを監視していて、動いたのはクリックやブランドに関わるシグナル |
月曜の朝に全部アラートが鳴る | 単日比較になっている。週末のデータはノイズが多く、狭い帯なら必ず引っかかる |
アラートが届く頃には修正がすでに出ている | 実行頻度は週次なのに変更サイクルは日次。トリガーの設計が合っていない |
この表の 2 行が自分の環境に当てはまるなら、対処は下の 4 つの変更で共通です。どれも新しいツールを必要としません。
改善 1:「あらゆる変化でアラート」を 3 つの帯に置き換える
使えるモニターの状態はきっかり 3 つで、真ん中があるからこそ運用に耐えます。
帯 | 定義(例) | エージェントの動作 |
|---|---|---|
レポート | 順位が 3〜5 変動、または表示回数が 10〜30% 変動 | 週次レポートに書くだけ。通知はしない。 |
注視 | 順位が 6〜10 変動、またはページがトップ 20 から外れる | 該当した日付とともに注視リストへ追加する |
対応 | 順位が 10 以上変動、または稼ぎ頭のクエリが 1 ページ目から外れる | 通知を 1 件だけ送る。ページとクエリを添えて。 |
この帯が機能する理由は 3 つあります。数値で書かれていること、頭の中ではなくスキルファイルに保存されていること、そして「対応」の帯が意図的に狭いことです。「対応」が週に 2 回を超えて鳴るなら、帯が広すぎます。

帯は 3 つ、通知チャネルは 1 つ。「対応」の帯は、あなたが読み続けられる程度に静かでなければなりません。
品質チェック: 帯を有効にする前に、先月のデータに当ててみてください。「対応」に入る行がいくつになるか数えます。月に 8 件を超えるなら、しきい値を動かします。
うまくいかない場合: トラフィックの少ないサイトでは、順位の帯だけでは永遠に鳴りません。表示回数の帯を主トリガーにし、順位を副次的なトリガーにしてください。
改善 2:クエリセットを凍結してグループ化する
クエリ一覧が毎週変わると、監視は必ず漂流します。四半期は凍結して、それから見直してください。
クエリは検索ボリュームではなく、すでに社内で使われている言葉でグループ化します。
- 稼ぎ頭のクエリ — 売上に直結するもの。ここには最も厳しい「対応」の帯を当てます。
- 比較クエリ — 購入を検討する段階のもの。競合が動けば動くので、アラートよりも注釈が必要になります。
- ブランドクエリ — 自社名や製品名。ここでの下落は SEO 以外の原因であることが多く、だからこそレポートに入れる価値があります。
- サポートクエリ — 既存顧客が答えを探すもの。商業価値は低い一方、コンテンツの劣化を示すシグナルは強くなります。
実用的な範囲は 20〜50 クエリです。20 を下回るとクラスターを見落とし、50 を超えると監視する面積が広すぎて「対応」が鳴りっぱなしになります。
改善 3:読む前に注釈を入れる
このワークフローで最も費用対効果の高い習慣は、2 分で終わります。週次レポートが生成される前に、出荷したものを短く書き残すのです。リリース、テンプレート変更、リダイレクト、価格の編集、PR の掲載などです。
注釈がないと、あらゆる変動が既定で SEO の説明をまとうことになります。火曜日のテンプレート変更が原因だったのに、チームが一週間アルゴリズム更新を追いかけるのはこうして起きます。
Hermes スキルはこの注釈を任意扱いではなく、入力として必須にすべきです。注釈がなければ、スキルは推測せず、ヘッダーに「変更履歴の提供なし」と明示してレポートを書きます。

注釈は分析の後ではなく、前に入ります。ワークフロー全体で最も安価な精度改善です。
改善 4:2026 年に実際に動いたシグナルを監視する
ここが、多くの監視設計が 1 年遅れている部分です。2026 年 9 月 9 日に公開された Zyppy の専門家調査は、131 人の実務者から 13,665 件のデータポイントを集めました。行動とクリックのシグナルは 29.4%、ブランドのシグナルは 27.0%、テクニカル SEO の健全性は 17.5% でした。この調査の盲点についてはページ対ブランドのギャップの解説で扱っていますが、モニターにとっての実務的な結論はそっけありません。順位だけを追っているなら、最も置き換えられやすいシグナルを追っていることになります。
費用をかける価値がある追加は 2 つです。
フラグが立ったクエリの表示回数あたりクリック数。 4 位を保ったまま表示回数が増えて CTR が落ちているクエリは、安定していません。劣化しています。そして順位はそれを教えてくれません。
ブランド検索を独立した行として持つ。 ブランド需要は SEO からは見えない理由で動き、他のあらゆる数値の読み方まで変えます。別行で追うことで、ブランド起因の流入変動をコンテンツの成果と取り違えずに済みます。
さらに進めて AI での引用状況を加えたいなら、独自のしきい値を持つ別セクションに置いてください。回答エンジンでの可視性を順位モニターに混ぜると、どちらも読みにくくなりますし、そもそも情報源として比較できません。
Hermes Agent のスキルとして作る
Hermes Agent はこの用途に向いています。同梱のスキルをセッションをまたいだ記憶とともに繰り返し実行できるので、週次のモニターがまさに必要とする性質です。まだ導入していなければ、Hermes SEO/GEO 運用ガイドでプロジェクトフォルダと承認ルールを扱っています。
スキルファイルに必要なのは 5 つのブロックです。
- 入力 — 先週のデータ書き出し、変更履歴のメモ、凍結したクエリ一覧。
- 帯 — 改善 1 の 3 つのしきい値を、数値で。
- グループ — 改善 2 の 4 つのクエリグループと、それぞれに適用する帯。
- 出力 — 決まった 3 セクションのレポートに、先週から繰り越す注視リストを加えたもの。
- 境界 — 読み取り専用、サイト変更なし、「対応」の帯以外では通知しない。
そのまま使える出発点:
## 順位モニターのスキル
入力: data/latest.csv, notes/change-log.md, queries/frozen-list.csv
実行頻度: 週次
帯:
- レポート: 順位が 3-5 変動、または表示回数が 10-30% 変動
- 注視: 順位が 6-10 変動、またはページがトップ 20 から外れる
- 対応: 順位が 10 以上変動、または稼ぎ頭のクエリが 1 ページ目から外れる
グループと帯の上書き:
- 稼ぎ頭: 6 ポジション以上で「対応」が鳴る
- 比較: 「注視」のみ、通知はしない
- ブランド: 「レポート」帯。別途フラグを立て、コンテンツの変動と混ぜない
- サポート: 「レポート」帯
出力: reports/monitor/YYYY-MM-DD.md
1. 帯を超えた変動行
2. 考えられる説明。入力の範囲内に限る。ファイルで説明できない場合は
「このデータでは説明できない」と書く。
3. 各行がいつ入ったかの日付つきの注視リスト
notes/change-log.md がなければ、ヘッダーに「変更履歴の提供なし」と書く。
サイト変更を提案しない。reports/monitor/ の外のファイルを編集しない。週次で実行してください。レポートは一度読みます。動くのは「対応」の帯だけで、しかも 2 週続けて同じ説明がついた行に限ります。
完了の形: 先月いくつのアラートが鳴り、そのうちいくつが行動になったか、検知までの平均時間はどれくらいかを言える状態です。この 3 つに答えられないなら、モニターはまだログにすぎません。
この帯の設計は、私が 2 度やらかした失敗から出てきました。最初に組んだモニターはあらゆる順位変動でアラートを出し、1 か月で無視する癖がつきました。2 つ目は何も鳴りませんでした。「対応」の帯を、自分の 10 倍のトラフィックがあるサイト向けに設定していたからです。上のバージョンは 3 度目の試みで、唯一今も読んでいるものです。
モニターが改善したかを測る
これが効いたかどうかは 3 つの数値でわかります。どれも順位ではありません。
指標 | 導入前 | 4 週間後の目標 |
|---|---|---|
月あたりのアラート数 | 20〜40 | 4〜8 |
判断につながったアラート | 0〜2 | その半分 |
下落から検知までの時間 | 2〜6 週間 | 1 週間 |
アラートは減ったのに判断が増えないなら、モニターが静かなのではなく「対応」の帯が狭すぎます。1 段広げて、もう 1 か月回してください。
使わないほうがよい場合
出力の持ち主がいないなら、この仕組みごと飛ばしてください。誰も読まない週次レポートは、レポートがない状態より高くつきます。順位の仕事は対応済みだという印象だけを生むからです。
1 日の表示回数が数百に満たないサイトも飛ばしてください。その規模では週次のモニターではなく月次の前年比較を使ってください。シグナルがまだ出ておらず、鳴りようのないしきい値の調整に時間を溶かすことになります。
FAQ
有料の順位トラッカーは不要になりますか? いいえ。Search Console がカバーするのは自社プロパティで、このモニターが必要としているのはまさにそれです。有料トラッカーが足すのは競合の順位、日次の実行頻度、自社データでは見えない地域です。まず無料で始め、基準ではなく比較が必要になったらトラッカーを足してください。
週に何件のアラートが普通ですか? 1 日の表示回数が数千のサイトなら、月 4〜8 件が実用範囲です。週 2 件が妥当な上限で、それを超えると帯が狭すぎます。
モニターは日次と週次のどちらで回すべきですか? レポートは週次、日次にするのは「対応」の帯だけです。日次レポートは日次の読解を生み、監視が安全策ではなく仕事になってしまいます。
Codex や Claude Code でも同じ設計を回せますか? 回せます。帯、グループ、注釈、出力の形はエージェントに依存しません。違うのはファイルの慣習だけなので、Codexと Claude Codeの手順は分けて書いています。
クエリが「対応」の帯で鳴ったときは何をしますか? まずページを見て、それから SERP を見ます。ページが正常で SERP の形が変わっているなら、必要なのは多くの場合、書き直しではなく別のコンテンツか別の形式です。AI SEO プラットフォームが順位の推移をどう追うかの記事で、確認の順序を扱っています。
著者:Camille Rhodes、Auspia で 300 以上の AI コンテンツワークフローを設計。ワークフロー設計、自動化の境界、そして AI 支援の SEO 作業を有用に保つレビュー手順について書いています。




