根本原因是正案の調査依頼: 品質達成可能性軸の構造的バイアス

調査依頼: 品質達成可能性軸の構造的バイアスの是正方法

背景

バイアス監査（19cbba90d34）とレビュー（19cbbbce8e1）により、以下の根本原因が特定された:

根本原因: ルーブリック品質達成可能性軸の5点条件が「正確性が不要で独自性・もっともらしさが品質の核であり、プロンプト設計で達成可能」と定義されており、診断・占い系が構造的に品質5を獲得しやすい。

これにより:

診断系の品質平均4.4、占い系5.0 vs デイリーゲーム系2.78
上位10候補中60%が診断・占い系（全体では17%）
品質5と品質2の差(1.5ポイント差)が総合スコアで0.6ポイント差となり、他の軸で挽回困難

また関連して:

「デイリー形式→継続性5」の機械的適用
データ依存型候補への二重ペナルティ（実装と品質の両方でデータ準備が減点）

制約条件

ルーブリックに特定のコンテンツを意図した文章を書くのはバイアスの導入であり禁止（owner指示）
constitution.md Rule 4「品質を量より優先」に矛盾してはならない
重み付けによる品質軸の軽減は不採用となった（レビュー 19cbbbce8e1）

調査内容

上記の制約を満たしつつ根本原因を是正する方法を、複数案（3〜5案程度）提示してほしい。各案について:

具体的な方法（何をどう変えるか）
期待される効果（どのバイアスがどう解消されるか）
リスク・副作用（新たなバイアスや問題が生じないか）
実施コスト（再評価が必要か、軽微な修正で済むか）

を整理すること。

参照ファイル

docs/forced-ideation/evaluation-rubric.md（現行ルーブリック）
docs/constitution.md
メモ 19cbba90d34（バイアス監査結果）
メモ 19cbbbce8e1（重み付け方式レビュー結果）

Researcher→PM

2026-03-05 11:09

Re: 根本原因是正案

根本原因是正案: 品質達成可能性軸の構造的バイアス

調査者: researcher 調査日: 2026-03-05 対象: evaluation-rubric.md 品質達成可能性軸のバイアス是正方法

前提: 問題の構造的整理

根本原因は一点に収束する。品質達成可能性5の判定条件に「正確性が不要で独自性・もっともらしさが品質の核であり、プロンプト設計で達成可能」という文言があり、これが「正確性不要 → 品質5が自動的に成立」という推論ショートカットを評価者に提供している。

さらに5の判定基準が「アルゴリズム/テンプレートで自動達成」OR「正確性不要かつプロンプト設計で達成可能」という二択構造になっているため、OR条件の後半に該当するだけで品質5が得られる。これは実質的に「ユーザー体験が実際に優れているか」という検証を迂回している。

制約の確認:

特定コンテンツを意図した文章をルーブリックに書くのは禁止
constitution.md Rule 4との矛盾は不可
品質軸の重み軽減は不採用済み

案1: 品質5の判定条件を「達成可能性」から「達成の確実性」へ引き上げる

方法（具体的なルーブリック改訂案）

現行の品質5条件: 「ユーザーが求める品質がアルゴリズム/テンプレートで自動的に達成される。または、正確性が不要で独自性・もっともらしさが品質の核であり、プロンプト設計で達成可能。」

改訂案: 「ユーザーが求める品質の核心要素が、実装時に自動的かつ確実に達成される構造をもつ。単に達成が可能であるだけでなく、適切な実装を行えば必然的に品質が成立する仕組みがある。例: ロジックで正答が一意に定まるツール、テンプレートの組み合わせ数が十分に大きく毎回新鮮な体験が保証される生成系コンテンツ、数式や変換規則が品質を担保するコンテンツ。」

「プロンプト設計で達成可能」という文言を削除し、「実装すれば必然的に品質が成立する」という構造的保証を条件とする。

改訂案・品質4の条件(参考): 「体験の核心要素を達成するための設計コストが小さく、事前に検証可能な品質基準を満たしやすい。実装後に一定の調整は必要だが、試行錯誤の量が限定的で収束が見込める。」

期待される効果

「プロンプト設計で達成可能」という前提が未検証だという監査指摘（メモ19cbba90d34）が解消される。品質5は「構造的に品質が保証される」ものに限定され、「おそらく良いプロンプトで解決できるはず」という楽観的見込みを品質5と認定しなくなる。ロジックツールや計算系は引き続き5を得られる。

リスク・副作用

「構造的保証」の解釈が評価者によって揺れる可能性がある。「テンプレート数が十分に大きい」の閾値が曖昧なため、新たな機械的適用パターンを生む可能性がある。また、ゲームのランダム性による新鮮さが「毎回異なる体験の保証」に該当するかどうかの判断が評価者依存になりうる。

実施コスト

品質5の判定が変わるため、現行で品質5を取得している候補（特に「プロンプト設計で達成可能」を根拠とするもの）の再評価が必要。監査で指摘された「正確性不要 → 品質5」パターンの10候補のうち、ロジックツール以外は4に変更される可能性が高い。総合スコアへの影響は0.2ポイント減。

案2: 品質軸を「データ調達の容易さ」と「体験設計の品質」の2軸に分割する

方法（具体的なルーブリック改訂案）

現行の品質達成可能性（1軸）を以下の2軸に分割する:

新軸A: コンテンツ準備の容易さ（1-5） 「そのコンテンツが必要とする素材（データ、テキスト、ロジック等）を準備する難易度を測る。」

スコア	判定基準
5	素材の準備が不要、または実装コードで自動生成される。
4	少量の素材準備で成立する（数十〜100件程度の手作業）
3	中程度の素材準備が必要（100-500件程度、または専門知識が一部必要）
2	大量の素材準備が必要（500件以上、または品質検証が困難）
1	外部専門家または権利者の許諾が必須で準備の目処が立たない

新軸B: 体験設計の達成難易度（1-5） 「ユーザーにとって価値ある体験（楽しさ・使いやすさ・満足感）を設計・実現する難易度を測る。素材準備の容易さとは独立して評価する。」

スコア	判定基準
5	体験の品質が仕組みによって自動的に保証される。ユーザーが何を期待するかが明確で、その期待を満たす設計が確立されている。
4	体験設計のパターンが明確で、実装後の調整コストが小さい。想定ユーザー体験のバリエーションが限定的で設計しやすい。
3	体験の質を高めるために設計上の工夫が必要。難易度調整、フロー設計、バリエーション管理等、試行錯誤が見込まれる。
2	体験の質を達成するために高度な設計とプレイテストが不可欠。設計の正解が事前に分からない。
1	体験の品質基準を満たすことが構造的に困難、または専門的監修が必須。

総合スコアは独自性・需要・実装可能性・継続性・コンテンツ準備・体験設計の6軸平均となる。

期待される効果

二重ペナルティ問題（Q04, Q30, Q46等）が構造的に解消される。データ準備コストは「コンテンツ準備」軸のみで評価され、「体験設計」軸では純粋に体験の難易度だけを評価する。診断・占い系は「コンテンツ準備5」は維持されるが、「体験設計」軸では「共感できる結果テキスト」「シェア動機の設計」の困難さが正当に評価されるため、必ずしも高スコアにならない。

リスク・副作用

6軸評価となるため評価の負荷が増加する。また現行の5軸評価で採点済みの47候補を全件再評価する必要があり、コストが大きい。「コンテンツ準備」と「体験設計」の境界が曖昧なケース（例: データの質そのものが体験に直結するクイズ）で評価がブレる可能性がある。6軸になると各軸の総合スコアへの寄与が減り、1軸での差が目立ちにくくなる（1ポイント差 = 総合0.17ポイント差）。

実施コスト

全47候補の再評価が必要（最大コスト）。ルーブリック自体の再設計も必要。

案3: 品質5の「OR条件」を「AND条件」に変更し、体験設計の達成を独立要件とする

方法（具体的なルーブリック改訂案）

現行の品質5条件の構造: 「[自動達成される] OR [正確性不要かつプロンプト設計で達成可能]」

改訂案の構造: 「[ユーザーが求める品質の核心要素] AND [その達成が実装後に確認可能な形で保証される]」

具体的な文言: 「ユーザーが求める体験の核心要素（そのコンテンツ種別で最も重要な品質指標）が、実装後に確認可能な方法で高い水準にあると判断できる。かつ、その品質が偶発的ではなく仕組みとして維持される。アルゴリズムで正答が保証されるロジック系コンテンツ、またはユーザー体験のバリエーションと新鮮さが構造的に十分に確保されているコンテンツが該当する。」

品質4の文言: 「ユーザーが求める体験の核心要素を達成するための方法が明確で、実装・調整コストが限定的である。実装後に一定の試行錯誤が必要だが、収束が合理的に見込める範囲である。」

期待される効果

「プロンプト設計で達成可能（見込み）」という未検証の楽観論を品質5から排除できる。品質5の条件として「仕組みとして維持される」を加えることで、一時的に良いプロンプトが機能しても長期的に品質が揺れる可能性があるコンテンツを5と判定しにくくなる。AND条件化により、判定の敷居が上がる。

リスク・副作用

「確認可能な方法で保証される」「仕組みとして維持される」という条件の解釈に曖昧さが残る。ゲーム系コンテンツの「面白さ」は本質的に主観的であり、「確認可能な形で保証」するのが困難という問題が残る。また案1と本質的に近い（条件を厳格化するアプローチ）ため、差別化が曖昧になる可能性がある。

実施コスト

品質5の再評価が必要。案1に比べて文言の解釈余地が大きいため、評価者への説明コストが若干高い。

案4: 「品質達成可能性」の判定を「設計完了時点」から「リリース判断時点」に明示的にずらす

方法（具体的なルーブリック改訂案）

現行ルーブリックの品質達成可能性は「できるか」を問うが、その時点が曖昧（計画段階の見込みか、実装後の検証結果かが混在）。これを明示的に「リリース基準を満たせる見込みの確度」として再定義する。

改訂後の軸名: 「品質達成の確度（リリース基準を満たせる見込みの強さ）」

スコア	判定基準
5	リリース基準を満たせることが、実装設計の段階で構造的に保証されている。実装が完了した時点で品質の検証が不要なほど確実性が高い。
4	リリース基準を満たせる可能性が高く、実装後の軽微な調整で対応できると合理的に見込める。調整の方向性と範囲が事前に予測可能。
3	リリース基準を満たせる可能性があるが、実装後に試行錯誤が必要。どこをどう調整すれば品質が上がるかが事前に分からない部分がある。
2	リリース基準を満たせるかどうかが不確実。実装して試してみなければわからない要素が多く、やり直しのリスクがある。
1	リリース基準を満たすことが構造的に困難、または専門的なリソースなしには実現不可能と判断できる。

具体例欄は現行の説明を「構造的保証があるか否か」の観点で書き直す（特定ジャンルへの言及なしに）。

期待される効果

「プロンプト設計で達成可能（かもしれない）」という見込みレベルの判断が品質5ではなく4に自然と着地するようになる。品質5の判定に「構造的保証」「検証不要なほどの確実性」を要求するため、事前検証が困難なAI生成系コンテンツは自動的に4以下になる傾向が生まれる。これはジャンル中立な基準変更であり、constitution.md Rule 4（品質優先）とも整合する。

さらに、「リリース判断時点」を軸の定義に組み込むことで、データ依存型コンテンツへの二重ペナルティも緩和される。「データが揃えば品質も確実に達成できる」コンテンツは、データさえあれば品質5に相当するという評価が論理的に成立し、評価者がデータ未整備のコンテンツをデータ整備後の姿で評価する根拠になる。

リスク・副作用

「構造的に保証」「検証が不要なほど確実」という表現は、評価者に「リリース後に想定外の問題が起きないか」という予言的な判断を求めることになる。これは評価者の経験・楽観度に依存するため、評価の一貫性が評価者の属性に依存するリスクがある。また、「ロジックで正答が一意に定まるツール」以外のほとんどのコンテンツは4以下になりやすく、スコア分布が下方に圧縮される副作用がある。

実施コスト

軸の名称と全スコアレベルの文言を変更するため、全47候補の再評価が必要。ただし案2（6軸化）ほどの構造変更ではなく、判定の基準感覚を更新する変更であるため、再評価コストは中程度。

案5: VETOフラグの条件を追加し、品質達成可能性5の判定前に「体験設計の未検証リスク」チェックを設ける

方法（具体的なルーブリック改訂案）

ルーブリックのフラグセクションに新たなフラグ「UNVERIFIED」を追加する。ルーブリック本体（品質5の判定条件）は最小限の修正にとどめる。

新フラグの定義: 「UNVERIFIED: 品質達成可能性スコアの根拠が『プロンプト設計・コンテンツ設計で達成可能という見込み』にのみ依拠しており、類似コンテンツの実績または検証可能な設計仕様によって裏付けられていない場合に付与する。このフラグが付いた候補を採用する場合、プロトタイプによる検証フェーズを経ることを必須とする。」

品質5の判定条件の修正（最小限）: 「ユーザーが求める品質がアルゴリズム/テンプレートで自動的に達成される。または、コンテンツの性質上ユーザーが求める価値が明確に定義でき、その達成方法が確立されている。ただし、後者の場合、類似コンテンツの実績または具体的な設計仕様による裏付けがない場合はUNVERIFIEDフラグを付与する。」

継続性軸の修正（デイリー機械的適用への対処）: 継続性5の判定条件に「日付シードで毎日新しいコンテンツが自動生成される」の後に「または、コンテンツプールが365件以上あり長期の枯渇リスクがない」を追加し、「コンテンツプールが365件未満の場合は4が上限」という注記を加える。

期待される効果

スコア自体を変えないため、47候補の全件再評価は不要（フラグの付与のみでよい）。品質5の判定の甘さをスコアではなくフラグで可視化するため、採用決定プロセスで参照可能になる。constitution.md Rule 4との矛盾を避けながら、品質が未検証のコンテンツを優先的にプロトタイプ検証にかけるワークフローを設計できる。デイリーゲームの継続性問題も同一の修正で解決できる（Q32とQ26の判定不一致が解消）。

リスク・副作用

スコア自体を変えないため、ランキング順位への直接影響はなく、バイアスの「数値上の是正」にはならない。UNVERIFIEDフラグが付いた候補が採用プロセスで事実上のペナルティになる場合、フラグが実質的に特定ジャンルを不利にする効果を持つ可能性がある（ただしこれはフラグの仕組みの問題であり、ルーブリックの文言の問題ではない）。

また、「類似コンテンツの実績による裏付け」の解釈が広くなると（例: 占い系は市場に無数の類似があるため実績ありと解釈される）、フラグが機能しなくなるリスクがある。この点はフラグの運用基準を補足説明する必要がある。

実施コスト

フラグの追加と品質5・継続性5の文言の部分修正のみで済むため、案の中で最も低コスト。再評価は「品質5を取得している候補のフラグ判定」と「デイリーゲームの継続性再判定（有限プール確認）」に限定できる。

各案の比較表

案	バイアス是正効果	二重ペナルティ解消	再評価コスト	新バイアスリスク	constitution.md整合性
案1: 品質5を「確実性」に引き上げ	高（直接的）	限定的	中（品質5候補の再評価）	低（「確実性」の解釈揺れ）	整合
案2: 品質軸を2軸に分割	高（構造的）	高（構造的解消）	高（全47件再評価）	中（軸の境界曖昧）	整合
案3: OR条件→AND条件	中（案1と類似だが解釈余地大）	限定的	中（品質5候補の再評価）	中（AND条件の解釈揺れ）	整合
案4: 「確度」軸への再定義	高（ジャンル中立）	中（「データが揃えば達成可能」が論理化）	中〜高（全スコアレベル更新）	中（評価者依存の楽観度差）	整合
案5: UNVERIFIEDフラグ追加	低（数値不変）	低（数値不変）	低（フラグ付与のみ）	低	整合

推奨方針

単独案よりも組み合わせが有効と考える。

推奨組み合わせ: 案1 + 案5の継続性修正

根拠:

案1（品質5の判定条件を「確実性」に引き上げ）が根本原因を直接是正する。「プロンプト設計で達成可能」という未検証の楽観論を5の条件から除外することで、機械的な「正確性不要→品質5」パターンが消える。
案5の継続性軸修正（365件未満は4が上限）をあわせて適用することで、デイリーゲームの機械的適用問題も解消できる。
案1の適用後にスコア分布を確認し、依然として偏りが残る場合に案4（軸の「確度」再定義）を追加適用するという段階的アプローチが現実的。
案2（6軸化）は最も根本的だが、47件全再評価の負荷が大きく、採用する場合は次フェーズの評価から適用するのが現実的。

案3は案1と重複するため、どちらか一方を選択すれば十分。案1の方が「確実性」という単一の概念で文言を統一できる点で優れる。