Article Brief

#Anthropic Akira 公開: 更新: 9分で読める

Claude Opus 5 API、移行前に見る実装差分

Claude Opus 5 API、移行前に見る実装差分
目次

Anthropic は 2026年7月24日、Claude Opus 5 を公開した。Claude Platform Docs では API model ID は claude-opus-5 とされ、複雑な agentic coding と enterprise work 向けのモデルとして説明されている。1M token context window、128k max output tokens、thinking の既定オン、Fast mode、fallback の更新が同時に入っているため、これは単なる「新しい最上位モデル」ではなく、API 運用の前提をいくつか変える更新である。

すでにこのサイトでは、流通面の更新として Copilot Claude Opus 5AI GatewayでClaude Opus 5運用 を扱った。今回見るのは、Anthropic 直結 API と Claude Platform 側の移行差分である。既存の Claude Sonnet 5の価格と移行設計Claude Opus 4.8の動的ワークフロー を評価している日本の開発組織ほど、Opus 5 を「どの用途へ入れるか」だけでなく「どの設定を変えるか」まで確認したほうがよい。

事実: モデルIDと提供経路をまず分ける

Claude Platform Docs の Opus 5 ページでは、API model ID は claude-opus-5 と案内されている。説明上の主用途は、複雑なエージェント型コーディングと企業向け作業である。発表文では、長時間エージェント、コーディング、専門業務の改善が強調され、Opus 4.8 と同じ価格帯で性能を上げる位置づけになっている。

日本企業が最初に分けるべきなのは、Anthropic 直結 API、Claude Code、Claude のアプリ内利用、Amazon Bedrock、Google Cloud、Microsoft Foundry、さらに Vercel AI Gateway や自社 LLM gateway 経由の利用である。同じ Opus 5 という名前でも、モデル ID、請求元、ログ、データ処理地域、fallback の設定場所、Fast mode の有無が一致するとは限らない。

特に Fast mode は注意が必要だ。Docs では、Claude Opus 5 の Fast mode は research preview として Claude API のみで利用可能で、Amazon Bedrock、Google Cloud、Microsoft Foundry では現時点で利用できないと説明されている。つまり、API 直結で速度検証した結果を、そのままクラウド marketplace 経由の本番設計へ移せるとは限らない。

事実: 価格はモデル単価ではなくジョブ単価で見る

Anthropic の価格ページと Opus 5 の資料では、標準の Opus 5 は入力100万トークンあたり5ドル、出力100万トークンあたり25ドルの価格帯として扱われている。Fast mode は入力100万トークンあたり10ドル、出力100万トークンあたり50ドルで、標準より高い。これは「速いから安い」ではなく、速度にプレミアムを払う設計である。

ここで実務上の焦点は、単価表より 1 ジョブあたりの総額である。Opus 5 は thinking が既定でオンになり、max_tokens は thinking と最終応答を合わせた出力上限になる。以前 Opus 4.8 で thinking を明示せずに動かしていた処理は、同じ max_tokens でも出力の使い方が変わる可能性がある。API の単価が同じでも、thinking、tool use、再試行、長い context、cache hit 率で請求は変わる。

Claude Opus 4.6 fast mode削除 で見たように、Anthropic 系モデルの移行では速度指定と課金の挙動がモデルごとに違う。Opus 5 でも、Fast mode を使う workload、標準速度でよい workload、Sonnet 5 へ落とせる workload を分けて計測する必要がある。

事実: thinking既定オンとeffort制御をテスト対象にする

Claude Opus 5 の Docs は、Opus 4.8 では明示しない限り thinking なしで動いていた一方、Opus 5 では同じリクエストが thinking オンで動くと説明している。thinking: {"type": "adaptive"} は引き続き有効で、既定と同等とされる。さらに thinking depth の制御には effort parameter を使う。

これは品質改善の話であると同時に、テスト観点の変更でもある。評価では、lowmediumhighxhigh のような effort 設定ごとに、完了率、応答時間、出力トークン、レビュー差し戻し率を見たい。低 effort で十分な業務と、高 effort でなければ失敗する業務を分けられれば、全リクエストを最上位設定で走らせる必要はない。

日本の開発組織では、Claude Code や社内 AI 開発支援で「難しいタスクだけ強いモデルに上げる」運用が現実的だ。たとえば小さな説明、定型変換、軽い要約は Sonnet 5 や低 effort で処理し、大きなリポジトリ調査、複数ファイル修正、障害原因の深掘り、仕様不明の migration は Opus 5 へ振る。ここを gateway 側で自動化するなら、モデル名だけでなく effort と上限トークンを設定として管理する必要がある。

実装論点: fallbackとtool変更は便利機能ではなく運用面で見る

Opus 5 の Docs には、mid-conversation tool changes と default fallbacks mode も並んでいる。前者は会話途中で tool を追加・削除しながら prompt cache を維持するための beta 機能で、後者は Anthropic 推奨の fallback model を refusal category ごとに適用する beta 機能である。

これらは一見すると開発者体験の改善だが、企業運用では統制機能として読むべきである。tool list を途中で変えられるなら、会話全体の権限境界がどの時点でどう変わったかをログに残す必要がある。fallback を provider 側の default に任せるなら、どの拒否カテゴリでどのモデルへ落ちたのか、コストと品質の差をどう検証するのかを決める必要がある。

特に日本企業では、金融、医療、製造、公共、委託開発のように、入力データや成果物の監査要求が強い現場が多い。fallback が成功率を上げても、モデルが変わったことを後から説明できない設計では本番に入れにくい。Opus 5 の採用時には、request ID、model ID、effort、thinking の有無、fallback 発生、tool list の変更、cache hit をメタデータとして保存する設計にしておきたい。

日本企業の導入順

第一に、既存の Opus 4.8、Opus 4.7、Sonnet 5、Claude Code の利用場所を棚卸しする。モデル名を直接書いているコード、社内 wrapper の alias、IaC、評価スクリプト、プロンプトテンプレート、管理画面の選択肢を確認する。

第二に、Opus 5 を一括置換しない。評価用の代表タスクを作り、標準、Fast mode、effort 別、Sonnet 5 との比較を同じ入力で測る。見るべき指標は、単発の回答品質だけではない。完了率、実行時間、出力トークン、tool call 数、再試行、レビュー差し戻し、失敗時の復旧性まで含める。

第三に、クラウド経路を決める。Anthropic 直結 API は機能更新が早い。一方、AWS、Google Cloud、Microsoft Foundry、AI Gateway では請求、ID、リージョン、監査、契約が既存のクラウド運用へ寄せやすい。Fast mode や beta 機能の利用可否が違うため、PoC と本番の経路を分ける場合は、差分を明文化する。

第四に、社内標準モデルの更新は利用者通知とセットにする。Opus 5 は高性能だが、thinking 既定オンや Fast mode の価格差を知らないまま使わせると、予算と期待値がずれる。開発者向けには、どの作業で Opus 5 を選ぶか、どの作業は Sonnet 5 でよいか、Fast mode は誰が使えるかを短く示すほうがよい。

まとめ

Claude Opus 5 API は、最上位モデルの更新であると同時に、thinking、effort、Fast mode、fallback、tool change、クラウド提供経路をまとめて見直す契機である。日本企業が見るべきなのは、ベンチマークの順位だけではない。自社の開発基盤、LLM gateway、予算監視、監査ログ、Claude Code の標準運用にどう入れるかである。

Opus 5 をすぐ全社標準にする必要はない。まずは長時間エージェント、複雑なコード変更、専門的な調査、レビュー負荷の大きいタスクに絞り、ジョブ単価と完了率を測る。そのうえで、Sonnet 5、Opus 4.8、Opus 5、Fast mode を役割別に並べる。これが、強いモデルを安全に使うための現実的な移行順である。

出典