AIスロップを回避する：バイブコーディングでもコード品質を保つ（2026年）

Jasmine、Claude Codeを毎日使い、この記事を書けるだけのAIスロップを世に出し（そして片付け）てきた開発者です。

バイブコーディングは、とんでもないスピードをもたらします。しかし、AIに1か月コードを書かせた人なら誰もが同じ感覚に突き当たります。「完璧に動く」PRをマージしたのに、数週間後にそれがエッジケースを取りこぼしていたり、誰も頼んでいない抽象化レイヤーを勝手に作っていたことに気づくのです。それがAIスロップです。この記事はバイブコーディングに反対するものではありません。この言葉が初めてなら、まずバイブコーディングとは何かを読んでください。ここでのテーマは、バイブコーディングに規律を持たせて品質を保つことです。

AIスロップとは？（そしてSNSの「AIスロップ」とどう違うのか）

AIコードスロップとは、AIが生成したコードのうち、コンパイルが通りテストにも合格するのに、構造的に浅く、プロジェクトの規約を無視し、人間がレビューできる速度を超えてマシンのスケールで量産されるために、それでもコードベースを腐らせていくコードのことです。これは「明らかに間違っている」コードではありません。もし見るからに壊れているなら、すぐに気づけるはずです。スロップが危険なのは、まさに正しく見えるからです。

この区別が重要なのは、「AIスロップ」という言葉が2つの方向に引っ張られているからです。

「AIスロップ」の2つの異なる意味：

1. AIコンテンツスロップ - SNSのフィードに氾濫する、大量生産されたゴミのような動画・画像・記事のこと。Merriam-Websterはまさにこの意味で「slop」を2025年の今年の言葉に選びました（2025年12月15日発表）。「AIスロップ」で見つかる記事のほとんどはこちらの話です。

2. AIコードスロップ - AIが生み出す低品質なコードのこと。この記事の主題です。これはエンジニアリングの観点であり、正直に語られることははるかに少ないテーマです。

SNSのコンテンツという意味を探して来たのなら、この記事は向いていません。自分のAI生成コードが正しく見えるのに間違っているのではと不安なら、ぜひ読み進めてください。関連して目にする用語：ai code slop、vibe slop、low-quality AI code。

AIスロップコードの6つのサイン（分類）

すべてのAIコードがスロップというわけではありません。しかしスロップにはかなり見分けやすい「指紋」があります。私が最もよく遭遇する低品質AIコードの6つのサインを、素早く見抜けるよう簡単な例つきで紹介します。

1. 正しく見えるのに、端で間違う。サンプル入力では問題ないのに、空文字列、タイムゾーン、負の数、ページネーションの最終ページで壊れます。例：空配列を一切扱わないため、ゼロ除算してしまう平均値計算の関数。
2. 過剰設計／不要な抽象化。5行で済むもののために、AIがファクトリ、ストラテジーパターン、汎用レイヤーを作り込みます。例：1つの日付文字列を整形するためのインターフェース＋3つのクラス。
3. リポジトリの規約を無視。命名、フォルダ構成、エラーハンドリングが、コードベースの他の部分とまるで違います。例：プロジェクトはResult<T>を使っているのに、AIはあちこちで例外を投げる。
4. 存在しないAPI／設定／パッケージのハルシネーション。存在しない関数を呼んだり、間違ったパッケージ名をインポートしたり、削除された設定オプションを使ったりします。例：import { parseDate } from 'date-fns' - ただしdate-fnsはその名前を一度もエクスポートしていません。
5. 実装をなぞるだけのテスト。テストが、生成されたばかりのコードをそのまま通すために書かれており、期待される振る舞いを検証していません。例：戻り値をモックしておいて、その同じモックに対してアサートする。
6. ハードコーディングとマジックナンバー。数値・URL・キーが、設定ではなくロジックに直接埋め込まれています。例：if (userId === 42)、あるいは至る所に散らばった3000のタイムアウト。

AIスロップが通常の技術的負債より厄介な理由

人間が作る技術的負債はたいてい見えています。自分（あるいは同僚）が意図して手を抜いた場所なので、どこに雑なコードがあるか分かっています。AIスロップは3つの点でより厄介です。

第一に、完成しているように見えます。コードはきれいに整形され、docstringもあり、テストもある - 「品質の高いコード」の表面的なシグナルがすべて揃っているので、脳が警戒を緩めてしまいます。第二に、マシンのスケールで均一に広がります。人間はある一か所で雑になりますが、AIは一晩で40ファイルにわたって同じやり方で雑になります。第三に、チームが信頼するあらゆるチェックを通過します。Lintはグリーン、型もグリーン、テストもグリーン - なぜなら、そのテストも同じコードをなぞるようにAIが書いたからです。

気がかりな数字：CSET（Center for Security and Emerging Technology、「Cybersecurity Risks of AI-Generated Code」、2024年）の調査によると、AIが生成したスニペットのほぼ半数に、バグまたは悪用可能なセキュリティ脆弱性が含まれていました。言い換えれば、「動く」ことと「安全に出荷できる」ことは同じではないのです。

よくあるシナリオ：あなたが小さな機能の追加を頼むと、AIが「気を利かせて」もっともらしいパターンに沿って関連する3つのファイルをリファクタリングします。PRはグリーン、レビューは「ただのリファクタだから」とざっと流され、マージされます。3週間後、無関係に見えるモジュールで奇妙なバグが現れます - そのパターンが、共有されている関数の振る舞いをこっそり変えていたからです。あなたは半日かけて原因をたどり、たどり着いた根本原因は、ずっと前に紛れ込んだ無害そうなスロップの塊だった、というわけです。

結果として、AIスロップは従来の技術的負債より速く蓄積するのに、より巧妙に隠れます - 表面化する頃には、いくつもの層に染み込んでいます。しかもパターンで広がるため、一か所を直すだけでは足りないことがほとんどです。AIがばら撒いたコピーを一つ残らず探し出さなければなりません。

バイブコーディングでAIスロップを避けるチェックリスト

ここが核心です。漠然と「もっと厳しくレビューする」ではなく、バイブコーディングのループの4つの段階に分けて考えます。よければ印刷して、モニターの横に貼っておいてください。

プロンプトを書く前に

• プロンプトを打つ前に、明確な仕様／受け入れ基準を書きましょう。AIはあなたの心を読めません。空白を推測で埋めます - そして推測こそがスロップの生まれる場所です。
• 小さく、範囲を絞ったタスクを渡しましょう。一度に1つの関数、1つのエンドポイント - レビューしやすく、間違いにも気づきやすくなります。
• コンテキストを読み込ませる：コーディング規約、アーキテクチャ、既存のパターン、あなたのCLAUDE.mdファイル。薄いコンテキストこそ、スロップの最大の原因です。

コードを生成している間

• AIにリポジトリの規約に従う（命名、エラーハンドリング、構造）よう指示しましょう - プロンプトではっきり言葉にし、推測を期待しないこと。
• ハルシネーションと戦うために、すべてのAPI／パッケージ／設定を最新のドキュメントに照らして検証しましょう。見たことのない関数をAIが呼び出したら、証明されるまでは捏造だと考えてください。

マージする前に

• すべての行を読んで理解する。破ってはいけない鉄則：理解していないコードは決してリリースしない。ある行がなぜ存在するのか説明できないなら、それはまだ準備できていません。
• 「動くか？」だけでなく、ロジック＋契約＋アーキテクチャをレビューしましょう。AIのコードのレビューは、人間のコードのレビューとは別の仕事です - 詳しくはAIのコードを正しくレビューする方法をご覧ください。
• テストが、なぞっている実装ではなく期待される振る舞いを検証していることを確認しましょう。
• Lint／型／カバレッジをCIのゲートとして維持しましょう - ただし、CIがグリーンでもスロップがないことの証明にはならないと忘れずに。
• AIが追加したばかりの依存関係とライセンスを確認しましょう。

保守フェーズ

• 「スロップ・カタログ」を作りましょう：AIがあなたのリポジトリで作りがちなアンチパターンを記録し、それをプロンプトのテンプレートやCIのルールにフィードバックします。コードベースがAIに「教える」ほど、スロップは減っていきます。

このセクションの関連用語：AI code checklist、context engineering。どんなチェックリストもスロップを100%なくすことはできません - できるのは、確率と蓄積のスピードを下げることだけです。

実例：スロップの塊ひとつと、その修正

割引計算の関数で具体的に見てみましょう - 典型的な「正しく見えるのに間違っている」例です。これがAIの最初のアウトプットです：

// BEFORE - AI slop: looks right, wrong on several edge cases
function applyDiscount(price, discountPercent) {
 const finalPrice = price - (price * discountPercent / 100);
 return finalPrice.toFixed(2);
}

// applyDiscount(100, 20) -> "80.00" ✓ seems fine

サンプルテストは通るので、簡単にマージできてしまいます。しかし：(1) 数値ではなく文字列を返すため、他の場所の計算を壊します。(2) 負の値や > 100 の割引をブロックしません。(3) 金額の計算で浮動小数点の丸め誤差にぶつかります。(4) 不正な入力を扱いません。修正版がこちらです：

// AFTER - slop fixed: explicit contract, guarded edge cases
function applyDiscount(priceCents, discountPercent) {
 if (!Number.isInteger(priceCents) || priceCents < 0) {
 throw new Error('priceCents must be a non-negative integer (unit: cents)');
 }
 if (discountPercent < 0 || discountPercent > 100) {
 throw new Error('discountPercent must be within 0..100');
 }
 // Compute in cents (integers) to avoid floating-point rounding errors
 const discount = Math.round(priceCents * discountPercent / 100);
 return priceCents - discount; // returns a number (cents), not a string
}

ポイントは「修正版の方が長い」ということではありません。スロップ版が、整った見た目の裏に4つの誤った前提を隠していた、ということです。契約を理解するために読む - 戻り値の型、有効な値の範囲、金額の扱い方 - そのときになって初めて、スロップは正体を現します。だからこそ「動く」だけでは決して十分ではないのです。

コンテキストエンジニアリング - スロップを減らす根本

マージ後にスロップを直すのは高くつきます。コンテキストエンジニアリングで最初から食い止める方がはるかに安上がりです：AIが推測せずに済むよう、正しい材料を渡すのです。具体的には、コーディング規約、アーキテクチャの地図、リポジトリの既存パターン、そしてプロジェクトの規約を記した堅実なCLAUDE.mdファイル。仕組みをさらに深く知るには、コンテキストエンジニアリングそのものを一つのスキルとして扱ってください。

良いコンテキストは、AIを「入社初日の優秀な開発者」から「すでにコードベースを知っている開発者」へと変えます。同じモデルでも、アウトプットの品質はまるで違います - 純粋にコンテキストだけの差で。

チーム規模では、多くの人の間でコンテキストとプロセスの基準を一貫させるのは大変です。一つのやり方は、Claude Code向けのスキル・サブエージェント・標準ワークフローをまとめた既製のキットです - たとえば、Claude Code向けAgentKitキットは、レビュー規約・構造・パターンをチーム全体で共有できるようパッケージ化しており、コンテキストと基準が人によってばらつくのを防ぎます。直接見てみたいなら、AgentKitの価格を確認できます（リンク経由で20%オフ）。どんなツールもあなた自身の判断の代わりにはなりません - けれども、コンテキストを標準化することは、スロップを根本から減らす確かなテコになります。

「テイスト」 - AIには代替できないエンジニアリングの判断力

結局のところ、スロップの防止を100%自動化することはできません。実務家がテイストと呼ぶものが必要です：AIが生み出したものを、たとえ「動いて」いても、出荷しないべきときを見極める力です。テイストとは、あるコードの塊を見て、それが半年後にどこで痛みを生むかを見通す能力です。

コードを書くのはAIですが、コミットされたすべての行に責任を負うのは人間です。本番でバグが起きたとき、「でもAIがそう書いたので」は誰も受け入れてくれません。テイストは買うこともできず、プロンプトで生み出すこともできません - 実際に読み、実際に理解し、自分がマージするものを実際に自分ごととして引き受けることからしか生まれません。それが、バイブコーディングとバイブスロップを分ける一線です。

よくある質問（FAQ）

コードのAIスロップは、SNSのAIスロップとどう違うのですか？

SNSのAIスロップは、AIが大量生産するコンテンツ（動画・画像・記事）のこと - Merriam-Websterが「slop」を2025年の今年の言葉に選ぶきっかけとなった、一般的な意味です。AIコードスロップは低品質なAIコードのこと：コンパイルが通りテストにも合格するのに、構造的に浅くコードベースを腐らせます。この記事は2つ目の意味についてのものです。

バイブコーディングは必ずスロップを生みますか？

いいえ。バイブコーディングがスロップを生むのは、規律を欠いたときだけです：曖昧なプロンプト、読み込ませないコンテキスト、そして読んで理解していないコードのマージ。規律あるバイブコーディング - 明確な仕様、良質なコンテキスト、丁寧なレビュー - なら、品質を保ちながらAIのスピードを手に入れられます。

自分のAIコードにスロップがあるか、どう見分ければいいですか？

6つのサインを確認しましょう：正しく見えるのに端で間違う、過剰設計、リポジトリ規約の無視、存在しないAPI／パッケージのハルシネーション、実装をなぞるだけのテスト、そしてハードコードされたマジックナンバー。ある行がなぜ存在するのか説明できないなら、それはおそらくスロップです。

テストとLintがあればスロップを止められますか？

いいえ。Lintとテストは表面的なエラーを捕まえますが、スロップはしばしばすり抜けます - AIが書いたテストは、同じコードをなぞるだけになりうるからです。それでもなお、ロジックを読んで理解し、契約とアーキテクチャを人間の目で確認する必要があります。

スロップを減らすのに役立つツールやキットはありますか？

根本的な対策はコンテキストエンジニアリングです：CLAUDE.mdのようなファイルを通じて、コーディング規約・アーキテクチャ・パターンを読み込ませます。チーム規模では、Claude Code向けのスキル／サブエージェント／標準ワークフローの既製キットが、コンテキストと基準を一貫させるのに役立ちます。ただしツールはあくまで補助 - 最終的な判断は、やはりあなた自身のものです。

まだ理解していないAIコードを出荷すべきですか？

いいえ、絶対にダメです。これはスロップを避けるための破ってはいけない鉄則です：コードがなぜ動くのか理解していなければ、保守もできず、デバッグもできず、壊れたときに責任を負うこともできません。理解できるまで読み、それからマージしましょう。

結論：規律あるバイブコーディング

AIスロップは、AIを避ける理由ではありません - AIを規律をもって使う理由です。公式はシンプルです：AIのスピード＋人間のレビューの規律＝クリーンで速いコード。後半を捨てれば、あっという間にスロップになります。続けるには、バイブコーディングとは何かで基礎を振り返り、AIのコードを正しくレビューする方法で品質管理を磨いてください。コードを書くのはAI - テイストと責任は、今もあなたのものです。