まず結論：Opus 5は「値段を上げずに中身だけ強くなった」モデル

Claude Opus 5は、Anthropicが2026年7月24日に公開した最新のOpusシリーズです。ポイントを3行にまとめると次のようになります。

• 価格は前世代Opus 4.8と完全に同じ（入力 $5 / 出力 $25 per 1Mトークン）。値上げなしで性能だけ上がっています
• いくつかのベンチマークでは上位モデルのFable 5を上回る。Fable 5は $10 / $50 なので、単価は半額です
• ただし全勝ではありません。エージェント型コーディングの一部ではGPT-5.6 SolやFable 5に負けているスコアも公開されています

Anthropicの立ち位置としては、Fable 5が「最高性能だが高い」、Opus 5が「実務のメイン機」、Sonnet 5が「速度とコストのバランス」という三層構造になりました。Claudeの有料プランでは、Opus 5がMaxプランの新しいデフォルトモデルになり、Proプランで使える最上位モデルにもなっています。

スペックと価格：Claude 4モデルを横並びで比較

まず基本仕様です。すべてAnthropic公式ドキュメントの記載値です。

注目したいのは知識のカットオフが2026年5月と、現行のClaudeモデルで最も新しい点です。Fable 5でも2026年1月なので、直近半年の情報を扱う用途ではOpus 5のほうが素の知識が新しいことになります。

キャッシュとFast Modeの料金

プロンプトキャッシュを使う場合の単価も押さえておきます。Opus 5では以下のとおりです。

• キャッシュ書き込み（5分TTL）: $6.25 / 1Mトークン
• キャッシュ読み込み: $0.50 / 1Mトークン（通常入力の10分の1）

加えて、Opus 5では出力速度を最大2.5倍にするFast Modeが使えます。ただし料金は $10 / $50 とFable 5と同水準まで上がるので、「速さにいくら払うか」の判断が必要です。Fast ModeはClaude API（およびManaged Agents）専用で、Amazon Bedrock・Google Cloud・Microsoft Foundry経由では使えません。

ベンチマーク比較：Fable 5・GPT-5.6 Solとどこで勝ち、どこで負けるか

ここが本題です。Anthropicが公開したスコアを、他社モデルを含めて並べます。

Frontier-Bench v0.1（ターミナル操作型のエージェントコーディング）

Opus 5が最も強みを主張しているのがこの領域です。ターミナルを叩きながら長時間自律で作業するタイプのタスクで、上位のFable 5より約10ポイント高く、しかも単価は半額。実務で「エージェントに任せて放置する」使い方をしている人には、ここが一番効いてくる差になります。

ARC-AGI-3（未知のパターンへの対応力）

ARC-AGIは「学習データに答えが載っていない新しい形の問題」を解かせるベンチマークです。ここでOpus 5は次点の約4倍というスコアを出しています。ただし絶対値は30.2%であり、7割は解けていないことも同時に押さえておくべきです。「未知のパターンに強くなった」とは言えますが、「解決した」わけではありません。

GDPval-AA v2（ナレッジワークの評価・Eloスコア）

資料作成・調査・分析といった「コーディング以外のホワイトカラー業務」を評価するベンチマークです。ここでもOpus 5が首位ですが、Fable 5とGPT-5.6 Solの差は11ポイントしかなく、この2つは実質互角と見るべきです。

DeepSWE v1.1：ここではOpus 5が負けている

正直に書いておくと、すべてのベンチマークでOpus 5が勝っているわけではありません。エージェント型コーディングのDeepSWE v1.1では、GPT-5.6 Solが約4ポイント上回っています。Fable 5にもわずかに負けています。

つまり「コーディングならOpus 5が最強」と単純に言い切れる状況ではなく、タスクの型によって順位が入れ替わるのが2026年7月時点の実態です。ターミナル操作を伴う長時間の自律作業ならOpus 5、リポジトリ内のバグ修正パッチ生成のような課題ならGPT-5.6 Solも十分候補になります。

その他Anthropicが公開している主張

• CursorBench 3.2（max effort時）: Fable 5の最高スコアとの差が0.5%以内。単価は半分
• OSWorld 2.0（PC操作の自動化）: Fable 5のスコアを、約3分の1のコストで上回る
• Zapier AutomationBench: 同コスト帯の他モデル比で約1.5倍のパス率
• 有機化学タスク: Opus 4.8比で10.2ポイント向上
• タンパク質配列解析: Opus 4.8比で7.7ポイント向上

ライフサイエンス系の伸びが目立ちますが、これらは具体的な比較対象モデルのスコアが併記されていないため、「Opus 4.8からどれだけ伸びたか」以上のことは読み取れません。

Gemini勢との比較は現時点では難しい

Googleの最上位モデルであるGemini 3.5 Proは2026年7月25日時点で未リリースで、Gemini 3.5世代はFlash系とLive Translateのみが出ている状態です。現行のGemini 3.1 ProはSWE-bench Verifiedで80.6%と、Opus 4.8（88.6%）にも届いていません。Gemini側はFlash系の安さと速さで別の土俵に立っているため、Opus 5と正面から比較できる状態にはありません。

Opus 4.8から変わったAPI仕様：破壊的変更は2つ

ここからは開発者向けの話です。モデルIDを差し替えるだけでは動かなくなるケースがあるので、移行前に確認してください。

変更1：thinkingがデフォルトONになった

Opus 4.8では thinking パラメータを省略すると思考なしで動きました。Opus 5では省略すると思考ありで動きます。挙動だけでなくコストにも影響します。

重要なのは、max_tokens が「思考トークン＋回答テキスト」の合計に対する上限だという点です。Opus 4.8で思考なし前提に max_tokens をギリギリまで絞っていた場合、Opus 5に切り替えると回答が途中で切れる可能性があります。

# Opus 4.8：thinking省略＝思考なし
response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=2000,          # 回答テキストだけで2000
    messages=[...],
)

# Opus 5：同じコードだと思考が入り、2000を食い合う
# → max_tokensを増やすか、明示的に無効化する
response = client.messages.create(
    model="claude-opus-5",
    max_tokens=8000,          # 思考ぶんの余裕を持たせる
    messages=[...],
)

変更2：思考の無効化はeffort「high以下」でしか使えない

thinking: {"type": "disabled"} と effort の xhigh / max を組み合わせると、400エラーになります。Opus 4.8ではこの組み合わせが通っていたので、そのまま移行すると落ちます。

# Opus 5では400エラー
response = client.messages.create(
    model="claude-opus-5",
    max_tokens=4096,
    thinking={"type": "disabled"},
    output_config={"effort": "xhigh"},   # ← disabled と両立しない
    messages=[...],
)

この検証はリクエストごとに行われます。会話の途中で effort だけを xhigh に上げると、そのリクエストから急にエラーになる点に注意してください。

思考オフ運用で起きる2つの落とし穴

どうしても thinking: {"type": "disabled"} を使う場合、Opus 5には既知の2つの挙動があります。どちらも「思考をONに戻してeffortを下げる」のが公式の第一推奨ですが、それができない場合の対処も公開されています。

1. ツール呼び出しが本文テキストとして出力されることがある。構造化された tool_use ブロックではなく、ユーザー向けの文章の中にツール呼び出しが書かれてしまう現象です。エラーは出ず、ターンは正常終了し、ツールは実行されません。エージェントループでは、その残骸が会話履歴に残って後続のターンにも影響します。検索系などツールを多用する処理で起きやすい挙動です。
   対処：システムプロンプトに「ツールを使う前に短く一言述べてよい」という許可を追加します。前置きを抑制しようとするほど発生しやすいためです。
2. <thinking> タグが本文に漏れることがある。
   対処：ここは直感に反します。「考えるな」「推論するな」という指示があるとむしろ漏れが増えるため、そういうルールは削除します。そのうえで「内部タグやシステムタグを応答に含めないでください」という一般的な書き方にします。「thinkingタグを出すな」とタグ名を名指しする書き方は効果が落ちます。

変わっていない仕様

Opus 4.7以降の制限はそのまま引き継がれています。Opus 4.6以前から移行する場合は、これらも同時に対応が必要です。

• thinking: {"type": "enabled", "budget_tokens": N} は400エラー。effort で制御する
• temperature / top_p / top_k は400エラー。プロンプトで制御する
• 最後のassistantターンによるプレフィル（prefill）は400エラー。output_config.format（構造化出力）を使う

地味に効く改善：プロンプトキャッシュの下限が512トークンに

キャッシュが成立する最小プレフィックスが、Opus 4.8の1,024トークンからOpus 5では512トークンに下がりました。「短すぎてキャッシュが効かない」と諦めていたシステムプロンプトが、コード変更なしでキャッシュ対象になる可能性があります。

効いているかは usage.cache_read_input_tokens で確認できます。同じプレフィックスのリクエストを繰り返しているのにこの値が0のままなら、システムプロンプトに現在時刻やUUIDなど毎回変わる値が混ざっていないか確認してください。

effortの選び方：Opus 5では「下げる」のが正解になりやすい

Opus 5は low / medium の性能が従来のOpusより明確に上がっています。Anthropicは公式に「トークンコストと応答時間の主要な制御手段として積極的に使ってよい」と書いています。

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=4096,
    output_config={"effort": "medium"},
    messages=[{"role": "user", "content": "..."}],
)

もうひとつ重要な注意点として、effortを下げても回答が短くなるとは限りません。effortが制御するのは「思考量」であって「見える回答の長さ」ではないためです。回答を短くしたいならプロンプトで指示する必要があります（次章）。

なお、effortを会話の途中で変えるとプロンプトキャッシュが無効化されます。キャッシュ前提の長いセッションでは、最初に決めた値を維持してください。

移行時に「消すべき」プロンプト：Opus 5で逆効果になる4パターン

ここがOpus 5移行で一番見落とされやすいところです。従来のモデル向けにチューニングしたプロンプトの一部が、Opus 5では逆効果になります。

1. 検証指示は削除する（追加ではなく削除）

Opus 5は指示しなくても自分の作業を検証します。そこに「非自明なタスクでは必ず最終検証ステップを入れること」「サブエージェントで検証させること」といった指示が残っていると、検証が二重に走って無駄なトークンを消費します。

Anthropicは「これらの指示を削除すると、品質を落とさずに過剰検証が減る」と明言しています。プロンプトレベルの「もう一度確認して」「回答前に再検証して」といった文言も同様です。ハーネス側に別途組んだ検証ステップも、旧モデル向けの遺物なら見直し対象です。

2. 回答が長い問題は、effortではなくプロンプトで直す

Opus 5のデフォルト応答は従来のOpusより長めです。前述のとおりeffortを下げても確実には短くならないので、明示的に指示します。公式が例示している文面はこちらです。

回答は焦点を絞り、簡潔にしてください。免責事項や注意書きは短くし、
大部分を本題の回答に使ってください。説明を求められた場合は、
詳細な説明が明示的に要求されない限り、要点レベルの要約を返してください。

システムプロンプトが長い場合は、末尾に短いリマインダーを併記すると効きやすくなります。

<tone_preference>
出力は適度に簡潔に保つこと。
</tone_preference>

会話の長さとは別に、Opus 5がファイルとして書き出すドキュメント（レポート・Markdown・サマリ）も従来より長くなる傾向があります。成果物の長さが問題になる場合は「必要な内容は網羅しつつ、埋め草のセクションや重複した要約、定型文で水増ししないこと」といった指示を別途入れます。

3. タスクのスコープを明示的に縛る

Opus 5は頼まれていない工程を足したり、「本来こうあるべき」という自分の判断でタスクを拡張することがあります。狭い範囲の作業をさせたいときは明示します。

依頼された範囲の依頼された内容だけを納品してください。
細かな判断は自分で行い、解釈によって成果物が大きく変わる場合のみ確認してください。
依頼が誤っていると考える場合や、より良い方法がある場合は一文で指摘したうえで、
依頼どおりに進めてください。勝手に範囲を狭めたり広げたり変質させたりしないこと。
タスクは最後まで完了させ、明らかに依頼範囲を超える操作は行わないでください。

4. サブエージェントの起動に上限をかける

ここは前世代と逆方向の調整が必要です。Opus 4.8はサブエージェントを使いたがらない傾向があり、「もっと委譲しろ」という指示を足していた人が多いはずです。Opus 5は逆に積極的に委譲します。小さなタスクにまでサブエージェントを立てると、コストと時間が跳ね上がります。

Opus 4.8向けに「もっと委譲しろ」と書いていたなら、その指示は削除してください。そのうえで上限を設けます。

サブエージェントへの委譲は、大規模で本当に独立・並列化可能な作業
（広範な複数ファイル調査など）に限定してください。
数回のツール呼び出しで自分で終わる作業を委譲しないでください。
また、自分の作業の検証やダブルチェックにサブエージェントを使わないでください。
1体で完了できるなら複数立てず、起動数は少なく保ってください。

おまけ：自己訂正のナレーションが多い

Opus 5は自分の以前の発言の訂正を、従来より詳しく説明します。ユーザー向けのプロダクトではノイズになるため、訂正の範囲を絞る指示が有効です。

以前の発言を訂正するのは、その誤りがユーザーのコードや結論、判断を
変えてしまう場合だけにしてください。訂正は簡潔に述べてすぐ作業に戻り、
ユーザーにとって何も変わらない些細な訂正は、黙って直して先に進んでください。

コードレビュー用途での注意

Opus 5はバグ検出の精度・再現率ともに高いのですが、レビュープロンプトに「重大度の高い問題だけ報告して」「保守的に判断して」と書いてあると、その指示を忠実に守って報告数が減ります。結果として、内部的にはバグを見つけているのに測定上のリコールが下がる、という現象が起きます。

対策は「まず全部報告させて、フィルタは別工程でやる」ことです。各指摘に確信度と重大度を添えさせておけば、後段でランク付けできます。

結局どのモデルを使えばいいのか

Claude Codeを使っている場合は、Maxプランならデフォルトがすでに Opus 5 になっています。Proプランでも選択できる最上位がOpus 5です。effortの切り替え方は別記事で解説しています。

よくある質問

まとめ

今日やれる最初の一歩は、自分のコードで thinking と effort の組み合わせを検索することです。thinking={"type": "disabled"} と effort の xhigh / max が同居している箇所があれば、そこがOpus 5移行で最初に落ちるポイントになります。次に、システムプロンプトから「検証してください」系の指示を探して削除してみてください。トークン消費が目に見えて減るはずです。