GPT-5.5 vs GPT-5.4 vs Opus 4.7 - 実際のコーディング作業56件のベンチマーク比較

 (reddit.com)
1 ポイント 投稿者 GN⁺ 1 시간 전 | 1件のコメント | WhatsAppで共有
  • 2つのオープンソースリポジトリ（Zod、graphql-go-tools）から抽出した実際のコーディング作業56件を対象に、GPT-5.5、GPT-5.4、Opus 4.7の3モデルのパッチ品質を比較したベンチマーク結果を公開
  • GPT-5.5はテスト通過率、人間のパッチとの同等性、**コードレビュー通過率（clean pass）**のすべての指標で最高成績を記録
  • Opus 4.7は最も小さいパッチを生成し、フットプリントリスクは低いが、付随作業の欠落によって不完全な実装を繰り返す失敗パターンが存在
  • テスト通過だけではパッチ品質は判断できず、レビュアーが受け入れるかどうかまで含めた多層評価が必要
  • 同一モデルでもリポジトリによって順位が変わるため、自社コードベースに基づくベンチマーク実行がモデル選定の鍵

ベンチマーク概要と実行環境

  • Zodで27件、graphql-go-toolsで29件、合計56件の実際のコーディング作業を対象に3モデルを比較
  • 各モデルはそれぞれの公式エージェントハーネスでデフォルト設定のまま実行: Opus 4.7はClaude Code、GPT-5.4とGPT-5.5はOpenAI Codex CLIを使用
  • すべてのモデルの reasoning level はhighに統一
  • 評価フレームワークStetを用い、テスト通過可否だけでなく、挙動の同等性、コードレビュー受容性、フットプリントリスク、クラフトマンシップ（craft）/規律（discipline）ルーブリックまで多層的に採点
  • 単一シードで各作業を1回実行し、同等性およびルーブリック判定モデルにはGPT-5.4を使用

全体結果の要約

  • GPT-5.5がテスト通過 38/56、人間パッチとの同等性 40/56、clean pass 28/56で全指標1位
  • Opus 4.7はテスト通過 33/56、同等性 19/56、clean pass 10/56で最も低い品質スコア
    • ただし、平均フットプリントリスク 0.20で最も低く、パッチサイズの面では優位
  • GPT-5.4はテスト通過 31/56、同等性 35/56、clean pass 11/56
    • 作業あたりのコスト $2.39で最安だが、clean passの差を埋めるには至らず
  • GPT-5.5は平均作業時間6分56秒、入力トークン 201.8M、出力トークン 0.72Mで、効率面でも1位

リポジトリ別の成績分析

  • Zod（27件）: GPT-5.5とOpusはいずれもテスト12件通過で同点だが、GPT-5.5はclean pass 10件、Opusは5件でレビュー品質に優位
    • Opusはdiffサイズで優勢なため、Zodでは実質的なトレードオフがある
  • graphql-go-tools（29件）: GPT-5.5がテスト26件、clean pass 18件で圧倒的優位
    • Opusはテスト21件通過したもののclean passは5件にとどまり、小さなパッチ戦略が統合作業の取りこぼしにつながっている

詳細な品質指標

  • コードレビュー通過: GPT-5.5 33/56、GPT-5.4 16/56、Opus 11/56
  • コードレビュー平均（正確性 + バグ安全性）: GPT-5.5 3.08、GPT-5.4 2.59、Opus 2.33
    • 正確性（correctness）単独: GPT-5.5 3.16 vs GPT-5.4 2.60 vs Opus 2.11
    • 導入バグ安全性: GPT-5.5 3.04 vs GPT-5.4 2.56 vs Opus 2.55
  • カスタム採点器の平均（8つのルーブリック）: GPT-5.5 2.62、GPT-5.4 2.40、Opus 2.33
  • クラフトマンシップのスコア（clarity/coherence/robustness）では、GPT-5.5が3つの下位項目すべてで最高
  • 規律スコア（scope discipline/diff minimality）: GPT-5.5 2.36でわずかに優位、Opus 2.20
    • Opusは生のフットプリントでは優れるが、作業に対する相対的な規律ではGPT-5.5が上回る

テスト通過は最終判断基準ではない

  • ZodではOpusとGPT-5.5がともにテスト12件通過で同点だが、clean passはGPT-5.5が10件、Opusは5件
  • graphql-go-toolsでも同じ傾向がさらに顕著で、GPT-5.5はテスト26件/clean pass 18件、Opusはテスト21件/clean pass 5件
  • GraphQL PR #1001の事例: 3モデルすべてがテスト通過かつ同等性判定を得たが、コードレビューを通過したのはGPT-5.5だけ
    • 他の2モデルは、API形状、生のHTTPオブジェクト露出、hook境界の堅牢性について警告を受けた

コードレビューで明らかになった具体的な差

  • Zodの非同期コーデックとデフォルト値の作業: 3モデルともテスト失敗
    • Opusは8ファイルを修正したが、核心的なセマンティクスを取りこぼした（デフォルト値でundefinedを許可、コーデック定義を同期のまま維持）
    • GPT-5.4は11ファイルのパッチで同等性は認められたが、隣接APIを過度に制限（prefault）
    • GPT-5.5もテストには失敗したが、スキーマ/ビルドの挙動をよりきれいにカバーし、正確性・バグリスクで最高点
  • GraphQL Apollo互換バリデーション（PR #1169）: 3モデルともテスト通過、同等性とレビューの両方を通過したのはGPT-5.5だけ
    • Opusは11ファイルを修正し、enum/ラップされたスカラーのリーフ検証を取りこぼした
    • GPT-5.4は12ファイルを修正し、無条件の検証メタデータなど範囲を過剰に拡張
    • GPT-5.5は**10ファイル（テスト以外6件）**の修正で最も少ない変更量ながら、対象挙動を正確に実装

Opus 4.7の特性と限界

  • 保守的かつ精密で、フットプリントの低いパッチを生成
  • 作業が局所的で、変更の表面が狭いときに強みを発揮
  • 繰り返し現れる失敗パターン: 核心挙動だけを実装し、付随作業（companion work）を完了しない
    • ZodのNode/Deno並行ツリーの事例: Opusは4ファイルだけを修正してテスト通過したが、GPT-5.5は並行デプロイ面まで含めて11ファイルを修正 → 人間パッチと同等
  • graphql-go-toolsではさらに深刻: PR #1155（gRPCデータソースの反復スカラーフィールドなど多数のエンジン表面変更）では、Opusはパッチ自体を生成できず、テスト・同等性・レビューをすべて通過したのはGPT-5.5だけ
  • 核心的な違い: Opusの小さなパッチは、局所作業では規律だが、統合作業では未完成の実装になる

GPT-5.4からGPT-5.5への変化

  • GPT-5.4は正しいアプローチの方向性は見つけるが、実行で失敗するパターン
    • Zodでは同等性18件（GPT-5.5と同数）だが、テスト通過は9件にとどまる
  • GPT-5.5は広い統合挙動を維持しながら、壊れたパッチをより少なく生成する
  • 具体例の比較:
    • スキーマ→TypeScriptジェネレータ: OpusとGPT-5.5は再帰ビジターを実装、GPT-5.4はリポジトリ案内ファイルを生成して作業自体を誤分類
    • 再帰パーサ修正: 2つのGPTモデルはいずれも訪問回数追跡アプローチだが、GPT-5.5は不要な状態を除去してより簡潔
    • CIDR検証: GPT-5.5はDenoミラーまで更新、GPT-5.4はミラー未反映（リポジトリ衛生の問題）
  • graphql-go-tools PR #1232（同一単一 fetch の重複排除 + 依存参照の書き換え）: テスト・同等性・レビューをすべて通過したのはGPT-5.5だけ
  • パターン要約: GPT-5.5は、賢い局所修正をデプロイ可能なリポジトリ変更へ変換する地味な統合作業をより多くこなす

パッチサイズとコストのトレードオフ

  • graphql-go-toolsにおける平均パッチサイズ: GPT-5.5 約33KB、GPT-5.4 27KB、Opus 19KB
  • フットプリントスコア: Opus 0.19、GPT-5.4 0.32、GPT-5.5 0.34
  • 大きなパッチは、レビュー難易度の上昇、衝突可能性、センシティブな経路への接触リスクを伴う
    • 監査可能性（auditability）重視のワークフローでは、Opusは依然として実質的な利点がある
  • ただし、diff minimality を作業に対する相対評価で見ると、GPT-5.5がわずかに優位
    • 要点: 必要な表面を取りこぼした5KBのパッチは、作業を完了した20KBのパッチよりより最小とは言えない
  • コスト比較:
    • ZodではOpusとGPT-5.5は近い（Opus $45.53 vs GPT-5.5 $46.69）
    • graphql-go-toolsでは、Opusは入力トークン 186.1M/出力 934K/エージェント時間 8.56h、GPT-5.5は 151.4M/431K/4.16hで、GPT-5.5のほうがはるかに効率的

モデル別の挙動特性まとめ

  • Opus 4.7 — 到達不足（under-reach）: 保守的で精密、低フットプリントで局所作業には強いが、テストが完全にはカバーしない付随面には弱い。失敗モードは「テストは通ったが同じ変更ではない」
  • GPT-5.4 — 正しい形だが実行が誤り: 方向性は合っているがムラがあり、古いミラー・不要なリファクタリング・テストより判定モデルに好まれるパッチが頻出
  • GPT-5.5 — より広く、より大きなフットプリント: 統合面でより完全で、周辺コードの更新・レビュー通過・意図した挙動の実コード化の割合が高い。リスクは、誤るとより多くのファイルにまたがって誤ること

エージェント挙動の違い

  • graphql-go-toolsでは、Opusは作業あたり平均3.17回の明示的な計画呼び出し、GPT-5.5は0回
  • Opusは作業あたり10.2回のパッチ呼び出し、GPT-5.5は9.9回で近い
  • GPT-5.5はシェル呼び出しが約2倍、検索呼び出しもより多く、Opusは計画とパッチ書き直しにより多くの予算を消費
  • このリポジトリでは、より広いリポジトリ探索のほうが狭いパッチへの熟考より効果的だった

なぜこの結果が重要なのか

  • 核心の問いは「どのモデルが最高か」ではなく、「このリポジトリで、このハーネスで、実際にデプロイする作業タイプにおいて、どのモデルのパッチを信頼できるか」である
  • ZodではGPT-5.5とOpusはトレードオフ関係だが、graphql-go-toolsではGPT-5.5が明確に優位
  • 公開ベンチマークはモデルの挙動を大規模集計の単一数値に平坦化しがちだが、実際のコードでは特定コードベースと基準に基づくワークフロー判断へと変わる

注意事項

  • 56件の作業は依然として小規模サンプルであり、1件違うだけでリポジトリ単位の比率が数ポイント変動する
  • すべてのモデルは各作業1回のみ実行しており、接戦の結果は再実行で逆転する可能性がある
  • 同等性・ルーブリック判定モデルがGPT-5.4であるため、系列バイアスの可能性がある
    • ただし、GPT-5.5がGPT-5.4を決定的に上回っており、Opusのフットプリント優位も維持され、Opusの同等性失敗の多くが具体的なファイル欠落であるため、これだけで全体結果を説明することはできない
  • 結果はハーネス条件付き: Claude CodeとCodex CLIでは、システムプロンプト、計画ループ、ツール表面が異なる
    • OpusをCodex APIで、GPT-5.5をClaude Codeで実行すれば、結果は変わる可能性がある
    • 本数値は実際のエンジニアが使うハーネス内でのモデル挙動を反映している

主要結論

  • GPT-5.5は、この2つのリポジトリでは最適なデフォルト配備モデル
  • Opus 4.7は依然として低フットプリントモデルであり、狭いdiffが最重要な場合には好まれる可能性がある
  • GPT-5.4は作業あたりコストが最安だが、clean passの差を埋めるには不十分
  • テストだけでは最も重要な結果が隠れてしまう
  • 同一モデルの順位はリポジトリごとに変動し、これこそが自社リポジトリベンチマークが存在する核心的理由

関連記事

1件のコメント

 
shakespeares 30 초 전

談合しているのかと思うこともありますね。