Claude

Claude Opus 5.5 公開。最上位が Fable 5.1 の水準まで降りてきて、Pro の既定モデルが Sonnet から Opus へ変わった

Anthropic が 2026-09-22、Claude Opus 5.5(claude-opus-5-5)を公開した。公式の説明は「大半の作業で Claude Fable 5.1 と同水準の性能を、Opus 5 比で約40%安い運用コストで出す」。API 価格は入力 $4 / 出力 $20 per Mtok(Opus 5 は $5 / $25)で、キャッシュ読み取りは $0.50 から $0.20 へ60%下がった。出力速度は Opus 5 比30%以上速い。ベンチマークは Terminal-Bench 4.0 が 66.4%(Opus 5 は 52.3%)、GDPval-AA v2.1 が 1846 Elo(Fable 5.1 は 1735)。同時に Claude Code v2.1.280 が Pro / Team Standard の既定モデルを Sonnet から Opus へ変更しており、何も設定していない利用者の挙動が変わる。プロンプトインジェクション耐性も向上し、封じ込め境界の回避試行が約85%減ったとしている。Opus 5.5 では thinking を無効化できない。

ニュース原文を読む ↗

要約

Anthropic は 2026-09-22、Claude Opus 5.5(モデルID claude-opus-5-5)を公開しました。公式の表現は「大半の作業で Claude Fable 5.1 と同水準の性能を出し、Opus 5 と比べて運用コストが約40%安い」です。

この1文には2つの主張が同居しています。性能が上がったという話と、値段が下がったという話です。モデル発表ではどちらか一方が語られることが多く、両方が同時に動く日は多くありません。

数字を並べます。API 価格は入力 $4 / 出力 $20 per Mtokで、Opus 5 の $5 / $25 から20%下がりました。キャッシュ読み取りは $0.50 から $0.20 へ60%、キャッシュ書き込みは $6.25 から $5 へ20%下がっています。Fast mode は入力 $8 / 出力 $40 です。

ベンチマークでは、エージェント的コーディングの Terminal-Bench 4.0 が 66.4%(Opus 5 は 52.3%)、FrontierCode v1.1 が 54.4%(同 48.0%)、CursorBench 4.0 が 57.8%(同 46.6%)。ナレッジワークの GDPval-AA v2.1 は 1846 Elo で、Fable 5.1 の 1735 を上回りました。コンピュータ操作の OSWorld 2.0 は 81.8%。出力速度も Opus 5 比で30%以上速いとしています。

そして、今日いちばん多くの人の手元で挙動が変わるのは、ベンチマークではなく既定値の変更です。

何が変わったか

変更は3つの層で起きています。

1つ目は、モデルそのものの追加です。 Claude.ai(Pro / Max / Team / Enterprise)、Claude Platform API、AWS、Google Cloud、Microsoft Azure で利用できます。5時間ごとの利用上限も拡大されました。Life Sciences Verification Program と、拡張された Cyber Verification Program の対象として、規制業務向けの利用枠も用意されています。

2つ目は、価格です。 上に挙げたとおり、入出力とキャッシュの4項目すべてが下がりました。**下げ幅が最も大きいのはキャッシュ読み取りの60%**で、ここは「同じ前提を何度も読ませる使い方」の単価に直結します。長いシステムプロンプト、長い仕様書、長いコードベースを抱えたまま何十回も往復するエージェント用途ほど効きます。

3つ目が既定値です。ここが実務上いちばん影響します。 同日に公開された Claude Code v2.1.280 が Opus 5.5 を既定の Opus モデルとして取り込み、あわせて Pro プランと Team Standard プランの既定モデルを Sonnet から Opus へ変更しました。Max / Team Premium / Enterprise はもともと Opus 既定だったので、これで全プランが揃ったことになります。

つまり Pro ユーザーは、何も設定を変えていなくても、今日から Opus を使っています。

関連して、/effort がモデルごとの設定になる前に保存していた effort レベルは、Opus 5.5 のような新モデルには引き継がれません。各モデルの既定値から始まり、明示的に選び直すまでそのままです。「前に high にしたはずなのに」という食い違いは、ここが原因になり得ます。

もう1つ、設定として消えたものがあります。Opus 5.5 では thinking を無効化できません。 公式は新しいコンプライアンス要件に合わせた変更と説明しています。thinking を切ることでトークンを節約する、あるいは応答の形を単純にする、という運用を組んでいた場合は、Opus 5.5 ではその手が使えません。preserved thinking は 2026-08-31 以降に作成された API アカウントへ適用されます。

安全性の側も動いています。 アライメント評価の改善に加え、プロンプトインジェクション耐性が上がり、封じ込め境界の回避試行が約85%減ったとしています。サイバーセキュリティと生物分野の安全策は Fable 5.1 と同等のものが適用されます。

後続として、Claude Sonnet 5.5 と Claude Haiku 5.5 が数週間内に予定されています。今日の判断は暫定であり、あと数週間で下位モデル側の数字も動く、という前提で読むのが妥当です。

業務インパクト

最初に確認すべきは、自分の組織が「既定値のまま使っている」かどうかです。

Claude Code を Pro または Team Standard で使っているチームは、今日から既定モデルが Opus に変わりました。モデルを明示指定していないスクリプト、CI、エージェント設定はすべて影響を受けます。性能が上がる方向の変更なので壊れることは少ないですが、単価は Sonnet より高いままです。 使用量の多いバッチ処理を既定モデル任せで回している場合、請求額の傾きが変わります。

コスト試算の作り直しが必要です。 Opus 5.5 は Opus 5 より20%安いので、すでに Opus 5 を使っていた組織にとっては、何もせずコストが下がる話です。一方、Sonnet で回していた処理を「せっかく安くなったから Opus へ」と動かすと、単価は上がります。方向を混同しないでください。

判断の軸はこうなります。Opus 5 を使っていたなら、Opus 5.5 へ移すのは検討ではなく作業です。 同等以上の性能で2割安く、速度も3割速いので、移さない理由を探す方が難しい。Fable 5.1 を使っていたなら、比較対象として Opus 5.5 が並びました。 公式の主張は「大半の作業で同水準」で、GDPval-AA では Opus 5.5 が上回っています。自分の業務での実測が要ります。Sonnet で足りていたなら、急いで動く理由はありません。 数週間後に Sonnet 5.5 が出ます。

キャッシュ読み取り60%減は、設計を変える余地を作ります。 これまで「長い前提を毎回渡すのは高いから、要約して渡す」という工夫をしていた処理は、前提を丸ごと渡す方が安く・正確になる可能性があります。要約による情報欠落と単価のトレードオフが、単価側に有利な方向へ動きました。プロンプトキャッシュを使っていない構成なら、まずそこを入れる方が効きます。

thinking を切れないことは、一部の運用に効きます。 出力トークン量の上限を厳しく見積もっていた処理、応答をそのままパースしていた処理は、Opus 5.5 へ移す前に挙動を確認してください。

プロンプトインジェクション耐性の向上は、営業トークとしてではなく前提条件として扱うべきです。 85%減は85%であって100%ではありません。外部入力をモデルに読ませる構成の設計方針(権限の最小化、実行前の確認、出力の検証)を緩める根拠にはなりません。耐性が上がったから対策を減らす、という読み方が最も危険です。

副業・個人活用視点

個人の Pro 契約者にとっては、今日から既定が Opus になったというのが全部です。 追加費用なしで上位モデルが既定になりました。これまで「Opus を使いたいときだけ切り替える」運用をしていた人は、切り替え操作そのものが不要になります。

むしろ注意すべきは逆方向です。 5時間ごとの利用上限は拡大されましたが、無制限ではありません。Opus は Sonnet より上限を早く消費します。 軽い作業まで全部 Opus で回すと、本当に必要な場面で上限に当たる、ということが起こり得ます。「軽い用事は Sonnet、重い判断は Opus」という使い分けは、既定が変わった後もそのまま有効です。

受託や副業でトークン課金を顧客へ転嫁している場合は、単価表の更新が要ります。 Opus 5 ベースで見積もっていた案件は、原価が2割下がりました。見積もりを出し直すか、利幅として持つかは判断ですが、原価が変わったことを把握していない状態が一番まずい。

「最上位モデルが安くなった」という事実は、提案の材料になります。 これまで予算の都合で下位モデルを前提に設計していた案件を、上位モデル前提で組み直せる余地が出ました。ただし数週間後に Sonnet 5.5 / Haiku 5.5 が出ます。今日の価格差を根拠に長期の設計を固めると、数週間で前提が変わります。 モデル名を埋め込んだ設計ではなく、モデルを差し替えられる設計にしておく方が安全です。

学習・情報発信の観点では、「性能向上」と「値下げ」が同時に来た点が語りどころです。 推論効率の改善分を価格へ戻す動きは、この数か月で複数のベンダーが取っています。モデルの優劣より、コストと性能の曲線がどう動いているかを追う方が、実務的な示唆が出ます。

参考

claude opus-5-5 モデル選定 API価格 既定モデル プロンプトインジェクション コスト設計