{"componentChunkName":"component---src-templates-blog-template-js","path":"/2026-05-03-weekly-knowledge","result":{"data":{"site":{"siteMetadata":{"title":"KenRp Blog"}},"markdownRemark":{"html":"<p>Codexの会話をそのまま記事にすると、時系列の報告にはなっても、読者が同じ問題を解くための手順にはなりにくい。反対にGit履歴だけでは、「なぜその設計を選んだか」が抜け落ちる。</p>\n<p>この問題に対して、セッションログとGit履歴を証拠として収集し、まず内部向けの作業メモへ保存する <code class=\"language-text\">worklog-blogger</code> を作った。公開記事はそこから一つの課題だけを選び、人が再構成する。</p>\n<h2>この記事で解決すること</h2>\n<p>対象は、AIとの開発記録を技術記事へ再利用したいものの、薄い週報や会話の転載にはしたくない人だ。この記事では次を扱う。</p>\n<ul>\n<li>会話、コマンド、Git履歴をどの役割で使い分けるか</li>\n<li>非公開の証拠と公開記事をなぜ分離するか</li>\n<li>生成処理をテスト可能なCLIとして保つ方法</li>\n<li>自動生成だけでは保証できない範囲</li>\n</ul>\n<h2>入力を「記事」ではなく「証拠」として扱う</h2>\n<p>入力はCodexのJSONLセッションログと対象リポジトリのGit履歴である。会話からは問題と判断理由、ツール呼び出しからは実行コマンド、Gitからは実際に残った変更を集める。</p>\n<p>役割を混ぜないことが重要だ。会話中の「直した」は成果の証明にならないため、コミット差分やテスト結果と照合する。一方、コミットだけでは却下した案が分からないため、判断理由は会話から補う。</p>\n<div class=\"gatsby-highlight\" data-language=\"text\"><pre class=\"language-text\"><code class=\"language-text\">Codexセッション ─┐\n                  ├─ 収集・マスク ─ 内部向けメモ ─ 編集 ─ 公開記事\nGit履歴 ─────────┘</code></pre></div>\n<h2>実装手順</h2>\n<p>日次記録と公開記事は、次の順序で分離する。</p>\n<p>日次処理は作業再開に必要な情報を残す。ここではローカルパスや失敗したコマンドも有用だが、そのまま公開する情報ではない。出力は必ず <code class=\"language-text\">draft: true</code> にする。</p>\n<div class=\"gatsby-highlight\" data-language=\"bash\"><pre class=\"language-bash\"><code class=\"language-bash\">python3 scripts/collect_worklog.py <span class=\"token punctuation\">\\</span>\n  --date <span class=\"token number\">2026</span>-05-03 --mode worklog --dry-run</code></pre></div>\n<p>記事候補の抽出も下書きで止める。公開頻度を優先して複数テーマを束ねず、トラブルシューティング、設計判断、実装手順など、一つの読者課題を選ぶ。</p>\n<div class=\"gatsby-highlight\" data-language=\"bash\"><pre class=\"language-bash\"><code class=\"language-bash\">python3 scripts/collect_worklog.py <span class=\"token punctuation\">\\</span>\n  --date <span class=\"token number\">2026</span>-05-03 --mode article-brief --dry-run</code></pre></div>\n<p>この二段階にした理由は、ログ収集と編集判断を分離するためだ。前者は機械的にテストできるが、説明の価値、重複、公開可否は人のレビューが必要になる。</p>\n<h2>実装を小さなCLIにした理由</h2>\n<p>実装にはPython標準ライブラリを使った。JSONL、日時、正規表現、ファイル操作、<code class=\"language-text\">git</code> の呼び出しで完結し、生成環境へ追加依存を持ち込まずに済む。</p>\n<p>処理は次の責務に分けた。</p>\n<ol>\n<li>セッションとGit履歴を読み取る</li>\n<li>秘密情報らしい値と内部情報を除外する</li>\n<li>コマンド、変更ファイル、判断を構造化する</li>\n<li>frontmatter付きMarkdownを生成する</li>\n<li>公開前の評価を行う</li>\n</ol>\n<p>Git管理下のスキルを正本とし、ローカルのCodexスキル配置先へ同期する。これにより、生成ロジックとテストの変更履歴を残し、別環境でも復元できる。</p>\n<h2>検証結果</h2>\n<p>テストは、ログ抽出、Git履歴抽出、frontmatter、秘密情報のマスク、記事評価を対象にしている。記事を再編集した時点でも、次のコマンドで7件が成功した。</p>\n<div class=\"gatsby-highlight\" data-language=\"bash\"><pre class=\"language-bash\"><code class=\"language-bash\">python3 -m unittest discover <span class=\"token punctuation\">\\</span>\n  -s skills/worklog-blogger/scripts <span class=\"token punctuation\">\\</span>\n  -p <span class=\"token string\">'test_*.py'</span>\n\n<span class=\"token comment\"># Ran 7 tests</span>\n<span class=\"token comment\"># OK</span></code></pre></div>\n<p>出力文そのものを完全一致させるのではなく、<code class=\"language-text\">draft: true</code>、必須frontmatter、証拠セクションなどの契約を検証する。文章表現まで固定すると改善しづらくなるためだ。</p>\n<h2>採用理由と代替案</h2>\n<p>毎日そのまま記事を公開する方式は採用しなかった。作業量と読者価値は一致せず、関連しない変更を一つの記事にまとめる原因になる。</p>\n<p>Gitコミットだけから生成する方式も避けた。差分の再現性は高いが、比較した案や制約が残らない。逆にセッションだけへ依存すると、発言と実装済みの事実を区別できない。両方を使い、公開前にコードとテストへ戻って確認する形にした。</p>\n<h2>制約と残る課題</h2>\n<ul>\n<li>マスク処理だけで秘密情報の不在を保証することはできない</li>\n<li>同日の別作業が混ざるため、対象リポジトリやテーマによる絞り込みが必要になる</li>\n<li>コマンドの存在だけでは成功を示せないため、終了結果も保存する必要がある</li>\n<li>評価点を通過しても、事実確認と重複確認は人が行う</li>\n</ul>\n<p>重要なのは、自動生成の量を増やすことではなく、検証可能な証拠を先に残すことだ。公開記事は、その証拠から読者の一つの問題を解く形へ編集して初めて成立する。</p>","excerpt":"Codexの会話をそのまま記事にすると、時系列の報告にはなっても、読者が同じ問題を解くための手順にはなりにくい。反対にGit履歴だけでは、「なぜその設計を選んだか」が抜け落ちる。 この問題に対して、セッションログとGit…","frontmatter":{"date":"2026年05月04日","path":"/2026-05-03-weekly-knowledge","title":"Codexの作業ログを再現可能な技術記事へ変える設計","thumbnail":"/kenRp-blog/assets/codex-worklog-notebook.jpg","metaDescription":"CodexのセッションログとGit履歴を、非公開の作業記録と読者向けの記事へ分離する方法を、実装構成・テスト・制約とともに解説します。","category":"Knowledge","tags":["codex","automation","knowledge"]}}},"pageContext":{"slug":"/2026-05-03-weekly-knowledge"}}}