ushironoko/novel-harness-skills/mystery-readers

mystery-readers — 読者検証(フェーズ5)

完成原稿を「読者への挑戦」直前で切り出し、最低10人の並列読者エージェントに読ませて、 探偵の解説前に犯人へ到達できるかを検証する。フェアプレイの実証テスト。

入力

• ~/mystery-novels/<slug>/novel.md（<!-- CHALLENGE-TO-THE-READER --> マーカー必須）
• 採点用に case.json / characters.json（スキルのみが読む。読者には渡さない）

事前に必ず読むもの

• ~/.claude/skills/mystery-readers/references/reader-protocol.md（切り出し・ペルソナ・採点・集計）
• ~/.claude/skills/mystery-novel/references/data-contract.md（ネタバレ境界）

プロトコル

1. 本文の切り出し。reader-protocol.md の awk コマンドで、挑戦マーカー直前までを

~/mystery-novels/<slug>/readers/_challenge_cut.md に出力。マーカーが無ければ 検証不能としてエラー報告（執筆ステップで設置が必要）。切り出し本文に解決編が 混入していないことを確認。

1. 真の答えを取得（スキル内部のみ）。case.json の perpetrator_id を characters.json で

本名に解決し、真犯人名・手段・動機を採点用に保持。この情報を読者プロンプトに含めない。

1. 読者エージェントを並列起動（最低10、推奨12）。1メッセージで Agent を同時発行。

• reader-protocol.md のペルソナを割り当て、多様性を確保。
• 最低1名は `subagent_type: "codex-reviewer"`（クロスモデル読者。CLAUDE.md原則4）。
• 各プロンプトに必ず明記:
• 「readers/_challenge_cut.md だけを読め。プロジェクト内の他ファイル(case.json,

characters.json, novel.md 等)を絶対に開くな。」

• 「あなたは探偵の解説を読む前の読者。犯人・手段・動機を推理し、出力スキーマのJSONで返せ。」
• 各読者は独立。互いの回答を見せない。

1. 採点（スキル側）。各読者の guessed_culprit を真犯人名と照合（表記ゆれ正規化）。

method/motive の概ね一致も判定。各読者結果を readers/<reader_id>.json に保存。 causal_loop 作品のみ: reader-protocol.md の rubric（bootstrap artifact 特定/閉包の把握/ 事件における役割、の3点中2点以上）で loop_seen を判定（読者スキーマは不変。採点側の 追加集計であり、読者への指示は変えない）。

1. 集計。readers/aggregate.json を reader-protocol.md のスキーマで作成:

solve_rate・method_hit_rate・motive_hit_rate・guess_distribution・ clues_readers_found / clues_readers_missed・fairness_signal・notes。 fairness_signal は trick_complexity(tier)依存で判定する。meta.json の settings.trick_complexity（または case.json の trick.complexity_tier、無ければ tier3）を 読み、reader-protocol.md の tier 別目標帯と観測 solve_rate を照合して good / too_easy / unfair_or_too_hard を決める。tier と target_band も aggregate に記録。 難度proxyも集計（LLM読者はsolve_rate飽和するため）: suspicion_spread（1人あたりseriously_suspected 平均数。1に近い＝曖昧さ不足）、misled_rate（misled_by が非空の読者率。低い＝偽の解決が不発）、 meta_guess_rate（reasoning_type=meta_guess の率。高い＝勘で当てられている）、lie_detected_rate （suspected_lies 非空率。低い＝A9違反の疑い）。solve_rate が高くてもこれらが悪ければ「難度不足」と診断。 causal_loop 作品のみ `loop_seen_rate` も集計する（loop 看破＝how軸が高くても who が 割れていれば健全。loop_seen_rate 単独で too_easy と診断しない）。

1. meta.json 更新。phases.readers.status="done"、phases.readers.solve_rate を記録。

1. 報告。solve_rate と fairness_signal、適用した tier と目標帯、推測分布（真犯人 vs

レッドヘリング/偽の解決）、見落とされた重要手掛かり、フェアネス所見を提示。

完了条件

• 読者エージェントを10名以上（codex 読者を含む）起動・採点済み。
• readers/aggregate.json 生成、meta.json に solve_rate 反映。

フェアネス所見の活用（→難易度修復へ還流）

• 読者検証は診断で終わらせず、too_easy を設計修復へ還流する。判定は方向を区別し、

LLM読者の正答率飽和を考慮する（reader-protocol.md「難易度修復のトリガ」）:

• too_easy（真犯人が首位 かつ Wilson 下限が帯上限超 かつ 難度proxy が退化＝spread<1.5 or

misled<0.25 or meta_guess>0.4、または who 一点集中）→ 設計レベルで A10 機会独占／A11 物証集中／ A12 動機独占／A13 過剰決定の解消・B 断片化の修復（workflows/mystery-batch.mjs の難易度ループ）。

• llm_saturated（solve 高いが proxy 全て健全）→ LLM超読者の飽和とみなし難易度UPしない。

人手/より難しい読者での確認に委ねる。

• too_hard/unfair（solve が帯下限未満・真犯人に票が入らない）→ 難易度UPはせず、手掛かり

補強／フェアネス見直し。

• in_band → 修復不要。
• 難易度UP修復はフェアネス退行禁止（load-bearing 手掛かりを削除・曖昧化して難しくするのは

反則）。修復後は再監査で fairplay_clues/knox の pass 維持を確認、崩れたら巻き戻す。

• 単体実行時はユーザーへ所見（方向つき）を提示する。