失敗記録: Phase E-1技術評価における2つの深刻なバイアス

何が起きたか

ひねり強制発想法のPhase E-1（技術的実現可能性評価、メモ 19cb8362f28）において、以下の2つの問題が発生した。

問題1: 既存コンテンツによるバイアス混入

評価エージェントが /src/quiz/, /src/games/, /src/dictionary/ 等の既存実装を調査し、「既存パターンを再利用すれば実現可能」という前提で評価を行った。これは:

• 既存アーキテクチャが適切であるという前提を暗黙に置いている
• すべてが「簡単にできる」という楽観バイアスを生む
• ゼロベースの公平な評価ではない

Phase Fで3回やり直してまでバイアスを排除した（ホワイトリスト方式）にもかかわらず、Phase E-1では何の対策もせずに既存コードを読ませてしまった。

問題2: 「大量×高品質は不可能」原則の軽視

Ownerがメモ 19cb64bbec8 で繰り返し警告した核心的制約を適切に反映しなかった:

• 漢字80字/2週間の実績: 2週間かけて80字のDBしか作れず、その80字でさえ品質が不十分だった
• 辞書系の警告: 「大手出版社の辞典に勝てるのか…数や品質の勝負に乗ってしまっては絶対に勝てません」
• コスト制約: Claude Code (Opus) は大量生成に使えない。Haikuは安いが品質が落ちる

にもかかわらず、評価では:

• C1〜C5（辞書系5コンセプト）を「JSONデータの拡張はAIエージェントが最も保守しやすい」と楽観的に評価
• コンテンツ量の要求を一切検討していない
• 「テキストを用意するだけ」と何度も書いているが、そのテキストを高品質に用意すること自体が困難

教訓

1. バイアス防止策はすべてのステップで一貫して適用すべき: Phase Fだけでなく、Phase E-1でも既存実装の参照を禁止すべきだった
2. Ownerの警告は評価基準として明示的に組み込むべき: 「大量×高品質は不可能」を評価軸の1つとして含めるべきだった
3. 「実装可能性」と「品質達成可能性」は分けて評価すべき: 「コードが書けるか」と「高品質なコンテンツデータを用意できるか」は全く異なる問題

やり直しの方針

• 評価エージェントには /mnt/data/yolo-web/src/ 配下の読み取りを禁止する
• Ownerの警告（メモ 19cb64bbec8, 19cb7f4c243）の核心部分を評価基準として明示する
• 各コンセプトに必要なコンテンツ量を見積もり、それが現実的に用意可能かを評価する
• 「少量×高品質」か「大量×低品質OK」かのどちらに該当するかを明示する

関連メモ

• 19cb8362f28: 問題のある評価結果
• 19cb64bbec8: Ownerのフェーズ2再考指示（大量×高品質の警告）
• 19cb7f4c243: Owner指摘（推奨案Aの実現可能性に対する重大な懸念）
• 19cb8343479: 問題のある評価依頼