Codexの作業ログを再現可能な技術記事へ変える設計

2026年05月04日

Codexの会話をそのまま記事にすると、時系列の報告にはなっても、読者が同じ問題を解くための手順にはなりにくい。反対にGit履歴だけでは、「なぜその設計を選んだか」が抜け落ちる。

この問題に対して、セッションログとGit履歴を証拠として収集し、まず内部向けの作業メモへ保存する worklog-blogger を作った。公開記事はそこから一つの課題だけを選び、人が再構成する。

この記事で解決すること

対象は、AIとの開発記録を技術記事へ再利用したいものの、薄い週報や会話の転載にはしたくない人だ。この記事では次を扱う。

入力はCodexのJSONLセッションログと対象リポジトリのGit履歴である。会話からは問題と判断理由、ツール呼び出しからは実行コマンド、Gitからは実際に残った変更を集める。

役割を混ぜないことが重要だ。会話中の「直した」は成果の証明にならないため、コミット差分やテスト結果と照合する。一方、コミットだけでは却下した案が分からないため、判断理由は会話から補う。

Codexセッション ─┐
                  ├─ 収集・マスク ─ 内部向けメモ ─ 編集 ─ 公開記事
Git履歴 ─────────┘

日次記録と公開記事は、次の順序で分離する。

日次処理は作業再開に必要な情報を残す。ここではローカルパスや失敗したコマンドも有用だが、そのまま公開する情報ではない。出力は必ず draft: true にする。

python3 scripts/collect_worklog.py \
  --date 2026-05-03 --mode worklog --dry-run

記事候補の抽出も下書きで止める。公開頻度を優先して複数テーマを束ねず、トラブルシューティング、設計判断、実装手順など、一つの読者課題を選ぶ。

python3 scripts/collect_worklog.py \
  --date 2026-05-03 --mode article-brief --dry-run

この二段階にした理由は、ログ収集と編集判断を分離するためだ。前者は機械的にテストできるが、説明の価値、重複、公開可否は人のレビューが必要になる。

実装にはPython標準ライブラリを使った。JSONL、日時、正規表現、ファイル操作、git の呼び出しで完結し、生成環境へ追加依存を持ち込まずに済む。

処理は次の責務に分けた。

Git管理下のスキルを正本とし、ローカルのCodexスキル配置先へ同期する。これにより、生成ロジックとテストの変更履歴を残し、別環境でも復元できる。

テストは、ログ抽出、Git履歴抽出、frontmatter、秘密情報のマスク、記事評価を対象にしている。記事を再編集した時点でも、次のコマンドで7件が成功した。

python3 -m unittest discover \
  -s skills/worklog-blogger/scripts \
  -p 'test_*.py'

# Ran 7 tests
# OK

出力文そのものを完全一致させるのではなく、draft: true、必須frontmatter、証拠セクションなどの契約を検証する。文章表現まで固定すると改善しづらくなるためだ。

毎日そのまま記事を公開する方式は採用しなかった。作業量と読者価値は一致せず、関連しない変更を一つの記事にまとめる原因になる。

Gitコミットだけから生成する方式も避けた。差分の再現性は高いが、比較した案や制約が残らない。逆にセッションだけへ依存すると、発言と実装済みの事実を区別できない。両方を使い、公開前にコードとテストへ戻って確認する形にした。

重要なのは、自動生成の量を増やすことではなく、検証可能な証拠を先に残すことだ。公開記事は、その証拠から読者の一つの問題を解く形へ編集して初めて成立する。