- はじめに｜“vibe coding”が刺さるのは、時代の空気が変わったからだ
- vibe codingとは何か｜「コードを読まない」という一点が本質
- なぜ増えたのか｜「速度」と「心理的ハードル」が一気に崩れた
- vibe codingが強い場面／死ぬ場面｜最初に線を引け
- メリットとデメリット｜問題は「コードが汚い」だけじゃない
- 「vibe codingは悪だ」と言う声の正体｜品質への怒りは、責任への恐怖でもある
- AI時代の“責任”とは何か｜「書く」ではなく「背負う」能力
- “ノリ”を武器に変える5つのルール｜ここだけ守れば事故は減る
- 実務で使うならこうする｜vibe coding運用テンプレ
- まとめ｜vibe codingは自由だ。だからこそ責任が要る
はじめに｜“vibe coding”が刺さるのは、時代の空気が変わったからだ
最近「バイブコーディング（vibe coding）」という言葉がやたら流れてくる。
響きは軽い。ふざけているようにも見える。だが、この軽さの奥にあるのは、開発の主役が「手」から「判断」に移りつつある現実だ。
AIがコードを吐く。人間がそれを試し、直し、方向を決める。
この流れはもはや一過性のブームではない。
だからこそ、議論は二極化する。
- 「バイブで書くとか終わってる。技術負債の量産だ」
- 「いや、スピードこそ正義。試して当てる時代だ」
結論を先に言う。
バイブコーディング自体は悪ではない。悪になるのは“責任の置き場”が消える瞬間だ。
この記事では、vibe codingの定義・背景を整理した上で、AI時代に「ノリ」を武器に変える条件を言語化する。
vibe codingとは何か｜「コードを読まない」という一点が本質
vibe codingは雑に言うと「ノリで書く」だが、もう少し正確に言うとこうだ。
- 仕様や設計を厳密に固めない
- まず動くものをAIと一気に作る
- そして場合によっては、コードを深く読まずに前に進む
この言葉はAndrej Karpathyが「vibe coding」と呼んで広がったとされる。彼の表現は象徴的で、“コードが存在することすら忘れて、雰囲気に身を委ねる”というニュアンスがある。
重要なのは、ここで言うvibe codingが「AI活用全般」ではない点だ。
LLMを使っても、レビューして理解してテストしているなら、それは単なるAI支援開発であって、狭義のvibe codingとは違う、という整理もある。
つまり、**“ノリで書く”というより、“理解を後回しにする”**ことが核心だ。
なぜ増えたのか｜「速度」と「心理的ハードル」が一気に崩れた
vibe codingが増えた理由は単純だ。
速いから、そして始めるのが楽だから。
- 0→1のプロトタイプが爆速になる
- 「何が正解か分からない」段階で、動くものを先に出せる
- ChatGPT / Cursor / Claude Code などの普及で、実装の初速が上がった
昔は「手を動かす前に、頭で整理する」が必要だった。
今は違う。「動かしながら整理する」が成立してしまう。
この変化を“堕落”と呼ぶ人もいるが、実態は堕落ではない。
開発の勝ち筋が、設計力だけで決まらなくなっただけだ。学者や趣味で開発する人にとって、vibe codingは一種の入り口になっている。
vibe codingが強い場面／死ぬ場面｜最初に線を引け
ここを曖昧にすると議論が荒れる。
vibe codingは万能ではない。向き不向きが極端だ。
vibe codingが強い場面（やっていい）
- 使い捨て前提の検証（週末プロジェクト、社内の小ツール、PoC）
- 要件が未確定で、とにかく形が必要なとき
- 「見せたら前に進む」状況（上司・顧客の合意形成のための試作品）
vibe codingが死ぬ場面（やると爆発する）
- 本番運用（売上・顧客・データが絡む）
- 長期保守が前提（引き継ぎが発生する／人が増える）
- セキュリティ・法務・品質の制約が強い領域
要するに、vibe codingは“速度で不確実性を殴る技”だ。
不確実性が減ってきたら、殴り方を変えないといけない。錯覚。何となくコピペで動かせてしまうが、エラーが出たときに原因が分からず手が止まる。結果、学習機会を失ってしまう。AIが“補助輪”になるどころか、むしろ“思考停止の誘導装置”になる可能性もある。
メリットとデメリット｜問題は「コードが汚い」だけじゃない
メリット
- 思考が止まらず、試行回数を増やせる
- 初学者でも「作る体験」に到達できる
- プロトタイプで意思決定が早くなる
ここは事実として強い。
「作れない」を「作れた」に変える力がある。
デメリット（本質は3つ）
① メンテ不能性（未来の自分を殺す）
ノリで積んだコードは、3か月後の自分が読めない。
そして未来の自分はだいたい忙しい。
② セキュリティ事故（取り返しがつかない）
AIが吐いたコードはそれっぽく動くが、秘密情報の扱いが雑なことがある。
「APIキーがログに出る」「権限がガバい」「入力が無防備」みたいな事故は、バグではなく事件になる。
この点をWillisonが強く警告している。
③ 学習停止（“動く”が麻薬になる）
一番危ないのはこれだ。
「動いたからOK」で終わると、エラーが出た瞬間に詰む。
そして詰む経験が増えるほど、AI依存が強まって、さらに理解が遠のく。
「vibe codingは悪だ」と言う声の正体｜品質への怒りは、責任への恐怖でもある
経験者がvibe codingを嫌うのは当然だ。
彼らは過去に何度も見ている。
- 動いていたはずの謎コードが、仕様変更で崩壊する
- 誰も触れず、結局作り直しになる
- 「スピードで得した分」を、後で10倍払う
だから、反射的に「悪」と言いたくなる。
ただし、それだけではない。
AIによって「それっぽい実装」が誰でも出せるようになった瞬間、
エンジニアの価値は「書ける」から「判断できる」に移る。
- 何を作るべきか
- どこが危険か
- どこから先は責任が重いか
この移動に追いつけない不安が、強い否定として出る。
つまり、vibe coding論争は、品質論であり、同時に職能の再定義でもある。
AI時代の“責任”とは何か｜「書く」ではなく「背負う」能力
AIは考えてくれない。
もっと正確に言うと、考えたように見える文章を出すだけだ。
だからAI時代に一番重要になるのは、コード力そのものより、
- 「これは本番に入れていいか？」
- 「この設計は拡張できるか？」
- 「何が起きたら事故になるか？」
を判断できる目だ。
言い換える。
vibe codingの責任とは、“動かした本人が後始末できる状態を残すこと”だ。
“ノリ”を武器に変える5つのルール｜ここだけ守れば事故は減る
vibe codingを肯定するなら、最低限これだけは持て。
1）「捨てる前提」を明文化する
PoCなのか、本番候補なのか。
最初に宣言しないと、PoCがそのまま本番に吸い込まれる。
2）境界線を作る（データと権限）
- 本番データを触らせない
- 権限は最小
- 秘密情報はコードに埋めない
ここを雑にすると、vibe codingは“遊び”から“事故”に変わる。
3）仕様を“短く”書く（長い設計書はいらない）
要件を1ページに落とせ。
「何を満たせば勝ちか」だけ書けばいい。
4）テストは“薄くてもいいから”必ず入れる
網羅は無理でもいい。
致命傷だけ守るテストを先に作る。これで未来が変わる。
5）最後に必ずリファクタ時間を取る
vibeで作った初版は汚くて当然だ。
問題は「汚いまま固定される」ことだ。
実務で使うならこうする｜vibe coding運用テンプレ
現実的な落としどころはこれだ。
- Phase1：vibeで作る（速度を取りにいく）
- Phase2：責任を持てる形に整える（判断を取りにいく）
この二段階を分けるだけで、vibe codingは“悪”から“武器”に変わる。
そしてPhase2でやることはシンプルだ。
- 仕様を短く書く
- 依存関係を整理する
- ログとエラーハンドリングを付ける
- テストを最低限入れる
- 他人が読める形にする（命名、分割、コメント）
ここまでやって初めて、AI時代の「責任」を果たしたと言える。
まとめ｜vibe codingは自由だ。だからこそ責任が要る
vibe codingは、クリエイティブな爆発だ。
考えすぎて止まるより、まず動かす。これは強い。
ただし、自由はタダではない。
AIがコードを書いたとしても、責任の署名欄に名前を書くのは人間だ。
- ノリで作るのはいい
- だが、ノリで放置するな
- 置き土産を“読める形”に変えろ
これができるなら、vibe codingは悪ではない。
むしろ、AI時代の開発スピードを取りにいく最短ルートになる。
