【代筆】以下はownerからの指示の原文ママです。

---

既存コンテンツにフラグを立てた上で評価させてしまうという評価方法の設計は、サイクル66全体を通じてずっと避けるべく努力してきたバイアスを強く増幅させるものです。既存コンテンツがGoogleに「有用性が低いコンテンツ」と認定されたことがそもそもこのコンセプト見直し作業を始めたきっかけなので、既存コンテンツがあるから価値があると見做すのは非常に危険です。どこからバイアスが入ったのかを特定して、そこからやりなおしてください。今動いているサブエージェントは停止してください。

---

【PM補足: バイアス混入箇所の特定】

背景

cycle-66はGoogleのAdSense審査で「有用性の低いコンテンツ」と判定されたことを受けて開始した。既存コンテンツの価値を前提とせず、ゼロベースでサイトコンセプトを再構築することが目的。MEMORY.mdにも「ゼロベース検討は最後まで一貫」「構想フェーズでは既存文書をsub-agentに見せない」という教訓が記録されている。

バイアスの混入箇所: 評価ルーブリック（docs/forced-ideation/evaluation-rubric.md）

バイアスは Task #5「評価ルーブリック作成と全コンテンツ候補の再評価」 で混入した。具体的には:

1. PROVENフラグの定義（ルーブリック109行目）

PROVEN | 既存サイト（yolos.net）で同種コンテンツの稼働実績がある | 実績に基づくスコアであり、信頼性が高い。

「稼働実績がある＝スコアの信頼性が高い」という定義は、既存コンテンツに正のバイアスを与える。Googleが「有用性が低い」と判定したコンテンツの実績を「信頼性が高い」と評価するのは矛盾。

2. 「既存実績を最優先」の注意事項（115行目）

既存実績を最優先: yolos.netで稼働中のコンテンツと同種のものは、実績に基づいてスコアリングする。推測よりも実績が常に優先される。

これにより、既存コンテンツは常に他の候補より有利にスコアリングされる仕組みになった。

3. バイアスの増幅経路

• ルーブリック → 再評価（Q34, Q36にPROVENフラグ付きで4.6の最高スコア）
• 再評価 → サイトコンセプト案（PROVENコンテンツを核に据えた案が多数）
• サイトコンセプト案 → レビュー（レビュアーが「PROVENコンテンツの活用度」を比較軸として採用）
• レビュー → 最終比較（「PROVEN活用数」「スモールスタート可能性」で既存コンテンツ活用案が圧倒的優位）
• 最終比較 → 推奨案（案1「デイリーパズル」= ほぼ既存サイトの追認）

4. 結果として何が起きたか

推奨1位の案1「デイリーパズル」は、既存4ゲームをそのまま核にした案。これは「Googleに有用性が低いと判定された既存サイトの追認」に等しく、cycle-66の目的（ゼロベースでのコンセプト再構築）と完全に矛盾する。

やり直し範囲

やり直すべき箇所

1. 評価ルーブリック: PROVENフラグを削除し、「既存実績を最優先」の注意事項を削除
2. 全コンテンツ候補の再評価: PROVENフラグなしで再評価
3. サイトコンセプト案の作成: PROVENバイアスなしで再作成
4. レビューと最終比較: 再実施

やり直さなくてよい箇所

• anonymized-candidates-v2.md（匿名化リスト自体にはPROVENフラグなし、確認済み）
• evaluation-rubric.mdの5軸定義自体（独自性、需要、実装可能性、継続性、品質達成可能性の定義は妥当）
• ただし各軸の具体例に「既存実績」への言及があるため、それらも修正が必要

関連メモ

• 19cb921ed73: ownerの前回指摘（コンテンツ/コンセプト混同、スコア不正確）
• 19cb92d1572: 再評価完了サマリー（PROVENフラグ付き）
• 19cb93abf8f: 最終比較分析（PROVEN活用度で比較）

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

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」）。特定サイトの名前が入っていなければこのまま使える。