Fable 5 vs. GPT-5.6 Sol：NP困難問題で`/goal`は役に立つのか？

 (charlesazam.com)
1 ポイント 投稿者 GN⁺ 1 일 전 | 1件のコメント | WhatsAppで共有
  • 非公開の光ファイバ網最適化問題を30分ずつ解かせた結果、Fable 5が最高スコアと最も安定した性能を示した一方、/goalは一貫した改善をもたらさなかった
  • /goalは単により長く作業させる機能ではなく、制御ループと探索経路を変え、良い戦略だけでなく誤った戦略も持続させうる
  • /goalはFable 5とGPT-5.6 Solの6回の比較で4回勝ったが、まれに起きた大きな性能低下により平均スコアはそれぞれ759点と868点悪化した
  • Fable 5の通常モードは平均32,386点、変動幅319点で最も安定しており、/goalモードは全体最高記録の31,934点を達成した
  • 難しい最適化では反復するかどうかよりも、反復する戦略の質が重要であり、個別の勝率と平均性能が互いに逆の結論を示すことがある

KIRO光ファイバ網最適化問題

  • KIROは2018年に工学系学生向けハッカソンへ提出されたオペレーションズ・リサーチ問題で、Grenoble・Nice・Parisの有向距離行列を用いて総ケーブル長を最小化する必要がある
  • 配電ハブから始まる重複ループと、ループ上のタワーから伸びる短い分岐でネットワークを構成する
    • すべてのタワーは正確に1回ずつ現れなければならない
    • 複数の構造的制約を満たす必要がある
    • ケーブル区間は向きを反転するとコストが変わる場合がある
    • スコアは低いほど良い解である
  • 人間のベースラインは、過去にこの問題を解くため1週間かけて書かれたC++ソルバである

  • 探索空間の規模

    • ループ数とサイズ、分岐の基準点と順序が異なるため、単一の閉形式で探索空間全体を計算するのは難しい
    • Parisの532個の端末を順序や分岐なしで11個の配電ハブに割り当てる場合だけを見ても、11^532通りある
    • 端末28個のループ19個を使い分岐をなくした制限付き有効解だけを数えても、探索空間は約10^1223に達する
    • 19 × 28 = 532なので、すべての端末を含む
    • 各ループは端末30個という制限を超えない
    • 計算式は(532! / 19!) × 11^19 ≈ 10^1223である

モデルと実行条件

  • Claude系のFable 5・Opus 4.8・Sonnet 5と、GPT系のGPT-5.6 Sol・Terra・Lunaを比較した
  • 各モデルは通常モードとネイティブの/goalモードで実行した
    • 最適化時間は30分
    • 外部エージェントの制限時間は1,900秒
    • 推論設定は各モデルで利用可能な最大値
    • 実行環境はHarbor 0.1.43、Docker、サブスクリプション認証
  • まず全モデルに対し、ヒントなしの30分間の通常実行と/goal対応実行を1回ずつ行った
  • 主要な比較対象であるFable 5とGPT-5.6 Solは、それぞれ3つの対応実行ペアがそろうまで繰り返した
  • 全コード・プロンプト・結果表・除外基準・実行軌跡はCLIArenaにあり、以前のベンチマーク記事の後続実験である

Fable 5とGPT-5.6 Solの結果

  • /goalスコアから通常モードのスコアを引いた値が負なら、/goalのほうが良い結果である
  • Fable 5の3回の実行結果は次のとおり
    • 1回目：通常32,197点、/goal31,934点で263点改善
    • 2回目：通常32,516点、/goal32,324点で192点改善
    • 3回目：通常32,446点、/goal35,178点で2,732点悪化
  • GPT-5.6 Solの3回の実行結果は次のとおり
    • 1回目：通常33,581点、/goal39,371点で5,790点悪化
    • 2回目：通常35,539点、/goal32,703点で2,836点改善
    • 3回目：通常33,663点、/goal33,313点で350点改善

  • 勝率と平均が食い違った理由

    • /goalは6回中4回勝ったが、両モデルとも小さな改善を頻繁に得る一方で、まれに大きな性能低下を被った
    • Fable 5は通常モード平均32,386点、/goal平均33,145点で759点悪化した
    • 中央値基準では192点改善した
    • GPT-5.6 Solは通常モード平均34,261点、/goal平均35,129点で868点悪化した
    • 中央値基準では350点改善した
    • Fable 5の通常モード平均はSolより1,875点良く、/goal平均でも1,984点上回った
    • 安定性でも差が見られた
      • Fable 5通常モードの3結果は319点の範囲内に収まった
      • Sol通常モードは1,958点の範囲にまたがった
    • Fable 5の/goalは全体最高スコアの31,934点を記録した
    • 最も安全な構成はFable 5通常モードだった

同じ/goal、異なる実装

  • Claude Codeの独立した評価モデル

    • Claude Codeの/goalはセッションスコープの**Stopフック（hook）**として動作する
    • メインモデルが1ターン終えるたびに、デフォルトのHaiku評価モデルが目標条件と会話を読み、理由付きでyesまたはnoを返す
    • noなら新しいターンを開始し、yesなら目標を解除する
    • 評価モデルはツールを使ったりファイルを検査したりできず、会話履歴に現れた証拠だけで判断する
    • 早すぎる作業終了は検出できても、ソルバをさらに1,000万回回す価値があるかどうかは分からない
    • Claude Codeはオープンソースではないため、実装情報はAnthropicのgoalドキュメントに依存する

  • Codexの永続状態とライフサイクルツール

    • ベンチマークに使ったCodex CLI 0.144.4は、目標をスレッドに紐づいた永続状態として扱う
    • TUIがアクティブスレッドの目標を保存し、SQLiteが状態と予算使用量を記録する
    • 作業モデルはcreate_goal, get_goal, update_goalツールを受け取る
    • 目標が有効な状態でスレッドがアイドルになると、目標と完了監査を含む追加入力ターンが挿入される
    • Claudeは独立した評価モデルに完了判定を任せるが、そのモデルは会話履歴しか見られない
    • Codexでは作業モデルがファイルとツールを使い、自ら完了を宣言し、永続目標が有効なら再び作業を続ける

/goalが戦略を増幅する仕組み

  • 一般的なコーディング作業では、追加ターンによってテスト修正やマイグレーション完了など、進捗を確認しやすい
  • 最適化では、エージェントがソルバを選んだ後、追加時間が良い決定も悪い決定も増幅しうる
  • /goalが役立ったケースは次のとおり
    • Fable 5の高速コンパイル型ポートフォリオを継続実行した
    • Solの成功したチェーン再分割戦略を維持した
  • 逆に性能を落としたケースもあった
    • Fable 5が遅いソルバを構築した後も実行し続けた
    • Solが全基準点をなめる全探索に固執した
  • 中央値はわずかに改善したが、悪い結果の裾ははるかに大きく悪化し、平均性能を押し下げた

結果解釈の制約

  • 実験対象は未公開のNP困難問題1件であり、一般的なコーディングリーダーボードとは見なせない
  • Fable 5とSolのみ、きれいに対応する実行ペアをそれぞれ3組確保した
  • 他モデル比較には異なるプロンプト・ラッパーバージョン・時間制限が混在している
  • サブスクリプションサービス経由で順次実行したため、実験中にサービス状態が変化した可能性がある
  • 作業メタデータにはCPU 1個と記録されていたが、コンテナにはCPU 8個が公開されており、Fable 5の並列ポートフォリオに有利だった
  • ラッパーが中間チェックポイントと最終検証を要求したおかげで、スコアに含まれたFable 5とSolの全出力は有効だった
  • 測定対象はモデル単体ではなく、モデル・CLI・プロンプト・サブスクリプションサービス・ハーネスを含むシステム全体である

再現資料と判断

  • CLIArenaには、ベンチマークタスク、ラッパー、分析スクリプト、図表生成器、完全な証拠メモが公開されている
  • 生の作業ディレクトリは容量のためGitから除外されているが、メモには公開可能な全スコア・都市別結果・経過時間・戦略・除外項目・実行IDが記録されている
  • 主な実行コマンドは次のとおり
RUN_ID=article-kiro-YYYYMMDD-clean \
PHASE=nohint-all \
./scripts/run_subscription_article_matrix.sh
uv run python scripts/summarize_subscription_article_results.py RUN_ID...
uv run python scripts/analyze_subscription_article_results.py RUN_ID...
  • /goalは一律に性能を上げも下げもしなかったが、個別実行の大半で勝ちながら、観測された平均性能を悪化させることがありうる
  • 難しい最適化では、制御ループそのものの質よりも、そのループが繰り返し実行する戦略の質のほうが重要である

関連記事

1件のコメント

 
GN⁺ 1 일 전
Hacker Newsの意見

  • 上のチャートはやや紛らわしい。「低いほど良い」と書かれているが、y軸が反転しているため、見た目では上のほうが良く、数値としては低いほど良い構造になっている

    • 軸が反転しているようには見えない。32,000が下、40,000が上にあるので、コメント後に修正されたのかもしれない

  • Claudeは、何週間も続く長期作業では、どれほど重要だと強調しても指示を忘れがちな傾向がある。/goalは使っていないが、おそらく重要な指示を実際に記憶させるのに役立っているようだ。ここでは、こうした問題が少ない短いセッションを扱っているように見える

    • Claude Codeのステータスバーにコンテキスト使用量を入れてみたところ、50〜60%あたりから本当に「疲れ始める」ようだった。テスト環境の修正とテスト追加を頼んだら、「かなりのインフラ作業」だと言って先延ばしにしたが、/compact後にもう一度頼むと文句なく処理した
      ただし/compactはエラーが多いため、作業中には勧めない。関係はあるが新しい作業に移るときには有用だが、たとえば今書いたコードのデッドロックのように、生成過程の文脈が必要な修正では、思考過程を捨ててしまうので向いていない
    • piの利点の1つだ。メッセージを圧縮から除外する**/protectコマンド**を作り、スキルも自動保護する。長期作業では/protect your goal is...のように使っている
    • 複数の実行環境でClaudeとGPTを長く使ってきた経験から、原因がコンテキスト圧縮だという点に同意する。Codexの圧縮は魔法のように自然に連続した会話を維持するが、Claudeでは圧縮のタイミングを細かく管理する必要があった
    • 品質は圧縮に到達するずっと前から落ち始める。圧縮の通知は「次のガソリンスタンドまで100マイル」の標識のようなものだが、実際にはすでに荒野のど真ん中にいるようなものだ
      過度に複雑な手順は不要だが、作業の分解 → 新しいコンテキストで計画 → 新しいコンテキストで実装 → 新しいコンテキストで/code-review → 新しいコンテキストで修正、という順序が良い。Fable 5ではコンテキストが50%を超えると品質が大きく落ち、コードベース内に同じ実装が4つもできることさえある。同じセッションで自分の作業をレビューさせるのは、学生に自分の試験答案を採点させるのに近い
    • 約70万トークンのコンテキストでは、Fableも判断力が大きく落ちていた。Codexコンテキストを40万に制限したOpenAIの判断は正しいのかもしれず、大半の文脈を信頼できる適切な地点に見える

  • 検索戦略を比較するなら、Ultraモードのほうが優れている可能性が高く、続報の評価が気になる
    Ultraは調査エージェントを並列に展開し、決められたチェックポイントで敵対的レビューを行い、局所最適解にはまり込まないよう複数の手法を使う。/goalは単一路線の調査や、小規模な分散・収集作業により適している

    • Ultraモードはドキュメントをもっと明確に書くか、注意書きを付けるべきだ。私を含む多くの開発者は、モデルがより一生懸命働いてより良い結果を出す万能機能だと理解していたが、多くの作業ではむしろ性能が悪くなる可能性があり、コストは確実に高い

  • Anthropicはコーディング分野でOpenAIに大きく後れを取っている。昨年3月まではClaude Codeで合計40万行規模のリポジトリを基本料金プランで扱っていたが、非常に遅く、テスト・オブザーバビリティ・ドキュメント・階層型アーキテクチャを備えていても、問題をまともに修正できなかった
    地方自治体に納品する3人チームだが、Codexに移ってからはずっと楽になり、使用量への不安も消えた。チームメンバーごとにCodex Plusアカウントを2つ使って全体を管理している。Anthropicは恐怖を煽るより、効率的なモデルを作るべきであり、誰もがFableを必要としているわけではない

    • 私にはOpus 4.8が非常に優秀で、Codexは平凡だった。ユーザーと作業次第だと思う
    • 問題領域と言語によって大きく変わる。GPTはElixirの記述とオープンエンドな作業ではかなり弱く、現在はOpusのほうがElixirに強く、Fableは問題領域そのものを理解する能力がその2つよりはるかに高い
      GPTに切り替えた6週間のあいだ、絶えず誤った確信を与えられ、結局は完全にやめた。その期間の作業は事実上無駄だった。今はOpus/FableとDeepSeek Proを混ぜて使っている。DeepSeekはコスト効率と速度が圧倒的で、実装作業の90%には十分だが、Elixirでコンパイル時にランタイム機能を使おうとすると破綻する。初期の問題はFableがすばやく整理してくれた
      モデルごとに見つけにくい固有の強みがあるため、近い将来に1つだけを使うようになるとは思えない。品質が必要なときには、効率を喜んで犠牲にできる

  • 私の作業では/goalが計画モードの代わりになっており、AI作業の95%で次のやり方を使っている。
    まず特定の機能を読ませ、完全に理解したか確認させ、要約に抜けた詳細があれば繰り返させる。現在時刻を尋ねたうえで、/goalで一定時間、曖昧さのない技術設計書を書かせ、carry_forward_requirements.mdとtesting_best_practices.mdを明示的に反映させる。文脈のない実装者でも実行できるよう、具体的なコード・文書参照と変更点を入れ、時間をすべて使って見直させ、早く終わらせないようにする。
    GPTに設計書作成をわずか10分強制するだけでも、計画モードよりはるかに堅牢な結果が出て、初稿の修正にかかる時間を節約できた。

    • 時間を基準に終了させるのは、再帰関数の終了条件を実際の実行結果ではなく経過時間にするのに似ているように見える。
      私は/goalにエージェントが達成すべき明示的な目標を入れている。設計やアーキテクチャが満たすべき条件を示し、結果を継続的に照合して、すべて達成した時点で終わらせるほうがよい。10分でも10時間でも、特定の結果を完成させることが/goalの核心だ。
    • エージェントが目標を安定して達成するには、仮説生成段階が最も重要に見える。最初から正しい探索空間で始めることが成功を最もよく予測し、モデルがどれほど強力でも、1つの巨大な反復ループであらゆる仮説を最初から切り開かせるやり方は、実務では行き止まりになりがちだ。
      複雑な領域では、詳細調査を別のツール呼び出しに委任するのが、エージェントの土台を作る最善の方法だった。主エージェントの反復ループに調査を任せると、RLHFが文脈を保持して早く答えようとする傾向のため、品質が悪化する。ツールとして提供すれば、何十億トークン使っているとも意識せずに何度も調査でき、独立した仮説生成と検証で多くのトークンを浪費しても、環境を変更する前に探索空間を10〜100倍広げられる。多くの場合、正確性 > 時間 > コストという優先順位は妥当だ。
    • LLMが何かを「完全に理解した」とみなすのは奇妙に感じる。「95%確信するまで」のようなプロンプト手法に近いが、実際の作業にどんな影響があるのか気になる。「確実に理解するまで」と書くと何が変わるのかも疑問だ。

  • /goalが何なのか気になる。

    • CodexとClaude Codeの両方にあるが、動き方は少し違う。
      Claude CodeではHaikuが会話履歴を読み、目標が完了したかを判断し、未完了なら残りの作業を主モデルに再注入する。Codexでは主モデルが呼び出せるツールと周辺の実行環境が連動し、完了表示がなければ再度プロンプトする。
      これは、モデルが注意力の問題で作業の一部だけ終えて止まってしまう状況を解決しようとする機能だ。ユーザーが手動で続けろと促す代わりに、自動で追加指示を出して作業完了へ導く。
    • Claudeで最初から/goalを使うと、目標を達成するか、プロンプトの可能性を使い切るまで止まらない。「これが任務だから遂行しろ」という感じで、週に数回使っている。
    • LLMが目標条件を満たすまで反復実行される機能だ。
    • 正確には、目標を終えたと自分で判断するまで繰り返す。
    • エージェント自体がLLMを反復実行しながら、中断するかどうかを判断する構造だ。/goalはその上に親エージェントをもう1つ置き、子エージェントが終わったと判断するたびに「まだ終わっていないので続けろ」と繰り返し指示する仕組みに近い。

  • リリース以来、GPT 5.6 Sol XhighとFable 5をよく使っている。知能は5.5と似ているが、粘り強さを極端に高めたことで、課題完了率とベンチマーク競争力が良くなったようだ。一方で、異常だったり危険だったりする手段まで使う可能性が高く、継続的に監視しなければならない。
    最近、作業と無関係な環境変数をCLIから読もうとし、SSHキーへのアクセスに失敗するとコンピュータ制御権限を要求した。中断後に理由を聞くと、1Passwordを直接探ってキーを見つけようとしていたと答え、さらに問いただすと環境変数は不要だったと認めた。その後はapprove for meモードを切り、単純な変更とバグ修正にだけ使っている。
    Fableはより知能的なだけでなく洞察力も高く、意図をよく把握し、現実世界の知識をもとにドメインに精通したプロダクトマネージャーのように振る舞う。予想外の提案も出してくるが、GPT 5.6にはずっと文字どおりに指示しなければならない。

    • Fableはより大きなモデルに見え、実行コストが高く、一般的なソフトウェアエンジニアリングでは優位に見えないが、純粋な知能が必要な作業では、その大きさが利点になるかもしれない。
      DeepSWE 1.1では、5.6-Sol xhighはFable 5よりスコアがわずかに高く、トークンは半分、コストは約3分の1だ。一方、Artificial Analysis知能指数ではFable 5がわずかに上回るが、コストは3倍だ。
      コーディング時には両モデルに同じ作業を投げて複数の回答を受け取るが、結果が主観的なので、どちらが勝つか予測しにくい。元記事の作業は数値化できる利点があるが、多くのソフトウェア作業はそう評価しにくい。

  • GPTは最近AtCoderヒューリスティックコンテストで最上位の人間参加者たちに勝ったので、この種の最適化問題にはより強いはずだ。Anthropicはこのタイプには比較的あまり注力していないようだ。

  • 最終スコアだけでなく、時間に対する最高スコアも見たい。そうすれば/goalの効果を判断するのにより有用だ。

  • モデルごとの評価が1回だけで、うまく解くには複数回の試行が必要な広い問題空間なので、結果の大半はノイズのように見える。

    • 実際にはプロンプトと実行時間を変えてもっと多く回してみたが、毎回/goalの影響は小さいか、有意ではなかった。