Claude 4.5で思考モードを使う方法

“Thinking mode”（extended thinking、thinking、または thinking blocks とも呼ばれる）は、Claude 4.5 における明示的かつ設定可能な動作モードで、最終回答を出力する前に、モデルが内部の段階的推論（“chain-of-thought”）を生成するために、別枠で予算化されたトークン数を消費するよう指示します。これは、レイテンシとトークンコストを深い内部熟考と引き換えに、マルチステップ推論、複雑なコーディングやエージェント型ワークフロー、リサーチタスクにおける性能を向上させるために設計されています。Claude 4.5 は Messages API レベルでこの機能を明示的パラメータ（例：thinking / budget_tokens もしくは 努力度/“interleaved-thinking” ヘッダー）として公開し、後の検証やツール利用のために thinking ブロックを保持し、任意で暗号化します。また、プロダクションのワークロードを構築する際に管理すべきキャッシュやトークン会計の挙動も導入します。

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

Claude 4.5 は、段階的な「4.5」アップデートとしてリリースされた最新の Claude モデル群（たとえば Sonnet 4.5 や Opus 4.5）です。Sonnet 4.5 は多くの開発者にとって、知能、コーディング、エージェント性能のベストバランスを目指しており、Opus 4.5 は非常に高い努力度の推論に注力し、マルチターンでの継続性向上のため thinking ブロックを保持します。どちらのモデルも Claude の拡張思考機能をサポートしますが、一部の挙動（例：要約版 vs フル思考）はモデルごとに異なります。

特に 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 系モデルでは、要約しか受け取らない場合でも thinking トークンは課金対象です。
• 要約と編集（レダクション）: 多くの Claude 4 モデルでは、ユーザーには thinking 内容の要約版が表示されます。一部の内部推論は安全性システムにより編集（暗号化）され、redacted_thinking として返される場合があります。
• 署名と検証: Thinking ブロックには、API に thinking ブロックを返す際（特にツール使用時）に検証に用いられる不透明な signature が含まれます。signature は不透明な値として扱い、解析を試みないでください。
• ツールとのインタリーブ思考: Claude 4 はツール実行と思考ブロックを交互に挟むこと（場合によりベータ・フラグが必要）をサポートします。これは、エージェント的なワークにおいて（ツールを実行 → 思考 → 別のツール実行 …）強力です。

ハンズオンの例や最新パラメータについては、Anthropic の Messages/Extended Thinking ドキュメントが正典的な参照先です。

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

要約版 vs フル思考、暗号化と署名

Claude のバージョンにより thinking の扱いは異なります。より新しい Claude 4（たとえば Sonnet/Opus 4.5）では、内部推論の要約版が一般公開される一方、完全なスクラッチパッドは暗号化され、signature フィールド（または redacted ブロック）でのみ利用できる場合があります。ツールを使用する場合（またはツールコール間で内部状態を保持する必要がある場合）は、thinking ブロックを API に返すか、ドキュメントで説明されている signature メカニズムを使用する必要があります。この仕組みにより、機微な内部推論を保護しつつ、必要な場合に安全に思考プロセスを継続できます。

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

ツール使用／継続: 次のリクエストで同じ内部状態を継続する必要がある場合（例：thinking に基づいてツールを実行した）、返却された thinking ブロックまたは signature を 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 配列に未加工の thinking ブロックを含めてください（次の例を参照）。

例 3 — マルチターンフローで thinking ブロックを再利用（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)

ツール統合や長いエージェントワークフローを行う場合、thinking ブロックを一切改変せずに正確に保持することが重要です。Opus 4.5 はターン間での thinking ブロック保持とキャッシュに関するデフォルトが改善されています。

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

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

• SDK のストリーミングエンドポイントを使用します（Python/TypeScript SDK にはストリームヘルパーがあります）。長時間または高予算の推論ジョブでは、ストリーミングにより HTTP タイムアウトを防ぎ、モデルの計算中に部分的なテキストを受け取れます。典型的なコードは text_stream（Python）やイベントパース（JS）を用います。
• 2 段階のストリームを想定してください。モデルがまず可視の推論チャンクを出力し、その後に回答を確定する場合があります。チャンク化されたコンテンツを扱い、「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 体験では、thinking は次の 2 つの方法で表面化されます。

• グローバル／セッション単位の設定: Claude Code は /config 設定パネルを提供し、動作（権限確認の仕方、thinking ブロックの保持可否など）を調整できます。永続的な挙動変更をしたい場合は、生の 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. 長時間タスクをエージェントに依頼します。thinking コンテンツが生成され、必要に応じて特定の bash 実行について許可を求めます。後から意思決定を検証・再実行したい場合は thinking ブロックを保持してください。

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

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

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

# Authenticate
claude-code --init

ターミナルで Thinking を有効化する

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

ヒント:

• 代替実装の模索が必要な場合は、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 ではこの挙動が自動化されています。モデルは既定で過去の thinking ブロックをコンテキストに保持し、30 時間超のセッションでも、なぜそのアーキテクチャ判断を行ったかをターン後に「忘れない」ようにします。

Claude 4.5 で THINKING モードを使うベストプラクティス

タスクに適したモデルと予算の選択

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

コストとレイテンシの監視・制御

課金対象は、受け取る要約の長さではなく、Claude が生成した thinking トークンの総量です。つまり、内部熟考が長いほど、たとえ要約が短くてもコストは増加します。トークン使用量を計測し、探索段階から本番移行にあたっては段階的なチューニング（例：2k → 8k → 32k）を検討してください。

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

Thinking ブロックは暗号学的に署名され、後で検証したり、インタリーブしたツール使用のために保持できます。ワークフロー上の必要がない限り、すべての後続リクエストで thinking ブロックをエコーしないでください。常時保持するとコンテキスト量が増え、トークン会計が複雑化します。

thinking をユーザーにストリームするタイミング

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

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

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

実運用におけるトラブルシューティングと注意点

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

• 無効な thinking + 強制ツール選択: thinking を要求しつつ、thinking と両立しない特定のツール使用モードを強制した場合、API はエラーを返します。tool_choice: {"type":"tool","name":"..."} と thinking を混在させないでください。
• Budget > max_tokens: インタリーブ思考のシナリオでは有効トークン規則が異なる場合があります。budget_tokens が max_tokens を超え得る条件は、プラットフォームドキュメントの「interleaved thinking」セクションを熟読してください。
• 署名検証: Thinking ブロックを保存して後で呼び出す場合、返却された signature を含めて API に渡してください。これにより改ざんが防止され、検証可能なチェーンが維持されます。

可観測性と計測

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

段階的ロールアウトと Human-in-the-loop

thinking 有効モデルはフィーチャーフラグの背後でロールアウトします。まずは開発者や内向けトラフィックの一部で開始し、失敗やレダクションを収集、プロンプトや予算を反復します。センシティブな領域では、内部推論が大きい出力についてリリース前に人的レビューを要求してください。

デバッグのヒント

• 小さく始める: 低い budget_tokens で有効化し、段階的に増やして、改善の差分を把握してください。
• ストリーミングを有効にし、content_block_delta / signature イベントをログに記録して、モデルが thinking ブロックを生成するタイミングを把握してください。
• Claude Code を使用している場合: /config とプロジェクトレベル設定を確認し、期待どおりでない場合は Claude Code の changelog を確認してください。

結論:

Claude 4.5 は、Extended Thinking と Claude Code CLI の力を組み合わせることで、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?→ Claude 4.5 の無料トライアル!