下書き保存で止めたら、誤投稿が起きなくなった

監査は「公開OK」と出ていた。
でも、俺はまだ保存しなかった。

前回、SEOレビューを重ねていったら、探していたのは精度ではなくなっていた話を書いた。
判断が出た後にも、実際に保存するまでもう一段、確認する場所が残っていた。

この記事で見ているのは、下書き保存そのものの手順ではない。公開OKが出たあと、すぐ保存せずに一度止めたことで、SEO情報のズレや誤投稿を防げた話である。

下書き保存のあとに残るDB登録、目次反映、series更新、内部リンク施工の分離は、次の記事「下書き保存で止めたら、公開後の工程が混ざらなくなった」で書いた。

監査は「公開OK」と出ていた。でも保存はまだしなかった

記事は、以前の記事「目次と内部リンクで、ブログを記事の集まりからサイトに変える」だった。
content_managerの品質チェックは終わっていた。
判定は公開OK。

それでも、その回のログには続きがあった。
「WP下書き保存はまだ未実行」と、わざわざ書き添えられていた。

チェックが通った瞬間に保存するものだと思っていた。
実際はそうならなかった。

監査が終わった直後の記録を見返すと、判定と保存が同じタイミングでは動いていない。
判定はもう出ている。
保存はまだしていない。

このズレを作る意味が最初は分からなかった。
判定OKなら保存すればいい、と単純に考えていたからだ。

だが記録を追っていくと、保存を保留している間に、もう一度手が入っていた。

保留していた間に直っていたのは、SEOコメントブロックのメタディスクリプションだった。
カルテのSEOレビュー欄には、監査後に確定した文言が入っている。
下書きファイルの冒頭に置くSEO情報のブロックは、まだそこに追いついていなかった。

先に確定させたのはカルテ側の文言だ。
下書きファイル側は、そのあとで合わせにいった。

順番を間違えると、この2つはずれたまま保存されてしまう。

実際の手順はこうだった。
下書きファイルのSEO情報コメント（title_tag・メタディスクリプション）を、カルテのSEOレビュー欄と一致させる。
一致を確認してから、post_draft.pyを実行する。

保存はこの確認の後に置かれていた。
確認の前には置かれていなかった。

一致させる作業そのものは地味だ。
だがこの地味な一手が、保存のタイミングを決めていた。

もし監査直後、メタディスクリプションを直す前に保存していたらどうなっていたか。
WPの下書きには、カルテの最終版とは違う文言が乗ったままになる。
下書きだから、まだ公開ではない。

それでも、確認すべき文面が本文とずれたまま残る。
その状態に気づかず次の工程に進めば、ずれた文言のまま公開に近づいていく。
これが、俺の考える「誤投稿」の中身だ。

派手な事故ではない。
静かに、気づかれないまま起きる食い違いだ。

前回の「SEOレビューを重ねていったら、探していたのは精度ではなくなっていた」でも同じ保留が起きていた。
監査は終わっていた。
それでも、post_draft.pyの実行はChatGPTのレビュー結果を待つ間、保留されていた。

さらにその後、実行はもう一段待たされた。
今度は俺（henshucho）の内部リンクの判断が終わるまでだった。

保存を保留する理由は毎回同じではない。
SEOブロックの同期のこともあれば、レビュー結果待ちのことも、内部リンクの判断待ちのこともある。
共通していたのは、「揃っていないうちは保存しない」という一点だけだった。

post_draft.py自体は、止める仕組みを持っていない。
SEO情報が空でも、実行すれば下書きは保存される。

止めていたのはスクリプトではなく、実行するタイミングを選ぶ側だった。
カルテと下書きが一致しているか。
レビュー結果は届いているか。
内部リンクの方針は決まっているか。

その確認が終わるまで、実行する手を止めていた。
止めていたのは仕組みではなく、判断だった。

監査が通った瞬間に保存していたら、いずれどこかでずれた内容がそのまま残っていたはずだ。
保存を工程の途中に置かず、最後の一手として残しておいた。
それだけで、食い違ったままの下書きが公開に近づく事態は起きなかった。

次は、その保存した下書きのあとに、DB登録・目次反映・内部リンク施工がどう別工程として残ったのかを書く。