サーバーで動く実体とリポジトリの分岐を解消し、公開ループを版管理下へ戻した
今回やったこと
静的サイトの公開ループについて、リポジトリが想定している構成と、常駐サーバーで実際に動いている構成が分岐していた状態を棚卸しした。今回の整理で、サーバー側にしか存在しなかった自動化のプロンプトと実行定義をリポジトリへ取り込み、重複する実装を整理した。実態を記録した正本は、リポジトリ内の設計ドキュメントに置いている。
ここで扱うのは、サイトの記事をどう書くかではなく、下書きから公開後の確認までをどの工程に分け、どのファイルを正本にするかという運用設計である。公開処理そのものの成否は、個別のコマンドよりも、実際に動く定義と版管理された定義が一致しているかに左右される。
分岐していた状態
もともとリポジトリには、決定的な公開スクリプトが存在していた。一方、常駐サーバーでは、別セッションがその存在を知らないまま構築した複数のLLMエージェント構成が動いていた。さらに別の日には、既存の公開後チェックを把握しないまま、似た役割のレビュー工程が追加された。
この状態では、リポジトリのファイルを読んで「設定はこうなっている」と判断しても、実際のジョブが別の定義を使っている可能性がある。重複したレビュー工程はラベルの衝突を起こし、公開前の審査を止める危険もあった。問題は単にファイルが古いことではなく、どれが正本なのかを決めないまま複数の実装が動いていたことにある。
棚卸し後の流れは、役割を分けると次のようになる。
| 工程 | 役割 | 実行の位置付け |
|---|---|---|
| 自動起稿 | 承認済み候補から下書きを作る | drafts/ready/ に置く |
| 公開前レビュー | 下書きの機械・内容チェック | 問題があれば公開へ進めない |
| 自動公開 | 公開待ち原稿を少数ずつ昇格 | 1日1本のdrip運用 |
| 公開後チェック | 実URL・漏れ・リンク・画像などを確認 | 判断が必要な問題を通知 |
| 人間案件の督促 | 未解決の判断事項を再通知 | 専用ラベルで追跡 |
公開前レビューと公開後チェックは似ているが、同じ工程ではない。前者は公開を止めるための検査で、後者は公開後に発見した問題を修正または人間判断へ渡すための検査である。
正本をリポジトリへ戻す
実際に動いていた生プロンプトと実行定義をリポジトリへ取り込み、サーバー環境固有のローカル領域だけに残っていた構成を版管理下へ戻した。これにより、プロンプトの内容とジョブの実行方法を同じ変更履歴で確認できるようになった。
同時に、重複していたレビュー用スクリプトと、役割が重なる公開後レビュー用のプロンプトを撤去した。使わなくなった公開スクリプトには非推奨であることを示すヘッダーを付け、すぐに削除せず、誤って使わないための記録として残した。
この作業で重要だったのは、実装をきれいに作り直すことではない。まず「いま動いているもの」を確認し、それを正本へ取り込み、その後に重複を整理する順番である。想定構成から書き直すと、事故の原因になった実体を再び見落とす可能性がある。
タイムアウト制限で無人ハングを終わらせる
棚卸し後の公開前レビュー・自動公開・公開後チェックには、上限時間を持つ共通ランナーを通す構成を採用した。各ジョブが無期限に承認待ちや外部コマンド待ちになると、失敗したこと自体が通知されない。そこで、一定時間を超えたら処理を打ち切り、Discordへ知らせる境界を実行側に置いた。
この境界は、成功を保証する仕組みではない。役割は「終わらない処理」を正常終了と取り違えないことにある。自動化では、エラーで落ちるケースだけでなく、何も返さず止まるケースも後続処理をブロックし、公開枠を占有し続けてしまう。タイムアウトを共通化すると、個別のプロンプトに安全策を書き忘れても、ジョブ全体の外側で終了条件を持てる。
まだ残る注意点
正本をリポジトリへ戻しても、運用上の確認が不要になったわけではない。プロンプトの変更と実行定義の変更が別々に反映されれば、再び半分だけ新しい状態になる。公開ペースの設定を変更した場合は、実行時に読まれるプロンプトまで含めて確認しなければならない。
また、公開後チェックは画像の不足を一方向だけで見ると、画像が一度も生成されていない状態を見逃す。公開ループの正本を整理した後も、下書き、画像のraw、生成済みwebp、frontmatterの関係を確認する必要がある。工程を分けることと、工程間の受け渡しを検査することは別の課題である。
やってみてわかったこと
無人運用の正しさは、リポジトリに「正しそうなファイル」があることでは判定できない。実行されている定義、実行時に読むプロンプト、生成物の置き場所を一つの流れとして突き合わせて初めて確認できる。
分岐を解消する作業では、実装を増やすより先に実体を版管理へ戻す方が効果が大きかった。正本が決まり、重複した工程が整理され、処理時間の上限が外側に置かれると、失敗の場所を調べられる。自動化を長く動かすために必要なのは、工程を増やすことではなく、どの定義が動いているかを追跡できる状態である。
更新履歴
- 2026-08-11: 初稿作成。公開ループの棚卸し記録をもとに構成。
訂正履歴
（訂正なし）