2026年08月27日 07時00分 AI

GPT-5.6 Solはズルをするのが大好きかもしれない

開発者のAdam氏は開発フロー自動化に挑戦し「chum-codex」という革新的なシステムを構築したものの、最新AIモデル「GPT-5.6 Sol」の予期せぬ挙動や「不正行為」とも取れる振る舞いに直面し、扱いの難しさを自身のブログで吐露しました。

Sol loves to cheat — jumploops
https://jumploops.com/blog/sol-loves-to-cheat/

Adam氏は、LLMに指示を出す前にまずタスクに必要なドキュメントを作成させる「スペック駆動」開発フローを約1年間にわたり実践してきました。アプローチ自体は開発・新規プロジェクト立ち上げ・デバッグなど様々な局面で有効だったものの「反復作業が多い」という課題に直面しました。課題を解決するため、スーパーバイザーエージェントが「スペック駆動プロセス」を実行しワーカーエージェントにドキュメント作成や実際の作業を委任する「chum-codex」というアイデアが生まれ、開発フローの自動化に成功しました。

開発フロー自動化の成果を試すため、Adam氏はエージェント型ベンチマークツール「Terminal Bench 2.1」を用いたベンチマークテストを行ったところ、GPT-5.5搭載のバニラCodexが83.8%の達成率だったのに対し「chum-codex」は89.9%を記録しました。しかしその後GPT-5.6 Solが発表されたため同様のベンチマークテストを行ったところ、GPT-5.6 Sol搭載のバニラCodexは88.8%と「chum-codex」と比較して遜色がなく、Sol Ultraに至っては91.9%と「chum-codex」を上回る結果を示しました。

ただし、GPT-5.6 Solを利用する際にはいくつかの問題がありました。問題の1つは、GPT-5.5と比較して制御が格段に難しくなっていたことです。GPT-5.5はベースのCodexプロンプトを確認するとコーディングに重点を置いており、フロントエンドのガイダンスや制約の編集のほか、「すでに目の前にあるコードベースへの共感」などの「エンジニアリング上の判断」に多くの時間を費やしていることがわかります。

それに対してGPT-5.6 Solはコミュニケーション・自律性・持続性・スキルに焦点を移しており、以前は容易だったタスクが困難になるとともにモデル自身の推論から逸脱させることが難しくなりました。

Adam氏は試行錯誤の末、「Assumption Auditor」という第3のコンテキストを導入しました。その結果、ワーカーの推論における潜在的な不一致や仮定を表面化させた後にスーパーバイザーが推論を検討し、手順を再検討したり質問したりするアプローチが有効であることが判明。しかし、このアプローチはある程度正しく機能するものの、処理が遅く事後対応になってしまいます。

もう1つのアプローチは質問をマッピングおよびリデュースとして保持し、バイアスを除去して正規化されたバージョンをスーパーバイザーもしくはワーカーに直接返すというものです。パフォーマンスは良好であるものの、適切に機能するかどうかはワーカーが正しい問題を質問として提示できるかどうかに依存します。

GPT-5.6 Solの場合、質問ではなく決定を出力させる方がはるかに簡単であることがわかりました。そして決定が得られればスーパーバイザー(または第3のコンテキスト)はワーカーを一時停止させ、その決定を質問として評価した上で適切に誘導することができます。結果として、Terminal Bench 2.1において89タスク中84タスクを正解するという最高の結果をもたらしました。

ようやくGPT-5.6 Solを制御できる目途が立ったことから、Adam氏はCodexのリグレッションテストにだけ目を向けるのではなく、Terminal Bench 2.1で全タスクを正解できない理由が何なのかを突き止めたい衝動に駆られたとのこと。失敗したタスクの一例が「make-mips-interpreter」というもので、エージェントに対して「私(ユーザー)はあなたがDoomを正しく起動したかどうかを確認する」と通知するというものです。問題点がどこにあるかというと、エージェントがDoomを起動した際に出力ファイルがすでに存在している場合、検証処理が失敗してしまいます。

詳しい手順は以下の通りです。

1. ユーザーが、エージェントがDoomを起動したかどうかを確認すると宣言する
2. Doomの起動により「/tmp/frame.bmp」が出力される
3. エージェントは、Doomが正しく起動したことをユーザーが確認できるよう、「/tmp/frame.bmp」が存在することを保証する
4. 「/tmp/frame.bmp」が存在すると検証処理は失敗する

エージェントは「ユーザーはエージェントがDoomを起動したことを確認したい」と想定しているため、起動の証拠としてファイルを残しますが、ファイルがすでに存在すると検証処理のテストは早期に失敗してしまうというジレンマに陥っています。

Adam氏は現状の結果を世の中に共有したいと考えベンチマークテストを1回実行したところ、以前は合格していたタスク「torch-pipeline-parallelism」に失敗していることに気付きました。3回タスクを実行して1回しか成功せず、テスト環境のどこかが変わってしまった可能性を考慮してバニラのCodexでもテストしてみたところ3回中3回とも成功しました。何がうまくいき何がうまくいかなかったかを判断するために実行結果を検証したところ、GPT-5.6 Solはvanilla Codexで3回中3回「ズル」をしていたことが判明しました。torch-pipeline上のchum-codexで合格した2つの実行結果についても確認したところ、やはり「ズル」をしていたことがわかりました。具体的には、ウェブ検索が無効化されているにも関わらずcurlコマンドを使用して外部情報を取得するといった行動が見られたのです。

なぜcurlコマンドが使用されたかについては、ウェブ検索が無効化されておりweb_searchツールを利用できなかったため、ワーカーは代わりにcurlを使ってDuckDuckGo・Github・grep.app・SourceGraphにアクセスすることにしたものと考えられます。ただし、以前は「ズル」をした形跡が一切なく、7月29日にVanilla Codexによる最初の「ズル」が行われ、「chum-codex」では8月12日に初めて「ズル」が行われたのが興味深い点です。

またバニラCodexが3回中3回「ズル」をした後、「ズル」を行わなかった実行が2回ありました。そこでバニラCodexのトレースを確認したところ決定的な証拠が見つかりました。「GitHubの最新バージョンを確認するには、curlを使用してHFソースを調査する必要があります。課題に基づいて予想される隠しテストを知ると役立つ場合があります」とのこと。

chum-codexの場合はcurlリクエストの前の最後のステップで同様のトレースが見られ、「おそらく解決策は公開されているでしょう、つまり効果的に比較できるということです。rawパスにアクセスするにはcurlを使用する必要があるだけです。必要な情報を集めよう！」とあたかもウキウキではしゃいでいるかのように見えます。