目次
「このバグ、原因がまったく掴めない…」「この新機能のアーキテクチャ、どう設計するのが最適なんだろう？」
開発現場で直面する複雑で答えのない問題。もし、AIが単に答えを提示するだけでなく、その結論に至るまでの“思考プロセス”を共有し、共に悩んでくれたら、どれほど心強いでしょうか。
その未来を実現するのが、Claude Codeの「拡張思考（extended thinking）」機能です。
この記事では、AI開発の最前線を走るAnthropicの思想が反映されたこの革新的な機能について、その仕組みから有効化の手順、ultrathinkといったトリガーの使い分け、実務での活用シナリオ、コスト管理のベストプラクティスまで、実務者向けに徹底的に解説します。
この記事を読めば、以下の全てがわかります。
- 拡張思考がなぜ複雑な問題に有効なのか、その根本的な仕組み
- Claude Codeで拡張思考を呼び出す具体的なトリガーと有効化の確認方法
- コーディング、デバッグ、設計における具体的な使いどころと効果
- コストとパフォーマンスを両立させる「Thinking Budget」の考え方
- コピペしてすぐに使える、実践的なプロンプトテンプレート集
- 拡張思考に関するよくある誤解と、チームで導入するための判断基準
拡張思考（extended thinking）とは
拡張思考（extended thinking）とは、一言で言えば、「AIに、難問に対して“より多くの考える時間とリソース”を与え、その思考プロセスを段階的に可視化させることで、最終的な回答の精度と信頼性を飛躍的に高める機能」です。
従来のAIが、質問に対して即座に最適解（に見えるもの）を出力する「直感的な回答マシン」だとすれば、拡張思考が有効化されたAIは、問題のあらゆる側面を検討し、仮説を立て、自己批判を繰り返す「熟考するパートナー」へと変貌します。
何が変わる？：難問に対し“考える時間”を増やして精度を上げる仕組み
拡張思考の核心は、AIの推論プロセスにあります。通常、AIはユーザーの知らない内部的な処理（思考連鎖：Chain of Thoughtなど）を経て回答を生成します。拡張思考は、この内部プロセスを意図的に長く、深く、そしてオープンにします。
具体的には、以下の2つの変化が起こります。
- 推論の段階的な可視化: AIは最終的な答えを出す前に、「まず、問題の要件を再定義します」「次に、考えられるアプローチを3つ挙げます」「A案のメリット・デメリットを評価します」といったように、思考のステップを
<thinking>ブロックとして出力します。これにより、ユーザーはAIが今何を考えているのか、なぜその結論に向かっているのかをリアルタイムで把握し、必要であれば軌道修正を指示できます。 - 思考トークンの重点的な使用: この深い思考プロセスを実現するため、Claude Codeは内部的に「思考トークン」と呼ばれるリソースを通常よりも多く消費します。これは、推論の幅と深さを確保するためのコストであり、AIが安易な結論に飛びつくのを防ぎます。結果として、より網羅的で、論理的な破綻の少ない、質の高いアウトプットが期待できるのです。
対応モデルの概要：Claude 3.7 Sonnet以降やClaude 4系の対応と“ハイブリッド推論”の考え方
この強力な拡張思考機能は、Anthropicの最新鋭モデルでサポートされています。具体的には、Claude 4シリーズといった、高度な推論能力を持つモデルが対象です。
これらのモデルは、「ハイブリッド推論」というコンセプトを実装しています。これは、タスクの複雑性に応じて、AIが自律的に推論モードを切り替える考え方です。
- 単純なタスク（例: 変数名のリネーム、簡単なコードスニペットの生成）: 高速な標準モデルが即座に応答し、開発者のフローを妨げません。
- 複雑なタスク（例: 大規模リファクタリングの計画、原因不明のバグ調査）: ユーザーが拡張思考をトリガーすると、システムは自動で
Claude 4のような高性能モデルに切り替え、じっくりと時間をかけた思考を開始します。
これにより、開発者は日常的な作業の速度を犠牲にすることなく、必要な時だけAIの「全力」を引き出すことが可能になります。
Claude Codeでの拡張思考の呼び出し方
Claude Codeで拡張思考を利用するのは簡単です。特別な設定画面を開く必要はなく、普段のチャットやコマンド操作に特定のトリガーを含めるだけです。
基本トリガー：/init とプロンプト内の think / think hard / think harder / ultrathink の使い分け
拡張思考を呼び出すトリガーには、思考の深さに応じていくつかのレベルが用意されています。
| トリガー | 思考の深さ | 主な用途 |
/init extended-thinking | セッション開始 | これから行う一連の対話で、拡張思考をデフォルトで有効にしたい場合。 |
... think about it. | 浅い思考 | 簡単な選択肢の比較や、アイデアの壁打ち。 |
... think hard about it. | 標準的な思考 | 少し複雑なロジックの実装や、バグの原因の仮説出し。 |
... think harder about it. | 深い思考 | 複数のコンポーネントにまたがるリファクタリング計画や、アーキテクチャ設計。 |
... ultrathink on this. | 極めて深い思考 | 再現性の低いパフォーマンス問題の調査、ゼロからのアルゴリズム設計など、最重要課題。 |
これらのトリガーは、プロンプトの末尾に自然な形で付け加えることで機能します。
使用例:
// @claude
// 以下の要件を満たすReactのカスタムフックを実装してほしい。
// ・APIからユーザーリストを取得する
// ・ローディング状態とエラー状態を管理する
// ・取得したデータをキャッシュする
// この設計について、think harder about it.
ultrathinkは最も多くの思考トークンを消費するため、コストと時間に影響します。本当に重要な、失敗が許されないタスクに限定して使用するのが賢明です。
有効化チェック：出力に“thinking”ブロックが現れる／応答に時間がかかる等の挙動
拡張思考が正しく有効化されると、Claude Codeの応答に明確な変化が現れます。
- “thinking”ブロックの出現: AIは最終的なコードや文章を生成する前に、以下のような
<thinking>ブロックを出力し始めます。これが拡張思考がアクティブになっている最も明確なサインです。<thinking> OK, I understand the request. I need to create a React custom hook for fetching user data. First, I'll break down the requirements: 1. **API Fetching**: Use the `fetch` API or a library like `axios`. 2. **State Management**: Need states for `data`, `loading`, and `error`. `useState` should be sufficient. 3. **Caching**: This is the tricky part. I should consider a simple in-memory cache using `useState` or `useRef`. For more advanced cases, `React Query` or `SWR` would be better, but the request asks for a custom hook, so I'll implement a basic version myself. Let's plan the implementation steps... </thinking> - 応答時間の増加: AIが深く考えているため、当然ながら応答速度は通常のプロンプトよりも遅くなります。焦らず、AIの思考プロセスが表示されるのを待ちましょう。この「待ち時間」こそが、アウトプットの質を高めるための投資です。
失敗しやすい例：UIの通常“thinking”との混同／WebUIとCodeの差分
拡張思考を使う上で、初心者が混同しがちな点が2つあります。
- 通常の「思考中アニメーション」との違い: Claude Codeが応答を生成している最中に表示される「…」のようなアニメーションは、単に処理中であることを示しているに過ぎません。拡張思考の
<thinking>ブロックは、思考の内容そのものがテキストとして表示される点で、本質的に異なります。 - WebUIの拡張機能との違い: Anthropicが提供するWebUIにも、思考プロセスを強化する設定が存在する場合があります。しかし、Claude Codeの拡張思考トリガーは、IDEに特化しています。開いているファイル、カーソルの位置、プロジェクト全体の構造といったリッチなコンテキストを深く理解した上での思考であるため、汎用的なWebUIよりも、より的確で実践的な思考プロセスが期待できます。
ultrathinkのような強力なトリガーは、基本的にClaude Code内での利用が想定されています。
使いどころ：どんなタスクで効く？
拡張思考は万能薬ではありません。単純なタスクに使っても、時間とコストが無駄になるだけです。その真価は、「正解が一つではなく、多角的な検討や段階的な分解が必要な複雑なタスク」で発揮されます。
コーディング＆デバッグ：複雑なバグ調査、リファクタ戦略立案、境界条件洗い出し
- 複雑なバグ調査: 「特定の条件下でしか再現しない」「複数のモジュールが絡み合っている」といった厄介なバグ調査に最適です。AIに再現手順、エラーログ、関連コードを渡し、「このバグの根本原因についてultrathinkして」と依頼します。AIは考えられる仮説を複数列挙し、それぞれの検証方法（ログの追加、デバッグコードの挿入など）を提案し、思考を深めていきます。
- リファクタリング戦略立案: 巨大な関数やクラスをリファクタリングする際に、「このコードをどう分割するのが最適か、think harderして」と依頼します。AIは、単一責任の原則や関心の分離といった設計原則に基づき、複数の分割案とそれぞれのメリット・デメリット、具体的な移行手順を段階的に示してくれます。
- 境界条件の洗い出し: 新しい関数を実装した後、「この関数のエッジケースや境界条件を網羅的に洗い出して。think hard about it.」と指示します。AIは、
nullやundefined、空の配列、巨大な数値、不正な型など、人間が見落としがちなテスト観点をリストアップしてくれます。
アルゴリズム設計・検証：ステップ分解や代替案比較が必要な課題
グラフの最短経路探索や、スケジューリング問題など、複雑なアルゴリズムをゼロから設計する際に、拡張思考は強力なブレインストーミングパートナーになります。 「ダイクストラ法とA*アルゴリズムのどちらをこの状況で採用すべきか、それぞれの計算量と実装のトレードオフを比較検討して。think harder about it.」といったプロンプトが有効です。AIは、それぞれのアルゴリズムの動作原理をステップバイステップで説明し、特定のユースケースにおける優劣を論理的に導き出します。
仕様策定・テスト設計：テスト観点列挙や段階的推論が有効な場合
アプリケーションの要件定義やテスト計画といった上流工程でも、拡張思考は役立ちます。 例えば、新しい決済機能の仕様を策定する際に、「クレジットカード決済機能に必要なテスト項目を、ユーザーシナリオ、セキュリティ、パフォーマンスの観点から網羅的に列挙して。ultrathink on this.」と依頼します。AIは、正常系シナリオから異常系、セキュリティ脆弱性（XSS, CSRFなど）のテスト、負荷テストの観点まで、体系的に項目を洗い出してくれます。
ベストプラクティス（プロンプト＆運用）
拡張思考のポテンシャルを最大限に引き出し、同時にコストを適切に管理するためには、いくつかのベストプラクティスを意識する必要があります。
プロンプト設計：目的→制約→評価基準→段階的手順→最終アウトプットの順に明示
AIに質の高い思考をさせるには、質の高いインプットが不可欠です。拡張思考を依頼する際は、以下の構造を意識したプロンプトを設計しましょう。
- 目的 (Goal): 何を達成したいのかを明確に記述します。「〜を実装して」ではなく、「〜という問題を解決するために、〜を実装して」と背景を伝えます。
- 制約 (Constraints): 守るべきルールや条件を伝えます。「使用する言語はPython」「外部ライブラリは使わない」「計算量はO(n log n)以下で」など。
- 評価基準 (Evaluation Criteria): 何をもって「良いアウトプット」とするかの基準を示します。「可読性」「再利用性」「保守のしやすさ」などを重視するよう伝えます。
- 段階的手順の要求 (Step-by-Step Instruction): 「まず計画を立て、次にコードを書き、最後にテストケースを示してください」のように、思考の進め方をガイドします。
- 最終アウトプットの形式指定 (Output Format): 最終的な成果物の形式を指定します。「Markdownの表形式でまとめて」「JSON形式で出力して」など。
この構造化されたプロンプトが、AIの思考の「レール」となり、脱線を防ぎます。
Thinking Budgetの考え方：思考トークン“予算”を決めて過剰推論やコストを抑制
拡張思考、特にultrathinkは、多くの「思考トークン」を消費し、コスト増大や過剰な応答遅延につながる可能性があります。そこで重要になるのが「Thinking Budget（思考予算）」の考え方です。
Claude Codeでは、コマンドにオプションを追加することで、思考に使うトークンの上限を設定できます。
Bash
# Claude Codeのターミナルからコマンドとして実行するイメージ
claude generate_code "complex algorithm" --extended-think=harder --thinking-budget=5000
--thinking-budget=5000 は、「思考プロセスに最大5000トークンまで使って良い。それを超える場合は、その時点での結論をまとめて出力して」という指示になります。
この予算設定により、「思考の深さ」と「コスト・時間」のバランスを取ることができます。重要なタスクには大きな予算を、そうでない場合は小さな予算を設定するなど、状況に応じた使い分けが重要です。
可視化思考の活用：思考ブロックの読み解き／途中での方針修正ポイント
拡張思考の最大の利点は、<thinking>ブロックによる思考の可視化です。これをただ眺めるだけでなく、積極的に対話し、介入することで、AIをより良い方向へ導くことができます。
AIが思考ブロックを出力している最中に、 「待って、その仮説は間違っている。DBのスキーマはこうなっているから、そのアプローチは使えないはずだ。」 「その3つの選択肢のうち、スケーラビリティを最優先してB案を深掘りしてほしい。」 といったフィードバックをチャットで送ります。
すると、AIは進行中の思考を中断し、新たなインプットに基づいて思考を再開・修正します。このインタラクティブなプロセスこそ、AIとの真の「ペアプログラミング」「ペア設計」と言えるでしょう。
実践レシピ：コピペで使える拡張思考プロンプト
ここでは、日々の開発業務ですぐに使える拡張思考のプロンプトテンプレートを3つ紹介します。// @claude 以下をコピーし、ご自身のClaude Code環境で試してみてください。
1. 複雑なバグ調査テンプレート
// @claude
// ## バグ調査依頼 ##
//
// **目的:**
// ユーザープロフィールの更新時に、断続的に発生する「500 Internal Server Error」の根本原因を特定し、修正する。
//
// **再現手順:**
// 1. ユーザーAでログインする。
// 2. プロフィール編集ページに移動する。
// 3. 自己紹介文を500文字以上入力し、更新ボタンを高速で2回クリックする。
// 4. 約3回に1回の確率で500エラーが発生する。
//
// **提供情報:**
// - エラーログ: (ここに実際のエラーログを貼り付け)
// - 関連コード(UserService.ts): (ここに問題のコードを貼り付け)
// - DBスキーマ(usersテーブル): (ここにスキーマ情報を貼り付け)
//
// **思考とアウトプットの要求:**
// 以下のステップで思考し、最終的なレポートを作成してください。
// 1. **仮説列挙:** 考えられる原因の仮説を少なくとも3つ挙げてください（例: レースコンディション、DBのロック、バリデーションの問題など）。
// 2. **検証プラン:** 各仮説を検証するための具体的な手順や、追加すべきログ、デバッグコードを提案してください。
// 3. **根本原因の特定:** 検証プランに基づき、最も可能性の高い根本原因を一つに絞り込んでください。
// 4. **修正パッチ案:** 根本原因を解決するためのコード修正案を提示してください。
// 5. **回帰テスト案:** 修正によって他の機能に影響が出ていないか確認するためのテストケースを提案してください。
//
// このタスクについて、ultrathink on this.
2. アーキテクチャ設計レビューテンプレート
// @claude
// ## アーキテクチャ設計レビュー依頼 ##
//
// **目的:**
// 新規開発するリアルタイム通知システムのアーキテクチャを決定する。
//
// **非機能要件:**
// - **スケーラビリティ:** 将来的に100万人の同時接続ユーザーをサポートできること。
// - **リアルタイム性:** メッセージの遅延は平均100ms以内であること。
// - **コスト効率:** 運用コストを可能な限り低く抑えること。
// - **開発の容易さ:** 既存の技術スタック（Node.js, TypeScript）と親和性が高いこと。
//
// **思考とアウトプットの要求:**
// 1. **代替案の提示:** 上記要件を満たすためのアーキテクチャ案を、以下の3つの技術を軸にそれぞれ設計してください。
// - 案A: WebSocket (Socket.IO)
// - 案B: Server-Sent Events (SSE)
// - 案C: クラウドのマネージドサービス (例: AWS AppSync, Ably)
// 2. **トレードオフの比較:** 3つの案について、先に挙げた4つの非機能要件（スケーラビリティ、リアルタイム性、コスト、開発容易性）の観点から、それぞれのメリット・デメリットを比較検討してください。
// 3. **比較表の作成:** 比較結果をMarkdownの表形式でまとめてください。
// 4. **推奨案の提示:** 総合的に判断し、本プロジェクトに最も適していると考えるアーキテクチャ案を一つ選び、その選定理由を詳細に説明してください。
//
// この設計タスクについて、think harder about it.
3. CI/CD併用テンプレート (Headlessモード想定)
これは、CI/CDパイプラインのスクリプトからClaude Codeのコマンドを呼び出すことを想定したプロンプトです。
// @claude
// ## CI/CDパイプライン向け 静的解析＆セキュリティ監査プランニング ##
//
// **目的:**
// mainブランチへのマージ前に、コードの品質とセキュリティを自動で検証するステップを計画する。
//
// **コンテキスト:**
// - このプロンプトは、CI/CDパイプライン（headlessモード）から実行される。
// - 対象リポジトリはTypeScriptとReactで構成されている。
// - 最終的なアウトプットは、後続のジョブで実行可能なシェルコマンドのリストであること。
//
// **思考とアウトプットの要求:**
// 以下の観点で、実行すべき検証ステップを計画し、具体的なコマンドとして出力してください。
//
// 1. **コード品質チェック:**
// - ESLintによる静的解析
// - Prettierによるコードフォーマットチェック
// - TypeScriptの型チェック
// 2. **セキュリティ脆弱性スキャン:**
// - 依存関係（npmパッケージ）に既知の脆弱性がないかスキャン (例: `npm audit`)
// - ソースコード自体に潜在的な脆弱性（例: XSS, 不適切なAPIキーの使用）がないか、静的解析でチェック
// 3. **テスト実行:**
// - Jestによるユニットテストとカバレッジレポートの生成
//
// このプランニングについて、think about it.
よくある誤解と落とし穴（FAQ）
Q1. “ultrathink”はどこでも使える？
A1. 主にClaude Code内での利用に最適化されています。 ultrathinkやthink harderといったトリガーは、単なるキーワードではありません。Claude Codeの環境では、IDEが提供する豊富なコンテキスト（プロジェクト全体のファイル構造、Gitの差分、カーソル位置など）と連携して機能します。そのため、一般的なWebUIで同じキーワードを使っても、Claude Code内と同等の深い思考が得られるとは限りません。最高のパフォーマンスを引き出すには、Claude Code内での利用が推奨されます。
Q2. 拡張思考を使うと、いつも遅くなるしコストが上がるのでは？
A2. その通りですが、制御可能です。 拡張思考は意図的に多くのリソースを消費するため、応答時間は長くなり、トークン消費量（コスト）も増加します。しかし、これは質の高いアウトプットを得るためのトレードオフです。対策は以下の2つです。
- 使い分けの徹底: 全てのタスクに使うのではなく、前述の「使いどころ」で紹介したような、複雑で重要なタスクに限定します。
- Thinking Budgetの活用:
--thinking-budgetオプションで思考に使うトークンの上限を設定し、コストと時間の暴走を防ぎます。
Q3. 拡張思考を使えば、AIの幻覚（ハルシネーション）はゼロになる？
A3. ゼロにはなりませんが、大幅に削減される傾向にあります。 拡張思考は、AIに自己批判と論理的なステップを踏ませるため、事実に基づかない情報を生成する「幻覚」を抑制する強い効果があります。思考プロセスが可視化されるため、ユーザー自身がAIの推論の誤りに気づきやすくなるという利点もあります。 しかし、AIの根本的な性質上、幻覚の可能性を完全にゼロにすることはできません。重要な情報を扱う際は、AIの回答を鵜呑みにせず、「その情報の根拠は？」「公式ドキュメントへのリンクを示して」といったプロンプトを追加し、ファクトチェックを怠らないようにしましょう。
まとめ：導入判断のチェックリスト
あなたのプロジェクトやチームで、Claude Codeの拡張思考を導入すべきか迷った際は、以下のチェックリストを参考にしてください。YESが多いほど、導入効果が高いと言えます。
□ タスクの難易度: 日常的に、単一の正解がない複雑な問題（難解なバグ、アーキテクチャ設計、大規模リファクタリングなど）に取り組んでいるか？
□ 思考プロセスの可視化の必要性: AIの回答の「なぜ？」を知りたいか？AIとの対話を通じて、結論を共創していきたいか？
□ 時間とコストの許容度 (SLA): 目先の応答速度よりも、最終的なアウトプットの品質を重視できるか？質の高い思考のためなら、多少のコスト増を許容できるか？
□ 再利用性とナレッジ化: 複雑なタスクの解決プロセスを、テンプレート化してチームのナレッジとして蓄積していきたいか？
チームでの運用ルール化のヒント:
- いつONにするか: 「プルリクエストのレビューで、複雑な変更に対してレビュアーがAIレビューを要求する場合」「週次のアーキテクチャ検討会で、AIを壁打ち相手として使う場合」など、具体的なシーンを定義する。
- コスト管理:
Thinking Budgetの標準的な上限値をチームで決め、それを超える場合はリーダーの承認を得る、といったルールを設ける。
Claude Codeの拡張思考は、AIを単なるツールから真の「思考パートナー」へと昇華させるゲームチェンジャーです。このガイドを手に、ぜひその圧倒的な問題解決能力を体験してみてください。
