実装ログを公開できる技術記録へ変換する運用

2026年06月22日から2026年06月28日にかけては、Gatsby ベースの個人技術ブログに、毎日の作業記録をそのまま置くのではなく、読み返して再利用できる技術記録へ整形する運用を固めた。合わせて、worklog-blogger という Codex 用の自作スキルで下書きを生成し、daytrade_10-30man という少額資金向けデイトレ補助ツールの初期実装も、同じ記録運用で残せる形にそろえた。

この週の学びは、生成されたログをそのまま公開しないことよりも、どのリポジトリに何を追加し、どこまで検証し、何をまだ公開していないのかを明示した方が、後から読む人にも自分にも価値が高い、という点にある。

この記事で解決すること

実装ログを残しても、検証状況や未公開範囲が曖昧だと、読者は安全に再利用できない。この記事では、次の悩みを解く。

• 小さなツール実装を、公開できる技術記録として整理したい。
• 自動生成ログの抽象表現を落とし、対象リポジトリ中心に書き直したい。
• テスト済みの範囲、ローカル確認のみの範囲、未検証の範囲を分けたい。

実施した改善

この事例では大きく二つの流れがあった。ひとつは daytrade_10-30man の初期版を実装し、計算ロジック、UI、単体テスト、ブラウザ確認までを通したこと。もうひとつは、そのような実装作業や日次の運用作業をブログ側の Markdown 記事として残し、週単位で再構成できる記録フローを整えたことだ。

日次ワークログでは毎回 dry-run を先に実行し、自動生成文に残る抽象表現や公開に向かない断片を落としてから保存した。週次では、その蓄積を「どの技術をどう導入し、どんな検証と制約があったか」という読者向けの知識へ再編集した。

確認できた成果

成果として特に大きかったのは、実装作業と記録作業の両方で「どこまで自動化し、どこから人が具体化するか」の境界が明確になったことだ。自動生成は初稿の回収に向いているが、公開できる技術記録へ仕上げるには、対象リポジトリの構成、テスト、検証結果、未実施項目まで人が明示した方が品質が安定した。

判断と進め方

週の前半では、日次 Worklog の生成結果に 対象アプリ のような未具体化表現が残りやすいことが分かった。そのため、まず dry-run を見てから、最終的に変更された成果物を主語に本文を組み直す運用へ寄せた。

2026年06月23日には daytrade_10-30man の初期実装を進め、HTML と JavaScript だけでリスク計算ツールを成立させた。この日は「実装したものをどう検証し、それをどう記録するか」が一番揃っており、この事例の実装系ワークログの基準点になった。

週の後半では、ブログ側の記事追加フローそのものを毎日確認し、frontmatter 契約、Markdown 取り込み経路、validate-content.js による品質ゲートを繰り返し見直した。結果として、作業量が薄い日でも「何を変更し、何はまだしていないか」を正確に残せるようになった。

使った技術

この事例で触った技術は、単にログ収集のための道具ではなく、変更対象のアプリやリポジトリを成立させるためのものとして整理すると理解しやすい。

導入や検証の観点で見ると、この事例の中心は「アプリを実装する技術」と「その変更を壊さず記事化する技術」を分けて扱えた点にある。草稿生成スキル 自体は情報源の回収と下書き生成に使ったが、記事本文の主語はあくまで daytrade_10-30man とブログ側の変更内容に置いた。

構成

この事例の構成は、実装対象と記録対象を疎結合にしたことが重要だった。daytrade_10-30man は静的な単一ページアプリとして完結し、ブログ側は Markdown ベースのブログとして完結する。両者のあいだを 草稿生成スキルが下書き生成で橋渡しするが、公開される成果物はあくまで各リポジトリ側のファイルだ。

flowchart LR
  A["作業ログと実装変更"] --> B["草稿生成スキルで下書き生成"]
  B --> C["人手で対象リポジトリ中心に具体化"]
  C --> D["ブログリポジトリ の Markdown 記事"]
  D --> E["validate-content.js で検証"]
  A --> F["daytrade_10-30man の単体テスト / ブラウザ確認"]

daytrade_10-30man 側では、index.html が画面層、src/risk.js が計算ロジック層、test/risk.test.js が検証層を担う単純な分離を採用した。ブログ側では、_data/blog/*.md をデータ層とし、Gatsby の取り込み設定と validation スクリプトが受け入れ層として機能している。

採用理由と代替案

この事例の技術選定は、派手な技術導入よりも、変更対象ごとの責務を崩さないことを優先した。

daytrade_10-30man を静的 HTML と JavaScript で始めたのは、試作段階でフレームワークの都合より計算ロジックの早い検証を優先したかったためだ。リスク管理ツールの最初の価値は画面演出ではなく、許容損失と建玉サイズの計算が正しいかにあるので、src/risk.js を切り出してテストしやすい形にした判断は妥当だった。

ブログ側で Markdown 1 ファイル追加の運用を守ったのは、テンプレートやビルド設定を増やさずに既存パイプラインへ統合できるからだ。自動生成が抽象的でも、最終成果物を BlogPost frontmatter に合わせた 1 記事へ閉じ込めれば、影響範囲をかなり小さく保てる。

また、毎回ビルド全体を回さず validate-content.js を最小の品質ゲートとして使ったのも合理的だった。この事例の主な変更はコンテンツ追加であり、まず壊しやすいのは表示ロジックより frontmatter 契約だからだ。逆に言えば、レンダリング確認や公開確認は今後の追加課題として明示しておくべきだと分かった。

検証結果

確認した観点は、daytrade_10-30man の計算ロジック、UI、テスト、ブラウザ確認を分けて記録した点にある。確認した主なコマンドは次の通り。

npm test
python3 -m http.server
# Playwright: ブラウザ上の表示と計算結果を確認
node scripts/validate-content.js

公開記事では、ローカルで確認した範囲と、まだ公開・本番検証していない範囲を分けて扱った。

導入手順

同じような運用を導入するなら、次の順で進めると再現しやすい。

1. 変更対象アプリの責務を分ける。 daytrade_10-30man なら UI と計算ロジック、ブログ側 なら記事データと取り込み設定のように、どこを更新したのか説明できる単位を先に作る。
2. 生成系の自動化は必ず dry-run から始める。 この事例では毎回草稿生成スキルの dry-run を確認し、未具体化の表現や公開不要な断片を先に洗い出した。
3. 変更対象ごとの検証経路を分ける。 daytrade_10-30man では単体テストとブラウザ確認、ブログ側では frontmatter validation を使い、同じ「検証」という言葉でも中身を混ぜないようにした。
4. 書き込み後の成果物を人手で具体化する。 自動生成された文章をそのまま使わず、対象リポジトリ名、変更箇所、実施した検証、未実施のデプロイや公開を明記する。
5. リリース可否を別判定にする。 初稿作成時は下書き管理に留め、レビュー後に公開する。この切り分けが事故防止に効く。

制約と残課題

一番大きな課題は、自動生成された初稿がそのままでは「読む価値のある技術記録」にならないことだった。対象アプリ名が曖昧なまま残ったり、ローカル文脈に依存した記述が混ざったりすると、後から読んでも再利用できない。

次の課題は、作業量が薄い日の扱いだった。実装差分が少ない日は、無理に別リポジトリの話を足すより、その日に実際に行った運用改善や検証作業を正確に書いた方が品質が高い。この事例のブログ側まわりの複数日ログは、その割り切りを実践した形になっている。

最後に、デプロイや公開については「やっていないことをやっていないと書く」必要があると分かった。特にこの事例では validate-content.js までで止めており、ビルド全体、公開、リリースは未実施だった。この境界を書かないと、読者は導入済み範囲を誤解しやすい。

次の改善候補

• 草稿生成スキル 側で未解決プレースホルダや抽象語を検出し、write 前に警告できるようにする。
• ブログ側で frontmatter validation に加えてレンダリング確認を入れ、本文構造の崩れも早めに拾えるようにする。
• daytrade_10-30man 側では売買手数料、スリッページ、入力異常系を扱うテストを増やし、ローカル確認から次の実運用検証へ進める。
• 週次記事の生成では、この事例のように実装対象が複数ある場合に、どの変更を中心テーマに据えるかを事前に決める基準を用意する。
• draft 記事のままでもビルド、プレビュー、公開可否を段階的に判定できるよう、release 前チェックを別の運用ルールとして外出しする。