バイブコーディングの後始末が週160万円——slopfixが示すAI技術的負債の現実

経営の意思決定にAIを使い倒している、ひでです。

「AIで開発が速くなった」。

この一年、何度も聞いた言葉です。

ところが最近、その次に来る請求書の話が経営者の間で静かに増えています。

速く作ったコードを、あとから人手で作り直す費用です。

海外では、その後始末そのものを週$10,000（約160万円）で請け負うチームが現れました。

今日は投資助言でも技術論でもなく、この現象が発注側の経営に何を突きつけているかを整理します。

AIコードの「後始末」が商売になった——slopfixという新業態

slopfixは、AIで書かれたコードベースを保守できる状態に戻すことだけを請け負う3人のチームです。

Maciejさんをヘッドに、KubaさんとKrzysztofさんの計3名。

彼らの投稿が2026年7月7日にHacker Newsを賑わせました。

面白いのは、これが「動かないものを直す」サービスではない点です。

依頼主のコードは動いています。

ただ、機能を1つ足すのに数日かかり、そのたびに別の2つが壊れる。

動くのに触れない、という状態です。

週160万円・成果連動という料金設計

週$10,000で3名を1週間投入する形ですが、注目すべきはその先です。

彼らは事前に削減目標を約束し、達成率に応じて金額を調整します。

50%削減を目標に掲げて20%しか達成できなければ、達成率は40%なので請求も$4,000（約64万円）に下がる、という按分です。

後始末という曖昧になりがちな仕事に、検収可能な計算式を先に置いている。

ここが商売として成立している理由だと僕は見ています。

依頼主は「動くけど触れない」コードを抱えた企業

依頼主の典型は、スケールの過程でコードの重複が増え続けた企業です。

急いで機能を積み増すたびに似たコードが方々にコピーされ、どこを直せば何が壊れるのか誰も把握できなくなる。

これは特殊な失敗ではありません。

速さを優先すれば通る道で、AIが開発速度を上げたぶん、この状態に到達するのも速くなっただけです。

10万行が3.5万行になる——バイブコーディングが積む技術的負債

slopfixが公開した実例が象徴的です。

あるコードベースを10万行から3.5万行へ、約65%削減しました。

行数は scc というツールで計測しています。

つまりそのコードは、3分の2近くが無くても同じ機能を提供できた。

動作に寄与しない負債がそれだけ積み上がっていた、ということです。

なぜAIが書くとコードは膨らむのか

人間のエンジニアなら、既にある関数を思い出して再利用します。

AIは指示に対してその都度もっともらしいコードを生成するので、似た処理が別の場所に何度も書かれやすい。

悪意はなく、構造として重複が増えます。

小さいうちは問題になりませんが、重複はスケールに比例して効いてきて、ある規模を超えると「1つ直すと2つ壊れる」状態に転じます。

削るのはAIではなく人間の経験

ここは正確に押さえたいところです。

一部の報道は「AIエージェントがAIコードを削除する」と伝えましたが、本人たちの説明を読むとやや単純化されています。

彼らはClaude Codeを使うものの、ごく短いリード（very short leash）で走らせ、どこを残しどこを削るかの判断は人間の経験に委ねます。

片付けたあとは CLAUDE.md のようなガードレールを装備し、同じ膨張の再発を防ぐ。

AIは道具で、判断は人間、というのがこのビジネスの前提です。

AIコード発注で経営者が備えるべきこと

日本語のネット記事の大半はエンジニア向けで、「発注した側の経営者が何を確認すべきか」を扱ったものはほとんど見当たりません。

ですがslopfixの話は、発注側の経営判断に直結する材料です。

「動く」と「保守できる」を分ける検収の目

多くの発注者は、デモが動けば検収を通します。

ですが「動く」と「保守できる」は別物です。

slopfixの依頼主は全員、動くコードの検収を通したうえで、あとから触れなくなって困っている。

検収の場で「この機能を1つ追加するのに何日かかりますか」「似た処理はどれくらい重複していますか」と一言聞けるか。

この差が、あとで払う後始末代の有無を分けます。

契約に品質の約束を書き込む

対処は難しくありません。

発注契約に、動作要件だけでなく保守性の要件を書き込むことです。

• コードの重複率をどの水準に収めるか（scc などで計測可能な数字にする）
• 仕様や設計のドキュメントを納品物に含めるか
• CLAUDE.md のような再発防止のガードレールを引き渡すか

これらを初期の見積もり時に握っておけば、保守フェーズで後始末を別発注する二重の出費を防げます。

負債は消せませんが、どこまで許容するかを先に決めることはできます。

受注側の商機——「後始末」市場は始まっている

視点を変えると、slopfixは受注側にとっての型を示しています。

「AIで速く作る」の第一波が生んだ負債を、「人の判断で片付ける」第二波が商売になり始めた、という構図です。

成果連動の価格設計もよくできています。

削減率を先に置き、届かなければ減額すると宣言することで、成果の見えにくい後始末の発注ハードルを下げている。

日本でも同様の後始末を掲げる受託事業者が出始めています。

速く作る競争ではAIが優位でも、何を残し何を捨てるかの判断は経験が効く領域です。

まとめ——負債は管理できる。管理しないと後始末代を払う

伝えたいのは「AI開発は危険だからやめろ」ではありません。

速く作ること自体は正しい選択です。

要点は1つ、技術的負債は消せないが管理はできる、ということです。

管理しなければ、あとから週160万円級の後始末代を誰かに払う。

slopfixが商売として成立している事実が、その請求書の実在を証明しています。

発注側がやるべきは、「動くか」の先に「保守できるか」を検収に足すこと、そして負債をどこまで許すかを契約で先に決めておくことです。

ここまでやれば、後始末は突然の出費ではなく、管理された経営判断の範囲に収まります。