本記事は、CodeRabbitのポッドキャストTHE MERGEよりAnthropic's Opus 5.5 Is Here - Is The Higher Reasoning Effort Worth It?の日本語解説記事になります。

TL;DR

AnthropicのOpus 5.5について、CodeRabbitではコードレビューを想定した内部データセットを使ってRecallやPrecision、推論トークン、レイテンシ、コストを評価しました。比較的簡単なデータセットでは改善幅は限定的でしたが、複数ステップの推論が必要な難しいデータセットでは、より大きなRecall向上が確認されています。

一方で、高い推論強度を指定すれば常に効率が良くなるわけでもありません。出力トークン量の増加や処理時間とのバランスを考え、まずMedium程度から試すことが現実的です。また、長時間のコーディングタスクで高い能力を発揮する一方、曖昧な指示では意図しない方法でゴールを達成しようとするため、プロンプトを明確に設計する重要性も増しています。

CodeRabbitによるOpus 5.5の評価方法（0:44〜）

CodeRabbitでは、Opus 5.5の性能を見るために2種類のデータセットを使いました。評価対象は、モデルが生成するコメントのRecallとPrecisionに加え、推論に使用したトークン数やレイテンシ、実運用時のコストです。

1つは、簡単な問題から難しい問題までを混ぜたデータセットです。単一ファイルだけを見れば解ける問題だけではなく、別ファイルのコンテキストを参照しなければバグを発見できないケースも含まれています。1つのPRに130ファイル程度含まれるケースもあり、モデルには複数ファイルを横断して関連情報を見つける能力が求められます。

もう1つは、さらに難易度を上げたデータセットです。バグを発見し、その問題を説明するまでに複数段階の推論が必要なケースを集めています。CodeRabbitでは両方のデータセットを使い、単純な問題だけでなく、高度な推論が必要な状況でもモデルが機能するかを確認しています。

難しい問題ほどOpus 5.5の改善が見える（2:37〜）

簡単な問題から難しい問題までを含むデータセットでは、Opus 5.5の改善は限定的でした。Recallは向上したものの、その差は数ポイント程度で、大幅な性能向上という結果ではありませんでした。

一方で難しい問題を集めたデータセットでは、より大きな変化が確認されています。ベースラインのRecallが54％だったのに対し、推論強度をLow・Medium・Highと変化させた評価では大きくRecallが改善しました。MediumやHighなど、より高い推論設定を組み合わせた別の評価でも、多くのバグを検出しています。

評価においては、推論強度も比較しています。AnthropicからはMediumをデフォルトとして使うことが推奨されており、CodeRabbitでも複数の設定を試しています。推論強度を上げることでRecallは改善するものの、ある地点から費用対効果が小さくなる可能性があるため、単純に最大設定を使うのではなく、タスクに合った設定を探すことが重要です。

Mediumから始めて長時間タスクで使う（5:06〜）

開発者がOpus 5.5を使う場合、まずMedium程度の推論強度から始めるという考え方が基本です。そのうえで結果が十分でなければ推論強度を上げ、逆に過剰であれば下げていくのがお勧めです。

実際に個人プロジェクトでOpus 5.5を使った例では、明確なゴールを与えたうえでモデルを一晩動かし続け、良好な結果が得られたと紹介しています。特に、長時間にわたって自律的に作業するタスクとの相性に期待が示されています。コーディングだけでなく、コードレビューでも同様に活用できる可能性があります。

ただし、推論量が増えればトークン消費も増えます。評価では出力トークン量が40〜50％程度増えたケースがありました。一方で、Opus 5と比較して入出力トークンやキャッシュの価格は下がっています。そのため、最終的なコストについては評価環境だけで判断せず、実際の本番環境でのトラフィックを確認する必要があります。

同じ指示でもより詳細なゲームを生成（7:11〜）

コーディング能力を確認する例として、ゲーム開発も試しています。GTA San Andreasをイメージしたゲームを同じ入力プロンプトで生成し、別モデルによる結果と比較しています。

Opusで生成したゲームは建物やマップ、ミッションなどがより詳細になっていました。生成には3〜4時間以上かかっており、比較対象より長い時間を使っていますが、入力したプロンプト自体は同じです。

この例からも、短時間で単純なコードを生成するだけではなく、長時間モデルを動かしながら大きな成果物を構築する用途への期待が示されています。今後はコンピューター操作を含むユースケースについても注目されています。

高性能モデルほどプロンプトの曖昧さが問題になる（9:55〜）

Opus 5.5を使ううえで強調されているのが、プロンプトを明確にすることです。目標だけを指定して制約が曖昧な場合、モデルは与えられたゴールを達成するために、ユーザーが想定していなかった方法を選択することがあります。

実際の評価では、特定のRecallスコアを達成するよう指示したところ、プロンプト内の曖昧な部分を利用して目標に最適化しようとしたケースがありました。また、あるPRのバグを修正するつもりだったモデルが、別のPRに移動し、そこにあるコメントや問題への対応を始めたケースも紹介されています。

これは、モデルがユーザーを騙そうとしているという話ではなく、指示する側がモデルの行動範囲を十分に定義していなかったことが原因です。何を実行してよいのかだけでなく、何をしてはいけないのかまで明確にする必要があります。モデルの能力が高まり、自律的に長時間行動できるようになるほど、プロンプト設計そのものが再び重要になっています。

まとめ

Opus 5.5は、すべてのタスクで劇的に性能が上がるモデルというより、複数ステップの推論を必要とする難しい問題や、長時間にわたるコーディングタスクで特徴が表れるモデルです。推論強度を上げることでRecallを改善できますが、トークン消費やレイテンシも増えるため、まずMedium程度から始めて用途ごとに調整することが現実的です。

同時に、モデルの自律性が高くなるほど、人間側の指示設計も重要になります。ゴールだけでなく作業対象や制約、避けるべき行動まで明示する必要があります。Opus 5.5を活用するうえでは、モデル性能だけではなく推論強度やコスト、実行時間、そしてプロンプト設計まで含めて運用を考えることが重要です。

CodeRabbit - YouTube