記事の自動投稿｜承認なしで2か月、壊れなかった理由

朝メールを確認すると、コンテナのお知らせページに知らない記事が増えている日がある。
私が書いたのではない。
毎朝9時に、AIが自分でニュースを調べて記事を書き、検証をパスしたものをそのまま本番サーバーへ反映しているからだ。
人間の承認は、どの段階にも入っていない。

なぜ承認ゲートを外したのか

最初は承認制だった。
AIが下書きを作り、私が読んで、問題なければ本番へ反映する、という流れだった。
けれど実際にやってみると、詰まるのはいつも承認の一手間だった。
毎朝の記事を確認する時間が取れない日が続くと、公開が数日分まとめて滞る。
そのうち承認待ちの記事が溜まっていること自体を忘れる。
承認ゲートは事故を防ぐための仕組みのはずが、実際には公開を止めているだけの日のほうが多かった。
2か月前、思い切って承認ゲートを外し、検証に合格した記事はそのまま本番へ反映する運用に切り替えた。

人が見ない代わりに、何が事故を防いでいるのか

承認を外すというのは、チェックを外すことではない。
むしろ逆で、人が毎回目視していた分を、機械的な検証に置き換える必要があった。
ローカルの検証環境に一度反映してから、投稿用と表示用の2系統のテーブルの件数が一致しているか、内容のハッシュ値が一致しているか、実際にページへアクセスしてHTTP200が返るか、本文が二重にエスケープされていないか、ハングルやキリル文字が紛れ込んでいないかを、すべて機械的に検査している。
1つでも落ちれば、その記事は公開せずpendingフォルダに残して報告する。
「承認ゲートを外した」というより、「人間の目」という単一障害点を、複数の機械的な検証に分散させた、というのが実態に近い。

実際に踏んだ落とし穴

検証項目のほとんどは、机上で考えたものではなく、実際に事故を起こしてから加わった。
本番反映用のSQLファイルに生の改行が残っていて、PHPのserialize関数が生成する文字列のバイト数とずれ、本文が正しく復元できなくなったことがある。
以来、SQLファイル中の改行は必ずエスケープ表記に変換し、1ステートメントを1行にまとめるルールにした。
本番のpost_idがローカルで想定していた採番と衝突しかけたこともあり、投入直前に本番側の最大値を確認する手順を必須にした。
検索コンソールを調べたときには、量産型の告知記事がクロール予算を食いつぶしていることも分かった。
その反省から、独自性の低いベンダー発表の要約記事にはnoindexを既定で付け、コラムだけを検索対象に絞る判断もした。
どれも起きてから直したもので、最初から見えていたわけではない。

通知は、事故が起きたときだけ鳴らす

日次の運用を2か月続けて分かったのは、毎回「今日も無事終わりました」と知らせる仕組みは、すぐに読まれなくなるということだった。
平常運転では通知を送らず、報告はチャットに残すだけにしている。
通知を送るのは、本番反映の検証に失敗して記事が公開できなかったときと、外部の下書き置き場に投稿されないまま3本以上、または3日以上溜まっているときの2つだけに絞った。
黙っていると損失が積み上がる種類のことだけをプッシュし、それ以外は静かに流す。
この線引きを決めるまでは、通知を送りすぎて結局読み飛ばされるか、何も送らずに本当に困ったときも気づかないかのどちらかだった。

2か月運用してみて

承認する人がいなくなったぶん、責任は検証項目を設計する側に完全に移った。
これは気が抜けない反面、毎朝の公開作業に追われることがなくなったのは大きい。
今のところ、検証を通過した記事が壊れて公開された、という事故は起きていない。
それは運が良かったからではなく、事故を1つ起こすたびにチェック項目を1つ増やしてきた積み重ねだと思う。

この運用を支えているのが、毎朝決まった時刻に処理を起動する仕組みと、AIに渡すプロンプトの設計だ。
cronマネージャーやプロンプトテンプレ管理の機能ページでも、コンテナで使える自動化の仕組みを紹介している。