モデルを解き放つ:最先端のハーネス設計
Replitがmodel routerに反論:routerは常に選択するモデルより弱く、core loop自身が各ステップでどの種類のsubagentを使い、どれだけの計算資源を使うかを決める方がよい。4つのharnessプリミティブと実測データにより、harnessは介入しないほどよいという結論。
日本語
コピー

モデルを解放する:フロンティア向けharness設計
モデルルーターは今やどこにでもあるが、根本的な限界がひとつある。精巧なヒューリスティクスにせよ、ターンごとに小さなLLMを走らせて選ばせるにせよ、ルーターの能力は選ばれる側のモデルを超えられない。Replit Agentはその決定権をモデル自身に渡した。メインagent、つまりコアループが、subagentのティアと投入量を決め、タスクの進行に合わせて自分自身の設定も変える。この自由を得て、GPT-6 Astraは定型的な実装を安価なsubagentに任せ、どのtokenに金をかける価値があるかを自分で判断する。DeepSWEとTerminal-Benchで、Replit AgentはAstra単体に対してパレート最適だった。公表されているAstraのベースラインの中に、より低コストでより高スコアのものはない。sidekickアーキテクチャ(同じ構成だが、常駐workerが1つだけ)と比べても、それぞれ11点、16点高い。
なぜscaffoldingを減らすのか
コーディングagentは圧縮された専門用語だらけの文体で書き、その渾名は「Claudish」。フロンティアモデルの文体はどれも十分に独特で、テキストだけで見分けがつく [7]。だから私たちは、各モデルが自分のやり方で働けるようにharnessを設計しつつ、それでも必要なガードレールは残した。狙いは最小コストで品質を保つことにある。新しいモデルが出るたびに、信じ込んでいた結論を測り直し、創発的な挙動の上に成り立つ技術を素早く試す。モデルを解放するとは、どれだけ深く考えるか、いつ仕事を手放すか、誰に渡すかを、モデル自身に決めさせることだ。
モデルを解放する
harnessは選択肢を用意し、ガードレールを守る。各ステップの判断はコアループが下す。
1 どれだけ深く考えるか
投入量は段階的に設定でき、最新のモデルなら1ターン内でも変更できる。cache missは起きない。
2 いつ仕事を手放すか
引き継ぎはコンテキスト管理と並列化をもたらす。小さなタスクなら何も派生させない。
3 誰に渡すか
フロンティアはまだら模様だ。だから各専門家は、その仕事を最も得意とするモデル上で動かす。

図1:モデルを解放する——コアループが各ステップで下す3つの決定。
組み合わせ可能な委譲プリミティブ
GPT-6 Astra [2] で実験を始めたとき、このモデルが委譲を得意とすることに気づいた。GPT-6シリーズは、キャッシュを壊さずにターン途中でeffortを調整できるOpenAI初のモデルでもある。
これらの能力を活かすため、私たちは4つのharnessプリミティブを磨き上げた。コアループが各ステップで持つ選択肢はわずかになる。どの種類のsubagentを派遣するか、どの規模とeffortで動かすか、すでにタスクを渡したsubagentに戻るか、そしてどれだけ深く考えるか。2026年9月時点で、Replit DesignはDesign ArenaのBuildersリーダーボードで1位 [8]。各カテゴリには専用のモデルとツールがある。どの専門家を用意するかは今のところharnessが決め、コアループはいつ、どう使うかを決める。
- Subagentのティアとeffort。 small、standard、largeの3ティアがあり、コストと能力が段階的に上がる。ティア内にはeffortレベルもある。どちらもsubagentごとに適用され、派遣のたびにコアループが選ぶ。たとえば機械的なリネームはsmall・低effortに、厄介なバグの仮説生成はlarge・高effortに渡す。
- 再利用可能なsubagent。 コアループは、すでにタスクを渡したsubagentに最初からやり直さずに戻れる。セッション全体を通じて固定の助手がいるわけではない。任意の数のsubagentが種類やティアをまたいで温まった状態を保ち、どれを起こすかをコアループが決める。OpenAIの新しいモデルではキャッシュの寿命が延び、このやり方のコストが下がった。GPT-6シリーズ [2]、Fable 5.1 [3]、そしてこれらのベンダーがその後リリースしたモデルでは、effortの調整でキャッシュが保たれる。他のモデルでは、effortの調整もモデル切り替えもキャッシュを再構築する。私たちはエスカレーションシステムを訓練し、各ステップで軌跡を検査してeffortをタスクの難易度に合わせている。ルーターのようにリクエスト時に一度だけ判断するのではなく、ターン途中で進行中の作業に反応する。
AstraとFable 5.1 [3] のコード品質のおかげで、evalスコアを落とさずにcode-review subagentの使用を減らせた。これほどのエンジニアリング水準は、これまでのどのモデルでも見たことがなかった。
新しいモデルは自分でタスクを分派する
AstraやFableのようなフロンティアモデルはtokenあたりのコストが高く、小さなモデルの隣に置くと割高に見える。だが私たちは、こうしたモデルが自然にタスクを安価なsubagentへ分派し、自分のtokenを本当に必要な判断に残すことを観察した。Replit Agentの本番環境で、各モデルを1週間ずつ:Fable 5が2026年8月、Fable 5.1とAstraが9月。3つのモデルが本番環境でこの判断をどう扱うか:
| Fable 5 | Fable 5.1 | GPT-6 Astra | |
|---|---|---|---|
| サブエージェントを派遣したターンの割合 | 32% | 21% | 36% |
| 汎用 worker に作業を渡したターンの割合 | 0.9% | 2.3% | 20% |
| 既存のサブエージェントへの再派遣 | 17% | 29% | 42% |
表 1:Replit Agent 本番環境におけるタスク委譲。各モデルとも推論強度は medium。
3 つのモデルはいずれもタスクを委譲するが、そのやり方はそれぞれ違う。medium では、Fable シリーズが汎用 worker に作業を渡すことはほとんどない。読み取り専用の explorer と reviewer を送り出し、実装は自分で抱え込む。Astra は、プロンプトなしで自発的に汎用 worker へ作業を渡した最初のモデルであり、一度 worker にタスクを任せると、新しく始めるのではなく同じ worker に戻る傾向がある。この再訪率は世代を追うごとに上がっている。
ベンダーのページからサービスを追加すると、いつもベンダー側に戻されてしまう。直せますか?AgentExplorerWorker AWorker BTester

図 2:2026 年 9 月 17 日の本番ターン。trace をもとに描画。コアループは explorer を 1 つ、worker を 2 つ、tester を 1 つ派遣した。worker への派遣 5 回のうち 3 回は、すでにタスクを任せた worker への再訪だった。
結果
実行結果は 4 回の繰り返しの平均値。エラーバーは 95% 区間、つまり平均 ± 1.96 SE で、DeepSWE リーダーボードと揃えている [4]。Astra のデータは公開されている mini-swe-agent ベースライン [4] [9] によるもので、リーダーボードが区間を出している箇所ではこちらも区間を出す。比較するベースラインは 2 つ。1 つは Astra を単体で mini-swe-agent 上で走らせ、各リーダーボードの公開スコアを取ったもの。もう 1 つは sidekick アーキテクチャで、設定は完全に同一のまま 1 点だけ変更し、サブエージェントのプリミティブを長期間生存する worker に置き換えている。どのグラフも縦軸がスコア、横軸がタスクあたりのコストなので、最も効率のよい構成は左上に来る。実行からは GPU タスク 3 件を除外した。Replit Agent はタスクあたり 2.25 で 42%、xhigh で 1.84 で 33%。

DeepSWE:スコアとタスクあたりコスト
113 タスク、4 回の繰り返しの平均値。GPT-6 Astra は mini-swe-agent 上で単体実行、公開 v1.1 リーダーボード。
Terminal-Bench 4.0:スコアとタスクあたりコスト
63 タスク、4 回の繰り返しの平均値。GPU タスクは除く。GPT-6 Astra は mini-swe-agent 上で単体実行、Artificial Analysis リーダーボード。
どちらのベンチマークでも、Replit Agent は sidekick アーキテクチャを 11 点差、16 点差で上回った。sidekick はコストが低い代わりに、スコアを 6 分の 1 から 3 分の 1 譲り渡している。Astra の単体実行はスコアで上回るが、それはただ金を多く使っているだけだ。最良の構成でも Replit Agent を 2 点、11 点上回るにとどまり、コストは 2 倍以上かかる。どちらのベースラインもコストとスコアを同時に制することはできない。Replit Agent はユーザーに届けられているそのままの形で実行し、プロンプトも harness も変更していない。
harness 設計における苦い教訓
我々の見方では、この結果は Sutton の苦い教訓の一例だ [6]。人間の知識を agent にハードコードするのは短期的には効くが、長期的には停滞し、最終的には計算量とともにスケールする汎用的な手法に追い越される。硬直した harness はモデルを特定の働き方に押し込み、組み合わせ可能な harness はモデル自身に選ばせる。モデルが賢くなるほど、harness はモデルの代わりに決めるべきではない。
細かく規定したアーキテクチャと比べて、このやり方には 3 つの利点がある。
- モデルの scaling law に賭ける。 モデル自身の判断に委ねた委譲は、リリースのたびに強くなる。次世代モデルの早期プレビューでもこの傾向は続いている。
- タスクに合う。 小さなタスクは何も派生しない。検索は explorer を 1 つ派生する。ビルドタスクは互いに独立した部分に分かれるとき、チームを派生する。
- 永続化せずに再利用する。 サブ agent はモデルが取り戻す必要があるときのために自分のコンテキストを保持する。モデルが取り戻さない限り、何も永続化されない。
Sutton の言葉を借りれば、ハーネスはモデル自身に仕事の進め方を発見させるべきものであって、我々がその方法を規定するものではない。モデルを解き放て。