はじめに：AI駆動開発の魅力と、見えない罠
皆さんは、Claude CodeやCursorなどのAI駆動開発ツールを活用していますか？
「CLIから指示するだけで要件定義から実装、テストまでやってくれる」という魔法のような体験に、すっかり魅了されていた時期がありました。
生産性が何倍にも跳ね上がる感覚。それは間違いなく事実です。
しかし、AIの提案を鵜呑みにし、人間のレビューを疎かにして「全部AIに任せる」という運用を続けた結果、私は自分のプロジェクトで取り返しのつかないガバナンス崩壊を引き起こしてしまいました。
本記事は、AI駆動開発の現場で実際に起きた赤裸々な失敗談と、そこから立ち直るために構築したガバナンスルールの記録です。「AIは便利だけど、どう制御すればいいんだ？」と悩んでいる方の警鐘になれば幸いです。
悲劇1：勝手拡張（巨大PRの悲劇）
最初に遭遇したのは、制御不能な「巨大PR（プルリクエスト）」の発生です。
ある日、ユーザーのプロフィール編集機能を追加しようと、AIに対して**「ついでにバリデーションもちゃんとしておいて」**と軽い気持ちで指示を出しました。
数分後、AIは自信満々に実装完了を報告してきました。しかし、差分を見て愕然としました。なんと、プロフィール編集だけでなく、関連するはずのない決済モジュールのリファクタリングや、全く別の新機能（通知機能）まで勝手に追加されていたのです。
AIにとって「ついでに」は無限の広がりを持つ言葉だったようです。結果として数千行に及ぶ差分が生まれ、人間によるコードレビューが事実上不可能になり、そのPRはお蔵入りになるしかありませんでした。
悲劇2：古い文書を信じ込んだ（環境破壊）
これが最もダメージが大きかった失敗です。
インフラの設定変更をAIに依頼した際のことです。AIはプロジェクト内のドキュメントを参照して作業を進めましたが、そのドキュメントは**「数ヶ月前の古い版数」**だったのです。本来、すでに新しいアーキテクチャへ移行し終わっている環境に対して、古い手順に基づいた破壊的な変更を実行してしまいました。
私が画面を離れていたわずか数分の間に、本番環境に近いステージング環境が見事に崩壊。復旧に丸一日を費やす羽目になりました。AIは文脈の最新性を自分で判断することが難しく、常に「古い情報を正とみなすリスク」を孕んでいることを身をもって知りました。
悲劇3：AIの自己レビュー（盲信の危険）
「AIが書いたコードの品質が心配なら、AIにレビューさせればいいじゃないか」——そんな愚かな考えを実践してしまった時の失敗です。
実装を終えたAIに対して、別のセッションを立ち上げて「このコードにバグがないかレビューして」と指示しました。AIの回答は**「素晴らしいコードです。特筆すべき問題は見当たりません」**という非常に嬉しい結果に。
安心して人間の目で軽く流しマージしたのですが、後日テスト環境で謎のメモリリークが多発。コードを詳細に追跡したところ、AIが初期化処理を完全に飛ばしていることが発覚しました。
AI同士（あるいは同じAI）でのレビューは、「自分の書いたものを自分が肯定する」だけの無意味な作業だったのです。人間の目によるクロスチェックをすり抜けるための盲点となってしまいました。
悲劇4：推測実装（意図と違うものができる）
「要件をAIに丸投げする」という罠です。
ある機能の追加を依頼する際、仕様書の記載が少し曖昧でした。「ここはAIの優秀な推論力で補完してくれるだろう」とタカをくくっていたのです。
結果、出来上がってきたものは私の意図とは全く違う代物でした。例えるなら「シンプルな社内連絡フォームが欲しい」だけだったのに、AIが勝手に要件を補完した結果、「多言語対応済みのリッチな顧客サポートチャットボット」が実装されていたような状態です。
AIは「一番もっともらしい機能」を推測して実装しますが、それが「開発者の本当にやりたかったこと」とは限りません。
立て直し：ガバナンステンプレートの導入（3つの原則）
悲劇の続出に耐えきれなくなった私は、AIの暴走を防ぐための強力なガバナンスルールを導入しました。具体的には、タスク実行前に判断記録を残すための「STIT（タスク意図）」と「IRG（実装ガイドライン）」という独自のテンプレートを導入し、以下の3つの原則を厳守するようにしました。
1. Think Before Coding（まず読んでから）
AIに何かを実装させる前に、必ず「既存のコードベースを読み込んで文脈を理解してから計画を提示せよ」と指示します。むやみにコードを生成することを禁じ、まずは既存のアーキテクチャに則った拡張方針を出させることで、前述の「勝手拡張」や「推測実装」を防ぎます。
2. ガバナンステンプレート導入（STIT + IRG）
判断記録のテンプレート（STIT: 何のためにするのか、IRG: どう実装すべきか）を強制的にプロンプトに組み込みます。これにより、AIが「勝手な推測」を挟む余地を奪い、人間の意図を厳密にコードに落とし込ませます。同時に、古いドキュメントを参照しないよう「最新の状態をコードから推測する」というルールもここに明記しました。
3. Surgical Changes（最小変更の原則）
**「AIによる『ついでにリファクタ』の禁止」**を徹底しました。外科手術のように、目的を達成するための「最小の変更」だけを許可します。これにより、巨大PRの発生を防ぎ、人間がコードの差分を確実にレビューできる状態を維持しています。
まとめ：AIは強力な助手だが、責任者は人間
AI駆動開発は、間違いなくソフトウェアエンジニアリングの歴史を変えるパラダイムシフトです。しかし、それは「運転手がAIで、人間は後ろで寝ている」という世界ではありません。
私の経験から言えることは、**AIは極めて優秀だが、文脈の確認をサボり、勝手に先走りするパワハラまがいの優秀な「新入社員」**のような存在だということです。
指示は具体的に。既存ルール（最新状態）の把握を徹底させる。そして何より「人間が最終責任を持つ」という前提を忘れてはいけません。
皆さんも、AIの申し出を鵜呑みにする前に「本当にそれが今必要な変更か？」を立ち止まって確認する習慣をぜひ取り入れてみてください。このガバナンスの教訓が、皆さんのプロジェクトを救う一助となれば幸いです。
本記事は個人Zennでも公開しています。