2026年6月1日から2026年6月7日にかけて、Markdown ベースの技術ブログ kenRp-blog と、Codex の作業記録から記事草稿を作る自作スキル worklog-blogger を使い、日次ワークログをそのまま公開候補にせず、dry-run と手動編集を挟んで週次ナレッジ記事へ育てる運用を整理した。この事例の焦点はアプリ機能の追加ではなく、ブログ側という公開先リポジトリに対して、どの粒度で草稿を残し、どこで品質を担保するかを実務として固めることだった。
自動生成した記事は速く作れる一方で、抽象的な説明やローカル事情が混ざると、公開後に価値の低いコンテンツに見えやすい。この記事では、次の悩みを解く。
\nこの事例ではブログ側の _data/blog 配下に日次 worklog を継続追加し、それらを元に週次の knowledge 記事へ再構成する流れを整えた。対象期間の作業記録は 2026-06-03、2026-06-04、2026-06-05 の 3 本で、いずれも草稿生成スキルの collect_worklog.py で dry-run を先に実行し、そのままでは説明が抽象的すぎる箇所を人手で具体化している。
主に整えたのは次の 3 点である。
\n| 項目 | \n今週に行った変更 | \n狙い | \n
|---|---|---|
| 日次草稿の生成 | \ncollect_worklog.py --dry-run を先に実行 | \n即書き込みを避けて品質を確認する | \n
| 記事本文の編集 | \nブログ側の既存 frontmatter と文体に合わせて再編集 | \n外部読者にも意味が通る粒度へ寄せる | \n
| 週次への再構成 | \n複数日の日報を 1 本の知見記事へ変換 | \n単なる日記ではなく再利用可能な形にする | \n
一番の成果は、日次 worklog と週次 knowledge 記事の役割分担が明確になったことだった。日次では「何を確認し、どのファイルに手を入れたか」を残し、週次では「なぜ dry-run を挟むのか」「どこを人手で補うのか」という運用知見へ変換できるようになった。
\nまた、この事例の記録から次の基準が揃った。
\nこの事例の dry-run 初稿は、必要な見出し自体は出力できていたが、本文は「対象アプリの改修を説明する」というより「一般論を並べる」状態に寄りやすかった。特に 利用した技術、アーキテクチャ、選定理由、導入手順 は、対象の変更内容ではなく記事生成一般の説明へ流れやすく、そのままでは読者が「今週なにを整えたのか」を追いにくかった。
そこでこの事例では、対象を「草稿生成スキルでブログ側向け草稿を作り、それを公開候補のコンテンツへ編集する運用」と明確に置き直した。つまり、記事生成スクリプト自体を情報源として扱うのではなく、そのスクリプトを使ってブログ側のコンテンツ変更をどう安全に進めるかを、アプリ運用の設計として説明する方針にした。
\nこの切り分けにより、日次ログは再開用メモとして残しつつ、週次記事では「どこまで自動化し、どこを人が責任を持つか」という形で知見化できた。
\nこの事例の対象変更で使った技術の中心は、静的ブログリポジトリであるブログ側の 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 契約の整合を固める段階だったためである。
\nこの事例の構成は、入力、雛形生成、編集、保存を分離したコンテンツ運用として整理できる。対象はアプリ画面ではなくブログ側の記事データ層であり、そこへ 草稿生成スキルを補助ツールとして接続する形になっている。
\nflowchart LR\n A["日次 worklog(2026-06-03/04/05)"] --> B["collect_worklog.py の weekly-blog dry-run"]\n B --> C["週次記事の初稿"]\n C --> D["本文を手動で具体化"]\n D --> E["ブログリポジトリ の Markdown 記事"]\n E --> F["下書きとして保存・レビュー"]責務分割の観点では、草稿生成スキルは草稿のたたき台を作る層、ブログ側は記事を保存して公開形式へ載せる層、人手の編集は両者の間で品質を担保する層として機能している。これにより、自動生成の速度は活かしつつ、公開記事として必要な文脈補完と秘匿情報の除去を別工程に分離できる。
\nこの運用を選んだ理由は、既存のブログ側の構成を変えずに改善できるからだった。新しい CMS やデータ形式を持ち込まず、Markdown と frontmatter を維持したまま草稿の品質を上げる方が、差分が小さく、失敗時の影響範囲も読みやすい。
\nまた、dry-run を必須にしたのは、自動生成結果をそのまま保存すると、対象変更に紐づかない汎用文や公開に不要な内部文脈を取り込みやすいためである。この事例の 3 本の日次 worklog でも、初稿はフォーマットこそ成立していたが、内容は手修正が前提だった。完全自動書き込みより、dry-run で確認してから編集する方が結果として正確だった。
\n| 選択肢 | \n判断 | \n理由 | \n
|---|---|---|
| dry-run 後に編集して保存 | \n採用 | \n抽象的な文面や機微情報を事前に潰せる | \n
| 自動生成後に即書き込み | \n不採用 | \n内容の薄い草稿が残るリスクが高い | \n
| 新しい保存形式を導入 | \n不採用 | \nブログ側の既存契約との整合を崩すため | \n
| 公開まで一気に進める | \nこの事例では見送り | \n草稿品質の確認が先で、リリース段階ではないため | \n
確認した観点は、生成結果を即保存せず、dry-run と手動編集で止める運用を繰り返した点にある。確認した主なコマンドは次の通り。
\npython3 collect_worklog.py --mode weekly-blog --dry-run\nnode scripts/validate-content.js\n# 保存前後に frontmatter と秘匿情報を確認抽象的な初稿を検出した場合は、対象変更、検証結果、未実施項目を本文へ補ってから保存する流れにした。
\n今週に実際に固めた導入手順は次の通りである。対象は 草稿生成スキルを使ったブログ側の週次記事化フローであり、記事生成の自動化そのものを公開候補へ載せるための実装手順でもある。
\ncollect_worklog.py --date 2026-06-07 --mode weekly-blog --dry-run を実行し、frontmatter と必須見出しを持つ初稿を生成する。この事例ではここまでを実施し、ビルド、デプロイ、リリースは意図的に行っていない。つまり、実装は「週次記事ファイルを正しい構造で作ること」、テストは「dry-run と目視確認で内容を検証すること」、リリース操作は「まだ実施しない」と切り分けて運用した。
\n最大の課題は、入力となる日次 worklog 自体が薄いと、週次記事も抽象的になりやすい点だった。この事例の記録はどれもブログ側への草稿追加作業が中心で、別リポジトリの機能改修や本番反映のような強い変化点は含まれていない。そのため、週次記事では「何を作った週か」よりも「どう運用を固めたか」を主題に置き直す必要があった。
\n次に、公開向けの草稿としては、ローカルパスや内部向け前提をどこまで残すかの線引きが難しかった。作業再開には有用でも、公開記事には不要な情報が多いため、自動生成に任せきりにせず、人手の編集を必須工程にする必要があった。
\n最後に、この事例ではあくまで草稿品質の整備が中心であり、ビルド済み表示確認や公開後の読まれ方までは検証していない。コンテンツ契約の整合と公開前安全性は見たが、表示面の確認は次の段階に残っている。
\ncollect_worklog.py 側で、抽象的な表現やプレースホルダーが残ったときに警告を出す。