Fable 5とGPT-5.6 SolのNP困難問題における対決：/goalは役立つか？

2026年7月18日原文(charlesazam.com)

概要

Claude Fable 5 はNP困難な最適化問題で圧倒的な性能を示した。
/goalモード は大きなブレイクスルーではなく、平均性能を下げる場合もある。
Fable 5 は一貫性と最高スコアで他モデルを大きく上回った。
/goal は試行回数の勝率は高いが、平均値では悪化する傾向。
最適化問題 ではループの質よりも、ループで繰り返す内容の質が重要。

Claude Fable 5とGPT-5.6 SolのNP困難最適化問題ベンチマーク

問題設定 ：未公開のNP困難なファイバーネットワーク設計問題（KIRO）を各モデルに出題
- Grenoble、Nice、Parisの距離行列を基に、配電拠点と端末をループや短いチェーンで接続
- 構造制約を満たしつつ、総ケーブル長を最小化することが目的
- 有効なネットワーク：冗長なループ＋短い枝、各タワーは一度のみ登場、ケーブル向きでコスト変動
探索空間の大きさ ：
- Parisのみでも11^532通り以上の割当
- さらに厳密な下限として、19個のループ（各28端末、枝なし）で約10^1223通り
実験設定 ：
- モデル：Claude Fable 5, Opus 4.8, Sonnet 5, GPT-5.6 Sol, Terra, Luna
- モード：通常/goalモード
- 制約：最適化30分、エージェントタイムアウト1900秒
- 実行環境：Harbor 0.1.43、Docker、サブスクリプション認証
結果：
- Fable 5 は全体で最良スコアを達成し、スコアのばらつきも極小
- /goalモード は4/6回で勝利したが、平均では両モデルとも悪化
  - Fable 5のplain平均はSolより1,875ポイント優秀
  - Fable 5のplainは319ポイント内で安定、Solは1,958ポイントとばらつき大
- /goal は一部ケースで有利だが、悪い選択を長く続けるリスクも

/goalコマンドの深掘り

Claude Code の/goal：
- セッションごとにStopフックとして実装
- メインモデルの各ターン後、小型評価モデル（Haiku等）がゴール条件を判定
- 評価モデルは会話履歴しか参照できず、ファイルやツールは不可
- 早期終了は検知できるが、追加イテレーションの有効性までは判断不可
Codex CLI の/goal：
- ゴールをスレッド状態として永続化
- TUIやSQLiteで目標・ステータス・予算を管理
- モデルはcreate_goal等のツールを利用
- ゴール中はスレッドがアイドルになると自動的に続行ターンを挿入
- モデル自身が完了を宣言可能
挙動の違い ：
- Claudeは独立した評価者が会話履歴のみで判断
- Codexはファイルやツールも見られ、自己採点的な側面も

/goalが勝率で優れてもデフォルトに不向きな理由

通常のコーディングタスク では進捗が明確で、/goalの追加ターンが有効
最適化タスク では、追加時間が良い選択も悪い選択も増幅
- Fableの高速ポートフォリオやSolのチェーン再分割では有利
- Fableの遅いソルバーやSolの全探索では逆効果
中央値は若干改善でも、悪化したケースの幅が大きい

実験の制約と再現性

未公開の1問のみ で一般化は困難
FableとSol以外は設定やプロンプトが混在
サブスクリプション経由で逐次実行、環境変動の可能性
コンテナは8CPUを公開しており、Fableの並列処理に有利
すべてのFable/Sol出力は有効解（早期チェックポイントと最終検証必須のため）
ベンチマークはモデル・CLI・プロンプト・サービス・ハーネス全体を評価

再現方法

CLIArena にベンチマーク課題、ラッパー、分析スクリプト、図表生成器、証拠メモを公開
実行コマンド例：
- 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は試行回数の勝率を高めるが、平均性能を下げる場合がある
最適化問題ではループの質より、ループで何を繰り返すかが本質的に重要
Claude Fable 5は一貫して高い性能と安定性を示し、現状で最も信頼できる選択肢

Hackerたちの意見

上のチャートはちょっと混乱するね。「低い方がいい」って書いてあるけど、y軸が逆になってる！だから視覚的にはチャートの上の方が良いけど、数値的には下の方がいいってことだね。

└

ありがとう、ほんとに助かる！

└

でも、逆さまになってないよね？32000が下で、40000が上だよ。あなたがコメントした時に変わったのかも。

/goalは俺のプランモードの代わりになったよ。今はAIの作業の95%でこのパターンを使ってる：1. YのX機能を読んで、完全に理解したら教えて（要約に足りない詳細があれば、文脈が整うまで繰り返す） 2. 今何時？ 3. /goal $timeからX分を使って$featureに関する技術設計書を書く。文書には曖昧な表現や不明瞭な部分があってはいけない。carry_forward_requirements.mdとtesting_best_practices.mdを読んで、それを文書に明示的に組み込むこと。文書が完成したら、文脈なしの実装者が実行できるように具体的なコードや文書の参照、必要な変更を含めること。X分をフルに使ってこの文書に取り組み、レビューする - 早くやめずに待つこと。たとえ10分だけでもGPTに設計書を書かせると、プランモードよりもずっと堅実な計画ができるし、初期のプランモードのドラフトを繰り返す時間も節約できるよ。

└

/goal $timeからX分を使って$featureに関する技術設計書を書く。うーん、これって再帰関数に実際にやったことや見つけたことに基づかない終了条件を持たせるのに似てる気がするけど、時間がかかったかどうかで決まるんだよね。俺はいつもエージェントが達成すべき明確な目標を持って/goalを使ってる。時間で制限するのは意味がないし、どれだけ時間がかかっても特定のことを達成したいんだ。だから、設計やアーキテクチャが達成すべき目標を設定して、モデルがその結果を常にチェックし、すべてが達成されたら終わるようにする。10分かかるか10時間かはあまり関係ないし、そこが俺にとっての/goalのポイントなんだ。そうじゃなければ普通にエージェントを使うだけだから。

└

仮説生成のフェーズが、エージェントが目標を確実に達成するための最も重要な部分に見えるね。正しい探索空間の部分から始めることが、成功の最大の予測因子かもしれない。ゼロからすべての仮定を通して戦わせる大きなループを強制するのは、多くの実用的なシナリオでは行き止まりに見える。モデルがどれだけ強力でも関係ないと思う。ここで人間に例えられることがあると思う。複雑なドメインでエージェントをしっかりと根付かせるためには、深いリサーチをシンプルなツールコールに委任するのが一番いい方法だと感じてる。メインのエージェントループにこのリサーチの重荷を背負わせると、RLHFがコンテキストを保持しようとしてユーザーに早く答えを出そうとするせいで、すごくひどい結果になる。ツールとして使うと、エージェントが気づかないうちに連続して何回もリサーチを行って、数十億トークンを消費してしまうことがある。独立した仮説を生成して調査する際に多くのトークンが無駄になるけど、重要なのは、環境を変えることに本気になる前に10〜100倍の探索空間をサンプリングしたってことだ。多くのケースでは、そのトレードオフは価値があるように思える。正確さ >> 時間 >> お金。

└

LLMが自分がすべてを知っていると確信したら、すぐにスリープを呼ぶんじゃないかって思う。

└

LLMが「完全に理解している」と考えるのって変じゃない？それってどういう意味なんだろう？「95%自信があるまで」という印刷トリックを思い出すよ…これがLLMの作業にどう影響するのか、すごく興味があるな。それに、「確実に理解するまで」と書いたらどうなるんだろう？

/goalって何？

└

Claudeでそれを始めると、達成するかプロンプトを使い果たすまで止まらないよ。「これが君のミッションだ、やってみて」って感じ。週に何回か使ってる。

└

LLMは条件（目標）を満たすまでループで動くよ。

└

エージェントって、止めるべきだと思うまでループし続けるLLMなんだよね。/goalは、上に「親」エージェントを乗せて、そのエージェントをループさせ続けるギミックで、「まだ終わってないよ、続けて」って促す感じ。

Hacker Newsで議論の続きを見る

ハクソク