はじめに
ビジュアルノベルエンジン「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