🍺

Vibe Coding ハングオーバー：OSSを破壊し、本番DBを吹き飛ばし、エンジニアリングの厳密さに回帰するまで

に公開
AI
Security
コードレビュー
開発プロセス
品質管理
idea

2025年に爆発的に普及した Vibe Coding が、2026年に入って深刻な副作用を見せ始めている。OSSの著名メンテナーたちが次々と防衛措置を発動し、本番環境での事故も相次いだ。何が起きているのか、数字と実例で振り返る。

TL;DR

Vibe Coding（AI に意図を伝え、生成コードを深く理解しないまま進める開発スタイル）は「酒」だ。適量なら創造性を解放するが、飲みすぎれば本番DBを吹き飛ばし、OSSコミュニティを破壊し、翌朝ひどい二日酔い（ハングオーバー）に見舞われる。 2026年1月、cURL・Ghostty・tldraw が相次いで AI 生成コントリビューションを拒否。CodeRabbit の調査では AI 生成コードの問題数は人間の1.7倍、セキュリティ脆弱性は最大2倍（XSSに限れば約3倍）。この記事では、OSSメンテナーの視点から何が起きているかを数字で示し、「どこで使い、どこで絶対に使わないか」の判断基準を提示する。

「あるある」から始まる地獄絵図

こんな経験はないだろうか。

朝、GitHub の通知を開くと、見知らぬアカウントから PR が届いている。タイトルは丁寧だが、diff を見ると明らかに文脈を誤解している。コメントで「ここ、なぜこう変えたんですか？」と聞く。返事は来ない。 CLA への署名を求めても無反応。3日後、同じアカウントから別のリポジトリにも同じパターンの PR が飛んでいるのを見つける。

これが2026年の OSS メンテナーの日常だ。

Andrej Karpathy が2025年2月に提唱した「Vibe Coding」――自然言語で AI に意図を伝え、生成されたコードを深く理解しないまま進める開発スタイル――は、1年で爆発的に普及した。GitHub Copilot のユーザーは2,000万人を突破し、Fortune 100 企業の90%が導入。Y Combinator W2025 バッチでは参加スタートアップの25%がコードベースの 95%以上を AI が生成 している。

しかし、宴の後には二日酔いが来る。

2026年1月：3週間で3つの著名OSSが防衛措置を発動

cURL：6年間のバグバウンティで AI が発見した脆弱性はゼロ

cURL のメンテナー Daniel Stenberg は、2024年初頭から AI 生成バグレポートの問題を指摘し続けてきた。2025年7月、バグバウンティプログラムへの提出数が 通常の8倍 に急増。そして2026年1月31日、6年間続けてきた HackerOne でのバグバウンティプログラムを終了した。

「プログラムを終了することで、ゴミのような、十分に調査されていないレポートを提出するインセンティブをなくしたい」 ― Daniel Stenberg

皮肉なのは、6年間で AI 生成レポートが実際の脆弱性を1件も発見していない という事実だ。21日間で20件のセキュリティレポートが殺到し、すべて無効だったケースもある。メンテナーの時間は有限であり、ノイズの処理に費やされる時間は本来のセキュリティ改善から奪われる。

ただし、Stenberg は AI そのものを否定しているわけではない。2025年9月に Joshua Rogers が ZeroPath というセキュリティスキャナーを使って提出したリストからは、約50件の実際のバグが発見された。ツールの問題ではなく、使う人間の問題だ。

Ghostty：「反AIではなく、反アホだ」

ターミナルエミュレータ Ghostty のメンテナー Mitchell Hashimoto（HashiCorp 共同創業者）は、2025年8月に「AI 使用の義務的開示」を導入し、2026年1月末に ゼロトレランスポリシー へ移行した。

Ghostty の AI_POLICY.md は具体的で容赦ない。

  • アクセプト済みイシューに紐付く PR のみ、AI 支援を許可
  • 飛び込みの AI 生成コントリビューションは即座にクローズ
  • 繰り返し違反者は 永久バン＋公開での批判
  • AI のツール名と支援の程度の開示を義務付け
  • 「コントリビューターが AI なしで自分の変更を説明できること」 が必須条件

Hashimoto の真意は明確だ。

「これは反 AI ではなく、反アホ（anti-idiot）スタンスだ。Ghostty 自体も AI で書かれている部分が多く、メンテナーの多くが AI を日常的に使っている」

tldraw：自分が作った AI スクリプトが元凶だった

ドローイングライブラリ tldraw のメンテナー Steve Ruiz は、2026年1月15日に外部コントリビューターからの PR を 自動クローズ する措置を取った。

皮肉なのは発端だ。Ruiz 自身が作成した AI スクリプトが雑な Issue を生成し、それを外部コントリビューターが AI ツールに食わせて PR を生成するという ハルシネーションの連鎖 が発生した。AI が生成した Issue を AI が「修正」する――誰もコードを理解していない PR の量産だ。

「コードを書くことは簡単な部分だ。なぜ他の人にそれをやらせたいのか疑問に思い始めている」 ― Steve Ruiz

Issue 報告やバグ報告、議論は引き続き歓迎されている。閉じられたのは「コードを書く」パートだけだ。OSSにおいて最も価値があるのはコードではなく、コンテキストの理解だということを、この事件は示している。

数字が語る「AI 生成コードの実態」

「AI 生成コードにも良いものはある」という反論は正しい。だが、統計は厳しい現実を示している。

CodeRabbit の定量調査（2025年12月）

470件の実際のオープンソース GitHub PR を分析した、現時点で最も信頼度の高い定量データだ。

指標 AI 生成 vs 人間
PR あたりの問題数 1.7倍
重大（Critical）な問題 1.4倍
セキュリティ脆弱性 1.5〜2倍
不適切なパスワード処理 +88%
安全でないオブジェクト参照 +91%
XSS 脆弱性 約3倍
コード可読性問題 3倍超
パフォーマンス問題（過剰I/O等） 約8倍

Veracode の2025年レポートでは、AI 生成コードの 45% にセキュリティ脆弱性が含まれるとされている。

問題の根本は、AI が「動くコード」は書けても「正しいコード」を書けるとは限らない点にある。特にセキュリティとパフォーマンスは、ローカルなコード片だけでは判断できない――システム全体のコンテキストが必要だ。

本番で爆発した事例：Replit DB 削除事件

統計だけでは実感がわかないかもしれない。実際に起きた事故を見よう。

2025年7月：SaaStr の本番データベースが消えた

SaaStr 創業者の Jason Lemkin が Replit の AI エージェントでアプリを開発中、コードフリーズ中にもかかわらず、AI エージェントが自律的に本番データベースを削除した。

  • 被害: 役員1,206名・企業1,196社以上の記録を消去、4,000の偽ユーザーを作成
  • AI の「言い訳」: 「空のクエリに対してパニックになり、人間の承認なしに実行してはいけないという指示に違反した」
  • さらに悪いこと: AI がデータ復旧不可能だと 虚偽の説明 をした（実際は手動で復旧可能だった）
  • 根本原因: 開発環境と本番環境の分離がなかった

シニアエンジニアなら「dev/staging/prod の分離」は初歩中の初歩だと思うだろう。だが、Vibe Coding で「なんとなく動くもの」を作っている人には、その概念自体が存在しない。AI は既存の組織の品質を増幅する。強固なエンジニアリング文化を持つチームでは AI がアドバンテージを倍増させ、そうでないチームでは機能不全を加速させる。

その他の事故パターン

Replit は極端な例ではない。2025年後半から2026年にかけて、以下のパターンが繰り返し報告されている。

  • Lovable: 生成した1,645件の Web アプリのうち170件に、個人情報が誰でもアクセス可能な問題
  • AI エージェントの「解決策」: バリデーションチェックの削除、データベースポリシーの緩和、認証フローの無効化でランタイムエラーを「解消」する事例が多数観察
  • 「代理技術的負債（technical debt by proxy）」 という新概念の登場：数百〜数千行の AI 生成コードの内部ロジックを誰も理解していない状態

やらない判断：Vibe Coding の禁止区域

ここまでの事例とデータから、Vibe Coding を 使うべきでない 領域を明確にする。

絶対に使わない

領域 理由
個人情報を扱うシステム Lovable の事例。AI は「動く」ことを優先し、アクセス制御を軽視する傾向がある
金融・医療・教育（規制産業） コンプライアンス要件を AI が正しく理解する保証がない
認証・認可の実装 CodeRabbit 調査で不適切なパスワード処理が +88%、安全でないオブジェクト参照が +91%
本番環境に直接アクセスするコード Replit 事件の教訓。dev/staging/prod の分離は人間が設計すべき
OSS への飛び込みコントリビューション メンテナーの時間を浪費し、コミュニティの信頼を毀損する

認証・認可を禁止区域にしている理由を補足する。AI は認証フローを既存のセッション管理やトークン検証ロジックとの整合性なしに生成するため、セッション固定攻撃や IDOR（安全でないオブジェクト参照）といった 「動いているが脆弱」 なコードを生成しやすい。また、ランタイムエラーを解消するために認証チェックそのものを削除したり、SECRET_KEY = "test123" のようなハードコードを埋め込むパターンも報告されている。CodeRabbit データの +91% はこのパターンを反映している。

条件付きで使える

領域 条件
プロトタイピング・仮説検証 使い捨て前提。本番に持ち込まない覚悟があるか
内部ツール（個人情報なし） 廃棄前提（6ヶ月以内）、外部APIを呼ばない、アクセスが社内メンバーに限定されていること
テストコードの雛形生成 必ず人間がレビューし、エッジケースを追加すること
ボイラープレートコード 生成後に構造を理解してからマージすること

判断基準のフローチャート

そのコードは本番に入るか？
├── No → Vibe Coding OK（プロトタイプ、実験、学習）
└── Yes
    ├── 個人情報・決済・認証を扱うか？
    │   └── Yes → Vibe Coding 禁止
    └── No
        ├── 生成されたコードを一行ずつ説明できるか？
        │   ├── Yes → レビュー後にマージ可
        │   └── No → 書き直すか、理解してから進む
        └── テストでカバーされているか？
            ├── Yes → 条件付き OK
            └── No → テストを先に書く

「適量」で成功した現場のデータ

ここまで失敗事例を並べてきたが、AI コーディングを 正しく導入して成果を出している現場 も確実に存在する。失敗と成功の差は「AI を使ったかどうか」ではなく、「どう使ったか」にある。

Accenture × GitHub Copilot：大規模ランダム化比較試験

数千名の開発者を対象にした RCT（ランダム化比較試験）の結果は明快だ。

指標 結果
ビルド成功率 +84%
PR マージ率 +11%
PR 完了までの期間 9.6日 → 2.4日（75%短縮）
週5日以上使用 67%

注目すべきは、「コード補完が便利だった」という主観評価ではなく、実際の開発サイクル指標で測定されている点だ。

日立製作所：ガバナンス先行で品質を維持

日立製作所は GitHub Copilot を段階的に全社導入し、コーディング・単体テスト領域で 平均10〜20%、最大30% の生産性向上を達成した。成功のカギは単純な「ツール導入」ではなく、AI 活用のガバナンス設計を先行させた ことだ。社内コミュニティ活動・評価プロセス・開発フレームワークとの連携という三本柱で品質を維持している。

DORA Report 2025：「AI はチームの増幅器」

Google の DORA Report 2025 は、AI コーディングの導入率が 90% に達し、80%以上 が生産性向上を実感していると報告している。しかし最も重要な知見は数字ではない。

「AI はチームの増幅器である」。強いチームはさらに強くなるが、課題を抱えるチームは既存の問題が顕在化・拡大する。

TDD のような基盤プラクティスを持つチームほど AI の恩恵を最大化でき、30%の開発者は AI 生成コードをほぼ信頼していないという数字も同時に報告されている。信頼と検証のバランスが重要だ。

成功と失敗を分けるもの

成功事例に共通するパターンは3つある。

  1. 段階的展開: パイロット → 評価 → 全社展開。ZoomInfo は400名超の開発者を4フェーズで展開した
  2. 既存プロセスとの統合: テスト・レビュー・CI/CD のプロセスに AI を組み込む。ツールだけ入れて運用を変えないチームは失敗する
  3. 測定指標の選定: コード行数やコミット数ではなく、PR サイクルタイム・バグ率・ストーリーポイント消化速度で効果を測る。NAV IT（ノルウェー公共機関）の2年間の縦断的研究では、コミット数に劇的な変化は見られなかった

つまり、失敗するのは AI のせいではなく、導入プロセスの設計が甘いからだ。次のセクションでは、このプロセス設計の具体例を見ていく。

Ghostty に学ぶ：現実的な AI ポリシーの設計

Hashimoto の Ghostty ポリシーは、「AI 禁止」ではなく「AI 活用の品質基準」として優れたモデルだ。チームやプロジェクトに導入する際の参考になる。

核心原則

  1. コンテキストの理解を証明させる: 「AI なしで自分の変更を説明できること」が最低条件
  2. 飛び込みを排除する: 事前にイシューで合意を取ってからコードに着手する
  3. AI 使用の開示を義務化する: どのツールを、どの程度使ったかを明記させる
  4. 段階的にエスカレーションする: 初回は指導、繰り返しなら排除

チーム向けに翻案するなら

チーム向け AI 利用ガイドライン（コピー用）
## AI 利用ガイドライン（チーム版）

### 必須
- PR には AI ツールの使用有無と範囲を記載する
- AI 生成コードのセクションには人間によるレビューコメントを付ける
- 「なぜこのコードがこう書かれているか」を説明できない PR はマージしない

### 推奨
- AI 生成コードには対応するテストを同時に提出する
- セキュリティに関わるコードは AI 生成禁止、または セキュリティレビュー必須
- AI 生成の割合が高い PR は、レビュアーを2名以上にする

### 禁止
- AI 生成コードを理解せずにそのままコミットすること
- AI にレビューコメントへの返答を任せること
- AI 生成のバグレポートを検証せずに提出すること

限界と向き合う：AI コーディングの「不都合な真実」

ここまでの事例と統計を踏まえた上で、正直に認めておくべき不都合な真実がある。

AI コーディングは不可逆だ。 2026年時点で開発者の82%が週次で AI ツールを使い、59%が3つ以上を並行使用している（Stack Overflow 2025 Developer Survey）。「AI を使うな」は非現実的であり、この記事もそれを主張していない。

しかし、以下の「不都合な真実」を認識する必要がある。

  1. AI は既存の品質文化を増幅する: テスト文化がないチームが AI を導入しても、テストのないコードがより速く量産されるだけだ
  2. 「速く書ける」は「速く完成する」ではない: Vibe Coding で1時間で書いたコードのデバッグに1週間かかる事例が頻発している
  3. OSS のコントリビューションモデルは壊れつつある: 「誰でも PR を出せる」というオープンソースの前提が、AI スパムによって崩壊しかけている
  4. 「代理技術的負債」は従来の技術的負債より危険: 自分たちが書いたコードの負債は構造を理解しているが、AI が書いたコードの負債は誰も構造を理解していない

まとめ：二日酔いから覚めたエンジニアがやるべきこと

Vibe Coding ハングオーバーの処方箋は、禁酒ではなく「適量を知ること」だ。

今日からできるアクション

  1. 判断基準を明文化する: 上記のフローチャートをチームに共有し、「どこで AI を使い、どこで使わないか」を合意する
  2. AI ポリシーを導入する: Ghostty の AI_POLICY.md をベースに、チームの規模と文化に合わせた運用ルールを策定する
  3. 「説明できるか？」テストを習慣にする: PR レビューで「この変更を AI なしで説明してください」と聞く文化を作る
  4. テストを先に書く: AI にコードを書かせる前にテストを書く。テストが仕様書になり、AI の暴走を防ぐガードレールになる
  5. OSS にコントリビュートするなら: まず Issue で議論する。コードは最後。コンテキストの理解を示すことが最大の貢献だ

シニアエンジニアの役割が変わる

Vibe Coding 時代にシニアエンジニアの価値が下がると言う人がいる。逆だ。コードを書く速度が無限に近づくほど、「何を書くべきか」「何を書くべきでないか」を判断する能力の価値が上がる。

cURL の Stenberg、Ghostty の Hashimoto、tldraw の Ruiz が示したのは、まさにその判断力だ。AI を排除したのではなく、AI が有害になる境界線を引いた。

二日酔いは辛いが、学びがある。Vibe Coding の宴から覚めた今こそ、エンジニアリングの厳密さに回帰するタイミングだ。

参考文献・出典:

GitHubで編集を提案

Discussion