Portfolio logo
☠️

バイブコーディング中毒が奪う『責任』:生成AI時代の開発で失うもの

調査・設計・計画テスト・実装の4工程で見た生成AIの強みと限界、そしてバイブコーディングが『責任』を奪っていく構造を整理する。

#vibe-coding #generative-ai #software-engineering #responsibility #testing

バイブコーディングは「速く進む」ための手段だと思っていた。けれど数ヶ月使い続けた結果、いちばん失ったのは責任感だった。

バイブコーディング中毒。こんな言葉は存在しない。だが、数ヶ月バイブコーディングを実践してきた中で陥った状態は、まさにこの状態である。

生成AIは確かに強い。調査も設計も、ある局面では人間を超える。しかしその強さは、「自分が書いた」感覚を奪い、いつのまにか「誰が責任を負うのか」を曖昧にする。

以下は、調査・設計・計画テスト・実装の4工程で、生成AIがどこで強く、どこで危険になるかの整理だ。

調査: ほぼすべてのタスクでAIのほうが精度が高い

調査は間違いなく圧倒的に強い。関連リンクの探索、類似実装の抽出、要約、比較表。人間よりも速く、確度の高い調査を出してくる。

ただし、調査結果の「採用・非採用」を決めるのは人間だ。ここをAIに丸投げした瞬間、責任の境界が曖昧になる。

設計: 小さくは鋭いが、大きくなるほどブレる

機能が小さいほど、AIの設計提案は鋭い。小さなAPIや小さなUIは、サクッと良い方向にまとめてくる。

一方で、機能が大きくなるほど設計のブレ幅が増える。分割の粒度、責務分離の基準、冪等性や運用の視点が曖昧になりやすい。設計を「それっぽく」作るが、責任ある意思決定にはならない。

計画テスト: もっともらしいが、危ない

テスト計画は特に要注意だ。

  • それっぽい計画を出す
  • その計画はほとんどの場合”通る”
  • でも本質的な不具合を炙り出す設計になっていない

AIは「通るテスト」を作るのが得意だ。ときにはパワープレーで通すための計画になる。だから、人間が「なぜこのテストなのか?」を問わない限り、品質のふりをした安心感だけが残る。

実装: 認知の限界を超えた瞬間、崩壊する

実装は、一度の修正で人間が認知したいと思う範囲を超えると途端に破綻する。

高度で複雑な実装が出力されるほど、人間は読みたくなくなる。そして「読みたくない」という感情が、バイブコーディング中毒を加速させる。

小さな範囲ですら「具体を認知したくない」状態になる。こうして、完璧なバイブコーディングが完成する

そこに責任はあるか?

学びとして、あえてこう問いたい。

設計も完璧(だと思っている)、テストケースも完璧、実装もたぶんできていて、テストもオールグリーン。完璧だ。

ではその機能にバグが見つかりました。他の人が調査します。

  • なぜこうなっているんだ?
  • あなたに聞きます。「AIは当時このようにやったんですが、細かい箇所はこうなっていたんですね…」

実装したのはAIかもしれない。でも、他の人から見れば実装したのはあなただ。責任はあなたが取る必要がある。

ここがバイブコーディングの最大の落とし穴だ。成果物の責任は生成AIではなく、人間に帰属する

中毒の構造: 責任を持ちたいのに、持てない

指摘されて「今度はちゃんと書く」と思っても、できない。

  • AIが書いてくれるから
  • そのほうが楽だから
  • そして、いつのまにか認知できないコードが積み上がるから

これは中毒だ。理解はしている。どうやってやればいいかもわかっている。

それでも、書くことをAIに全部任せてしまう。これではダメだ。書いたものを認知できない。責任を負っていない。

中毒に陥らない人ももちろんいるだろう。バイブコーディングに慎重な人は、アウトプットに満足できるハードルが高い。けれど、ハードルが低い人はどうだろうか。私のように新しいものに飛びついて、とりあえず試したくなる人はどうだろうか。なんでもやってくれるその万能感に酔って、思考が鈍っていく。理解が浅くなっていく。中毒に陥っていく。

レビュー/ペアプロが効く理由

ここで救いになるのが、レビューの文化かもしれない。私の所属している会社ではXPが主流で、トランクベースの開発をペアプロで回してきた。しかしAIが台頭してからはソロでの作業が増え、チケットの認識合わせだけして個々人が進める形になった。チームの総意ではあったが、進捗への影響は正直よくわからない。修正コストや、最終的にみんなが認識しているレベルを加味すると、ペアプロでやっていた時期のほうが完成度は高かったように感じる。納期やチーム構成にもよるが、当時はそれでよかった。今はむしろペアプロを積極的に進める方がいいように感じている。チームとしての動きを柔軟に変えていく必要がある。

ペアプロをして強く感じるのは、AIに任せっきりにならないという点だ。AIが出してきたものをちゃんと確認しようという雰囲気が自ずと形成される。さらに、作業が途中でペアを変更するとき、作業内容を完璧に把握していないと次の相手に説明できない。これはコードに対する責任を持てていない状態をあぶり出す。ひとり作業では発生しない、良い制約だ。

「責任感を持って自分で考えてやればいいだろう」という意見もあるだろう。でも全員が同じレベルでできるわけではない。だからレビューやペアプロが存在する。機械的に防ぐための仕組みとしての価値がある。

そして、ペアプロ時にAIを使うには、お互いのAIに対する理解が必要だ。「とりあえずAIに任せますか!」なのか、「この部分の調査だけお願いしますか!」なのかで、出力も責任も大きく変わる。どこまでをどう使うかは、始める時点でチーム内の認識を合わせないと、モヤモヤが溜まり続ける。

使い捨て/検証プロジェクトの適性

とはいえ、全否定ではない

バイブコーディング自体を否定したいわけではない。 **問題の本質は、バイブコーディングではなく“責任の欠如”**だと思う。

いくつかの記事では「品質が悪すぎて結局人間のメンテが必要」「設計力が弱まる」といった話が出てくるが、私は全くそうは思わない。品質が悪いのは、おそらく古いモデルを使っているからだろう。設計力がある人間が使ってバイブコーディングをしたからといって、設計力が落ちることはない。これは問題の本質ではない。

そもそも、メンテナンスを前提としないプロジェクトも存在する。使い捨てだったり、本当にただの価値検証だったり。そこにバイブコーディングはガッチリとはまる。個人開発では特に有効だと思っている。全くプログラムが書けない人が、アイデアを形にできるということはとても素晴らしいことだ。

会社での責任

ただし会社のプロジェクトでは、責任が問われる。それこそがすべてだ。自分が書いたコードには説明責任がある。AIが書いたコードだから信用ならない、という話ではない。どうでもいい。そのコードに対して責任を持てるなら、それでいい。

私の現在地

ここ数ヶ月バイブコーディングを積極的に使ってきた。得られたのは責任感の喪失のみ。

進捗は大きく変わらない。自分が書いても、あまり変わらない。

ただし、現行コードの調査と、ある程度の設計は圧倒的に速くなった。だから私は、今後こうする。

  • 調査: AI
  • 設計: AI(ただし決定は自分)
  • テストケース: AI(ただし抜け漏れは自分で確認)
  • 実装: 自分

責任を持つべき場所は、結局「自分が読み、理解し、説明できる範囲」だと実感した。

TODO駆動でAIに実装させるのは、条件付きで“良い”

Todoをコード内に張り巡らせて、そこをAIに実装させるのはとても良い使い方だと思う。

ただし条件がある。

  • 完成形を頭の中で先に描き切っていること
  • ズレた分だけ認知できなくなることを理解していること
  • タスクを狭く小さく分割できていること

一つ一つを狭く小さく分割して、頭に完璧に描いた状態なら、AIに中身の具体を書かせてもある程度は問題ない。

再現用の作業構造(例)

export type QuoteRequest = {
  age: number
  monthlyPremium: number
  planId: string
}

export type QuoteResult = {
  planId: string
  premium: number
  message: string
}

export function calculateQuote(input: QuoteRequest): QuoteResult {
  // TODO: 入力の境界値チェックを実装する
  return {
    planId: input.planId,
    premium: input.monthlyPremium,
    message: "draft",
  }
}

export async function fetchCampaignMessage(planId: string): Promise<string> {
  // TODO: ここはAPIクライアントの実装に置き換える
  return `campaign:${planId}`
}

この状態でAIに実装を埋めさせるなら、設計が完璧に頭に入っているので、実装のブレが小さくなり、認知する範囲が限定される。

まとめ

この中毒から抜け出すには、かなりの忍耐力がいる。でも、プロフェッショナルとして自分の書いたコードに責任を持つためには必要なことだ。 生成AIは強い。けれど、強いからこそ使い方の責任が問われる。

  • 生成AIは調査で圧倒的に強い
  • 設計は小さければ強いが、大きくなるほどブレる
  • 計画テストは“通る”が、質が保証されるわけではない
  • 実装は認知の限界を超えると崩壊する
  • バイブコーディングの本質的な問題は「責任の欠如」

理解している。どうやってやればいいかもわかっている。それでも任せ続ければ、責任は消える。

責任を持てる範囲でのみ、AIを使う。その線引きが、いまの自分には必要だ。