GPT-5.6 SolとTerra:コーディングエージェントとコードレビューでの位置づけ

GPT-5.6 Sol and Terra: Where they fit for coding agents and code reviewの意訳です。

OpenAIはGPT-5.6をリリースしました。エンジニアリングチームにとっての実践的な問いは、SolとTerraがコーディングのスタックのどこに位置づけられるか、です。このレビューでは、コーディング体験、長時間にわたるエージェントの作業、そしてCodeRabbitのレビューベンチマークを見ていき、各モデルが役立つ領域と、従来のルーティングのやり方がなお通用する領域とを切り分けます。

コーディングエージェントにGPT-5.5や以前のOpenAIモデルを使っているなら、Solのテストを始めましょう。Solはより最後までやり遂げます。散らかったリポジトリのタスクをこなし、長いチェックリストを真剣に扱い、私たちのハーネスで動かすと、より多くのレビュー上の問題を見つけます。Terraは、範囲の限られた作業のためにテストする、より安価なレーンです。その長時間のコーディング実行は、トークンあたりの価格と並んで、解決したタスクあたりのコストを測るべきだという注意喚起でもあります。

Solはほかの最先端モデルを消し去るわけではありません。アーキテクチャ上の判断や計画のセンスが欲しいときは、Fable 5のほうがなお強く感じられます。一部のレビューワークフローでは、Sonnet 5のほうがコメント品質の点でなおすっきりしています。Solは、より実践的な軸で勝ります。作業を渡せば、それを押し進め続けてくれると期待できるのです。

それが、今回のリリースにおける乗り換えの問いです。最も賢く聞こえるモデルが必要なのか、それとも作業をより多く仕上げてくれるモデルが必要なのでしょうか。

GPT-5.6の新しい点

OpenAIはGPT-5.6を、段階を持つ能力のあるファミリーだと説明しています。Solがフラッグシップモデルです。Terraがより低コストな選択肢です。Lunaが最も速く最も低コストな段階です。重要な変化は、GPT-5.6を1つのモデルとして扱うのではなく、いまや作業を深さに応じてルーティングできることです。

このリリースは、エンジニアリングチームにとって4つのことを変えます。

1. Solは、より強力な長期的視野のコーディングレーンを提供します。タスクがファイルやテスト、そして後続の修正をまたいだ粘り強さを必要とするときに使うべきモデルです。
2. Terraは、範囲の限られた実装や最初のパスのレビューのための、より安価な経路を提供します。
3. Lunaは、速さとコストが主な制約となる大量の作業のための、推論の少ないレーンを提供します。
4. プロンプトキャッシュがより予測しやすくなり、明示的なキャッシュのブレークポイントと30分の最低キャッシュ寿命が加わりました。

価格表は、競争上の姿もより明確にしてくれます。Solは入力価格でClaude Fable 5より安く、Opus 4.8に近い一方で、TerraとLunaはより軽い作業のための、より安価なルーティングレーンを作り出します。

OpenAIはまた、明示的なキャッシュのブレークポイントと30分の最低キャッシュ寿命を含む、より予測しやすいプロンプトキャッシュも追加しました。長時間にわたるエージェントのジョブでは、これがモデルのコストを変えうるのです。同じリポジトリを何時間も読み込むモデルは、キャッシュの読み込みが効くようになると、見え方が変わってきます。

こちらが実用的なマップです。

Lunaは、ファネルの入り口にあたるエージェントの作業のために注目すべき段階です。安価な最初のパスがそれ自体で価値を持つ場所や、TerraやSolへのエスカレーションの前に負荷を減らせる場所で使いましょう。鍵は、推論が少ないことです。タスクが主に要約、ラベル付け、抽出、あるいは骨組みの下書きであれば、Lunaが始めるべき場所です。

最もはっきり表れたのは、やり遂げる力だった

あるタスクが、そのパターンを分かりやすく見せてくれました。エージェントは、あるプログラミング言語にステップ付きのスライシングを追加しなければなりませんでした。それはパーサーの対応、配列や文字列に対する実行時のふるまい、代入のふるまい、Unicodeの正しさ、そして正確なエラーメッセージを意味しました。

より弱いエージェントは、それを完了したように見せることがあります。パーサーを編集し、うまくいく1つのテストを実行して、止まってしまうのです。Solは、この仕事の役に立つバージョンをやり遂げました。パーサーとエバリュエータを調べ、的を絞ったテストを追加し、長さゼロの代入やUnicodeのルーン数といったエッジケースを扱い、中核のテストスイートを実行し、無関係なgo vetの警告に気づき、検証したうえで提出したのです。

そのプロセスが兆候を運んでいました。Solは、機能の周りにある地味な作業をやってのけたのです。

私たちは、メモリに残っているライブのパズルテストでも同じパターンを見ました。3人の生徒の単語パズルでは、Solは候補の単語を文字に分解し、各生徒の知識の状態を順に推論していきました。Terraも答えにたどり着きましたが、その経路はより場当たり的に見えました。答えは一致しました。確信の度合いは、しませんでした。

コーディングエージェントにとって、そのギャップは、実行をどれだけ信頼できるかを変えます。パズルを当て推量で切り抜けるモデルは、あなたのリポジトリの中でも当て推量をするでしょう。方法を組み立ててそれを検証するモデルは、次のタスクに明白な経路がないときに、より高い勝算を持ちます。

Solは、粘り強いエンジニアとしてイメージするのが最もふさわしいでしょう。飾らない物言いで、リストに対して頑固です。それでも私は、自由度の高いアーキテクチャには別のモデルを持ち込むでしょう。チェック項目を片づける必要があるときは、Solを選ぶでしょう。

私たちは、タスクの面でも同じ切り分けに気づきました。Fableはアーキテクチャの議論、UIのフロー、そして高レベルの判断に向いている傾向があります。Solはリスト、長時間にわたる実装、既存のコードパターン、コンピュータ操作のワークフロー、サブエージェントの連携、そして複数日にわたるCodexの実行において、より強力でした。それがチームにとって役立つ区別です。最も賢い議論が欲しいときはFableを、キューを動かす必要があるときはSolを使いましょう。

コーディングの実行:Solはやり遂げる

私たちはTypeScript、Go、Python、JavaScript、Rustにわたる100を超えるタスクによる、長期的視野のコーディング実行も見ました。各タスクはエージェントにリポジトリを調べ、コードを変更し、ふるまいのチェックに合格することを求めます。このスコアが役立つのは答えのスタイルではなく、完了したソフトウェアの変更を追跡するからです。

Solは試行のエラーなしで、63.7%のタスクに合格しました。それは実際に手を動かした体験と一致します。Solは方向感覚を保ち、要件を確認し続け、リポジトリのタスクの華やかでない部分をこなしていくのです。

Terraは40.7%のタスクに合格しました。また、より多くの出力トークンを使いました。Terraは出力トークンあたりのコストがSolの半分ですが、この実行では完了したタスクあたり平均55,594出力トークンを使い、Solの20,968に対して多くなりました。

Terraは、範囲の定まった作業では安上がりかもしれません。長時間のコーディングのジョブでは、大量の作業をそこへ回す前に、解決したタスクあたりのコストを測りましょう。

これがエージェントループにとって意味すること

コーディングの結果は、特定のルーティングのパターンを指し示しています。Solを、SDLCのあらゆるモデルの代替として扱うべきではありません。作業がエージェントが実行してテストし、改善できるだけの形を持ったときに、最も強くなります。

コード生成をエージェントループに分けるなら、私は作業を次のようにルーティングするでしょう。

主な変化は、エージェントに進み続けることを信頼できる場所です。問題が曖昧なときは、計画は依然として2つ目のモデルから恩恵を受けます。計画が明確になれば実装、テストの修復、そして後続の修正のためにループに入れるモデルとしてSolが有効です。

コードレビュー:Solはより多く見つける、そこからフィルタリングが信頼を勝ち取らねばならない

コードレビューの基準は異なります。コーディングエージェントは、パッチを仕留めるなら冗長でもかまいません。レビュアーは正しい問題を捉え、開発者が対応するような形でそれを説明しなければなりません。

私たちは既知の問題を含む本番相当のPRを使い、新しいモデルをCodeRabbitのレビューベンチマークに通しました。目的はレビューシステムにSolやTerraを加えたときに、何が起きるかを見ることでした。

ベースラインは、私たちの現在のアンサンブルです。デルタは、そのモデルをアンサンブルに加えたときの変化を示します。正のデルタは、現在のアンサンブルが見逃しやすかった問題をそのモデルが見つけたことを意味します。負のデルタは、その実行でモデルが十分に役立つ兆候を加えなかったことを意味します。

この表は6つの指標を使います。

• Pass： 開発者が対応できる形で見つかった、想定された問題の数
• Delta vs baseline： 現在のアンサンブルにそのモデルのレーンを加えたあとの上昇または低下
• Pass full： なお表現の引き締めやプロダクト側のフィルタリングを要するかもしれない妥当な指摘に、より広く点を与えたもの
• Precision： 対応可能なコメントのうち、残すに足るほど正しかったものの割合
• Comments： プロダクト側のフィルタリング前の、生のモデルのコメント量
• Nitpicks： レビューのノイズを生みうる、優先度の低いコメント

Solは、見落とし防止の点で正しい方向に動きました。私たちの内部のレビューの議論では、ベースラインよりおよそ8件多くバグを見つけました。ダッシュボードのデータでは、Solは対応可能な合格99件中69件、すなわち69.7%で、モデルのレーンをアンサンブルに加えたあとに+7.4ポイントの上昇を示しました。

Solは、メインのレビューのパスにとってより強力な候補です。より批判的、より網羅的でリスクのある差分を素通しさせにくいのですが、その代償が精度になります。対応可能な精度は31.6%で、そのレポートではベースラインより8.2ポイント低く、231件の生のコメントを生み出しました。

そのトレードオフがCodeRabbitで扱えるのは、フィルタリングのほうが、見逃したバグを取り戻すよりも簡単だからです。モデルがより多くの妥当な問題を見つけるなら、プロダクトは弱いコメントを抑え、見せ方を調整し、役立つ指摘だけを開発者へと回せます。そもそも問題を見つけられないモデルは、扱える材料が少なくなります。

Terraは、より物静かなレーンです。143件のコメントと21件のnitpickを生み出し、Solよりずっと少なくなりました。合格率も52.5%と低く、そのレポートではベースラインの平均より8.6ポイント低下しました。最も良かったカテゴリはLogic Error(ロジックエラー)で33件中20件、すなわち60.6%でした。また、29件のcriticalなコメント、64件のmajorなコメント、50件のminorなコメント、そして差分の外側のコメントはわずか9件を生み出しました。

私は、リスクの高い変更に対する最終のパスをTerraに任せて信頼する前に、トリアージやより安価なレビューの場面でTerraをテストするでしょう。データは、強さではなく慎重さを指し示しています。

SolはFable 5やSonnet 5とどう比べられるか

この比較には1つの但し書きが必要です。これらの数字は、異なるハーネスから来ています。SolとTerraのコーディング実行の結果は、このレビューで新しく示すものです。公開済みのFable 5とSonnet 5の記事は、異なるセットアップと母数で、コードレビューとコーディングタスクの証拠を使っていました。

Fable 5は自律性の高いモデルでした。私たちのFable 5のレビューでは、カバレッジはベースラインに近くとどまり、対応可能なレビュータスク105件中65件で、ベースラインとOpus 4.8の105件中66件に対するものでした。フルレビュータスクの合格は105件中74件に達し、ベースラインの105件中72件をわずかに上回りました。懸念は精度と量でした。対応可能な精度が32.8%、フルの精度が19.4%、そして253件のコメントでした。

そのことが、Fable 5を自律的なコーディングのプロジェクトにとって魅力的にする一方で、デフォルトの本番レビュアーとしては勧めにくくしていました。探索して計画し、構築すると同時に、長く走って展開を難しくするだけのレビューのノイズを生み出しました。

Solは、実行が中心のコーディング作業にとって、より実践的に感じられます。私たちの発見は、上で述べたのと同じ切り分けを指し示しています。タスクがセンスや高レベルの判断から恩恵を受けるときはFableのほうが良いのです。長いリストを渡してすべての項目を処理してほしいときは、Solのほうが良いのです。

Sonnet 5は別の物語を語ります。私たちのSonnet 5のレビューでは、精度はSonnet 4.6の約29%から、おおよそ38%〜40%へと上がりました。落とし穴は、厳密なバグの捕捉でした。ベースラインは約57%を捉え、Sonnet 5は約50%〜51%に着地し、Sonnet 4.6は約63%を捉えたものの、より多くのノイズを生み出しました。

そのことが、コメントの品質や開発者の注意力が主な関心事であるときに、Sonnet 5を良い選択肢にします。Solは、私たちの現在の見立てでは、より見落とし防止を優先します。より多く見つけ、より多くコメントし、その出力の周りにプロダクト側のフィルタリングを必要とします。

ルーティングのガイドは次のようになります。

最先端モデルは、いまや十分に異なって感じられるようになり、1つのデフォルトモデルでは役立つ能力を取りこぼしてしまいます。

Solの代償

Solの主な弱点は、曖昧な判断です。アーキテクチャの議論、プロダクト上のトレードオフ、あるいは擁護しうる経路が複数ある計画については、私は依然としてFableやSonnetを並行して走らせるでしょう。Solは、作業が明確な形を持ったときに最も強くなります。

Solは行き詰まることもあります。私たちの発見では、ある単純な変更が、Solが役に立たない経路にはまり込ませ、8ターンを要しました。そうした場面はGPT-5.5より少なくなりましたが、それでも未だに起こります。数時間や複数日にわたる実行のためには、停止ポイントやチェックポイント、そして2つ目のレビューのスレッドを使いましょう。

レビューへの信頼が、もう1つの代償です。Solはより多くの問題を見つけますが、開発者はプロダクトを生き延びたコメントしか目にしません。あまりに多く投稿する生のモデルは、人々にそれを無視するよう仕向けかねません。レビューのプロダクトは、依然としてランク付けとフィルタリングをし、説明しなければなりません。

Terraには、それ自身のコストの問いがあります。表示価格は低いのですが、長時間のコーディング実行はSolより多くの出力トークンを使いました。大量のジョブのためには、大きなトラフィックを移す前に、自分たちで1回の問題解決にかかるコストのテストを行いましょう。安いトークンが、必ずしも安く解決したタスクを意味するわけではありません。

乗り換えるべきか?

GPT-5.5や以前のOpenAIモデルを使っているなら、コーディングエージェントにはSolへ乗り換えましょう。長時間のコーディング実行は強力で、実際に手を動かしたときのふるまいはスコアと一致します。Solはより長く方向感覚を保ち、より多くの要件に従い、エージェントを役立つものにする華やかでない作業をより多くこなします。

Terraは2つ目のレーンとして使いましょう。範囲の限られたコーディングタスク、最初のパスのレビュー、そしてSolへのエスカレーションが可能なワークフローのためにテストする価値があります。出力の総額には目を配りましょう。

Lunaは最初のパスのレーンとして使いましょう。モデルの切り替えの判断はSolとTerraのために取っておき、速さとコストが主な制約でなくなったら、より大きなタスクを上位へ回しましょう。

FableとSonnetは、あなたの道具箱に残しておきましょう。Fableは、アーキテクチャやより高レベルの計画にとって、なお強力な選択肢であり続けます。Sonnet 5は、よりすっきりしたレビューコメントが欲しいときに、なお魅力的であり続けます。Solは、作業を仕上げる必要があるときに私が手を伸ばすモデルです。

ほとんどのエンジニアリングチームにとって、乗り換えの道筋は明確です。長時間にわたる実装やより難しいレビューのジョブでSolから始め、タスクが範囲の定まったところにTerraを加え、判断により繊細さが求められる部分には、いま使っている最良の計画モデルを残しておきましょう。