- 最近、IT業界で 「バイブコーディング・クリーンアップ」 という新しいサービスカテゴリーが登場している:
Vibe Coding Cleanup as a Service
- AI生成コードの大半は本番運用に適していない という現実が明らかになるにつれ、それを整理・修正する新たなサービス市場が生まれている
- Andrej Karpathyが2025年初頭に 「Vibe Coding」 を定義して以降、開発者の92%がAIツールを活用している一方で、コード品質の低下や セキュリティ脆弱性 の問題が深刻化している
- 実際に開発者たちは、AIが作成した 不整合・重複・不合理なロジック を解消することを専門業務とし、専用マーケットプレイスやコンサルティングサービスが広がっている
- AIは小さな作業には優れているが、システム全体の文脈を考慮できないため 構造的負債とセキュリティ問題 を量産し、それがやがて「クリーンアップ経済」という新しい産業機会を生み出している
- 企業がAIコーディングをうまく活用するには、プロトタイプはAIに任せつつ、アーキテクチャ・セキュリティ・テストの整理工程に専門人材を投資 する必要がある
バイブコーディングの登場と拡大
- 2025年初頭、Andrej Karpathyが 「バイブコーディング」 という用語を使い、この概念が定着した
- 自然言語の対話を通じて関数全体を生成する方式
- 生産性を10倍向上できるという期待とともに急速に普及
- GitHubによれば、開発者の 92%がAIコーディングツール を使用している
- Copilotは毎月数十億行のコードを生成している
- しかしGitClearの分析によれば、AIコード利用時には 41%高いコード変更率 が見られる
- 2週間以内に差し戻しや再作成されるコードが大幅に増加
- Stanfordの研究では、AI支援を使う開発者は 安全性の低いコードをより多く書く 一方で、より安全だと信じる傾向 を示した
- AIツールは、入力検証の欠如、古い依存関係の使用、曖昧な設計判断などにより、さまざまなアンチパターンを増幅する問題を引き起こす
クリーンアップ経済の現実
- 最近のIT業界では、バイブコーディング・クリーンアップという新しいサービス領域 が静かに立ち上がっている
- 当初は「AIが作ったぐちゃぐちゃなコードを直す」という冗談レベルで始まったが、今では実際のビジネス機会として定着しつつある
- 404 Mediaの調査によれば、一部の開発者は AIコードの整理だけでキャリアを築いている
- 「AIスパゲッティ」と呼ばれる不整合・重複・的外れなロジックを解体する仕事
- Ulam Labsは Vibe Coding Cleanup を中核サービスとして宣伝している
- VibeCodeFixers.com という専用マーケットプレイスも登場
- わずか数週間で300人以上の専門家が参加し、数十件のプロジェクトがマッチング
- 典型的な顧客: 「数千ドル分のOpenAIクレジットを消費し、半分だけ動くプロトタイプを抱えたスタートアップ」
AIコードが失敗する理由
- 問題はAI自体が悪いコードを書くことではなく、システムの文脈を理解できず、局所最適化されたコードを書くこと にある
- その結果、不整合パターン・重複ロジック・セキュリティ上の抜け穴 が蓄積し、技術的負債が発生する
- Georgetown Universityの研究によれば、AI生成コードの少なくとも48%がセキュリティ脆弱性 を含んでいる
- 秘密情報の露出、古いライブラリの使用、高負荷時に発生する競合状態など
- さらに深刻なのは、開発者自身がAI生成コードを十分に理解できず、問題を適切に発見できない現象 である
- Thoughtworksはこれを 「能力負債」 と定義している
市場機会
- クリーンアップ市場は急成長しているが、具体的な数値の把握は難しい
- Gartnerは 2028年までに企業開発者の75%がAIコード補助を使うようになる と予測している
- ほとんどのプロジェクトで整理の必要性が生じると見込まれる
- その一部だけでもクリーンアップが必要になれば、規模の面で非常に大きな新市場として浮上する
- 経済面でも魅力がある
- スタートアップはAIで素早くMVPを作るが、その後の整理に同等の時間と費用を投入する
- それでも従来型の開発よりはなお速い
- クリーンアップ専門家は 1時間あたり200〜400ドル を請求している
- 定額パッケージ、AIコード監査、「Vibe-to-Production」パイプラインのようなプロダクト化されたサービスも拡大
- Thoughtworksによれば、AI活用プロジェクトでは リファクタリング比率が低下 し、コード変更はさらに増加、さらに実際の本番投入前に大規模な整理工程が必須となっている
- 多くのコンサルティング企業が、AIコードのクリーンアップや修復役を専門に担う人材の採用を開始している
- 結論として、クリーンアップ市場は実在し、急速に成長しており、なお未開拓の領域が多い
エンジニアリングへの影響
- ソフトウェア開発手法の 根本的な変化 が進行中である
- 開発プロセスは AIが実装し、人がアーキテクチャ・テスト・整理を担当する 分業体制 へと再編されている
- Gergely Oroszは AIツールを「非常に意欲的なジュニア開発者」 に例え、速いペースでコードを書くが常に監督が必要だと強調している
- しかしAIは 常にジュニア開発者のレベルにとどまり、シニアへ成長しないため、常にクリーンアップ専門家の役割が必要になる
- 新しいキャリアパスも開かれている
- ジュニア開発者が整理スキルを身につければ、2年でシニア級の年収が可能
- AIの強みと限界を理解するシニア人材は高い価値を生み出す
- 成功する企業はAIを最も多く使う企業ではなく、整理プロセスを体系的に構築する企業 である
- 強固な クリーンアッププロセスを構築 した組織は、市場で競争優位を持つことができる
Donado Labsの立場
- Donado Labsは数多くの バイブコード整理の経験 に基づき、AIは加速には有用だが、必ず専門家による整理工程が必要だと強調している
- プロトタイピングや反復作業にはAIを、中核アーキテクチャとセキュリティ・テストは人間 が担当する
- 「Vibe to Production」サービスにより、AIプロトタイプを企業レベルへ整備 する
- AIコーディングを成功裏に活用する企業は、AIを最も多く使う組織ではなく、AIを賢く活用し、整理に投資する組織 である
- 技術的負債が蓄積する前に、クリーンアップを並行して進めることが重要
- AIがプログラマーを置き換えるという主張に対して、「そのコードの後始末は誰がするのか?」という問いこそが 本当のビジネス機会 である
4件のコメント
GPT初期には、コーディングを外注している人たちに対して、AIでプロトタイプを作ったから少し仕上げるだけでいいと言って買い叩く人たちがいましたよね。
とありますが、正直、これをやる人っているんでしょうか？
Vibe Codingの登場以前から、めちゃくちゃなコードを整理してくれるサービスがあればいいなとは思っていましたが、こうして誰かが作るものですね。ただ、うちの会社で導入することはなさそうです T_T
AI画像の指を修正してくれる外注が流行っていましたが……今ではそれすらやらなくなりました。
AIクリーンアップも、そういう前例をたどりそうですね
Hacker Newsの意見
私はかなり長い間、ビジネス経由で「構造改善」プロジェクトを請け負ってきた。
以前はほとんど動かないコードを主に外注エージェンシーから受け取っていたが、最近はその発生源がLLMに移ってきたように見える。
結局、同じ問題が繰り返されているように思う。
ただコスト削減の方法が変わっただけだ。
近道を選ぶ理由は確かにあるが、それによってコストが発生しうることを十分に認識していないときに本当の問題が起きる。
マネージャー、社員、外注人材など出所に関係なく、結果は似たようなものだ。
まだ vibe coding プラットフォームの構造改善サービスを別途宣伝したことはないが、そろそろ試してみる時期かもしれない。
オーストラリアのソフトウェア市場は小さいので、そうした実験の結果はあまり聞こえてこない。
vibe coding と外注開発の違いは、コード生産量にあると思う。
一度、vibe coding で簡単なヘルパースクリプトを作ってみたが、自分で書いていたら今のコードの1/3ほどにしかならなかっただろうし、ほとんどのエッジケースは最初から扱わなかったはずだ（無駄な例外処理もあったし、本当に役立つものもあった）。
私がやったのはコードをざっと見て、誤ってホームディレクトリが削除されかねないので temp ファイル削除の1行を消す程度だった。
ところが後でさらに深いデータ処理をしているうちに、temp ファイルが一部消えていて、削除コードがほかに2か所あったことに気づいた。
実際、人が読むにはコード量が多すぎて、全部確認するのは非現実的だ。
それでも速度面では間違いなくものすごい効率だ。
今後はコードを細かく読むより、サンドボックスでAIにテストを回させるつもりだ。
特に Claude Code のように「プランモード」があるツールでは大きな違いがある。
最近、会社で Claude Code をよく使っているが、いつもプランモードで対話しながらまず「どう実装するか」を聞き、数回のやり取りで良い設計になるよう詳細プランを詰めている。
その後、AIはどんなコードを生成するかを（コード diff とともに）正確に示し、私が最終承認してから実際のコードを生成する。
対照的に、以前外注チームが作ったコードをレビューしたときは、内容を到底把握できないめちゃくちゃなスパゲティコードだった。
SEOのためだけでも、vibe-coding 関連の用語をサイトに書いておくのは悪くないアイデアだと思う。
私も似たことを考えた。
ただ、プロジェクトが vibe-coded でバグだらけのコードになったとき、私が行ってバグを直し、構造を整えればそれで終わりなのか？
そもそも設定するための専門知識すらなかった会社が、その後どうやって保守を続けられるのか気になる。
外注と LLM ベース開発の両方で、結局は同じような能力が必要だと思う。
つまり、要件整理、コミュニケーション、ステークホルダー管理、仕様定義、テスト、文書化といったエンジニアリングの堅実な基礎が引き続き必要だということだ。
Karpathy の "vibe coding" という概念が、こんなふうに流行したのは少し奇妙に感じる。
おそらく実際の開発経験があまりない人たちの間でだけそうなのではないかと思う。
私の記憶では、vibe coding とは「ただAIと会話しながら、コード生成結果は確認もせず、流れだけを信じて進める」一種のフロー状態で、コードはほとんど見返さないアプローチだった。
真面目に作るソフトウェアで品質が少しでも重要なら、本当にひどいやり方だ。
Twitterのミームや自己満足の実験、家で使う小さなスクリプト程度には使えても、ちゃんとした製品を開発するときに成り立つ話ではないと思う。
ここまで話題になったのは Karpathy のような有名人によるうまいネーミングのおかげで、別の人が言っていたら埋もれていただろう。
AI以前から、ジュニアや経験の浅い開発者はすでにこういうやり方でコーディングしていた。
どこかからコピペして動くことだけ確認し、妙なバグやコアダンプが出たらソースコードの順番だけ変えてどうにか消す、というやり方だ。
こういうスタイルは会社では少なくとも警告を受けるか、改善計画に入れられるか、ひどければ退場させられかねない。
非専門家はソフトウェアエンジニアとのやり取りで、きちんとした成果を得られないことが多かった。
vibe coding の登場は、私たちがこれまでどんなソフトウェアを届けてきたのかを省みるきっかけだと思う。
実際、私の知る vibe coded スタートアップのソフトウェア品質はひどいが、彼らが望む動作さえすれば、現段階では品質は重要ではない。
ソフトウェア品質がビジネスに「実際の打撃」を与えるまでは、わざわざ開発者を雇って自分たちのアイデアが変質するリスクを負いたがらないだろう。
結局、ゴミのようでも自分たちが今すぐ使えるもののほうが、自分たちの望まない完璧なソフトウェアよりましなのだ。
好き嫌いは別として、vibe coding は今後も消えないだろう。
私自身この概念にはあまり賛同していないが、組織内では同僚に「これ vibe coded で作ったよ」と時々言っている。
私たちにとっては「コードの大半をAIで自動生成した」程度の意味だ。
とはいえ、こうして作ったコードをレビューなしでそのまま本番に載せるつもりは絶対にない。
単に「かっこいいアプリを vibe coding でさっと作ってみた」くらいの、軽い実験用途でしか使っていない。
Karpathy は、vibe coding は試してみる価値のある「可能な実験」で、どこまで行けるかを試すのが面白い、という趣旨で言っていたのだと思う。
会社で本当に vibe coding だけで製品を作れという推奨ではなかったはずだ。
人々がこの表現の文脈をあまりにも自分勝手に解釈したのだ。
実際、Karpathy は自分の言葉の意味をYouTube動画で説明している。
関連記事
Karpathy YouTube: Software Is Changing (Again)
人々は難しいことがこれで簡単にできるようになると信じたがっているので、誤解がさらに膨らんだのだと思う。
私は、もともとの tweet 自体も冗談か「YOLOコーディング」の自由さを表現しただけで、実務プロセスとして勧めたものではないと今でも思っている。
そのとき感じた解放感を愉快に書いただけだ。
今や vibe coding は、実質的にあらゆるAIコーディング支援を見下したり皮肉ったりするための言葉として使われている感じがする。
どんなツールでもうまく使うことも下手に使うこともできるのに、最近は「vibe coding がいかにバカげているか」というミームがオンラインで手っ取り早く支持を集める。
もううんざりするほどだ。
「スタートアップが vibe coding のおかげで数週間短縮してMVPを作り、あとで同程度のコストと時間をかけてクリーンアップするとしても、従来の開発よりなお速い」というのが記事の主張の核心だ。
本当にそうなのか気になる。
私が見た限りでは、開発者が自分で作ってもAI支援を使えば速度差はそれほど大きくないかもしれない。
特にMVPやプロトタイプが後でそのまま本番に入ると分かっているなら、最初にアーキテクチャをきちんと決めるほうが長期的には良いと感じる。
だが、たいていプロダクト側や経営陣はこの時間を無駄だと見なす。
vibe coding の本当の利点は、プロダクトチームが開発者に説明する必要なく、自分たちの欲しいものをすぐ直接作ってみられる点だ。
ひょっとすると、コードそのものを作るというより、仕様やプロトタイプを明確にする vibe coding ベースのプロダクトツールのほうが市場性があるかもしれない。
そうしたツールは開発者にはより良い仕様を与え、ビジネス側にもより大きな貢献と主導権をもたらせる。
スタートアップでは市場投入が非常に重要なので、トータルで時間もコストも余計にかかるとしても、リリースが速いという理由で技術的負債を受け入れるのは十分に合理的な判断だ。
だから人は技術的負債を積み上げるのだ。
Twitter も最初は Ruby on Rails ベースのWebアプリとして始まり、ジャスティン・ビーバーがツイートするたびにサーバーが落ちて fail whale が出ていた。
だが成長するにつれて、最終的には専門家を雇って、より堅牢でスケーラブルな構造へと本格的に作り直した。
MVPというよりプロトタイプ程度には使えるかもしれないが、
プロトタイプを prod に上げないという組織的・個人的な規律がないなら、vibe coding は避けるべきだと思う。
会社の経営陣に「今まさに使っているすばらしいコードは中身がぐちゃぐちゃなので全面的に作り直す必要がある」と説得するのがどれほど難しいか、みんな分かっているはずだ。
こういう場合は、むしろノーコード(no-code)ツールのほうがずっと安全だ。
ほとんどのMVPやプロトタイプは結局すぐ本番に上がるのが現実だ。
ここで誰かが「MVPコードが見ていて具合が悪くなるほど汚くないなら、コード品質に時間をかけすぎている」という話をしていたのを思い出す。
結局、その場しのぎのコードが会社のバックボーンになる。
こうした構造改善だけを請け負うサービスを「C-Suite cleanup as a Service」と呼んでもいい気がするが、そんなふうに宣伝したら誰も雇わないだろう。
記事を読んですぐ、em-dash がなくても Claude が書いた文章だとはっきり感じた。
もちろんOPは自分の考えや資料をプロンプトとして与えたのだろうが、独特の言い回しや文のニュアンスがLLMでよく出るものとまったく同じで、無理やり読まされている感じがした。
こういうスタイルの文章は、今後「LLM文体」として時代遅れになっていくのではないかと思う。
これからは vibe-writing cleanup as a service が主流になりそうだ。
私は昔から em-dash をよく使ってきたが、今や無理にでもそれを減らさなければならない時代が来た気がする。
Microsoft Word は自動でハイフンを em-dash に変えてくれる。
vibe coding はDIYの配管作業に似ていると思う。
自分でやってみて浴室で水が噴き出したら、結局は高い金を払って緊急出動の配管工を呼ぶ羽目になる。
その過程で次はもう少し学ぶことになる。
似たように見られるが、プロの配管工もDIYを補助する道具をうまく使う。
違いは、プロはいつどこまで使うべきかをよく分かっていることだ。
むしろもっと深刻だと感じる。
配管工の仕事は何をしているか目で見ながら進めるが、vibe code はある日突然何かが動かなくなり、理由も分からない。
YouTube では、むしろプロより丁寧に作業するDIY配管工もたくさん見られる。
vibe coder がこうした経験から本当に学ぶかどうか次第だと思う。
時間がたてば分かるだろう。
この比喩は本当に的確だと思う。
プレッシャーを受けた不動産仲介業者が家を売るために慌てて配管工事をするように、スタートアップ創業者も早く何かをデモして投資家や顧客の関心を引き、あとで本物の専門家を呼んでクリーンアップする。
運が良ければ、その前に大事故を防げるかもしれない。
Janitor Engineer（清掃員エンジニア）という言葉がすでに業界にあったのかと驚いた。
それと、"Why AI code fails at scale" の後にある記事リンクが全部切れていたが、わりと最近の文章なのに余計に不思議だ。
念のため言っておくと、これを誰かが不快に受け取らないでほしい。
私も vibe coding が流行してから、AI が生み出したコードの塊を片っ端からほどいて整理する「all-organic-code」コンサルタントになるという半分冗談の引退プランをずっと考えている。
本当に希少なのは、むしろ新規プロジェクト(greenfield)のほうだ。
vibe coding は文書化とアーキテクチャの明確さを急速に弱めている。
会社はコードトークン生成量とプロトタイプの速さだけを重要指標と見なし、隠れた保守・クリーンアップコストを無視している。
今や本当のスキルは生成ではなくクリーンアップだ。
本当の実力は、最初からうまくガイドして、ちゃんとしたソフトウェアを引き出すことだ。
Claude Code のようなものを見て「これが最先端技術だ」と考える人もいるが、きちんとやるにははるかに多くの関与が必要だ。
実際のところ、従来のエンジニアリングと大して変わらない。
コストを最小化し、要求を満たすことが核心だ。
保守性を明示的に要求しなければ、そのまま本来意図された結果（？）が出てくる。
なぜ文書化の死なのか分からない。
最初から文書だけを書いて、その後コードがその文書と一致しているかを確認しながら開発するやり方もある。
あるいはコードから文書を生成させて、それが妥当かどうかを自分でレビューすることもできる。
うちの会社は何十年も、顧客企業の非常事態システム（障害などで深刻な金銭損失が発生し、自力では解決不能）の緊急復旧を続けてきた。
ここ数年で、こうした事例はかなり急速に増えている。
vibe code は多くの点でレガシーコードに似ている。
コードに自信が持てず変更をためらい、内部品質も外部品質も低い。
ただし違いもある。
年数の割にコード量が少なく、スケジュール圧力が強く、期待値が誇張されている。
最も費用対効果が高いのは、エラーを実行時(runtime)ではなく、できるだけ設計(design)やコンパイル時より前に移すことだ。
問題は、AIのせいで誰もがランタイムまであまりにも速く突っ走ってしまうことだ。
参考までに、"Vibe code is legacy code (val.town)" という記事は読む価値がある。
関連HN投稿
レガシーコードだからといって、いつも悪いとは限らない。
たいていは複雑だったり文書化が不足していたり、長い年月のあいだに大小さまざまな運用上の修正パッチが積み重なっていたりする。
多くの運用課題（新しい要件など）が反映されていて、実サービスでうまく回っていることも多い。
問題は、そのコードベースに詳しい人がいなくなり、さらには当時使っていた言語やツールを知る人材すらいなくなるときだ。
vibe coding は強い型付けの言語にも適用できるのだろうか。
vibe で作られたコードをレガシーコードのように扱えるという点には同意する。
ただ、人々が vibe code に対しても本当に変更をためらう傾向があるのかは気になる。
LLMによるコード生成は、今後消える可能性もあるのではないかと思う。
この記事は、LLMコードが常に作られ、常にクリーンアップが必要だと前提しているが、もしLLMコスト+クリーンアップコストが常に開発者の給与より高いのなら、結局は人間が直接書く方向に戻るべきではないか？
LLMでコードを生成してから確認して使うのは、vibe coding とは違う。
vibe coding は、完成したコードを確認せずそのまま使う場合だ。
どちらのやり方も結局なくならないように思う。
今日のAIベースの vibe coding は、だんだん流行の勢いが落ちている。
なぜなら、まもなくもっと優れたAIが現れるからだ。
一日中 vibe coding ばかりしていると、結局コストが見合わない構造になるかもしれない。
手厚い支援や補助のおかげで皆が熱狂していたのは錯覚だったのかもしれず、後になって現実に気づいて苦しむことになる。
コーディング事例がすべて取り込まれ、予測補完・自動生成の補助ツールになっていく流れ自体は絶対になくならない。
昔はシンタックスハイライトなしでもコーディングしていたが、今では誰もわざわざそうしないのと同じだ。
DFSのようなものを80回目も打ち直したからといって、プログラマーとしての自尊心が高まるわけではない。