「いつか作りたい」から8年。AIを味方にしたら、たった3ヶ月で完成した話

8年間ずっと「これを作りたい」と思い続けながらも、なかなか形にできなかったプロジェクト。それがAI（生成AI）の力を借りることで、驚くべきことにたった3ヶ月で開発・完成まで漕ぎ着けることができました。長年の構想を現実にするための、AIを活用した開発の圧倒的なスピード感と可能性についてまとめた投稿です。

この記事、俺は信じるよ。注ぎ込まれた労力が半端ない、250時間だぞ！自分がやってきた小規模なプロジェクトから考えても、この記事は「AI支援による本格的なシステムプログラミングプロジェクト」がどんな感じになるかを示す、いいモデルケースだと思う。

これ、俺の経験とマジで近いわ。結論にも同意するし、もっとこういう事例が増えてほしいね。

AIコーディングに対して正直でバランスの取れた意見が見れるのは新鮮だね。AIにコードを書かせて「お、動いた、指示通りだ」っていう最初の感動を通り越した後の、リアルなAI支援コーディングってまさにこんな感じ。AIコード生成を使ってからその出力をレビューしたことがあるエンジニアなら、みんなこの経験に心当たりがあるはずだ：『1月後半にコードベースを詳しくレビューしたとき、欠点は明白だった。完全にスパゲッティ状態だったんだ。Pythonのソース抽出パイプラインの大部分が理解不能で、関数は明確な形もなく適当なファイルに散らばり、数千行に膨れ上がったファイルもいくつかあった。極めて脆弱で、目の前の問題は解決できても、より大きなビジョンに対応できる代物ではなかった』。コードをレビューする段階までたどり着かない人もいる。そういう人たちは真っ先にLinkedInやブログに行って、「手書きのコーディングは終わった、もう一生手でコードは書かない」なんて投稿を（ChatGPTに書かせたりして）始めるんだよね。逆に、コードを見て「使い物にならないゴミだ」と断定し、SNSで「AIコーディングは全くの無価値、何にも使わない」と投稿する人もいる。このブログ記事は、そのどちらの極端な少数派でもない人たちが今通っている道のりを示してる。つまり、AIツールは強力なアクセラレーターになり得るけど、ワークフローの中で正しく使う方法を学ぶ必要があるし、コードに深く関わり続ける必要があるっていう気づきだ。よくあるクリックベイト的な極論に比べると地味だし、「結局はハードワークが必要」なんて部分は読んでて少しがっかりするかもしれないけど、これがAIコーディングの現状に対する現実的でバランスの取れた見方だよ。

「アーキテクチャとは局所的なパーツが相互作用した結果であり、局所的に正しいコンポーネントを繋ぎ合わせるだけでは、優れた全体的な振る舞いは得られない」――これ、めちゃくちゃいい記事だね。レイヤードAI（階層的なAI利用）でこのギャップをどう埋められるか試行錯誤してるけど、今のモデルは曖昧な設計フェーズが苦手な気がする。局所的な実行フェーズでは素晴らしいんだけどね。これってソフトウェアエンジニアリング全体を反映してる気もするな。大抵の人は設計が苦手だし、繰り返しと経験で上手くなっていくもの。でも、設計には「正解」がなくてトレードオフの連続だから、今のモデルが人間と同じプロセスを再現するのは難しいのかも。

長期的には、AIが提供する最大の価値は「理解を得るための強力なツール」になることだと思う。LLMのアウトプットの目標が、近いうちに「深い理解」へと変わっていくんじゃないかな。例えば、このプロジェクトの障害は400ものルールがある複雑なCコードだった。LLMを使えばその構造や理解を解析してツールを作れるけど、もっと有用なアウトプットは、ルールとその相互作用を完全に文書化することかもしれない。新しいコードからならもっと簡単に抽出できるだろうけど、APIドキュメントとか、解説を交えた論理ルールセットの紐付けとかを想像してみてほしい。そうすれば他の開発ツールも簡単に作れるし、コードに依存せずにルールの構造からバグ分析したり、アーキテクチャレベルで最適化を判断したりできる。LLMが何を作るべきかを知るには人間が必要だ。コード生成が簡単になれば、次は「柔軟なコンテキストや理解」を体系化することが、労力なしで生成できるものをさらに増幅させるためのゴールになるはず。

今が一番難しい時期なんだろうね。この一年、俺もずっとそんな感じ。先月やったことの多くは、たった半年前にはSFの世界の話だった。可能性の範囲と質が、数週間ごとに飛躍的に進化してる気がするよ。今は使ったことのない言語でプロジェクトをいくつか進めてる。Rustのサイドプロジェクトと、Goのプロジェクトが2つ。JavaやKotlin（ここ10年）、たまにPythonでバックエンド開発を数十年やってきた経験はあるし、他にもいくつかかじった言語はある。バックエンドの構造化や、何に注意すべきか、何にテストが必要かとかは分かってる。多くの人は、AIが生成したものはすべてレビューすべきだと言うし、それは極めて妥当だ。ただ、今のAIは俺がレビューするより速くコードを生成する。レビュー能力がボトルネックになってるんだ。で、手動や自動テストで「なんとなく動いてる」ことが証明されたとき、どの時点で「これで十分」とするか？簡単な答えはないけど、許容できるデューデリジェンスのレベルは考えておく必要がある。「バイブス・コーディング」は目隠しして壁に何かを投げつけるようなもんだけど、エージェント型エンジニアリングはその対極にある。俺はプロンプトで品質特性をかなり強調するようにしてる。優れた設計、高い凝集度、低い結合度、SOLID原則の重要性とかね。その辺を意識してリファクタリングを提案させるだけで、大抵いくつかいい案が出てくる。あとは「いい感じだね、やっちゃって」と言うだけ。こういうバカげたプロンプトのバリエーションを楽しむのもちょっとした快感だよ。「Make it so（例のあれ風に：やってくれ）」がお気に入り。いいプランさえあれば、何を打ち込むかは大した問題じゃないんだ。それと、エッジケースや異常系のテスト、堅牢化、並行処理、レイテンシ、スループットについても厳しい質問をぶつけるようにしてる。そうしないと、AIは近道を選んだり、正常系だけに集中したり、全部大丈夫だとハルシネーションを起こしたりするから。でもこれを見つけるのに必ずしも詳細なレビューはいらない。AIにコードをレビューさせて、間違っている点や改善できる点の詳細リストを作らせればいい。ちゃんとプロンプトを組めば、見つけるべきものは見つけてくれる。これには技術がいるけど、それも手間がかからなくなっていく予感がする。結局は、失敗しがちなことを正しく行うためのガードレールを進化させる話だしね。AIがデフォルトでこれらを正しくやり始めたら？どんどん良くなっていく一方だと思うよ。

これは俺も経験ある。AIと仕事をする上で、テストはおそらく最もやりがいがあり（難しく）、かつ重要な部分だね。特に最悪なのは、テストがそもそもないクソコードをリファクタリングするとき。機能が混乱してたり、知らないところで不適切に使われてたりする場合だ。AIは「ロジックがとりあえず動くか」というテストケースは書くけど、振る舞い、特に統合テストでカバーすべき範囲は全然カバーしてくれない。これに対するいい答えはまだ見つかってないんだ。特にReactアプリだとテストのベストプラクティスが分からなくて苦労してる。でも、BDD（振る舞い駆動開発）とAIによるスペック駆動開発を組み合わせるのが、一つの答えになるんじゃないかと注目してるところ。誰か、いいテストを生成するためのアプローチやフレームワークを持ってる人いない？

AIツールとそれが与える影響について、ハイプ抜きの現実的な体験談が見れて本当に良かった。> 『1月後半にコードベースを詳しくレビューしたとき、欠点は明白だった。完全にスパゲッティ状態だったんだ…極めて脆弱で、目の前の問題は解決できても、より大きなビジョンに対応できる代物ではなかった…すべて捨ててゼロからやり直すことに決めた』この部分は興味深かったな。フレッド・ブルックスの「一つは捨てるつもりで書け」という哲学に通じるものがある。「ほとんどのプロジェクトにおいて、最初に作ったシステムはかろうじて使える程度だ。だから一つは捨てる計画を立てろ。どうせ捨てることになるんだから」。この経験が示す通り、AIツールはその「最初に捨てるバージョン」にたどり着くまでの時間を大幅に短縮してくれる。それこそがAIの真骨頂だ。AIに最初からプロダクションクオリティを期待するのは愚かなことだよ。とりあえず素早く実装して、どう動くか見て学び、その上で設計にこだわりを持ってリファクタリングする。これが正しいAIの使い方だね。TDDの「Red, Green, Refactor」に近い。まず失敗するテストを書き、コード品質は気にせず最速でパスさせ、それからコードを改善して信頼性を高める。時間が経って、今のハイプサイクルが落ち着けば、これが長期的にAIツールを活用する最善の方法だとみんな気づくだろう。> 『エネルギーがあるときは、正確で範囲を絞ったプロンプトが書けて、本当に生産的だった。でも疲れているときはプロンプトが曖昧になり、出力も悪くなった』この部分も同感だわ。自分が何をしたいか明確なときは具体的な仕様が書けてAIを誘導できるけど、曖昧なときは出力もひどくなって、結局それを理解したり再プロンプトしたりするのに余計な時間を取られるんだよね。

「AIコーディングツールを使うのとスロットマシンを打つのには、嫌な共通点がある。プロンプトを送り、待ち、素晴らしいものかゴミのようなもののどちらかが出てくる。夜遅くまで『あと一回だけプロンプトを…』となってしまい、上手くいかないと分かっていても何が起こるか見たさにAIを試し続けてしまう。サンクコストバイアスも働く。『言い方を変えれば今度は上手くいくかも』と、明らかに不向きなタスクに固執してしまうんだ」。うわぁ、これ刺さるわ…。最近職場で、期間限定のキャンペーンとして全主要モデルが使い放題のコーディングエージェントが導入されたんだけど。「あと一回プロンプトを」っていうモードに入っちゃうと仕事をやめるのがめちゃくちゃ難しくて、気づいたら12時間労働とか余裕でいっちゃうんだよね。

SQLiteって、SQL用にlemonパーサーで生成したものを使ってないんだっけ？（同じSQLiteプロジェクトの）pikchrをGoに移植したときは、まずlemonを移植して、次にグラマー、その後にサポートコードって順でやったよ。SQLパーサーでも同じことをやろうと思ってたんだけど、pikchrのグラマーに比べると桁違いに複雑なんだよね。