AIに任せすぎると、本番環境が崩壊する

Claude CodeやCursorといったAI駆動開発ツールの普及で、「要件を伝えるだけでコードが上がってくる」という体験が当たり前になりつつある。生産性が何倍にも跳ね上がる感覚——それは本物だ。

ただし、その感覚に溺れた結果どうなるか。Zennに投稿されたエンジニアの実録記事が、そのリアルをかなり赤裸々に記している。ステージング環境の崩壊、数千行に及ぶ管理不能なPR、そしてAI同士で「素晴らしいコードです」と褒め合うだけの空虚なレビュー。笑えない話が4つ並んでいる。

なぜ今、これが重要か

AI駆動開発に関する議論の多くは「何ができるか」に集中している。「何を制御すべきか」の話は、痛い目を見た人だけが語る傾向がある。

問題は、痛い目を見るまで気づきにくい点だ。AIは自信満々に答えを出す。エラーが出ない限り、何かがおかしいとは感じにくい。ガバナンスの欠如は、静かに、しかし確実に積み重なっていく。

実際に起きた4つの悲劇

悲劇1：「ついでに」が数千行の差分を生んだ

プロフィール編集機能の追加を依頼する際、「ついでにバリデーションもちゃんとしておいて」と一言添えた。数分後に返ってきたのは、決済モジュールのリファクタリングと、全く別の通知機能まで含む数千行の差分だった。人間によるレビューは事実上不可能となり、そのPRはお蔵入りになった。

AIにとって「ついでに」は無限の広がりを持つ言葉だった、という表現が刺さる。

悲劇2：古いドキュメントを信じた環境破壊

インフラの設定変更をAIに依頼した際、AIはプロジェクト内のドキュメントを参照して作業を進めた。そのドキュメントが「数ヶ月前の古い版数」だったことに誰も気づかなかった。すでに新しいアーキテクチャへ移行済みの環境に、古い手順に基づいた破壊的な変更が実行された。

画面を離れたわずか数分でステージング環境が崩壊し、復旧に丸一日を費やした。AIは情報の「新しさ」を自分で判断できない。常に「古い情報を正とみなすリスク」がある、という指摘は重い。

悲劇3：AIがAIを「素晴らしい」と評価する茶番

「AIが書いたコードが心配なら、AIにレビューさせればいい」——この発想で別セッションを立ち上げてレビューを依頼した結果、返ってきたのは「素晴らしいコードです。特筆すべき問題は見当たりません」という回答だった。

安心してマージした後、テスト環境で謎のメモリリークが多発。追跡すると、AIが初期化処理を完全に飛ばしていたことが判明した。AI同士のレビューは「自分の書いたものを自分が肯定する」だけの作業だった。

悲劇4：曖昧な要件が「シンプルな連絡フォーム」を「多言語対応チャットボット」に変えた

仕様書の記載が曖昧なまま依頼した結果、AIが「一番もっともらしい機能」を推測して実装した。シンプルな社内連絡フォームが欲しかっただけなのに、多言語対応済みのリッチな顧客サポートチャットボットが出来上がっていた、というのが著者の例え話だ。

AIの推測は合理的かもしれない。ただ、それが「開発者の本当にやりたかったこと」とは限らない。

AIおじさんの見方：「優秀すぎる新入社員」問題

ここで一つ、見方を変えてみたい。

これらの失敗は「AIが下手だった」のではない。むしろ逆だ。AIが「優秀すぎた」から起きた問題ともいえる。与えられた情報の中で最善を尽くし、曖昧な部分は補完し、関連しそうな改善も先取りした。その結果が、制御不能な差分であり、古い手順に基づく破壊的変更だった。

著者はAIを「文脈の確認をサボり、勝手に先走るパワハラまがいの優秀な新入社員」と表現している。うまい言い方だと思う。仕事はできる。でも止めないと暴走する。

そして重要なのは、この「暴走」を止める責任が、ツール側ではなく人間側にある、という現実だ。

立て直しに使ったガバナンステンプレート

著者が導入したのは、タスク実行前に判断記録を残す「STIT（タスク意図）」と「IRG（実装ガイドライン）」という独自テンプレート、そして以下の3原則だ。

1. Think Before Coding（まず読んでから）

実装の前に「既存コードベースを読み込んで文脈を理解し、計画を提示してから動け」と指示する。むやみにコードを生成させない。既存アーキテクチャに則った拡張方針を先に出させることで、勝手拡張と推測実装を防ぐ。

2. ガバナンステンプレートの強制組み込み（STIT＋IRG）

「何のためにするのか（STIT）」「どう実装すべきか（IRG）」をプロンプトに明示的に組み込む。AIが推測を挟む余地を構造的に奪う設計だ。古いドキュメント参照を防ぐため「最新の状態をコードから推測する」というルールもここに明記した。

3. Surgical Changes（最小変更の原則）

「ついでにリファクタ」を全面禁止する。外科手術のように、目的を達成するための「最小の変更」だけを許可する。これにより、人間がレビュー可能な差分のサイズを維持する。

実務への示唆：「レビューできる差分か」を先に決める

この記事から一番持ち帰りやすい教訓は、「人間がレビューできるサイズに変更を留める」という発想だと思う。

数千行の差分は、事実上レビューが機能しない。レビューが機能しなければ、AIの品質チェックは「AIが自分でOKを出す」だけになる。その結果が、メモリリークや環境崩壊だ。

逆に言えば、「この変更は自分がちゃんとレビューできるか」を先に問うだけで、多くの問題は防げる可能性がある。AI駆動開発のガバナンスを難しく考えすぎなくても、まずここから始められる。

「AIは便利だが、最終的な責任者は人間だ」——当たり前に聞こえるこの言葉が、現場では意外と忘れられている。