Claude 4.5でthinking modeを使用する方法

「Thinking mode」（extended thinking、thinking、thinking blocksとも）は、Claude 4.5 における明示的かつ設定可能な動作モードで、最終的な回答を出力する前に、モデルが内部で段階的な推論（“chain-of-thought”）を生成するための専用トークン予算を消費するよう指示します。これは、待ち時間とトークンコストを引き換えに、より深い内部熟考を行うことで、多段推論、複雑なコーディングやエージェント的ワークフロー、リサーチタスクの性能を高めるよう設計されています。Claude 4.5 は Messages API レベルでこの機能を明示的なパラメータ（例：thinking / budget_tokens や effort/“interleaved-thinking” ヘッダー）として提供し、後で検証やツール利用のために思考ブロックを保持し、必要に応じて暗号化します。また、本番ワークロード構築時に管理すべきキャッシュおよびトークン計上の挙動を導入しています。

Claude 4.5 とは？（どのモデルを気にすべき？）

Claude 4.5 は、段階的な「4.5」アップデートとしてリリースされた最新の Claude モデル群（例：Sonnet 4.5、Opus 4.5）です。Sonnet 4.5 は、ほとんどの開発者にとって知性、コーディング、エージェント性能の最良バランスを提供する位置づけです。Opus 4.5 は非常に高い努力度の推論に注力し、マルチターンの連続性を高めるために思考ブロックを保持します。両モデルとも Claude の拡張思考機能をサポートしており、振る舞い（例：要約版と完全版の思考など）はモデルによって一部異なります。

Claude 4.5 の性能向上、とりわけ Sonnet 4.5 で顕著な改善は、実世界の GitHub イシュー解決能力を測定する SWE-bench Verified ベンチマークで最も明確に現れます。

これらの数値は、Claude 4.5 が単にスニペットを書くのに優れているだけではなく、ファイルシステム全体を探索し、人間の介入なしに自律的にタスクを実行する能力が大幅に向上していることを示しています。

なぜ重要か

• コーディングとエージェント: Sonnet 4.5 は、実世界のソフトウェアタスクや長期的なコーディング作業で大きな向上を示しており、コード生成、コード編集、自律エージェントフローに自然に適しています。
• 拡張思考とコンテキスト: Claude 4.5 ファミリは非常に大きな内部スクラッチパッド（数万トークン以上）で推論するよう設計されており、より深い多段推論を可能にします。これは、プロンプト設計、トークン予算、ツール連携の方法に影響します。

Claude 4.5 の Thinking Mode とは？

Thinking Mode（正式名称は "Extended Thinking"）は、モデルが最終出力を提供する前に自分自身に対して「作業過程」を見せるための機能です。標準モデルが即座に回答にコミットするのとは異なり、Claude 4.5 は専用の推論スペースを用いて、複数の仮説を検討し、論理の潜在的な誤りを特定し、戦略を洗練します。

レスポンスの構造

標準の対話では、モデルはプロンプトを受け取り回答生成を開始します。Thinking Mode では、レスポンスは 2 つの明確なブロックに分かれます。

Thinking mode の主要な特性

• 要求により有効化: {"type":"enabled","budget_tokens":10000} のような thinking オブジェクトを API コールで渡すことで有効化し、内部推論用のトークン予算を与えます。
• 予算管理: budget_tokens はモデルの内部推論トークンを上限設定します。予算が増えると => 推論の深さの可能性が高まる一方で、コストと待ち時間が増加します。Claude 4 系モデルでは、要約ビューしか受け取らない場合でも思考トークンは課金されます。
• 要約と編集（レダクション）: 多くの Claude 4 系モデルでは、ユーザーが目にするのは内部推論の要約版です。内部推論の一部は安全システムにより編集（暗号化）され、redacted_thinking として返される場合があります。
• 署名と検証: 思考ブロックには不透明な signature が含まれており、思考ブロックを API に返す際の検証（特にツール利用時）に用いられます。署名は不透明なものとして扱い、解釈や解析を試みないでください。
• ツールとのインタリーブ思考: Claude 4 は思考ブロックとツール実行をインタリーブ（モデルによってはベータ/フラグが必要）でサポートします。これはエージェント的ワークに有効です（ツールを実行→考える→別のツールを実行→…）。

最新の事例やパラメータについては、Anthropic の Messages/Extended Thinking ドキュメントが正準の参照です。

Messages API は thinking コンテンツをどのように返すか

要約版 vs フル thinking／暗号化と署名

Claude の各モデルバージョンは thinking の扱いが異なります。より新しい Claude 4 モデル（Sonnet/Opus 4.5 など）では、内部推論の「公開ビュー」を要約で返すことが多く、完全なスクラッチパッドは暗号化され、signature フィールド（または redacted ブロック）としてのみ利用可能な場合があります。ツールを使う場合（あるいはツールコール間で内部状態を保持する必要がある場合）、返却された思考ブロックを API に戻すか、ドキュメントに記載の署名メカニズムを使用してください。このメカニズムは、機密性の高い内部推論を保護しつつ、必要なときに安全に思考過程を継続できるようにします。

実務的な取り扱いパターン

ツール利用／継続: 次のリクエストで同じ内部状態を継続する必要がある場合（例：thinking に基づいてツールが実行された）、返却された思考ブロックまたは署名を次回の API コールに含めて、モデルが復号し前回の続きから進められるようにします。

Request: thinking: {type: "enabled", budget_tokens: N} を送信します。

Response: （a）公開出力の要約、（b）暗号化された signature または redacted_thinking ブロック、（c）その両方が返る可能性があります。

CometAPI は公式 API 価格の 20% の価格で Claude 4.5 API を提供しており、Anthropic Messages を用いて呼び出すこともできます。開始前に API キーの取得が必要です。

例 1 — シンプルな curl（非ストリーミング）で thinking を有効化

curl https://api.cometapi.com/v1/messages \
  -H "x-api-key: $CometAPI_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 16000,
    "thinking": {
      "type": "enabled",
      "budget_tokens": 10000
    },
    "messages": [
      {"role": "user", "content": "Design a robust data validation strategy for CSV imports, show tests + code."}
    ]
  }'

レスポンスには content ブロックが含まれます。各ブロックを検査し、最終出力には text ブロックを優先してください。thinking ブロックにはモデルの内部分析の要約が含まれます。

例 2 — Python：リクエスト、thinking と text ブロックの解析

import os, requests

API_KEY = os.environ["CometAPI_API_KEY"]
URL = "https://api.cometapi.com/v1/messages"
HEADERS = {
    "x-api-key": API_KEY,
    "anthropic-version": "2023-06-01",
    "content-type": "application/json"
}

payload = {
    "model": "claude-sonnet-4-5",
    "max_tokens": 16000,
    "thinking": {"type": "enabled", "budget_tokens": 8000},
    "messages": [{"role": "user", "content": "Explain how to do property-based testing in Python; include example code."}]
}

r = requests.post(URL, headers=HEADERS, json=payload)
r.raise_for_status()
resp = r.json()

# Parse blocks
for block in resp.get("content", []):
    if block.get("type") == "thinking":
        thinking_summary = block.get("thinking")
        print("=== THINKING (summary) ===")
        print(thinking_summary[:1000])  # truncate for logs
        print("signature:", block.get("signature")[:64], "...")
    elif block.get("type") == "text":
        print("=== FINAL TEXT ===")
        print(block.get("text"))

このコードは、要約された thinking と最終回答を抽出して出力します。マルチターンのエージェントフローで継続性を維持する必要がある場合は、次のリクエストの messages 配列に未修正の思考ブロックを含めてください（次の例を参照）。

例 3 — マルチターンフローで思考ブロックを再利用する（Python 擬似）

# After initial response (resp above):
# Add the assistant message including the thinking block back into the conversation
assistant_message = {
  "role": "assistant",
  "content": resp["content"]  # include raw content array (contains thinking + text blocks)
}

# Next user turn: ask follow-up and include previous assistant message
payload2 = {
  "model": "claude-opus-4-5",  # Opus preserves thinking blocks better across turns
  "max_tokens": 20000,
  "thinking": {"type": "enabled", "budget_tokens": 12000},
  "messages": [
    {"role": "user", "content": "Now adapt the validation logic for an avro pipeline."},
    assistant_message
  ]
}
r2 = requests.post(URL, headers=HEADERS, json=payload2)

ツール統合や長時間のエージェントワークフローを行う場合、思考ブロックを正確に未修正のまま保持することが極めて重要です。Opus 4.5 はターン間の思考ブロック保持とキャッシングに関するデフォルトが改善されています。

thinking 出力をストリーミングし、UI に進捗を表示するには？

ストリーミングのベストプラクティス

• SDK のストリーミングエンドポイントを使用します（Python/TypeScript SDK にはストリームヘルパーがあります）。長時間または高予算の推論ジョブでは、ストリーミングにより HTTP タイムアウトを防ぎ、モデルの計算中に部分的なテキストを受け取ることができます。一般的なコードは text_stream（Python）やイベントパース（JS）を反復処理します。
• 二段階ストリームに備えます：モデルは最初に可視の推論チャンクを生成し、その後回答を確定することがあります。チャンク化されたコンテンツに対応し、「thinking…」と最終回答の状態を表示できる UI を構築してください。
• API がストリーミング時に signature_delta や content_block_delta を返す場合、それを捕捉し、仕様に従って後続のコールに添付してください。

UI で推論の進捗を途中表示する必要がある場合は、レスポンスをストリーミングしてください。サーバーは thinking_delta イベントに続いて text_delta イベントを発行します。

curl https://api.cometapi.com/v1/messages \
  --header "x-api-key: $CometAPI_API_KEY" \
  --header "anthropic-version: 2023-06-01" \
  --header "content-type: application/json" \
  --data '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 16000,
    "stream": true,
    "thinking": { "type": "enabled", "budget_tokens": 8000 },
    "messages": [ { "role": "user", "content": "Walk me through debugging this failing unit test and propose fixes." } ]
  }'

ストリーミング時は、content_block_start、content_block_delta（thinking_delta と text_delta を含む）、content_block_stop イベントを順に処理してください。これにより、モデルのステップごとの推論を進行中に表示できます。

Claude Code は thinking mode とどのように連携するか？（terminal + VS Code）

Claude Code は、Messages API とツールランナーを統合したインタラクティブなエージェント的コーディングターミナルです。CLI/IDE 体験では次の 2 つの方法で thinking を公開します。

• グローバル／セッション単位の設定: Claude Code は /config 設定パネルを用意しており、動作（権限リクエストの方法、思考ブロックを保持するかなど）を調整できます。永続的な動作変更をしたい場合は、生の JSON を再入力するのではなく、この UI を使用してください。
• モデル選択と CLI コマンド: REPL で claude-sonnet-4-5 や claude-opus-4-5 をアクティブモデルとして選択できます。ツールと thinking の挙動は Messages API のセマンティクスに従います。CHANGELOG とリリースノートによれば、Opus 4.5 の一部デプロイでは thinking がデフォルトで有効になっており、その設定は /config に表示されます。

Claude Code の実務的なフロー:

1. REPL でプロジェクトを開始。
2. /config を使用して thinking 関連のフラグ（保持、詳細度など）を確認。
3. 長いタスクの実行をエージェントに依頼 — 必要に応じてツール実行の許可を求めます。後で検証や再実行が必要な場合は、思考ブロックを保持してください。

インストールとセットアップ

Claude Code は Node.js を必要とし、グローバルにインストールできます。

# Install Claude Code CLI
npm install -g @anthropic/claude-code

# Authenticate
claude-code --init

ターミナルで Thinking を有効化

Claude Code は、推論の深さを制御するための各種フラグと自然言語トリガーをサポートします。

Tips:

• 代替実装の検討が必要な場合は、think／think harder を使用してください。
• Claude Code がツールコール（テスト実行、git 操作など）を行う際、CLI/エージェントが thinking ブロックを返す場合はそれを保持してください。そうしないとステップ間でコンテキストが失われる可能性があります。

インタリーブ思考とブロック保持の利点

高度なエージェント的ワークフロー向けに、Claude 4.5 はマルチターン対話とツール利用を大幅に強化する 2 つのベータ機能を導入しました：Interleaved Thinking と Thinking Block Preservation。

Interleaved Thinking（ベータ）

標準の推論は出力前に一度だけ行われます。Interleaved Thinking（interleaved-thinking-2025-05-14 ヘッダーで有効化）は、Claude がツールコールの合間に「考える」ことを可能にします。

Claude がサーバーをデバッグしていると想像してください：

1. Think: 「最初にログを確認すべきだ。」
2. Tool Call: read_file(logs.txt)
3. Think: 「ログにはデータベースのタイムアウトが出ている。次は接続プール設定を確認する必要がある。」
4. Tool Call: read_file(db_config.yml)

この「継続的反省」により、モデルはツールから得たデータに基づいて戦略を適応させ、硬直した事前計画に従うのではなく柔軟に進められます。

Thinking Block Preservation

ツール利用を含むマルチターン対話では、前回の thinking ブロックを API に渡すことが極めて重要です。

• 推論の継続性: 以前の思考を受け取ることで、Claude は推論の論理的コンテキストを維持します。
• Opus 4.5 の最適化: Claude Opus 4.5 では、この挙動が自動化されています。モデルは既定で過去の思考ブロックをコンテキスト内に保持し、30 時間以上続くセッションでも、10 ターン前に特定のアーキテクチャ決定を行った理由を「忘れない」ようにします。

Claude 4.5 の THINKING mode を使用するベストプラクティス

タスクに適したモデルと予算を選ぶ

コーディングとエージェント的ワークフローには Sonnet 4.5 を使用すると、速度・コスト・強力なコーディング能力の最良のトレードオフが得られます。最も深い推論や最大のコンテキストウィンドウ、長時間の自律セッションを計画する場合は Opus 4.5 を使用してください。両者とも拡張思考をサポートします。budget_tokens はタスクの複雑さに比例して設定し（まずは小さく実験し、品質の顕著な向上が見られた場合のみ引き上げる）、調整してください。

コストと待ち時間の監視と制御

課金は、受け取る要約出力ではなく、Claude が生成した思考トークンの「全量」に対して行われます。つまり、内部熟考が長いほど、要約を受け取るだけでもコストが増加します。トークン使用量を追跡し、探索から本番への移行時には段階的なチューニング（例：2k → 8k → 32k）を検討してください。

必要な場合のみ思考ブロックを保持する

思考ブロックは暗号学的に署名され、後の検証やインタリーブツール利用のために保持できます。ワークフローがモデルに過去の内部熟考を保持させる必要がある場合（例：エージェントがステップを再実行し、保持された根拠が必要）のみ、毎回のリクエストで思考ブロックを反映するようにしてください。常時保持するとコンテキストが膨らみ、トークン計上が複雑化します。

thinking をユーザーにストリーミングする場面

ストリーミングされた thinking は、開発者向けツールや教育的 UI に適しています（モデルが熟考中であることを「進行中」として表示）。ただし、要約や編集を考慮せずに生の thinking をコンシューマー向け本番アプリのエンドユーザーに配信しないでください。要約 thinking はそのために存在します。ストリーミングする場合は、「Assistant reasoning — internal」のように内部推論であることを UI で明示し、最終ユーザーに要約版と完全版のどちらを見せるかを制御してください。

ツール利用とインタリーブ

thinking とツール（コード実行、Web 取得、ローカルプロセス）を組み合わせる場合、モデルがツールを選択・実行し、その結果を同一ターン内で推論するために、インタリーブ思考 の設計を使用してください。インタリーブは複雑性を増し（フラグが必要な場合もあります）が、エージェント的自動化に強力です。保持する thinking の範囲を明確にし、thinking 有効化時のツール選択の挙動をテストしてください。

実務的なトラブルシューティングと運用メモ

よくあるエラーとその意味

• 無効な thinking と強制的なツール選択: thinking を要求しつつ、thinking と互換性のない特定のツール利用モードを強制すると、API はエラーを返します。tool_choice: {"type":"tool","name":"..."} と thinking を併用しないでください。
• Budget > max_tokens: インタリーブ思考のシナリオでは有効トークンルールが異なります — プラットフォームドキュメントに、budget_tokens が max_tokens を超えてよいケースが説明されています。大規模予算をテストする前に「インタリーブ思考」セクションを熟読してください。
• 署名検証: 後続コールのために思考ブロックを保持する場合は、返却された signature を含め、Claude からのものであることを API が検証できるようにしてください。これにより改ざんを防ぎ、検証可能な連鎖を維持します。

可観測性と計測

ログには次を記録してください：（1）model の選択、（2）thinking.budget_tokens、（3）実際の思考トークン消費量（課金されます）、（4）ストリーミング遅延（最初の thinking_delta までの時間）、（5）最終テキストトークン。これらの指標から、ユーザー向けフローの予算や SLO を構築します。

段階的ロールアウトと人間の関与

thinking 有効化モデルは機能フラグの背後でロールアウトしてください。まずは開発者や社内トラフィックの一部から開始し、失敗や編集事例を収集し、プロンプトや予算を反復します。機微な領域では、内部推論を多く含む出力については公開前に人間によるレビューを義務付けてください。

デバッグのヒント

• まずは小さく：低い budget_tokens を有効化し、段階的に拡張して増分的な改善を把握します。
• ストリーミングをオンにし、content_block_delta／署名イベントをログに記録して、モデルが思考ブロックを生成するタイミングを理解します。
• Claude Code を使用している場合：/config とプロジェクトレベルの設定を確認し、期待されるデフォルトと挙動が一致しない場合は Claude Code の changelog を参照してください。

結論:

Extended Thinking と Claude Code CLI の力を組み合わせた Claude 4.5 は、IDE の発明以来、開発者の生産性における最も重要な飛躍をもたらします。モデルが「作業過程」を示し、複雑な問題について熟考できるようにすることで、Anthropic は「チャットボット」時代を超え、「エージェント」時代へと進みました。

Messages API をカスタム開発ツールに統合する場合も、Claude Code で日々の PR を管理する場合も、Thinking Mode の習得は不可欠です。これは信頼に必要な透明性と、卓越性に必要な推論の深さを提供します。

開発者は CometAPI 経由で Claude 4.5（Claude Sonnet 4.5、Claude Haiku 4.5、Claude Opus 4.5）モデルにアクセスできます。開始するには、CometAPI のモデル機能を Playground で試し、詳細は API ガイドを参照してください。アクセス前に、CometAPI にログインして API キーを取得済みであることを確認してください。CometAPI は、統合を支援するために公式価格よりはるかに低い価格を提供しています。

Ready to Go?→ Free trial of Claude 4.5!