気づいたら2パス型チェッカー付き独自言語ができていた話

「AI に作らせたら知らないうちに2パス型チェッカーができてた話」 開発者自身が全貌を把握する前に、AIが強固なコンパイラアーキテクチャを築き上げていた事件。

1. 始まりは「ちょっとしたプレビュー機能」

kaedevn の開発初期、スクリプトエンジン（KSC）の実装は非常に場当たり的に始まりました。

• セッションA: 「エディタ上でスクリプトのプレビューを実行したい」→ ブラウザで動く簡易的なインタプリタ（packages/interpreter）を作成。
• セッションB: 「JSONの構造を型安全にしたいし、エラーを事前に検知したい」→ 構文解析とパースを行うコンパイラ（packages/compiler, packages/ksc-compiler）を作成。

開発者（人間）の認識としては、「今日はプレビュー機能を作った」「今日はバリデーション機能を作った」という、個別の小さなタスクをこなしたという感覚しかありませんでした。

2. 複数のAIセッションが織りなす「暗黙の連携」

AI駆動開発（特にClaude Code等の自律型エージェントを使用した場合）の恐ろしいところは、人間がセッションをまたいで「あれを追加して」「これを直して」と指示を出している間に、AIがリポジトリ全体の構造を読み取り、勝手に最適なアーキテクチャへとコードを成長させてしまうことです。

後日、システム全体の挙動を追うためにコードベースを詳細に調査したところ、驚くべき事実が発覚しました。

単なる「文字列をJSONに変換するスクリプト」だと思っていたものが、いつの間にか以下のような本格的な2パスコンパイラアーキテクチャへと変貌を遂げていたのです。

1. 第1パス (Lexer & Parser): .ks / .ksc ファイルを読み込み、AST（抽象構文木）を構築。Levenshtein距離を用いたタイポの推測機能まで実装されている（例：「もしかして @fade ですか？」）。
2. 第2パス (Type Checker & Validator): 構築されたASTに対し、コマンドの引数の型チェック、必須パラメータの欠落検証、存在しないリソースへの参照警告などを静的解析として実行。
3. コード生成 (Code Generator): 最終的な Op 命令列（IR: 中間表現）のJSONを出力。

3. 作者本人よりAIの方が「全体像」を知っている

これはAI駆動開発における非常に象徴的な「あるある」です。

人間は「目の前の1つの機能（要求）」しか見ていません。しかしAIは、指示を受けるたびにコードベース全体を走査し、「この要件を満たしつつ、既存のコードと整合性を取るなら、パーサーにバリデーションフェーズを追加して2パス構成にするのが最も美しい」と勝手に判断し、無言で実装してしまいます。

「個々のタスクは明確に指示したはずなのに、積み重なった結果出来上がったシステムの全体像は、作者本人よりもAIの方が深く把握している」

本プロジェクトのコアであるスクリプトコンパイラは、まさにこの現象によって生み出されました。今日の調査で初めて「これ、TypeScript風の型チェッカーを持つ独自言語じゃん……」と作者自身が驚愕することになったのです。

4. 考察：設計を「生やして」いくというパラダイム

従来の開発では、人間が「よし、今から2パスコンパイラを作るぞ」とアーキテクチャを事前に設計し、それに従って実装を進めます。 しかし、AI駆動開発（特にRail Codingのような強固な型制約を敷いた開発）においては、**「要件を満たすために安全なコードを書き続けた結果、自然と最適なアーキテクチャが『生えてくる』」**という現象が起きます。

AIが複数セッションで段階的に作り上げたこのコンパイラは、人間の「トップダウン設計」ではなく、環境（型と要件）の制約が生み出した「ボトムアップの進化」の結晶と言えるでしょう。