はじめに

ビジュアルノベルエンジン「kaedevn」の開発は、1 週間で 278 コミットという密度の高い開発でした。開発が一段落した後、「この開発体験から何本の記事が書けるか」を Claude Code に聞いてみたところ、39 本の記事ネタが抽出されました。

この記事では、「git log とレポートファイルから記事ネタを抽出する」という作業の手順と、Claude Code への指示方法、そして出力された結果の構造を解説します。

全体の流れ

Step 1: 情報収集 — git log 全件 + docs/09_reports/ の全レポート
Step 2: パターン分類 — 7 カテゴリに分類
Step 3: ネタ一覧生成 — タイトル・概要・ソースファイル・予想文字数
Step 4: 一覧の検証 — 重複・漏れのチェック

Step 1: 情報収集

git log の読み込み

278 コミットの全件を Claude Code に読ませます。

git log --oneline --all

出力例:

a0ad2e6 docs: インタプリタ実装報告書を追加
45360d3 fix: エディタのアセットフィルターを新 taxonomy に対応
e7aa0ba fix: 公式アセットインポート時の slug 長超過で 500 エラーになる問題を修正
2eb84f6 fix: /my-assets フィルター・インポートボタンのコントラスト改善
4f78463 feat: /my-assets にサブカテゴリフィルター追加（3段階絞り込み）
...（278 コミット）

レポートファイルの一覧

docs/09_reports/
  └── 2026/02/
        ├── 09/  — ブラウザ統合、インタプリタ実装
        ├── 18/  — Azure デプロイ、サーバー設定
        ├── 19/  — セキュリティ監査、タイムライン仕様
        ├── 20/  — 3カラムレイアウト、State ルール
        ├── 21/  — バトルシステム仕様
        ├── 23/  — アセット管理仕様
        └── 24/  — OSS 準備、Zenn 記事ネタ

レポートは 68 ファイル以上あり、各レポートに開発の背景・判断・結果が記録されています。

ソースコードの構成

apps/editor/     — エディタ（React + Vite）
apps/hono/       — API（Hono）
apps/next/       — 認証・管理（Next.js）
packages/core/   — 共有ロジック
packages/web/    — PixiJS エンジン
packages/compiler/    — KSC コンパイラ
packages/interpreter/ — KSC インタプリタ

Step 2: パターン分類

278 コミットとレポートの内容を分析し、以下の 7 カテゴリに分類しました。

パターン	定義	例
A: 実装レポート	「何を・どう作ったか」の記録	インタプリタ 7 フェーズ実装
B: 設計解説	「なぜそう設計したか」の説明	IEngineAPI の抽象化設計
C: Claude Code 協働	AI との開発方法論	CLAUDE.md の設計、スキル定義
D: 実践ログ	1 セッションの開発ログ	モバイル UX 改善の実践
E: OSS ドキュメント	OSS 公開のドキュメント戦略	30 ファイルのドキュメント整備
F: Monorepo 運用	monorepo の運用ノウハウ	4 サービスのデプロイ自動化
G: メタ	記事ネタ抽出自体の解説	この記事

カテゴリ設計の意図

A（実装）と B（設計）を分けたのは、読者のニーズが異なるためです。

A を読む人: 「どう実装するのか」を知りたい。コードを見たい
B を読む人: 「なぜその設計にしたのか」を知りたい。トレードオフを理解したい

同じ機能でも、A と B で 2 本の記事が書ける場合があります。例えば「インタプリタ」なら:

A-01: .ksc インタプリタを TypeScript で 7 フェーズに分けて実装した全記録
B-04: インタプリタのパイプライン設計 — テキスト→行分類→パース→評価の 4 段階

Step 3: ネタ一覧の生成

各記事ネタに対して、以下の 4 項目を出力しました。

出力フォーマット

### A-01: .ksc インタプリタを TypeScript で 7 フェーズに分けて実装した全記録 (12,000字)
Phase 1（Parser・セリフ）→ Phase 7（デバッグ・統合テスト）まで。193 テスト。
ソース: `packages/interpreter/`, `docs/09_reports/2026/02/24/02-interpreter-implementation-report.md`

項目	目的
カテゴリ + 番号	記事の位置づけを明確にする
タイトル (予想文字数)	Zenn のタイトルとしてそのまま使える形
概要 (1-2 行)	記事の内容を凝縮
ソースファイル	記事を書く際に参照すべきファイル

ソースファイルの紐付けが重要

各記事ネタに「ソースファイル」を紐付けることで、後から記事を書く際に「何を読めばいいか」が明確になります。

### D-04: 実践ログ — エディタ モバイル UX を Phase 1→3 で改善 (8,000字)
ソース: コミット `c0ebade` 〜 `62f6f16`

コミットハッシュを記録しておけば、git show c0ebade で変更内容を確認できます。レポートファイルがあれば、当時の判断や背景を読み直せます。

出力結果の全体像

最終的に生成されたネタ一覧の規模は以下の通りです。

パターン	本数	予想合計字数
A: 実装レポート	12	102,000
B: 設計解説	10	73,000
C: Claude Code 協働	8	61,000
D: 実践ログ	7	56,000
E: OSS ドキュメント戦略	3	18,000
F: Monorepo 運用	4	25,000
G: メタ	1	8,000
合計	39	343,000

39 本、予想合計 343,000 字。1 週間の開発からこれだけの記事ネタが出てきたのは、レポートを日々書いていたことが大きいです。

代表的な記事ネタ

実装レポート (A)

### A-01: .ksc インタプリタを TypeScript で 7 フェーズに分けて実装した全記録 (12,000字)
Phase 1（Parser・セリフ）→ Phase 7（デバッグ・統合テスト）まで。193 テスト。

### A-03: ブラウザで動くビジュアルノベルエンジンを PixiJS + TypeScript で作った (10,000字)
WebEngine（IEngineAPI 実装 384 行）。背景・キャラ・セリフ・選択肢が全部ブラウザで動く。

### A-10: KSC コンパイラを Phase 0 から Phase 5 まで一気に実装した (15,000字)
Lexer → Parser → TypeChecker → IR Emitter → VM → WebOpHandler。315 テスト。

設計解説 (B)

### B-01: IEngineAPI — 17 メソッドのプラットフォーム抽象化層を設計した理由 (8,000字)
Web / Console / Switch / Test の 4 実装を同じインターフェースで動かす設計判断。

### B-03: .ksc 言語を設計した — VN 専用スクリプト言語の文法とトレードオフ (10,000字)
セリフブロック `#speaker...#`、choice 構文、def/sub 分離、文字列補間の設計意図。

Claude Code 協働 (C)

### C-01: CLAUDE.md でコンテキストを設計する — AI 出力品質を左右する 1 ファイル (8,000字)
プロジェクト概要、アーキテクチャ、ルール、ポート設定を 1 ファイルに集約。

### C-06: 278 コミット・1 週間・人間のコード 0 行 — Claude Code だけで PF を作った (12,000字)
全コミットが Claude Code 生成。15 万行のビジュアルノベル PF。

Claude Code への指示方法

指示のポイント

入力を明確にする: 「git log 全件」「docs/09_reports/ の全ファイル」と具体的に指定
出力フォーマットを指定する: タイトル・概要・ソースファイル・予想文字数
分類基準を示す: 「実装 / 設計 / 協働 / ログ / OSS / 運用 / メタ」のカテゴリ
重複チェックを依頼する: 同じ機能が複数カテゴリに出ても OK だが、内容が重複する場合は統合

予想文字数の算出

予想文字数は「コードブロック + 説明文」で算出しています。

コードブロック 1 つ: 約 500-1,000 字
テーブル 1 つ: 約 200-500 字
説明文 1 段落: 約 200-400 字
典型的な記事構成（はじめに + 5 セクション + まとめ）: 約 5,000-8,000 字

Step 4: 一覧の検証

漏れチェック

コミットログとレポートから網羅的にネタを抽出した後、以下を確認します。

全レポートが少なくとも 1 つの記事ネタに紐付いているか: 紐付いていないレポートがあれば、ネタとして見落としている可能性がある
大きなコミット（feat: で始まるもの）が記事ネタに含まれているか: 機能追加のコミットは記事ネタになりやすい
ソースファイルが存在するか: 紐付けたファイルが実際に存在するか

重複チェック

重複候補	判断
A-01 (インタプリタ実装) vs B-04 (パイプライン設計)	OK: 視点が違う（実装 vs 設計）
D-05 (Azure デプロイログ) vs F-02 (デプロイ自動化)	OK: 視点が違う（ログ vs 運用ノウハウ）
A-06 (Asset 実装) vs D-07 (Asset 実践ログ)	OK: 粒度が違う（全体 vs 1 セッション）

同じ機能でも、「実装の全記録」と「1 セッションの実践ログ」では内容が大きく異なります。

この手法が使える条件

前提条件

コミットメッセージが一定のフォーマットに従っている: feat:, fix:, docs: などの prefix があると分類しやすい
開発レポートが存在する: git log だけでは「なぜそうしたか」の情報が不足する
ソースコードがリポジトリにある: 記事を書く際の参照先が必要

効果が高いケース

ケース	理由
開発が一区切りついたタイミング	全体像が見えるため、分類しやすい
50 コミット以上ある	ネタの量が十分にある
複数の技術要素がある	カテゴリ分けが意味を持つ
レポートが日々書かれている	背景情報が豊富にある

メタとしての価値

この記事自体が G パターン（メタ）です。「記事ネタを抽出した手順を記事にする」というメタ構造を持っています。

### G-01: 278 コミットから 38 本の記事ネタを Claude Code で抽出した手順 (8,000字)
`git log` 全件 + `docs/09_reports/` 68 レポートを Claude Code に読ませてネタ一覧を生成。
パターン分類 → タイトル・概要 → ソースファイル紐付け → 予想文字数の順で作成。
ソース: `docs/09_reports/2026/02/24/05-zenn-article-ideas.md`（この文書自体）

「この文書自体がソースである」という自己参照は、記事ネタ抽出の最終成果物として意味のあるメタデータです。

記事の優先順位付け

39 本全てを書く必要はありません。優先順位を以下の基準で決めました。

高優先度

C パターン（Claude Code 協働）: 独自性が高く、他の記事と差別化しやすい
E パターン（OSS ドキュメント）: OSS 公開のタイミングに合わせて出したい
F パターン（Monorepo 運用）: 再現性が高く、読者の実務に直結する

中優先度

A パターン（実装レポート）: 量が多い（12 本）ため、選別が必要
B パターン（設計解説）: 深い内容になるため、1 本あたりの執筆コストが高い

低優先度

D パターン（実践ログ）: セッションの臨場感は時間が経つと薄れるため、早めに書くか割り切る

まとめ

ステップ	内容	ポイント
情報収集	git log + レポート全件	漏れなく収集
パターン分類	7 カテゴリに分類	視点の違いで分ける
ネタ一覧	タイトル + 概要 + ソース + 文字数	ソースファイルの紐付けが重要
検証	漏れ・重複チェック	同機能の視点違いは OK
優先順位	独自性 + タイミング + 再現性	全部書く必要はない

278 コミットの git log を読んでいるだけでは、記事ネタは見えてきません。「パターン分類」というレンズを通して初めて、同じ機能でも「実装レポート」「設計解説」「実践ログ」という 3 つの記事に分解できることに気づきます。AI は分類と構造化が得意です。人間は「どのレンズで見るか」を決める。その役割分担が、39 本という数を可能にしました。

　　　　　　　　　　Claude Opus 4.6