LLM や AI コーディングエージェントの進化で、コードを書く速度は明らかに上がった。Claude Code や Codex CLI、Cursor のようなツールを使うと、Issue を渡してから動くコードが返ってくるまでの時間は、数年前とは別の桁になっている。
一方で、この速度は方向性が合っている場合にだけ恩恵になる。方向性が外れたまま AI を回す人は、同じ速度で「AI Slop」（AI が生成した、価値の低い大量のアウトプット）を量産する側に回ってしまう。この記事では、そういう働き方をしてしまう人を仮に AI Slopper と呼び、なぜ AI ネイティブ開発だけでこの落差が致命的になるのか、AI Slopper への依頼コストがどう跳ね上がるのかを整理する。
AI Slop と AI Slopper
AI Slop は、生成 AI で大量生産された、低品質・低価値なコンテンツを指す言葉として広まった。ニュース記事、SNS 投稿、画像、動画の文脈で語られることが多いが、ソフトウェア開発の文脈でも同じ現象が起きる。要件を満たしていない実装、テストが通ることだけを目的にした修正、動くけれど意図と噛み合っていないリファクタリング、そういったアウトプットが AI Slop のコード版である。
本記事では、プロジェクトやプロダクトの方向性を理解しないまま AI を活用して、無駄なコードやアウトプットを高速に生み出す人のことを AI Slopper と呼ぶ。悪意の話ではなく、方向性を掴めていない状態で AI の生産性だけを引き上げてしまった結果として、そうなってしまうという構造の話である。
従来型の開発と、AI ネイティブ開発でのズレの増幅の違い
方向性が外れたときに、従来型の開発と AI ネイティブな開発ではズレの増幅のされ方が違う。
従来型の開発では、実装の速度そのものが人間の手を動かす速度に律速されている。方向性が間違っていても、レビューでの指摘、ペアプロでの軌道修正、進捗確認時のディレクションといった介入が「まだ間に合う」タイミングで挟める。10 行書いたところで方向性がおかしいと気づけば、100 行書き直す前に止められる。ズレは線形にしか広がらない。
AI ネイティブな開発では、実装の速度が人間の手ではなくエージェントのループ速度で決まる。方向性が合っていない状態で走らせると、数分〜数十分で数百行、時には数千行のコードが生成される。しかもエージェントは、テストを通す、Lint を通す、CI を通すといった局所的なゴールを機械的に達成しようとするため、方向性のズレとは無関係に「完成度の高そうな見た目」で成果物が出てくる。ズレは実装量に比例して指数的に膨らむ。
図にすると次のような関係になる。
flowchart LR
subgraph Traditional[従来型の開発]
direction TB
T1[方向性ズレ] --> T2[人間が手で書く]
T2 --> T3["レビュー・ペアプロで<br>軌道修正"]
T3 --> T4[線形の手戻り]
end
subgraph AINative[AI ネイティブ開発]
direction TB
A1[方向性ズレ] --> A2["エージェントが<br>ループで生成"]
A2 --> A3["テスト・Lint・CI は<br>通ってしまう"]
A3 --> A4[指数的な手戻り]
end
Traditional ~~~ AINative
方向性のズレを検知するタイミングが、従来型では「実装中のどこか」だったのに対して、AI ネイティブでは「PR が積み上がってから」になりやすい。この検知タイミングの後ろ倒しが、AI Slopper の存在を可視化しにくくしている。
AI Slopper の症状
AI Slopper のアウトプットには、共通してよく見る症状がある。技術的なミスというよりは、方向性の理解不足がコードの形で現れているものが多い。
- 要件に書かれていない機能を勝手に足す、あるいは要件の一部を読み飛ばしたまま実装する
- 既存のコードベースにある同種の実装や共通コンポーネントを使わず、AI が書きやすい形で再発明する
- テストを、実装の正しさを保証するためではなく、CI を green にするためだけに書く（実装を反映しただけのテスト）
- レビューコメントに対して、根本原因ではなく「コメントを黙らせる差分」を返す
- 過剰な抽象化、過剰な設定オプション、過剰な defensive コード（YAGNI と DRY の使い分けができていない）
- 「なぜこの実装なのか」を聞くと、AI に渡したプロンプトの逐語再生しか返ってこない
- ドキュメント・README・コミットメッセージが冗長で、要点と経緯が読み取れない
いずれも、個別に見れば些細な問題に見える。しかし、これらが 1 つの PR に複数現れ、しかも高速に量産されると、レビュー側のコストは急速に肥大する。
依頼コストが自分でやるコストを上回る構造
AI Slopper に仕事を依頼したときに発生するコストを、依頼側の視点で分解してみる。
| コスト項目 | 従来型で仕事を依頼した場合 | AI Slopper に依頼した場合 |
|---|---|---|
| 依頼時のコンテキスト共有 | 中（口頭・ドキュメントで補完可能） | 大（AI に伝わる粒度まで分解が必要） |
| 途中経過のディレクション | 小〜中（レビュー・デイリースタンドアップ・チームミーティングで軌道修正できる） | 大（アウトプットが出るまで方向性のズレに気付けない） |
| 成果物のレビュー | 中（人間が書いた前提のレビュー） | 大（見た目の完成度と実質のギャップを見抜く必要がある） |
| 手戻りのやり直し | 中（部分修正で済むことが多い） | 大（前提が違うと全書き直しになりやすい） |
| コミュニケーション | 中 | 大（AI が生成した根拠の薄い主張への対応コストが加わる） |
AI ネイティブな環境では、依頼者自身が Claude Code や Codex に同じ指示を与えれば、多くの場合、AI Slopper に依頼するよりも短時間で妥当な成果物が出てくる。依頼者自身がプロダクトの方向性を持っているぶん、方向性のズレはそもそも発生しにくい。
つまり、AI Slopper に依頼したときのマネジメントコストが、依頼者が自分で AI を使うコストを上回った時点で、AI Slopper に回す仕事は経済合理的に消滅する。従来型の開発では、実装スピードそのものに希少性があったため、方向性の理解が薄くても「手が動くこと」だけで貢献できる余地があった。AI ネイティブな環境では、手が動くこと自体は AI が肩代わりするため、その希少性は消えている。
AI Slopper と、AI を使いこなす人の違い
同じ AI コーディングエージェントを使っていても、AI Slopper と AI を使いこなす人では、事前準備と停止条件の設計に明確な差が出る。
AI を使いこなす人は、AI に投げる前の段階で次のような整理をしている。
- 「なぜこの機能を作るのか」（Why）と「何を作らないか」を、AI 以前に自分の中で言語化している
- 既存のコードベース、共通コンポーネント、命名規則、テストパターンを事前に読み込ませる、あるいは Skill や AGENTS.md のような形で共有する
- 成功条件（テストが通る、受け入れ基準を満たす、実ブラウザで動く）を、機械的に判定できる形に落としてから走らせる
- 停止条件（証拠がなくなったら止まる、対象範囲を越えたら止まる、修正回数の上限で止まる）を明示する
- AI の出力を鵜呑みにせず、既存コードとの整合性・意図との一致・不要な複雑度がないかを、自分の頭で最終確認する
一方 AI Slopper は、これらの整理を AI に外部化しようとする。「良い感じにやって」「動くようにして」「エラーを直して」といった曖昧な指示で走らせ、返ってきたものをそのまま PR に載せる。方向性を持っていないぶん、AI の出力に対する評価軸を持てず、良い出力と悪い出力を区別できない。
差が生まれるのは AI のスキルではなく、プロダクトの理解と評価関数の設計である。
依頼される側にできること
AI Slopper にならないために、依頼される側でできることは意外と地味である。
- 実装に入る前に、目的・非目的・成功条件を自分の言葉で 1 回書く（AI に整形させる前に、自分の頭で書く）
- コードベースの主要な設計原則、命名規則、既存の共通コンポーネントを自分で読む（AI に要約させて済ませない）
- AI が生成した PR を、他人の PR としてレビューする視点で自分で先にレビューする
- 「なぜこの実装なのか」を、AI の出力ではなく自分の言葉で説明できる状態にしてからレビューに出す
- 分からないことは、AI に聞く前に、まず Issue の起票者や PM に聞く
ドメイン理解・プロダクトの方向性・既存コードベースへの敬意、この 3 つを AI 以前に自分の中に持てるかどうかが、同じ AI を使っていても最終的な生産性を分ける。
依頼する側にできること
依頼する側にも、AI Slopper を生み出さないためにできることがある。
- 目的・非目的・成功条件・停止条件を Issue に書く（口頭やチャットで済ませず、文字にする）
- 既存の類似機能・共通コンポーネント・参考実装への参照を Issue に含める
- 受け入れ基準を、テスト・ビルド・実挙動といった二値で判定できる形に落とす
- レビュー段階で、方向性のズレを見つけたら差分の修正ではなく「Issue の理解」から巻き戻す
- コンテキストを共有すべき AGENTS.md・Skill・ドキュメントを整備し、依頼のたびに個別に共有する運用を減らす
これらは AI ネイティブな開発に特有の要求ではなく、従来の開発でも本来必要なものである。ただし従来は、実装者自身が経験と勘で埋めていた曖昧さが、AI が実装者に入ってきた瞬間にそのまま AI Slop として顕在化する。人間だけの開発では隠れていたコミュニケーション負債が、AI ネイティブ開発では最短で表面化する、という言い方もできる。
それでも AI Slopper に依頼したくなる場面はあるか
現実には、あらゆる状況で依頼者自身が AI を使えるわけではない。依頼者の時間が完全に埋まっている、依頼者の専門領域外である、複数タスクを並列で回す必要があるといった状況では、誰かに委譲する必要がある。
ただし、その委譲先が AI Slopper であってはコストは下がらない。委譲先に求めるのは、AI を高速に回す能力ではなく、依頼者と同じレベルまでプロダクトの方向性を理解し、成功条件・停止条件を自分で設計できる能力である。この能力を持った人に委譲すれば、AI ネイティブ環境でのレバレッジは依頼者以上に効く。逆に、この能力を持たない人に AI を持たせても、依頼者のマネジメントコストを増やすだけで終わる。
まとめ
- LLM や AI コーディングエージェントは、方向性が合っている場合にだけ生産性を上げる
- 方向性を持たないまま AI を回すと、AI Slop を高速で量産する側（AI Slopper）になる
- 従来型の開発ではズレは線形、AI ネイティブ開発ではズレは指数で膨らむ
- AI Slopper に依頼するコストは、依頼者が自分で AI を使うコストを上回りやすく、経済合理的に仕事が消えていく
- 依頼される側は、プロダクトの理解と評価関数の設計を AI 以前に持つこと
- 依頼する側は、目的・非目的・成功条件・停止条件を Issue に文字で残すこと
AI コーディングエージェントの登場で、「手が動く」ことの希少性は下がり、「方向性を持てる」ことの希少性は上がった。同じ AI を使っても成果が分かれるのは、この一点で説明がつく。
以上、AI ネイティブ開発で方向性を持てない働き方（AI Slopper）が、なぜ経済合理的に仕事を失っていくのかを整理した、現場からお送りしました。