注目 Extended Thinking Opus Sonnet Advanced

Claude Code の Extended Thinking：より深い推論を引き出す

Claude Code の Extended Thinking をマスターしましょう。現行モデルの adaptive reasoning の仕組み、effort レベルによる制御、ultrathink の使いどころ、複雑な開発タスクに深い推論を活かす方法を解説します。

2026年1月10日 • 更新日：2026年11月4日 • 17 分で読める • 著者：Claude World

2026年11月4日更新： ultrathink でそのターンを xhigh effort に引き上げられるようになりました（Claude Code v2.1.311 以降）。下記「ターン単位：ultrathink」と effort レベルガイドを参照してください。

2026年10月21日更新： Claude Code 2.1.305 に合わせて書き直しました。現行モデルは effort レベルで制御される adaptive reasoning（適応的推論）を使い、Opus 5.5、Sonnet 5.5、Haiku 5.5、Fable モデルでは thinking をオフにできません。ultrathink は 1 ターンだけより深い推論を要求するキーワードで、設定例も実在する設定キーに置き換えました。

Extended Thinking（別名「Thinking Mode」）は、Claude が応答する前に行う推論です。開発者がコードを書く前にアーキテクチャを検討する時間を取るようなものです。現行モデルでは、これは適応的です。Claude は各ステップで考えるかどうか、どれだけ考えるかを自分で決め、effort レベルがその考えやすさを方向づけます。

このガイドでは、現行モデルで thinking がどう機能するか、どう制御するか、そして最大限の効果を発揮するためのパターンを解説します。

Extended Thinking とは？

Extended Thinking により、Claude は以下のことが可能になります：

応答前により長く熟考する
問題に対する複数のアプローチを検討する
エッジケースを体系的に推論する
複数ステップの実装を徹底的に計画する

┌─────────────────────────────────────────────────────────────┐
│                    Normal vs Extended Thinking              │
│                                                             │
│  Normal:                                                    │
│  ┌────────┐      ┌────────┐                                │
│  │ Prompt │  ──► │Response│                                │
│  └────────┘      └────────┘                                │
│                                                             │
│  Extended Thinking:                                         │
│  ┌────────┐   ┌─────────────────┐   ┌────────┐            │
│  │ Prompt │ ► │ Internal Reason │ ► │Response│            │
│  └────────┘   │ (collapsed)     │   └────────┘            │
│               └─────────────────┘                          │
│                     ▲                                       │
│                     │                                       │
│              Longer, deeper                                 │
│              deliberation                                   │
└─────────────────────────────────────────────────────────────┘

Adaptive reasoning：必要なときに考える

Claude Code のドキュメントはこう説明しています。「Adaptive reasoning は各ステップでの thinking を任意にするため、Claude は定型的なプロンプトにはより速く応答し、深い思考が有益なステップにそれを振り向けられます。」Fable モデル、Sonnet 5 以降、Haiku 5.5、Opus 4.7 以降は常に adaptive reasoning を使い、これらのモデルでは effort レベルが thinking 量の主要な制御手段になります。プロンプトや CLAUDE.md でもっと考える／あまり考えないよう指示することもでき、モデルは effort 設定の範囲内でそのガイダンスに応じます。

モデルのサポート状況

Claude Code 2.1.305 では次のとおりです。

モデル	thinking の方式	thinking をオフにできるか	Effort レベル	デフォルト effort
Fable 5.1、Fable 5	Adaptive reasoning	不可	`low`〜`max`	`high`
Opus 5.5、Sonnet 5.5、Haiku 5.5	Adaptive reasoning	不可	`low`〜`max`	`medium`
Opus 5、Sonnet 5、Opus 4.8	Adaptive reasoning	可	`low`〜`max`	`high`
Opus 4.7	Adaptive reasoning	可	`low`〜`max`	`xhigh`
Opus 4.6、Sonnet 4.6	既定は adaptive。`CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1` で固定予算に戻る	可	`low`、`medium`、`high`、`max`	`high`
Haiku 4.5	固定トークン予算での thinking	可	effort 非対応	—

low〜max は 5 段階すべて、つまり low、medium、high、xhigh、max を指します。Haiku 4.5 が今も重要なのは、Claude Platform on AWS、Amazon Bedrock、Google Cloud’s Agent Platform、Microsoft Foundry では haiku がこのモデルに解決されるからです。

重要なポイント: 現行ラインナップで決めるのは Claude が考えるかどうかではなく、effort レベルでどれだけ考えるかです。

Thinking のオン／オフ

thinking に対応するすべてのモデルで、thinking は既定でオンです。以下の操作はオフにできるモデルでのみ効果があり、Opus 5.5、Sonnet 5.5、Haiku 5.5、Fable モデルでは Thinking can't be turned off と表示されるか、何も起こりません。

Config 経由

/config で Thinking Mode を切り替えます。Claude Code はその選択を ~/.claude/settings.json の alwaysThinkingEnabled として保存します。

Settings 経由

{
  "showThinkingSummaries": true
}

Claude Code は既定で thinking の出力を折りたたみ、Anthropic API 上のインタラクティブセッションでは redacted（伏せられた）thinking ブロックを受け取ります。Ctrl+O で展開したときに完全な要約を見たい場合は showThinkingSummaries: true を設定してください。オフにできるモデルで全セッションの thinking を止めるには "alwaysThinkingEnabled": false を設定します。true は何も変えません（thinking はすでにオンだからです）。生成された thinking トークンは、折りたたまれていても伏せられていても、すべて課金対象です。

セッション単位

Option+T（macOS）または Alt+T（Windows/Linux）で現在のセッションの thinking を切り替えます。常に thinking する Opus 5.5、Sonnet 5.5、Haiku 5.5、Fable モデルでは効果がありません。

ターン単位：`ultrathink`

プロンプトのどこかに ultrathink を含めると、セッションの effort 設定を変えずにそのターンだけより深い推論を要求できます。

"ultrathink: why does this cache invalidation race only show up under load?"

Claude Code はこのキーワードを認識し、コンテキスト内の指示を追加します。v2.1.311 以降は、ターミナルのプロンプトで入力すると、Anthropic API 経由の Opus 5.5、Sonnet 5.5、Haiku 5.5、Fable 5.1 でそのターンを xhigh effort に引き上げることもできます。引き上げられるときは、この単語が虹色で表示されます。Amazon Bedrock のように引き上げられない環境では、effort レベルを設定してください。いずれの場合も保存済みの effort 設定は変わりません。また v2.1.316 の changelog では、このキーワードを無効にする CLAUDE_CODE_DISABLE_ULTRATHINK が追加されています。「think」「think hard」「think more」などの他の表現は、キーワードとしては認識されず通常のプロンプトテキストとして扱われます。

環境変数経由

MAX_THINKING_TOKENS の挙動はモデルによって異なります。

0 は Anthropic API 上で thinking をオフにします。ただし thinking をオフにできない Opus 5.5、Sonnet 5.5、Haiku 5.5、Fable モデルは例外です。サードパーティ provider では 0 は thinking パラメータを省略するだけなので、adaptive reasoning のモデルは引き続き考える可能性があります。
正の値は固定の thinking 予算です。adaptive reasoning のモデルでは Claude Code がこの数値を無視します（CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 で Opus 4.6 や Sonnet 4.6 を固定予算に戻した場合を除く）。予算はリクエストの最大出力トークン数より 1 少ない値が上限で、1,024 を下回ることはありません。

Anthropic API で thinking をオフにしている場合、その組み合わせを受け付けないモデル（Opus 5 など）に対しては、Claude Code はより高いレベルではなく effort high を送ります。

クイックモデル切り替え

Option+P（macOS）または Alt+P（Windows/Linux）を押すと、プロンプトを消さずにモデルを切り替えられます。macOS ではこのショートカットにターミナル側で Option を Meta として設定する必要があります。

Effort レベル

adaptive reasoning のモデルでは、effort レベルが thinking の深さを制御する手段です。/effort でセッションに設定し、必要に応じてサブエージェント単位で上書きします。

Effort	thinking 量	ユースケース
`low`	最小限	簡単なタスク、リネーム、結果を自分で確認するバッチ処理
`medium`	バランス型	Opus 5.5、Sonnet 5.5、Haiku 5.5 のデフォルト。範囲が明確な日常業務
`high`	深い	既存コードのバグ修正、複雑な分析。Fable 5.1 を含む他の多くのモデルのデフォルト
`xhigh`	より深い	アーキテクチャの意思決定と最も難しい判断作業
`max`	最も深い	Claude に自力で解き切ってほしい難問。考えすぎる傾向があるのでまずテストを

すべてのモデルがすべてのレベルに対応しているわけではありません。Opus 4.6 と Sonnet 4.6 には xhigh がなく、Haiku 4.5 は effort 対応モデルとして掲載されていません。完全な対応表と、effort を保存・制限する設定については Ultracode と Effort レベルをご覧ください。

Effort の設定

プロンプトに「with high effort」と書いても effort レベルは変わりません。それは現在の設定の範囲内でモデルが参考にするガイダンスです。レベル自体を変えるには次のようにします。

/effort high      # set the level and save it as this model's default
/effort           # open the slider: Enter saves, s applies to this session only
/effort status    # show the level in effect

claude --effort xhigh                   # one session, set at launch
CLAUDE_CODE_EFFORT_LEVEL=high claude    # environment variable; overrides --effort and /effort

サブエージェントには、定義のフロントマターで effort を設定するか、Claude に Agent ツールの effort パラメータ（v2.1.292 以降）を渡してもらいます。「分析を Opus の general-purpose サブエージェントに high effort で任せて」と頼んだときの呼び出しは次のような形です（Agent ツールは以前 Task という名前で、Task も別名として引き続き使えます）。

Agent({
  description: "Analyze payment architecture",
  subagent_type: "general-purpose",
  model: "opus",
  effort: "high",
  prompt: `
    Analyze the payment integration architecture.
    Consider all edge cases and failure modes.
  `
})

Extended Thinking を使用するタイミング

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

セッションのデフォルト effort でさっと一周：

"How should we structure our microservices?"

Claude: [Quick response, may miss considerations]

ultrathink で深く（あるいは先に /effort high）：

"ultrathink

How should we structure our microservices?
Consider: scalability, team structure, data ownership,
deployment complexity, and failure isolation."

Claude: [Thorough analysis of trade-offs]

セキュリティレビュー

プロンプトからモデルや effort は切り替えられないので、先に設定します。

/model opus
/effort high

"Review the authentication implementation for vulnerabilities.

Consider: OWASP Top 10, JWT best practices, session
management, rate limiting, and common attack vectors."

複雑なリファクタリング

"Think through how to refactor the legacy payment system
to the new architecture. Consider:

- Backward compatibility
- Database migrations
- API versioning
- Rollback strategy
- Testing approach"

複雑な問題のデバッグ

"This bug only happens in production with high concurrency.
ultrathink about potential causes.

Symptoms: [describe symptoms]
Environment: [describe environment]
Recent changes: [describe changes]"

Extended Thinking パターン

「think deeply」のような表現は、モデルが effort レベルの範囲内で参考にするガイダンスです。認識されるキーワードは ultrathink だけで、レベル自体を変えるのは /effort です。

パターン 1：アーキテクチャレビュー

"I need to design a new feature. ultrathink.

Feature: Real-time notifications
Requirements:
- Support 100K concurrent users
- < 100ms delivery latency
- Support mobile and web
- Handle offline users

Analyze options and recommend architecture."

パターン 2：トレードオフ分析

"Think deeply about this trade-off.

Option A: Monolith with modular structure
Option B: Microservices from start

Context:
- 3-person team
- MVP stage
- Unknown scale requirements
- Limited DevOps experience

Analyze both options with pros, cons, and recommendation."

パターン 3：セキュリティ監査

これは /effort high 以上で実行してください。

"Perform a deep security audit.

Focus areas:
- Authentication and authorization
- Input validation
- Data encryption
- API security
- Dependency vulnerabilities

For each issue found, provide:
- Severity (Critical/High/Medium/Low)
- Description
- Remediation steps
- Code examples"

パターン 4：パフォーマンス調査

"The API is slow under load. Think through potential causes.

Observations:
- Response time increases from 50ms to 2s at 500 RPS
- CPU stays at 30%, memory at 60%
- Database connections spike
- No errors in logs

Analyze potential bottlenecks and suggest investigation steps."

コストとキャッシュへの影響

重要: thinking はトークンを消費し、セッション途中でモデルや effort を変えるとプロンプトキャッシュを失うことがあります。

┌─────────────────────────────────────────────────────────────┐
│              What Thinking Costs You                        │
│                                                             │
│  Tokens:                                                    │
│  ├── Every thinking token is billed, even when collapsed    │
│  └── Higher effort -> more thinking -> more tokens          │
│                                                             │
│  Prompt cache:                                              │
│  ├── Switching models starts a fresh cache                  │
│  ├── Changing effort resets it on most models               │
│  └── Opus 5.5, Sonnet 5.5, Haiku 5.5 and Fable 5.1 keep it  │
│      (with an API key or a Claude subscription)             │
└─────────────────────────────────────────────────────────────┘

effort の変更でキャッシュがリセットされるモデルでは、キャッシュがまだ有効なうちに Claude Code が確認を求めます。

推奨事項: モデルと effort レベルはセッションの最初に決め、より深い推論は日常的なタスクではなく価値の高い意思決定のために取っておきましょう。

モデル選択ガイド

Haiku 5.5 を使用する場合（十分に機能する最小の effort で）

Best for:
- File searches and exploration subagents
- Pattern matching
- Simple code generation
- Bulk operations

Thinking is adaptive and always on; keep effort
low for mechanical work.

Example:
"Find all uses of deprecated API in the codebase"

Bedrock、Agent Platform、Foundry、Claude Platform on AWS では haiku は今も Haiku 4.5 を指し、固定予算で thinking し、effort 設定は受け付けません。

Sonnet 5.5 を使用する場合（デフォルトは `medium`）

Best at medium effort:
- Standard implementations
- Code refactoring
- Test writing
- Documentation

Raise to high for:
- Complex implementations
- Multi-file refactoring
- Architecture-sensitive changes

Example:
"Implement the user authentication system following
our security patterns. ultrathink about the token
refresh mechanism design."

Opus 5.5 / Fable 5.1 を使用する場合（最も深い推論）

Best for:
- Architecture decisions
- Security audits
- Complex debugging
- Critical code paths

Opus 5.5 defaults to medium; raise it to high or
xhigh for this work. Fable 5.1 defaults to high.

Example:
"Review the payment processing implementation,
especially the transaction handling logic."

Agent での Thinking Mode

v2.1.198 以降、サブエージェントはメイン会話の thinking 設定を継承します。セッションで thinking がオンならサブエージェントでもオンです。サブエージェント単位の thinking スイッチはないため、深さは各サブエージェントのモデルと effort で調整します。

Explore Agent（Haiku）

組み込みの Explore エージェントはメイン会話のモデルで動作します（メインが Fable で、サブスクリプションまたは Console アカウントでサインインしている場合は opus のモデルを使います）。探索を安く保つには、model: haiku を指定した Explore という名前のサブエージェントを自分で定義するか、Claude に Haiku で検索を実行するよう頼みます。

Agent({
  description: "Find auth patterns",
  subagent_type: "Explore",
  model: "haiku",
  prompt: "Find authentication patterns (thoroughness: medium)"
})

追加の effort は不要 - 純粋な検索と発見のため。

Implementation Agent（Sonnet + High Effort）

複雑な実装では、サブエージェントの effort を上げます。

Agent({
  description: "Implement OAuth with PKCE",
  subagent_type: "general-purpose",
  model: "sonnet",
  effort: "high",
  prompt: `
    Implement OAuth 2.0 with PKCE flow.
    Consider:
    - State management
    - Token storage
    - Refresh handling
    - Error recovery
  `
})

Review Agent（Opus + xhigh Effort）

重要なレビューには Opus と xhigh effort を使用します。

Agent({
  description: "Security review payments",
  subagent_type: "general-purpose",
  model: "opus",
  effort: "xhigh",
  prompt: `
    Security review the payment integration.
    Check for:
    - PCI compliance issues
    - Data exposure risks
    - Authentication bypasses
    - Rate limiting gaps
  `
})

頻繁に実行するレビューは、カスタムサブエージェントのフロントマターに model: opus と effort: xhigh を書いておけば、毎回同じ設定で実行されます。

実践的な例

例 1：機能設計

"I need to add collaborative editing to our document app.

ultrathink.

Constraints:
- Real-time sync (< 100ms)
- Handle offline mode
- Conflict resolution
- Undo/redo support

Analyze:
1. Technology options (CRDT, OT, etc.)
2. Architecture approach
3. Trade-offs of each option
4. Recommended path forward"

例 2：移行計画

/model opus
/effort high

"We're migrating from MongoDB to PostgreSQL.
Create a migration plan.

Current state:
- 50 collections
- 10M documents
- 5 services depending on data
- Zero downtime requirement

Deliverables:
1. Migration strategy
2. Schema design
3. Service update plan
4. Rollback strategy
5. Testing approach
6. Timeline estimate"

例 3：デバッグセッション

"Production issue: Intermittent 500 errors on /api/checkout.

Think through this carefully.

Data points:
- Happens ~1% of requests
- No pattern in time of day
- No correlation with request size
- Started after last deploy
- Logs show: 'Connection reset by peer'

Analyze potential causes and investigation steps."

例 4：コードレビュー

"ultrathink: review this PR.

PR adds: Payment processing with Stripe

Focus areas:
- Error handling completeness
- Idempotency of operations
- State machine correctness
- Webhook handling security
- Test coverage adequacy

Provide detailed feedback with specific line references."

Thinking Mode の設定

プロジェクトレベル

thinking は既定でオンなのでプロジェクト設定は不要です。設定するのは effort です。.claude/settings.json で次のように書きます。

{
  "model": "sonnet",
  "modelSettings": {
    "claude-opus-5-5": { "effortLevel": "high" }
  },
  "maxEffortLevel": "xhigh"
}

modelSettings はモデルごとに effort レベルを与え（この例では誰かが Opus 5.5 に切り替えたとき high で動作します）、maxEffortLevel はすべてのモデルの上限を xhigh にします。トップレベルの effortLevel（low、medium、high、xhigh）は、このプロジェクトの全モデルに 1 つのデフォルトを設定します。

タスクごとのトリガー

Claude Code に thinkingConfig や thinkingTriggers という設定はありません。同じ目的は次の 3 つの実在する仕組みで満たせます。

1 ターンだけ深くするプロンプト内の ultrathink。
スキルやサブエージェントのフロントマターの effort。常に深さが必要な作業に常に深さを与えます。
最も高価なレベルに手が届かないようにする maxEffortLevel。

たとえば、常に xhigh で実行するセキュリティレビュー用スキルはこうなります。

---
name: security-review
description: Deep security review of the current diff
effort: xhigh
---

Review the diff for authentication, authorization, and input-validation issues.
Report each finding with a severity and a file and line reference.

コスト対効果の分析

Extended Thinking が効果的な場合

シナリオ	推奨 effort	品質向上	ROI
アーキテクチャの意思決定	`high`〜`xhigh`	数ヶ月の手戻りを回避	非常に高い
セキュリティレビュー	`high`〜`max`	脆弱性の発見	非常に高い
複雑なリファクタリング	`high`	より良い設計	高い
バグ調査	`high`	より迅速な原因特定	高い
日常的なコーディング	モデルのデフォルト	わずかな改善	低い

スキップすべき場合

次の作業はモデルのデフォルト、あるいはそれ以下の effort のままにします。

ファイル検索
パターンマッチング
シンプルなコード変更
ドキュメントの更新
定型的なテスト

ベストプラクティス

1. 深さについて明示的に指定する

"ultrathink: analyze this code for security issues."

以下のようにしない：

"Analyze this code."

2. 豊富なコンテキストを提供する

深い推論はコンテキストがあるとより効果的に機能します。

"ultrathink: design the caching layer.

Context:
- Current: No caching, 200ms average response
- Goal: <50ms for 80% of requests
- Constraints: Redis available, 5GB memory budget
- Traffic: 10K RPM, 80% reads

Consider cache invalidation, TTL strategies, and
cache stampede prevention."

3. 構造化された出力を要求する

"Think through this architecture decision.

Output format:
1. Options considered (3-5)
2. Evaluation criteria
3. Analysis matrix
4. Recommendation with rationale
5. Risk assessment"

4. Agent と組み合わせる

オーケストレーションに effort を、実行にスピードを割り当てます。

"Phase 1 (Opus 5.5, xhigh effort): Design the migration strategy
Phase 2 (Sonnet 5.5, medium effort): Implement each migration step
Phase 3 (Haiku 5.5, low effort): Run tests in parallel"

Thinking 使用状況のモニタリング

Effort と Context の確認

セッションヘッダーにはモデル名の横に有効な effort が表示され（例：「with low effort」）、/effort status でも確認できます。/context はコンテキストウィンドウを何が占めているかを示します。カスタムステータスラインはモデル、effort レベル、thinking の状態、コンテキスト使用量を JSON で受け取るので、常時表示しておけます。

{
  "statusLine": {
    "type": "command",
    "command": "jq -r '\"[\\(.model.display_name)] \\(.effort.level // \"-\") effort | \\(.context_window.used_percentage // 0)% context\"'"
  }
}

セッションに応じた調整

5.5 ファミリーと Fable モデルでは thinking をオフにできないため、定型的なファイル更新が続くときは代わりに effort を下げます。/effort を開いて low を選び、s を押せばこのセッションだけに適用されます。/effort low と入力した場合は、そのモデルのデフォルトとしても保存されます。

始め方

今日：

デフォルトの effort でアーキテクチャの質問を 1 つし、次に ultrathink を付けてもう一度試す
出力品質を比較する
時間とトークンの差を /usage で確認する

今週：

プロジェクトのデフォルトモデルとモデルごとの effort を決める
より多くの effort が有効なタスクを特定する
深い推論に豊富なコンテキストを与えるプロンプトを作成する

今月：

チーム向けの effort ガイドラインを確立する
深さが必要なスキルとサブエージェントのフロントマターに effort を追加する
意思決定品質への影響を測定する

Extended Thinking は Claude を高速な応答者から思慮深いパートナーへと変えます。重要な意思決定に戦略的に effort を投じれば、アーキテクチャ決定の質が向上するのを実感できるでしょう。

出典: Claude Code model configuration, Claude Code CHANGELOG