ドリップ公開が止まる／出ない時の切り分け手順
今回やったこと
毎日1本ずつ公開するドリップ処理が止まったとき、公開処理本体だけを疑わず、下書き・検証・画像・生成元を順番に確認する切り分け手順を整理する。題材になった停止では、公開待ちの下書きが存在していたにもかかわらず、処理は先へ進まなかった。
結論から言えば、原因は公開処理の中心部ではなく、2本の下書きで frontmatter の必須フィールドが欠けていたことだった。検証が ERROR になったため、公開レーンは安全側に止まった。画像待ちの prompts.json も不足しており、通知だけを見ると「記事があるのに出ない」状態に見えた。
まず「記事がある」を分解する
公開待ちの記事が見つかったからといって、公開可能とは限らない。最低限、次の状態を別々に確認する必要がある。
| 確認するもの | 見る内容 | ここで分かること |
|---|---|---|
| 下書きの存在 | drafts/ready/ と drafts/deploy/ のファイル | 在庫が本当にあるか |
| frontmatter 検証 | 必須フィールドと形式 | レーンに投入できるか |
| 画像待ち | prompts.json と画像の状態 | 後段処理の待ちか |
| 生成元 | CLI とフォーマット処理 | 欠落がどこで生じたか |
この順序には理由がある。最初にファイルが無ければ、検証を調べても意味がない。ファイルがあっても frontmatter が壊れていれば、画像を待つ前に止まる。画像待ちなら公開を遅らせる設計か、画像なしで先へ進める設計かを確認する。最後に、同じ欠落を作った入口を直す。
在庫確認
└─ 無い → 生成レッグ・移記を確認
└─ 有る → frontmatter を検証
└─ ERROR → 生成元と下書きを修正
└─ PASS → 画像待ちと deploy 状態を確認
frontmatter の欠落は入口で防ぐ
今回の修正では、生成元の build_frontmatter をCLI出力へ組み込んだ。記事を人手で整える段階だけで必須項目を確認すると、別の起稿経路から出たファイルで同じ欠落が起きる。生成時点で契約を組み立て、出力された下書きがその契約を持つ状態にする方が、停止を早く発見できる。
ここでいう契約は、タイトルや本文の内容だけではない。公開レーンが読む status、記事を識別する slug、カテゴリやタグ、画像処理が参照する情報など、後続処理が必要とするメタデータも含む。1項目の欠落が検証エラーになるなら、その項目は記事の付属情報ではなく、パイプラインの入力である。
画像待ちも同じ視点で扱う。prompts.json が無い場合、画像処理レッグが何を生成すべきか分からない。記事の本文が完成していても、画像を後段で補う設計なら生成指示の欠落は別の停止要因になる。通知には「下書きがある」だけでなく、検証結果と画像状態を分けて含める必要がある。
止まったときの実務的な順番
最初に drafts/ready/ と drafts/deploy/ のファイル数を確認し、旧形式のファイルを在庫として誤って数えない。次に検証スクリプトを対象ファイルへ実行し、ERROR のフィールドを確定する。ここで検証を飛ばして本文を直すと、原因が別に残ったまま再実行することになる。
検証が通ったら、画像が必須なのか、画像なしで公開を進めてドレインが追いつく設計なのかを確認する。最後に、対象ファイルを作った生成元と、その出力を受け取るレーンの間で、frontmatter の組み立て方が一致しているかを見る。
やってみてわかったのは、公開停止の切り分けでは「公開処理が壊れた」という大きな仮説を、在庫・検証・画像・生成元という小さな状態へ分解することが有効だという点である。安全側に止まる仕組みは必要だが、止まった理由を同じ粒度で通知できなければ、運用上は沈黙と変わらない。
更新履歴
- 2026-08-31: 初稿。候補キューの記録とリポジトリ内の生成・検証手順をもとに整理。
参照
- 記事フォーマット用スクリプト
- 自動起稿ランナー