ハクソク

世界を動かす技術を、日本語で。

Vibeコーディングクリーンアップサービス

246日前原文(donado.co)

概要

  • Vibe Coding cleanup という新サービスカテゴリの台頭
  • AI生成コードの品質問題と 専門家による修正需要 の拡大
  • AIコードの失敗要因 と技術的負債の増大
  • 市場機会 と高単価な専門職の出現
  • エンジニアリング分野への影響 と今後のキャリアパス

Vibe Coding cleanup市場の誕生

  • Vibe Coding cleanup は、AI生成コードの問題修正を専門とする新たなサービスカテゴリ
  • LinkedInでの「AIの失敗修正」ジョークが 現実のビジネス機会 へと発展
  • 多くのAI生成コードが 本番環境に不適格 であり、企業は専門家の採用に奔走
  • 技術的負債の増大回避 が急務となる現状

Vibe Codingの爆発的普及

  • 2025年初頭、Andrej Karpathyが「 vibe coding」を提唱
  • 開発者はAIとの対話で関数単位のコード生成を行う新しい働き方
  • GitHubの調査 で92%の開発者がAIコーディングツールを利用、Copilotによる月間生成コードは数十億行規模
  • GitClearの分析 ではAI補助導入後に41%のコードチャーン（2週間以内の書き換え・削除）が発生
  • Stanfordの研究で、AI利用者は セキュリティ意識が過信 傾向、実際には安全性低下

AI生成コードの問題点

  • 入力検証不足、 古い依存関係、 一貫性のない設計 など、シニアエンジニアが嘆くレベルの品質問題
  • GitClearやStanfordの分析で セキュリティホール や構造的欠陥が頻出
  • AIは小規模タスクには強いが、システム全体の文脈理解は苦手
  • Stack Overflowの調査 で、AIは局所最適なコードを生成しがち
  • Georgetown Universityの研究で、AI生成コードの48%以上に脆弱性

Vibe Coding cleanup経済圏の拡大

  • 404 Mediaの調査 で、AI生成コードの修正を専門職とする開発者が増加
  • Hamid Siddiqiは15-20件の修正案件を同時進行し、高単価で「AIスパゲッティ」解消に従事
  • Ulam Labsは「Vibe Coding cleanup」を主要サービスとしてPR
  • VibeCodeFixers.comでは数百人の専門家が登録、案件マッチングが急増
  • Y Combinatorのスタートアップの25% が95% AI生成コードという現状

AIコードが大規模運用で失敗する理由

  • AIは システム全体の文脈を理解せず、局所最適なコード を量産
  • パターン不一致、重複ロジック、セキュリティホール の温床
  • 自動スキャナーでも見逃す問題や 秘密情報の漏洩、非推奨ライブラリの提案 が多発
  • 開発者自身が 生成コードを理解できず、問題を見抜けない ケースが増加
  • Thoughtworksは「 コンピテンシー負債」と警鐘、AI依存で自社システムの保守力低下

市場機会と新たな職種

  • Gartner予測 で2028年には75%のエンジニアがAIコードアシスタントを利用
  • 大半のプロジェクトで cleanup需要 が発生し、巨大市場へと成長中
  • MVP到達の高速化と、その後のcleanup作業が スタートアップの新常態
  • AIコード修正専門家の時給は200-400ドル、パッケージ化サービスも登場
  • Thoughtworksの報告で、AI補助下でリファクタリング減少・コードチャーン増加、cleanup前提の運用が必須
  • 「AIコード修復」専門職の求人が急増

エンジニアリング分野へのインパクト

  • AIが実装、ヒトが設計・テスト・修正担当 という役割分担へのシフト
  • Gergely Orosz曰く「AIは熱心なジュニア開発者」だが、 永遠にシニアにはならない
  • cleanupスキルを持つジュニアは 2年でシニア並みの待遇 も可能
  • AIの強みと限界を理解するシニアは 企業の中核人材 に
  • 堅牢なcleanupプロセス構築が競争優位 の鍵

Donado Labsの見解と成功事例

  • Donado Labsでは AI加速の有効性 を認識しつつ、 プロによるcleanup を必須プロセス化
  • 試作や定型処理はAI、本番設計や重要ロジックは人間担当
  • 「Vibe to Production」サービスで テスト・セキュリティ強化・ドキュメント整備 を徹底
  • AIコーディングの成功企業は、AI活用の巧拙で差別化
  • Vibe Codingは 危険なツール であり、専門知識・cleanup投資が不可欠

まとめ：AI時代の本当の機会

  • AIがプログラマーを代替する という主張への反論
  • 「コードを誰が直すのか」こそが最大のビジネスチャンス
  • cleanup市場の急成長と、 新たなキャリアパスの創出

Hackerたちの意見

うちの会社は何十年も緊急修理（システムがダウンして、企業に大きな損失を与えるやつ）をやってきたんだけど、ここ数年でその件数がかなり増えてるんだよね。

バイブコーディングって、DIYの配管工事みたいなもんかな。自分でちょっとやってみて、後で水がトイレ中に噴き出したら、高い料金で緊急の配管工を呼ぶみたいな。次回のためにちょっと学ぶことになるよね。

└

そう言えるね。でもプロの配管工は、DIYの人たちのために作られた道具を使うのが好きだったりする。違いは、いつ使うべきか、いつ使わないべきかを知ってることだね。

└

それに、YouTubeではプロ以上のことをするDIYの配管工がたくさん見つかるよ。

└

それは多分、バイブコーダーが経験から学ぶかどうかにかかってるね。どうなるか見てみよう。

└

もっとひどいよ。配管工の仕事なら、少なくとも自分が何をしてるか見えるからね。でも、バイブコード？ある日突然壊れて、なんで壊れたのかわからない。

└

いい例えだね。まるで不動産屋が家を売るプレッシャーにさらされて、急ごしらえのDIY配管をするみたい。家が売れたら、ちゃんとした配管工を雇って直してもらう、災害が起こる前にね。ここでは、創業者が投資家や顧客の注意を引くために何かをデモして、その後でちゃんと整えるって感じだね。

それだと、LLM生成のコードが一般的に廃れていくのかって疑問が出てくるね。この記事は、LLMが常に存在して、常にクリーンアップが必要だと仮定してるみたいだけど、本当にそれが価値があるのか、人間がコードを書く世界に戻るべきなんじゃないかと思う。だって、給料 < LLMクレジット + クリーンアップコスト だし。

└

コードを生成するためにLLMを使って、それをチェックして使うのは、もはや誰もコードを見ないVibe Codingとはちょっと違う。でも、どちらもこれからも残るだろうね。

└

一日中Vibe Codingをするのは、持続可能なコストがかかるかもしれないね。それがかなり補助されていたのは、非合理的な熱狂だったのかも。これは、いわばバイトアンドスイッチの後遺症を残すかもしれない。でも、存在するすべてのコード例を予測的なオートコンプリートや生成アシスタントに圧縮するという一般的なアイデアは決して消えないだろうね。まるでシンタックスハイライトなしでコーディングするようなもので、選択肢としてね。確かに、必要なときにはみんなそうしてたけど、もうそんなことはしないよね。できるけど、なんで？80回目の深さ優先探索のちょっとしたバリエーションを手で書くことで、自分が良くなった気がする？全然そんなことないよね？

└

今日のAIを使ったVibe Codingは確実に流行遅れになってるね。明日にはもっと良いAIが出てくるから。

しばらくの間、ビジネスを通じて「救助」プロジェクトを引き受けてるんだ。以前は、ほとんど機能していないコードがアウトソーシング会社を通じて生成されてたけど、今はLLMが新しいソースになりそうだね。結局、同じ問題が出てくると思う。ただコスト削減の方法が変わるだけ。ショートカットを取る理由はあるけど、経験上、そういうショートカットには代償があることを忘れてると問題が始まるんだよね。マネージャーでも、従業員でも、アウトソーシングの人でも、結果は同じ。バイブコーディングプラットフォーム用の別のサービスとして宣伝することは考えてないけど、考えた方がいいかも。オーストラリアのソフトウェア市場は小さいから、その実験の結果についてあまり聞かないんだよね。

└

SEOのために、少なくとも自分のウェブサイトにVibe Codingの用語を追加するのはいいアイデアかも。

└

そんなことを考えてたんだけど、結局会社にはどうなるの？もし彼らがバイブコーディングでプロジェクトを作って、バグだらけのクソコードになったら、君が入ってバグを直してコードを整理するだけで終わり？最初にセットアップする知識がなかったら、どうやってメンテナンスを続けるの？

└

アウトソーシングとLLM駆動の開発には、同じようなスキルがたくさん必要だと思う。つまり、「エンジニアリング」の部分（要件収集、コミュニケーション、ステークホルダー管理、仕様定義、テスト、ドキュメンテーション、そして全体の混乱を管理すること）だね。

└

バイブコーディングとアウトソーシングエージェンシーの問題の一つは、短時間で生み出せるコードの量が半端ないことだよ。簡単なヘルパースクリプトをバイブコーディングしたけど、自分で書いてたら1/3の行数で済んだし、ほとんどのエッジケースをカバーできなかった（無関係なものもあれば、実際に役立つものもあったけど）、時間もかかりすぎた。バイブコーディングされたコードが動くか確認する方がずっと早かったんだ。このタスクは「動くか動かないか」って感じで、微妙なエラーが入る余地はなかったしね。コードをざっと見て、一時ファイルを削除する行を削除して、ホームディレクトリを消さないようにリスクを減らして実行した。データを深く扱おうとしたら、一時ファイルが足りないことに気づいて、見逃してた二つの一時ファイル削除の行があったことに気づいた。人間が合理的に読むにはコードが多すぎるけど、スピードのメリットは本物だよ。今後の計画は、コードをもっと注意深く読むことじゃなくて、サンドボックスに入れてAIに遊ばせることだね。

└

Claude Codeみたいなツールには大きな違いがあるよ。プランモードってやつね。今、仕事でClaude Codeをたくさん使ってるんだけど、最初にするのはプランモードに入ること。そこで「どうやって実装するか説明して」って会話できるんだ。数回のやり取りの後、良い（または自分が思う「良い」）デザインに合わせてそのプランを洗練させることができる。そうしたら、何をするか（コードの差分付きで）正確に教えてくれるから、それにサインするんだ（また、数回のやり取りの後に）。その後にコードを生成するんだよ。対照的に、何年も前のプロジェクトでは、海外のチームが生成したコードをレビューしてたんだけど、全く理解できなかった。もう完全に絡まり合ったゴチャゴチャで、修正不可能だった。

バイブコードはレガシーコードと共通点が多い。変更する自信が低いし、内部と外部の品質も低い。でもいくつかの違いもあって、年齢と量の比率が低い、スケジュールのプレッシャー、膨れ上がった期待がある。エラーをランタイムからコンパイルタイム、コンパイルタイムからデザインタイムに移すのが最もコスト効果的なんだけど、残念ながらAIは人々をできるだけ早くランタイムに急がせるんだよね。

└

強い型付けの言語でVibe Coding使えるの？Vibeコードは他のレガシーコードのように扱えることが多いって同意するけど、Vibeコードを変えることに人々が消極的だって本当なの？

└

これ、面白いかも。「バイブコードはレガシーコードだ (val.town)」 https://news.ycombinator.com/item?id=44739556

└

レガシーコードが必ずしも悪いわけじゃないよ。単に複雑だったり、ドキュメントが不十分だったりするだけで、何年もかけて積み重ねられた本番環境での修正がちゃんと記録されてないことが多いからね（元のプロジェクトがそうだった場合がほとんどだけど）。君のレガシーコード製品は、過去の本番環境の問題（新しい要件も含めて）が特定されて修正されてきたおかげで、問題なく動いているかもしれない。でも、変更が必要になるときに問題が出てくることが多い。特に、コードベースに詳しい人がいなくなったり、使われていた言語やツールすら知らない場合はね。

バイブコーディングはドキュメントとアーキテクチャの明確さの死を加速させてる。企業は生成されたトークンやプロトタイプまでの時間で成功を測っていて、クリーンアップやメンテナンスの隠れた大きなコストを無視してる。今の本当のスキルは生成じゃなくてクリーンアップなんだよね。

└

本当のスキルは、生成されたソフトウェアがクソにならないように慎重に導くことだよ。ここにいる人たちは、クロードコードを見て最先端だと思ってるけど、最高の結果を得るにはもっと手間のかかるプロセスが必要なんだ。実際、他のエンジニアリングとそんなに変わらないよ。コストを最小限に抑え、要件を満たす。頭の良くない人たちは、メンテナンス性を仕様に入れないから、まさに求めた通りのものが手に入るだけ。

└

なんでドキュメンテーションが死んだって言われてるの？最初はドキュメンテーションだけで始めて、コードがそれに沿ってるか確認すればいいじゃん。コードからドキュメンテーションを生成することもできるし、ちゃんと合ってるか自分でチェックすればいいんだよ。

スタートアップはVibe Codingを使ってMVPに到達するのに数週間節約し、その後同じくらいの時間と予算をクリーンアップに使う。でも、それでも従来の開発より早いんだよね。これが記事で説明されている状況の核心だと思う。全体的に見て、開発者がMVPを作るよりも早いって本当なのかな。私が見た限りでは、特にAIの助けがあれば、開発者も同じくらい早く作れると思う。ただ、MVPやプロトタイプがすぐに本番環境に入るって分かってるから、あまりやりたくないかもしれないね。早めにしっかりしたアーキテクチャを作る方がいいと思うけど、プロダクトやマネジメントはそれを無駄だと見なすかも。一方で、Vibe Codingはプロダクトチームが開発者に説明することなく、欲しいものを正確に作れるようにする。それがこの技術の本当の魅力で、基本的にはもっと優れたFigmaみたいなものだね。もしかしたら、コードを作るふりをせず、開発者により良い仕様を提供しつつ、プロダクトやビジネス側がプロセスにもっと関与できるような、プロダクト指向のVibe Codingツールの市場があるかもしれない。

└

スタートアップはVibe Codingを使ってMVPに到達するのに数週間節約し、その後同じくらいの時間と予算をクリーンアップに使う。でも、それでも従来の開発より早いんだよね。 > これが記事で説明されている状況の核心だと思う。全体的に見て、開発者がMVPを作るよりも早いって本当なのかな。スタートアップではトラクションを示すことが非常に重要だから、マーケットへの投入時間を短縮することは大きなメリットになることが多いよね。たとえ全体的に見てもっと時間がかかっても。同じ理由で、人々は一般的に技術的負債を合理的に引き受けることができるんだ。

└

MVP？絶対に違うね。プロトタイプならあり得るけど…プロトタイプを作る場合、もし自分がそのプロトタイプを製品化しないっていう規律がないなら、組織も同じように規律がないと、バイブコーディングはお勧めしないよ。管理職に、今使ってる素晴らしいものを捨てて、内部がゴミだから書き直さなきゃいけないって納得させるのがどれだけ大変か、みんな知ってるよね。ノーコードツールの方が、その点では使いやすくて安全だと思う。

└

MVP/プロトタイプが直接製品化されることを十分に理解している。もしそれが起こらないと思ってたら、自分たちを騙してるよね。ここで言われてた名言を思い出すな。「もしあなたのMVPコードが身体的に気持ち悪くならないなら、コードの品質に時間をかけすぎてる。」MVPは、会社の未来の基盤になることが避けられないみたい。サービスは「C-Suite Cleanup As A Service」って言った方が正確かもしれないけど、そうなると誰も雇わないだろうね。

└

TwitterはRuby on Railsのウェブアプリとして始まって、ジャスティン・ビーバーがツイートするたびにTwitter全体がダウンして、フェイルクジラが現れてた。でも成長して、いつかはプロに依頼して、もっとスケーラブルで堅牢なスタックでゼロから書き直す余裕ができたんだ。

ジャニターエンジニアってもう存在してるの？マジか。あと、この記事の「Why AI code fails at scale」セクションから始まるリンクが、なぜか5日前に書かれたばかりなのに全部死んでる。ちょっと疑問だな… 追記: 誰かを不快にさせるつもりは全くないんだけど、実はVibe Codingの始まりからずっと半分冗談で「オールオーガニックコード」コンサルタントになって、AI生成のゴチャゴチャを整理してクリーンアップするっていう退職計画を持ってたんだよね。

└

ブラウンフィールド専門って、ずっと前からあることだと思う。むしろ、グリーンフィールドの方が珍しいよね。

Karpathyの「バイブコーディング」が概念として広まったのはちょっと奇妙だよね。経験が足りない人たちの間だけかもしれないけど。私の理解では、Karpathyが言ってた「バイブコーディング」ってのは、フローステートの「AIと話すだけで、振り返らない」みたいなものだった。生成されたコードを見ないで、AGIのバイブを感じるだけ・・・。もし自分が作ってるものの品質に少しでも気を使うなら、これは本当に恐ろしいことだよ！笑いのネタや「AGIが来た！」ってツイートにはいいかもしれないけど、真剣なソフトウェア開発の方法としてはどうなの？！！！これが流行った理由の一部は（クールな名前以外にも）Karpathyから来たからだと思う。あまり知られてない人が同じことを言ってたら、多分却下されてたよ。私はジュニア開発者（それほどジュニアじゃない人も）を見たことがあるけど、AIが出る前は、こういう風にコードを書いてた - どこかからコードをコピーして、動くまでハックするって感じ。厄介なコアダンプバグが出たら？ - ソースコードを並べ替えて消えさせる。最低でも、企業環境ではこういうやり方は注意されるし、パフォーマンスプランに乗せられるか、もっとひどいことになるかも！

└

多くの非技術者にとって、ソフトウェアエンジニアとの関係はひどい結果を生んでた。バイブコーディングは、私たちが提供してきたものへの非難だよ。バイブコーディングされた災害が何らかの形で望ましいってのは、私たちにとってあまり良いことじゃない。Karpathyのブランディングは可愛いけど、その成功には関係ない。バイブコーディングのスタートアップを運営してる人たちを知ってるけど、ソフトウェアの品質はゴミだよ。でも、彼らが望むことはできてる。それが今のところ彼らが気にしてることだから。ソフトウェアの品質がビジネスに影響を与える時が来るまで、彼らはバイブコーディングを続けるだろうね。アイデアを台無しにするソフトウェアエンジニアを雇うより、欲しいもののゴミバージョンの方が、いらないものの完璧なバージョンよりマシだから。

└

好きか嫌いかは別として、バイブコーディングはもう定着しちゃったね。私もこの考えには賛成できないけど、組織の人には「これをバイブコーディングした」とか言ってるよ。私たちにとっては、AIを使ってほとんどのコードを書いたって意味なんだ。ただ、レビューなしで本番環境に投入することは絶対にないけどね。これは「このクールなアプリをバイブコーディングしたから、見てみて、もしかしたらもっと大きなものになるかも…」って感じ。

└

そうだね、でも彼が言ってたのはバイブコーディングが「可能」だし、試してみるのも楽しいってことだと思う。どこまでできるかを見るのは確かに面白いし、驚くようなこともできるからね。でも、企業が本気で「バイブコーディング」で製品ソフトウェアを作ろうとするべきじゃないよ。二つの出版社と三人の著者は「バイブコーディング」の意味を理解できてないみたいだね - https://simonwillison.net/2025/May/1/not-vibe-coding/ （カーパシーがこの動画で彼の意図を説明してたと思うけど、詳細は忘れちゃったな：ソフトウェアは再び変わりつつある https://www.youtube.com/watch?v=LCEmiRjPEtQ）このフレーズは完全に文脈から外れてしまったと思う。多分、人々が信じたかったからだろうね。難しいことが簡単になったと信じたかったし、その方法でたくさんのお金を稼げると思ったんだ。

└

彼は内部の人間だから、毎回良い結果が得られるようにプロンプトや設定を工夫できるんじゃないかな。それを説明すると、すごく簡単に聞こえるし、当然君もやるべきだって感じになるよね。

└

今のところ、「バイブコーディング」ってAIのコーディング支援を貶める言葉になってる気がする。いつも通り、人々は手元のツールを使って良いコードも悪いコードも作れるけど、今は「バイブコーディングってマジでバカだよね！」って投稿するだけでネット上でたくさんのアップボートがもらえるから、ちょっと疲れちゃった。

└

カーパシーの「バイブコーディング」がコンセプトとして広まったのはちょっと奇妙だね。歴史のこの時点は、実際には何についても真剣さが欠けている時期だよ。逆に言えば、CEOたちに彼らの労働力がすぐに置き換えられるっていう心地よいフィクションが与えられているのと同じだね。

└

最初のツイートはジョークだったと思ってる。実際の仕事をするための提案じゃなくて、YOLOモードでコーディングする自由についての反省だったんだよね。指示として受け取るべきじゃなかった。

最初から、エムダッシュなしでも、この投稿がクロードによって書かれたのは明らかだったよ。OPは自分のアイデアをプロンプトに入れたり、いくつかのソースを提供したりしたんだろうけど、これらのフレーズを読むと、まるでLLMの出力を読んでいるような生々しい感覚を覚えたよ。「厳しい現実」「彼は完璧に捉えた」「シニアエンジニアを泣かせるような設計の決定」「根本的な問題」みたいな感じ。これって、全く同じようなリズムの文章がLLMの出力に似すぎて、ある種の書き方が廃れちゃうんじゃないかって思っちゃう。

└

バイブライティングのクリーンアップサービスに備えておけ…

└

私は一生エムダッシュを多用してきたけど、今はそれを排除しなきゃいけない気がする :(

└

Microsoft Wordは、ほとんどの場合、ハイフンをエムダッシュに自動修正するよ。