コードをほとんど読まずにAIエージェントへ実装を任せる「バイブコーディング」という開発スタイルが話題になっています。
個人のゲーム制作やプロトタイプでは有効という報告がある一方、業務システムを開発するチームにそのまま持ち込んでよいかは別の話です。スクラムやカンバンでチーム開発を回しているエンジニアリングマネージャー、あるいは技術的負債の管理に悩むテックリードに向けて、導入可否を判断する軸を整理しました。
題材として取り上げるのは、開発者がAnthropic社のコーディングエージェント「Claude Code」を使って個人開発したブラウザ向けRTS（リアルタイムストラテジー）ゲーム「Battle Drones」の開発事例です。12回の大きな改修と321回のコミットを経て、建物9種・地上車両7種・空中車両6種・歩兵3種を備えたゲームが完成しています。開発者自身が「コードをほとんどレビューしていない」「TypeScriptはほとんど使ったことがない言語」と明言している点が特徴です。
どんな場面でこの判断が必要になるか
バイブコーディングの採用可否が問われるのは、主に次のような場面です。
- 新機能のプロトタイプを素早く形にしたいとき
- 社内ツールや検証用スクリプトなど、保守期間が短いコードを書くとき
- スプリントの見積もりに「AIエージェントにどこまで任せるか」を織り込みたいとき
- 技術的負債の許容ラインをチームで合意し直したいとき
共通するのは「スピードと引き換えに何を手放すか」という問いです。ここを曖昧にしたまま導入すると、後工程でレビュー負荷や障害対応のコストとして跳ね返ってきます。
判断軸1: コードの寿命
Battle Dronesの開発者は「コードをほとんどレビューしていない」状態で12回の改修を重ねています。個人のゲームプロジェクトであれば、動けば勝ちというシンプルな評価基準が成立します。
一方、業務システムは数ヶ月〜数年にわたって保守されます。レビューを省いたコードは、半年後に別のエンジニアが触る際の「読めないコード」になりがちです。寿命が短い検証コードほどバイブコーディングの相性がよく、寿命が長いコードほど慎重な判断が必要になります。
判断軸2: 失敗時の影響範囲
ゲームのバグはプレイ体験を損ねますが、個人開発であれば致命傷にはなりません。業務システムでは話が違います。
決済処理や個人情報を扱う機能で、レビューなしのAI生成コードをそのまま本番投入するのはリスクが高すぎます。逆に、社内向けの管理画面や、障害が起きても即座にロールバックできる機能であれば、影響範囲は限定的です。失敗したときに誰がどれだけ困るかを先に洗い出しておくと、採用範囲の線引きがしやすくなります。
判断軸3: チームの技術的な理解度とのギャップ
開発者は「TypeScriptをほとんど使ったことがない」状態でこのプロジェクトを進めています。個人開発なら、理解が追いつかなくても自分が困るだけで済みます。
チーム開発では事情が異なります。ある開発者がAIエージェントに任せて書いたコードを、別のメンバーがレビューし保守する場面が必ず出てきます。チーム全員がそのコードベースの設計思想を理解できていない状態は、技術的負債の温床になります。採用するなら「誰が読んでも理解できるコードにする」というレビュー基準を先に決めておくことが欠かせません。
判断軸4: 反復のスピードが価値に直結するか
Battle Dronesの開発では、開発者が「もっと楽しくして」とだけ指示したことが転機になったと振り返られています。曖昧な指示でも、素早く形にして触って確認し、またフィードバックするというサイクルが機能したからこその結果です。
業務開発でも、要件が固まりきっていない新規機能のプロトタイピングでは、このサイクルの速さがそのまま価値になります。逆に、要件が明確で変更が少ない定型的な機能開発では、スピードよりも正確さと一貫性が優先されるため、恩恵は小さくなります。
選択肢の比較
| 観点 | フル採用（レビュー省略） | 部分採用（要所でレビュー） | 見送り（従来通り） |
|---|---|---|---|
| 向くコードの寿命 | 数日〜数週間の検証用 | 数ヶ月単位の機能開発 | 基幹システム・長期保守対象 |
| 失敗時の影響 | 限定的・即復旧可能 | 中程度・テストで担保 | 大きい・業務停止リスクあり |
| チームの前提知識 | 個人または少人数 | レビュアーが言語に精通 | 特に制約なし |
| 見積もりへの影響 | 大幅短縮を期待できる | レビュー工数を上乗せ | 従来の見積もり基準を維持 |
ケース別の推奨
新規サービスの企画段階でユーザー体験を検証したいなら、フル採用に近い形で試すのが向いています。Battle Drones のように「まず動くものを作って触ってみる」ことで、仕様書だけでは見えなかった課題が早期に見つかります。
スプリント内で既存システムに機能を追加するケースでは、部分採用が現実的です。AIエージェントに実装の叩き台を書かせたうえで、重要なロジックだけ人間がレビューする運用がバランスを取りやすくなります。見積もりに「レビュー工数」を明示的に加えておくと、後工程での手戻りを防げます。
決済・認証・個人情報を扱う機能や、障害復旧に時間がかかるインフラ周りの変更は、見送るか最小限の採用にとどめるべきです。開発者自身がコードをほとんど理解していない状態での本番投入は、スクラムでいう「完成の定義（Definition of Done）」を満たしているとは言えません。
あえて見送るべき条件
次のいずれかに当てはまる場合は、導入を見送るか慎重に範囲を絞ることをおすすめします。
- チーム内に生成されたコードをレビューできる人材がいない
- 障害発生時のロールバック手順が整っていない
- 規制対応やセキュリティ監査の対象となる機能である
- 見積もりの精度よりも説明責任（なぜその実装にしたか）が重視される現場である
まとめ
Battle Drones の開発事例は、個人のプロトタイピングにおいてバイブコーディングが強力な武器になることを示しています。321回のコミットを経て、コードをほとんど読まずに本格的なゲームが完成したという事実は印象的です。
ただしチーム開発に持ち込む際は、個人開発とは前提がまったく異なります。まず自分のプロジェクトについて「このコードは半年後も使われているか」「失敗したら誰がどれだけ困るか」の2点を書き出してみてください。
その答えによって、フル採用・部分採用・見送りのどれを選ぶべきかが自然と見えてきます。次のスプリント計画で、該当する機能を一つ選んで試験的に部分採用から始めてみるのが現実的な一歩になります。