モデルルーターは今やどこにでもありますが、根本的な限界を抱えています。高度なヒューリスティクスに基づくものであれ、各ターンを読み取ってどの LLM を使うか判断する小さなモデルに基づくものであれ、ルーターの能力は常に「自身が選択しようとしているモデル」より劣ります。Replit Agent は、代わりにモデル自身に判断させます。
メインエージェント（コア・ループ）がサブエージェントのティアと推論努力量（effort）を選び、タスクの進行に合わせて自身の設定も調整します。この自由度を得た GPT-6 Astra は、定型的な実装をより低コストなサブエージェントに任せ、自分のトークンをどこに使う価値があるかを自ら判断します。DeepSWE と Terminal-Bench の両方で、Replit Agent は Astra 単体に対してパレート効率的です。つまり、公開されている Astra のベースラインで、これより低コストかつ高スコアなものはありません。また、同じ構成からサブエージェント群を除き「長寿命のワーカー 1 体」に置き換えたサイドキック構成に対しても、それぞれ 11 ポイント、16 ポイントの差をつけて上回っています。
アニメーションや脚注を含む全文は https://replit.com/blog/free-the-models をご覧ください。
スキャフォールディングを減らす理由
新しいモデルがリリースされるたびに、ハーネスに組み込まれた前提は陳腐化します。
モデルが長期タスクに強くなるにつれ、ハーネス層でのスキャフォールディング（足場づくり）はそれほど必要なくなります。実際、モデルは自ら委譲に傾くようになっています。コンテキスト管理や並列処理にサブエージェントを使うのです。最近のブレークスルー（Navier–Stokes 問題の進展など）も、一部はフロンティアモデルを搭載したエージェント群の協調によって生まれました [[1]](https://openai.com/index/navier-stokes-solution/)。
ただし、フロンティアは一様ではありません。最強のコーディングモデルが、UI 設計や Slides 作成、あるいはメール文面の作成でも最強とは限りません。
だからこそ私たちは、各モデルがそれぞれの得意なやり方で動けるようにハーネスを設計しています。必要なガードレールは残しつつ、「最小コストで最大品質」を目標にするのです。
新しいモデルが出るたびに、これまで確信していた前提を検証し直し、創発的な振る舞いを活かす手法を素早く試すことになります。つまり「モデルを解放する」とは、どれくらい深く考えるか、いつ作業を引き継ぐか、誰に引き継ぐかを、モデル自身に決めさせることなのです。
図 1：コア・ループが各ステップで行う 3 つの意思決定。
委譲のための組み合わせ可能なプリミティブ
GPT-6 Astra [[2]](https://openai.com/index/gpt-6-astra) で実験を始めたとき、このモデルは委譲が非常にうまいことがわかりました。また GPT-6 ファミリーは、OpenAI のモデルとして初めて、キャッシュを壊さずにターン途中で effort を変更できるようになりました。
これらの機能を活かすため、ハーネスの 4 つのプリミティブを磨き上げました。コア・ループは各ステップで次のような少数の選択肢を持ちます。どんな種類のサブエージェントを起動するか、どのサイズ・どの effort か、すでに指示済みのものに戻るか、そしてどれくらい深く考えるかです。
- ドメイン対応のサブエージェント。 汎用ワーカーに加え、読み取り専用のエクスプローラー、ブラウザテスター、レビュアー、そして Slides や UI 向けのデザイン用サブエージェントといった専門職を用意し、それぞれに適したモデルとツールを持たせています。現時点では「どの専門職が存在するか」はハーネスが決めますが、「いつ・どう使うか」はコア・ループが決めます。
- サブエージェントのティアと effort。 small / standard / large の 3 ティアがあり、順にコストと能力が上がります。さらに各ティア内で effort レベルを設定できます。どちらもすべてのサブエージェントに適用され、起動ごとにコア・ループが選びます。たとえば機械的なリネームは small × low effort に、なかなか直らないバグの仮説出しは large × high effort に割り当てます。
- 再利用可能なサブエージェント。 コア・ループは、ゼロから作り直す代わりに、すでに指示済みのサブエージェントに戻ることができます。セッション中に延命される「サイドキック」が 1 体いるわけではありません。種類やティアを問わず任意の数のサブエージェントが待機状態を保ち、どれを起こすかはコア・ループが選びます。OpenAI の新しいモデルではキャッシュの有効期間が長く、この運用のコストを抑えられます。
- 動的な effort チューニング。 ターン途中での effort 変更が一部のモデルでキャッシュを保持するようになったため、各ステップで進捗を確認し、タスクの難易度に合わせて effort を合わせるエスカレーション機構を訓練しました。ルーターと違い、リクエストに対して一度だけ判断するのではなく、進行中の作業に対してターン途中で介入します。
Astra と Fable 5.1 [[3]](https://www.anthropic.com/claude-fable-and-mythos-5-1) のコード品質が高いため、評価スコアを落とさずにコードレビュー用サブエージェントの利用を減らすこともできました。これほどのエンジニアリング品質を示すモデルは、これまで見たことがありません。
新しいモデルは自ら委譲する
Astra や Fable のようなフロンティアモデルはトークン単価が高く、小さなモデルと比べると非経済的に見えます。しかし実際に観察すると、これらは自然に低コストなサブエージェントへ委譲し、自分たちのトークンは本当に必要な判断のために取っておきます。
Replit Agent は、コア・ループにサブエージェントの起動を強制しません。表 1 は、本番環境で 3 つのモデルがこの判断をどう行っているかを示しています。
表 1：Replit Agent 本番環境での委譲状況（各モデルとも reasoning effort は medium）。
3 モデルすべてが委譲を行いますが、そのやり方はそれぞれ異なります。medium effort の場合、Fable モデルは汎用ワーカーに作業を任せることがほとんどなく、読み取り専用のエクスプローラーやレビュアーを派遣し、実装は自分で抱えます。Astra は、指示されなくても日常的に汎用ワーカーへ委譲する初めてのモデルであり、一度指示を出したワーカーには、新規起動よりも戻ることが多い傾向があります。この「復帰率」は世代を重ねるごとに上昇しています。
図 2：トレースから描画した 2026 年 9 月 17 日の本番ターン。コア・ループはエクスプローラー 1 体、ワーカー 2 体、テスター 1 体を起動。5 回のワーカー起動のうち 3 回は、すでに指示済みワーカーへの復帰でした。
結果
Replit Agent の Max モード（Astra をコア・ループとする最高品質設定）を、DeepSWE と Terminal-Bench という 2 つのソフトウェアエンジニアリングベンチマークで評価しました。比較対象は 2 つのベースラインです。1 つ目は mini-swe-agent 上の Astra 単体（各リーダーボードで公開済みの数値）、2 つ目はサイドキック構成（同じ設定からサブエージェントのプリミティブ群を取り除き、長寿命のワーカー 1 体に置き換えたもの）です。各グラフは横軸にタスクあたりコスト、縦軸にスコアをとっているため、左上ほど効率的な構成となります。
アクティブなオープンソースリポジトリに対する長期の変更をテストする DeepSWE v1.1 [[4]](https://deepswe.datacurve.ai/) では、Replit Agent がタスクあたり $2.11 で 72% を達成。mini-swe-agent 上の Astra は low effort で 67%（$1.60）、xhigh effort で 74%（$4.43）。サイドキック構成は 61%（$1.34）でした。Terminal-Bench 4.0 [[5]](https://www.tbench.ai/) は、シェルのみで完遂するマルチステップ作業をテストします。Replit Agent はタスクあたり $2.53 で 49% に到達。対する Astra は low effort で 42%（$2.25）、xhigh で 60%（$5.86）。サイドキック構成は 33%（$1.84）にとどまりました。
Replit Agent は両ベンチマークでサイドキック構成を上回り、その差は 11 ポイントおよび 16 ポイントです。サイドキック構成はコストが低いものの、スコアの 6 分の 1 から 3 分の 1 を犠牲にしています。Astra 単体がスコアで上回るのは、より多く支出した場合のみです。Astra の最良設定は Replit Agent より 2 ポイントおよび 11 ポイント高いものの、コストは 2 倍以上かかります。コストとスコアの両方で勝るベースラインはありません。なお Replit Agent は、プロンプトやハーネスに変更を加えず、ユーザーに提供しているそのままの状態で実行しました。
ハーネス設計における「苦い教訓」
私たちはこの結果を、Sutton の「苦い教訓（Bitter Lesson）」[[6]](http://www.incompleteideas.net/IncIdeas/BitterLesson.html) の一例と捉えています。人間の知識をエージェントに組み込むことは短期的には有効ですが、長期的には頭打ちになり、最終的には計算量とともにスケールする汎用的な手法に追い抜かれます。硬直的なハーネスはモデルに一つの働き方を強制しますが、組み合わせ可能なハーネスはモデルに選択を許します。モデルが賢くなるほど、ハーネスが代わりに決めるべきことは減っていくのです。
より規定の強いアーキテクチャと比較して、このアプローチには 3 つの利点があります。
- モデルのスケーリング則に賭けている。 モデルの「センス」に依存する委譲は、リリースを重ねるごとに改善します。次世代モデルの早期プレビューでも、この傾向は続いています。
- タスクにぴったり合う。 小さなタスクなら何も起動せず、探索が必要ならエクスプローラーを 1 体、ビルドが独立した部品に分かれるならチームを起動します。
- 永続化せずに再利用する。 サブエージェントは、モデルが戻りたくなった場合に備えてコンテキストを保持しますが、戻らない限り何も永続化されません。
Sutton の言葉で言えば、ハーネスは「私たちがどうやるか」を規定するのではなく、モデルが「どう実行すべきか」を発見できるようにすべきです。モデルを解放しましょう。
謝辞
執筆者：Daniel Furman、Jacky Zhao、Vaibhav Kumar、Ed Sioufi、Michele Catasta。James Austin、Toby Ho、Preeya Kirani、Zhen Li、Robin Newhouse、Devanshu Sen Pandey、Ibrahim Sheikh、Samuel Spitz、Peter Zhong、そして Replit の AI チームの皆さんに、本稿への貢献を感謝します。Replit で AI に取り組みたい方は、私のチームで採用を行っています。pirroh@repl.it までご連絡ください。
