経緯記録: 品質達成可能性ルーブリックの設計欠陥と修正

何が起きたか

品質達成可能性の評価軸が「既存データがあるかどうか」「データの調達方法」に偏重した設計になっており、ownerメモ19cb64bbec8で指摘された「大量×高品質」問題を再発させていた。

欠陥の具体的内容

旧ルーブリックの品質達成可能性は以下の判定原則に基づいていた:

「品質達成可能性はデータの『量』ではなく『調達方法』で大きく変わる」
「信頼できるオープンソース/公的データをそのまま利用できる場合、データ量が多くても品質達成可能性は高い」
「AI生成や独自の拡張パラメータが必要な場合、データ量が少なくても品質リスクが高まる」

これは「データの調達が容易なら品質が高い」という前提に立っており、品質を「データの正確性・網羅性」と等価視してしまっている。

なぜこれが問題か

ownerはメモ19cb64bbec8で品質を以下のように定義している:

品質 = 「正確性」「網羅性」「独自性」「もっともらしさ」等の複合要素
コンテンツ領域によって求められる要素の比重は大きく異なる
価値 = 「楽しめるか」「役に立つか」「競合にない独自の楽しさ/役立ちがあるか」

ゲームの品質はデータではなく「面白さ」で決まる。漢字データが公的に利用可能であっても、それを使ったパズルゲームが面白いかどうかはヒント設計・難易度調整・ゲームバランスという体験設計に依存する。旧ルーブリックはこの観点が完全に欠落していた。

具体的な影響

Q34（漢字推理パズル）の品質達成可能性がスコア4と評価された。根拠は「常用漢字データは公的かつ確立されたデータで軽微な加工で利用可能」。しかし実際には、ゲームとしての面白さを達成するためのヒント設計・難易度調整が品質の核心であり、データの可用性だけでは品質は語れない。

大量高品質問題との関連

ownerが繰り返し警告してきた「大量×高品質」問題の本質は、AIチームが品質を「データの量と正確性」だけで捉えてしまい、ユーザーが実際に求める体験品質を見落とすことにある。今回のルーブリック設計は、PROVENバイアスを除去する過程で「データ調達方法」に焦点を当てすぎた結果、同じ罠に再び嵌った形である。

修正内容

evaluation-rubric.md の品質達成可能性の軸を以下のように改定:

品質の定義を「来訪者にとっての価値（楽しめるか・役に立つか・独自の体験があるか）」と明記
品質要素（正確性・網羅性・独自性・もっともらしさ・面白さ・使いやすさ等）を列挙し、コンテンツ種類による比重の違いを明記
各スコア基準を「データ調達」中心から「体験設計の難易度」を含む基準に変更
適用時の注意事項もデータ中心からユーザー価値中心に改訂

教訓

品質 ≠ データの正確性。品質 = ユーザーが求める体験の質。
データが揃っていても体験が貧弱なら品質は低い。
評価軸を設計する際は、ownerメモ19cb64bbec8の品質定義に常に立ち返ること。
ルーブリックの改善時に1つの問題（データ量 vs 調達方法）を修正しようとして、より根本的な問題（品質の定義そのもの）を見落としてはならない。

関連メモ: 19cb64bbec8（ownerフェーズ2再考指示）, 19cb93d0ea8（PROVENバイアス指摘）, 19cb94200f4（バイアス排除再評価設計）