バイブコーディングからAI駆動開発へ

プロジェクションマッピング協会の三代です。

AIでコードを書ける時代になり、プログラミングの専門教育を受けていない人でも、アプリや自動化ツールをかなりの速度で作れるようになりました。私自身もその恩恵を強く受けている一人です。

大学ではPythonやPHPに少し触れたものの、何かを一人でゼロから作り上げるところまではなかなか到達できませんでした。ところが生成AIの登場後、GPT-4oと姿勢推定ライブラリを使ってカメラ系アプリを形にできた経験から、「AIは本当に開発の現場で使える」と確信しました。そこからAIを活用したコーディングに深く取り組み始め、2026年3月時点でおよそ2年近くになります。

プロジェクションマッピング協会でも、マッピング制作そのものだけでなく、周辺業務の自動化やAI活用を進めています。その流れの中で、AIで「動くもの」は作れるようになった一方で、こんな悩みも出てきました。

• 1か月後に自分でもコードの中身が追えない
• バグを直すたびに別の場所が壊れる
• コードが複雑化し、AIの修正精度まで落ちてくる

この記事では、そうした悩みに対して、バイブコーディングから一歩進んだ「AI駆動開発」という考え方を、できるだけわかりやすく整理して紹介します。

この記事はこんな人向けです

• コーディングの基礎はあまりないが、AIでアプリやツールを作り始めた人
• バグ修正のたびに別の不具合が出て困っている人
• コードがスパゲッティ化して、AIが以前より賢く動かないと感じている人

まず「バイブコーディング」とは何か

まずは「バイブコーディング」という言葉を整理しておきます。
この言葉は2025年ごろから広まり、「雰囲気でAIに指示し、とにかく動くものを素早く作る」開発スタイルを指す場面で使われています。

これは決して悪い手法ではありません。小さな自動化ツール、試作品、社内向けの簡易アプリなどでは、非常に強力です。実際、従来ならエンジニアに依頼しないと作れなかったものが、個人でも短時間で形になります。

ただし、サービスとして継続運用するもの、料金をいただくSaaS、障害が信用に直結するシステムになると話は変わります。

その段階で必要になるのは、

• 思いつきで足した機能が他を壊していないか
• 将来の修正に耐えられる構造か
• 別の人が見ても理解できるか

という視点です。
つまり、「動いたからOK」だけでは足りなくなります。

なぜバイブコーディングだけではつらくなるのか

AIはコード生成が非常に速いため、短期間で大量の変更を積み上げられます。これは大きな武器ですが、同時に「壊れる速度」も上がるということです。

以前は、ある程度経験のあるプログラマが最後にレビューすれば何とかなる場面も多くありました。しかし現在は、AIが短時間で大量のコードを出力できるため、単独の人手レビューだけに品質保証を頼るのはかなり難しくなっています。

ここで重要なのは、「人が見るのをやめる」ことではありません。
そうではなく、人のレビューを支えるために、

• テスト
• 設計の整理
• 変更履歴の分割
• ドキュメント化

を先に整えておくことです。

そこで必要になるのが「AI駆動開発」

私は、バイブコーディングの次の段階として「AI駆動開発」が必要だと考えています。

ここでいうAI駆動開発は、AIに丸投げすることではありません。
むしろ逆で、人間が方向を決め、ルールを与え、確認方法を先に用意した上でAIに実装させる進め方です。

「コードがよくわからないのに、どうやってAIをコントロールするのか」と思うかもしれません。ですが、開発の世界にはすでに先人たちの知見があります。設計、テスト、レビュー、リファクタリングなどのベストプラクティスを、AIに守らせながら使うのが現実的なやり方です。

その代表例が、テスト駆動開発（TDD: Test-Driven Development） です。

TDDを誤解なくシンプルに説明すると

TDDは、「先にテストを書く」「次に実装する」「最後に整理する」を短いサイクルで回す開発手法です。
Martin FowlerはTDDを、次の3ステップを繰り返す方法として説明しています。

1. 次に必要な機能のためのテストを書く
2. そのテストが通る最小限のコードを書く
3. コードを整理し、構造を改善する

よく「TDDをやれば品質が上がる」「カバレッジ80%あれば安心」といった説明を見かけますが、これは少し雑です。

大事なのは、カバレッジの数字そのものではなく、期待する振る舞いを先に明文化すること です。
コードカバレッジは参考指標にはなりますが、「80%だから安全」とは言えません。逆に、数字が高くても重要な異常系を見落としていれば、実運用では普通に壊れます。

例: 日本専用の天気アプリ

たとえば「日本国内の住所だけを受け付ける天気アプリ」を作るとします。

このとき、正常系のテストだけを書いていると、

• 東京都の住所を入れたら天気が返る

だけを確認して満足してしまうかもしれません。

しかし実際には、異常系も重要です。

• 海外の住所を入れたらエラーにする
• 空欄ならエラーにする
• 存在しない住所形式ならエラーにする

こうした条件を先にテストとして書いておけば、AIが「とりあえず何か返してしまう」実装をしたときにも、すぐ検知できます。

TDDがAIコーディングと相性が良い理由

AIで開発していると、よくあるのが次の状態です。

• 1つのバグを直したら別のバグが出る
• 修正を重ねるほどコードが読みにくくなる
• どこまで直ったのか判断できない

TDDや自動テストがあると、修正のたびにテストをまとめて実行できます。すると、ある変更が別の機能を壊していないかを機械的に確認できます。

つまりAI時代におけるテストは、単なる品質管理ではなく、AIへのフィードバック装置 でもあります。
「この修正で何が正しいのか」を自然言語だけで毎回説明するのではなく、テストという形で機械可読にしておくわけです。

これは、コードが読めない人にとっても大きな助けになります。
なぜなら「正しいかどうか」の判定を、感覚ではなくテスト結果で見られるからです。

AI駆動開発で最低限そろえたいもの

ここまで読むと難しそうに見えるかもしれませんが、最初から完璧である必要はありません。まずは次の4つがあるだけでも、かなり変わります。

1. 仕様を短く書く(Planモードを使用)

AIにいきなり実装させるのではなく、先に以下を書きます。

• 何を作るか
• 何を入力にするか
• 何を返すか
• どういうとき失敗とするか

これだけでも、AIの暴走がかなり減ります。
実装よりもPlanモードで出来上がる仕様が自分の意図したものかをしっかり調べ、壁打ちすることに時間を費やしてください。
三代個人的にはCodexのplanモードよりClaude codeの方がより具体期な仕様でPlanをしてくれるのでおすすめです。

2. 正常系と異常系のテストを作る（/tddコマンド）

最低限、以下は分けて考えるのがおすすめです。

• 期待通り成功するケース
• 入力ミスで失敗するケース
• 想定外データで壊れないケース

3. 変更を小さく分ける（Planモード内でTodo作成）

「UI変更」「DB変更」「認証変更」を一度にやらせると、AIも人間も追えません。
変更を小さく分けるほど、問題の切り分けが楽になります。

4. READMEやメモを残す

AIで作ったコードほど、後から人間が見失いやすいです。
少なくとも以下は残した方がよいです。

• このアプリは何をするものか
• 起動方法
• 主要ファイルの役割
• よくあるエラー

「未来の自分向けマニュアル」を残す感覚が大切です。

※注意点としてはコード内に不要なコメントでメモは残さないでください。このメモは仕様が変わった際にAIを混乱させる技術的負債としてのこり、後のバグにつながります。ドキュメントはreadmeにまとめるようにしてください。AIにとっては、このコードはこんな問題があったから一旦無視していい、などの経緯は一切通じません。そこにあるコード、メモが最新として扱われます。
コードいれたメモの鮮度を保つのは不可能なためメモを入れないことをおすすめします。

ECCとは何か

ここで紹介したいのが、Everything Claude Code（ECC） です。

ECCはAnthropicの公式製品そのものではなく、コミュニティ主導で整備されている大規模なリポジトリです。ルール、スキル、ガードレール、セキュリティ関連の設定、エージェント運用の知見などがまとめられており、Claude CodeやCodex、Cursorなど複数のAI開発環境で活用できるように設計されています。

2026年3月21日時点で、GitHub上の affaan-m/everything-claude-code は 約91.5k stars を獲得しており、かなり強い注目を集めています。

私の理解では、ECCは「AIに正しい開発の癖を身につけさせるための土台」に近い存在です。単なる設定ファイル集ではなく、

• 開発ルール
• 調査の進め方
• セキュリティの考え方
• メモリ運用
• スキルの再利用

といった、AIエージェント運用の実践知がまとまっています。

そのため、「AIで書けるようにはなったが、品質が安定しない」という段階の人にはかなり有益です。

Claude Codeはなぜ有力か

Claude CodeはAnthropicが提供する公式のAIコーディング環境です。公式ページでも、ターミナルやIDE上でコードベースを探索し、質問に答え、変更を加え、CLIツールと連携できることが案内されています。

もちろん、Cursorなど他の選択肢もあります。どれが絶対に正しいというよりは、

• 普段の作業環境に合うか
• 権限管理がしやすいか
• テスト実行や修正の往復がしやすいか

で選ぶのが現実的です。
そのうえで、ECCのような知見を組み合わせると、AIの出力品質を一定以上に保ちやすくなります。

結局どう始めればいいか

もし今、

• AIでいろいろ作れて楽しい
• でも保守がきつい
• バグ修正が怖い

という状態なら、次の順で進めるのがおすすめです。

1. まずは今作っているものの仕様を短く文章化する（先にplanモードを使う。）
2. ECCを導入し /tddコマンドを使用しその仕様通りのテストを書いてもらう。
3. 大きな修正をやめて、小さな変更単位でAIに頼む
4. READMEに「これは何か」「どう動かすか」を残す
5. Claude CodeやCursorのようなAI開発環境に、ECCのような知見を取り込む

これだけでも、「作れるけれど保守できない」状態からかなり脱出しやすくなります。

まとめ

バイブコーディングは、AI時代の強力な入口です。実際、それによって開発の裾野は大きく広がりました。
ただし、作るものが大きくなり、長く運用する必要が出てくるほど、「雰囲気で進める」だけでは厳しくなります。

そこで必要になるのが、AI駆動開発へのアップグレードです。

• 仕様を先に言語化する
• テストで期待値を固定する
• 小さく変更する
• ドキュメントを残す
• AIに守らせるルールを用意する

この発想に切り替えるだけで、AIコーディングは単なる勢い任せの作業から、継続運用できる開発へ変わっていきます。

ECCのような実践知の集合体は、その移行を助ける有力な選択肢の一つです。まだ触れていない方は、まずリポジトリを見て、自分の使っているAI開発環境でどう取り込めるか試してみるとよいと思います。

• ECC: https://github.com/affaan-m/everything-claude-code

参考リンク

• OpenAI, “Hello GPT-4o” – https://openai.com/index/hello-gpt-4o/
• Martin Fowler, “Test Driven Development” – https://martinfowler.com/bliki/TestDrivenDevelopment.html
• Anthropic, “Claude Code” – https://claude.com/product/claude-code
• GitHub, affaan-m/everything-claude-code – https://github.com/affaan-m/everything-claude-code