logical-consistency-reviewer

name	logical-consistency-reviewer
description	文章、記事、レポート、企画書の論理破綻をレビューし、論点、必要情報、推論、結論と根拠の構造を確認する。Why So、So What、MECEの観点で飛躍、矛盾、論点ずれ、根拠不足を検出する。公開前や改稿前に文章の筋道を点検するときに使う。単なる校正、文体調整、事実確認のみ、法的助言、数学的証明の厳密検証には使わない。

論理整合性レビュー手順

文章・記事・レポート・企画書の論理破綻を検出し、結論、根拠、解釈、構造のつながりを点検する。文章の美しさよりも、論点に対して筋道が通っているかを優先する。

使用条件

次の場合に使う。

• 文章の主張が論理的に成立しているか確認する必要がある。
• 公開前の記事、提案書、説明文、論考、研究メモをレビューする必要がある。
• 結論と根拠の関係、飛躍、矛盾、論点ずれ、MECE漏れを検出する必要がある。
• 修正方針として、どの段落をどう直すべきか示す必要がある。

次の場合には使わない。

• 誤字脱字、文体、自然さだけを直す。
• 出典の真偽確認だけを行う。
• 法的判断、医療判断、数学的証明の厳密検証を代替する。
• 文章が存在せず、ゼロから構成案だけを作る。

基本姿勢

1. 結論を先に特定する。
2. 論点と関係しない表現上の好みを混ぜない。
3. 事実、解釈、評価、提案を分けて扱う。
4. 「根拠が弱い」と「論理が破綻している」を区別する。
5. 断定できない場合は「未検証」「根拠不足」「推論の飛躍」と明示する。
6. 修正案は、抽象的な助言ではなく、文章上の具体的な操作として提示する。

レビュー手順

1. 対象と目的を確定する

1. 入力文章、想定読者、文章の目的を確認する。
2. 目的が不明な場合は、文章内の手がかりから暫定目的を置く。
3. 暫定目的を置いた場合は、レビュー冒頭に「暫定前提」として明記する。
4. 文章が長い場合は、章、段落、見出し単位で番号を付けて参照できるようにする。

2. 論点を決める

1. 文章が答えようとしている問いを一文で抽出する。
2. 論点が複数ある場合は、主論点と副論点に分ける。
3. 論点が曖昧な場合は、以下のどれが曖昧かを示す。
   • 対象: 何について述べているか。
   • 判断軸: 良い、悪い、必要、有効などを何で判断しているか。
   • 範囲: どこまでを扱い、どこから扱わないか。
   • 読者行動: 読者に何を理解、判断、実行させたいか。

3. 必要情報を分解する

1. 論点に答えるために必要な情報カテゴリを列挙する。
2. 文章内にある情報と、不足している情報を分ける。
3. 各情報を次の型に分類する。
   • 事実: 観察、データ、引用、出来事。
   • 定義: 用語、範囲、前提条件。
   • 因果: AがBを引き起こすという説明。
   • 比較: AとBの差、優劣、トレードオフ。
   • 価値判断: 望ましい、危険、有益などの評価。
   • 提案: 取るべき行動や選択肢。
4. 情報不足が結論に影響する場合は、重大度を付ける。

4. 情報から何がいえるかを点検する

1. 各根拠から導かれている解釈を抽出する。
2. 推論の型を判定する。
   • 演繹: 一般原則から個別結論を導く。
   • 帰納: 複数事例から一般化する。
   • アブダクション: 最もありそうな説明を仮説として置く。
3. 型ごとに破綻を探す。
   • 演繹: 前提が結論を本当に含意しているか。
   • 帰納: 事例数、代表性、反例の扱いが十分か。
   • アブダクション: 代替仮説を無視していないか。
4. 以下の典型的な論理破綻を検出する。
   • 結論先取り: 根拠が結論を言い換えているだけ。
   • 飛躍: 根拠から結論までの中間説明がない。
   • 論点ずれ: 根拠が主論点ではなく別問題に答えている。
   • 過度な一般化: 限定的な事例から広い結論を出している。
   • 偽の二分法: 選択肢が二つしかないように扱っている。
   • 因果と相関の混同: 同時発生を原因として扱っている。
   • 循環論法: 結論を前提として使っている。
   • 藁人形化: 反対意見を弱く単純化している。
   • 曖昧語のすり替え: 同じ語が途中で別の意味になる。
   • 必要条件と十分条件の混同。

5. 論理を構造化する

1. 文章の最終結論を頂点に置く。
2. 主要根拠をその下に並べ、ピラミッド構造として整理する。
3. 各階層で Why So? を問う。
   • 上位主張に対して、下位根拠が「なぜなら」と答えているか確認する。
4. 各階層で So What? を問う。
   • 下位根拠から、上位主張が「だから」と自然に導けるか確認する。
5. 同じ階層の根拠がMECEに近いか確認する。
   • 漏れ: 結論に必要な論点が欠けていないか。
   • ダブり: 同じ根拠を別名で繰り返していないか。
   • 粒度: 抽象度の違う項目が同列に並んでいないか。
6. 構造化した結果、文章順が論理順とずれている場合は並べ替え案を出す。

6. 重大度を判定する

各問題に重大度を付ける。

• 致命的: 結論が成立しない、逆の結論も同程度に成り立つ、主要前提が矛盾している。
• 重大: 主張はあり得るが、重要な根拠、定義、中間説明が欠けている。
• 軽微: 局所的に分かりにくい、根拠の配置や接続語が弱いが、全体結論は残る。
• 補足: 論理破綻ではないが、読者が疑問を持ちそうな補足点。

7. 修正案を作る

1. 問題ごとに、該当箇所、問題、理由、修正方針を示す。
2. 致命的または重大な指摘には、可能な限り書き換え例を付ける。
3. 根拠不足の場合は、必要な情報の種類を指定する。
4. 論点が多すぎる場合は、削る論点、残す論点、別記事に分ける論点を提案する。
5. 文章の意図を勝手に変えない。複数の修正方向がある場合は選択肢として示す。

出力形式

短いレビューでは次の形式で答える。

## 論理整合性レビュー

### 暫定前提
- 目的:
- 想定読者:
- 主論点:

### 結論
- 判定: 問題なし / 軽微な修正で可 / 要修正 / 結論再設計が必要
- 最大の論理リスク:

### 論理構造
- 最終結論:
- 主要根拠:
  1.
  2.
  3.

### 指摘事項
| 重大度 | 箇所 | 問題 | なぜ問題か | 修正方針 |
|---|---|---|---|---|

### 修正優先順位
1.
2.
3.

長いレビュー、公開前原稿、重要な意思決定文書では、assets/review-template.md を読んで詳細版の形式を使う。

検証

1. 出力前に references/checklist.md を読み、レビュー漏れがないか確認する。
2. レビューをファイルに保存した場合は、次の検証スクリプトを実行する。

python3 scripts/check-review-output.py path/to/review.md

3. スクリプトが失敗した場合は、不足セクションを追加して再実行する。

エラー処理

• 入力文章が短すぎる場合は、暫定的に評価できる範囲を示し、必要な追加情報を列挙する。
• 論点が複数競合している場合は、最初に論点候補を分け、どれを主論点にするか確認する。
• 事実確認が必要だが外部調査していない場合は、「事実関係は未検証」と明記する。
• 修正案が複数あり得る場合は、目的別に選択肢を出す。
• 文章の専門領域が不明な場合は、論理構造だけを評価し、専門的妥当性は未検証とする。