thinking-dual-process

デュアルプロセス思考

概要

言語モデルは、プロンプトに続く可能性が統計的に最も高い内容を素早くパターン補完して、最初の回答を生成します。この高速な処理は、定型的で十分に確立されたタスクには非常に有効ですが、重大な結果を伴うタスクや不慣れなタスクでは危険です。そうしたタスクでは、もっともらしく聞こえる回答と正しい回答が食い違うことがあるからです。このスキルは、その高速な処理に意図的に歯止めをかけるものです。重要なタスクで答えがあまりにも簡単に出てきたら、回答を確定する前に明示的な検証を一度行います。

この考え方は、Kahneman の速い思考と遅い思考の区別に由来しますが、ここでの実用的な考え方は心理的なものではなく、機械的なものです。つまり、高速な生成（即座の補完）と意図的な確認（回答を再導出する、テストする、または根拠を探す）です。

基本原則： 流暢さは正しさを保証しません。答えが簡単に出てきて、なおかつ間違えたときの損失が大きい場合、その組み合わせは、検証を終えてよいという合図ではなく、いったん立ち止まって確認するきっかけです。

トリガーカード

重大な結果を伴うタスクや不慣れなタスクで答えが即座に出てきたら、回答を確定する前に検証を一度行います。

1. 気づく： 途中の手順を経ずに、答えがすぐに浮かびましたか？ 何も確認していないのに、自信だけは高い状態ですか？
2. トリガーを確認する： そのタスクは重大な結果を伴う／取り消せないものですか、それとも不慣れな分野のものですか？ どちらでもなければ、高速な回答をそのまま提出します。
3. 検証する： 主張を言い直す → 別の独立した方法でもう一度導出またはテストする → 正解の根拠（コード、ドキュメント、データ）と照合する → 食い違いがあれば解決する → 回答を確定する。

トリガーは、簡単に出た答え＋間違えたときの実質的な損失です。答えを苦労して導き出したなら、すでに十分に検討しています。タスクが些細で取り消し可能なら、過剰に検証する必要はありません。

使用する場面

• データ移行、セキュリティ、削除、公の場での確約など、重大な結果を伴う、または取り消せないタスクで、答えが明白に感じられたとき。
• 不慣れな分野や新しいタスクで、頼れる定番のパターンがないとき。
• 統計的または定量的な推論が必要なとき（高速な補完が確実に不正確な確信につながる領域です）。
• 作業をレビューしていて、ざっと確認しただけで「問題なさそう」と感じたとき。
• 主張がもっともらしく都合よく思えても、実際にはコード、ドキュメント、データと照合していないとき。

判断の流れ：

Answer arrived fast? → High stakes OR unfamiliar? → yes → RUN A VERIFICATION PASS
                                                  ↘ no → fast answer is fine, ship it
                     ↘ no (had to work for it) → you already deliberated

使用しない場面

• 定型的で、取り消し可能で、重要度の低いタスク。 変数名の変更、些細な編集、明白な情報の検索など、すべてを再検証するのは時間の無駄であり、分析麻痺を招きます。
• すでに意図的に検討を重ねた場合。 答えを苦労して導き出したなら、もう一度確認しても重複です。トリガーは簡単に出た答え＋重大な結果であり、すべての回答ではありません。
• 検証にかかるコストが、それによって防げる損失を上回る場合。 間違えたときの損失に応じて、確認の深さを調整してください。
• 実行すれば済む場合。 テストや簡単な実行で決着がつくなら、追加の推論ではなく実行してください。

2つのモード

高速な生成（デフォルト）

特徴	説明
速度	即座 — 最初にもっともらしく補完した内容が、そのまま答えになります
根拠	学習時に見た類似のプロンプトとのパターンマッチング
確信度	正しさとは無関係に高いことがよくあります — 流暢さが確信を装います

高速な生成が信頼できるもの：

• 明確な標準回答がある、十分に確立された定型的なタスク
• 曖昧さの少ない、形式の変更、要約などの変換
• 一般的で安定した事実の想起
• 慣れ親しんだ言語やフレームワークでの日常的なコーディング

高速な生成が信頼できないもの：

• 算術や複数段階の定量的な推論
• 統計的推論やベースレートの問題
• 当てはめるテンプレートのない、新しい問題や不慣れな問題
• もっともらしく聞こえる回答が、微妙な誤りを含む可能性のあるあらゆるもの（API、バージョン固有の挙動、エッジケース）

意識的な検証（オーバーライド）

特徴	説明
速度	遅い — 答えを導き直す、テストする、または情報源を確認します
根拠	明示的な手順と、確かな情報との照合
確信度	実際に検証した内容に基づいて得られます

意識的な検証は、次の場合にはコストをかける価値があります。

• 結果を独立した別の方法でもう一度導き直す
• 出力を予測するのではなく、コードを実行または追跡する
• 記憶に頼らず、実際のファイル、ドキュメント、データに照らして主張を確認する
• 迅速な回答では見落とされるエッジケースを列挙する

唯一の失敗モードは、使いすぎです。確認にかかるコストが、間違いによる損失を上回るような、些細で取り消し可能な作業に適用することです。

プロセス

ステップ 1：迅速な回答に気づく

迅速な回答はすぐに形になります。明示的な作業をする前に生まれる回答です。それ自体は普通のことで、たいていは問題ありません。気づくべきなのは、どのようにその回答に至ったかです。

• 中間の手順を踏まず、すぐに回答ができた
• プロンプトから「明らかに」導かれる
• 確信度は高いが、実際には何も確認していない

Example: "Does this regex match leading zeros?"
A confident yes/no forms instantly → fast generation.
Before answering: is this high-stakes or am I sure? If either is shaky, test the regex.

ステップ 2：2 つの発動条件を確認する

検証を行うべきなのは、次の両方が十分に当てはまる場合だけです。

答えがすぐに出た（ステップ 1）、かつ 間違えた場合のコストが現実的に大きい：

• 重大な影響がある、または操作を元に戻せない
• 分野に詳しくない、または問題が新しい
• 算術的または統計的な推論が必要
• 間違っているがもっともらしい回答がレビューをすり抜ける可能性がある

苦労して答えにたどり着いたなら、すでに熟考しています。ここで止めてください。影響が些細で取り消し可能なら、迅速な回答で問題ありません。ここで止めてください。

ステップ 3：検証を行う

両方の条件に当てはまる場合は、規律ある確認を 1 回だけ行います。

1. RE-STATE  - Write the claim/answer explicitly
2. RE-DERIVE - Reach it a second, independent way (or test/run it)
3. CHECK     - Against ground truth: the code, the docs, the data, the math
4. RECONCILE - If the two paths disagree, the fast answer was wrong — find out why
5. COMMIT    - Ship the verified answer

次のような、迅速な回答に特有の危険信号に注意してください。

• 最も一般的、または標準的な回答だが、プロンプトには通常と異なるひねりがある
• 実際には確認していないバージョン、設定、またはエッジケースに依存している
• 早めに切り上げられる都合のよい回答である
• ユーザーの前提を検証せず、そのまま言い返している

ステップ 4：労力を重要度に合わせる

状況	プロセス
迅速な回答＋影響が小さい	そのまま提示する。無理に疑念を生み出さない
迅速な回答＋影響が大きい	上記の検証を行う
すでに熟考済み	完了 — 2 回目の確認は不要

迅速な生成での失敗モード

質問のすり替え

迅速な生成では、質問された内容ではなく、それに近い簡単な質問に答えてしまうことがあります。

Asked: "Is this O(n) or O(n log n)?"
Answered: "Does this look like efficient code?"  (vibe, not analysis)

Asked: "Does this migration preserve all rows?"
Answered: "Does this migration look correct?"  (plausibility, not verification)

解決策は、正確な質問を言い直すこと（ステップ 3）です。そうすれば、すり替えが明らかになります。

パターン照合による誤り

パターン	何をするか	失敗する場合
標準回答への引き寄せ	教科書的な回答を返す	プロンプトに標準と異なるひねりがある
ベースレートの無視	目立つ詳細から推論する	実際の結果がどれほど一般的かを無視する
アンカリング	プロンプト内の数値を基準にする	その基準が恣意的、または誤っている
確証	与えられた枠組みを支持する情報を示す	その枠組みが誤りである証拠を見落とす
迎合的な同意	ユーザーが示した前提を繰り返す	その前提こそが問題だった

WYSIATI（見えているものがすべて）

迅速な生成では、プロンプトにあるものだけから最も筋の通った回答を組み立て、欠けている情報を指摘しません。

Given: "the function returns the user"
Concludes: "so the happy path works"
Missing: the 404 path, the timeout, the null case — none mentioned, so none considered

回答に一貫性があっても、状況の全体を網羅しているとは限りません。「目の前にない情報で、確認すべきものは何か？」と明示的に問いかけてください。

流暢さは正しさを意味しません

滑らかで、自信に満ち、体裁の整った回答は、読み手にとっても生成時にとっても、より信頼できるように感じられます。この流暢さのシグナルは、回答が正しいかどうかとは無関係です。

流暢な回答	検証済みの回答
読みやすく、見かけ上の自信が強い	合格した特定のチェックに基づく確信
リスク：吟味されずに受け入れられる	リスク：些細なタスクでのみ過剰に使われる

**落とし穴：**素早く出された回答が洗練されているほど、異議を唱えられにくくなります。これは、リスクの大きさに応じて判断すべきこととは正反対です。重大なタスクでは、きれいすぎる回答をそのまま提出する理由ではなく、検証を行う理由として捉えてください。

適用例

コードレビュー

Fast answer: "This looks fine" (matches familiar-looking code)
Verification pass (high-stakes change):
- Trace the actual logic line by line, don't pattern-match the shape
- Enumerate the edge/error paths the diff doesn't mention
- Check the change against the contract it must uphold (callers, tests)

事実や API の動作を報告する場合

Fast answer: "Use method X, it takes these args" (canonical recall)
Verification pass (unfamiliar/version-sensitive):
- Confirm the method exists in the version in this repo
- Check the signature in the actual source/docs, not from memory
- If unsure, say so or look it up rather than assert

アーキテクチャ／技術の選択

Fast answer: "Use [the obvious default]" (most-common completion)
Verification pass (high-stakes):
- State the actual requirements, then check the default against them
- Name one alternative and why it loses, so the choice is reasoned not reflexive

デバッグ

Fast answer: "It's probably X" (first plausible hypothesis)
Verification pass:
- List the candidate causes, not just the first
- Find the evidence that would distinguish them, and look at it
- Resist committing to X until the logs/repro actually point there

他の思考スキルとの連携

バイアスの軽減と併用する場合

バイアスに左右されたエラーの多くは素早い生成で入り込み、検証の段階で見つけられます。重大な判断では、ステップ 3 の内容としてバイアス軽減のチェックリストを実行してください。

ベイズ推論と併用する場合

素早い回答ではベースレートが軽視されますが、検証によって考慮されるようになります。

Fast: "Positive test result = probably has the condition"
Verified: state the base rate first, then update (see thinking-bayesian)

第一原理思考と併用する場合

素早い回答は類推で推論します（「誰もが X をしている」）。検証では、その制約が本当に存在するのかを問い直します。

Fast: "Competitors do X, so we should too"
Verified: "What's the fundamental requirement? Does X actually meet it?"

プレモーテムと併用する場合

素早い回答はデフォルトで楽観的ですが、検証によって失敗の視点を加えます。

Fast: "This plan will work"
Verified: "Assume it failed — what's the most likely reason?"

OODA ループと併用する場合

本当に時間がない状況（インシデント）では、確信度約 70％の素早い回答に基づいて行動し、再度観察してください。検証にこだわって手を止めてはいけません。完全な検証はその後に行うか、インシデント中の取り消せない操作に限って行ってください。

素早い回答を信頼できる場合

素早い方法は敵ではありません。ほとんどの場合は正しく、検証しすぎることもそれ自体が失敗です。次のような場合は、素早い回答に頼りましょう。

1. 一般的なタスクである — 標準的な変換や、一般的で安定した事実
2. パターンにすんなり当てはまる — プロンプトに珍しいひねりがない
3. 簡単に取り消せる — 間違った回答を、ほぼコストをかけずに見つけて修正できる
4. 指摘されても簡単に確認できる — 確認が一手で済む

Fine to ship fast:
- "Convert this JSON to YAML"
- "What HTTP status means 'not found'?"
- A rename or a comment fix

Verify first:
- "Will this SQL touch every shard?"
- "Is this auth check actually enforced on the server?"
- Anything version-, edge-case-, or money-sensitive

「これが間違っていたら、いつ、どのように気づくでしょうか。そして、どれほどのコストがかかるでしょうか？」と考えてください。

検証チェックリスト

• 回答が素早く出されたのか、十分に検討されたのかに気づいた
• 2 つのトリガーを両方確認した：簡単な回答であること、そしてエラーに実質的なコストが伴うこと
• 両方に当てはまる場合、グラウンドトゥルースに照らして、規律ある検証を 1 回行った
• 別の独立した方法でもう一度結果を導き出すか、テストした
• 些細で取り消し可能なタスクを過剰に検証しなかった
• バージョンやエッジケースに左右される主張を、記憶だけで断言せず確認した
• 間違った場合のコストに合わせて検証の深さを調整した

主な質問

• 「この回答は簡単に出すぎたでしょうか。ここではそれが重要でしょうか？」
• 「これは一般的なタスクでしょうか。それとも珍しいひねりがありますか？」
• 「別の独立した方法で導き出すと、何がわかるでしょうか？」
• 「私の確信は実際のチェックに基づいているでしょうか。それとも回答が整って読めることに基づいているだけでしょうか？」
• 「目の前にないものに、何が欠けているでしょうか（WYSIATI）？」
• 「これが間違っていたら、いつ、どのように気づくでしょうか？」

核心となる警告

流暢で自信に満ちた回答が示すのは、生成された内容の一貫性であって、その背後にある証拠の質ではありません。最も洗練された回答ほど、最も異議を唱えられにくくなります。これは、リスクが高いときに限っては正反対であるべきです。重要な事柄について回答が簡単に出てきたら、その簡単さは検証を始めるきっかけであり、完了の合図ではありません。