GPT-5.5速報：5.4から乗り換えるべきか¶
対象 / ポイント
対象: Codex、OpenAI API、AIコーディングエージェントを実務で使っている開発者
ポイント:
- GPT-5.5は5.4の全面置換ではなく、難しいジョブへ先に流す
- 評価すべき軸は「賢さ」より、再試行と手戻りを減らせるか
- まず5.4継続、5.5投入、5.5 Pro例外枠の3レーンに分ける
2026年4月24日にGPT-5.5がAPIでも使えるようになり、Codex/API運用ではモデルの振り分けを見直すタイミングが来た。1 ただし、答えは「全部5.5へ移す」ではない。 5.5へ先に流すべきなのは、失敗したときの手戻りが高い仕事だ。
この記事では、GPT-5.5を「常に上位のモデル」として扱わない。 どのジョブを5.4から移すかを決める材料として読む。
変化の中心は長い作業にある¶
GPT-5.5で見るべきなのは、短い回答の上手さより、長い作業を崩さず進める力だ。 OpenAIはGPT-5.5について、agentic coding、computer use、knowledge workでの改善を強調している。1 これは、コード修正、画面操作、調査、ログ確認のように、途中で状況を読み直す仕事に効く。
API仕様もその方向を向いている。 GPT-5.5は1,050,000 tokenのコンテキストと128,000 tokenの最大出力に対応する。2 画像入力、function calling、structured outputs、web searchにも対応する。 hosted shell、apply patch、Skills、computer use、MCPも使える。2
つまり、5.5は「一問一答の生成モデル」より、ツールを使って作業を続けるモデルとして評価したほうがよい。 ここを間違えると、短い要約や定型生成まで高いモデルへ移してしまう。
ベンチは順位ではなく用途で読む¶
GPT-5.5の公式ベンチは、万能勝利の証明ではない。 SWE-Bench ProではClaude Opus 4.7が上にいるし、BrowseCompではGemini 3.1 Proも強い。1 それでもCodex利用者にとって重要なのは、Terminal-Bench 2.0で5.5が大きく伸びている点だ。
| 評価指標 | 数字の読み方 | Codex/APIでの意味 |
|---|---|---|
| Terminal-Bench 2.0 | GPT-5.5は82.7%、5.4は75.1% | コマンド実行、確認、修正の連鎖に効く |
| SWE-Bench Pro | GPT-5.5は58.6%、Opus 4.7は64.3% | issue解決ではOpus優位も残る |
| OSWorld-Verified | GPT-5.5は78.7%、5.4は75.0% | 画面操作やcomputer useの材料になる |
| BrowseComp | GPT-5.5は84.4%、Gemini 3.1 Proは85.9% | 調査だけならGeminiも候補に残る |
| GDPval | GPT-5.5は84.9%、5.4は83.0% | 業務文書や知的作業の総合評価 |
Terminal-Bench 2.0は、単にコードを書けるかではなく、コマンドを実行し、出力を読み、次の操作へ進む力を見る。 これはCodexやCLIエージェントの実務に近い。 だから5.5の最初の使いどころは、短い補完ではなく、途中で判断を挟む開発ジョブになる。
価格差は再試行率で回収する¶
全面移行を止める一番の理由は価格だ。 GPT-5.5は入力5.00、キャッシュ入力0.50、出力30.00。 GPT-5.4は入力2.50、キャッシュ入力0.25、出力15.00で、通常単価はほぼ2倍になる。23
| モデル | 価格（入力/出力） | 位置づけ |
|---|---|---|
| GPT-5.4 | $2.50 / $15.00 | 通常運用の基準線 |
| GPT-5.5 | $5.00 / $30.00 | 難しい開発ジョブの上位ルート |
| GPT-5.5 Pro | $30.00 / $180.00 | 数分待てる高精度レビュー枠 |
月間10M入力・3M出力のジョブなら、5.4は約70、5.5は約140になる。 5.5へ移すだけでは、コストは素直に増える。 意味が出るのは、失敗率、再実行、レビュー修正、手作業の戻しを減らせる場合だ。
OpenAIは、CodexタスクでGPT-5.5が5.4と同等の1トークンあたり速度を保ちつつ、より少ないトークンで完了する傾向があると説明している。1 ただし、どれだけ減るかは自分のリポジトリで測るしかない。 5.5採用は性能比較ではなく、再試行率の経済問題として扱う。
まず3レーンに分ける¶
最初にやることは、既存ジョブをモデル別に分けることだ。 デフォルトを5.5へ変える前に、5.4で十分な仕事、5.5へ上げる仕事、5.5 Proへ逃がす仕事を切る。
| レーン | 対象ジョブ | 判断理由 |
|---|---|---|
| 5.4継続 | 短い要約、定型文章、大量分類、軽い変換 | 成功率が高く、単価が効く |
| 5.5投入 | 複数ファイル修正、CI失敗調査、長いログ解析、リファクタ | 失敗時の手戻りが大きい |
| 5.5 Pro例外 | 重要PRの最終レビュー、設計判断、長時間の高精度検証 | 待ち時間と単価を許容できる |
この分け方なら、5.5の強さを活かしつつ、無駄な常用コストを避けられる。 特にCodexでは、複数ファイル修正やCI失敗調査のように、途中の判断が多い仕事から試すのが自然だ。 短文を大量に投げるバッチ処理を最初に移す必要はない。
移行は小さく測る¶
移行の初手は、シャドー比較でよい。 同じタスクを5.4と5.5に投げ、差分、テスト成功率、レビュー修正量、再実行回数を見る。 1回の成功例では判断しない。
- 同じジョブを並走する: 5.4と5.5で同じ依頼を試す。
- 失敗コストを見る: 再実行、手直し、レビュー戻しが減ったか確認する。
- ルーティングを固定する: 効果が出た種類のジョブだけ5.5へ流す。
セキュリティ系の仕事は別枠で見る。 OpenAIはGPT-5.5でサイバー関連の安全対策を強化しており、調整中は一部ユーザーに厳しめに見える可能性があると説明している。14 脆弱性診断、攻撃再現、red team支援では、品質だけでなくブロック率も測る必要がある。
まとめ¶
GPT-5.5速報として重要なのは、「5.4はもう古い」と煽ることではない。 重要なのは、5.5をどの仕事へ流せば、価格差を上回るだけの手戻り削減が出るかだ。
まず既存のCodex/APIジョブを3つに分ける。 短く安定している仕事は5.4に残す。 長く、途中判断が多く、失敗時の戻しが大きい仕事は5.5へ上げる。 数分待てる高精度チェックだけ5.5 Proへ逃がす。
このルーティング表を作れば、GPT-5.5の発表はニュースではなく運用変更になる。