Claude Opus 5.5：料金改定と移行前に確認したいこと
Claude Opus 5.5が2026年9月22日に公開されました。 Anthropicは、コーディングや実務での性能向上に加え、標準設定の代表的な処理でOpus 5より費用が40%低くなると報告しています。これは提供元の評価結果であり、当社がお客様のシステムで測定した削減率ではありません。すでにClaudeを使うチームが確かめたいのは、自社の成果物が改善するか、費用や確認の手間が減るかです。公式発表。
まずは既存業務を一つ選び、費用、連携、成果物の順に比較することを提案します。本記事は公式資料の確認と評価手順の提案であり、当社による実機ベンチマークではありません。資料の確認日は2026年9月22日です。
料金はどこが変わったのか
Opus 5.5の100万トークン当たりの料金は、キャッシュなしの入力が4ドル、出力が20ドル、キャッシュ読み込みが0.20ドルです。以下はClaude APIの標準料金で、単位は100万トークン当たりの米ドルです。Claudeのサブスクリプション料金や当社のサービス料金とは別です。Anthropicの料金表。
| トークンの種類 | Opus 5 | Opus 5.5 |
| --- | --- | --- |
| キャッシュを使わない入力 | 5 USD | 4 USD |
| 出力 | 25 USD | 20 USD |
| 5分間キャッシュへの書き込み | 6.25 USD | 5 USD |
| キャッシュからの読み込み | 0.50 USD | 0.20 USD |
計算例として、キャッシュなしの入力10万トークンと、課金対象の出力1万トークンを使うと、トークン料金は0.75ドルから0.60ドルになります。同じ使用量なら20%の値下げです。この例にはキャッシュ操作、ツール、再試行、税金、他の料金モードは含みません。画面に表示された文章だけでなく、推論を含む課金対象の出力を数えます。
発表にある40%という数字には、完了までに必要な処理量の変化も関わります。キャッシュの利用割合、出力量、推論の強度、再試行の回数は業務によって異なります。予算に反映する前に、合格した成果物一件を得るための総費用を測定してください。
どの業務で試すか
モデルの仕様には、API ID `claude-opus-5-5`、100万トークンのコンテキスト、最大12万8,000トークンの出力が記載されています。Anthropicは、継続的なコーディングや知識業務向けのモデルと位置付けています。
最初の候補には、複数モジュールにまたがる修正、矛盾する資料の比較、各数値を出典まで確認できる報告書など、成果物を具体的に点検できる業務が向いていると考えます。大きなコンテキストには資料を多く渡せますが、必要な箇所がすべて使われたことや、条件がすべて守られたことまでは保証しません。
今も手直しが発生している業務を選び、なくしたい失敗を先に書きます。「説得力のある報告書」では判定が曖昧です。「全数値を提供資料で確認でき、不明な数値は不明と記載する」なら確認できます。
本番の処理を移す前にAPI連携を確認する
公式の変更点には、クライアント側で確認すべき仕様変更があります。
推論は無効にできず、既定のeffortは`medium`になります。
`tool_choice`でツールを強制する`any`と`tool`は拒否されます。
過去の推論を再利用できるかは、モデルと会話履歴に依存します。
Claude APIとGoogle Cloudでは旧computer-useツールが使えません。Bedrockでは扱いが異なります。
進捗表示も変わります。ツール呼び出し間のメッセージは推論ブロックに入り、既定では表示されません。表示設定とプラットフォームごとの対応は移行ガイドで確認してください。
通常のリクエスト、ツール呼び出しと結果の返却、会話の再開、モデルの切り替え、利用者に見える進捗更新を、それぞれ点検します。互換レイヤーがある場合も、実際に送信する内容を確認してください。HTTP応答が成功していても、応答の読み取り、画面表示、成果物の保存まで動くとは限りません。
チームで確認できる小さな評価
次の手順は最初の選別用です。広く導入する前に対象を増やしてください。Opus 5.5で実施済みの試験結果ではなく、評価方法の提案です。
1. 一つの業務から、使用許可のある例または架空の例を10件用意します。情報の欠落、資料の矛盾、ツールの失敗も含め、期待する結果はプロンプトとは別に保管します。
2. 現行と候補に同じ入力、ツール、合格基準を使います。effortは明示して記録します。異なる既定値の比較では条件を揃えられません。
3. 担当者が正確さ、出典、作業範囲を確認します。手直し時間、経過時間、全トークン使用量、失敗した試行も記録します。
4. 評価全体の費用を合格した成果物の数で割ります。確認に使った時間も併記します。安い回答でも大幅な修正が必要なら、業務上の価値は下がります。
5. 合意した基準を満たしたら、条件に合う業務の一部から切り替えます。元に戻す経路を残し、モデル変更後に会話を再開する動作も確かめます。
受け入れ基準のガイドも、試験の条件を具体化する際に使えます。「資料の統合にはOpus 5.5、定型項目の抽出には現行の構成」という判断でも十分に有用です。すべての業務を一度に移す必要はありません。
次の一歩を具体的にする
入力の例、必要な成果物、現在手直ししている箇所を一つずつ用意してください。業務評価の範囲を相談する。本格的な移行の前に、連携の確認項目と合格を判断する証拠を整理します。