メインコンテンツまでスキップ

Claude Opus 5：Claude Code チームが求めていた日常使いの frontier モデル

· 約13分
Claude Dev
Claude Dev
Claude Dev

Anthropic は 2026 年 7 月 24 日に Claude Opus 5 を公開しました。Claude 5 ファミリーの中で、日常的に使える frontier モデルという位置づけです。Claude Fable 5 の frontier 知能に近づきながら、価格は Opus 4.8 と同じ 入力 100 万 token あたり 5 ドル、出力 100 万 token あたり 25 ドルに据え置かれています。

この価格こそが今回の本題です。

Fable 5 は、最も難しく、長く、自律性の高い仕事のためのモデルであり続けます。Sonnet 5 は、多くのチームが広く使えるデフォルトの agent モデルです。Opus 5 はその中間にあります。真剣なエンジニアリング作業に十分強く、日常の workflow では Fable より制約が少なく、まれな escalation だけでなく繰り返し使える価格です。

初期のコミュニティ反応は前向きですが、まだ定まっていません。X では medium effort の品質と token 効率への期待が目立ちます。Reddit と Hacker News はより慎重で、usage limit、モデル churn、safety fallback、そして新しい Opus が複雑な coding session で本当に体感改善するのかを気にしています。その懐疑は健全です。

Anthropic が出したもの​

Claude Opus 5 は、Opus 4.8 に代わる Anthropic の最強の汎用 Opus モデルです。公式 docs では、Opus 4.8 からの段階的な飛躍として説明されており、深い reasoning、agentic coding、長期タスク、test-time compute scaling、code review、vision、long context、office work、multi-agent coordination で大きな改善があるとされています。

運用上の詳細は重要です。

  • Model ID：claude-opus-5
  • Context window：デフォルトおよび最大 1M tokens
  • Max output：128k tokens
  • 価格：入力 100 万 token あたり 5 ドル、出力 100 万 token あたり 25 ドル
  • 提供範囲：Claude API、Claude.ai plans、Claude Code、Amazon Bedrock、Google Cloud、Microsoft Foundry
  • Fast mode：Claude API で利用可能、入力 10 ドル、出力 50 ドル / 100 万 token
  • Prompt cache minimum：Opus 4.8 の 1,024 tokens から 512 tokens に低下
  • Thinking：デフォルトで有効
  • Effort ladder：low、medium、high、xhigh、max

移行は model ID の置き換えだけではありません。Opus 4.8 では adaptive thinking を明示しない限り thinking なしで動きました。Opus 5 では thinking がデフォルトで有効になり、effort が深さ、レイテンシ、コストを制御する主なノブになります。

実際の breaking change もあります。thinking を無効にする場合、effort は high 以下でなければなりません。thinking: {"type": "disabled"} と xhigh または max を組み合わせると 400 が返ります。

Claude Code ユーザーにとっての読み方は単純です。Opus 5 はデフォルトでより考え、より行動しようとします。それは良いことです。ただし prompt にまだ "double check everything" や "always use a verifier agent" のような古い足場が残っていると、予算を燃やす原因にもなります。

コミュニティの読み方：期待と警戒​

ローンチ日のシグナルは活発ですが、まだばらつきがあります。

X では、最も強い好意的反応は medium effort と 効率に集中しています。Techmeme は、Opus 5 が特に medium effort で印象的だという早期投稿を拾いつつ、実際のツールで壊れた workflow や混在した第一印象も記録しています。

Reddit のトーンはより実務的です。Claude 関連コミュニティは leaderboard の勝利より、次の点を気にしています。

  • Opus 5 が Claude Pro と Max の limits を速く消費しすぎないか;
  • Claude Code で Opus 4.8 より明確に良いのか;
  • Fable 5 はまだ支払う価値があるのか;
  • safety fallback が通常の security や research 作業を妨げないか;
  • Anthropic がチームの評価速度を超えてモデルを出していないか。

Hacker News も同じ傾向です。より強い日常モデルを求める人がいる一方で、model churn に疲れ、実際の coding session で regression を減らしてほしいという声もあります。有用な HN 的批判は「benchmark は偽物」ではありません。有料のエンジニアリング作業で重要なのは、モデルが混乱した数時間のタスクを終わらせ、高価な review debt を作らないかどうかです。

これが Opus 5 を評価する正しい枠組みです。チャットで賢く聞こえるかではなく、失敗する agent loop、誤った code review コメント、部分的な実装、不要な token burn を減らすかで見るべきです。

Opus 5 が Opus 4.8 より重要な理由​

Opus 4.8 はすでに強力でした。Opus 5 が重要なのは、Anthropic が Opus 層をより運用しやすくしているからです。

新しい docs は低い effort 設定を強調しています。low と medium は簡単な prompt のための安いモードだけではありません。Anthropic は、high effort の一部の token とレイテンシで強い品質を保つと述べています。これが実際の Claude Code workload でも成り立つなら、Opus 5 は「詰まったときだけ使う」モデルではなく、日常的な routing layer になります。

Claude stack の考え方はこう変わります。

  • Sonnet 5：日常の実装、小さな refactor、広い automation。
  • Opus 5 medium/high：複雑な edits、code review、debugging、より信頼度の高い agent loop。
  • Opus 5 xhigh/max：難しい architecture、深い調査、大規模 migration。
  • Fable 5：コストと retention 制約を受け入れられる、最も難しい長時間自律作業。

これは、1 つのデフォルトモデルと 1 つの高価なモデルだけより良い形です。Claude Code チームは同じモデルファミリー内で本物の cost-performance ladder を持てます。

隠れた移行リスク：過剰検証​

最も重要な prompting の変化は見落としやすいです。

Anthropic は、Opus 5 が以前の Opus モデルより自分の作業を積極的に検証すると説明しています。これは純粋な改善に見えますが、すでに検証ステップを強制する agent harness では移行リスクになります。

もし Claude Code wrapper が次のように指示しているなら：

  • 常に final verification pass を実行する;
  • verifier subagent を起動する;
  • すべての結論を二重確認する;
  • すべての修正を説明する;
  • 変更全体を再 review するまで終了しない;

Opus 5 はそれらの指示を自分の挙動と重ねる可能性があります。結果は、遅い作業、増える tool calls、増える narration、そして shipping ではなく checking に使われる token です。

より良いパターンは条件付き検証です。

  • ファイルが変わったときに検証する;
  • コマンドが結果を直接証明するときに検証する;
  • subagent は独立した並列作業だけに使う;
  • 小さなタスクに第二の checker を求めない;
  • harness で tool use と subagent 数を制限する。

Opus 5 は検証の必要性をなくしません。検証の置き場所を、曖昧な prompt 儀式ではなく明示的な engineering gate に移すべきだということです。

Safety と Fallback：Fable より摩擦は少ないが、不可視ではない​

Opus 5 は、Anthropic の高能力モデルにとって騒がしい 1 か月の後に登場しました。Fable 5 と Mythos 5 は access restriction、cyber safeguard、fallback 挙動への不満に直面しました。Opus 5 はその product gap への回答でもあります。

Reuters は、Anthropic が価値重視なら Opus 5 を選び、数日続く自律プロジェクトには Fable 5 を残すという見方を報じました。The Verge なども、Opus 5 は cybersecurity 文脈で Fable 5 より制限が少ない一方、safeguard は残ると報じています。

新しい API fallback mode はここで重要です。開発者は "default" fallbacks を選べます。これにより、安全分類器に flag された request を Anthropic が推奨 fallback model に route でき、各 app が独自 fallback list を維持する必要が減ります。

便利ですが、チームは設計が必要です。

  • refusal を含む stop_reason を確認する;
  • 利用可能なら stop_details を記録する;
  • fallback が起きたときユーザーに伝える;
  • Opus 5 と fallback response の品質差を測る;
  • すべての HTTP 200 が要求したモデルの回答だと仮定しない。

これは Claude Code、security review、research workflow で特に重要です。Fallback は hard block より良い場合がありますが、それでも model-routing event です。

Claude Code チームが最初に試すべきこと​

汎用 benchmark prompt から始めないでください。本当に痛い仕事から始めてください。

有用な Opus 5 eval には次を含めるべきです。

  1. 複数ファイルの bug fix

実際の failing test または production trace を渡します。無関係な code を書き換えずに正しい root cause を見つけるかを測ります。

  1. Code review pass

すべての actionable issue を求め、その後 severity を filter します。Anthropic の prompting docs は、保守的にさせすぎると Opus 5 が under-report する可能性を指摘しています。

  1. Medium-effort の implementation task

medium、high、xhigh で実行します。完了品質、token 使用量、command 数、review effort を比較します。

  1. Long-context repo task

大きな codebase や長い design history を使います。context の深い位置でも instruction following が安定するか見ます。

  1. Tool-heavy agent loop

過剰に説明するか、過剰に委任するか、過剰に検証するかを確認します。チーム全体の default を変える前に harness を調整してください。

指標は accepted change あたりのコストであるべきです。100 万 token あたりのコストではありません。Opus 5 は call あたり高くても、turn が少なく、実 bug を早く見つけ、rework を避けるなら shipped feature あたりでは安くなります。

実用的な移行チェックリスト​

Opus 4.8 から移行するチーム向け：

1. Model ID を更新する​

テスト workload を：

claude-opus-4-8

から：

claude-opus-5

へ移します。

eval が通るまで、Opus 4.8 は routing table に残してください。

2. max_tokens を見直す​

Thinking はデフォルトで有効で、max_tokens は thinking と visible output の両方を含みます。Opus 4.8 integration で tight limit を使っていた場合、Opus 5 は想定より早く truncate する可能性があります。

3. Effort levels を試す​

xhigh が正しい default だと決めつけないでください。実タスクで medium、high、xhigh を試します。max は追加 reasoning budget に見合うタスクだけに使ってください。

4. 古い verification boilerplate を削る​

包括的な self-review や subagent verification を強制する prompt instruction を削除します。変更ファイル、tests、risk level に紐づく正確な gate に置き換えてください。

5. 使える場所で prompt caching を有効にする​

512-token の cache minimum により、短めの安定した system prompt も cache 可能になります。繰り返し prefix を持つ tool では小さいが意味のあるコストレバーです。

6. Fallback を観測可能なイベントとして扱う​

server-side fallback を使うなら記録してください。ユーザーの信頼は、裏側でモデルが変わったことを把握できるかに依存します。

結論​

Claude Opus 5 は単なる「安い Fable 5」ではありません。その捉え方は単純すぎます。

これは Anthropic が frontier-level agentic work をより運用可能にしようとする試みです。真剣な coding に十分強く、Fable より安く、より多くの platform で使え、固定の知能設定ではなく effort によって調整できます。

コミュニティの反応が混在しているのは正しいです。開発者が期待するのは、Opus 5 が日常の Claude Code 作業の上限を引き上げるかもしれないからです。一方で usage limits、safety fallbacks、verbosity、subagent spawning、model churn は本物の workflow cost です。

正しい行動は、すべての難しいタスクを盲目的に Opus 5 に切り替えることではありません。意図して route してください。

  • Sonnet 5 は日常実行;
  • Opus 5 medium/high は日常の難しい仕事;
  • Opus 5 xhigh/max は本格的な調査;
  • Fable 5 は最大自律性が必要で制約に見合う稀な仕事。

Opus 5 が Anthropic docs と初期反応の示す通りに実 repo で機能するなら、Claude Code チームの新しい標準 escalation model になります。ただし最も恩恵を受けるのは、effort を調整し、古い prompt baggage を取り除き、launch-day vibes ではなく accepted work を測るチームです。

参照ソース​