Claude Opus 5.2 vs Claude Opus 5：違いは未確認、まず何をテストすべきか
判断の早見表
| 質問 | Claude Opus 5 | 「Claude Opus 5.2」 | 今すべきこと |
|---|---|---|---|
| 公式に名前が付いている？ | はい。2026 年 7 月 24 日リリース | いいえ。コミュニティの呼び名 | ロードマップ項目ではなく、監視対象として扱う |
| 文書化された API ID は？ | claude-opus-5 | Anthropic のドキュメント、SDK の一覧、Claude Code のビルドのいずれにも見つからず | 推測した ID を設定に入れない |
| 料金と上限は文書化されている？ | 100 万トークンあたり $5 / $25、1M コンテキスト、出力 128K | 不明 | Opus 5 を基準に予算を組む |
| 今日、同条件のテストを実行できる？ | はい。文書化されたチャネル経由で可能 | 呼び出せる候補がない | ベースラインとリプレイセットを今のうちに凍結する |
| ユーザーは何を報告している？ | 「サボる」、考えすぎる、長いタスクで「続けて」が必要 | "way faster"、出力がきれい、"not lazy"（Claude Code のみ） | 報告を 1 つずつ測定可能なテストに変換する |
| 切り替えた場合のフォールバックは？ | Anthropic 運営のプラットフォームでは active と記載され、廃止は「2027 年 7 月 24 日より前にはならない」 | 該当なし | ロールバック先にする特定の EvoLink ルートを検証する |
勝者はいません。文書化された製品は片方の列だけだからです。この比較から得られる実用的な成果は、後継モデルが示さなければならない証拠を定めることです。
Claude Opus 5.2 vs Opus 5：分かっている違いと、分かっていないこと
Anthropic のモデル概要、料金ページ、リリースノート、Claude Code の変更履歴が記載しているのは Claude Opus 5 までで、Opus 系列でそれより新しいものはありません。9 月 14 日以降、複数の X アカウントが、Claude Code が一部の Opus 5 リクエストを新しいビルドにルーティングしていると報告しています。識別子やリクエスト記録を含む投稿はなく、どのアプリやプランが対象かについて報告は食い違い、Anthropic はコメントしていません。
- 「Foundry の
claude-opus-5-2.yaml」は、値が Opus 5 と同じコミュニティのレジストリのエントリである - 「xhigh と max を含む 5 段階の effort」は、現在の Opus 5 で文書化されている段階そのものである
- 8 月には「Opus 5.1」が噂されたが、その名前ではリリースされなかった
- モデルに「Tibo」が誰かを尋ねる方法が読んでいるのは生成されたテキストであり、モデルの識別ではない
ユーザーの報告と、証拠として認められるもの
| コミュニティの報告（Claude Code、9 月 14〜17 日） | それが応えている Opus 5 への不満 | 証拠として認められるもの |
|---|---|---|
| "way faster" / 考えすぎが減った | high と xhigh の effort で、出力の前の thinking が長い | 同じタスクセット、同じ effort レベルで、合格タスクあたりの実時間と出力トークンを数日間にわたって測る |
| "not lazy"、長いタスクを進んでこなす | タスクの途中で止まり、ユーザーに続行を求める | 完了した長時間タスクあたりの催促回数。介入なしでの完了率 |
| "really clean output"（出力がとてもきれい。X の投稿）。肥大化や作り込みすぎの少ないコード（又聞きでしか読めなかった Reddit のスレッド） | 作り込みすぎ、または冗長な実装 | 依頼した範囲に対する diff のサイズ。受け入れた変更あたりのレビュアーの修正量 |
| 視覚タスクと 3D タスクで良くなり "getting close to Astra-level"（Astra のレベルに近づいている）としつつ、同じ投稿者は依然として Astra のほうが上だと見ている | 視覚・空間系の作業が弱い | 固定のルーブリックを使った同条件の視覚タスク（そのワークロードが自分たちにとって重要な場合） |
| あるフォーラムのユーザーが、ある晩には使えたのにその後また使えなくなったと報告 | 不満ではなく、警告 | どんな改善も、ベースラインと見なす前に、複数の日と複数の CLI バージョンにわたって持続していること |
どの改善なら切り替える価値があるか：タスク別
「良くなった」の意味は、ワークロードによって違います。何を最初に測るのか、どの程度の改善なら移行作業に見合うのかを、タスク種別ごとに決めてください。しきい値を決めるのは皆さんです。この表が示すのは、どこを見るべきかだけです。
| タスク種別 | 最初に測るもの | あわせて見るもの | 切り替える価値のある改善 |
|---|---|---|---|
| 対話型の Q&A とチャット | 最初の有用な回答までの時間（p50 と p95） | 受け入れ率、出力トークン | 受け入れ率を落とさずに、レイテンシが「ユーザーが気づく」水準から「気づかない」水準になる |
| リポジトリ規模のコーディング | 受け入れた変更のテスト合格率 | 依頼した範囲に対する diff のサイズ。レビュアーの修正時間 | 1 回目の試行でテストを通過する変更が増え、diff が依頼したファイルの範囲に収まる |
| 長時間エージェント | 人の介入なしでの完了率 | タスクあたりの催促回数、ツールエラーからの復旧、完了タスクあたりの総トークン | 「続けて」や救済が必要だったタスクが、トークンを膨らませることなく無人で完了する |
| 構造化抽出 | パースまたはスキーマ検証の成功率 | リトライ回数、有効レコードあたりのコスト | 有効レコードあたりのコストが同じか下がり、無効な出力が減る |
| バッチでの文書処理 | 合格文書あたりのコスト | バッチ期限内のスループット、キャッシュヒット率 | 締め切りを守ったまま、合格文書あたりのコストが下がる |
あるタスク種別に、今の Opus 5 で測定可能な問題がないなら、新モデルがほかでどんなスコアを出そうと、そのタスクを移す理由はありません。
Claude Opus 5 がすでに提供しているもの
この比較で計測できる側は Opus 5 です。
- API モデル ID は
claude-opus-5。日付なしの固定スナップショット - 100 万トークンあたり入力 $5・出力 $25。キャッシュ書き込みは $6.25（5 分）と $10（1 時間）、キャッシュ読み取りは $0.50。バッチは半額。リサーチプレビューの fast mode は $10 / $50 で、Claude API のみ
- 1M トークンのコンテキスト（それより小さいバリアントなし）。最大出力 128K
- adaptive thinking が既定でオン。effort は low、medium、high（既定）、xhigh、max。thinking を無効にできるのは high 以下のときだけ
- thinking トークンは出力トークンとして課金され、
max_tokensにも算入される
過去の Opus リリースで変わったこと：影響の種類別
リリースに含まれる変更のすべてが、インテグレーションを壊すわけではありません。3 つの種類を分けて見ると、何を再テストすべきかが分かります。
| リリース | 日付 | 文書化された破壊的変更 | コストまたは挙動の変化 | 新機能 |
|---|---|---|---|---|
| Opus 4.6 | 2026 年 2 月 5 日 | — | adaptive thinking の導入 | 1M コンテキスト、出力 128K、コンテキスト圧縮 |
| Opus 4.7 | 2026 年 4 月 16 日 | 既定値以外の temperature、top_p、top_k は 400 を返す | 新しいトークナイザー：同じテキストでもトークン数が増える | xhigh effort、より高解像度のビジョン |
| Opus 4.8 | 2026 年 5 月 28 日 | — | — | fast mode、エージェントと推論の向上 |
| Opus 5 | 2026 年 7 月 24 日 | thinking が既定でオン。xhigh または max で thinking を無効にすると 400 を返す | thinking トークンが出力として課金されるため、同じ料金のまま出力量が増える。既定の応答も長くなった | キャッシュの最小単位が 512 トークンに、会話途中でのツール変更（ベータ） |
切り替えの前に行う互換性チェック
| 対象 | 確認すること | 理由 |
|---|---|---|
| モデル識別子 | その ID が、Anthropic または利用中のクラウドチャネルによって文書化されていること。Bedrock と Google Cloud には独自の形式がある | 推測した文字列は失敗するか、プロキシによって無関係なモデルにエイリアスされるおそれがある |
| thinking と effort | effort のマトリクスを再実行する。無効化の経路と 400 の挙動をテストする | Opus 5 は両方を変えた。既定値はまた変わり得る |
| トークンの計上 | タスクあたりの入力、出力、キャッシュのトークンを測り直す | トークナイザーや thinking の変更は、定価が変わらなくても請求額を変える |
| サンプリングパラメータ | モデルが拒否するパラメータが設定に残っていないか grep する | 4.7 は既定値以外のサンプリング値をエラーにした |
| 構造化出力とツール | パーサーとスキーマ検証をリプレイし、ツールの失敗を注入する | Anthropic の Opus 5 のノートによれば、content[0].text を読むコードは、ブロックを type で選ぶ必要がある。応答が thinking ブロックから始まることがあるため |
| フォールバック | フォールバックがリクエストに応答したときはログに残し、実験の独立した群として扱う | モデルが混ざった結果は比較を汚染する |
識別について補足します。返却される model フィールド、リクエスト ID、使用量、請求書をログに残すことは必要ですが、それは基礎となる重みの独立した証明にはなりません。どのフィールドも、サーバーかプロキシが供給するものだからです。確かめられるのは、文書化された ID の対応関係、返却されるメタデータ、信頼できる上流の記録、課金の間の整合性です。すり替えを追跡可能にするにはそれで十分で、実務上の目標もそこにあります。
ペア評価の進め方
1. Opus 5 のベースラインを凍結する
プロンプト、ツール、effort レベル、コンテキストの状態、タスクの合格率、実時間、入力と出力のトークン、キャッシュの利用、リトライ、レビュー時間、既知の失敗ケースを記録します。Opus 5 が「続けて」と求めてきたセッションや、変更を作り込みすぎたセッションも含めてください。報告が主張しているのはまさにそこなので、「変更前」の数字が必要になります。
2. 3 つのリプレイグループを作る
- 成功すると分かっているタスク。リグレッションを捕まえるため
- Opus 5 が失敗すると分かっているタスク（サボり、冗長さ、考えすぎ）。置き換えの価値を測るため
- 現状では人間か別のルートが必要な、限界に近いタスク
3. 候補を加えるのは、文書化され、整合性の取れたルートになってから
候補をハーネスに加えるのは、その ID が Anthropic または利用中のクラウドチャネルによって公開され、認証済みリクエストが成功し、返却されるメタデータが文書化された対応関係と一致し、使用量が公開料金と照合できたときです。そのうえで、ベースラインと同じプロンプト、ツール、タイムアウト、effort の方針、リトライのルール、レビュアーを使います。
コストの計算例
切り替えを決める数字は、総支出ではありません。受け入れ基準を通過したタスク 1 件あたりに、いくら払っているかです。
合格タスクあたりの API コスト = 評価グループの API 総支出 ÷ 受け入れ基準を通過したタスク数分子には、そのグループが消費したものをすべて入れます。失敗した試行、リトライ、フォールバックの呼び出しも含みます。キャッシュの書き込みと読み取りは、実際に課金されたとおりに数えてください。thinking トークンはすでに出力トークンとして課金されているので、二重に足さないでください。人によるレビュー時間は、API のドル額に換算せず、独立した列に残します。
| ベースライン群 | 候補群 | |
|---|---|---|
| 試行したタスク | 100 | 100 |
| API 総支出（失敗とリトライを含む） | $12.00 | $14.00 |
| 受け入れ基準を通過したタスク | 80 | 95 |
| 合格タスクあたりの API コスト | $12.00 ÷ 80 = $0.150 | $14.00 ÷ 95 = $0.147 |
| 人が修正またはやり直す必要のあるタスク | 20 | 5 |
候補群は $2.00 多く使いましたが、それでも合格タスクあたりではわずかに安くなっています。支出のうち、使える成果につながった割合が大きいからです。より大きな効果は最後の行にあります。人の手に戻るタスクが 15 件減っています。逆のケースも同じくらい現実的です。候補が $16.00 を使って 85 件しか通過しなかったとしたら、合格タスクあたりのコストは $0.188 になり、品質の上積みが 25% 高い単価に見合うかどうかが問われます。見出しの数字を読む前に、この割り算をしてください。
記入して使える受け入れ記録
「明らかに良い」「レイテンシが維持されている」といった曖昧なゲートは、チェックのしようがありません。しきい値は、そのタスク種別のビジネス要件に基づいて実行の前に書き、そのあとで結果を記録します。この表をタスク種別ごとに 1 枚ずつコピーして使ってください。
| 項目 | あなたのしきい値（実行前に設定） | ベースラインの結果 | 候補の結果 | 達成？ |
|---|---|---|---|---|
| タスク種別とリプレイグループ | — | |||
| サンプルサイズ（試行したタスク数） | 最小：____ | |||
| 合格率（合格 ÷ 試行） | ____ % 以上、かつ成功既知グループでベースラインを下回らない | |||
| p95 レイテンシ | ____ 秒以下 | |||
| 合格タスクあたりの API コスト | $ ____ 以下 | |||
| 100 タスクあたりのリトライとフォールバック呼び出し | ____ 以下 | |||
| 合格タスクあたりの人による修正時間 | ____ 分以下 | |||
| 長時間タスクあたりの催促回数（エージェントのみ） | ____ 以下 | |||
| ____ 日間の一貫性 | どの日にもしきい値の未達がない |
タスク単位で切り替え、戻り道もテストする
現実的な着地点は、全面的な切り替えではなく、ルーティングポリシーです。記録を通過したタスク種別を、上のマトリクスの順に移し、残りは Opus 5 に置いておきます。
claude-opus-5 を active とし、廃止は「2027 年 7 月 24 日より前にはならない」としています。また、その日付が適用されるのは Anthropic が運営するプラットフォーム（Claude API、Claude Platform on AWS、Microsoft Foundry）で、Amazon Bedrock と Google Cloud は独自にスケジュールを決めるとも述べています。これは評価のための期間です。フォールバック先にする特定のルートのキャパシティ、権限、ステータスを保証するものではありません。カナリアを始める前に、使う予定の Opus 5 フォールバックルートに実際のトラフィックを流し、クォータと権限を確認し、トラフィックをそこへ戻す設定変更をリハーサルしておいてください。Opus 5 を残すべきなのは、合格率、レイテンシ、コストの目標をすでに満たしている場合、移行しても測定された上積みがない場合、あるいはログでプライマリとフォールバックの呼び出しをまだ区別できない場合です。ベースラインを集めている間の「待ち」は、受け身ではありません。受け身になるのは、発表されてもいないモデルのためにデリバリーが止まったときだけです。
EvoLink の統合 API では、モデルの選択をアプリケーションコードではなくルーティング設定に置けるため、挑戦者となるモデルを追加するのも外すのも低コストです。この計画のどの部分も、今日 Opus 5.2 のルートが存在することを前提にしていません。
現在の Claude Opus 5 ルートを確認する Claude Opus 5.2 API のリリース通知を受け取るFAQ
Claude Opus 5.2 は発表されましたか？
2026 年 9 月 18 日時点で、Anthropic のモデルカタログ、リリースノート、料金ページ、ニュースルームのいずれにも言及は見つかりませんでした。最新の Opus は Claude Opus 5 です。
Claude Opus 5.2 は Claude Opus 5 より優れていますか？
証拠に基づく比較はありません。文書化され、呼び出し可能な Opus 5.2 が存在しないからです。コミュニティの報告は、Claude Code 内で出力が速くなりサボらなくなったと述べていますが、モデル識別子も測定値も伴っていません。
ユーザーは Opus 5.2 で何が直ったと言っていますか？
速度、考えすぎ、長いタスクでのサボり、冗長なコードや作り込みすぎたコードです。リプレイセットの分類としては適切ですが、これらは主張であって、結果ではありません。
コストを公平に比べるにはどうすればいいですか？
評価グループの API 総支出（失敗とリトライを含む）を、受け入れ基準を通過したタスクの数で割ります。比べるのはその数字であって、総支出や定価ではありません。人による修正時間は別に報告します。
新しい Opus では、クォータや予算の消費が速くなりますか？
測定できるようになるまでは分かりません。Opus 5 の消費量が増えたという報告はすでに一部のユーザーから出ています。また、Opus 5 では thinking トークンが出力トークンとして課金されるため、より多く考えるモデルは、定価が同じでもコストが上がります。実際に使う effort レベルで、合格タスクあたりの入力、出力、キャッシュのトークンを測ってください。Claude アプリのコンシューマー向けプランのクォータは、API の課金とは別の話です。
プロジェクトを始めるのは Opus 5.2 を待ってからにすべきですか？
いいえ。納期のある開発には Claude Opus 5 を使い、モデルの選択は設定に置いておき、アップグレード評価の材料になるトレースを集めてください。
モデル ID の claude-opus-5-2 は今使えますか？
いいえ。この識別子は Anthropic のどのドキュメントにも見つかりませんでした。推測した ID は失敗するか、もっと悪い場合には、サードパーティのプロキシによって無関係なモデルにマッピングされます。
新しい Opus が出ても Opus 5 は使い続けられますか？
claude-opus-5 を active とし、廃止は 2027 年 7 月 24 日より前にはならないとしています。Bedrock と Google Cloud は独自に日程を決めます。これは特定のゲートウェイルートを保証するものではないので、使う予定のフォールバックルートをテストしてください。リリース後は 2 つをどう比較すればいいですか？
プロンプト、ツール、タイムアウト、effort レベル、コンテキストの状態、リトライのルール、レビュアーをそろえます。タスク種別ごとに受け入れ記録を 1 枚記入し、合格タスクあたりのコストを比べ、リハーサル済みの戻り道を用意したうえで、タスク種別ごとにトラフィックを移します。
情報源
- Anthropic: Models overview
- Anthropic: Model IDs and versioning（"Model weights versus serving infrastructure" を含む）
- Anthropic: What's new in Claude Opus 5（破壊的変更と thinking トークンの課金）
- Anthropic: Effort parameter
- Anthropic: Pricing
- Anthropic: Model deprecations（対象プラットフォーム、パラメータの廃止）
- Anthropic: Introducing Claude Opus 4.7
- Anthropic: Introducing Claude Opus 4.8
- Anthropic: Introducing Claude Opus 5
- X: @notjazii、2026 年 9 月 14 日
- X: @pankajkumar_dev、2026 年 9 月 15 日
- EvoLink: Claude Opus 5.2 のリリース日
- EvoLink: Claude Opus 5.2 API の提供状況
- EvoLink: Claude Opus 5
