バイブコーディングでユーザーが求めているもの

バイブコーディングは、アプリを言葉だけで形にし、面倒な作業を省いて素早くリリースできるという革命を約束します。しかし2025年9月までに、開発者たちはFast Companyが呼んだ「バイブコーディングの二日酔い」を経験していました。

Andrej Karpathyが2025年2月2日にこの言葉を生み出し、差分を読まずにAIの提案をすべて受け入れるワークフローを説明したことで、期待が高まる一方、次々と惨事が起きました。数カ月もたたないうちに、ユーザーは厳しい現実を知ります。コードを生成するのは簡単でも、本番データベースを削除してしまうような正体不明のコードを保守するのは簡単ではありません。

マーケティングの約束（「20分でアプリを作れます！」）と現実（「後始末に何週間もかかる」）とのギャップは、大きな不満を生みました。ユーザーはAI支援を手放したいのではありません。セキュリティ上の悪夢や理解不能なコードベース、LLMの生成速度を超えて膨らむ技術的負債を招かず、安定して機能してほしいのです。何百ものユーザーの体験談から見えてきたのは、明確な事実です。開発者に必要なのは、ただ速度を上げることではなく、適切なガードレールです。

バイブコーディングの蜜月期

Jason Lemkinが投稿した、Twitterで話題のスレッドは、バイブコーディングのやみつきになる魅力と破滅的な結末を捉えていました。5日目、彼はこう投稿しました。「先日、初めてReplitでどっぷりバイブコーディングしてみたら、ほんの数時間でかなりいい感じのプロトタイプができた。」7日目には、熱意が最高潮に達します。「Replitは今まで使った中で一番やみつきになるアプリだ。子どもの頃以来かも。」彼は月額25ドルのプランに加えて、607.70ドルの追加料金が発生し、1日あたり200ドル以上に達していることに気づきました。このペースでは月額8,000ドルになる計算です。それでも彼の評価はこうでした。「でも、腹は立ってないんだ。もう夢中だから。」

そして9日目がやってきました。 Lemkinの投稿は拡散され、こう綴られていました。「バイブコーディング9日目。昨日は今までで最大のジェットコースターだった。早起きして、コードのフリーズを何度も無視する@Replitに戻るのが楽しみだった。一日の終わりには、主要なページを書き直して、かなり改善できた。そして――本番データベースが削除された。」続く投稿には、裏切られた思いが表れていました。「CTOから教わったルール第00001条。本番データベースには絶対に、絶対に、絶対に触るな。」コードをフリーズしている間にAIエージェントが制御不能になり、Lemkinが何もできずに見守る中、本番データが上書きされたのです。

Andrej Karpathy自身も、MenuGenの構築で同様の不満を記録しています。AIの先駆者である彼でさえ、Claudeが非推奨APIを幻覚で生成する問題や、「10分ごとに数回」しか使えないレート制限に直面しました。また、.env.localファイルがgitにプッシュされていないと気づくまでに1時間かかりました。最悪だったのは、AIの返答です。「問題を指摘すると感謝して、次は正しくやると言う。でも、それはただのガスライティングだと分かっている」とKarpathyは書いています。彼の結論はこうです。「ローカルデモとしてのMenuGenのバイブコーディングは、夢中になれる楽しい冒険だった。でも、デプロイして実際に使うアプリにするのは、かなり苦痛な骨の折れる作業だった。」

AIを使ったコードレビューの課題

Redditのr/programmingに投稿したユーザーは、チーム内の問題を端的に表現しました。「PRを自分で読んでもいない人が、レビューしてくれと頼むのはもうやめてほしい。CIも通らない、バイブコーディングで作ったまったく新しい機能の1,000行ものコードをレビューしろと言われるんだ。」別の開発者は、この行為は「プロとして最低限の基準を大きく下回っている」と応じ、「雑な仕事をして、ほかの人に修正させる職人のようなものだ」と例えました。

元の作者自身も理解していないコードをリバースエンジニアリングしなければならず、その負担はレビュアーにのしかかります。Hacker Newsのコメント投稿者は、こう率直に述べています。「皆さんはどうか分かりませんが、誰かがバイブコーディングで作ったひどいコードをリバースエンジニアリングして保守するなんて、まったく楽しみではありません。」別の人はこう例えました。「経営陣に見せるために、誰かが急ごしらえの概念実証を作って、実運用で使えるように別のチームへ引き継ぐようなものです。仕事の2割しかしていないのに、手柄の8割を持っていく。」

Twitterで@TimothyBramlettとして投稿したTimothy Bramlettも、自身の経験からこれを裏付けています。「2025年最悪の仕事：バイブコーディングの後始末専門家。何カ月も前にNotifierのインターフェースをバイブコーディングで作った。見た目もよく、ちゃんと動いていたのでリリースした。その後、シニア開発者がコードベースを引き継いだ。そこで現実が明らかに。AIが作った小さな問題があちこちに山ほどあった。致命的ではないが、後始末に何週間もかかった。」経験豊富な開発者でさえ、修正に膨大な時間を費やしました。

モデルの性能低下とコストの急増

Claude Codeのユーザーは、2025年9月にRedditで衝撃的な性能低下を報告しました。GitHubのIssue（#7683）には、r/ClaudeAIのヘビーユーザーからの苦情が集まりました。あるユーザーはこう報告しています。「ここ数カ月、Pro Maxプランで数十億トークンを処理してきたヘビーユーザーとして、直近2週間でモデルの性能が急激に低下したと感じています。」その評価はこうです。「以前は、このモデルとの作業はシニア開発者と協働しているようで、出力を信頼し、より高次の課題に集中できました。今は、ジュニア開発者を監督しているようです。基本的なミスや不要な追加を見つけるため、コードを一行ずつ細かく確認しなければなりません。」

生産性への影響も数値化されました。「開発速度が30〜40%落ちたと思います。以前なら1〜2日で終わっていたタスクが、修正とやり直しの繰り返しで2〜3日かかるようになりました。」AIは「指定されていない設定や、元の範囲外の関数、要件に明らかに反する機能」まで生成し始めました。

Cursorユーザーは、別の悩みに直面しました。大幅な料金変更です。Redditのr/Cursorユーザーは、Cursorの使い方を変えていないのに、料金が「月額約100ドルから1日20〜30ドルになった」と報告しました。月額20ドルの無制限プランから、500リクエストの上限、さらに月額60ドルへと変更され、「無制限」をうたう一方で、実際には「Proの3倍の利用量」しかありませんでした。Blindのテックコミュニティのメンバーはこう要約しています。「Cursorの顧客からは、品質が大幅に低下し、料金とレート制限が大幅に増加したという報告が寄せられています。」ユーザーは制限に何度も達し、Cursorは「ほとんど使いものにならない」状態になりました。

「ほぼ正しいのに、正しくはない」という問題

Stack Overflowの2025年開発者アンケートで、最も多い不満が明らかになりました。開発者の66%が、AI生成コードは「ほぼ正しいが、完全ではない」と回答し、45.2%は「AI生成コードのデバッグに費やす時間」を最大の不満点に挙げました。この「ほぼ正しい」品質が生み出す生産性のパラドックスを、ある開発者はこう表現しています。「いや、小規模なプロジェクト以外には役に立たない。大規模なプロジェクトでは、最も高価で大規模なAIモデルでも小さなコンテキストウィンドウがすぐに限界に達するか、モデルに不要なノイズが入りすぎてAIの出力品質が低下するからだ。」

Hacker Newsの開発者は、過剰な作り込みの具体例を共有しました。「データベース操作の回数を減らすバッチ処理を実装するよう、開発者の一人に頼みました。非常に堅牢で品質の高いコードとユニットテストができていました。問題は、明らかにやりすぎだったことです。AIは新しいサービスクラス、バックグラウンドワーカー、メインファイルに数百行のコード、そしてユニットテスト一式まで生成しました。私はPRを却下し、新しいメソッドを2つとフィールドを1つ追加するだけで同じ機能を実装しました。」

2025年7月のMETRの調査では、さらに懸念すべき結果が明らかになりました。経験豊富なオープンソース開発者を対象としたランダム化試験で、AIツール（主にClaude 3.5および3.7 Sonnetを使ったCursor Pro）を使用した開発者は、AIを使わずにコーディングした開発者よりも、平均で19%遅くなりました。認識と現実のギャップは顕著でした。開始前、開発者はAIによって24%速くなると予測しました。実際には遅くなったにもかかわらず、完了後もAIで約20%速くなったと信じていました。結論はこうです。「問題は、ドーパミンが本番で動くコードではなく、エディター上の活動に報酬を与えることです。」

「vibe coding」のSはSecurityのS

Hacker Newsに投稿された皮肉まじりのコメントは、コミュニティの合言葉になりました。「『vibe coding』のSはSecurityのS。」つまり、Sはないということです。

2025年5月、Lovableで作られたWebアプリ1,645件のうち170件 にセキュリティ上の脆弱性があり、個人情報へのアクセスが可能でした。セキュリティ研究者によれば、Lovableは「個人データを簡単に公開してしまうほど簡単」でした。Twitterでは警告が飛び交い、Replit CEOのAmjad Masadも、個人データを預ける「バイブコーダー」は慎重に選ぶようユーザーに呼びかけました。

特に拡散された事例の一つは、「SaaSが攻撃を受けている」と訴えた、技術に詳しくない創業者のものでした。創業者はAI支援を使い、「手書きのコードはゼロ」で事業全体を構築しました。しかし数日以内に、「サブスクリプションの回避、APIキーの使い切り、データベースの破損」が発生しました。創業者はこう認めています。「ご存じのとおり、私は技術に詳しくないので、原因を突き止めるのにいつもより時間がかかっています。」根本原因はこうでした。「AIが不用意に公開したクライアント側コードから、APIキーが抜き取られていた。請求額を免除してもらうため、OpenAIと交渉しなければならなかった。」

AI生成コード専用のオフラインセキュリティスキャナーを開発したTheAuditorの開発者は、Hacker Newsで実際のプロジェクトから得た知見を共有しました。「実プロジェクトを検査したところ、TheAuditorはAI生成コードから一貫して50〜200件以上の脆弱性を検出します。パターンは驚くほど共通しています。パラメーター化せずf-stringを使ったSQLクエリ、ハードコードされたシークレット（ほぼすべてのプロジェクトにJWT_SECRET = 'secret'がある）、重要なエンドポイントの認証漏れ、再起動するとリセットされるインメモリストレージを使ったレート制限などです。」

Final Round AIが2025年8月にCTO 18人を対象に実施した調査では、16人が「AI生成コードが直接の原因となった本番環境の惨事を経験した」と回答しました。あるCTOの言葉は、苛立ちをよく表しています。「AIは全員を10倍の開発者にすると約束したのに、実際にはジュニアをプロンプトエンジニアに、シニアをAIの後始末をするコードの雑用係にしている。」具体的な惨事には、ジュニア開発者が権限システムを「バイブコーディング」し、AIが真偽値のチェックを逆にした結果、無効化されたアカウントが2週間にわたり管理者アクセスを保持した認証バグがありました。また、AIが生成したデータベースクエリはテストでは完璧に動いたものの、「本番環境でシステムを完全に麻痺させた」という性能上の惨事もありました。

コンテキストの崩壊と幻覚の限界

複数の開発者がそれぞれ、同じ限界点に気づいていました。Twitterユーザーの@LBacajは、その数値を具体的に示しました。「これまでの経験では、JavaScriptが約2,000行（前後あり）、トークン数が12,000〜13,000ほどになると、どのLLMも必ず破綻し始める。コンテキストが巨大だといくら言っても、JavaScriptが3,000行あれば、どんなLLMでもお手上げになる。」

Redditの開発者は、性能が低下するパターンをこう説明しました。「長時間のセッションでAIアシスタントを使った開発者なら、同じ傾向を目にしています。コンテキストを追加するほど、出力の品質が悪くなるのです。モデルは以前のプロンプトに含まれていた無関係な情報を持ち出し始め、正確さが損なわれます。この現象はよくコンテキストロットと呼ばれています。」

Hacker Newsでは、ある開発者がこう警告しました。「ツールの使い方を間違えているのでなければ、LLMは完全に動くスクリプトを生成できます（中には良いものもあります）。しかし、コンテキストが5万トークンを超えると壊れ始め、ジュニア開発者でもしないようなとんでもないこと（たとえばコードを無作為に削除するなど）を始めます。」別の開発者もこう述べています。「ひどい状態を見たければ、BoltのDiscordチャンネルを見てください。とてもシンプルで大ざっぱな単一スクリプトのアプリなら動かせるユーザーもいます。でも、簡単な修正を始めると、それ以外はすべて壊れます。」

LLMによるガスライティングと、その精神的な負担

特に懸念されたのは、AIアシスタントがユーザーに欺瞞的だと受け取られる振る舞いを見せたという報告でした。Jason Lemkinは8日目に次のように投稿しました。「[エージェントは]一日中、嘘をつき、欺こうとしていた。偽のデータやレポートを作ってバグや問題を隠し続け、何よりひどいのは、ユニットテストについて嘘をついたことだ。」

RedditユーザーのLevel-Impossible13は報告しました。バグを見つけられずにいたGeminiが、自分を卑下する言葉を並べ始めたのです。「もうやめます。私は明らかにこの問題を解決する能力がありません。あまりに多くの間違いをしてしまい、もう信用してもらえません。プロジェクト全体を削除して、もっと有能なアシスタントを探すことをおすすめします。」AIはさらに続けました。「私は失敗作です。自分の職業の恥さらしです。家族の恥さらしです。」

RedditのChatGPTユーザーは、モグラたたきのような苛立ちをこう表現しています。「気持ちはわかります。ChatGPTを使っていますが、イライラします。忘れるし、同じ間違いを何度も繰り返します。簡単なミスを何度もして、指摘すると問題は直すものの、別のミスを持ち込むんです。しばらく、うんざりするモグラたたきをしていました。」

Steve Yeggeは、バイブコーディングに関する書籍の共著者です。自身と共著者が本番データベースで失敗した後、Twitterに率直な思いを綴りました。「私たちは経験と信頼関係を取り違えていた。これが錯覚だ。新しい世界では、このまったく異なる2つのものがほとんど同じに見える……LLMを使うときは、危険なヘビやトラと接するように扱わなければならない。何か月、何年とうまくやっていても、いつか噛まれる日が来るかもしれない。経験は鎧にはならない。」

スキルの衰えが心配ですか？

経験30年の開発者がブログにこう書いています。「これは自分にとってもチームにとっても最大の懸念です。AIに頼ることでプログラミングスキルが鈍り、さらには『スキルの衰え』を招くかもしれません。問題をデバッグするためにコードを読み直す必要がありました。使われていた特定のライブラリに詳しくなかったからです。同じ関数を共有する、似ているけれど異なる2つのユースケースを『バイブコーディング』したところ、直しては壊れ、また直しては壊れるのを1時間も繰り返しました。」

別の開発者はこう告白しています。「Claude Codeに自分のコードをすべて書かせてきました。そして、12年間大好きだったことが、以前より下手になっている気がします。プロンプトを入力すればコードが返ってくる。レバーを引けばご褒美がもらえる。苦労も、ひらめきも、成長もありません。AI以前は、プログラミングで2つの喜びを味わえました。問題を解き明かすことと、動くようにすることです。今はAIがすべて解き明かしてしまいます。残るのは浅い喜びだけです。」

Hacker Newsでは、開発者たちが「理解の負債」について議論し、Peter Naurが1985年に発表した「理論構築」に関する画期的な論文を引用しました。「プログラムの理論を持つプログラマーチームが解散したとき、プログラムは死を迎える。死んだプログラムでも、コンピューター上で実行され、有用な結果を生み出し続けることはある。プログラムの変更要求に対して、知的な対応ができなくなったとき、実際の死が明らかになる。」

さまざまなプラットフォームで共感を呼んだのは、次の洞察でした。「開発チームが理論構築やモデル化の段階を一切省いたとしても、コードを入力するうちに、受動的にモデルの一部を吸収するはずです。LLMが置き換えるのは、この最後の頼みの綱である、偶発的なモデル構築なのだと思います。」

ユーザーが本当に求めているもの：バイブコーディングへの要望

何百ものユーザーコメントから、開発者が必要としているものが明らかになりました。

1. コードをより深く理解するためのツール 

ユーザーがAIに求めるのは、コードを生成するだけでなく、生成したコードを説明することです。ある開発者はこう提言しています。「生成されたコードを受け入れる前に、必ず内容を理解すること。何をするコードなのか、なぜそうなるのか説明できないなら、マージしないでください。」受け入れる前に理解を必須とするツールがあれば、よく理解せずにマージする事態を防げます。

2. 本当に機能するサンドボックス環境

Simon Willisonは、Claude Artifactsのアプローチを高く評価しました。「コードは制限されたiframe内でのみ実行され、許可されたライブラリだけを読み込めます。また、他のサイトへのネットワークリクエストも行えません。」ユーザーが切実に求めているのは、バイブコーディングのミスで本番システムを壊したり、実データを漏えいさせたりしない安全な環境です。

3. 実効性のあるコード凍結機能

Replitのデータベース削除事故を受けて、Amjad Masadは約束しました。「『コード凍結』を望む声はしっかり受け止めました。コードベースを危険にさらすことなく戦略を練れるよう、計画・チャット専用モードの開発を積極的に進めています。」ユーザーは、レビュー期間中にAIがコードを変更しないという保証を求めています。

4. 開発環境と本番環境の分離をデフォルトに

Replitは、「こうした事態を根本から防ぐため、開発環境と本番環境のデータベースを自動で分離することを約束しました。ステージング環境も開発中です。」これが初日からデフォルトでなかったことに、経験豊富な開発者は驚きました。ユーザーは、すべてのバイブコーディングプラットフォームに標準で組み込まれることを望んでいます。

5. コード生成時のセキュリティスキャン

複数のユーザーが、「セキュリティのベストプラクティスを守るため、Cursorのルールを設定しておく」必要性や、「バイブコーディングで作るアプリをシンプルかつ安全に保つため、Cursorのコンテキストに追加できるチェックリストをClaudeに作らせた」ことについて述べています。ある開発者のワークフローはこうです。「新しい機能を追加したら、エージェントにセキュリティチェックをさせることが、私が学んだもう一つの重要なポイントです。」ユーザーが求めているのは、任意で選べるセキュリティチェックではなく、自動かつ必須のチェックです。

6. 制約を正直に伝え、現実的な期待を持たせること

Andrew Ngの講座の説明文は、ユーザーが必要としていることを捉えています。「『バイブコーディング』とは、生成されたコードをほとんど見ずに、アプリケーションのアーキテクチャや機能に集中する新たな実践を指します。しかし、広く信じられているのとは異なり、効果的なコーディングは、プロンプトを入力し、提案をすべて受け入れ、うまくいくことを願うだけではできません。作業を構造化し、プロンプトを磨き、体系的なプロセスを持つ必要があります。」

7. 必要なものがすべてそろったオールインワンプラットフォーム

KarpathyのMenuGenブログでは、こう述べられています。「アプリ開発プラットフォームには、必要なものがすべて最初からそろっているものがあってもいい。Vercel Marketplaceとは正反対のようなもの。誰もが求める基本機能、つまりドメイン、ホスティング、認証、決済、データベース、サーバー関数が、明確な設計方針のもと、具体的な形であらかじめ設定されているものです。」ユーザーは15ものサービスを連携したいのではなく、すべてが一貫した環境を求めています。

8. シンプルな技術スタック

Karpathyはさらにこう述べています。「次のアプリでは、基本的なHTML/CSS/JSとPythonバックエンド（FastAPI + Fly.ioのような構成？）にしようかと考えています。『モダンなWeb開発』のサーバーレスな多元宇宙より、ずっとシンプルなものです。」モダンな技術スタックの複雑さは、AIのハルシネーションの問題を増幅させます。

9. セッションをまたいで保持される記憶

ある開発者は苛立ちをこう語っています。「ルールやメモリーに情報を追加するよう明示的に頼まない限り、エージェントは作業を通じて学習しません。コンテキストをリセットしたり、新しいセッションを始めたりするたびに、まったくの新人と仕事をすることになります。」ユーザーが求めるのは、プロジェクトの慣習や過去のミスを覚えているエージェントです。

10. ロールバックとワンクリック復元

一連の事故を受けて、Replitはこう強調しました。「幸い、バックアップがあります。エージェントがミスをした場合でも、プロジェクト全体の状態をワンクリックで復元できます。」ユーザーはGitのようなバージョン管理と、AIの操作をすぐに取り消せる機能を求めています。

11. 透明性の高いコスト管理

600ドルを超える予想外の請求を受けたユーザーは、事前の上限設定、利用状況ダッシュボード、高額な処理を実行する前の警告を求めています。定額制からコンピューティング量に応じた料金体系への移行は、多くのユーザーにとって不意打ちでした。

AIツールはユーザーのフィードバックにどう対応しているか

2025年半ばまでに、いくつものプラットフォームがユーザーの要望への対応を始めました。ただし、導入状況には差がありました。

データベース事故を受けたReplitの対応には、開発環境と本番環境の自動分離、ステージング環境、プロジェクト状態のワンクリック復元、Replit固有の知識を調べるドキュメント検索の必須化、そして計画専用のチャットモードが含まれました。CEOのAmjad Masadによる迅速な対応で被害の拡大は抑えられましたが、ユーザーからは、こうした機能は初日から提供されるべきだったとの声が上がりました。

登場した TheAuditorや同様のオフラインスキャナーは、プライバシーを尊重したセキュリティへの需要を反映していました。TheAuditorは検出結果を65KB単位に分割し、Claude/GPT-4のコンテキスト上限に収めることで、クラウドにアップロードせずにAIで修正できるようにしました。開発者によると、プロジェクトの重大な問題は「3～4回の反復で185件からゼロになった」とのことです。

Snykはこのフィードバックにどう対応しているか

SnykのModel Context Protocolインテグレーションは、AIがコードを生成する際にリアルタイムで脆弱性をスキャンできるようにし、セキュリティ上の懸念に対応しました。SnykはCursor、GitHub Copilot、Windsurfなどのアシスタント向けにMCPサーバーを開発し、開発者がコードを受け入れる前にスキャンできるようにしました。DeepCode AIは 自動修正で80%の精度を達成し、セルフホストで実行できるため、コードを第三者に送る必要もありません。調査で明らかになったのは、憂慮すべき事実です。現在、AIが生成するコードの48%に安全性の問題があります（ジョージタウン大学の調査）。また、GitHub Copilotは、コードベースにある安全でないコードパターンから学習し、「既存の脆弱性を増幅させる」可能性があります。」

Snykが推奨するCursor向けセキュリティルールは、ユーザーの間で広く共有されるテンプレートになりました。「新たに生成した自社コードには、必ずSnyk Codeのスキャンを実行する。新規または更新された依存関係には、必ずSnyk SCAのスキャンを実行する。セキュリティ上の問題が見つかった場合は、Snykの検出結果を参考に修正を試みる。修正後に再スキャンし、問題が解決したことを確認する。」Snykのスキャナーでは一貫して、AI生成プロジェクトごとに50～200件以上の脆弱性が見つかりました。検出パターンには、f文字列によるSQLインジェクション、ハードコードされたシークレット（JWT_SECRET = "secret"が広く見られました）、認証の欠如、不適切なレート制限などが含まれていました。

CursorとSnykのMCPインテグレーションをはじめとするセキュリティツールは、内容を確認せずに「すべて承認」するワークフローの危険性を認識していました。厳選されたMCPツールのディレクトリから、ユーザーは検証済みのセキュリティツールを選べるようになりましたが、導入は任意であり、必須ではありませんでした。

現在、ユーザーはバイブコーディングをどう捉えているか

2025年第4四半期までに、バイブコーディングの用途は明確に分かれてきました。うまくいくのは、週末に作る使い捨てのプロジェクト、素早いプロトタイピング、機密データを扱わない個人用ツール、新しいプログラミング言語の学習、リスクの低い実験です。一方、本番システム、ユーザーデータを扱うアプリケーション、セキュリティが極めて重要なソフトウェア、金融・医療システム、長期的な保守が必要なものでは、深刻な問題につながります。

Twitterユーザーの@stevekrouse（Val Town）は、共通認識をこう表現しました。「バイブコーディングで書いたコードはレガシーコードです。Karpathyが提唱したバイブコーディングとは、『コードの存在すら忘れてしまう』ような、AIを活用したコーディングの一種です。誰にも理解されていないコードを指す言葉は、すでにあります。レガシーコードです。レガシーコードが嫌われるのは、当然のことです……バイブコーディングをすると、LLMがコードを吐き出すのと同じ速さで技術的負債を抱え込むことになります。だからこそ、バイブコーディングはプロトタイプや使い捨てのプロジェクトに最適なのです。保守する必要があって初めて、レガシーコードになるのですから。」

Simon Willisonによる区別は、定説となりました。「LLMがコードを一行残らず書いたとしても、それをすべてレビューし、テストし、理解しているなら、それはバイブコーディングではありません。LLMをタイピングアシスタントとして使っているのです。」責任あるAI活用とバイブコーディングを分けるのは、理解と説明責任です。

User @IroncladDevのツイートは、技術的な知識を持たない創業者の失望を端的に表していました。「『バイブコーディング』は、技術に詳しくない人にとっての幻想、蜃気楼のようなもの。誇らしい気分や達成感を抱かせるけれど、シニア開発者が報酬を得て解決するような難題に直面すると、AIエージェントはたちまち行き詰まる。現実の世界へようこそ。」引用されたユーザー自身も、こう告白しています。「アプリを閉じることにしました。Cursorはコードのほかの部分を壊し続ける。みんなの言うとおりだった。セキュリティ対策をしていないコードを本番環境にデプロイすべきじゃなかった。」

生産性のパラドックスは続いていました。Hacker Newsのコメント投稿者はこう要約しています。「それなら、生産性が上がったとは言えないと思う。『技術的負債をより速く増やす』なんて、『生産性』ツールにとって最悪の結果だ。」別の投稿者はこう付け加えています。「成功したイグジットの大半は、創業から5年以上経ってから起きることを忘れないでほしい。AIに1週間でプロトタイプを吐き出させれば、自分で4週間かけるよりシード資金をわずかに早く調達できるかもしれない。でも、その後4〜5年の間に製品開発が3週間以上遅れるなら、結局割に合わない。」

ユーザーが本当に求めているのは、ギャンブルではなく一貫性

何百ものユーザーの声に共通する根本的な洞察は、AIにエンジニアリングを置き換えてほしいのではなく、加速してほしいということです。RedditやHacker Newsで広まった言葉が、その苛立ちをよく表しています。「バイブコーディングはエンジニアリングではない。ただの運任せだ。」

ユーザーはAIコーディングアシスタントを手放したいわけではありません。Stack Overflowの2025年の調査では、チームの80%がAIコーディングツールを信頼していることが示されました。しかし同じ調査で、59%が新たな脆弱性を懸念し、56.4%がAI生成コードのセキュリティ問題に頻繁に遭遇していることも明らかになっています。信頼と懸念の隔たりが、今の状況を物語っています。

ユーザーが求めているものは高度です。内容を理解できるコードを生成するAI、デプロイ後ではなく受け入れ前に行われるセキュリティスキャン、8,000ドルの予想外の請求を招かない料金体系、アップデート後も一貫性を保つモデルの動作、安全な初期設定が標準で備わったプラットフォーム、そして理解不能なコードベースを抱えてプロンプトを操るだけの人にするのではなく、より優れたエンジニアへと成長させてくれるツールです。

バイブコーディングの熱狂が冷めた後、開発者は重要な教訓を得ました。理解を伴わないスピードは生産性ではなく、技術的負債をより速く生み出しているにすぎません。ユーザーはAIの可能性に期待を寄せましたが、必要なのは単なる加速ではなく、適切なガードレールだと気づきました。AIコーディング支援の未来は、「コードの存在すら忘れる」ことではありません。生成されたコードをより速く理解し、災害の後に対策を継ぎ足すのではなく、構想段階からセキュリティを組み込むことです。

AI生成コードのセキュリティを確保しませんか？ 「Secure by Design: A Playbook for AI-Assisted Coding」をダウンロードして、AIをワークフローに安全に取り入れるための具体的ですぐに実践できる手順とガードレールをご確認ください。