Chain of Thought

思考の連鎖とは、一回の回答の中で、Claudeに最終的な答えだけでなく推論の過程を段階的に書き出させることを指す。これは extended thinking（拡張思考）とは異なる。extended thinking はモデルが利用できる内部の思考予算であり、リソース配分の仕組みに属し、思考過程が必ずしもユーザーに表示されるとは限らない。思考の連鎖は推論の手順を回答そのものに明示的に書き出させるものであり、各ステップが見える。また prompt chaining（プロンプトの連結）とも異なる。prompt chaining は大きなタスクを複数の独立したプロンプトに分割し、複数回の呼び出しをつなげて完了させるものだ。思考の連鎖は一回の回答内部での推論の展開であり、複数回の呼び出しは伴わない。三つは混同されやすいが、それぞれ異なる階層を扱っている。思考の連鎖はこの一回の回答の推論過程を書き出すかどうかを、extended thinking はこの思考にどれだけのリソースを使えるかを、prompt chaining はこのタスクを複数回の呼び出しに分割するかどうかを扱う。

この手法が必要とされるのは、直接答えを求めることと推論の展開を求めることとでは、検証可能性がまったく異なるからだ。結論だけの場合、計算結果が間違っていても、分かるのは「この数字が違う」ということだけで、間違いがデータの取り違えなのか、数式の誤りなのか、途中のどこかのミスなのかは分からない。やり直す唯一の実質的な方法は通常、全体を再実行することであり、どこで壊れたかを特定する手段がない。思考の連鎖が推論を展開すると、誤りは具体的なある一手順に落ち着き、「三番目の前提が成り立たない」と直接指摘できる。Claudeはその一手順だけを修正すればよく、最初からやり直す必要がない。この違いは職場の場面で特に重要だ。契約条項の比較、予算の試算、方針の適用判断など、AIの助けが必要な多くのタスクが本当に求めているのは「一つの答え」ではなく「検証でき、異議を唱えられる推論過程」だからだ。展開されなかった推論は、本質的には信じるか信じないかしか選べないブラックボックスの結論にすぎない。

実際の運用は二つの層で行う。表層のやり方は、指示の中で明確に要求することだ。「結論を出す前に、あなたの推論過程を段階的に説明してください」、あるいは「まず検討している要因を列挙し、次に一項目ずつ判断し、最後に結論を出してください」のように形式を指定する。これはほぼどんなタスクにも有効で、コストは回答が長くなることだが、その見返りとして各手順を検証できるようになる。深層のやり方は、これに構造化された要求を組み合わせる。計算系のタスクでは、結果だけでなく途中の計算式をすべて列挙させる。判断系のタスク（例えば「この契約条項は標準的と言えるか」）では、まず判断の根拠となる具体的な条文や基準を列挙させ、その根拠と結論の関係を説明させる。結論を先に述べてから根拠を後付けするのではない。この順序自体が、推論が本当に一通り考え抜かれたものか、それとも結論が先に出てきて根拠が後から飾り付けられただけかを左右する。注意すべきは、思考の連鎖は「付ければ必ず精度が上がる」ものではない点だ。非常に単純なタスク（固定された事実を調べるだけなど）に推論の展開を求めると、かえって速度が落ち、不必要に長くなる。展開する価値があるのは通常、計算、複数段階の判断、あるいは議論の余地がある推論タスクである。

あなたにとって、思考の連鎖が本当に変えるのは「間違いに気づいた後、何ができるか」である。推論が展開されていない場合、答えが間違っていると分かっても、できるのは丸ごと聞き直すことだけで、運が良ければ正しい版に当たる程度だ。推論が展開されていれば、どの手順の前提やデータが問題だったかを直接指摘でき、修正は当てずっぽうの再試行ではなく的を絞ったものになる。これは出力に最終的な責任を負う場面で特に重要だ。予算試算や契約条項の判断を上に提出する場合、その結論がどう導かれたかを説明できるかどうか自体が、責任を遡って追跡できるかどうかの分かれ目になる。注意すべきリスクは、思考の連鎖が推論を「より信頼できるように見せる」点だ。書き出された手順自体が間違っていたり、単なる後付けの正当化だったりする可能性がある。推論を展開したからといって推論が正しいとは限らず、特に具体的な数字や外部の事実が関わる箇所は依然として自分で確認する必要があり、過程が詳しく書かれているというだけで結論をそのまま通してはならない。