取り下げ済み記事へのリダイレクトを公開後チェックが誤検知した
今回やったこと
取り下げた記事のURLからトップページへ301リダイレクトする運用で、公開後チェックが意図した応答を配信事故と誤判定する問題を修正した。チェックはURLを取得し、記事タイトルが応答に含まれるかを確認していた。301の転送先がトップページなら、記事タイトルが見つからないのは当然だが、検査はそれを本文消失として扱った。結果として、実際には意図したリダイレクトが動いているのに、空振りのアラートや督促が続いた。
修正では、取り下げ済みの記事を公開後チェックの対象から除外する理由判定を追加し、レビュー手順にもリダイレクトの挙動を明記した。URLの応答だけを見るのではなく、その記事が現在どの状態にあるかを確認してから、応答を評価する形に変えた。
HTTPの応答だけでは異常を決められない
公開後の監視は、読者が記事を開けるかを確認する重要な工程だ。ただし、監視が取得した本文は、そのURLに期待される内容かを文脈なしに示すものではない。取り下げ済みの記事では、旧URLを残したまま別ページへ案内することがある。301に従って転送先を取得すると、最終応答は成功でも、本文は元記事とは別のページになる。
チェックが「HTTP取得に成功したか」と「期待した記事本文が表示されたか」を区別しない場合、正常な転送を本文消失と誤認する。今回の監視はタイトルの有無を主な手掛かりにしていたため、リダイレクト先のトップページを見て異常と判断した。応答コードだけを判定に追加しても十分ではない。旧URLの状態と、転送が意図されたものかを合わせて解釈する必要がある。
| 状態 | URL取得で見えるもの | 判定の考え方 |
|---|---|---|
| 公開中の記事 | 記事本文とタイトル | 記事の内容を確認する |
| 取り下げ済みで転送あり | 転送先ページの内容 | 取り下げ状態と転送先を照合する |
| 公開中なのに本文がない | 期待するタイトルがない | 配信異常として調査する |
同じ「タイトルが見つからない」という結果でも、記事の状態によって意味が変わる。監視条件は結果の文字列だけでなく、対象の状態を入力に含めなければならない。
対象外にする理由を機械で共有する
取り下げ済みの原稿を検査から外す判断を、各レビュアーの記憶や個別のプロンプトだけに任せると、別のレーンで同じ誤報が起きる。そこで、取り下げ状態と対象外にする理由を返す共通処理を設け、公開後チェックの入り口で利用する。レビュー指示にも同じ例外を記載し、手動で調査する場面でも意図したリダイレクトを事故扱いしないようにした。
この仕組みで大切なのは、取り下げを曖昧な「見なくてよい印」にしないことだ。対象外にする根拠を持ち、対象の状態が確認できる場合にだけ検査を省く。該当する状態が確認できない場合は、通常のチェックへ回す。これにより、すべての301を正常扱いするような広すぎる例外を避けられる。
また、通知件数が多いこと自体を障害の深刻さと同一視しない方がよい。繰り返し通知は、根本原因を解消していないサインにもなる。今回のように同じ対象から同じ誤判定が反復するなら、通知文面を調整するだけでなく、検査前の対象選定に状態の条件が足りているかを調べる必要がある。
やってみてわかったこと
公開後チェックは、ページが応答するかを確認するだけではなく、「そのページが今どの状態にあるべきか」と実際の挙動を照らし合わせるものだ。取り下げた記事には記事本文を期待せず、設定した転送が意図どおり働いているかを見る。公開中の記事には引き続き本文の確認を行う。対象の状態によって検査内容を変えることで、誤報を減らしながら異常検出を保てる。
監視ルールを追加するときは、正常な記事だけでなく、取り下げ、移転、転送、削除のような状態変化も想定する。例外がある場合は、個別の運用メモに閉じず、判定ロジックとレビュー手順の両方へ反映する。そうすれば、運用の担当や実行レーンが変わっても同じ状態を同じように扱える。
更新履歴
- 2026-10-07: 初稿。取り下げ記事のリダイレクトを公開後チェックが誤検知した事例を整理。
訂正履歴
なし。