Fable5とGPT-5.6のNP困難問題比較

TL;DR: クロードの Fable 5 と GPT-5.6 Sol に、未発表の NP ハード最適化問題を /goal モードあり・なしでそれぞれ解かせました。Fable 5 は圧倒的な強さを見せましたが、/goal が劇的な変化をもたらすわけではありません。

背景: これはハッカソンで学生向けに出題されたオペレーションズ・リサーチの問題です。私は数年前にこの問題を C++ で解くために 1 週間ほど費やしており、人間としての基準値を持っています。

Fable 5 はこのベンチマークにおいて圧倒的な強さを見せました。全体として最良の解を生成し、その一貫性は私がこれまでこの問題で見たどのモデルとも比較になりません。これは純粋な知能の賜物です。驚異的です。

もう一つの結果は、/goal が単なる「もっと頑張れ」という汎用的なスイッチではないということです。それは制御ループと探索経路そのものを変化させます。時にはより良い解の領域に到達できることもあれば、逆に悪いアイデアが育つ時間を無駄にしてしまうこともあります。

すべてのコード、プロンプト、結果表、除外条件、そして軌跡に関するメモは CLIArena にあります。これは私のこのベンチマークに関する最初の論文の続編です。

問題の説明

KIRO は、私が 2018 年に工学学生だった頃に取り組んだファイバーネットワーク設計の問題です。グラノーブル、ニース、パリの有向距離行列が与えられたとき、ソルバーは複数の構造的制約を守りつつ、ループと短いチェーンを使って配分ポイントとターミナルを接続する必要があります。目標となるのはケーブルの総延長で、値が小さいほど優れています。

有効なネットワークは、配分ハブを根とする冗長なループと、そのループ上のタワーから伸びる短い枝で構成されます。各タワーはちょうど 1 回だけ現れなければならず、ケーブルセグメントの向きを変えることでコストが変化します。

探索空間はどれほど大きいのか？

解が使用するループの数やサイズ、枝の固定位置と順序に自由度があるため、単一の閉じた式で総数を数えることはできません。ただし、パリに関するデータだけで有用な下限値を導き出すことができます。

順序や枝の存在を無視し、532 個のターミナルそれぞれを 11 箇所の配分ハブのいずれかに割り当てるだけの場合でも、11^532 通りの組み合わせが存在します。

より厳しい下限値は、意図的に制限された有効解の特定のグループから導き出されます。具体的には、分岐を持たない 28 個のターミナルで構成されるループがちょうど 19 個あるケースです。これにより 19 x 28 = 532 となり、すべての 532 個のターミナルをカバーしつつ、ループごとの 30 個という上限も守られます。

この 532 個のターミナルに順序をつけ、それを 19 の連続するグループに分けます。ただし、ループの集合には順序がないため 19! で割ります。さらに、各ループに対して 11 個あるハブから一つを選ぶ組み合わせも考慮します。

(532! / 19!) x 11^19 ~= 10^1223

検証内容

主な実験はあえて範囲を狭く設定しました。

結果

旗艦モデルのペア比較に集中する前に、スweep 対象となったすべてのモデルについて、ヒントなしで 30 分間実行したペアを 1 つずつ用意しました。Fable と Sol のグラフには、複製されたヘッドラインセットから Pair 1 を使用しています。残りの 4 つのモデルはそれぞれ 1 つずつのペアを使用しています。

その後、Fable 5 と Sol の比較を繰り返して、それぞれについてマッチングされた実行結果を 3 つずつ集めました。

「Negative」は、/goal の方が優れていたことを示します。6 回の試行のうち 4 回で /goal が勝利したため、勝率だけでこの機能が有用であるように見えますが、平均値がもう一方の半分の物語を語っています。

両モデルは通常、わずかな利益を得る一方で、稀に大きな性能低下を被ることがあります。そのため /goal コマンドは多くのランで勝利しましたが、平均スコアについては両モデルとも悪化しました。

Fable は明らかに Sol よりも強力でした。Fable の通常設定の平均点は Sol を 1,875 ポイント上回り、/goal 使用時の平均点でも 1,984 ポイント差をつけました。より重要なのは、Fable の通常設定がわずか 319 ポイントの狭い範囲に収まったのに対し、Sol は 1,958 ポイントにも及ぶ広がりを見せたことです。Fable が /goal を使用した際、最も高いクリーンスコアである 31,934 を記録しました。一方、通常設定が最も安定した構成と言えます。

/goal コマンドの詳細分析

同じコマンドが実装する2つの異なるシステム

Claude Code と Codex はどちらも /goal を公開していますが、その実装は根本的に異なります。

Claude Code: 独立した評価モデル

Claude Code では、/goal はセッションスコープの停止フックとして実装されています。メインモデルの各ターン終了後、デフォルトでは Haiku という小型の評価モデルが条件と会話履歴を読み込み、「Yes」または「No」を理由付きで返します。「No」の場合は次のターンへ進み、「Yes」の場合はゴール達成としてクリアされます。

この評価モデルはツールを使用できず、ファイルも参照できません。トランスクリプト上に現れた証拠のみに基づいて判断を下すため、早期の終了を検知することはできますが、さらに 1,000 万回のソルバー反復を行う価値があるかどうかを判断することはできません。

Anthropic のゴールドキュメント

なお、Claude Code はオープンソースではないため、私たちは Anthropic が公開している情報にのみ依存しています。

Codex: 永続的な状態とライフサイクルツール

また、ベンチマーク対象のリリースである Codex CLI 0.144.4 のソースコードも確認しました。Codex では、ゴールは永続的なスレッド状態として扱われます。

• TUI（ターミナルユーザーインターフェース）がアクティブなスレッドの目的を保存し、SQLite がそのステータスと予算管理を担当します。TUI、スキーマ

• 作業用モデルは、create_goal、get_goal、update_goal の各ツールを受け付けます。ツールの仕様

スレッドがアイドル状態になり、ゴールがアクティブな場合、Codex は目的と完了監査を含む継続ターンを注入します。Runtime、prompt

Claude は完了を別のモデルに委譲します。Codex では、作業中のモデルが完了を宣言すると、保存されたゴールがアクティブなまま処理を再開します。Claude の評価者は独立していますが、転記内容しか見ることができません。一方、Codex はファイルやツールを確認できますが、実質的には自分の仕事を自分で採点していることになります。

/goal が多くのケースで勝つ理由と、それでもデフォルト設定として不適切な理由

通常のコーディングタスクでは、進捗が明確に見えます。テストの修正や移行完了など、次のステップで成果が出ることが多いからです。

しかし最適化は異なります。エージェントがソルバーを選んだ後、追加の時間を費やすと、良い判断はさらに強化され、悪い判断は悪化します。

今回のケースもまさにその通りでした。ゴール機能は、Fable が高速なコンパイル済みポートフォリオを維持できた場合や、Sol が成功した連鎖再分割を実行した場合に効果を発揮しました。一方、Fable が低速なソルバーを構築したり、Sol が網羅的なアンカー走査に固執したりした場合は逆効果となりました。

中央値はわずかに正しい方向へ移動しましたが、悪い結果の尾部（ワーストケース）は大幅に誤った方向へと広がりました。

限界について

これは未公開の NP ハードタスクであり、一般的なコーディングリーダーボードではありません。クリーンな対照ペアが3組存在するのは Fable と Sol のみです。他の比較ではプロンプトやラッパーバージョン、時間制限が混在しており、試行はサブスクリプションサービスを通じて順次実行されたため、サービスの性能変動の影響も受けた可能性があります。

コンテナにはタスクメタデータで1つと宣言されていたにもかかわらず8つのCPUが割り当てられており、これが Fable の並列ポートフォリオに有利に働きました。スコアリング対象となった Fable と 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」が有益か有害かを headline にするべきではありません。重要なのは、「persistence」という機能が個々の試行では勝つ可能性が高い一方で、観測された平均パフォーマンスを低下させる可能性があるという点です。困難な最適化問題においては、ループ自体の質よりも、そのループ内で何が継続して実行されているかの質の方が重要になります。