賢いモデルが来るほど、ハーネスは「捨てる」設計になる — Anthropicがマルチからシングルに戻した理由
去年の私は、凝ったハーネスを組むことを「実力」だと思っていました。専門エージェントを役割ごとに分けて、オーケストレーターが指示を配って、各エージェントの出力を別のエージェントが検証する。図に描くと立派でした。地下鉄の路線図みたいに線が交差していて、見るたびに「俺はちゃんと設計している」という気持ちになれました。
その構成が、モデルの更新一回でだいたい半分無駄になりました。新しいモデルは、私がわざわざ分業させていた仕事を1体で平然とこなしました。検証エージェントが拾っていたミスを、そもそも生成側がしなくなった。私が時間をかけて組んだ足場は、足場が支えるべき建物のほうが勝手に育ったせいで、宙に浮いていました。
この記事は、その経験から得た一つの主張の話です。ハーネスの複雑さは、モデルの賢さと反比例します。 賢いモデルが来るほど、それまで必要だった足場は不要になっていく。つまり複雑なハーネスには賞味期限があります。
最初に、似て非なる話と切り分けておきます。私は前に「マルチエージェントの調整コストはエージェント数の二乗で増える」という記事を書きましたが、あれは今ある複雑さがいくら高くつくか、というコストの定量の話でした。今日はそれと別で、時間軸の話をします。同じ構成が、来月のモデル更新で丸ごと要らなくなる。そういう話です。コストが高いから減らすのではなく、賢くなったから外せる。ここが今日の中心です。
Anthropicは自分たちでマルチをやめている
この主張を一番きれいに裏付けているのが、ハーネス設計の本家であるAnthropic自身の方針転換です。
Anthropicの長時間エージェント設計について、彼らは初期に複数の専門エージェントを並べるマルチエージェント構成を採っていましたが、シングルエージェントで十分になったと述べています。設計思想として「モデルが改善すればハーネスも進化すべき」という一文を置いていて、賢くなったモデルに対しては複雑なオーケストレーションが不要になり、シンプルなハーネスでも高品質な出力が得られる、という立場です。
実際、彼らの公式な長時間エージェントのハーネス設計を見ると、驚くほど素っ気ない。複雑な制御フローではなく、環境を立ち上げる初期化エージェントと、毎セッション少しずつ前に進むコーディングエージェントの2要素に集約されています(Anthropic Engineering)。状態管理も派手な仕組みではなく、進捗ファイルとgit履歴という、人間のエンジニアが毎日やっていることをそのまま使っています。賢いモデルを相手にするとき、足場は薄いほうがうまくいく、という設計判断がそこにあります。
念のため正直に書いておくと、「マルチが常に劣る」という話ではありません。Anthropicのマルチエージェント研究システムは、単一エージェントを研究評価で90%以上上回った実績があります。ただしそれが効くのは、タスクが独立スレッドに分解できて、かつ大量のトークンを投下できる場合に限る、と彼ら自身が条件を付けています。条件を満たさないとき、マルチの分業は利益より調整の重さが勝つ。そして「条件を満たさないケース」は、モデルが賢くなるほど増えていきます。1体で足りる仕事が増えるからです。
「ツールを80%消したら成功率が上がった」
時間軸の話だと抽象的なので、最近のいちばん分かりやすい数字を出します。Vercelが社内のtext-to-SQLエージェントで、専用ツールを18個用意し、重いプロンプトエンジニアリングと手動のコンテキスト管理で固めた構成を運用していました。成功率は80%で頭打ちでした。
彼らはそこから足場を8割削りました。 18個のツールを捨てて、execute bash という単一ツールだけを残し、賢いモデルに直接ファイルシステムを触らせた。結果、成功率は100%に上がり、3.5倍速くなり、トークンは37%減りました(Vercel)。
ツール18個（足場あり） → bash 1個（足場なし）
成功率 80% → 100%
速度 基準 → 約3.5倍
トークン 基準 → 37%削減Vercelの総括が刺さります。18個のツールは「モデルの推論を制約していた」、手動のコンテキスト管理は「モデル自身が読めるものを要約していた」。つまり足場が、賢いモデルの足を引っ張っていた。これは私が路線図みたいなハーネスを組んでいたときに起きていたことと、まったく同じ構造です。賢くない相手を想定して用意した補助輪を、賢くなった相手に付けたまま走らせていた。
足場は「外」から消えていく
もう一つ、自分で組まなくてよくなる方向の変化があります。
少し前まで、長時間エージェントを動かすにはコンテキスト圧縮や古いツール結果のクリア、セッションをまたいだ記憶を、自分のハーネスに実装する必要がありました。今はその多くがClaude側の機能として降りてきています。トークンが膨らむと自動で要約するコンテキスト圧縮、重いツール結果を自動で消すcontext editing、会話をまたいで保存・取得するmemory tool(Claude Docs)。
これは地味ですが、ハーネスエンジニアにとっては大きい。去年は自分で書いていた足場の一部が、今年はプラットフォームの標準装備になっている。自分のコードベースから消えていく足場、という形でも反比例は進みます。書かずに済むコードは、メンテしなくて済むコードです。
なぜこれが可能になったかというと、土台のモデル自体が長時間自律的に動けるようになったからです。Claude Sonnet 4.5はSWE-bench Verifiedで77%超を記録し、複雑なタスクで30時間以上連続して動いた、とされています(Anthropic)。7時間で息切れしていた頃に必要だった「こまめに状態を退避して引き継ぐ」足場は、30時間動く相手にはそのままの形では要らない。能力が上がる→足場が縮む、の連結がここにあります。
では、ハーネスは消えてなくなるのか
ここまで読むと「じゃあハーネスエンジニアリングは消える職能では？」と思うかもしれません。私はそう思いません。消えるのは複雑さであって、ハーネスそのものではない。
理由は3つあります。どれだけモデルが賢くなっても、コンテキストウィンドウは有限で、コンテキスト管理の必要はゼロにはなりません。モデルに何をやらせて何をやらせないかというセキュリティ境界は、ビジネス判断なので人間が引きます。そしてビジネス成果を評価するフィードバックループは、本質的にシステムの外側にあります。この3つは、賢さでは解けない。
だから次に来るハーネスエンジニアの仕事は、足場を増やすことではなく、どの足場が賞味期限切れかを見極めて外すことになります。これは難しい仕事です。自分が苦労して組んだものを、モデルが賢くなったという理由だけで捨てる判断には、ある種の悔しさが伴うからです。私は路線図を消すとき、けっこう未練がありました。
実装の上手さが「足す」で測られた時代から、「外す」で測られる時代へ。プレイヤーからコーチへ、というより、過保護な親から手を離す親へ、という感じが近い。子が育つたびに補助を一段ずつ外していく。外しすぎれば転ぶし、外さなければいつまでも歩けない。その引き際の設計が、これからのハーネスエンジニアリングの中心になると思っています。
去年の私の路線図は、もう手元にありません。消したあとのハーネスは拍子抜けするほど短くて、最初は不安でした。でもモデルの更新が来るたびに、短いほうが壊れない。賢い相手には薄い足場。これが、3ヶ月分の自慢を捨てて私が得た、たった一行の結論です。
ハーネスを「足す」から「外す」へ切り替える具体的な設計判断 — 2行のAGENTS.mdから始める最小構成、コンテキストリセットのパターン、5つのフレームワークでのハーネスの定義 — は ハーネスエンジニアリング: AIを使う側から、AIが動く環境を設計する側へ にまとめています。この記事は、その「外す」判断を時間軸から眺めたらどう見えるか、という補助線です。
この記事は役に立ちましたか？