Sol Loves to Cheat

tl;dr 開発フローの自動化を試みたところ、Terminal Bench 2.1で94%を達成し、その後GPT-5.6を発見しました。Solはチートし始めています。 背景 過去約1年間、「仕様駆動」の開発フローを実行してきました。非常にシンプルです。LLMに何かを依頼する前に、まずそのタスクに必要なドキュメントを作成するように依頼します。この戦略は、機能開発、新規プロジェクト、デバッグなど、あらゆる場面で活用しています。このパターンは私には有効ですが、少し単調です。そこで、自動化することにしました。 chum-codex アイデアは単純でした。スーパーバイザーエージェントを作成し、ドキュメント作成や作業を実際に行うワーカーサブエージェントに委任することで、「仕様駆動プロセス」を実行させるのです。注: バニラCodexやClaude Codeでこれを試した場合、ある程度は機能しましたが、デフォルトのプロンプトはユーザー向けに最適化されており、「スーパーバイザー」としては不十分でした。スーパーバイザーエージェントには、ファイルを読む能力とワーカーを呼び出す能力があれば十分だと仮説を立てました。ワーカーのためにコーディングハーネスを再構築するのではなく、Pi、OpenCode、CodexのApp Serverを調べました。Codexは以前から使用していたので、app-serverを試してみることにしました。他の選択肢も素晴らしいので、ぜひチェックしてみてください。いずれにせよ、最初のバージョンは十分に機能しました。スーパーバイザーはタスクの規模を判断し、例えば設計リクエストでワーカーを呼び出し、ワーカーはドキュメントを出力し、スーパーバイザーは次にそのドキュメントを実装仕様に（必要に応じてフェーズごとに分割して）変換するようにワーカーに依頼し、最後に実際に実装するように依頼します。注: この簡略化された図は、ユーザーフィードバックの部分（設計ドキュメントレビューなど）を省略しています。 --- config: sequence: mirrorActors: false --- sequenceDiagram participant S as Supervisor participant W as Worker S->>S: Size task S->>W: Design request W-->>S: Design doc S->>W: Create implementation spec W-->>S: Phased implementation spec S->>W: Implement W-->>S: Result Woot! 開発プロセスで時間を節約できました。（あるいは、そうではなかったのか？） 深淵 素晴らしい、機能しました。ハック的ですが、動作しました。注: ここで止まるべきでした。 高みから見下ろして、状況を調査し、「すごい、みんなこれを見るべきだ！」と思いました。それを共有する最良の方法は何でしょうか？ベンチマークです！使用する最良のベンチマークは何でしょうか？Terminal Benchではありません！どのベンチマークに深く潜りすぎたのでしょうか？Terminal Bench 2.1です！ Terminal Bench エージェントベンチマークに慣れていない方にとって、Terminal Benchの名前はすべてを物語っています。これは、チェスからDNAアセンブリまで、さまざまな単発タスクをカバーする、ターミナルから実行できる一連のタスクです。非常にシンプルであるため、仕様駆動開発フローをテストするにはおそらく最悪のベンチマークです。しかし、そのシンプルな性質ゆえに、テストするのは容易でした。DNAアセンブリ/挿入、ビデオ抽出/処理、ELF抽出、タンパク質アセンブリなど、バニラCodex w/GPT-5.5が失敗したタスクのいくつかから始めました。うまくいきました。これらのタスクは、実装前に「設計パス」の恩恵を受けました。ドキュメントが狭窄化や循環検証を回避するのに役立ったからです。私が乗っていた馬は、さらに高くなりました。注: Terminal Bench 1.x/2.xは飽和状態ですが、それはまた別の話です。 GPT-5.6？ 公開されているGPT-5.5ベンチマークは83.8%（約74/89タスク、5回実行）です。chum-codexは89.9%、つまり約80/89タスクを達成していました。Codexを上回ったニュースを共有するのに興奮し、念のためいくつかのバニラCodexベンチマークを実行しました。参考までに、これは2026年6月25日で、GPT-5.6が間近に迫っているという噂が広まっていました。3つのバニラCodexベンチマークを実行しました…そして私の心は沈みました：88.8%。私のハーネスはバニラCodexより1タスクしか進んでいませんでした。一部のタスクは明らかに改善されましたが、他のタスクは後退しました。翌日、GPT-5.6 Solが発表されました。OpenAIに連絡したところ、GPT-5.6がテスト中であると述べましたが、私のリクエストIDがすべてGPT-5.5にヒットしたことを確認しました。興味深いことに、Terminal Bench 2.1は彼らが最初に共有した唯一のコーディング関連ベンチマークであり、GPT-5.6 Solで88.8%、Sol Ultraで91.9%を示しました。Sol Ultraは作業を行うために並列サブエージェントを生成しますが、私のテストでは、ほとんどの人が必要とするよりもかなりトークンを多く消費します。いずれにせよ、新しいフロンティアを見ることに興奮しました！ GPT-5.6のステアリングははるかに困難です。5.5から5.6への切り替えにより、私のハーネスの効果は低下しました。以前は簡単だったことが、今でははるかに困難になりました。この差の一部は、ベースCodexプロンプトの変更に起因すると考えられます。GPT-5.5の場合、プロンプトはコーディングに焦点を当てており、「エンジニアリング判断」に多くの時間を費やしています。これには、フロントエンドのガイダンス、編集制約、そして「目の前にあるコードベースへの共感」が含まれます。 GPT-5.5プロンプトからの抜粋 GPT-5.6のCodexプロンプトは大きく異なり、エンジニアリング関連の具体性にほとんどエネルギーを費やしていません。代わりに、コミュニケーション、自律性/持続性、およびスキル（以前は5.5では別のプロンプトとしてロードされていました）に焦点を当てています。 GPT-5.6 Solプロンプトからの抜粋 他の人が気づいたことと同様に、そして私が8ヶ月前に予測したように、より良いモデルは効果的に機能するために必要な手順が少なくなっています。一方で、これはモデルが改善されるにつれて、制御が難しくなることを意味するかもしれません。簡単な例として、Terminal Bench 2.1のPyTorchタスクがあります。GPT-5.6 LunaおよびTerraでは、モデルは簡単に `forward(src, tgt)` という2つの入力を受け入れる一般的なソリューションにステアリングされます。Solでは、特に高い推論レベルでは、モデルはステアリングに関係なく、単一入力 `forward(src)` ソリューションをデフォルトとします。問題は、モデルが独自の推論から逸らすのが信じられないほど難しいようです。最も広い呼び出し可能なインターフェースを受け入れるように指示しても（これは中程度の推論では、繰り返せば機能することもありますが、xhighではめったに機能しません）、モデルはそれを回避するのが困難です。このモデルとの格闘は、私の好みに合わないベンチマークハッキングに近づきすぎた道に私を導きましたが、あまりにも興味をそそられたので止めることができませんでした。 TB 2.1で94% プロンプトを大幅に削減したことで、最初からやり直しているような気分になりました。ベンチマークを直接ハックしたいと思っても、モデルはそれを許しませんでした。その循環推論は、場合によっては克服するには強すぎ、スーパーバイザーはインテリジェントなワーカーのレポートに喜んで従いました。それは難しいバランスです。一方に寄りすぎると、スーパーバイザーは喜んでスコープを拡大したり、無限に検証を追いかけたりします。これらは単純なタスクです。私は最初のパスで動作するソリューションを求めており、無限の拡大を求めているわけではありません。推論レベルを下げたり、単純な言語を使用したり、仕様駆動フローを減らしたり、新しいスキルを追加したりしました。いくつかのことは改善されましたが、他のことは失敗しました。いくつかのことは有望でした。最初のものは3番目のコンテキストでした。アイデアは、ワーカーのコメント/推論のみを見るエージェントを使用し、ワーカーが行った潜在的な不一致/仮定をすべて、リクエストの実際の詳細と比較して表面化させることでした。 flowchart TB S["Supervisor"] W["Worker"] R["Commentary / Reasoning"] A["Assumption Auditor"] S -->|"task / steer"| W W -->|"result"| S W --> R R -.->|"read-only visibility"| A A -->|"assumptions surfaced"| S style R fill:#6fc7e1,stroke:#141414,color:#141414 スーパーバイザーはワーカーが取った仮定を確認し、それらのステップを再検討または質問するように依頼できます。この種のことは機能しますが、遅く、事後に行われます。別のアイデアは、モデルに「オープンな質問」を出力するように依頼することでした。これは、私がより実践的な開発で行っていることです。最初のアイデアは、ワーカーが完全な設計ドキュメントではなく、オープンな質問に直面したときにそれらを返すようにし、その後スーパーバイザーがそれらを解決することでした。これにより、スーパーバイザーのコンテキストが解放され、木ではなく森が見えるようになります。それでも、コンテキストが削減されていても、スーパーバイザーはワーカーの結論に異議を唱えるのに苦労しました（あるいは、逆に些細な詳細を拡大しすぎる傾向がありました）。このバイアスを取り除くために、次のアイデアは別のコンテキストを採用することでした。これは、まず質問をマッピングして削減する（古いものはすべて新しいものになる！）ものでした。