バイブコーディングでエンジニアが再び直面するあらゆる問題
一撃で動く状態にすることはできる。だが、それが生み出す問題は山ほどある。
実際にバイブコーディングしている現場で起きていること
私はフリーランスでエンジニアをやっています。案件によっては生成AIを使えない現場も、逆にいわゆるバイブコーディングしまくっている現場もあります。
2026年2月の今日この時点での私の感想は、「バイブコーディングは圧倒的な速度を得られるが、バイブコーディングしていいのはそれを自力で実装できる設計・コーディング能力がある人だけ。3本目の腕として使う分にはものすごい価値があるが、腕のない人がお願いする、という使い方になった瞬間にあらゆる問題が起きる」です。
バイブコーディングという言葉自体は、Andrej Karpathyが2025年2月にXで言い出したものです。自然言語でAIに指示を出して、生成されたコードを深く理解しないまま受け入れるスタイル。Karpathy本人は趣味プロジェクトの文脈で使っていたんですけど、言葉だけが独り歩きして、今では米国開発者の92%がAIツールを日常利用、全コードの41%がAI生成という状態になっています。
バイブコーディングしてもらうことのメリット
圧倒的な速度でコードが書ける。知らなかったメソッドやライブラリも、READMEを見た程度の理解で割と正確な利用方法でコードを書いてくれます。74%の開発者が生産性向上を実感しているという統計がありますが、体感としてはそんなものじゃない場面もあります。30分で1日分の仕事が終わることもある。
docstringや決まったフォーマットのコードも、ある程度の精度で書いてくれる。ボイラープレート的なコード、テストコード、設定ファイルなど、自分で書けるけど時間がかかるものを任せられるのは助かります。
ある程度の精度で、コードの構造も考えてくれる。ディレクトリ構成やクラス設計の叩き台をさっと出してくれるので、壁打ち相手としては悪くない。ただし「ある程度」なんですよね、これが。
速度が尋常じゃない。これは上の「圧倒的な速度」とは別の話で、もっと大きなスケールの体感です。ある機能をライブラリ化しようと思って、3ヶ月くらいかかるかなと思ってマイルストーンを切っていったんですけど、いざ始めたらその週の週末3日間で当初の3ヶ月分のマイルストーンが全部終わりました。自分の見積もり能力を疑いましたね。「時間がかかるから後回し」と思っていたことに気軽に着手できるようになったのは、地味にでかい変化です。
使い捨てツールはまじで便利。1機能だけの簡易ツールって、別に最初から作り直したって大したことないんですよね。そういうものを一切コード読まずに機能要件だけ伝えてサクッと用意する、ということはめちゃめちゃあります。ファイル変換とか、ログ解析とか、ちょっとしたデータ整形とか。これはまじで便利です。
ただし、問題はバイブコーディングそのものじゃないんですよね。使い捨てツールみたいな用途なら何も困らない。問題は、長期運用するビジネス直結のシステムにバイブコーディングを持ち込むことです。保守し続ける必要があるコードに対して「コードを深く理解しないまま受け入れる」をやると、そこから先のデメリットが全部降りかかってきます。
「オーバーエンジニアリング」の基準が変わった
メリットで「速度が尋常じゃない」と書きましたけど、これが一番効いてくるのが機能のライブラリ化です。システムの一部を独立したライブラリとして切り出す。関心の分離、保守性、安定性、テスタビリティ。いいことずくしなのはAI登場以前からわかっていました。
でも唯一のネックが保守コストだった。切り出すのも維持するのも時間がかかるから、「それはオーバーエンジニアリングだよ」と却下されるシーンが山ほどありました。理想はわかるけど現実的じゃない、と。
AIの登場で、その障壁がなくなりました。さっき書いた通り、3ヶ月の見積もりが3日で終わる世界です。かつてオーバーエンジニアリングとされていたことが、気軽にできるようになった。そして責務の範囲を最小化したライブラリ単位の開発こそ、バイブコーディングの出番です。スコープが小さくて明確なら、AIの出力は格段に正確になる。使い捨てツールが便利なのと同じ理屈です。
そう考えると、マイクロサービスアーキテクチャとかライブラリ化による責務の分離って、これからさらに価値が上がっていくんじゃないかと思っています。保守コストが最大の障壁だったのに、その障壁がなくなったわけですから。「理想だけどコストに見合わない」と却下されてきた設計パターンが、現実的な選択肢になる。個人的にはここが、AIがソフトウェア開発にもたらす一番大きな構造変化なんじゃないかと思っています。
ところが面白いことに、AIも「それはオーバーエンジニアリングだと思いますよ」とよく言ってきます。過去の人類の記録をもとに知見を述べてくるので、当然そうなります。昔の常識で判断してくる。でも、その昔の常識を成り立たせていた前提条件がもう変わっているわけです。いや、やれよ、と。
そしてここが大事なんですけど、AIは「この機能はライブラリとして切り出したほうがいい」とは言ってきません。あくまでリポジトリの中であれこれ提案してくれるだけです。モノリスのままいくのか、切り出すのか。そういう大きな構造判断に思い至るのは、ある程度の失敗経験やビジネスの将来像を意思決定してきた人間の能力です。ChatGPTが登場した時点からずっと思っていますけど、まだここは人間の腕の見せ所です。
結局、AIがなんの情報をもとに、どういう意味で「オーバーエンジニアリング」と判断しているのか。それはなぜか、本当にそうか。ここを判断できるかどうかが分かれ目です。AIの提案を鵜呑みにしない、というのはコードの話だけじゃなくて、こういう設計方針の判断にも効いてきます。
バイブコーディングしてもらうことのデメリット
AIはそのシステムの行末がわかるわけではない。1ヶ月後に実装する予定の機能に備えた構造や、拡張性、保守性を考慮したコードは書いてくれません。プロンプトで指示すればある程度はやってくれますが、限界があります。今この瞬間の要件を満たすことに全力で、長期的な設計判断は苦手です。
コーディングに重要なWhyが疎かになる。なぜこのコードが必要なのか、なぜこの構造にするのか、なぜこのライブラリを使うのか。理由がコードからわからないことが多いです。自分で書いていれば「ここはこういう理由でこうした」という記憶が残りますけど、AIに書かせると、その設計判断の文脈がごっそり抜け落ちる。
意味不明に巨大なコードを書いてくることがある。ユースケース上必要のないフォールバックコードや、過剰なエラーハンドリングコードなどを大量に書いてきます。「念のため」の冗長な実装が積み重なると、コードの見通しが悪くなるだけでなく、どこが本質的な処理でどこが防御コードなのか判別できなくなる。
車輪の再発明が多い。構造的に共通化できるコードを、毎回新しく書いてきます。コードの再利用性が低くなる。既存のコードをリファクタリングしながら要求された機能を実装することは苦手で、今あるコードはそのまま使って増設しかしようとしないという傾向があります。CodeRabbitが470件のPRを分析した結果、AI共著コードは重大な問題が1.7倍、セキュリティ脆弱性が2.74倍多いという統計が出ていますが、このデメリットの積み重ねがまさにそれです。
実際のところ、AIが書いたコードの問題に気づけますか
上で挙げたデメリットが具体的にどう表れるか、見てみてください。以下はAIが生成しがちなコードです。それぞれに問題があります。
async def verify_token(token: str) -> dict:
payload = jwt.decode(
token,
SECRET_KEY,
algorithms=["HS256"]
)
if payload["exp"] < time.time():
raise TokenExpiredError()
return payloadapp.get("/api/users", async (req, res) => {
const { name, email, role } = req.query;
let query = "SELECT * FROM users WHERE 1=1";
if (name) query += ` AND name LIKE '%${name}%'`;
if (email) query += ` AND email = '${email}'`;
if (role) query += ` AND role = '${role}'`;
const users = await db.query(query);
res.json(users);
});async def fetch_with_retry(url: str, max_retries: int = 3):
for attempt in range(max_retries):
try:
response = await httpx.get(url)
response.raise_for_status()
return response.json()
except Exception:
if attempt == max_retries - 1:
raise
await asyncio.sleep(2 ** attempt)何ができる人ならバイブコーディングが有効か
元も子もないと思われるかもしれないけど、はっきり言います。
ある要件が決まって、それに対するモデルもアーキテクチャもディレクトリ構造もロジックも決められて、それを実装する能力がある人。その人が、それを全て指示した上で実装速度を上げるためにAIに生成させる。場合によっては実装させる前にその設計についての壁打ちはする。でも、AIの提案を鵜呑みにしないことが大事です。
AIを先生とかコーチとか、自分より優れたエンジニアのように扱ってる人が作ったものは、例外なくみんな破綻してます。そして本人が破綻してることにすら気が付いてないから救いようがない。もっと言えば、なぜかそういう人ほどAIが書いただけのゴミに絶対の自信を持ってるんですよね。
63%の開発者が「AIが書いたコードのデバッグで、自分で書くより時間がかかった」と答えているという統計がありますけど、これ、ほぼ間違いなく「自分で実装できない領域のコードをAIに書かせた人」の数字だと思っています。自分で書ける範囲のコードなら、AIの出力を見て「これは筋がいい」「ここは変だ」と判断できる。判断できないコードを受け入れるから、デバッグで地獄を見るわけです。
AIを部下って言い方もアレですけど、3本目の腕程度で使えるなら、全体の把握もAIの謎実装もデグレも考慮漏れも気が付いて却下できるから、積極的に使うといいです。Cursorでも、Claude Codeでも、Devinでも、ツールは何でもいい。問題はツールじゃなくて、使う人間の側にあるので。
ツールの話を少しだけ
どのツールがいいか、という質問をよく受けます。正直そこは本題じゃないですけど、選択肢を知っておくのは悪くないので簡単にまとめておきます。
VS Code forkベースのIDE。ユーザー100万人超、有料36万人。コードベース全体を理解した補完が強いです。ただしモデルはOpenAIやAnthropicに依存しており、結局はモデルの能力次第。$20/月。
他にもGitHub Copilot、Windsurf、Cline/Roo Codeなどがありますが、繰り返し言います、問題はツールの選択じゃないです。
結局のところ
バイブコーディングは道具です。包丁と同じで、料理ができる人が使えば効率が上がるし、料理ができない人が振り回せば怪我をする。それだけの話なんですけど、なぜかこの業界では「包丁があれば誰でもシェフになれる」みたいな空気が流れていて、正直どうかと思っています。
自分で設計できて、自分で実装できて、自分でレビューできる。その上で速度を上げるために3本目の腕としてAIを使う。これが唯一まともな使い方です。それ以外の使い方をしている人が作ったものは、今は動いていても、半年後に要件が変わったとき誰も直せなくなります。
The New Stackは2026年にバイブコーディングが「catastrophic explosions」を引き起こすと警告していますけど、大げさだとは思いません。今日AIが書いたコードを、半年後に修正できる人間がチームにいるかどうか。その問いに自信を持ってYesと言えないなら、バイブコーディングとの付き合い方を見直したほうがいいです。