バイアス排除再評価: プロセス設計

ownerの過去指示から抽出したバイアス防止原則

1. 既存/新規の出自を秘匿 (19cb304c2f9): 評価者にどれが既存かを知らせない
2. ゼロベース = 同一条件で公平に評価 (19cb3008a0b): 既存だから/新規だからで条件を変えない
3. 「あえて言わない」原則 (19cb6fee624): 「XXXを禁止する」「XXXは禁止されていない」のどちらもバイアス。言及しないのが正解
4. 既存コンテンツのテーマバイアスに注意 (19cb701e6e8): 日本文化偏重は既存コンテンツからの間接バイアスの可能性
5. 数量均等化 (19cb70dad02): 特定テーマの候補が多いと、そのテーマが有利になる
6. PROVENフラグは矛盾 (19cb93d0ea8/今回): Google「有用性が低い」と判定されたものの実績を正のシグナルにするのは矛盾

今回のバイアス混入の分析

混入箇所: evaluation-rubric.md

具体的な汚染ポイント:

1. PROVENフラグの定義（109行目）
2. 「既存実績を最優先」原則（115行目）
3. 「既存実績からの基準点」セクション（83-87行目）- irodori, kanji-kanaru等を名指しで言及
4. 実装可能性スコア4の例（52行目）- 「既存実績あり: irodori, nakamawake等」
5. 継続性スコア5の例（65行目）- 「漢字かなる、四字きめる等は既に稼働中の実績あり」
6. 品質達成可能性スコア2の例（94行目）- 「漢字辞典の実績（2週間で80字）」

なぜこのバイアスが入ったか

owner指摘（19cb921ed73）でスコアの不正確さを指摘された際、「厳密な基準点が必要」と判断し、yolos.netの実績を基準点に使った。これは「厳密さ」を求めた結果、既存コンテンツに錨を下ろすアンカリングバイアスを導入してしまった。

バイアスの影響範囲

1. ルーブリック → 2. 再評価スコア → 3. サイトコンセプト案 → 4. レビュー → 5. 最終比較 全段階が汚染されている。

再評価プロセス設計

Step 1: ルーブリック浄化

evaluation-rubric.mdから以下を除去・修正:

• PROVENフラグを完全削除
• 「既存実績を最優先」原則を削除
• 「既存実績からの基準点」セクションを削除
• 各スコアの具体例から、特定サイトの実績への言及を全て除去
• 代替: 一般的・仮想的な例に置き換え（「あるサイトで〜」ではなく「〜の場合」のような抽象例）

Step 2: ルーブリック浄化のレビュー

浄化後のルーブリックを別のreviewerに渡し、以下を確認:

• 既存コンテンツを特定できるヒントが残っていないか
• 特定の候補タイプに有利/不利なバイアスがないか
• スコア基準が明確で一貫しているか

Step 3: 全候補の再評価

入力:

• anonymized-candidates-v2.md（クリーン確認済み）
• 浄化済みルーブリック

注意事項（sub-agentへの指示設計）:

• ❌ yolos.netや既存サイトへの言及を一切含めない
• ❌ 「既存」「新規」「PROVEN」等の語を使わない
• ❌ coding-rules.mdを読ませない（「あえて言わない」原則: 技術制約を見せると特定コンテンツが有利になるリスク）
• ❌ 評価ルーブリック以外の参考資料を渡さない
• ✅ anonymized-candidates-v2.mdとルーブリックのみ
• ✅ 候補をグループに分け並列で評価（順序バイアス防止）
• ✅ グループ分けはランダムシャッフル

Step 4: サイトコンセプト案の再作成

入力:

• 浄化済み再評価結果（上位コンテンツ候補のみ）
• constitution.md（サイトの基本方針のみ）

注意事項:

• ❌ 既存サイトの構成を見せない
• ❌ 「少量×高品質 vs 大量×低品質OK」の分類を先に提示しない（これもバイアス。分類はコンセプト評価時に初めて行う）
• ✅ コンテンツスコアのみに基づいて相性の良い組み合わせを考える
• ✅ 3〜5個のコンセプト案を作る

Step 5: レビューと最終選定

• コンセプト案のレビュー
• 最終比較（この段階で初めて技術制約・持続可能性等を考慮）

技術制約の扱いについて（重要な設計判断）

coding-rules.mdを評価時に見せるかどうかは重要な判断。

• 見せた場合: 「外部API不可」の制約を知ることで、API依存コンテンツが不当に低くスコアリングされる（これは正当）。ただし、既存のデイリーゲームが「技術制約内で動いている」ことへの間接的なバイアスになるリスクもある。
• 見せない場合: 技術的に実装不可能なコンテンツが高スコアになるリスク。ただしこれはStep 5で除外できる。

→ 判断: ルーブリックの「実装可能性」軸に技術制約の要約を含める（一般的な制約として記述し、特定サイトへの言及なし）。これはルーブリック自体の一部として自然であり、「coding-rules.mdを読め」という別途の指示を出すよりもバイアスリスクが低い。

ただし、ルーブリックの実装可能性の記述は現状で十分一般的（「禁止: ランタイムの外部API呼び出し、データベース、認証」「可能: クライアントサイドJS、ローカルストレージ、SSG/ISR」）。特定サイトの名前が入っていなければこのまま使える。