2026年1月26日、Andrej Karpathyがこんな言葉をXに投稿した。「2026年を、GitHubやSubstack、X、Instagram、あらゆるデジタルメディアにわたる『スロポカリプス』の年として覚悟している」。
スロポカリプス（Slopacolypse）。Slop（粗悪なコンテンツ）とApocalypse（終末）を組み合わせた造語だ。AIが大量生産する粗悪なコードやコンテンツが世界を覆う——そういう警告だ。
Karpathyは悲観的な人間ではない。同じポストの中で「AIの進歩はネットで大きなプラス」とも言っている。それでもなお、この警告を発したのには理由がある。
本人の80/20転換から始まった話
Karpathyのポストが刺さるのは、彼自身が「当事者」だからだ。
2025年11月時点のKarpathyのコーディングスタイル：手動80%、AIエージェント20%。それが2025年12月には逆転した。AIエージェント80%、手動での編集20%。
「20年以上のプログラミング経験が、数週間で覆った」。これがKarpathyの言葉だ。
彼はもはやプログラミング言語でコードを書かない。英語で書く。「ほぼ英語でプログラミングしている」という状況を自ら認めている。世界トップクラスの機械学習エンジニアがそう言っているのだ。
そこに問題も潜んでいる。AIに頼るようになってから、「手でコードを書く能力が徐々に萎縮し始めていることに気づいた」とも書いている。筋肉のようなものだ。使わないと落ちる。
Karpathyは「コードを生成する能力（書く）」と「コードを識別する能力（読む・理解する）」は別の脳の働きだと指摘している。AIに書かせ続けても、読んで判断する能力は別途鍛えなければ維持できない。
品質の現実：数字で見る
「AIが書いたコードは人間より品質が低い」というのは直感的にわかる話だが、実際にどのくらいの差があるのか。データが出ている。
CodeRabbitの調査
CodeRabbitは470のオープンソースPRを分析した。AIが書いたPRと人間が書いたPRを比べた結果がこうだ。
- AIのPRは平均10.83個の問題を含む。人間のPRは6.45個
- 差は1.7倍。AIが生む問題は人間の約2倍近い
カテゴリ別にみると差はさらに開く：
- 読みやすさ：AIは人間の3倍超の問題
- セキュリティ（不適切なパスワード処理など）：最大2.74倍
- パフォーマンス（過剰なI/O処理）：約8倍
- エラーハンドリング：約2倍
「AIのほうが速い」は事実だろう。しかし「AIのほうが品質が高い」は、少なくとも今は嘘だ。
Stack Overflow 2025 Developer Survey
Stack Overflow 2025年の開発者調査によると、AIツールを使う開発者は84%（前年76%から増加）に達した。一方で、AIの出力精度を信頼しないと答えた割合は46%（前年31%から大幅増加）。
使う人は増えているが、信頼は下がっている。
最大の不満は何か。45%の開発者が「AIの解決策がほぼ正しいが違う」ことのデバッグに時間がかかると答えている。VentureBeatの分析によると、66%の開発者が「ほぼ正しい」AIコードの修正に多くの時間を費やしていると回答した。
ここに本質的な問題がある。
「ほぼ正しい地図」が一番危ない
明らかに間違っている地図は使わない。でも「ほぼ正しい地図」は信用してしまう。だから迷う。
AIのコードも同じだ。完全に動かないコードなら捨てればいい。問題は「動くように見えるが、穴がある」コードだ。こちらのほうがずっと危険で、見つけにくい。
速射砲の比喩で考えるとわかりやすい。AIは毎秒100発撃てる。でも的中率が55%なら、45発は外れだ。弾の数が増えれば増えるほど、外れの数も増える。速さは正確さを補わない。
セキュリティ危機：45%が脆弱性を含む
品質の問題は、セキュリティの問題と直結している。
Veracode 2025 GenAI Code Security Reportは、100以上のLLMを対象に80の実際のコーディングタスクを分析した。結果：AIが生成したコードの45%に、OWASP Top 10（セキュリティの重大欠陥トップ10）に分類される脆弱性が含まれていた。
OWASP Top 10というのは、Webアプリケーションのセキュリティにおいて特に重大な問題のリストだ。SQLインジェクション（不正なデータベース操作）、XSS（他のユーザーへの攻撃）、認証の欠陥といった、プロが最も注意するカテゴリがここに入っている。
言語別の失敗率も出ている：
- Java：70%超のケースでセキュリティ欠陥を導入
- Python、C#、JavaScript：38〜45%の失敗率
特定の脆弱性タイプに絞るとさらに悪い数字が並ぶ：
- XSS（クロスサイトスクリプティング）：86%のサンプルで防御に失敗
- ログインジェクション：88%が脆弱
- SQLインジェクション：80%がパスと比較的よい成績だが、残り20%は依然リスクを抱える
Veracode CTOのJens Wesslingはこう述べている。「AIモデルは約半分のケースで誤った選択をしており、改善していない」。
新しいモデルや大きなモデルが、古いモデルより著しくセキュアなコードを生成するわけではない。Veracodeの調査では、モデルのサイズや新しさとセキュリティ性能の間に有意な相関は見られなかった。「最新モデルに切り替えれば安全」という考え方は根拠がない。
具体的にどういう問題が起きるのか、コード例で見てみよう。
AIが生成しがちなSQL脆弱性
# ❌ AIが生成しがちなSQLクエリ（インジェクション脆弱性あり）
query = f"SELECT * FROM users WHERE email = '{user_input}'"
cursor.execute(query)
# ✅ パラメータ化クエリ（インジェクション不可能）
query = "SELECT * FROM users WHERE email = ?"
cursor.execute(query, (user_input,))
上の例は「動く」。ユーザーが普通にメールアドレスを入力する限り、問題なく動作する。だから「完成した」と判断してしまう。しかし攻撃者が ' OR '1'='1 のような文字列を入力すると、データベース全体が操作できてしまう。
ログに機密情報を出力する問題
# ❌ AIが「デバッグのため」と生成しがちなログ
print(f"User logged in: email={email}, password={password}")
# ✅ 機密情報を含まないログ
print(f"User logged in: email={email}")
これも動く。ログが出力されるだけだ。しかしパスワードがサーバーのログに記録され続ける。ログ管理ツール、クラウドのログサービス、場合によってはエンジニアのターミナル画面に平文のパスワードが流れる。
AIはレビューする人間が「コードを読んで問題に気づく」というフィードバックループを経ていない。「動くかどうか」が主な評価基準になりやすく、「安全かどうか」は後回しになる。
生産性劇場
Karpathyは同じポストでもう一つの問題も指摘している。「AIハイプ生産性劇場（AI hype productivity theater）」という言葉だ。
AIを使っているように「見せる」パフォーマンスと、実際に生産性が上がることは別の話だ、という指摘だ。
コードの量が増えた。コミットの頻度が上がった。プルリクエストが速く出るようになった。これらは測定しやすいし、「AIで生産性が上がった」という証拠に使いやすい。
でも実際は何が起きているのか。コードレビューに時間がかかるようになった。「ほぼ正しいが違う」バグの修正に時間を取られるようになった。セキュリティの問題が後工程で発覚するようになった。これらは数字にしにくい。
速射砲で大量に撃ったからといって、的に当たった数が増えるとは限らない。
24%がAI生成、それでも「動いている」
現在、生産コードの24%がAIツールによって書かれた（米国では29%）という報告がある。
大量のAI生成コードが本番環境で動いている。そしてその45%には潜在的なセキュリティ上の問題があるかもしれない、ということだ。
「でも実際に被害は起きていないじゃないか」という反論もあるかもしれない。脆弱性は「あるかどうか」と「発見されて悪用されるかどうか」は別の話だ。家のドアに鍵がかかっていなくても、泥棒が来なければ被害はない。でもドアに鍵をかけない理由にはならない。
AIを使うな、ということではない
ここまで読んで「AIコーディングはやめたほうがいい」という結論になるなら、この記事は書き方を間違えている。
Karpathy自身が「net huge improvement（全体としては巨大なプラス）」とはっきり言っている。2025年12月にLLMエージェントの能力が「ある閾値を超えた」とも。実際に、Karpathyのコーディングスタイルは既に80%がAIエージェントになっている。
問題は「AIを使うかどうか」ではなく「AIが書いたコードをどう扱うか」だ。
品質を守る3つの習慣
AIとうまく付き合うために、今日から実践できることがある。
1. AIコードを「レビューする」文化を作る
AIが書いたコードは、承認を必要としないドラフトだ。完成品ではない。人間がレビューして初めて「コード」になる。
特に確認すべきは：入力値のバリデーション（検証）、認証・認可の処理、エラーメッセージの内容、ログに出力しているもの。これらはAIが特に「動くが危ない」コードを生成しやすい領域だ。
2. セキュリティ検証をワークフローに組み込む
手動レビューだけに頼らない。静的解析ツール（コードを実行せずに問題を検出するツール）をCI/CD（継続的インテグレーション/デリバリー）に組み込む。コードが変わるたびに自動でセキュリティチェックが走る状態を作る。
「後でやる」は来ない。ワークフローに最初から組み込んでしまうのが唯一確実な方法だ。
3. 「読む力」を意識して維持する
Karpathyが「筋肉の萎縮」と言っていたのは、生成の能力ではなく識別の能力だ。AIが書いたコードの問題を見つけるには、コードを読んで理解する能力が必要だ。
コードを書かなくなっても、読む習慣は維持したほうがいい。生成は委託できる。判断は委託できない。
速さと品質は別の軸
工場が自動化されて製品を大量生産できるようになったとき、品質管理ゼロでは欠陥品が増えるだけだった。自動化の恩恵を受けるために、品質管理という仕事が生まれた。
AIコーディングも同じ段階に来ている。「速く書ける」という恩恵を受けるために、「正しく検証する」という仕事が必要になっている。
スロポカリプスを回避するのは難しくない。AIが書いたコードを人間がレビューする。それだけだ。自動化の恩恵と品質管理の手間、両方を引き受ける覚悟があれば、スロポカリプスはただの警告で終わる。
