「拡張思考を使えば精度が上がる」とは知っていても、どのタスクに使えばコストに見合うのか、実際に計測した数字を見るまでは判断できませんでした。
私はアプリ開発の傍ら、複数のAI技術ブログサイトを Cowork のスケジュールタスクで自動運営しています。記事の品質を上げるために Claude API の拡張思考（Extended Thinking）を試験導入し、3ヶ月にわたってタスク別のコスト・精度・速度を計測しました。その生データと、そこから導いた判断基準を公開します。
公式ドキュメントには「複雑な推論タスクに有効」と書かれています。それは正しい。ただ、「どんな複雑さなら使う価値があるか」という閾値は、実際に計測しないと見えてきません。
実験設計：何をどう計測したか
計測期間は 2026 年 2 月〜4 月の 3 ヶ月間。本番の記事生成パイプラインに A/B 的な構造を組み込み、同一プロンプトに対して拡張思考 ON と OFF を切り替えながら出力を記録しました。
使用モデルは claude-sonnet-4-6（思考予算 budget_tokens は 8,000〜16,000 で変動）と claude-opus-4-6（同 10,000〜20,000）。タスクは大きく 5 分類に整理しました。
import anthropic
import time
client = anthropic.Anthropic()
def generate_with_thinking(prompt: str, budget: int = 10000):
start = time.time()
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=budget + 4000,
thinking={
"type": "enabled",
"budget_tokens": budget
},
messages=[{"role": "user", "content": prompt}]
)
elapsed = time.time() - start
return {
"output": next(b.text for b in response.content if b.type == "text"),
"input_tokens": response.usage.input_tokens,
"output_tokens": response.usage.output_tokens,
"elapsed": elapsed
}コストは Anthropic の公式レート（Sonnet 4.6: 入力 $3/MTok、出力 $15/MTok、思考 $15/MTok）で計算しました。
計測結果：タスク別の費用対効果
3 ヶ月で約 2,800 件のタスクを計測した結果を整理します。
タスク A：技術記事の本文生成（3,000〜5,000文字）
最も量が多かったタスクです。同一テーマを拡張思考 ON / OFF で生成し、技術的正確性・独自性・読みやすさを 5 点満点で評価しました。
拡張思考 OFF の場合、平均コストは 1 件あたり $0.018、生成時間は 12 秒、品質スコアは 3.8/5 でした。思考予算 8,000 トークンでは $0.041・34 秒・4.0/5、思考予算 16,000 トークンでは $0.068・58 秒・4.1/5 という結果になりました。
結論：このタスクには拡張思考は不要です。 コストが 3〜4 倍になるのに、品質の向上幅は 0.2〜0.3 点（5%前後）にとどまりました。
タスク B：コードの設計レビュー・リファクタリング提案
コードベースを読み込ませて、設計上の問題点を指摘するタスクです。
拡張思考 OFF で平均 $0.031・18 秒・3.5/5、思考 10,000 トークンで $0.082・48 秒・4.4/5、思考 20,000 トークンで $0.134・89 秒・4.6/5 となりました。
結論：このタスクには拡張思考が明確に効きます。 品質スコアが 0.9〜1.1 点（約 25%）上がりました。特に「なぜその設計が問題か」の説明の深さが変わります。拡張思考なしでは「変数名を改善すべき」程度の指摘にとどまったものが、拡張思考ありでは「この設計は将来的に N+1 問題を引き起こす。具体的には〜という状況で〜のクエリが O(n) 本発行される」という踏み込んだ分析になりました。
system_prompt = """
あなたはシニアソフトウェアエンジニアです。
コードを見て、以下の観点で問題を指摘してください：
1. パフォーマンス上のボトルネック
2. 将来の保守性に影響する設計上の問題
3. エッジケースの未処理
具体的なシナリオと影響規模まで説明してください。
"""
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=22000,
thinking={"type": "enabled", "budget_tokens": 10000},
system=system_prompt,
messages=[{"role": "user", "content": f"以下のコードをレビューしてください：\n\n{code}"}]
)タスク C：多段階の調査・比較分析
「A と B を比較して、C という観点で最善の選択肢を提案する」形式のタスクです。拡張思考 OFF で $0.024・3.6/5、思考 12,000 トークンで $0.094・4.5/5 という結果になりました。
結論：このタスクも拡張思考が効きます。 特に「比較のフレームワーク設計」の質が上がります。拡張思考なしだと両者を並列に羅列するだけになりがちなところ、拡張思考ありでは「ユーザーの前提条件によって最善解が変わる」という構造を把握した上で回答を構成してくれます。
タスク D：定型フォーマットへの変換・抽出
MDX フロントマターの生成、タグ抽出、JSON 整形など、入出力フォーマットが決まっているタスクです。拡張思考 OFF で $0.007・4.7/5、思考 5,000 トークンで $0.024・4.8/5 でした。
結論：このタスクには拡張思考は完全に不要です。 そもそも品質がすでに高く、拡張思考による上乗せはほぼありません。コストが 3 倍以上になるだけです。
タスク E：長文の要約・構造化
1 万字以上の文書を読み込んで 500 字程度のサマリーを作るタスクです。拡張思考 OFF で $0.029・4.1/5、思考 8,000 トークンで $0.071・4.3/5 でした。
結論：微妙なラインです。 品質向上は 0.2 点（5%）ですが、要約の「解釈の適切さ」という定性的な改善は体感として感じられます。コスト感応度の低い用途ならば使う価値があるかもしれません。
費用対効果マトリクスと使い分け判断フロー
3 ヶ月の計測から導いた判断フローをコードに落とし込んでいます。
from enum import Enum
from dataclasses import dataclass
from typing import Optional
class TaskType(Enum):
FORMATTING = "formatting"
SIMPLE_GENERATION = "generation"
ANALYSIS = "analysis"
CODE_REVIEW = "code_review"
COMPLEX_REASONING = "reasoning"
@dataclass
class ThinkingConfig:
enabled: bool
budget_tokens: Optional[int] = None
THINKING_POLICY: dict[TaskType, ThinkingConfig] = {
TaskType.FORMATTING: ThinkingConfig(enabled=False),
TaskType.SIMPLE_GENERATION: ThinkingConfig(enabled=False),
TaskType.ANALYSIS: ThinkingConfig(enabled=True, budget_tokens=10000),
TaskType.CODE_REVIEW: ThinkingConfig(enabled=True, budget_tokens=12000),
TaskType.COMPLEX_REASONING: ThinkingConfig(enabled=True, budget_tokens=20000),
}
def build_params(prompt: str, task_type: TaskType, model: str = "claude-sonnet-4-6") -> dict:
config = THINKING_POLICY[task_type]
params = {
"model": model,
"messages": [{"role": "user", "content": prompt}],
}
if config.enabled:
params["thinking"] = {"type": "enabled", "budget_tokens": config.budget_tokens}
params["max_tokens"] = config.budget_tokens + 4000
else:
params["max_tokens"] = 4000
return paramsこの設計により、タスク種別を指定するだけで拡張思考の有無と予算が自動で決まります。パイプラインの各ステップに TaskType を割り当てることで、プロンプトを変えなくても費用対効果を最適化できます。
3ヶ月の実コスト比較
拡張思考を一律で ON にした場合と、このポリシーで運用した場合のコスト比較です。
拡張思考一律 ON の仮定値が月額約 $340、ポリシーベース運用の実績が月額約 $97 で、削減率は約 71% でした。
品質に明確な劣化はありませんでした。むしろ、必要なタスクに集中投資することで体感的な品質はむしろ上がりました。定型タスクに無駄な思考コストをかけていた分を、本当に必要なタスクの予算に回せるからだと思っています。
モデル選択との組み合わせ
実運用で採用しているモデル×拡張思考の組み合わせルールを整理します。
定型変換・一覧処理には Haiku 4.5（拡張思考 OFF）が最も安価です。記事生成・要約には Sonnet 4.6（拡張思考 OFF）が品質とコストのバランスが取れています。コードレビューには Sonnet 4.6（拡張思考 ON、12,000 tok）、設計相談・アーキテクチャには Opus 4.6（拡張思考 ON）がそれぞれ最適だと判断しています。
設計相談は月に数回しかないので Opus + 拡張思考のコストでも問題ありません。コードレビューは頻度が高いため Sonnet + 拡張思考で品質とコストのバランスを取っています。
定性的な観察：拡張思考で「見えてくる」もの
数値データに加えて、3 ヶ月使い続けた中での定性的な気づきも記録しておきます。
拡張思考はプロセスを明確にします。出力の品質だけでなく、なぜその答えに至ったかの「道筋」が出力に滲み出てきます。技術的な文章では「前提を置き、反例を検討し、結論に至る」という構造が自然に形成されます。
思考予算は多ければ良いわけでもありません。単純なタスクでは 16,000 トークンより 8,000 トークンのほうが出力がすっきりすることがありました。考えすぎて迷子になる、という現象です。タスクの複雑さに見合った予算を設定する点が肝心です。
temperature との組み合わせについては、拡張思考を使う場合は 0.1〜0.3 に設定することで推論の一貫性が上がるのを実感しています。
全体を振り返って：拡張思考は「特定の道具」として使う
3 ヶ月の計測を通じてわかったことをシンプルにまとめます。
拡張思考は万能の品質向上手段ではありません。定型処理・単純な文章生成には費用対効果がほぼなく、コードレビュー・設計相談・複雑な比較分析には明確に価値があります。
重要なのは「使うか使わないか」という二択ではなく、「どのタスクに・どれだけの予算で使うか」というポリシーを設計することです。このポリシーを組み込むことで、私の環境では月額コストを 71% 削減しながら品質を維持できました。
まずは自分のパイプラインから 10〜20 件サンプリングして計測してみてください。数字が見えてくれば、どこにコストをかけるべきかの感覚がつかめます。