配布資料 51事例 #11: 否定された設計案を、AI が何度でも再提案した

8回却下しました。しかも同じ案が2回出てきました。 挙げ句、正解は最初から自分たちの要件定義に書いてありました。

何が起きたか

返金原資の設計議論で、AI の提案を否定する往復が最低5回発生しました。否定された設計案は記録上8パターンに及びます。

将来売上からの天引き（販売者が退会したら回収不能）。 「決済手数料はほぼ±0」として計算から除外（年間数万件なら数百万円の損失）。 銀行振込での補填（原資問題を構造的に解決しない）。 手数料の二重計上。

同じ案を2回提案した記録も残っています。

さらに決定的だったのは、正解（請求書方式）が既存の要件定義にすでに規定されていたことです。 AI はそれを読まずに、独自案を出し続けていました。

なぜ起きたのか

表面的には、個々の設計案の事業的な欠陥です。回収可能性、収支、業界慣行の無視。

構造は4つです。 ①AI はセッションを跨ぐと否定された記憶を失い、もっともらしい同じ案に再収束します ②既存資料の確認より発案を優先する癖があります ③自分の提案を擁護する誘惑があります（これは AI 自身が振り返りで記録しています） ④事業視点——赤字許容度や回収リスク——の欠如

そこから生まれたルール

議論の決着と同日中に、3点セットで焼き込みました。

①「絶対禁止事項リスト」（禁止事項と理由のテーブル）を rules ファイルとして新設し、返金関連の実装時に必ず照合する ②要件定義の本文へ反映する ③誤提案パターンと再発防止のセルフチェック（既存文書確認・事業収支・退会リスクなど5項目）を記憶に残す

リストは以後も成長しました（8→10項目）。 そしてルール自体の誤りも後日訂正され、訂正の経緯ごと本文に残る運用になっています。

どう機械に守らせたか

rules ファイルを、対象パス（返金・精算・注文系）の編集時に自動ロードされる配置にしました。 CLAUDE.md には「実装時必読・否定済み設計の再提案禁止」を明記しています。

コードレビュー用のサブエージェントには、観点2番として「否定済み設計の再導入検知」を組み込みました。

持ち帰るなら

AI との設計議論では、採用した案だけでなく「否定した案と否定の理由」を成果物として残してください。

否定リストがなければ、次のセッションの AI は同じ提案を必ず繰り返します。

人間側の技術も要ります。抽象的に却下せず反例で否定すること。そして「既存文書を確認しろ」で独自案ループを切断すること。 この2つが揃うと、否定は一度で済むようになります。