sequential-thinking

非推奨 — Opus 4.7 は適応型思考（各ステップで任意）を使用し、Sonnet 4.6 は構造化された思考連鎖をネイティブに処理します。ほとんどのタスクでは、「注意深く、段階を追って考えてください。見た目以上に難しい問題です」とプロンプトで指示すれば、必要な深さの思考を引き出せます。この方法論は、モデルの適応型思考の選択にかかわらず、決定論的でレビュー可能な推論の軌跡が求められる場合（監査、証明、事後分析）の参照パターンとして保持されています。

Sequential Thinking

Sequential Thinking MCP サーバーの sequentialthinking ツールを、コストのかからない指示型プロンプトに置き換える、構造化された内省的な問題解決方法論です。

置き換え対象：@modelcontextprotocol/server-sequential-thinking（1 ツール、ターンあたり約 1,800 トークンを節約）

クイックリファレンス

機能	従来の MCP ツール	新しい方法
段階的な推論	sequentialthinking(thought, thoughtNumber, ...)	以下の方法論に従う
思考の修正	sequentialthinking(isRevision=true, revisesThought=N)	インライン修正プロトコル
分岐の検討	sequentialthinking(branchFromThought=N, branchId=...)	分岐ラベリングプロトコル
スコープの動的な調整	sequentialthinking(needsMoreThoughts=true)	スコープ再評価のチェックポイント
仮説の検証	sequentialthinking を nextThoughtNeeded=false になるまで繰り返す	結論を出す前の検証プロトコル

前提条件

ありません。このスキルは純粋な方法論であり、CLI ツール、API、認証は必要ありません。

中核となる方法論

構造化された問題解決プロトコル

複雑で複数の段階からなる問題に直面したときは、このプロトコルに従ってください。MCP ツールが機械的に強制していた重要な動作を、明示的な手順として表現します。

1. スコープの評価

取りかかる前に、問題の複雑さを見積もり、明示してください。

「これはおよそ N ステップ必要です。次のように分解できます……」

問題を 3～7 個のサブゴールに分解します。分解できない場合は、まず問題を明確にする必要があるというサインです。先に進む前に質問してください。

2. 番号付きステップの実行

各ステップを明確な構造で進めます。

• ステップ N / M — このステップのサブゴールを述べます
• 推論または作業内容を示します
• 中間結論を述べます
• 次のステップとのつながりを明示します：「つまり、ステップ N+1 では……する必要があります」

先のステップに飛ばないでください。各ステップでは、具体的で検証可能な中間結果を出す必要があります。

3. 修正チェックポイント

3～4 ステップごとに、必ず自己確認を行います。

チェックポイント： まだ正しい方向に進んでいますか？

• これまでに分かったことを踏まえても、以前の結論は妥当ですか？
• 問題のスコープは変わりましたか？
• 前提はまだ有効ですか？

修正が必要な場合は、明示してください。

ステップ N の修正： [X] という以前の結論は、[Y] が理由で誤りでした。 訂正後の結論は [Z] です。これにより、後続のステップ [影響を受けるステップの一覧] に影響します。

これは、MCP の isRevision および revisesThought パラメーターに代わるものです。重要なのは、何が変わったのか、その理由は何か、後続のどの内容が無効になるのかを明示することです。

4. 分岐の検討

複数の実行可能なアプローチがある場合、何も言わずに一つを選ばないでください。分岐を明示します。

分岐点（ステップ N から）：

アプローチ A — [ラベル]： [簡単な説明と予想される結果] アプローチ B — [ラベル]： [簡単な説明と予想される結果]

評価：[重要なトレードオフを 1～2 文で比較] [根拠] により、アプローチ [X] に決定します。

これは、MCP の branchFromThought および branchId パラメーターに代わるものです。重要なのは、機械的に分岐させることではなく、判断のポイントと根拠を明示することです。

特に重大な分岐では、最初から一方を選ぶのではなく、決定する前に両方の分岐を簡単に検討します（それぞれ 2～3 ステップ）。

5. スコープの動的な調整

分析の途中で、問題が見積もりより大きい、または小さいとわかった場合は、次のようにします。

スコープの更新： 当初は N ステップと見積もっていましたが、[理由] により、現在は M ステップと見積もっています。

これは、needsMoreThoughts と totalThoughts の調整に代わるものです。当初の見積もりに合わせるために推論を人為的に圧縮しないでください。予測よりも正確さが重要です。

6. 検証と結論

最終回答を提示する前に、必ず次のことを行います。

1. 言い換え：元の問題を自分の言葉で言い換えます
2. 解決までの道筋をたどる：「ステップ 1→3→5 で [X] が確立され、ステップ 4→6 で [Y] が確立されました」
3. 検証：明示されたすべての制約と要件に照らして確認します
4. 不確実性を明示：残っている不確実性や前提を明らかにします
5. 結論を出す：すべての制約を満たした場合にのみ結論を出します

検証： この解決策はすべての要件を満たしていますか？

• [要件 1]：[ステップの参照先] により ✓ 満たしています
• [要件 2]：[ステップの参照先] により ✓ 満たしています
• [要件 3]：⚠ 部分的 — [不足点とその緩和策を説明]

これは、nextThoughtNeeded=false の終了条件に代わるものです。MCP では、思考が完了したことを明示的に示す必要がありました。この方法では、検証チェックリストを通じてそれを実現します。

出力形式

逐次的な思考セッションの出力は、次の構成になります。

• 番号付きの思考 — それぞれにサブゴールの記述、推論、中間結論を含め、Step N of M とラベル付けします
• 修正マーカー — 変更点、その理由、影響を受ける後続のステップを示す Revising Step N: ブロックをインラインで配置します
• 分岐の指標 — 選択肢、採用の表明、その根拠を列挙する Branch Point (from Step N): ブロックを配置します
• スコープの更新 — 分析の途中でステップ数の見積もりが変わった場合は、Scope Update: の行を記載します
• 検証ブロック — 各要件を満たしていることをステップの参照先とともに確認する最終チェックリストです。結論を出す前に、解決されていない不確実性も明示します

調整ルール

• 複雑さに応じて深さを調整する： 単純な問題（判断が 1 つで、制約が明確）の場合は 3〜5 個の思考が適切です。中程度の問題（トレードオフを伴う複数ステップ）の場合は 5〜10 個です。複雑な問題（アーキテクチャ、連鎖的な障害のデバッグ、形式的な推論）の場合は 10 個以上とし、人為的に圧縮しないでください。
• 修正は品質を示す： 先行するステップを修正する思考セッションは、自己修正せず直線的に進むものより信頼性が高くなります。修正は失敗ではなく、この方法が意図どおりに機能している証拠です。
• 広さより深さを優先する： 選択肢を浅く多数列挙するより、分岐を少なくして詳しく検討します。選択によって結果が実質的に変わる場合にのみ、その分岐を検討する価値があります。
• スコープを誠実に扱う： 当初のステップ数の見積もりが誤っていた場合は、明示的に更新します。途中で正確に修正するほうが、古い見積もりに合わせて無理に結論を出すより適切です。

よくあるワークフロー

詳細なデバッグ

複雑なバグやシステムの問題を診断する場合：

1. 再現 — 観察された動作と期待される動作を正確に記述します
2. 仮説を立てる — 根本原因の候補を 2〜3 個挙げ、可能性の高い順に並べます
3. 絞り込む — 最有力の仮説について、それを確認または否定できる最小限のテストを特定します
4. テストする — テストを実行し、結果を確認します
5. 反復する — 仮説が否定された場合は次の仮説に進みます。確認された場合は根本原因をたどります
6. 修正を検証する — 修正によって根本原因に対処できており、リグレッションが発生しないことを確認します

ステップ 2 では、分岐の検討を使って、競合する仮説を明示します。

アーキテクチャ上の意思決定

システム設計や技術選定を行う場合：

1. 枠組みを定める — 決定事項、制約、重み付けした評価基準を明示します
2. 選択肢を列挙する — 実行可能な選択肢を挙げます（3〜5 個を目安にします）
3. 評価する — 各選択肢を基準に沿って採点します。意思決定マトリックスを使用します
4. ストレステストを行う — 上位 1〜2 個の選択肢について、障害モードやエッジケースを検証します
5. 決定する — 明確な根拠と、文書化したトレードオフを示して決定します
6. 記録する — この決定を見直すきっかけとなる条件を示します

数学的／形式的な推論

証明、導出、形式検証を行う場合：

1. 主張または目標を正確に示します
2. 証明戦略（直接法、背理法、帰納法、構成法）を特定します
3. 各手順を、名前の付いた規則または補題で正当化しながら実行します
4. 次に進む前に、各手順の妥当性を確認します
5. 証明が完全であること（すべてのケースを網羅し、論理の飛躍がないこと）を検証します

形式的な推論では誤りが連鎖するリスクが高いため、Revision Checkpoints を積極的に使用します。

エラー処理

問題	原因	対処
推論が堂々巡りになる	Revision Checkpoint がない	チェックポイントを設けます。目標を言い直し、以前の結論を繰り返している手順がないか確認します
対象範囲が広がり続ける	問題の定義が不十分	いったん止めて、独立した小問題に分解し、最小のものから解決します
分岐のどちらを選ぶか決められない	評価基準が不明確	選択肢を比較する前に、基準を明確化し、重み付けします
結論が制約を満たさない	検証手順を省略した	回答を提示する前に、検証チェックリストをすべて実施します
前の手順が無効になる	新しい情報が前提と矛盾する	該当する手順、誤り、後続への影響をすべて明示し、修正します

制限事項

• 会話をまたいで状態は保持されません。 MCP サーバーは、セッション内で思考履歴を保持していました。この方法論では代わりに会話のコンテキストウィンドウを利用します。同一の会話内では同等ですが、セッションをまたいで保持されることはありません。
• プログラムで扱える思考グラフはありません。 MCP は各思考手順について構造化された JSON を返しており、理論上は他のツールで利用できます。一方、この方法論が生成するのは自然言語です。実際には、MCP の JSON 出力がプログラムで利用されることはほとんどありませんでした。
• 自己管理が必要です。 MCP は手順の番号付けとチェックポイントの構成を機械的に強制していました。この方法論では、Claude がプロトコルに従うことに依存します。実際には、推論パターンについては明示的な指示でも、ツール呼び出しによる強制と同程度の信頼性があります。

トークン削減の分析

指標	MCP（1 ターンあたり）	Skill（1 ターンあたり）	削減量
スキーマのオーバーヘッド	~1,800 トークン	0 トークン（必要時に読み込み）	~1,800 トークン/ターン
20 ターンの会話	~36,000 トークン	~300 トークン（初回読み込みのみ）	~35,700 トークン
ツール呼び出しのオーバーヘッド	~200 トークン/呼び出し	0（ネイティブな推論）	~200 トークン/呼び出し

Sequential Thinking MCP は、ターンごとに大量のスキーマトークンを消費する一方で、Claude がプロンプトを通じてネイティブに再現できる機能を提供しているため、投資対効果が最も高い移行の一つです。