AI駆動開発とは何か — Vibe Codingとの違いをどこで引くか

AI駆動開発とは

AI駆動開発とは、AIにコードを書かせる工程を、権限・レビュー・監査という運用の仕組みで囲ってから業務に組み込む開発の進め方である。「AIが書く」こと自体は Vibe Coding と同じで、違うのは書かせたあとの扱いにある。

Vibe Codingの定義

Vibe Coding という語は、2025年2月にAI研究者のAndrej Karpathy氏がX（旧Twitter）で最初に使った。氏は自身の使い方をこう表現している。

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.

「コードの存在を忘れるほどAIに委ねる」という定義そのものが、個人の探索的な開発を指している。成果物が動けばよいという前提であり、これは週末のプロトタイピングや使い捨てのツール作りには合理的なやり方である。

業務の開発で違ってくる3点

業務でコードを書くときは、Vibe Codingの前提がそのまま成り立たない。理由は3つある。

第一に、書いたコードを誰が読むかが違う。 個人のプロトタイプは書いた本人しか読まないが、業務のコードは他のエンジニア・将来の自分・場合によっては監査の対象になる。「AIが書いたから中身を読んでいない」は、業務では説明責任を果たせない。

第二に、失敗の影響範囲が違う。 個人の実験が失敗しても自分が困るだけだが、本番のデータベースへの書き込みやリリースのミスは他者に影響する。取り返しがつく失敗と、つかない失敗を区別する必要が出る。

第三に、変更を誰が承認したかを後から示せる必要がある。 「なぜこの変更が入ったか」を後から追えないコードは、業務では負債になる。

権限を絞る、という選択肢

Vibe Codingとの違いを「気をつけて使う」という精神論に留めると、効き目は使う人の注意力に左右される。業務での使い方は、AIが到達できる範囲そのものを狭める方向に寄る。

Claude Codeでいえば、サブエージェントに与えるツールを制限する機能がこれにあたる。公式ドキュメントは、サブエージェントの利点として「Enforce constraints by limiting which tools a subagent can use」（どのツールを使えるかを制限することで制約を強制する）を挙げている。各サブエージェントは独立したコンテキストと独立した権限で動き、タスクごとに「読み取りだけ」「特定のディレクトリだけ」といった絞り込みができる。

さらに、Hooksという仕組みを使うと、ツールを実行する直前に条件をチェックして、危険な操作をブロックできる。公式ドキュメントには、rm -rf を含むコマンドを検知したら permissionDecision に "deny" を返してブロックする例が載っている。止め方はもう一つあり、フックがexit code 2で終了した場合もPreToolUseはそのツール呼び出しを止める。これは「AIに指示で気をつけさせる」のではなく、指示が効かなかった場合でも実行そのものが止まるという点が異なる。

FAQ

Q. Vibe CodingはAI駆動開発より劣った手法ですか。 いいえ、用途が違います。個人の検証やプロトタイプでは、いちいち権限を絞る手間がかえって足を引っ張ります。向き不向きの問題です。

Q. AI駆動開発なら誤りが起きませんか。 起きます。権限・レビュー・監査は誤りを無くす仕組みではなく、誤りが起きたときに気づき、取り返せるようにする仕組みです。

Q. 個人開発からチーム開発に移るとき、何を最初にやるべきですか。 AIが触れる範囲を明示的に絞ることです。「気をつけて使う」から「触れない範囲を作る」への切り替えが最初の一歩になります。

まとめ

AI駆動開発とVibe Codingの境目は、AIの賢さでもプロンプトの書き方でもない。AIが書いたものを、権限とレビューと記録の仕組みでどこまで囲うかという運用の設計にある。個人の実験ではその仕組みは重荷でしかないが、チームで運用し続けるコードでは前提になる。

権限・レビュー・監査を含めた「業務としてのAI駆動開発」をどう設計するかは、研修や伴走という形でもご相談いただけます。