scenario-quality-review

name	scenario-quality-review
description	シナリオの「魅力」と「読者体験」を検証するセルフレビュースキル。 lintが捕捉する構造的問題（会話比率、ナレーション連続等）の上位レイヤーとして、 「読者が自然に読めるか」「引き込まれるか」「疑問を持たないか」を検査する。 「レビューして」「セルフレビュー」「品質チェック」「読者視点で確認して」 「唐突感がないか見て」「魅力的か確認して」といった依頼で発動。 シナリオ執筆後のセルフレビューフェーズで必ず使うこと。

シナリオ品質レビュースキル — 読者の目で検査する

lintは「壊れていないか」を検査する。このスキルは「魅力的か」を検査する。 両方通って初めて、シナリオは出荷可能になる。

---

レビューの実行手順

Step 0: 前提確認

レビュー対象の章を読む前に、以下を準備する:

1. 対象章のファイルを全文読む
2. 前章のファイルを全文読む（接続の自然さを検証するため）
3. characters.mbt の該当キャラ設定を確認する
4. lint結果を確認する（npm run lint:scenario で構造的問題を先に潰す）

Step 1: 7つの検査軸でレビューする

以下の7軸それぞれについて、問題箇所を具体的な行番号とともに報告する。

---

検査軸 1: 唐突感検出

読者が「え？」と思った瞬間、物語への没入が切れる。

チェック項目

• シーン間の接続: 前シーンの結果状態 → 次シーンの冒頭が自然に繋がるか
• キャラの登場: 新キャラの初登場に「なぜここにいるか」の手がかりがあるか
• 行動の動機: キャラの行動に「なぜ今それをするか」が読み取れるか
• 感情の変化: 感情が変わる場合、変化のきっかけ（イベント）が先にあるか
• 視点の切替: 視点が変わる場合、読者に混乱なく伝わるか

判定基準

OK:   読者が立ち止まらずに読み進められる
WARN: 一瞬「ん？」となるが、前後の文脈で補完できる
NG:   読者が戻って読み直す必要がある、または理解できない

---

検査軸 2: 読者の疑問検出

読者が「なんで？」と思って答えが見つからない箇所は、没入の穴になる。

チェック項目

• 因果の欠落: 行動Aの結果としてBが起きているが、A→Bの繋がりが不明
• 不自然な無反応: キャラが当然反応すべき出来事にノーリアクション
• 説明不足の設定: 読者が「そもそもなぜ？」と思う前提が未説明
• 物理的矛盾: 距離、時間、道具の扱いに無理がないか

報告フォーマット

[疑問] L{行番号}: {読者が持つであろう疑問}
  → 原因: {なぜこの疑問が生じるか}
  → 対策: {どう修正すれば疑問が解消されるか}

---

検査軸 3: 「初めて」矛盾検出

「初めて〜した」は強い表現。前のシーンで同等の出来事があると即座に矛盾する。

チェック項目

• テキスト内の「初めて」「初めての」を全て抽出する
• 各「初めて」について、前章・前シーンで同種の出来事がなかったか検証する
• 矛盾がある場合、「初めて近くで〜」のように修飾語で限定するか、表現を変える

よくあるパターン

表現	よくある矛盾	修正例
「初めて声を聞いた」	前シーンで同じキャラが話している	「初めて、近くで声を聞いた」
「初めて目が合った」	前シーンで視線が交差している	「初めて、ちゃんと目が合った」
「初めて名前を知った」	前シーンで名前が出ている	削除するか、別の表現に

---

検査軸 4: 反復演出の前提確認

「ページがめくれなかった」のような反復演出は、オリジナルが先にないと機能しない。

チェック項目

• 反復演出（同じフレーズ・同じ仕草・同じ構造の再利用）を全て抽出する
• 各反復について、オリジナルの初出箇所を特定する
• オリジナルが対象章より前にあることを確認する
• 反復の間隔が適切か確認する（近すぎると効果が薄い、遠すぎると読者が忘れる）

判定基準

OK:   オリジナルが1-3章前にあり、印象的な場面で使われている
WARN: オリジナルが5章以上前。読者が覚えているか不安
NG:   オリジナルが存在しない、または同じ章内で反復（近すぎて演出効果なし）

---

検査軸 5: キャラの魅力度チェック

character-appeal スキルの簡易版。この章でキャラが「愛される」方向に動いているか。

チェック項目

• 主人公: ツッコミや軽い言葉で親しみやすさがあるか（重い内省に沈んでいないか）
• ヒロイン: 行動の変化に読者が「あっ」と気づけるか（言葉ではなく行動で見せているか）
• サブキャラ: 登場する意味があるか（ただの情報伝達役になっていないか）
• 全キャラ: characters.mbt の voice/mannerisms と矛盾していないか

魅力の3指標

指標	定義	チェック方法
共感性	読者が「分かる」と思える言動があるか	モノローグが「俺もそう思う」と思えるか
意外性	「この人こういう面もあるんだ」がこの章にあるか	キャラの新しい一面が1つ以上あるか
一貫性	前章までの言動と矛盾しない範囲の変化か	characters.mbt の設定と照合

---

検査軸 6: テンポとペーシング

読者の「ページをめくる手」が止まらないか。

チェック項目

• 冒頭の掴み: 最初の3行で「続きが気になる」要素があるか
• 中だるみ: 「何も起きない」区間が10行以上続いていないか
• クライマックスの位置: 章の最も印象的な瞬間が後半1/3にあるか
• 余韻の適切さ: ラスト3-5行に余韻があるか（ぶつ切りになっていないか）
• シーン間ブリッジ: シーンの切り替わりに「橋渡しの要素」（物、感覚）があるか

テンポの波形チェック

章全体を5等分し、各区間の「動き」を判定する:

理想:  静→動→動→静→余韻
危険:  静→静→静→動→ぶつ切り（序盤が退屈）
危険:  動→動→動→動→動（休む間がなく疲れる）

---

検査軸 7: サブテキスト（言外の意味）の豊かさ

ADVの魅力は「書かれていないこと」にある。読者が行間を読める余白があるか。

チェック項目

• 直接的すぎる感情表現: 「嬉しかった」「悲しかった」を使っていないか → 行動で見せているか
• 読者だけが知る情報: 主人公が気づいていないが読者は分かる要素があるか
• 二重の意味: 会話やナレーションに表面的な意味と深い意味の二層があるか
• 余白: 「……」や沈黙が「何も言えない」のではなく「言えないことがある」を伝えているか

---

Step 2: レビュー結果の出力フォーマット

以下の形式で報告する:

## シナリオ品質レビュー: {章タイトル}

### サマリー
- 総合評価: {S/A/B/C}
- 最重要の問題: {1行で}
- 最大の強み: {1行で}

### 問題一覧（重要度順）

| # | 検査軸 | 行 | 重要度 | 問題 | 対策 |
|---|--------|-----|--------|------|------|
| 1 | ... | L{n} | HIGH/MED/LOW | ... | ... |

### 良い点

- {具体的な行番号とともに、なぜ良いかを説明}

### 修正優先度

1. {最優先で直すべきもの}
2. {次に直すべきもの}
3. ...

総合評価基準

S: HIGH問題なし。そのまま出荷可能
A: HIGH問題なし。MED問題が1-2個。軽微な修正で出荷可能
B: HIGH問題が1-2個。修正が必要だが構造は健全
C: HIGH問題が3個以上、または構造的な書き直しが必要

---

Step 3: lint との連携

レビュー実行前に必ず npm run lint:scenario を実行し、構造的問題を先に解消する。 lint が WARN/ERROR を出している状態でこのレビューを実行しても、 lint で捕捉される問題が結果に混ざってノイズになる。

実行順序:

1. npm run lint:scenario → 構造的問題を修正
2. このスキルでレビュー → 品質問題を修正
3. 再度 npm run lint:scenario → 修正が新しい構造問題を生んでいないか確認

---

補足: 検査軸の拡張方法

新しい検査軸を追加する場合:

1. 「この問題は決定的にlintできるか？」を先に判断する
2. YES → src/lint/lint.mbt にルールを追加する（harness-engineering スキル参照）
3. NO → このスキルに検査軸を追加する
4. 追加後、既存の全章に適用して問題がないか確認する