よくある状態：「◯◯を修正して」とだけ伝えて実装させ、出てきたものを見てから「そうじゃない」「そこは触らないでほしかった」と直しの往復が始まる。

こうする

計画段階で、AIに「受け入れ条件」と「スコープ外」を明文化させる。

受け入れ条件：何ができたら完了か。あとで「満たした／満たしていない」を判定できる具体さで書き出す
スコープ外：今回やらないこと。触らないファイル・変えない挙動・対応しないケース

書くのはAIです。人間はそれを見て「やってほしいこと／やってほしくないこと」を確認・修正してから実装に進ませる。

実例

タスク「パスワードリセット機能を追加する」の計画書冒頭のイメージ：

# パスワードリセット機能の追加

## 受け入れ条件

- [ ] 登録済みメールアドレスを入力すると、リセット用リンクがメールで届く
- [ ] リンクから新しいパスワードを設定でき、以降は新パスワードでログインできる
- [ ] リンクには有効期限があり、期限切れ・使用済みのリンクではエラーメッセージが表示される
- [ ] 未登録のメールアドレスを入力しても、登録の有無が相手にわからない応答になる
- [ ] 既存のログイン・ログアウトの挙動が変わっていない

## スコープ外（今回やらない）

- 2要素認証・SMS認証の導入
- パスワードポリシー（強度ルール）の変更
- ログイン画面のデザイン変更
- 管理者による強制リセット機能

ポイントは、「未登録でも登録の有無がわからない応答」のようなセキュリティ上の暗黙の期待や、「既存の挙動が変わっていない」のような**「壊さないこと」の条件**まで書き出すこと。人間が頭の中で当然と思っていることこそ、明文化しないとAIには伝わりません。スコープ外の「デザイン変更はしない」も、AIが気を利かせて画面を「改善」してしまう事故を防ぎます。

なぜ：一度書けば、5回効く

この1枚の表が、開発の流れ全体で使い回されます。

人間が着手前に確認できる——「やってほしいこと・やってほしくないこと」の認識合わせが、実装後ではなく実装前にできる
実装AIの迷いが消える——何をするべきで、今回は何をしないのかがはっきりわかる。AIの実装が最も暴走するのは、完了条件が曖昧なとき
AIが自己チェックできる——実装後に「本当に自分の仕事は終わったのか」「余計なことをしていないか」を条件表と突き合わせて確認できる
レビューAIも同じ観点で見られる——レビューの基準が「レビュワーの気分」ではなく条件表になる
人間の最終レビューも同じ観点——そして「これを満たしていたら成功」。完了の定義で揉めない

つまり、関わる全員（人間・実装AI・レビューAI）が同じものさしを持つ、ということです。

運用のコツ

計画書の冒頭に置く。付録ではなく一番目立つ場所に。以降の全工程がここを参照する
スコープ外を空にしない。「やらないこと」が書けないのは、範囲を考えていないサイン。「隣接するあの機能は触らない」だけでも書く
条件はテストに落とす。受け入れ条件の多くはそのままテストコードにできる。「条件表を満たすテストを書いて」まで頼めば、自己チェックが機械化される

お知らせ

この記事は、イデアライブ社内の「AI駆動開発の考え方」ドキュメント（全12本）をシリーズとして公開しているものです。

イデアライブでは、一緒に働く仲間を募集しています → Wantedly