8年の渇望、3か月で完成 - AIが変えたサイドプロジェクトの方程式
(lalitm.com)- 長らく不足していたSQLite向けの高品質な開発ツールを、AIの助けで短期間に完成
- 公式の文法仕様の不在と複雑なCコードベースにより、パーサー構築が最大の難関だった
- Claude CodeなどのAIコーディングエージェントを活用して初期実装を素早く進めたが、スパゲッティコードの問題によりRustベースでの書き直しを断行
- AIはコード生成・リファクタリング・学習支援・UX改善で大きな効率を見せた一方、設計の先送り・コードベースとの断絶・依存の中毒性といった副作用も生じた
- 結論として、AIは実装速度を高めるツールにすぎず、設計とソフトウェアの方向性は人間が責任を負うべき
AIで構築したSQLite開発ツール、3か月の記録
- SQLite向けの高品質な開発ツールを長年求めていたが、既存のオープンソースツールは信頼性・速度・柔軟性の面で不十分だった
- PerfettoSQLの保守中に、フォーマッター、リンター、エディター拡張などの機能需要があったが、適したツールがなかった
- 個人プロジェクトとして新しいツールを作ろうとしたが、難易度と反復作業の負担から何年も先送りになっていた
プロジェクトの難しさ
- SQLiteには公式の文法仕様や安定したパーサーAPIがない
- 内部的に構文木を生成しないため、ソースコードから直接パーサーロジックを抽出する必要があった
- 400以上の文法規則を一つひとつ対応付ける必要があり、テスト作成とデバッグは非常に反復的で消耗する作業だった
- SQLiteのCコードベースは複雑で密度が高く、理解が難しい
- 仮想テーブルAPIと実装を把握するだけでも数日かかるほど、構造が難解だった
AIと進めた開発プロセス
- 2025年末からClaude CodeなどのAIコーディングエージェントを本格活用
- 初期にはAIに設計・実装の大半を委ねる「vibe-coding」方式で進めた
- 成果物は動作したが、コードベースがスパゲッティ状に複雑化し、保守不能な水準になった
- その後、全体をRustで書き直し、構造を再定義
- CではなくRustを使うことで、上位コンポーネント（バリデーター、言語サーバーなど）を開発しやすくした
- AIは「自動補完を強化する道具」に限定し、設計・レビュー・テストは自分で主導
- リンティング、検証、テスト自動化など、AIの成果物を検証するためのスキャフォールディングを構築
AIが可能にしたこと
-
惰性の克服
- AIが具体的な問題単位に作業を分解し、着手しやすくしてくれた
- 「SQLiteパースを理解しなければならない」から「AIが提案したアプローチをレビューする」へと転換し、実行速度が向上
-
コード生成とリファクタリングの速度
- 要件が明確なとき、AIは標準的で一貫したコードをすばやく書ける
- 非標準的な設計（パーサー構造など）では、むしろ邪魔になり、自分で書く必要があった
- 大規模なコード生成の後には継続的なリファクタリングが必須で、それによって品質を維持した
-
学習支援役
- AIがWadler-Lindigフォーマットアルゴリズムのような新しい概念をリアルタイムで説明
- Rust、VS Code拡張など不慣れな領域でも素早く入り込めた
- プロジェクトの文脈を見失ったときも、「このコンポーネントを説明して」といった問い合わせで即座に文脈を復元できた
-
完成度の向上
- エディター拡張、Pythonバインディング、WASMプレイグラウンド、ドキュメントサイトなど、付加機能の開発コストを下げた
- 実装負担が減ったことでUX改善に集中でき、エラーメッセージやCLI設計などユーザー体験を強化できた
AI利用の副作用
-
中毒性
- 「もう一度プロンプト」を繰り返すスロットマシン型の報酬構造
- 疲れるほどプロンプトの品質が落ち、結果も悪化して悪循環が起きた
-
コードベースとの断絶
- AI生成コードが増えるほど、細部の構造に対する感覚を失う
- 文脈を失うとAIとの対話も長くなり、非効率になった
- 対策として、生成直後にコードを自分で読み、「自分ならどこを違う形で書いたか」を点検する習慣を導入
-
設計の先送りと腐食
- リファクタリングが容易なため、中核となる設計判断を先送りする傾向が生じた
- テストが多くても根本的な設計ミスを覆い隠すのは難しく、結局は全面的な書き直しが必要になった
-
時間感覚の欠如
- AIはコードの時間的文脈や進化の過程を理解できない
- 過去のミスを繰り返したり、すでに解決した問題を再探索したりする非効率が生じた
- 文書化で補えるが、設計意図まで完全に記録するのは難しい
AI活用の相対性
- 深く理解している領域ではAIは卓越しており、素早いレビューと反復が可能
- 例: パーサー規則の生成は明確な正解があるため効率的
- 部分的に分かっている領域では学習ツールとして有用だが、継続的な注意が必要
- 例: フォーマッターアルゴリズムの学習
- 何を作るべきか分からない段階では、むしろ有害
- 例: アーキテクチャ設計段階で非生産的なループが発生
- 検証可能な問題（コンパイル・テスト通過）にはAIは強いが、
デザイン・API品質のように正解のない問題には弱い
結論
- 8年間構想していたSQLiteツールを3か月で実現できたのはAIのおかげ
- ただしその過程は単純な成功談ではなく、AI依存の限界と代償を伴っていた
- AIは実装を加速する装置ではあるが、設計の代替物ではない
- 技術的な質問には正確に答えられても、歴史・好み・ユーザー感覚は欠けている
- 真の教訓は、AIによってより速く壁にぶつかれるとしても、
人間が設計の方向性と「ソフトウェアの魂」を担わなければならないという点にある - 今後必要なのは、実際のユーザーと保守に耐える水準のプロジェクト事例の共有
- 単なる実験ではなく、現実的で持続可能なAI協業開発の経験の蓄積である
1件のコメント
Hacker Newsの意見
AIコーディングに対するバランスの取れた視点が新鮮だった
たいていの真面目な開発者なら共感できる話だと思う。最初はAIがうまくコードを書くことに驚くが、後から見るとコードベースがスパゲッティコードでめちゃくちゃになっている
コードレビューもせずに「もう手動コーディングは終わった」と騒ぐ人もいれば、「AIコーディングは役に立たない」と決めつける人もいる
でも現実はその中間のどこかにある。AIは大きな生産性の加速装置になり得るが、正しくワークフローに組み込み、人間が継続して関与する必要がある
最初はプロトタイプだったが、すぐに実サービスへ発展した。その後、リファクタリングしながら不要なコードを片付けるのに苦労した
それでも、あの素早いプロトタイプがあったからこそ今の製品が存在する。Claudeはまるでチェーンソーのようにコード整理に役立った
最近はpre-commitフックで型チェッカーを追加し、90件のエラーを2時間で修正した。
AIコーディングは驚異的だが、プロダクションコードでは依然として人間のレビューと判断が不可欠だ
ただ、この事例は個人のグリーンフィールドプロジェクトなので、一般的なチーム開発にそのまま当てはめるのは難しい
それでも、プロトタイプを「捨てる前提」で作るならスパゲッティコードでも問題ないと思う。
問題は、著者がそれを本物の製品へ育てられると錯覚したことだ。
ただ、その失敗のおかげでよりよい設計を学べたはずだと思う
最初は驚き、次に失望し、最後にバランスを見つける。
まるでAI版のキューブラー＝ロスモデルのようだ
もちろん品質は重要だが、今ではコード品質そのものの重要性が下がりつつある
個人用アプリのように保守が不要なコードは増えており、AIの設計能力も急速に向上している
結局のところ「AIコーディングの真実」は変わり続けており、この流れは止まらないだろう
第一に、たいていの開発者は静かに2〜50%の生産性向上を享受していて、わざわざ騒がない
第二に、本当のAIコーディングは地味で絵にならない。
結局LLMは「ボイラープレートを暗記しなくてよくなる道具」にすぎず、コーディングの本質はそのままだ
私もAIによるテスト生成で同じ問題を経験した
テストが増えると安心感はあるが、実際にはエッジケースを扱えていない
特にテストのないレガシーコードをリファクタリングするとき、AIが作ったテストは動作していることしか確認せず、振る舞いの一貫性は保証しない
Reactアプリではこの問題が特に深刻だった。そこで今は、BDD + 仕様ベース開発をAIと組み合わせる方法を考えている
単体テストでは創造的なmock設計が、統合テストではデータ操作が、e2eテストではセレクタの安定性が核心になる
こうした創造的な判断は、まだAIには追いつきにくい
97%のカバレッジでも、論理的な入力空間には穴が多かった。
最近ではequivalence partitioningのような古典的手法をAIエージェントで自動化し、60個のモデルに適用した
純粋関数をできるだけ分離し、入力と出力のマッピングを完全にテストするのが核心だ
長期的には、AIの本当の価値は理解力を増幅する道具としての役割にあると思う
たとえば複雑なCコードの規則を分析して、構造を文書化するといったことだ
こうした知識抽出が可能になれば、APIドキュメントや規則マッピング、バグ解析、アーキテクチャ最適化まで自動化できる
結局、コードを生成することよりもコンテキストを構造化する能力のほうが重要になっていくだろう
① 要件だけ投げてアプリ全体を生成させる全知のオラクル型
② IDEの中で1行ずつ確認しながら使う補助ツール型
持続可能なサービスを作るなら、②のほうがはるかに現実的だ
「アーキテクチャはローカルな断片同士が相互作用するときに生まれる」という言葉が印象的だった
AIはローカルな実装には強いが、曖昧な設計段階には弱い
実際のところ、これは人間の開発者も同じだ。設計とは正解のないトレードオフの連続だからだ
特にClickHouseのSQL設計で大きな助けを得た
AIが提案したテンプレートベースのSQLインクルード方式のおかげで、重複を減らし性能も改善した
こうしたアプローチは以前からあったのかもしれないが、AIなしでは見つけにくかったと思う
この記事に説得力があるのは、250時間の実際の努力が注ぎ込まれているからだ
この規模のプロジェクトこそが、本物のAI支援システムプログラミングの現実的なモデルだと思う
「AIコーディングはスロットマシンみたいだ」という表現にとても共感する
私も会社で無制限のAIエージェント利用権を与えられているが、「もう1回だけプロンプト」とやっているうちに、
気づけば12時間たっている。没入の中毒性が強い
今がたぶんAIコーディングが最も難しい時期なのだと思う
6か月前には想像もできなかったことが、今では可能になっている
複数の言語でプロジェクトを進めているが、AIがコードをあまりにも速く作るので、
今ではレビュー速度がボトルネックになっている
ある程度テストが通ると、「これで十分なのか？」と悩み始める
私はプロンプトにSOLID原則、結合度、凝集度のような品質属性を明示している
AIにリファクタリング案を尋ね、よさそうなら「よし、実行して」と言えばいい
結局重要なのはプロンプト設計の技術だ
ただ、近いうちにAIがこうした品質ガードレールを標準で担うようになるとも思う
言語そのものが性能のボトルネックではないが、新しい言語を試すことは学習に役立つ
Fred Brooksの「一つは捨てよ」哲学を思い出す
AIはその最初のバージョン、つまりthrowawayを素早く作るのに最適だ
いきなりプロダクション品質を期待するのは愚かなアプローチだ
まず素早く作って学び、その後でリファクタリングするのが王道だ
疲れているとプロンプトが曖昧になり、結果も悪くなるという点にも共感する
SQLiteのSQLパーサーがlemonで生成されていないことに驚いた
pikchrをGoに移植したときは先にlemonを移植したが、SQLiteはパースツリーすら作らない
lemon文書を見ると、これは設計段階における問題定義の不足のように見える
私もこの記事の結論に全面的に同意する
AIコーディングの現実を誇張せず率直に見せてくれる良い事例だ