日次ワークログを公開できる技術記事へ変える編集フロー

2026年5月25日から2026年5月31日にかけて、技術メモブログ kenRp-blog と、Codex の作業記録から記事草稿を作る自作スキル worklog-blogger を組み合わせ、日次の作業メモを週次の知見記事へ育てる運用を固めた。狙いは「その日の作業を残すこと」と「読者に再利用できる知見として公開すること」を分離し、下書き品質と公開安全性を両立させることだった。

この記事で解決すること

作業ログは再開用メモとしては便利でも、そのまま公開すると背景が足りず、読者には日記に見えやすい。この記事では、次の悩みを解く。

• 日次メモと公開記事の役割を分けたい。
• 自動生成草稿を、読者が再利用できる内容へ編集する手順を決めたい。
• Markdown ブログの frontmatter 契約を壊さず、公開前の安全確認を入れたい。

実施した改善

この事例では、Gatsby ベースの Markdown ブログに、日次 worklog を継続して追加した。あわせて 草稿生成スキルという Codex スキルの出力を見直し、dry-run で草稿を確認してから、公開可能な粒度へ人手で具体化する流れを定着させた。

単に毎日のログを並べるのではなく、週次記事では「何を導入したか」「どの構成で回しているか」「なぜその手順にしたか」をまとめ直せるように、日次側のタイトル、frontmatter、検証手順もそろえた。

確認できた成果

日次記録と週次記事の役割分担が明確になったことが一番の成果だった。日次側は再開用メモ、週次側は第三者向けの知見記事として整理し直すことで、同じ情報源から別の価値を引き出せるようになった。

また、ブログ側の frontmatter 契約を崩さずに運用できること、scripts/validate-content.js による軽量検証で最低限の品質確認を回せること、週次記事で参考元 worklog を明示する方針を固定できたことも大きい。

判断と進め方

最初の dry-run 出力は、週次記事としては抽象的すぎた。特に「利用した技術」「アーキテクチャ」「選定理由」「導入手順」が、対象変更ではなく記事生成一般の説明に寄っており、何を実装・検証した週なのかが読み取りにくかった。

そこでこの事例では、対象を「草稿生成スキルを使ってブログ側に日次ワークログを蓄積し、その内容を週次記事に再構成する運用」と定義し直した。草稿生成スキルは Codex セッションログや Git 状態から Markdown 草稿を作るスキル、ブログ側はその草稿を記事データとして管理するブログ基盤である、と初出で説明するように統一したことで、外部読者にも文脈が通りやすくなった。

さらに、dry-run の結果をそのまま書き出すのではなく、既存記事形式との整合、不要なローカル情報の除去、記事の主語の明確化を経てから保存する手順に切り替えた。これで「自動生成は速いが、そのままでは薄い」という弱点を、編集ステップで補う構成にできた。

使った技術

この事例の変更対象で中心になった技術は、ブログ基盤と草稿生成スキル、検証用の Node.js スクリプト scripts/validate-content.js、そして Markdown frontmatter だった。ブログ側は Gatsby 2 系と Netlify CMS 系プラグインを前提にした静的ブログで、記事データを _data/blog/*.md から読む構成になっている。

草稿生成スキル 側では collect_worklog.py を使い、まず weekly-blog の dry-run で初稿を生成した。ここで生成結果の抽象度や公開安全性を点検し、その後に日次 worklog で蓄積した情報を参照しながら本文を具体化した。つまり、実装は Python スクリプト、保存は Markdown、整合性確認は Node.js、表示先は Gatsby という分担で成り立っている。

テストとビルドの観点では、この事例の対象変更はブログアプリ本体の UI 実装ではなくコンテンツと運用フローだったため、フルビルドよりも scripts/validate-content.js を優先した。初稿作成時点では下書き整備を目的とし、レビューが終わるまで公開系操作を止める設計にした。

構成

今回の構成は、入力、生成、編集、検証、保存を分離したのがポイントだった。自動生成に任せる部分と、人手で責任を持って調整する部分を明確に切り分けたことで、再現性と公開品質の両方を扱いやすくなった。

flowchart LR
  A["Codex セッションログ / 既存 worklog"] --> B["草稿生成スキル collect_worklog.py"]
  B --> C["dry-run 草稿"]
  C --> D["人手で具体化・秘匿情報確認"]
  D --> E["ブログリポジトリ の Markdown 記事"]
  E --> F["validate-content.js で検証"]

ブログ側では、コンテンツ層と表示層が分かれている。今回直接触ったのは _data/blog 配下の Markdown で、Gatsby テンプレートや画面ロジックを変えなくても、frontmatter 契約を守れば記事一覧と詳細ページに流し込める。これにより、記事生成フローの改善とブログ表示基盤の保守を分離できた。

また、週次記事は日次 worklog をそのまま連結するのではなく、「行ったこと」「成果」「過程」などの章へ変換する二段構成にした。元データの記録性と、公開記事の説明性を別レイヤーとして扱う設計である。

採用理由と代替案

この構成を選んだ理由は、既存のブログ側の契約を壊さずに改善できるからだった。CMS やデータ保存方法を増やさず、Markdown と frontmatter を維持したまま運用を整えれば、差分が小さく、失敗時の切り戻しも簡単である。

また、完全自動生成ではなく dry-run を挟むのは、セッションログ由来の草稿に抽象的な表現や公開に向かないローカル情報が混ざりやすいためだ。特にこの事例では、対象アプリ のような汎用プレースホルダーが残る日があり、自動生成結果をそのまま採用しない判断が妥当だった。

さらに、週次記事で参考 worklog を必ず列挙する方針を取ったのは、知見の出どころをあとから追えるようにするためである。これは記事の信頼性だけでなく、次回の改善でどの日の記録が薄かったかを見つける材料にもなる。

検証結果

確認した観点は、日次記録と公開記事の役割を分け、Markdown の契約を壊さずに検証した点にある。確認した主なコマンドは次の通り。

node scripts/validate-content.js
python3 collect_worklog.py --mode weekly-blog --dry-run
# frontmatter: template / path / draft / category / tags / metaDescription

dry-run の出力をそのまま採用せず、公開前にローカル情報、抽象表現、未具体化の主語を落とす判断を入れた。

導入手順

導入手順は、単にファイルを増やすのではなく、草稿生成から検証までを一つの運用として並べる必要があった。今週に実際に固めた流れは次の通りである。

1. 草稿生成スキルの collect_worklog.py で、対象日の日次 worklog や対象週の weekly blog を dry-run 生成する。
2. 生成結果を確認し、対象リポジトリ名、目的、検証内容、公開上の問題がないかを点検する。 3.ブログ側の既存記事構造に合わせて、frontmatter と本文を具体化する。
3. scripts/validate-content.js を実行し、必須 frontmatter、公開 path、draft 記事数などの契約を確認する。
4. Markdownファイルを下書きとして保存し、別工程の公開レビューで本文、リンク、秘匿情報を確認する。

この事例の運用で特に重要だったのは、実装・テスト・保存・公開を分けて扱うことだった。実装は草稿生成と本文編集、テストは frontmatter 検証、保存は _data/blog への書き込み、公開は別工程として切り分けた。

制約と残課題

一番の課題は、日によって入力情報の密度が大きく違うことだった。材料が少ない日は自動生成結果が汎用テンプレート寄りになり、週次記事に転用したときに「何を学べるのか」が弱くなる。

次に、公開向け Markdown として扱う以上、ローカル絶対パス、内部向け文言、個人情報、秘密情報をどこまで削るかの判断が必要だった。自動生成だけではこの線引きが安定しないため、人手による確認工程を外せなかった。

最後に、今回はコンテンツ追加と整合性確認までは回せても、Gatsby 全体のフルビルドや表示確認、公開後の動線確認までは実施していない。軽量検証で十分なケースと、表示確認まで必要なケースの境界は、今後さらに詰める余地がある。

次の改善候補

次は collect_worklog.py 側で、プレースホルダーや抽象的な見出しが残ったときに警告する仕組みを入れるとよい。これがあれば、dry-run の時点で「そのままでは週次記事に耐えない」ことを早く検知できる。

あわせてブログ側にも、frontmatter だけでなく本文の禁止パターンを検査する仕組みを追加したい。たとえば絶対パス、内部専用ラベル、不要な確認セクション名などを検出できれば、公開前レビューの負荷を下げられる。

さらに、日次 worklog のタイトルと導入文で「どのリポジトリに何を追加した日か」を今より明示すれば、週次記事の再構成精度は上がる。この事例では週次記事側で補完したが、本来は日次段階で素材の質を上げた方が全体の運用コストは小さい。