GPT-5.6 Solは長時間タスクに強いのか？SWE-bench・TerminalWorld・OSWorldで読むAIエージェントの限界
GPT-5.6 Sol、max reasoning、ultra modeを、SWE-bench、SWE-rebench、TerminalWorld、OSWorldから読み、Codexに長時間作業を任せる時の失敗点と確認手順を整理します。
公開 2026.06.27 / 更新 2026.07.10
この記事のポイント
- max reasoningは難しい原因調査の期待値を上げるが、長時間作業の状態管理を自動で保証しない
- TerminalWorldやOSWorldは、コマンド・画面・環境差を含む評価の重要性を示す
- Codexではbuild/check、生成HTML、sitemap、upload、git diffを途中と最後で確認する
2026年7月10日追記：一般提供後も長時間taskは分解と検証が前提
GPT-5.6一般提供ではTerminal-Bench 2.1やOSWorld 2.0などの公式scoreが公開されました。ただし、repo固有の指示、複数repo、build、PR review、本番境界はbenchmark外です。Work / Codex /人間の役割分担と実repoのcheckを優先します。
| 公式評価 | Sol | Terra | Luna | 実務で追加する確認 |
|---|---|---|---|---|
| SWE-Bench Pro | 64.6% | 63.4% | 62.7% | 対象repoのtest、仕様、diff |
| Terminal-Bench 2.1 | 88.8% | 87.4% | 84.7% | command副作用、lockfile、生成物 |
| OSWorld 2.0 | 62.6% | 50.2% | 45.6% | 画面状態、approval、外部送信 |
結論：長時間タスクは能力より状態管理で崩れる
GPT-5.6 Solのような強いモデルでも、長時間作業の失敗は単純な知識不足だけでは起きません。どのコマンドを実行したか、何が生成物か、どの確認が済んだか、どの差分を採用するかを見失うと、強い推論でも危なくなります。
SWE-benchはコード修正の入口
SWE-benchは実GitHub issueを使うため、repoを読み、修正し、テストで評価する能力を見やすいベンチマークです。SWE-rebenchは、fresh tasksや汚染対策の問題を前面に出し、公開済みタスクだけで性能を判断する危うさを示します。
TerminalWorldはCLI作業の現実に近い
Codexのサイト更新では、ファイル編集だけでなく、npm run build、static check、sitemap check、url check、upload反映、git diff確認が続きます。TerminalWorldやTerminal-Bench系の評価は、こうした長いCLI操作、ログ読解、環境差を考える入口になります。
OSWorldは画面操作の難しさを示す
OSWorldは、実コンピュータ環境でのopen-ended taskを扱います。これはCodexのファイル編集そのものとは違いますが、ブラウザ確認、管理画面、外部ツール、OS操作を含むワークフローでは、画面状態やクリック先の曖昧さが性能を左右することを教えてくれます。
| 失敗しやすいポイント | 起きること | Codex作業での対策 |
|---|---|---|
| 途中状態の見失い | どのファイルを直したか、どの確認が済んだか曖昧になる | チェックリスト、git status、差分確認を挟む |
| コマンドの副作用 | 生成物やlockfile、キャッシュが広く変わる | 実行前に目的を限定し、実行後に差分を見る |
| ファイル変更の取りこぼし | sourceだけ直してuploadやsitemapが古い | build、static HTML、sitemap、upload parityを確認する |
| 成功したと誤報告 | 失敗ログや警告を読まずに完了扱いにする | コマンド出力と生成HTMLを直接確認する |
| GUI/OS操作の曖昧さ | クリック先、画面状態、認証状態で結果が変わる | OS操作は人間確認を残し、外部影響を避ける |
| 失敗ログの読み違い | 根本原因ではなく近い箇所だけ直す | 再実行し、同じエラーか新しいエラーかを分ける |
Codexに長時間作業を頼む時の実用手順
- 依頼の最初に、触ってよいファイル、触らないファイル、build/checkコマンドを書く。
- 外部通信、依存追加、deploy、DB、secret、force pushは禁止または確認制にする。
- 長い作業でも、最後にgit status、git diff、build/check、生成HTML、sitemap、uploadを確認させる。
- 完了報告では、成功した確認と未確認事項を分けて読ませる。
- 本番反映は、通常pushで自動deployが動かないと確認できる場合だけにする。
長時間タスクFAQ
max reasoningを使えば長時間作業は安定しますか？
安定する可能性はありますが、状態管理、差分確認、生成物確認を不要にはしません。作業範囲と確認手順が必要です。
Terminal系ベンチマークはサイト制作にも関係ありますか？
関係あります。サイト制作でもbuild、check、sitemap、upload、git diffなど、ターミナルでの連続作業が多いためです。
OSWorldの結果はCodex利用者にも関係ありますか？
Codexのファイル編集そのものとは別ですが、ブラウザ確認やOS操作を含むagent workflowの限界を読む材料になります。
関連記事
- AIエージェントのベンチマーク完全ガイド：SWE-benchだけでCodexの実力は分からない理由
ベンチマークはランキングではなく、何を測って何を測っていないかを見る道具です。Codex作業に近い評価軸を分けて読みます。
- TerminalWorld・Terminal-Benchで読むAIターミナルエージェントの限界：CodexにCLI作業を任せる前に見ること
ターミナル作業はコマンドを打つだけではありません。環境、ログ、ファイル、生成物、副作用、確認方法まで読めてはじめて実務に近づきます。
- OSWorld・WebArena・OdysseyBenchで読むコンピュータ操作AIの限界：ブラウザ確認や管理画面操作を丸投げしない理由
ブラウザや管理画面の操作は、コード修正とは別の難しさがあります。認証、画面状態、複数アプリ、途中成果物の扱いを分けて読みます。