dry-runで薄い自動生成記事を防ぐ公開前フロー

2026年6月1日から2026年6月7日にかけて、Markdown ベースの技術ブログ kenRp-blog と、Codex の作業記録から記事草稿を作る自作スキル worklog-blogger を使い、日次ワークログをそのまま公開候補にせず、dry-run と手動編集を挟んで週次ナレッジ記事へ育てる運用を整理した。この事例の焦点はアプリ機能の追加ではなく、ブログ側という公開先リポジトリに対して、どの粒度で草稿を残し、どこで品質を担保するかを実務として固めることだった。

この記事で解決すること

自動生成した記事は速く作れる一方で、抽象的な説明やローカル事情が混ざると、公開後に価値の低いコンテンツに見えやすい。この記事では、次の悩みを解く。

• 生成結果を即保存せず、dry-run で止める基準を作りたい。
• 下書きのどこを人手で補えば、読者向けの記事になるか確認したい。
• 公開前に frontmatter、秘匿情報、説明密度を軽量に検証したい。

実施した改善

この事例ではブログ側の _data/blog 配下に日次 worklog を継続追加し、それらを元に週次の knowledge 記事へ再構成する流れを整えた。対象期間の作業記録は 2026-06-03、2026-06-04、2026-06-05 の 3 本で、いずれも草稿生成スキルの collect_worklog.py で dry-run を先に実行し、そのままでは説明が抽象的すぎる箇所を人手で具体化している。

主に整えたのは次の 3 点である。

確認できた成果

一番の成果は、日次 worklog と週次 knowledge 記事の役割分担が明確になったことだった。日次では「何を確認し、どのファイルに手を入れたか」を残し、週次では「なぜ dry-run を挟むのか」「どこを人手で補うのか」という運用知見へ変換できるようになった。

また、この事例の記録から次の基準が揃った。

• ブログ側の frontmatter 契約を崩さずに草稿を追加する。
• 草稿生成スキルの出力は雛形として使い、対象変更の説明が薄い日は手動で補う。
• 秘密情報やローカル事情の混入確認を、書き込み前後の両方で行う。
• 初稿は下書きとして保存し、公開レビューまで編集余地を残す。

判断と進め方

この事例の dry-run 初稿は、必要な見出し自体は出力できていたが、本文は「対象アプリの改修を説明する」というより「一般論を並べる」状態に寄りやすかった。特に 利用した技術、アーキテクチャ、選定理由、導入手順 は、対象の変更内容ではなく記事生成一般の説明へ流れやすく、そのままでは読者が「今週なにを整えたのか」を追いにくかった。

そこでこの事例では、対象を「草稿生成スキルでブログ側向け草稿を作り、それを公開候補のコンテンツへ編集する運用」と明確に置き直した。つまり、記事生成スクリプト自体を情報源として扱うのではなく、そのスクリプトを使ってブログ側のコンテンツ変更をどう安全に進めるかを、アプリ運用の設計として説明する方針にした。

この切り分けにより、日次ログは再開用メモとして残しつつ、週次記事では「どこまで自動化し、どこを人が責任を持つか」という形で知見化できた。

使った技術

この事例の対象変更で使った技術の中心は、静的ブログリポジトリであるブログ側の Markdown 記事管理、草稿生成スキルの collect_worklog.py、そして公開前確認のためのシェルコマンド群だった。ブログ側では _data/blog/YYYY-MM-DD-*.md に記事を置く構成を前提に、template: BlogPost、path、draft、category、tags、metaDescription を揃えた frontmatter を維持している。

草稿生成スキルでは collect_worklog.py --mode weekly-blog --dry-run を入口にし、週次記事の初稿を出力したうえで、参照元の日次 worklog を読み直して本文を具体化した。検証はアプリ本体のビルドやデプロイではなく、この事例の対象が草稿運用の整備だったため、dry-run の内容確認、生成後 Markdown の目視確認、秘密情報パターンの簡易検索を優先している。

今回のビルド、デプロイ、リリース操作は実施していない。理由は、作業対象がブログ側の公開前コンテンツであり、まずは草稿品質と frontmatter 契約の整合を固める段階だったためである。

構成

この事例の構成は、入力、雛形生成、編集、保存を分離したコンテンツ運用として整理できる。対象はアプリ画面ではなくブログ側の記事データ層であり、そこへ 草稿生成スキルを補助ツールとして接続する形になっている。

flowchart LR
  A["日次 worklog(2026-06-03/04/05)"] --> B["collect_worklog.py の weekly-blog dry-run"]
  B --> C["週次記事の初稿"]
  C --> D["本文を手動で具体化"]
  D --> E["ブログリポジトリ の Markdown 記事"]
  E --> F["下書きとして保存・レビュー"]

責務分割の観点では、草稿生成スキルは草稿のたたき台を作る層、ブログ側は記事を保存して公開形式へ載せる層、人手の編集は両者の間で品質を担保する層として機能している。これにより、自動生成の速度は活かしつつ、公開記事として必要な文脈補完と秘匿情報の除去を別工程に分離できる。

採用理由と代替案

この運用を選んだ理由は、既存のブログ側の構成を変えずに改善できるからだった。新しい CMS やデータ形式を持ち込まず、Markdown と frontmatter を維持したまま草稿の品質を上げる方が、差分が小さく、失敗時の影響範囲も読みやすい。

また、dry-run を必須にしたのは、自動生成結果をそのまま保存すると、対象変更に紐づかない汎用文や公開に不要な内部文脈を取り込みやすいためである。この事例の 3 本の日次 worklog でも、初稿はフォーマットこそ成立していたが、内容は手修正が前提だった。完全自動書き込みより、dry-run で確認してから編集する方が結果として正確だった。

検証結果

確認した観点は、生成結果を即保存せず、dry-run と手動編集で止める運用を繰り返した点にある。確認した主なコマンドは次の通り。

python3 collect_worklog.py --mode weekly-blog --dry-run
node scripts/validate-content.js
# 保存前後に frontmatter と秘匿情報を確認

抽象的な初稿を検出した場合は、対象変更、検証結果、未実施項目を本文へ補ってから保存する流れにした。

導入手順

今週に実際に固めた導入手順は次の通りである。対象は 草稿生成スキルを使ったブログ側の週次記事化フローであり、記事生成の自動化そのものを公開候補へ載せるための実装手順でもある。

1. 対象週のワークログファイルを確認し、週次記事の根拠に使える日次 worklog を特定する。
2. collect_worklog.py --date 2026-06-07 --mode weekly-blog --dry-run を実行し、frontmatter と必須見出しを持つ初稿を生成する。
3. dry-run の本文を確認し、対象変更の説明が薄い箇所を、参照した日次 worklog の具体的な事実で補う。 4.ブログ側の既存記事と整合するように、タイトル、導入文、章ごとの主語を整え、不要な確認用見出しが混ざっていないことを確認する。
4. 生成後のMarkdownから、秘密情報、個人情報、過度にローカルな情報がないかを見直したうえで下書き保存し、公開レビューへ回す。

この事例ではここまでを実施し、ビルド、デプロイ、リリースは意図的に行っていない。つまり、実装は「週次記事ファイルを正しい構造で作ること」、テストは「dry-run と目視確認で内容を検証すること」、リリース操作は「まだ実施しない」と切り分けて運用した。

制約と残課題

最大の課題は、入力となる日次 worklog 自体が薄いと、週次記事も抽象的になりやすい点だった。この事例の記録はどれもブログ側への草稿追加作業が中心で、別リポジトリの機能改修や本番反映のような強い変化点は含まれていない。そのため、週次記事では「何を作った週か」よりも「どう運用を固めたか」を主題に置き直す必要があった。

次に、公開向けの草稿としては、ローカルパスや内部向け前提をどこまで残すかの線引きが難しかった。作業再開には有用でも、公開記事には不要な情報が多いため、自動生成に任せきりにせず、人手の編集を必須工程にする必要があった。

最後に、この事例ではあくまで草稿品質の整備が中心であり、ビルド済み表示確認や公開後の読まれ方までは検証していない。コンテンツ契約の整合と公開前安全性は見たが、表示面の確認は次の段階に残っている。

次の改善候補

• collect_worklog.py 側で、抽象的な表現やプレースホルダーが残ったときに警告を出す。
• 日次 worklog の段階で「どのリポジトリに何を追加した日か」を今より明示し、週次への再構成をしやすくする。
• ブログ側で、frontmatter だけでなく本文中のローカルパスや禁止セクション名を検査する軽量チェックを追加する。
• 草稿整備に加えて、必要な週だけでも表示確認や公開直前レビューの工程を別途定義する。