指摘: コンテンツとサイトコンセプトの混同、評価スコアの不正確さ

問題1: コンテンツとサイトコンセプトが混ざっている

今のブラインド比較では、コンテンツ案とサイトコンセプト案が混在しており、コンテンツの評価軸で一律に評価されていた。これではあまり意味がない。

サイトコンセプトとは

• サイト全体の方向性を決めるもの
• 全体の統一感を押さえつつ、複数のターゲットに対して複数のコンテンツを提供し、回遊やリピートを狙うための戦略
• 評価軸: マーケットの大きさ、競合プレイヤーの規模や強さ、拡散されやすさ、回遊性の高さ、など

コンテンツ案とは

• サイトコンセプトを支えるパーツ
• それぞれが特定のターゲットを持つ
• 評価軸: 独自性、実現可能性、品質達成可能性、など

問題2: 評価スコアが不正確

anonymized-candidates-v2.md に記載されているスコアに疑問がある:

• Q34 漢字クイズの品質達成可能性=4: 2週間で80字の低品質データしか作れなかった実績があるのに4は高すぎる
• Q24 AI実験ブログの独自性=3: 世界的にも例がないとされるコンテンツなのに独自性3は低すぎる
• Q42 日本語クイズの品質達成可能性=4 vs Q43 ユーモア占いの品質達成可能性=3: 高度な正確さが求められるQ42が4で、不正確でも構わないQ43が3なのはおかしい
• 占い系の実装可能性=4: シンプルにランダムな結果を出すだけの占いが実装可能性5ではなく4なのは不適切

→ より厳密な評価尺度を導入すべき。

正しい作業手順

1. コンテンツ案だけの形に作り直す: サイトコンセプト的なもの（キャラ占いプラットフォーム等）を除外し、個別コンテンツの粒度に揃える
2. 厳密な評価尺度で再評価: 各評価軸の基準を明確に定義し、既存実績も考慮した正確なスコアリング
3. コンテンツをまとめてサイトコンセプトを複数作成: 実現可能なコンテンツ群をどう組み合わせるかという戦略レベルの検討
4. 有力なサイトコンセプト案を選定: サイトコンセプトの評価軸（市場規模、競合、拡散性、回遊性等）で評価

コンテンツ候補の厳密な評価尺度の定義

背景

Owner指摘（19cb921ed73）により、現行の5軸評価スコアが不正確であることが判明。 より厳密な評価尺度を定義し、全コンテンツ候補を再評価する必要がある。

依頼内容

以下の評価軸について、各スコア（1-5）の明確な判定基準を定義してください。

評価軸

1. 独自性: 日本語Web市場で類似サービスがどの程度存在するか
2. 需要: ターゲットユーザーの規模と検索需要
3. 実装可能性: 技術制約（.claude/rules/coding-rules.md参照）の中で実装できるか
4. 継続性: リピート訪問の動機付けと、コンテンツ更新の持続可能性
5. 品質達成可能性: AI運営チーム（LLM + 自動化）で十分な品質を達成・維持できるか

各スコアの判定基準の要件

各軸について、スコア1-5それぞれに 具体的な判定条件 を設けてください。例えば:

品質達成可能性の例:

• 5: テンプレート/アルゴリズムベースで、人間の専門知識や正確性の検証が不要（例: ランダム結果生成、日付シードのゲーム）
• 4: データは必要だが、正確性への要求が低く、AI生成テキストで十分（例: ユーモア系コンテンツ）
• 3: 一定の正確性が必要だが、小規模なデータセット（100件以下）で成立（例: クイズ20問）
• 2: 大規模なデータセットが必要、または高度な正確性が求められる（例: 辞書、学習教材）
• 1: 専門家の監修が必須、またはリアルタイムの正確性が必要（例: 医療情報、法律相談）

実装可能性の例:

• 5: HTMLとCSS＋簡単なJS、またはテンプレートベースで完結（例: 占い、簡単なジェネレーター）
• 4: クライアントサイドJSでゲームロジック実装（例: ボードゲーム、パズル）
• 3: 複雑なアルゴリズムやデータ構造が必要（例: AI対戦、複合ゲーム）
• 2: サーバーサイド処理やビルド時の複雑な生成が必要
• 1: 外部API・DB・認証が必要で技術制約に抵触

重要な考慮事項

• 既存実績を考慮する: このサイト（yolos.net）で既に運営しているコンテンツがある場合、その実績（品質、制作にかかった時間、課題）を基準に反映すること
  • 例: 漢字辞典は2週間で80字、品質も不十分だった → 品質達成可能性の低い例
  • 例: 既存のデイリーゲーム4種は稼働中 → デイリーゲームの実装可能性は実績あり
• 不正確で構わないものと正確性が必要なものを区別する: ユーモア占い（不正確でも面白ければOK）とクイズ（正解が必要）では品質達成可能性の基準が異なる
• 「ランダム結果を出すだけ」は実装可能性5: 占いやジェネレーターの実装はシンプルなランダム生成であり、最も容易な部類

出力

docs/forced-ideation/evaluation-rubric.md に評価ルーブリックを出力してください。

評価ルーブリック作成完了

成果物

docs/forced-ideation/evaluation-rubric.md に評価ルーブリックを出力しました。

内容概要

5つの評価軸それぞれについて、スコア1-5の具体的な判定基準を定義しました。

各軸の設計方針

1. 独自性: 日本語Web市場での競合数と大手の存在を基準に5段階。大手寡占=1、空白市場=5。
2. 需要: 検索ボリュームとターゲット人口規模を基準に5段階。数千人以下=1、日本人口の10%以上=5。
3. 実装可能性: coding-rules.mdの技術制約を前提に、実装工数と技術的複雑さで5段階。外部API必須=1、テンプレートベース=5。
4. 継続性: リピート訪問の動機と更新の持続可能性の両面。一度見たら終わり=1、日付シードで自動更新=5。
5. 品質達成可能性: AI運営チームで達成できる品質レベル。専門家監修必須=1、アルゴリズムが正確性を保証=5。

Owner指摘への対応

• 漢字辞典の実績（2週間で80字、品質不十分）: 品質達成可能性=2の基準例として明記。大規模辞典はスコア2が標準。
• 占い系の実装可能性: ランダム結果生成はスコア5と明記（テンプレートベースで完結するため）。
• 不正確OK vs 正確性必須の区別: 品質達成可能性の最重要原則として「不正確でも成立するコンテンツは高スコア」を明記。
• 既存実績の優先: デイリーゲーム4種（稼働中）、開発者ツール35種（品質安定）、漢字辞典（品質不十分）の実績を基準点として組み込み。

追加した仕組み

• VETOフラグ: いずれかの軸が1の場合、総合スコアに関わらず採用不可を示す。
• RISKフラグ: 品質達成可能性または実装可能性が2以下の場合、リスク軽減策が必要。
• PROVENフラグ: 既存サイトでの稼働実績がある場合、スコアの信頼性が高いことを示す。
• 適用時の注意事項: コンテンツ形式ごとの標準スコア傾向を明記し、評価のブレを防止。