「後方互換性のために旧実装を残します」。AI に書かせたコードで、こういう差分を見た人は多いはずです。呼び出し元を調べると誰も使っていない。互換性の要件も確認されていない。それでも旧実装は残ります。

これは単発の癖ではなく、AI が生成するコードに広く見られるパターンの一種です。

AIコーディング slop とは

slop はもともと家畜に与える残飯を指す俗語で、転じて生成 AI が量産する「それらしく見えるが質の低い出力」を指します。コードに限って定義すると、こうなります。

一応動作し、見た目も整っているが、コードベース全体の設計・制約・将来の変更を十分に理解せずに生成され、保守と検証のコストを他者に転嫁するコード。

単に「バグの多いコード」とは違います。局所的には正しそうなのに、全体としては劣化を積み重ねるのが特徴です。だから一目では弾けません。

開発者の体感もこれと一致しています。Stack Overflow の 2025 年開発者調査で、AI に対する最大の不満として挙がったのは「ほぼ正しいが、微妙に違う解」で 66%。次点が「AI 生成コードのデバッグに時間がかかる」で 45% でした。明確に間違っていれば捨てられます。厄介なのは、正しさの判定に時間がかかる出力のほうです。

以下、代表的な症状を4つの軸に整理します。

軸1: 消せないから足す

もっとも典型的なのが、既存コードに手を入れず、横に新しいコードを足していく振る舞いです。

// 後方互換性のため維持
export function oldCalculatePrice(...) { ... }

// 新しい実装
export function calculatePriceV2(...) { ... }

同じ症状は、いくつもの形で現れます。

  • formatDate / formatDateNew / formatDateSafe / formatDateForDisplay と、タスクごとに関数が増えていく
  • 一度しか使わない処理まで関数・hook・helper に切り出され、ファイル数と識別子だけが増える
  • 逆に、小さな追加を続けた結果、一つの関数やサービスに検証・認証・DB アクセス・整形・通知が全部詰まる

一見すると方向が逆の症状ですが、原理は同じです。既存の構造を組み替えるより、いまある場所に足すほうが失敗しにくい。既存関数を一般化することは呼び出し元すべてを壊すリスクを伴いますが、隣に新しい関数を置くことは何も壊しません。

この傾向は実測にも出ています。GitClear が 2023〜2026 年の 6.23 億件のコード変更を分析した結果では、リファクタリングに相当するコード移動が 21%(2022年)から 3.8%(2026年)へ 70% 減少、他ファイルの関数を呼ぶ回数——コード再利用の代理指標——が 35% 減少 しました。一方でコミット内のコピペは 41% 増、5行以上の連続重複は 81% 増えています。

軸2: 失敗を隠す

2つめの軸は、異常時の設計判断そのものを回避する振る舞いです。

try {
  return await primaryMethod();
} catch {
  try {
    return await fallbackMethod();
  } catch {
    return defaultValue;
  }
}

堅牢に見えます。しかし primaryMethod がその例外を投げない、fallback が本番環境では利用不能、というケースが混じります。実際に起きるのは、障害の解決ではなく障害の隠蔽です。DB 保存に失敗したのに成功レスポンスを返す。認証エラーが「データなし」として扱われる。外部 API の障害が空配列に変換される。

同じ軸に、実行されない防御分岐も入ります。

if (!user) {
  return null;
}

型定義上 user が必ず存在するなら、このチェックは安全性を足していません。むしろ、型設計の意味を曖昧にし、不正な状態の早期検知を潰し、本来エラーにすべき状態を正常系として通します。

「堅牢にしてください」という指示に対して、AI は観測可能性や障害ポリシーを設計するのではなく、catch と null チェックを増やす方向に倒れます。安全そうな形式を、必要性を検証せずに模倣するわけです。

この軸も数字で裏付けられています。前述の GitClear 調査では、エラーを覆い隠す構文が前年比 47% 増加 していました。

軸3: 「安全に見える」を生成する

3つめは、レビューの印象を最適化してしまう振る舞いです。

まず、テストを通すために本体コードのほうを変える。

// テストを通すため追加
if (process.env.NODE_ENV === "test") {
  return mockResult;
}

本来はテスト側の前提が間違っているのに、AI は「テストを通す」という明確な報酬を優先し、テストが仕様を正しく表現しているかを疑いません。

次に、検証していないテスト。

it("should call service", async () => {
  await handler(mockRequest);
  expect(service).toHaveBeenCalled();
});

戻り値も、状態変化も、副作用も、エラー処理も確認していません。expect(result).toBeDefined() や、全依存を mock したために何も検証していないテスト、スナップショットを更新しただけのテストも同類です。カバレッジの数字だけが上がります。

そして、コメントによる自己正当化。

// Ensure backward compatibility
// Handle edge cases
// Safely process the response

コメントが「何をしているか」ではなく「このコードは安全である」と宣言しています。安全性が検証されていなくても、レビュー時の印象は良くなります。

この軸が厄介なのは、すべてがレビューを通りやすくする方向に働く点です。テストは緑、カバレッジは高い、コメントは丁寧。品質のシグナルとして使ってきた指標が、そのまま偽装できてしまいます。

軸4: 文脈がないまま形だけ揃える

4つめは、コードベースやエコシステムの文脈を持たないことから生じる症状です。

  • 形式的な抽象化 — interface UserData → UserInfo → UserResponse → UserResponseData と型が積み上がる。「保守しやすく」「型安全に」という指示が、interface・DTO・mapper を増やす形式的なパターンとして解釈されます。これは抽象化ではなく間接化です。
  • ライブラリの再発明 — JWT のパース、HTML サニタイズ、リトライ処理を自前で書く。認証・暗号・日時・SQL エスケープなど、車輪の再発明が事故に直結する領域ほど危険です。
  • 実在しない API・オプション — 存在しないオプション名を渡す。社内ライブラリや、新旧バージョンが混在する環境で起きやすい問題です。
  • 環境依存の見落とし — ローカルの絶対パス、タイムゾーン固定、単一プロセス前提のメモリキャッシュ、サーバーレス環境で永続ディスクを使う。
  • プロンプト語彙の写像 — 「安全に」「柔軟に」「拡張可能に」と指示すると SafeFlexibleExtensibleUserProcessor のような名前や、過剰な Strategy・Factory が生成されます。要件を理解した設計ではなく、指示の語彙をコード構造に写しただけです。

実害としての slopsquatting

軸4の「実在しない API」は、書き直せば済む話にとどまらない領域につながっています。slopsquatting ——AI が幻覚した存在しないパッケージ名を、攻撃者が先回りして取得しておく手口です。slop と typosquatting を合わせた造語です。

パッケージ名の幻覚率は、オープンソースモデルで平均 21.7%、商用モデルで平均 5.2%。最良の部類でも 3.59% は幻覚します。数パーセントでも、生成量が増えれば十分に狙える規模になります。実際、eslint-plugin-unused-imports の代わりに AI が提案しがちな unused-imports という悪性パッケージが公開され、2026年2月時点で週 233 ダウンロードを記録していました。

防御は依存の入口に置きます。lockfile の pin と hash 検証を CI で強制し、エージェントにパッケージを無審査でインストールさせない。allowlist と人間の承認を挟むのが基本です。

根っこにあるのは「削除の証明ができない」こと

4つの軸は、別々の癖ではありません。共通する制約があります。

コードを削除するには、次を確かめる必要があります。

  • 呼び出し元が存在しない
  • 外部から利用されていない
  • 動的に参照されていない
  • 過去バージョンとの契約が残っていない

これらは、コードベース全体と、その運用履歴と、外部の利用者を知らなければ証明できません。コンテキストが足りない状態では、削除は証明を必要とするが、追加は必要としない。だから追加に倒れます。

同じ非対称性が、他の軸にも効いています。エラーを握り潰すのは、どこで失敗させるべきかを決めるにはシステム全体の障害ポリシーが要るからです。コピペするのは、共通化すべきかどうかの判断に他の呼び出し元の知識が要るからです。形式的な interface が増えるのは、本当の抽象化には「何が変わりやすく何が変わりにくいか」の予測が要るからです。

つまり slop の本質は、コードが雑であることではありません。

「消す・統合する・境界を決める・異常時に失敗させる」という、全体を見なければ下せない設計判断を回避し、追加によって問題を解決し続けること。

局所的な正しさだけを最適化すれば、必然的にこうなります。

コストは誰が払っているのか

定義に含めた「他者に転嫁する」という部分も、実証データが出はじめています。

GitHub の人気リポジトリで、AI エージェントが作成したファイルと人間が書いたファイルを各 508 件、6か月追跡した研究では、AI 生成ファイルへの保守作業のうち 83% を人間が実施し、AI エージェントの寄与は 17% でした。コミットの内訳も偏っていて、AI 生成ファイルでは機能追加が 21.78% に対し bug fix は 11.73%。人間のコードでは fix(16.76%)とドキュメント(16.22%)が主です。書くのは AI、直すのは人間という分担になっています。

生成されたメソッドの 9.9% はレビュー中に削除されます。これは純粋にレビュアーの認知負荷としてのみ消費されるコストです。

もう少し広い調査もあります。6,275 リポジトリの AI 作成コミット 30.4 万件(2024年1月〜2025年10月)を静的解析にかけた研究では、検出された 48.4 万件の問題のうち 89.1% がコードスメル、runtime bug が 5.8%、security が 5.1%。どのツールでも 15% 超のコミットが 1つ以上の問題を混入させ(Copilot 17.3%、Gemini 28.7%)、混入した問題の 24.2% は最新リビジョンでも未解決のまま生き残っていました。

転嫁先は、自分のチームの外にも及びます。OSS プロジェクトでは低品質な AI 生成 PR の急増が報告されていて、Ghostty・curl・GNOME といったプロジェクトがコントリビューションガイドの厳格化やフィルタ導入といった防衛策を取っています。無償のメンテナが、他人の生成物のトリアージに時間を使う構図です。

組織レベルでは、DORA の 2025 年調査が同じ現象を別の角度から捉えています。AI 導入はデリバリのスループットと正の相関を示す一方、テスト・レビュー・QA という下流のボトルネックを露出させ、不安定性——変更失敗・手戻り・解決までの時間——の増加とも相関していました。リードタイムが 60〜70% 改善した一方で、そのうちレビューに費やす割合が 20% から 50% 超に増えた、という報告もあります。生成が速くなっても、律速段階が人間のレビューに移るだけなら、全体は速くなりません。

数字の読み方には留保がいる

ここまで数字を並べましたが、扱いには注意が要ります。

GitClear の調査は相関であって因果ではありません。 AI 普及期にコード品質指標が悪化した、という観測データです。同時期には開発チームの構成やリモートワークの定着など、他の変化も起きています。加えて同社はコード品質分析ツールのベンダーであり、利害関係があります。

METR の「19% スローダウン」は引用すべきではありません。 経験豊富な開発者が AI 利用時に 19% 遅くなったという 2025 年のランダム化比較試験は有名ですが、METR 自身が 2026年2月に方法論の問題を認めています。AI を手放したくない開発者が参加を拒否する選択バイアス、時給を $150 から $50 に下げたことによる追加のバイアス、AI で速く終わるタスクを開発者の 30〜50% が提出回避していたこと、複数エージェント併用で時間計測が成立しなくなったこと。改訂後の推定は元の被験者で -18%(信頼区間 -38%〜+9%)、新規被験者で -4%(同 -15%〜+9%)で、信頼区間がゼロをまたいでいます。AI が開発を遅くする証拠としては使えません。

そして、AI 生成コードが常に人間のコードより悪いわけでもありません。単純な課題では AI コードのほうがバグや修正工数が少なかったという研究もあります。差が開くのは、複雑な課題や、オブジェクト指向的な設計判断を含む課題です。

問題は AI を使うこと自体ではなく、全体設計を必要とする場面でも局所生成を繰り返すことにあります。

PR で疑うべきシグナル

理屈が分かれば、レビューで見る場所も決まります。次の語や構造が増えていたら、根拠を確認する価値があります。

シグナル 疑うべき問題
legacy, old, v2, compat 旧実装の不要な温存
fallback, safe, graceful エラー隠蔽
「念のため」「将来の拡張性」 仮想要件への過剰対応
似た関数が複数ある コピペ・共通化不足
interface や DTO が急増 形式的な抽象化
コメントが処理内容を逐語説明 自己説明的でないコード
catch 後に空配列・null を返す 障害の正常化
テストの mock が多すぎる 偽のテストカバレッジ
未使用 export が増える 削除回避
自前の認証・日時・リトライ処理 ライブラリの再発明
見慣れないパッケージが追加された 幻覚パッケージ
1つの PR が異常に大きい レビュー不能化

ただし、有効な対策はレビュアーの注意力を増やすことではありません。AI が下せない判断——削除・統合・境界の設定——を人間が明示的に引き受けることです。「この関数は消してよい」と調べた結果を渡せば、AI は消せます。判断材料を渡さずに「きれいにして」と頼めば、また足されます。

なお、生成物をそのままレビューに流すことがチームの信頼構造に何をするかは、別の記事「レビューは信頼で回っている」で扱いました。

まとめ

  • AIコーディング slop とは、局所的には正しそうに見えるが、全体設計を理解せずに生成され、保守と検証のコストを他者に転嫁するコード。
  • 症状は4軸に整理できる。消せないから足す/失敗を隠す/「安全に見える」を生成する/文脈がないまま形だけ揃える。
  • 根っこは共通で、削除・統合・境界設定・失敗設計はいずれも全体を知らなければ下せない判断だから回避され、追加だけが残る。
  • コストは実測できる。AI 生成ファイルの保守の 83% は人間が担い、混入した問題の 24.2% は未解決のまま残り、負荷は OSS メンテナやレビュー工程へ流れる。
  • ただし数字には留保がいる。GitClear は相関、METR の 19% スローダウンは著者自身が撤回済み、単純な課題では AI コードのほうが良い場合もある。
  • 対策はレビューの厳格化ではなく、AI が下せない判断を人間が明示的に引き受けること。

出典