Webマーケのチートシートを、新しい記事レーンとして立てる
今回やったこと
Webマーケティングのチートシートを、単発の記事ではなく、装填・公開・公開後レビューの段階を持つ記事レーンとして扱う設計を記録する。台帳にある項目をもとに下書きを作り、公開段階で在庫から1本ずつ出し、公開後に実URLを確認する。下書きは draft: true で保持し、公開処理が明示的に状態を切り替える。
この構成で大切なのは、記事ファイルがリポジトリにあることと、読者からアクセスできることを別の状態として扱う点だ。記事の作成、公開、公開後の点検をひとつの処理にまとめると、どの段階で何が起きたかが見えにくい。段階を分け、それぞれに機械的な確認を置く。
下書き段階でURLを作らない
下書きの印だけを付けても、静的サイトの生成処理がその記事のページを作ってしまえば、一覧に載らなくてもURLから読める状態になり得る。実際、このレーンでは draft: true の記事を公開対象から外す処理がURL生成の入口に必要になる。実装上の中心は、Webマーケ記事を列挙する getStaticPaths で下書きを除外することだ。
そのため、下書きが一覧に見えないことだけを確認しても十分ではない。ビルド結果を調べ、下書きページのURLが生成されないことを確かめる回帰確認を用意している。公開済み記事の確認とは違い、下書き段階では「ページが存在しない」ことが期待結果になる。テスト用の公開記事を陽性対照として扱うことで、検査自体が常に「見つからない」と返していないことも確認できる。
3段階を別々に保つ
| 段階 | 主な処理 | 確認すること |
|---|---|---|
| 装填 | 台帳から下書きを作り、PRで在庫へ入れる | draft: true の記事に公開URLが生えていない |
| 公開 | 時刻枠で在庫の状態を切り替えて配信する | 公開用の検証を通過している |
| 公開後レビュー | 公開された記事を実URLで再確認する | 問題の検出と修正・人間への引き継ぎが動く |
装填の設定と公開の設定も分ける。スクリプト側の公開設定は既定で無効にし、運用環境から明示的に有効化する。こうしておけば、スクリプトを単独で呼んだだけで公開へ進む事故を避けやすい。記事を在庫へ入れる処理と、在庫を配信する処理の権限境界が明確になる。
公開後の点検までを一つのレーンとする
公開後レビューは、公開済みのページを実URLで読み、機械検査と必要に応じた修正へつなぐ。検査対象の特定や処理の段取りは決定的なスクリプトが担い、内容の確認はレビュー処理へ渡す。修正可能なものと、人の判断が必要なものを同じ扱いにしない。
公開前の検査だけでは拾えない問題を見つけるには、公開後の点検も必要になる。公開前だけを見て「安全」と判断するのではなく、公開された記事を点検する処理も動作条件に含める。レビューの実行経路が止まった場合に公開レーンを継続するのか止めるのかも、事前に決めておく必要がある。
機械ゲートは失敗入力で確かめる
検証コマンドが正常終了するだけでは、下書きが公開対象から外れている証明にならない。誤った状態の入力を用意し、それを検査が検出して止めるところまで確認する。特に静的サイトでは「一覧には出ないがページは生成された」という状態があり得るため、ビルド出力の有無を直接確かめる回帰テストが役立つ。
運用を始める際は、下書きを1本だけ装填し、URLが作られないことを確認する。公開レーンでは、公開済みのテスト対象を使い、URLが生成される側も確認する。その後、公開後レビューが実URLを読めることを確認する。どれか一段だけが成功しても、レーン全体の完成とは見なさない。
更新履歴
- 2026-10-12: 初稿を作成。
訂正履歴
- なし。