Fable は、熟練エンジニアのマネージャーのように、早めに仕事を振り、仕様をきちんと書き、みずから手を動かすことは少ない。一方 Opus は、インターンのようなマイクロマネージャーである。この記事は Joon Lee X の記事をもとに、3,000 回の評価テストで背後にあるコスト構造を分解する。
（前情提要：Anthropic が「Claude for Small Business」を提供：中小企業の AI 自動化業務を狙い、請求書の督促や給与計算などを手伝ってくれる...）
（背景補足：Anthropic は実名 KYC による本人確認を要求！Claude の一部機能では身分証明書のアップロードが必要で、コンプライアンス上の負担が拡大）
本文目次
Toggle
はじめに
実験設定
1 つの agent のコスト
インターン付きのマイクロマネージャー vs 熟練エンジニア付きのマネージャー
引き継ぎの後
委任が役に立たないとき
結語
我々は Opus 4.8 を Fable 5 に置き換えたが、Devin の請求額の方がむしろ下がった。
Fable を Opus より安くする方法：委任によるリライトで Agent のコスト構造を最適化する
Fable は、熟練エンジニアのマネージャーのように、早めに仕事を振り、仕様をきちんと書き、みずから手を動かすことは少ない。一方 Opus は、インターンのようなマイクロマネージャーである。この記事は Joon Lee X の記事をもとに、3,000 回の評価テストで背後にあるコスト構造を分解する。
（前情提要：Anthropic が「Claude for Small Business」を提供：中小企業の AI 自動化業務を狙い、請求書の督促や給与計算などを手伝ってくれる...）
（背景補足：Anthropic は実名 KYC による本人確認を要求！Claude の一部機能では身分証明書のアップロードが必要で、コンプライアンス上の負担が拡大）
本文目次
Toggle
Fable 5 の 1 トークンあたりコストは Opus 4.8 の 2 倍だ。しかし、まったく新しい Fusion アーキテクチャで FrontierCode 1.1 上にこの 2 つのモデルを同時に走らせると、Fable の方がむしろ安くなる。もちろんスコアも高い。この文章ではその理由、そしてそれが「agentic な仕事にどう値付けするか」を意味するものを解説する。
はじめに
コードを書く agent を動かす人なら誰でも知っている。より強いモデルはより良い結果をくれるが、その代わりコストも飲み込まなければならない。
Devin Fusion をリリースする際、解決策を示した。最先端のモデルを司令塔として据え、より安くて速い分身に仕事を委譲させることで、前線レベルの性能を、低い 35% のコストで手に入れられるという道だ。
だが、司令塔となるモデルが仕事の大半を委譲するようになったら、1 トークンあたりの単価は全請求額を支配し続けるのだろうか？Fable 5 は Opus 4.8 より 1 トークンあたりのコストが 2 倍高い。したがって Fable が主導する agent は、当然より高くなるはずだ。答えを見つけるために、FrontierCode 1.1 で 3,000 回の評価テストのワークセッションを実行し、4 つの構成にまたがって比較した。Fable と Opus がそれぞれ主導席に座り、さらに各々が「いる」場合と「いない」場合で同じ安い副手を用いる。
純粋な実行（pure runs）の成績は、直感どおりだった。Fable のスコアは Opus を上回る（60.8 対 55.4）。そしてコストも高い。より良いモデル、より大きな請求額。
副手の加勢が入ると、話は面白くなる。
同じ副手を与えた場合、コストの並び順が反転した。Fable + 副手の方が Opus + 副手より安い（$1.86 対 $2.04）。一方でスコアはむしろ高い（60.7 対 54.6）。純粋な Fable と比べると、Fable + 副手はコストを 54% 押し下げたのに、スコアはほぼ変わらない。
| 構成 | | --- | | スコア | | 1 回あたりの実行コスト（平均） | | --- | --- | | Fable 5（low）+ 副手 | 60.7 | $1.86 | | Opus 4.8（medium）+ 副手 | 54.6 | $2.04 | | Fable 5（low） | 60.8 | $4.03 | | Opus 4.8（medium） | 55.4 | $3.06 |
結果は、「1 トークンあたり 2 倍高い」というのが間違った見方だったことを示している。agent のコストは主に、主導モデルが何ラウンドを走ったか、どれだけのコンテキストを一緒に引きずったか、そして最も重要な——それが「何を自分でやらなかったか」で決まる。違いは管理スタイルに集約される。Opus はインターン付きのマイクロマネージャーのように振る舞い、Fable は有能なエンジニア付きのマネージャーのように振る舞う。
実験設定
まず Fusion の副手アーキテクチャがどう機能するか、素早く復習しよう。主導 agent はワークセッション全体を持つ。ユーザーと対話し、計画し、作業をレビューして（commit を）提出する。さらに常駐する副手子 agent がいて、そこにタスクを委譲できる。主導モデルは素朴な言葉で引き継ぎの簡報を書き、それを、より安いモデルが動かす子 agent が自分のコンテキストの中で実行し、結果を返す。主導モデルはその結果をレビューし、次にどうするかを決める。
コストの流れがどこに向かうかを調べるために、我々は 2 つのことを行った。第一に、3,000 回すべてのワークセッションに含まれる LLM 呼び出しを解析した。どのモデルが話しているか、どのツールを呼んだか、読み書きしたトークン数、そして各呼び出しがいくらかかったかを特定した。第二に、40 個のタスクをより近距離で観察した。Fable が明らかに安いもの、Opus が明らかに安いもの、そして中間帯からのランダムなサンプルの一群だ。それぞれについて、Fable が主導する実行と Opus が主導する実行を並べて分析し、軌跡を比較し、お金がどこに使われたかを観察した。
1 つの agent のコスト
以下は、我々の実験においてコストが主導モデルと副手の間でどう配分されたかである：
| | | --- | | 主導 $ | | 副手 $ | | 1 回あたりの総コスト $ | | 主導の 1 回あたり回合数 | | 主導入力トークン（累計） | | --- | --- | --- | --- | --- | | Fable + 副手 | $1.28 | $0.58 | $1.86 | 11.5 | 545k tok | | Opus + 副手 | $1.73 | $0.31 | $2.04 | 26.5 | 1，679k tok |
Fable は副手に使う金額が Opus より多い——1 回あたり $0.27 多い。だが自分自身に使う金額は $0.45 減っている。Fable の主導は 1 回あたり 11.5 ラウンド、Opus は 26.5 ラウンド。出力 token は 3 分の 1 だけ（6.1k 対 19.0k）で、消費した入力 token も 3 分の 1 で済んでいる。Fable は 1 トークンあたり明らかに高いのに、コンテキスト管理とラウンド数では勝っている。
Fable のトークン節約は、「そもそも仕事を避けている」ことから来ている。興味深いことに、Fable が主導する実行の 81% では、主導モデルが最初から最後まで一度もコード編集をしなかった。Opus では、そのような実行は 24% だ。さらに Fable が主導する実行の 13% では、主導モデルがそもそも repo のどのファイルも自分で読んだことがなかった。
インターン付きのマイクロマネージャー vs 熟練エンジニア付きのマネージャー
このギャップが面白いのは、次の点だ。2 つの主導モデルが委譲する回数は同じくらいで、各実行で約 3 回の引き継ぎだ。逐次呼び出しのログは、「Fable は単に委譲回数が多いだけ」という単純な説明を覆す。真の違いは、それらが「いつ」委譲するか、「何を」委譲するかにある。Fable の最初の引き継ぎは、かなり早い。
Opus は、ずっと遅くに委譲する。長い間、自分で探索して実装した後だ。その時点では、設計上の意思決定はすでに済み、重要ファイルもコンテキストに投入済みで、高価な作業はもう終わっている。
典型的な、Fable が主導する実行では、まず repo をいくつか偵察し、その後、仕様レベルの簡報を書いて、「実装 + テスト + lint」のループを一度に委譲する。次に git show で diff を審査し、そしてコミットする。
典型的な、Opus が主導する実行は、20 から 45 ラウンドの独自探索・設計・実装を経て、加えて非常に遅いタイミングで起きる、機械的な後始末だけを委譲する引き継ぎを 1 回含む。
ときには、Fable が 1 つのワークセッションで最初に行う行動が引き継ぎになることもある。まったく同じタスクで、2 つの主導モデルの立ち上がりはこうなる：
明らかに直したい修正は、Opus により多く探索を委譲させるよう強制することだが、そのような行動を強制すると性能が落ちがちだ。調査を「安全に」委譲できるタイミングと、あなたが必ず自分でやらなければならないタイミングを知ること自体が、判断だ。脅されて委譲するようなモデルは、その判断力を得られるわけではない。委譲すべきでないものまで委譲してしまうだけだ。
各モデルの管理スタイルは、引き継ぎの簡報そのものにもはっきり表れる。Opus が実装を委譲するとき、それは命令を書いている。一方 Fable は、設計書を書いている。
委譲は単にコストを振り替えるだけではない。仕事の品質も変える。上のハッシュ（hashing）タスクがその鮮明な例だ。タスクの仕様では、ハッシュ関数はポインタ長に対して O(1) でなければならない。Opus は自分で実装したが、この要件をどこにも書き残していなかった。途中のどこかで、この制約を忘れ、線形時間の実装を渡してしまい、スコアは 25。対して Fable は、高次の制約として委譲した。簡報にはこう書かれている。「operator() はポインタ長に対して O(1) でなければならない：完全なトークン走査をしてはならない。」副手はそれを成功裏に実装し、94 点を獲得した。
このパターンは、さまざまなタスクで共通している。我々は、Fable の引き継ぎが制約や境界ケース、そして「完了とは何か」という定義を列挙していることを見つけた。そうすることで自分の手間を省き、かつ副手が安く・正しく実装できるようになる。
引き継ぎの後
もう半分は、主導 agent が副手から返ってきた成果をどう扱うかだ。2 つの主導モデルは、しばしば同じような安価なチェックを走らせる。2〜3 回の git diff / git show 呼び出しなどだ。だが Opus はそこで止まらない。副手のファイルを自分のコンテキストに戻す頻度が 2 倍で、その後は主導モデルの価格で、最大で 4 倍もの修正的な編集を行う。最悪の場合には、副手の成果を丸ごと元に戻し、手ずから書き直すまでしてしまう：
そして Opus の不信感は、正確性を上げはしない。評価タスクによっては、Fable の diff 審査を 1 回行っただけで副手の本当のバグを見つけ、Opus のように主導モデルの等級で頻繁に大規模リライトするのではなく、もう一度だけ安い引き継ぎを行うことを選ぶ。
委譲が役に立たないとき
Fable の委譲戦略は万能ではない。タスクに委譲できる構成要素がない場合、うまく機能しない。以下のようなタスクは、分解しにくいように見える：
注意すべきは、これらのタスクでは Fable がほぼまったく委譲しないことだ。良い簡報を書ける判断力は、同様に「いつ書くべきでないか」も知っている。とはいえ、委譲する価値のあるものが何もないタスクでは、委譲のコスト削減に効く余地がない。
本番の生産環境では Fusion は、別の次元でこの問題を扱う。委譲の決定は「高価なモデルに残すべき仕事は何か」を決め、ルーティング（routing）は「その高価なモデルをそもそも巻き込む必要があるか」を決める。
結語
我々はこの実験を始めたとき、測りたかったのは「Fable の 2 倍の上乗せ（プレミアム）がコストをどれだけ増やすか」だった。だが我々は驚くことに、Fable の有効な委譲によって全体のコストが下がっていることが分かった。Fable は、実装を一歩ずつ固定するのではなく、制約と結果を示す。フィードバックを与え、手を動かして修正するのではない。そして大半のケースで、そもそもコードに触れていない。これらはすべて、良いマネージャーの習慣である。
副手モデルがより安く、より良くなるにつれて、それらに任せられる仕事が増える。そして将来もなお、最前線の価格を払う価値があるのは判断力だ。何をやるべきか、どんな制約を課すべきか、そして誰が書くべきか——それである。