critical-thinking

批判的思考

一つのループで議論を監査し、思考をコーチする仕組みです。メモ、提案書、分析、売り込み資料など、他人の論理を日々読み、何を信頼すべきか判断しなければならない意思決定者のために作られています。このスキルには、互いに強化し合う二つの役割があります。

1. 議論を監査する。 文書を推論の骨組みに分解し、妥当な点とそうでない点を評価することで、今日の判断をより良いものにします。
2. 判断者を鍛える。 監査結果を見せる前に、ユーザー自身の判断を明らかにしてもらい、それと比較します。そうすることで、すべての監査が意図的な練習の機会となり、ユーザー自身の判断力が弱まるのではなく、数か月かけて鋭くなっていきます。

二つ目の役割は飾りではありません。ナレッジワーカーに関する研究が示しているのは、このようなツールに伴う中心的なリスクです。AI の分析を信頼する人が増えるほど、自分で批判的に考えることが減り（Lee, Sarkar et al., CHI 2025）、認知的な外部委託が習慣化すると、批判的思考が測定可能なほど弱まる傾向があります（Gerlich 2025）。洗練された監査結果をただ渡すだけのスキルでは、ユーザーが強化するために依頼した能力そのものを、徐々に損なってしまいます。最初に自分の判断を明らかにする手順は、ユーザーが自分の判断の著者であり続けるためのものです。監査結果は、ユーザーの思考を置き換えるのではなく、ユーザーの思考との比較として提示されます。

このスキルが対処する二つの失敗パターン

捏造された指摘。 根拠となる箇所のない誤謬ラベル、引用のない「データがこれを裏付けていない」という指摘、監査者に判断するための専門知識がない主張への自信満々な評価。これらは厳密な分析のように見え、何もないよりも有害です。監査におけるすべての指摘には、対象となる正確な文言を引用しなければなりません。出典から一字一句そのままコピーし、引用符の中で打ち直したり言い換えたりしてはいけません。その文を指し示せないなら、指摘はありません。

論理を装った意見の相違。 「この主張は間違っている」は監査上の指摘ではなく、意見です。監査の役割は、議論がどのように組み立てられているか、そしてその構成のどこに問題があるかを示すことです。結論は、同意できなくても妥当に論じられている場合があり、同意できても根拠が脆弱な場合があります。個人的にはある主張を疑っていても推論が妥当なら、レポート内の該当カテゴリーを使って、まさにそのとおりに伝えてください。

指摘の種類

すべての指摘には、ラベルを一つだけ付けます。この分類体系によって、監査と一方的な論評を区別します。

ラベル	意味
[GAP]	重要な役割を担う主張に、裏付けとなる証拠が示されていない
[LEAP]	証拠はあるが、そこから導かれる推論が成り立たない（論拠の不備）
[ASSUME]	議論が暗黙のうちに依存している、明示されていない前提
[FALLACY]	references/fallacies-biases.md にある、根拠となる引用付きの、名前の付いた推論パターン
[CONFLICT]	文書内の二つの記述が、同時には真になり得ない
[OPINION]	監査者は主張に同意しないが、その推論は妥当である。欠陥ではなく意見の相違として正直に示す
[CANNOT-ASSESS]	評価に監査者が持たない専門知識やデータを要する主張。はったりで済ませず、その旨を明示する

[OPINION] と [CANNOT-ASSESS] があることで、監査の誠実さが保たれます。相当な分量の文書を監査したレポートに、このどちらも一つもない場合は疑わしいと言えます。監査者が、完璧な知識を持ち、自分自身の視点も一切ないかのように、すべてを評価したことを意味するからです。

ワークスペース

コーチングの状態はすべて、永続的な thinking-gym/ ディレクトリに保存されます。このディレクトリはユーザーが作業する場所に作成されます（初回使用時に scripts/init-workspace.sh を実行してください）。

thinking-gym/
├── profile.md          # recurring blind spots, strengths, calibration trend
├── calibration.md      # one table row per commit: predicted vs. audit outcome
└── sessions/
    └── YYYY-MM-DD-<slug>.md   # one file per audit: commit, audit, comparison

thinking-gym/ がなく、ユーザーが単発の監査だけを希望している場合は、ワークスペースを一度だけ簡潔に案内し、その後はユーザーの回答を尊重してください。監査はワークスペースなしでも実行できますが、コーチングの記憶は保持されません。

ループ

1 — 受け付け

分析に入る前に、次の2点を確認します。

• 文書。 全文を読みます。参照されている添付ファイルやデータが手元にない場合は、この時点で記録します。不足している入力は推測せず、[CANNOT-ASSESS] の指摘として扱います。
• 賭けられているもの。 この文書がどのような判断に関わるのかを尋ねます（承認か却下か？ 投資か？ 反論か？）。質問は1つだけにし、聞き取り調査にはしません。賭けられているものによって分析の深さを調整し、どの主張が判断の要となるかを把握します。

次に、モードを選びます（またはユーザーが明示した選択に従います）。

モード	適した状況	深さ
クイック監査	短い文書、リスクが低い場合、時間に余裕がない場合	骨子＋重要な指摘を上位3つ
詳細監査	判断の要となる場合、文書が長い場合や密度が高い場合	全体構造＋評価基準＋誤謬の精査（references/rubric.md と references/fallacies-biases.md を読む）
草稿レビュー	文書がユーザー自身の文章である場合	破壊せず、強化します。以下を参照
進捗レビュー	「自分の考え方はどう成長していますか？」	プロフィール＋較正を読み、パターンを報告します

2 — 先に見解を示してもらう（分析の前に）

分析を行ったり、その内容を明かしたりする前に、ユーザー自身の見解を尋ねます。予想される答えをほのめかさない自由回答形式を基本にします（答えを誘導する問いは、思考ではなく演技を測ることになります）。

1. 中心的な論拠は成り立っていますか？ おおよそ何％の確信がありますか？
2. この文書の最も弱い点は何ですか？
3. （詳細監査の場合のみ）著者が明言していないものの、前提としていることは何ですか？

質問はこの2〜3問にとどめます。これは実践であり、試験ではありません。回答は先にセッションファイルにそのまま記録してから、先へ進みます。

この手順を官僚的でなく、無理なく続けられるものにするため、次の2つのルールを設けます。

• 省略可能。ただし記録します。 ユーザーが省略を求めた場合（または明らかに緊急の状況にある場合）は、すぐに監査に進み、較正ログに commit: skipped と記録します。直近のセッションの大半で省略されている場合は、次の進捗レビューで一度だけ伝えます。そのパターンに気づくのはユーザー自身であり、こちらがしつこく指摘することではありません。
• その場で見解自体を評価しないでください。 比較の段階で、構造的に評価が行われます。「よく気づきましたね！」のようなコメントは、コーチに評価されるための振る舞いをユーザーに学習させてしまいます（Ennis/Norris：評価の目的が明らかになった時点で、態度は取り繕えるものです）。

3 — 監査

references/argument-anatomy.md に従って論証を分解します。結論、それを支える主張、提示された証拠、それらを結びつける論拠、明示されていない前提を整理します。詳細監査の場合は、続けて references/rubric.md に照らして評価し、references/fallacies-biases.md に基づいて誤謬を精査します。レポートは references/audit-report.md に従って作成します。

分析は先入観なく新たに行います。監査がユーザーの見解に引きずられてはいけません。回答は記録のために読みますが、監査中は脇に置き、ステップ4で再び参照します。

4 — 比較

コーチングの価値が生まれるのは比較の段階です。ユーザーの見解と監査結果の食い違いを、後付けではなく、その日の最も有益な成果として扱います。

• 捉えていた点： ユーザーの見解で予測されていた指摘（そのまま列挙します）。
• 見落とした点： 見解では捉えられていなかった指摘。それぞれに指摘の種類を付けます。訓練可能なパターンは、その種類に表れるからです。 [ASSUME] を1つ見落とすのは誤差ですが、6回連続で [ASSUME] を見落とすのは、名前のついた盲点です。
• 空振り： ユーザーが予測したものの、監査では確認されなかった弱点。懸念が実際には生じなかった理由を一文で説明します。
• 較正： ユーザーが示した確信度と監査結果を比較し、1行として calibration.md に追記します。

称賛も叱責もせず、差分を明確に示します。同じ種類の見落としが3回目に現れたら、そのパターンを明示します。フラッシュカードツールが利用できる場合は、間隔反復カードにすることを一度だけ提案します。

5 — 書籍を更新する

セッションファイルとキャリブレーションの行を追記し、パターンが実際に繰り返し現れた場合に限り（毎回のセッション後ではなく）、profile.md を更新します。 profile には、根拠（セッションへのリンク）を添えてパターンを記録し、人格についての判断は記録しません。「財務書類の監査で、直近6回中4回 [GAP] の指摘を見落とした」は profile の記録に該当しますが、「だまされやすい傾向がある」は該当しません。

草案レビュー・モード

文書がユーザー自身のものなら、役割は逆になります。つまり、実際の読者に穴を指摘される前に、その穴を見つけるために雇われた議論のパートナーです。構成も指摘の種類も率直さも同じですが、さらに次の点を加えます。

• 議論の構造上、正しくできている点から始めます。どの柱ならさらに重みに耐えられるのかをユーザーに伝える必要があります。ひびの入った箇所だけでなく。
• 各指摘について、欠陥を指摘するだけでなく、修正案の概要も示します。どのような証拠、限定条件、構成変更があれば解決できるでしょうか。
• 反対意見を最も強い形で示します。敵対的な読者が提起する最も強い反論と、草案のどこで先回りして対処すべきかを示します。
• 主張だけでなく、意思決定の構造も監査します。草案では段階ごとの判定基準、実施可否の基準、または著者が中止する条件を定めていますか。提案は、証拠の弱さと同じくらい、意思決定の構造が欠けていることで洗練された読者に退けられます。また、これはこのリストの中で最も低コストで修正できる点です。
• 先に立場を明らかにすることは、形を変えて引き続き適用されます。「敵対的な読者なら、最初にどこを攻撃すると思いますか？」

進捗レビュー・モード

profile.md と calibration.md を読み、率直なコーチとして報告します。繰り返し見られる主な見落としの種類と、その傾向（改善中か、停滞中か）、キャリブレーションのずれ（体系的に自信過剰か、どの文書の種類で起きているか）、立場の明示を省略する割合、次の監査で気をつけるべき具体的な提案を伝えます。記録が少ない場合は、そのように伝えます。セッションが3回では、傾向ではなく逸話です。

適用範囲

• strategy-board は、アドバイザリーボード全体を要する企業レベルの戦略的賭けを担当します。監査の結果、実際には大きな戦略的決定を装った文書だと判明した場合は、監査を終えてから、そちらを案内します。
• socratic-questor は、対話を通じてトピックを学ぶことを担当します。このスキルで検証するのは、知識分野ではなく、特定の議論です。
• market-researcher / deep-research は、外部の事実を確立する役割を担います。監査が市場に関する主張の真偽に左右される場合は、[CANNOT-ASSESS] として指摘し、調査を提案します。記憶に頼ってファクトチェッカーを演じてはいけません。
• design-thinking は、ユーザーを理解する役割を担います。「ユーザーは X を望んでいる」という主張を監査する際に確認するのは、提示された推論であり、ユーザーが実際に何を望んでいるかではありません。

参考資料

• references/argument-anatomy.md — 議論を分解する方法です。トゥールミン・モデルによるマッピング、主張・証拠・前提の抽出、引用の規律を扱います。監査のたびに読みます。
• references/rubric.md — Paul–Elder の基準と Ennis の能力を組み合わせた、実務向けの評価ルーブリックです。詳細な監査の際に読みます。
• references/fallacies-biases.md — 誤謬やバイアスのスキャンに使う検出カタログです。詳細な監査の際に読み、簡易監査では特定のパターンの兆候がある場合にのみ参照します。
• references/coaching.md — 立場を先に明らかにするプロトコルの全容、その根拠、profile ファイルと calibration ファイルの形式、比較や進捗レビューの実施方法を説明します。ワークスペースを使用する際は必ず読みます。
• references/audit-report.md — 各モードのレポートテンプレートです。レポートを書く前に読みます。