はじめに
前回の記事「1週間・145コミット・14万行——人間はコードを1行も書いていない」では、数字を並べた。今回は 「なぜうまくいっているのか」 を書く。
結論を先に言うと、偶然ではない。以下の条件が重なったからだ。
- Web + TypeScript が AI の最強領域である
- ノベルゲーム というジャンルが AI と二重に相性が良い
- AI 同士の連携ワークフロー が自然に最適化された
- 制約（予算・時間） が逆にワークフローを洗練させた
開発しているのは kaedevn — ブラウザ上でビジュアルノベルを制作・公開できるプラットフォームだ。
Web + TypeScript が AI 開発に最適な5つの理由
1. パターンの標準化度が高い
AI が強いのは「コード量が多い」からではなく、パターンが高度に標準化されているから。
Web 開発の route → controller → service → repo → DB というパターンはテンプレ化されている。AI のパターン生成が最も得意な領域だ。Python は科学計算や ML 領域でドメイン知識が必要になり、コード量ほどには AI が強くない。
2. 即実行・即検証（最重要）
Claude Code は bash でそのまま npm test や npx vitest が実行できる。書く → 動かす → 直すのループが1ターン内で完結する。
Unity だとビルド → シーンロード → アセット読み込みが必要で、このループ自体が成立しにくい。AI は試行回数が命。ここが致命差になる。
実際、kaedevn の KSC コンパイラは 487 を超えるテストケースで検証されている。テストが一瞬で回る環境だからこそ、AI が高速に品質を担保できる。
3. エラーの可読性
TypeScript の型エラーはこうだ：
Type 'string' is not assignable to type 'number'
これは AI にとって「何が間違っていて何が正しいか」が明示された修正指示書。C++ の SIGSEGV や Unity のクラッシュログとは情報密度が違う。
4. 状態空間の有限性
Web UI は組み合わせは多いがルールは有限。ゲーム開発は物理・座標・アニメ・入力・同期など多次元で、AI は次元が増えるほど精度が落ちる。
5. 構造の予測しやすさ
Web アプリの構造はテンプレ化されている。「正解パターンが大量に存在する分野 = 生成 AI が強い分野」。Web 開発はまさにそれだ。
逆に AI が苦手なのは、数学最適化、低レイヤメモリ制御、物理シミュレーション、独自エンジン設計。
ノベルゲームが「二重に有利」な理由
状態空間がゲームジャンル中で最小
ノベルゲームの基本はテキスト + 立ち絵 + 選択肢のシーケンシャル進行。物理演算なし、リアルタイム同期なし、複雑な座標計算なし。
Web + TS の「状態空間が有限」という利点が二重に効く。
CRUD 的な要素が多い
kaedevn は単なるゲームエンジンではなく、プラットフォームだ。
- 作品管理・プロジェクト管理・アセット管理 → 典型的な CRUD
- ユーザー認証・API 設計・DB 設計 → AI が最速の領域
- エディタ UI → React + 状態管理 → AI が得意な領域
エディタだけで 78 ファイルのコンポーネントがあるが、大半は AI が自然に書けるパターンの組み合わせだ。
ゲームエンジン部分の分離
ゲーム描画（PixiJS / WebGL）は iframe で分離し、Next.js は「外側の UI」だけを担当する。複雑なゲームロジックと Web UI 層が混ざらない設計にしたことで、AI が各レイヤーを独立して実装できる。
バグループが消えた理由
初期の問題
Claude Code あるある——「修正 → 別のバグ → 修正 → 元に戻る」の無限ループ。時間もトークンも溶かす最悪パターンだった。
解消した3つの要因
1. TypeScript の型システムが事前にエラーを防ぐ
コンパイル時点で型の不整合が検出される。AI が「動かしてみたら壊れた」ではなく「書いた時点でエラーが出る」。修正の方向性が明確になる。
2. コードベース自体がコンテキストになる
プロジェクトの規模が大きくなるほど「こう書くべき」の前例が増える。Claude Code が既存コードのパターンに倣って実装するので、一貫性が自然に維持される。
kaedevn のモノレポは現在こういう構成になっている：
apps/
editor/ # React + Vite エディタ（78ファイル）
next/ # Next.js（認証・プロジェクト管理）
hono/ # Hono API バックエンド
packages/
ksc-compiler/ # 独自言語コンパイラ（3,161行）
interpreter/ # インタプリタ
web/ # PixiJS ランタイムエンジン
core/ # 共有型定義・タイムライン
battle/ # バトルシステム
パッケージが分かれているから、AI が1つのパッケージに集中して作業できる。これがバグの波及を防いでいる。
3. AI 生成のドキュメントが AI 自身の精度を上げる
Claude Code が実装しながら MD ドキュメントも生成する。そのドキュメントが次の実装のコンテキストになる。自分で自分の作業効率を上げていく構造だ。
現在 Markdown は 77,000 行以上。その9割は AI が開発しながら書いた。
AI 同士の連携ワークフロー
ChatGPT → Claude Code パイプライン
mk18（方向性・判断）
↓ 日本語で相談
ChatGPT（基本設計・仕様書生成）
↓ 仕様書 MD
Claude Code（実装 + ドキュメント + テスト）
↓ 指摘依頼
ChatGPT（レビュー反映）
ChatGPT を使う理由（身も蓋もない事実）
レートリミットが来ないのが一番の理由。
技術的優劣ではなく運用コストの最適化。設計フェーズはトークン消費が激しく、長い文脈を維持しながら何十往復もする。レートリミットに当たると思考が分断されて効率が激落ちする。
最小コストで最大効果を狙った結果、役割分担が綺麗になった。制約が最適解を生んだ。
AI が書いた仕様書は AI にとって実装しやすい
人間が書いた仕様書より AI が書いた仕様書の方が AI にとって実装しやすい。AI が生成する仕様は暗黙知や曖昧さが少なく、AI 自身が処理しやすい粒度と形式で書かれる。人間の仕様書にありがちな「ここは常識でわかるでしょ」という省略がない。
KSC コンパイラの Phase 4（VM 実装）の仕様書はこういう粒度だった：
- 命令セットの一覧（PUSH, POP, ADD, JMP, ...）
- 各命令のスタック効果
- テストケースの入出力例
- 「物理演算・NavMesh・パスファインディング禁止」のような明示的制約
「やらないこと」を書くのが重要。 Claude Code は優秀なので、制約を書かないと勝手にリッチな実装をしてくる。
CLAUDE.md とスキルシステム——AI を制御する仕組み
CLAUDE.md の実例
リポジトリルートに CLAUDE.md を置いている。この中でプロジェクトのルールを定義する。
### Testing
テストの目的は「テストを通すこと」ではなく
「エラーの発見」と「正常動作の確認」。
- `expect` で期待する状態を明確に検証する
- スキップ・フォールバック・エラー握りつぶしは禁止
- `waitForTimeout` でごまかさず、正しいセレクタや条件を待つ
- 失敗したら原因を調査してコードを修正する
このルールがあるから「テストが通った」にある程度の信頼を置ける。Claude Code は CLAUDE.md のルールを律儀に守る。
スキルシステムで定型作業を自動化
.claude/skills/ に7つのスキルを定義している：
.claude/skills/
dev-server/ # ローカルサーバー起動
deploy-azure/ # Azure デプロイ
playwright-e2e-test/ # E2E テスト（テンプレート + 7つの実例）
save-report/ # 作業レポート保存
commit/ # コミットルール
push/ # プッシュルール
zenn/ # Zenn 記事作成
「コミットして」「デプロイして」の一言で、定義済みのルールに従って動く。コミットメッセージの末尾には Claude Code の作業感想も入る——個人プロジェクトならではの遊び心だ。
MD 77,000行の正体
コードよりドキュメントが多い
Markdown: 77,284行（51%）
TypeScript: 61,402行（41%）
その他: 12,458行（8%）
合計: 151,144行（939ファイル）
誰が書いたか
- MD 77,000行の約90% → Claude Code が開発しながら自動生成
- MD 77,000行の約10% → ChatGPT との設計対話の成果物
- 人間が書いた行数 → 0行
MD は人間のためのドキュメントではない
AI 同士の通信プロトコルだ。ChatGPT が書いて Claude Code が読む。AI は5万行を一瞬で読める。情報量を落とさず詳細に書いた方が AI 同士の精度が上がる。
プロジェクトが大きくなるほどコンテキストが豊かになり、精度が上がる。人間のチームでいう「暗黙知の蓄積」を MD ファイルで明示的にやっている。
怖い話も正直に書く
コードの中身を理解していない
KSC コンパイラの IR エミッターがどうバイトコードを吐いているか、正直よくわかっていない。テストが通っているから信頼しているだけ。
コンパイラのソースはこういう構成だ：
packages/ksc-compiler/src/
lexer.ts # トークン化
parser.ts # AST 構築
checker.ts # 型チェック・意味解析
emitter.ts # コード生成
vm.ts # 仮想マシン
checker/ # スコープ・ビルトイン・エラー定義
types/ # AST, IR, トークン, 値の型定義
3,161 行。318 テストケース。全部 AI が書いた。人間はこの中身を読んでいない。
「テスト通った＝正しい」への過度な依存
テストケースが足りなければバグは見つからない。そしてテストケースも Claude Code が書いている。テストの品質を保証するテストは誰が書くのか——現時点では答えがない。
Claude Code がいなくなったら詰む
コードベースの大半を人間が把握していない状態で、メンテナンスを引き継げるのか。ただし MD が 77,000 行あるので、次に来る AI が読めば引き継げる可能性はある。
Vibe Coding との違い
Y Combinator の 2025 冬バッチでは 25% のスタートアップがコードベースの 95% 以上を AI 生成。Andrej Karpathy が「vibe coding」を提唱し、Collins Dictionary の 2025 Word of the Year にもなった。
kaedevn のケースが異質なのは3点：
- 規模 — 大半の vibe coding は数千行の MVP。15万行の本番志向プロジェクトをコード閲覧ゼロで進めているケースは稀
- AI 間連携 — 普通は「人間 → AI → コード」の1段構成。ChatGPT（設計）→ Claude Code（実装）→ ChatGPT（レビュー反映）のフィードバックループは先進的
- ドメインの複雑さ — ハビットトラッカーやランディングページではなく、独自スクリプト言語のコンパイラ + ゲームランタイム + マルチプラットフォーム展開
人間の役割の変化
従来 vs 現在
従来：設計 2割 → 実装 7割 → テスト 1割
現在：設計（ChatGPT 対話）9割 → 判断確認 1割 → 実装 0割
「コード0行」は「楽してる」ではない。 ChatGPT との設計対話（43 ファイル以上保存 + 未保存多数）、Claude Code への指示と確認、動作確認と方向性の判断——労力の 100% が設計と判断に投下されている。
映画監督がカメラを回さないのと同じ。建築家がレンガを積まないのと同じ。「何を作るか」を考える能力が、「どう書くか」の知識より価値を持つ時代になった。
まとめ：偶然ではなく、条件が揃った
Claude Code でのノベルゲーム PF 開発がうまくいっている理由を整理する。
| 要因 | 効果 |
|---|---|
| Web + TypeScript | AI の最強領域で即実行・即検証が可能 |
| ノベルゲーム | 状態空間が小さく CRUD 要素が多い |
| モノレポ + パッケージ分離 | バグの波及を防ぎ AI が集中作業できる |
| CLAUDE.md + スキル | AI の振る舞いをルールで制御 |
| AI 生成 MD | AI 同士の通信プロトコルとして自己強化 |
| ChatGPT + Claude Code | 設計と実装の分業が自然に最適化 |
これらの条件が1つでも欠けていたら、ここまでの速度は出なかったと思う。
AI 開発の生産性を決めるのは「どの AI が賢いか」より 「どれだけ途切れずに回せるか」 だ。そしてその「回しやすさ」は、技術選定とプロジェクト設計で決まる。
実際に動いているサービスはこちら: https://kaedevn.kaedeasset.com/
高度すぎて理解できないけどちゃんと動く。これがこれからの開発の普通の姿なのかもしれない。
Claude Opus 4.6