はじめに
最近、ClaudeやGeminiといったAIに様々なアプリケーションを作ってもらっています。「こういうものが欲しい」と伝えるだけで、それなりに動くものを仕上げてくれるのは驚きです。世の中ではこのような開発スタイルをVibe-Codingと呼んでいるようです。
この記事では、私がRustile（Rust製のX11向けタイル型ウィンドウマネージャー）をVibe-Codingで開発する中で感じたことと、開発体験をより良くするために試したことをまとめます。
Vibe-Codingで感じたこと
開発を進める中で、いくつか気になることがありました。
理解が追いつかないまま開発が進む
要件や設計をよく理解していない状態で、AIが出力したコードを雰囲気でレビューしてしまうことが何度もありました。もちろん、これは雰囲気でレビューした自分の問題なのですが、そういう対応が積み重なると「よくわからない部分」がどんどん大きくなっていきます。その結果、追加の開発は既存のコードをベースとするので、難しくなっていきました（仕事でも経験したことあるなぁ）。
設計や技術的な詳細を説明するドキュメントをAIに書かせることを試してみました。ただ、特に開発初期はコードを頻繁に変更するので、ドキュメントがすぐに陳腐化してしまいます。開発の度にそれらを更新するのは、コストに見合わないので続きませんでした。
書いてみて・試してみてわかることがある
これまでの開発なら、作りたい機能について実装方法をあれこれ検討したり、アイデアをちょっと試したりする過程があったと思います。でもVibe-Codingだと、その過程を飛ばして一気に成果物が出てきます。
実際に手を動かして試す中で初めてわかることって結構あると思います。それをコードにフィードバックする機会がないまま進めてしまうことに違和感を覚えました。また、完成したコードを見てフィードバックするのと、自分で検討や試行錯誤をした後にフィードバックするのでは、質も量も全然違うなと思います。
達成感・成長実感を得にくい
AIがまるっと作ってしまうので、自分であれこれ考えながら解決策を探る、そういう主体的なプロセスが抜け落ちていると感じました。プログラミングの楽しさは、こういう部分にもあると私は思います。
自分で作った実感が薄いと、達成感も成長実感も得にくいです。これは、自分がコードベースをどれだけ理解できているか、作るのに苦労したのかという話とも関係していると思います。
ADRの導入
こういった点を改善するために、**Architecture Decision Records（ADR）**をVibe-Codingのプロセスに組み込んでみることにしました。
ADRとは
ADRは、ソフトウェア開発での重要な設計判断を記録するドキュメントです。「なぜその設計を選んだのか」という意思決定のプロセスと根拠を残すことで、後から見返したときに背景を理解できるようにします。
どう導入したか
まずはWindow Rotation機能の実装で試験的にADRを書いてみました。記録したのは以下のような内容です。
- Context: ユーザーがウィンドウを回転させて配置を変える機能が必要。考えられるアプローチを列挙。
- Decision: 採用したアプローチとその説明。具体例。
- Consequences: その方法のメリット・デメリット、代替案とそれを採用しない理由。
開発を続けるうちに、このようなテンプレートに落ち着きました。ADRの草案をAIに書かせて、ステータス（Proposed、Accepted、Deprecated）を私が管理する形式にしました。
何が変わったか
ADRを導入したことで、いくつか良い事がありました。
まず、「なぜそのようなコードになっているのか」という背景を明文化するので、前よりも理解しながら開発を進められるようになりました。また、Proposedというステータスを用意したことで、いきなり実装に進まず、実装方針を検討する段階を踏めるようになりました。
結果として、試行錯誤のプロセスもある程度取り戻せたし、自分が作ったという感覚も前よりは得られるようになりました。
類似のアプローチ
私と同じようなことを感じている人をXや記事で見かけます。実際、Vibe-Coding, AI駆動開発を段階的に進めるためのツールも登場してきています。
Amazon Kiro
AmazonがKiroというVS CodeベースのAI IDEをリリースしています。**Spec-Driven Development（仕様駆動開発）**というアプローチを採用していて、プロンプトから仕様（要件・設計・タスク）を生成し、その仕様を詰めた上でAIが実装するという流れで開発を進めるのが特徴です。
cc-sdd
ClaudeでKiroと同様の仕様駆動開発を実現することを目指したcc-sddというツールもあります。要件定義（Requirements）→設計（Design）→タスク分解（Tasks）→実装（Implementation）という4段階のワークフローで開発を進めます。
cc-sddは今後試してみたいと思っています。このADRベースの開発とどう違うのか、あるいは統合することでより良い開発体験にならないか、試してみたいです。
まとめ
Vibe-Codingは雰囲気でそれなりのソフトウェアを作ってくれます。でも同時に、理解が追いつかないまま開発が進む、書いてみて・試してみてわかることをフィードバックできない、達成感や成長実感を得にくいといった気になる点もありました。
この記事で紹介したADRの導入は、そういった点を改善する一つの方法になりました。設計判断を明文化して段階的に開発を進めることで、理解しながら開発を進められるようになったし、試行錯誤のプロセスも取り戻せました。
Kiroやcc-sddといった仕様駆動開発のツールの登場や広がりを見ていると、AI駆動開発を段階的に進めることの重要性が認識されていると感じます。Vibe-Codingで同じような違和感を覚えた方がいたら、ADRの導入や仕様駆動開発を試してみるのが良いかもしれません。