やりたかったこと：直したページだけを検索エンジンに知らせる
私たちは自社の静的ブログを毎朝まとめて作り直し、配信しています。更新は IndexNow という仕組みで検索エンジンに知らせています。
ねらいは「変わったページだけ送る」ことでした。毎回全ページを送ると、実際には何も変わっていないページまで「更新した」と伝えてしまいます。そこで前回の版とページごとに比べ、変わったものだけを送るように切り替えを付けていました。
送りすぎを防ぐ歯止めも2つ置いていました。
- 件数の上限：50件
- 全体に対する割合の上限：50%
どちらかを超えたら「サイト全体の変更」とみなして、その回は送りません。テンプレートの一括変更などで大量に送ってしまうのを防ぐためです。
何を見たか：毎回「提出 0 件」で止まっていた
ある日の記録はこうでした。
対象 190 URL / 提出対象 0 URL
変わったページが 186 件で上限（50件）を超えた＝全体の変更と判断して送らない
190ページ中186ページが「変わった」と判定され、件数の上限に当たって送信は0件です。もう1つのサイトでも同じことが起きていて、29ページ中28ページ（97%）が「変わった」と判定され、今度は割合の歯止めで0件になっていました。
おかしいのは、記事を1本直しただけの日でも毎回こうなる点です。直したのは1ページなのに、判定では186ページが変わったことになっていました。「変わったページだけ送る」は、入れてから一度も働いていませんでした。
この不具合は見つけにくい形をしていました。ログに出ているのは「上限を超えたので送らない」という、歯止めの設計どおりの動作です。エラーも出ていません。止まっている理由が正常な動作に見えるので、読み流してしまいます。
何が分かったか：判定の入力に、毎回変わるものが混ざっていた
原因は、変更を判定するための入力にありました。
サイトを作り直すとき、全ページに「どの版か」を表す印を1つ埋め込んでいます。この版は、入力が1つでも変われば変わります。そのため記事を1本直すと全ページの印が変わり、ページごとの指紋（本文のハッシュ）も全部変わります。
結果として、判定は毎回「ほぼ全ページが変わった」と読み、歯止めも毎回作動して、送信は0件になっていました。
整理するとこうなります。
歯止めは正しく働いていた。入力が間違っていた。
歯止めを疑って上限を緩めていたら、毎回ほぼ全ページを送る状態になり、送りすぎを防ぐという本来の目的を自分で壊すところでした。直すべきなのは判定に渡す入力のほうです。
どう直したか：3つの修正と、それを確かめる試験
直したのは次の3点です。
- 指紋を取る前に、毎回変わる印を取り除く。 版の印を外した本文でハッシュを取り、本当に中身が変わったページだけが「変わった」と判定されるようにしました。
- 指紋の作り方に版番号を付ける。 作り方を変えると、古い指紋（印込み）と新しい指紋（印抜き）を比べることになり、また全ページが「変わった」と出てしまいます。前回の記録と作り方の版が違うときは比べずに、記録を作り直すようにしました。
- 配信ディレクトリの指定を、絶対の場所でも相対の場所でも受け付ける。 絶対の場所を渡すと内部でつながって存在しない場所になり、何も言わずに「無い」扱いになっていました。
試験は27件です。中でも次の2つが今回の要になります。
- 版の印だけが変わった日は、提出が0件になること
- 本文が1本だけ変わった日は、その1本が選ばれること
前者がないと「印で全部変わった」に戻ってしまったことに気づけず、後者がないと「変わったページだけ」が働いているかを確かめられません。
直した後の実際の回
修正直後の本番の回では、こう出ました。
提出対象 1 URL（日付由来 0 / 本文由来 1）
HTTP 200
本文だけを直したページが通知されたのは、これが初めてです。 修正前なら186件と判定されて0件になっていたはずの回です。
2026-10-15 の回はこうでした。
| 項目 | 値 |
|---|---|
| 対象 | 36 URL |
| 提出 | 5 URL |
| 日付由来 | 5 |
| 本文由来 | 30 |
| 結果 | HTTP 200 |
この回は本文由来の30件が全体の83%にあたり、割合の歯止めが作動して送られませんでした。日付由来の5件だけを送って HTTP 200 です。歯止めは外していませんが、送るべきものは送れています。今回の修正で狙ったのはこの状態でした。
業務に置き換えると
更新通知に限らず、「差分だけ処理する」「多すぎたら止める」という仕組みには同じ落とし穴があります。点検する項目を挙げます。
- 歯止めが毎回作動していないかを数字で見る。 送りすぎ・処理しすぎを止める仕組みを入れたら、作動した回数も記録してください。毎回作動しているなら、歯止めではなく入力を疑います。
- 変更の判定に、毎回変わるものを混ぜない。 ビルド番号や生成時刻がデータに入っていると、全件が「変わった」に見えます。比べる前に取り除いてください。
- 判定の作り方を変えたら、古い結果と混ぜて比べない。 判定の記録に版を付け、版が違えば比べずに作り直します。
- 「0件でした」を正常と読まない。 0件になった理由をログに出してください。上限で止めたのか、本当に変更が無かったのかで、取る対応が変わります。
- 場所の指定は、黙って「無い」にしない。 指定した場所が見つからないときは、0件として進めずに止めて知らせる形にしておくと、気づくのが早くなります。
この記事は、TechAthletes が自社のサービスを作る中で記録した実測をもとに書いています。業務への導入のご相談は 仕事の窓口 で受け付けています。