レビューAIの指摘を全部反映すると、要件定義が終わらない ― 採否基準とREQUIREMENTS.mdで止める

TL;DR（結論）

• レビューAIは「穴を見つける」のが仕事なので、放っておくと無限に穴を出す。全部反映すると要件定義が永遠に確定しない（＝終わらない要件定義ループ）。
• 原因はAIの精度ではなく、採否を決める「司令塔」を人間が空けていること。
• 対策は2つ。(1) 採否基準を「従わなかったら実際に誰が困るか」に固定する。(2) REQUIREMENTS.md の冒頭に「解決する穴 / やらないこと / レビューAIへの指示」を先に書く。
• 納品前に、コードを一行ずつ説明できるか確認する。

何が起きたか

AIとプログラムを詰めていて、技術で詰まったわけではないのに前に進まなくなった。要件定義が終わらない構造に入っていた。

穴を指摘される → 補強する → 補強したら新しい穴が見える → また補強する。これが延々と回る。特にレビューAI（コードや設計の穴を出させるAI）を噛ませると加速する。レビューAIの仕事は穴を見つけることなので、放っておけばいくらでも穴を出す。それを全部反映すると、完成のための要件定義ではなく、未完成を延命するための要件定義になる。

いわゆるスコープクリープの一種だが、穴→補強→新しい穴のフィードバックが自走する点が特徴だ。この記事では「終わらない要件定義ループ」と呼ぶ。

なぜ止まらないのか：原因はAIではなく「司令塔の空席」

最初はAIの精度の問題だと思った。でも違った。

問題は、AIを「決定を承認する権威」として扱っていたことにある。穴を出させること自体は悪くない。悪いのは、出したあとの採否を自分が中心で決めなかったことだ。中心が空席になると、AIの正論にそのまま引きずられる。

正直に書くと、正論を見せられると、それを反映しないことに罪悪感が出る。「理論上ありうる穴」と「今回塞がないと実際に困る穴」を、自分は分けきれていなかった。詰まりの正体は技術ではなく、ここだった。

対処1：採否基準を一つに固定する

基準はこれ一つに絞った。

その指摘に従わなかったら、実際に誰が困るか。

レビューAIが出す穴の大半は「理論上ありうる」だが、誰も困っていないことがある。困る人を名前で挙げられない指摘は、正しくても今回の要件には入れない。正しい指摘でも、今回の完成に直接効かなければ「将来課題」へ送る。抽象的な完璧さで判断しない。

問いの仕分けも効いた。

その問いに答えても、次の具体的な手が変わらないなら、それは「止まる問い」。

「また膨張するのでは」と考えるだけなら止まる問い。防ぐために何を書くか、何を今回やらないと決めるか、まで落ちるなら進む問い。

対処2：REQUIREMENTS.md に「完成を守る制約」を先に書く

要件定義では、機能要件より先に「完成を守るための制約」を書く。具体的には、REQUIREMENTS.md の冒頭にこれを置く。

## このシステムが解決する穴（これ以外はやらない）

1.
2.
3.

## やらないこと（明示的に範囲外）

-

## レビューAIへの指示（重要）

指摘は「このシステムが解決する穴 1, 2, 3 に直接効くか」で採否する。
効かない穴、将来の穴、理論上だけの穴は「将来課題」へ記録し、今回の要件には足さない。

この制約があれば、レビューAIが10個穴を出しても、1, 2, 3 に効く2個だけ反映し、残り8個は将来課題に送れる。完成を止めるのはコードの難しさではなく、線引きの不在である。

ポイントは、レビューAIを呼ぶ前にこれを書いておくこと。呼んでから書くと、もう増殖が始まっている。

納品前のルール：一行ずつ説明できるか

AIに実装を任せても、コードを目の前に置いて一行ずつ「これは何か」を説明できなければ納品しない。これは自分を責めるためではなく、知識を捨てられなくするための仕組みだ。わからない行があると納品が止まるので、脳がそれを「捨てていい情報」として扱えなくなる。

まとめ（チェックリスト）

• レビューAIを呼ぶ前に「解決する穴 / やらないこと / 採否基準」を書いたか
• 指摘の採否を「従わなかったら誰が困るか」「名前で挙げられるか」で決めたか
• その問いに答えると、次の手が変わるか（変わらないなら深掘りしない）
• 納品前に、コードを一行ずつ説明できるか確認したか

AIに任せるほど、人間側の問い・意思・責任は残る。便利になった分だけ、司令塔の椅子の重さが増す。その椅子だけは、空けてはいけない。