はじめに：バイブコーディング時代の到来
最近「バイブコーディング」という言葉を耳にする機会が増えました。
AIアシスタントの力を借りて、直感的にコードを書いていく開発手法のことです。
ChatGPTやClaude、GitHub Copilotといったツールの普及により、プログラミング経験が少ない人でもアプリ開発に挑戦できる時代になりました。
実際、私自身もフロントエンドエンジニア兼UIデザイナーとして、JavaScriptは得意でした。
しかし機能的なアプリ開発の経験は多くありませんでした。
それでもAIの力があれば何とかなるだろうと思い、念願だった自分のアプリ開発に挑戦することにしたのです。
今回は、その3ヶ月間のリアルな開発体験をお話しします。
結論から言うと、コードが書けることとアプリが完成することは全く別の話でした。
実体験：3ヶ月のDiffアプリ開発奮闘記
始まりはシンプルなテキスト比較ツール
開発したのは、テキストやファイルの差分を視覚的に表示するDiffアプリでした。
最初はとてもシンプルで、2つのテキストを入力すると違いをハイライト表示するだけの機能でした。
AIに「テキスト差分を表示するアプリを作りたい」と相談すると、驚くほどスムーズにベースコードが生成されました。
「これは簡単だな」と思ったのが、すべての始まりでした。
動くものができると、どんどん欲が出てきます。
「フォルダ同士の比較もできたら便利だろう」「納品用のデータを自動生成する機能もあったらいいな」と、思いついた機能を次々と追加していきました。
思いつきで積み重ねた機能の数々
最初の1ヶ月は順調でした。
新しい機能を思いつくたびにAIに相談し、コードを書いてもらい、少し調整して動かす。
この繰り返しが楽しくて仕方ありませんでした。しかし、2ヶ月目に入ると状況が変わってきました。
新しい機能を追加するたびに、既存の機能が壊れるようになったのです。
「あれ？先週まで動いていたテキスト比較が動かない」「フォルダ比較を追加したら、なぜか保存機能がエラーを起こすようになった」といった問題が頻発しました。
1ヶ月前に自分が作った機能なのに、どんな仕組みで動いているのかを思い出せません。
コメントもろくに書いていなかったため、過去の自分が何を考えてそのコードを書いたのかが全く分からなくなってしまいました。
大改修という名の迷宮
3ヶ月目に入り、さすがにこのままではまずいと思い、2日間かけて全体のコード構造を統一しようと試みました。
しかし、これが更なる悪夢の始まりでした。一つの部分を修正すると、思わぬところでエラーが発生します。
そのエラーを修正すると、また別の場所で問題が起きる、という悪循環に陥りました。
ここで白状すると、この3ヶ月間、私は「設計の検証」と「動作確認」ばかりを繰り返していて、実質的に完成したコードは一つもありませんでした。
「この機能を追加したらどうなるか」を試しては壊し、「こっちの構造の方がいいかも」と作り直しては元に戻す。
その繰り返しで3ヶ月が過ぎていたのです。
結局、2日間の大改修は失敗に終わり、以前よりも不安定な状態になってしまいました。
この時点で、アプリは一見動いているように見えますが、実際には継ぎ接ぎだらけの不安定な代物になっていたのです。
挫折の瞬間：Apple審査という現実の壁
TestFlightでの起動失敗
それでも何とか形にして、いよいよAppleのTestFlightで公開テストをしようと思いました。
ローカル環境では問題なく動いていたアプリが、TestFlight環境では起動すらしませんでした。
エラーメッセージを見ると、使用していたフレームワークがiOSの制限に引っかかっていることが判明しました。
開発初期の段階で、AIに「iOSアプリとして公開できるフレームワークを教えて」と聞いていれば防げた問題でした。
しかし、その時の私は「とりあえず動けばいい」という考えで、深く調べずにフレームワークを選択していたのです。
3ヶ月の努力が水の泡
この瞬間、3ヶ月間の努力が水の泡になったと感じました。
フレームワークを変更するには、アプリの根本的な部分から作り直す必要がありました。
しかし、現在のコードベースは複雑に絡み合っており、どこから手をつければいいのか全く分からない状況でした。
結果的に、アプリの公開を断念することになりました。バイブコーディングで「コードが書ける」ようになったはずなのに、なぜこんなことになったのでしょうか。
気づき：コードが書けることとアプリが完成することは別
根本的な設計思想の欠如
振り返ってみると、私の開発には根本的な設計思想が欠けていました。
「どんなユーザーが」「どんな場面で」「どんな問題を解決するために」このアプリを使うのか、という基本的な問いに答えられませんでした。
機能を思いつきで追加していた結果、誰のためのアプリなのか分からない代物になっていたのです。
テキスト比較をしたい人なのか、ファイル管理をしたい人なのか、それとも納品作業を効率化したい人なのか。
ターゲットユーザーが曖昧だったため、機能の優先順位も決められませんでした。
技術選定の重要性
また、技術選定の段階でもっと慎重になるべきでした。
「動けばいい」という考えで選んだフレームワークが、最終的にアプリの公開を阻む要因になってしまいました。
アプリ開発では、最初の技術選定が後々まで影響することを痛感しました。
継続的な設計の必要性
さらに、機能を追加するたびに全体の設計を見直す必要があることも学びました。
新しい機能が既存の機能とどう連携するのか、全体のユーザー体験にどう影響するのかを考えずに開発を進めた結果、一貫性のないアプリになってしまいました。
解決策：GitHub Spec Kitという新しいアプローチ
仕様駆動開発という考え方
この失敗体験を通じて、私は「仕様駆動開発（Spec-Driven Development）」の重要性に気づきました。
コードを書く前に、まず「何を作るのか」「なぜ作るのか」「どう作るのか」を明確にする必要があります。
これは当たり前のことのように聞こえますが、バイブコーディング時代には意外と見落とされがちな観点です。
そんな中、2025年9月にGitHubがSpec Kitというオープンソースツールを公開しました。これは、仕様駆動開発を支援するためのツールキットで、AIコーディングエージェントと組み合わせて使います。
Spec Kitの開発フロー
Spec Kitでは、以下のような流れで開発を進めます。
1. **`/specify`** – 仕様書を作成
2. **`/plan`** – 実装計画を策定
3. **`/tasks`** – 実行可能なタスクに分解
各フェーズにゲートがあり、品質を担保しながら進められます。Claude Code、GitHub Copilot、Cursorなど主要なAIエージェントに対応しているのも魅力です。
このプロセスを踏むことで、「思いつきで機能追加」という悪循環から脱却し、一貫性のあるアプリ開発が可能になると期待しています。
まとめ：仕様駆動開発の重要性
バイブコーディングは確かに素晴らしい技術です。
プログラミングの敷居を下げ、多くの人がアプリ開発に挑戦できる環境を作りました。
しかし、コードが書けることと、実際にユーザーに価値を提供するアプリを完成させることは全く別の話です。
私の3ヶ月間の挫折体験から学んだ最も重要な教訓は、「仕様の明確化こそが成功の鍵」ということでした。
AIの力でコードを書くスピードは格段に上がりましたが、「何を作るべきか」を考えるプロセスは人間にしかできません。
これからアプリ開発に挑戦される方は、コードを書く前に十分な設計時間を取ることをお勧めします。
遠回りに見えるかもしれませんが、結果的には最も効率的な開発につながるはずです。
私の経験が、どなたかの参考になれば幸いです。
