Claude Opus 5レビュー：5段階のEffort設定と料金・使い分け

Claude Opus 5は、複雑なコーディング、エージェント、エンタープライズ業務を想定したAnthropicのプレミアムモデルです。2026年7月24日に登場し、従来のOpusと同じ価格でFable 5に迫る能力を提供する、という明快な位置づけです。

価格だけを見れば、Opus 4.8からのアップグレードは難しくありません。ただし、本番環境への導入は単純ではありません。Thinkingがデフォルトで動作するようになり、Effortによってテキスト生成からツール利用まで作業量全体が変わります。さらに、以前の出力上限をそのまま使うと、推論が終わる前にタスクが打ち切られる可能性があります。

Claude Opus 5は性能の頂点ではなく、日常業務向けのプレミアムモデルです

日々発生する難しい仕事にはOpus 5が向いています。処理量とレイテンシが最優先ならSonnet 5を選びます。Fable 5へ進むのは、Opusでの評価に失敗したタスクで、しかも失敗の損失が2倍のトークン料金を上回る場合に限るべきです。

Anthropicも現在、同じ考え方でモデルを案内しています。最新のモデルガイドでは、判断に迷う開発者に対し、複雑なエージェント型コーディングやエンタープライズ業務ではOpus 5から始め、利用可能な最高水準の能力が必要になった段階でFable 5へ移るよう勧めています。

Opus 5のコンテキストウィンドウは100万トークン、同期出力の上限は128,000トークンです。コンテキストウィンドウとは、1回のリクエストでモデルが参照できる情報量であり、すべてのトークンに均等な注意が向くという保証ではありません。出力上限には内部のThinkingとユーザーに見える回答の両方が含まれるため、移行時には特に注意が必要です。

モデルIDはclaude-opus-5です。Claude API、Amazon Bedrock、Google Cloud、Microsoft Foundryで利用できます。Claudeアプリでは、Maxのデフォルトモデルであり、Proで使える最上位モデルです。

これは固定されたモデル順位ではありません。ワークロード上の証拠をもとに経路を変えるため、次のモデルが登場しても使い続けられるルーティング方針です。モデルの階層にこだわる必要はありません。

ベンチマークで見るべきは成功タスクあたりのコストです

Opus 5のベンチマークで重要なのは、すべての項目で首位になることではありません。より安い実行コストで、同じ合格結果に到達できるケースが多い点です。

Anthropicが公表した結果のうち、判断に関わるのは次の5つです。

• Frontier-Bench v0.1では、タスクあたりのコストを抑えながら、Opus 4.8の性能を2倍以上に伸ばしています。
• CursorBench 3.2では、EffortをmaxにしたOpus 5が、Fable 5の最高結果との差を0.5%以内に抑え、タスクあたりのコストは半分です。
• ARC-AGI 3では、Anthropicの比較における次点モデルの3倍のスコアを記録しています。
• Zapier AutomationBenchでは、同じタスクあたりコストで、合格率が次点モデルのおよそ1.5倍です。最も低いEffortでも、比較対象のどのモデルより多くのタスクに合格しています。
• OSWorld 2.0では、Fable 5の最高のコンピューター操作結果を上回り、コストは3分の1強に収まっています。

これらはベンダーが発表時に公開した結果であり、あらゆるリポジトリ、社内規定、ブラウザワークフローを横断する万能ランキングではありません。Effortを上げて追加のトークンを使うことで、合格する成果へつながり得るという方向性を示すデータです。一方、自社のエージェントで再試行が何回必要か、人が回答を却下する頻度はどの程度か、少し弱くても速い結果のほうがサービスレベル目標に合うかまでは分かりません。

そこで役立つのが、成功タスクあたりのコストです。すべての試行にかかったトークン料金、ツール呼び出し料金、プロダクト上重要なレイテンシ、人によるレビューを合算し、受け入れ基準を通過した出力数で割ります。

コーディングエージェントなら、テストに合格し、差分が依頼範囲に収まり、修正ラウンドなしでレビューを通ることを成功と定義できます。業務オペレーションのエージェントなら、レコードが正しく更新され、必要な承認を求め、裏付けのない操作を行わないことが基準になります。Effortを比較する前に、成果そのものを評価基準として明文化しなければなりません。

指標にすべきなのは、賢く見えるかどうかではありません。コストが分かっている状態で、成果が受け入れられたかどうかです。

同じワークロードなら料金は$9、$22.50、$45です

トークン構成が同じなら、Opus 5の料金はSonnet 5の期間限定価格とFable 5のちょうど中間です。

100件のタスクを例にします。1件あたり入力20,000トークン、出力5,000トークンを使うと、バッチ全体では入力200万トークン、出力500,000トークンです。

• Sonnet 5は、導入価格の入力$2・出力$10で**$9**です。
• Opus 5は、入力$5・出力$25で**$22.50**です。
• Fable 5は、入力$10・出力$50で**$45**です。

計算にはAnthropicの現行API料金を使っています。Sonnet 5の$2/$10という料金は2026年8月31日までで、その後の標準料金は$3/$15です。プロンプトキャッシュ、バッチ割引、Web検索、コード実行、再試行、モデルやEffort設定によるトークン使用量の変化は、この計算に含めていません。

この小規模な例では、OpusはSonnetより$13.50高く、FableはOpusより$22.50高くなります。バッチ全体で$13.50を超える価値のある修正を1回防げれば、OpusのSonnetに対する上乗せ分は正当化できます。Fableへ上げるなら、$22.50を超える失敗またはレビュー費用を防ぐ必要があります。

同じ条件で10,000件を処理すると、合計は$900、$2,250、$4,500です。OpusはSonnetより$1,350高く、Fableはそこからさらに$2,250上がります。試作段階では小さく見えたルーティングの違いが、本番規模では独立した予算項目になります。

Fast modeを考えると、この違いはさらに明確です。Opus 5を通常の約2.5倍の速度で動かす代わりに、料金は$10/$50と通常の2倍になります。100件の例では$45となり、Fable 5の基本トークン料金と同額です。標準の高速化スイッチとしてではなく、応答時間に上乗せ料金を払うだけのプロダクト価値がある場合に選びます。

Effort設定はトークン予算ではなく運用ポリシーです

まずはhighから始めます。これはClaude APIとClaude Codeのデフォルトで、Anthropicによればhighを明示した場合もEffortパラメータを省略した場合も動作は同じです。

Effortが制御するのは、Claudeが回答全体へ投入する作業量です。ユーザーに見えるテキストだけでなく、Thinking、ツール呼び出し、関数の引数まで含まれます。下げればトークン消費やツール操作を減らせる可能性があり、上げればより深い探索を行いやすくなります。ただし、厳密な上限ではなく振る舞いへのシグナルなので、lowでも難しい依頼ではThinkingが動くことがあります。

5つのレベルには、それぞれ適した役割があります。

lowは、安価で範囲が明確な仕事向けです。 分類、抽出、単純な変換、結果を容易に確認できる限定的なサブエージェント作業に使います。問い合わせを解決するエージェントより、どのキューへ送るかを決めるトリアージエージェントに適しています。

mediumは、本番運用でバランスを取る設定です。 手順は決まっていても入力が変わる、日常的なツール支援業務に向きます。顧客レコードの要約、定型回答の作成、明確な業務手順の適用などです。トークン料金やレイテンシが問題になったとき、デフォルトから最初に下げて試す候補です。

highは、日常的な難しい仕事のデフォルトです。 コード変更、微妙な判断を伴う分析、ミスの損失が大きく慎重な推論が必要な多段階エージェントに使います。上下の設定をすべて比較できるため、最初の計測地点として適しています。

xhighは、長時間にわたる仕事向けです。 Anthropicは、30分を超えて実行され、トークン予算が数百万に及ぶエージェント型タスクやコーディングタスクのためのレベルと説明しています。何度も探索し、多数のツールを呼び出し、長い実行を通じて計画を維持する必要がある場合に使います。

maxは、例外経路です。 最高の能力を引き出すため、トークン消費への制約を外します。xhighで失敗した後か、トークン効率より成果の価値を優先できるタスクだけを対象にします。

陥りやすい間違いは2つあります。

1つ目は、文章の長さをEffortで調整することです。Anthropicのドキュメントによると、Effortを変えてもOpus 5の表示される回答が確実に短くなるわけではありません。必要な長さはプロンプトで指定します。

2つ目は、難しそうなタスクをすべてmaxで始めることです。それではhighで合格できたかを学べず、その後のコスト議論も仮定のままです。見るべきなのは購入できる最高スコアではなく、求める成果を安定して満たす最も低い設定です。

Opus 5、Sonnet 5、Fable 5は誰に向いているのか

多くの利用者は、すべてのリクエストを1つのモデルへ任せるべきではありません。標準モデルを1つ決め、対象を絞ったエスカレーション経路を用意するのが合理的です。

資金調達後、エージェント製品を開発する創業者

検証しやすい大量のやり取りにはSonnet 5を使い、計画立案、矛盾するコンテキストの整理、ツール失敗からの復旧といった工程にはOpus 5を使います。

安全そうに見えるという理由で、すべてのターンをOpusに載せるのは危険です。大半のリクエストが予測可能な経路を通るなら、不要な仕事にプレミアム料金を払うことになります。安い経路を広く保ち、Opusは結果への影響が大きい工程へ絞ります。

複雑なオーケストレーションは、Opusのhighから始めます。既知の難しいタスク分類をxhighへ上げるのは、合格率の改善が追加トークンを賄える場合だけです。Fableへ送るのは、代表的なタスクでOpusが失敗し、事業への影響が2倍の単価に見合うときに限ります。

モデル基盤を標準化する中堅企業のCTO

Opus 5をプレミアム経路のデフォルトにし、モデルルーティングをポリシー上で可視化します。各ワークロードの責任者が、Sonnet、Opus、Fableを使う理由と、どの評価結果なら経路を変えるのかを説明できる状態にします。

Opus 4.8を使うすべてのリクエストで、モデル名の文字列だけを置き換えて移行完了としてはいけません。Thinkingがデフォルトになったことで、出力の挙動とトークン消費は変わります。既存のmax_tokens設定、キャッシュ済み会話の設計、検証プロンプトをすべて見直す必要があります。

Claude Sonnet 5の分析は、下限を判断する基準になります。現在の料金で合格品質を維持できるなら、Sonnetが優位です。Fableが上限となり、特定のワークロードでどちらかが優位だと証明されるまで、その中間をOpusが担います。

ビジネス業務を自動化するシニアオペレーター

複数のシステムやポリシー境界をまたぐ仕事にはOpusを使います。依頼を読み、アカウントを確認し、ルールを適用し、人の承認が必要か判断する仕事は、各工程が次の工程の結果を左右するため、要約を作るだけの作業より難しくなります。

ツールの範囲が限定された安定した手順にはmediumを使います。例外、曖昧な記録、矛盾する規定が頻繁に現れるならhighへ上げます。ベンチマークが優秀でも、取り消せない操作には人の承認を残してください。優れたモデルは定型レビューを減らせますが、説明責任をなくすものではありません。

Fableが合理的になるのは、極めて難しく、同時に極めて価値の高いタスクだけです。すべての結果を人が確認する運用なら、モデル料金を上乗せするより、レビュー画面を改善したほうが効果的な場合があります。

個人の技術開発者

プロダクトの形が変化している間はSonnet 5から始めます。難しいデバッグ、アーキテクチャレビュー、複数ファイルにまたがる実装はOpus 5へ移します。差が最も効くのは、失敗するとコンテキストの組み立て直しに大きなコストがかかる場面であり、小さな修正ではありません。

ベンダーをまたぐ選択は、別の論点として残ります。GPT-5.6とClaude Sonnet 5は、モデル品質だけでなく実行システムも異なります。Opus 5によってAnthropicのプレミアム経路は強化されますが、オーケストレーション、ツール権限、オブザーバビリティまで同じになるわけではありません。

4者とも判断が切り替わる点は同じです。計測した失敗コストとレビューコストがモデルの上乗せ料金を超えたら、アップグレードします。そのコストを誰も測っていないなら、エスカレーションの前に評価するのが安全な事業判断です。

Opus 4.8からの移行で挙動が変わる2つのポイント

claude-opus-4-8をclaude-opus-5へ変えても、単価は同じ$5/$25です。しかし、実行時の挙動まで同じにはなりません。

1つ目の変更は、Thinkingがデフォルトになったことです。Opus 4.8は、リクエスト側で有効にしない限りThinkingなしでも動作できました。Opus 5は、いつ、どの程度考えるかをデフォルトで判断します。max_tokensはThinkingと表示される回答の合計を制限するため、Opus 4.8では十分だった上限でも、Opus 5のエージェントが完了前に途切れる可能性があります。

2つ目は、ThinkingとEffortの関係です。Thinkingを無効にしたリクエストでxhighまたはmaxを設定すると、APIはHTTP 400を返します。Thinkingを無効のままにする必要があるならEffortはhigh以下に抑え、高いEffortを使うならThinkingを無効にするフィールドを削除します。

Anthropicは、Thinkingを無効にすると、Opus 5が正規のtool_useブロックを出さず、通常のテキストにツール呼び出しを書いたり、内部XMLタグを露出したりする場合があるとも警告しています。可能な限りThinkingを有効に保ち、支出はEffortで制御します。

長時間のコーディングまたはエージェントタスクには、次のPythonリクエストが有効です。

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=64000,
    output_config={"effort": "xhigh"},
    messages=[
        {
            "role": "user",
            "content": (
                "Review this repository migration plan. Identify unsafe "
                "assumptions, propose the smallest sound change, and verify "
                "the final plan against the stated acceptance criteria."
            ),
        }
    ],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

64,000トークンという上限は、xhighまたはmaxで使うAnthropic推奨の開始値であり、すべてのリクエストに必須ではありません。実際の使用量と完了時の挙動を観測してから引き下げます。

質的な違いも見込んでおく必要があります。Anthropicによれば、Opus 5は長い成果物を書き、エージェントセッション中に進捗を詳しく説明し、サブエージェントへ積極的に委任し、別途指示されなくても作業を検証する傾向があります。これらは有用ですが、静かに動くOpus 4.8を前提に設計したエージェントUI、ログ処理基盤、オーケストレーション層は調整が必要になる場合があります。

本番料金を左右する3つの要素

Effort、キャッシュ、速度は互いに影響します。1つだけを最適化すると、残り2つが悪化する可能性があります。

キャッシュを使う会話ではEffortを固定する

リクエスト間でoutput_config.effortを変えると、Anthropicがレンダリングするプロンプトも変わるため、後続リクエストはキャッシュ済みのプレフィックスを維持できません。長い会話の途中でEffortを上下させるシステムでは、見込んでいたキャッシュ削減効果を失う可能性があります。

キャッシュに依存するセッションは、開始時にEffortを1つ選び、そのまま維持します。後の作業に異なるEffortが必要なら、新しい会話へルーティングするか、エスカレーション費用としてキャッシュミスを受け入れます。

Opus 5では、キャッシュ可能な最小プロンプトがOpus 4.8の1,024トークンから512トークンへ下がりました。より短い反復指示でもキャッシュを使えるようになりますが、プロンプトのプレフィックスとEffortが安定していることが条件です。

Fast modeは能力ではなくレイテンシのために買う

Fast modeは通常の約2.5倍の速度で、100万トークンあたり$10/$50です。OpusがFableに変わる機能ではありません。100件の固定ワークロードでは、キャッシュや再試行を考慮する前の段階で、Opusの合計額が$22.50から$45へ上がります。

Fast modeはClaude APIのリサーチプレビューです。現時点ではAmazon Bedrock、Google Cloud、Microsoft Foundryで利用できません。マルチクラウド構成では、速度設定がどの環境でもモデルについてくるとは想定できません。

新しいベータ機能はベータとして扱う

会話途中のツール変更を使うと、プロンプトキャッシュを保ったまま、ターンの間でツールを追加または削除できます。この機能ではmid-conversation-tool-changes-2026-07-01ベータヘッダーを使います。

自動フォールバックでは、分類器がフラグを付けたOpus 5またはFable 5のリクエストをブロックせず、Anthropic推奨のフォールバックへ送れます。デフォルトおよび明示的なフォールバック一覧では、server-side-fallback-2026-07-01ベータヘッダーを使います。

どちらも運用上の問題を解消する機能です。同時に、1つの論理セッションで実行できる操作や、回答するモデルを変える可能性があります。取り消せないワークフローで有効にする前に、権限変更、障害処理、出力品質をテストしてください。

本番導入前に5段階のEffortを比較する方法

375回の評価を行えば、Effort設定を感覚ではなくルーティングデータとして扱えます。代表的な25タスクを5つのEffortで、それぞれ3回ずつ実行します。

同じ条件を繰り返すのは、エージェントが偶然1回だけ合格し、次のツール経路では失敗することがあるためです。タスクセットでは、数より内容が重要です。日常業務、既知のエッジケース、過去に人の修正が必要だった失敗を含めます。

本番環境でプロンプトキャッシュを使うなら、このテストでもセッション途中にEffortを変えてはいけません。各レベルを安定した会話設計で試さないと、キャッシュミスという制御されていない変数が混ざります。

たとえば、通常のアカウント業務はmediumで合格し、例外処理にはhighが必要で、限定的なデバッグ分類だけxhighで改善するという結果が得られるかもしれません。これは、すべてをxhighにする根拠ではありません。経済性の異なる3つの経路を作る根拠です。

同じ手順で、Fable 5が価格に見合うかも判断できます。Opusで基準を下回ったタスクだけにFableを追加します。100件の例でFableの合格率改善が$22.50の上乗せ分を賄えないなら、Opusを維持します。

セキュリティ上の境界はFable 5と異なります

Opus 5は正当なセキュリティ業務に対してFable 5ほど制限が強くありませんが、無制限のサイバーモデルではありません。

Anthropicによれば、Opus 5のサイバー分類器が介入する頻度は、Fable 5より約85%低くなる見込みです。ソースコードから脆弱性を発見できる一方、安全対策によってバイナリを使った脆弱性スキャン、ペネトレーションテスト、エクスプロイト生成はブロックされます。また、攻撃的サイバーセキュリティと生物学研究では、引き続きMythos 5に及びません。

この境界は、デバッグやセキュリティのエージェントに影響します。ソースレビューには対応できても、その後のエクスプロイト検証は拒否されたり、別の経路へ送られたりする可能性があります。拒否を想定外のパーサー障害にせず、処理済みの状態として扱えるワークフローを設計します。

Cyber Verification Programでは、条件を満たす企業や研究者が、セキュリティ制限を緩和したバージョンへアクセスできます。一般ユーザーは、アクセスが確認できるまで、この経路を前提に本番ワークフローを設計すべきではありません。

Anthropicの内部行動監査では、Opus 5の総合的な不整合行動スコアは2.3で、最近のモデルの中では最も低い値です。これはAnthropic独自のテスト群に関する証拠であり、承認、サンドボックス、最小権限のツールアクセスを外してよいという意味ではありません。

結論

Claude Opus 5は、新しいプレミアムワークロードではOpus 4.8に代わる選択肢であり、既存用途の多くも段階的な移行後に置き換えるべきです。価格は同じで、Effortに応じて能力をより安定して引き出せるうえ、重要な複数の評価でFable 5に迫っています。

一方、高処理量のすべての経路でSonnet 5を置き換えるべきではなく、maxをデフォルトにする理由もありません。経済性を生むのはルーティングです。安価に合格できる仕事はSonnetまたは低いEffort、日常的な難しい仕事はOpusのhigh、計測済みの長時間タスクはxhigh、FableはOpusの失敗が高くつくと証明された場合だけに使います。

Effort設定の価値は、この方針を明示できることにあります。評価変数として使い、キャッシュが重要な場面では固定し、すべてのエスカレーションを具体的な失敗と結び付けてください。

次のモデル変更も本番運用の判断へ落とし込みたい方は、ニュースレターにご登録ください。