オーケストレーションはアーキテクチャを超える：スタンフォード大学が見出したもの

LLMを制御する「ハーネス（オーケストレーション・コード）」の設計が、モデル自体の性能以上に重要であることを解説する。スタンフォード大学と清華大学の研究に基づき、適切なハーネス設計によって性能が6倍向上し、不要な複雑さを削ぎ落とす「引き算の原理」がエージェント開発の鍵となることを示している。

Orchestration Over Architecture: What Stanford Found

Thanks to Data Impluse for sponsoring this video: new papers from...

モデルよりもハーネスが性能を左右する時代
ハーネスはAIにとってのオペレーティングシステム
自然言語で記述するハーネスの衝撃
自動最適化されるハーネスの可能性
「引き算の原理」：洗練されたハーネスへの道

モデルよりもハーネスが性能を左右する時代

さて、あなたのLLMを包み込んでいるオーケストレーション・コードが、今やモデルそのものよりも大きなパフォーマンスの変動要因となっています。全く同じモデルを使っても、それを取り巻くラッパー、つまりハーネス次第で、性能に6倍もの差が出るのです。これはスタンフォード大学と清華大学による2つの論文から得られた主要な知見であり、どのモデルが最高かというこれまでの議論全体が、しばらく前から的外れな問いになっていたことを意味しています。

この動画では、3つのポイントを順に説明していきます。まず、ハーネスとは一体何であり、なぜそれがモデル自体よりも重要なのか。次に、これをハーネスエンジニアリングという学問分野として形式化した、清華大学とスタンフォード大学の2つの論文について。そして最後に、今日からエージェントの構築方法を具体的にどう変えるべきかという実践的な教訓です。この動画を見終わる頃には、エージェントのパフォーマンスが上がらない時に、具体的にどのレバーを引けばいいのかが正確にわかるようになるでしょう。そして、あなたが手を伸ばそうとしているレバーは、おそらく正解ではないということに気づくはずです。

ハーネスはAIにとってのオペレーティングシステム

では、詳しく解説しましょう。簡単に言えば、ハーネスとはモデルをエージェントに変えるためのアーキテクチャです。エージェント自体は、単なるワンショットのテキストジェネレーターに過ぎません。問いければ答え、そこで止まります。ハーネスこそが、行動を起こし、その結果を確認し、問題が実際に解決されるまで継続する能力をエージェントに与えるのです。

これを考える非常に分かりやすい方法として、オペレーティングシステムの比喩があります。生のLLMはCPUのようなもので、強力ですが不活性です。メモリもストレージも入出力もありません。コンテキストウィンドウはRAMとして機能し、高速ですが限定的です。外部データベースはディスクの役割を果たします。ツールの統合はデバイスドライバであり、そしてハーネスは、CPUがいつ何を見るかを決定するオペレーティングシステムなのです。この比喩は、私が以前の動画で紹介した9つのハーネス構成要素に、非常にきれいに当てはまります。

今回の動画でこれが重要な理由はこうです。前回の動画では、ハーネスとは何かについて答えました。今回の動画はそれとは別の、なぜ同じハーネスでありながら、構成要素の構造次第で6倍もの性能差が生じるのかという話です。

自然言語で記述するハーネスの衝撃

それでは最初の論文を見てみましょう。ここからが本当に面白くなります。一つ目は2026年3月に発表された、清華大学のパン氏らのチームによる論文です。彼らはシンプルな疑問を投げかけました。もし、エージェントの全制御ロジックをPythonやYAMLではなく、構造化された自然言語で記述できたらどうなるでしょうか。

その構造には3つの層があります。一番下にはバックエンド、つまり実際のインフラとツールがあります。中間には彼らがランタイム憲章と呼ぶものがあり、これは普遍的な物理法則のようなものです。具体的には、契約がどのように拘束されるか、状態がどのように持続するか、サブエージェントや子エージェントがどのように管理されるかといったことです。そして一番上に、状態固有のロジックを保持する自然言語のエージェントハーネス自体があります。これには契約、役割、状態構造、および失敗モードが含まれます。

なぜこの分離が重要なのでしょうか。それは、ハーネスエンジニアリングにおける対照実験を可能にするからです。ランタイムを固定したままハーネスを入れ替えることができるため、ハーネスの設計を単独でテストし、純粋な比較検証ができるのです。

結果は興味深いものでした。最大推論モードのGPT-5で検証したSWE-benchでは、構成に関わらず成功率は74%から76%程度に固まりました。しかし、フル装備のハーネスは1サンプルあたり1,630万プロンプトトークンを消費しました。600回以上のツール呼び出しと32分以上の実行時間です。ところが、これの一部を削ぎ落としたバージョンでは、120万トークン、51回の呼び出し、7分未満の実行時間で同じ結果に到達しました。同じ結果を得るために14倍もの計算資源を使っていたわけです。

彼らはモジュールごとの削減実験も行いました。つまり、システムの一部を順に削除していったのです。その結果、一貫して役に立っていたモジュールは自己進化だけでした。検証ツールは、実際には悪影響を及ぼし始めていました。SWE-benchではマイナス0.8、OS Worldではマイナス8.4のスコア低下が見られました。マルチ候補検索も5.6ポイントのマイナスでした。構造を増やせばいいというものではない、というのは驚くべき結果ですが、考えてみれば理にかなっています。これについては後ほど、実践的な教訓のところで改めて触れます。

しかし、この論文の目玉となる結果は別の実験から得られました。彼らはデスクトップ自動化用のOSシンフォニーというネイティブコードで書かれたハーネスを取り上げ、そのロジックを自然言語表現に移行させました。同じ戦略を使いつつ、自然言語で書き直しただけです。すると、パフォーマンスは30.4%から47.2%へと跳ね上がりました。実行時間は361分から41分に短縮され、LLMの呼び出し回数は1200回から34回へと激減しました。表現方法そのものが利益をもたらしたのです。これは極めて重要な発見です。

自動最適化されるハーネスの可能性

このことを念頭に置いて、DSPを構築したオマール・カタブ氏が発表したもう一つの論文を見てみましょう。彼はさらに一歩踏み込みました。表現がこれほど重要なら、最適なハーネスを自動的に見つけることはできないだろうか。

ここで今日のスポンサーから一言。RAGシステムであれエージェントシステムであれ、ウェブ上のデータにアクセスする必要がある本番システムを構築しているなら、スケールアップするにつれてリクエストがブロックされることに気づくでしょう。ロジックがどれほど優れていても、IPがフラグを立てられればデータの移動は止まってしまいます。解決策は優れたプロキシを持つことです。そこで今日のスポンサー、Data Impulseの出番です。ここのレジデンシャル・プロキシ・プールは、コストパフォーマンスにおいて正直太刀打ちできません。価格は1GBあたり1ドルからで、購入分に有効期限はありません。さらに、195カ国にわたる9,000万以上の倫理的に調達されたIPを利用できます。Scrapy、Playwright、Puppeteerなどをすでに使っているなら、ドキュメントに完全な統合ガイドがあります。既存のアプリケーションにプロキシを直接組み込めるのです。モバイルトラフィックが必要な場合も、専用のモバイルプールがあり、スクリプトをほとんど変えることなく、エンドポイントを変えるだけでスマートフォン級のIPを経由させられます。リンクは説明欄にあります。特定の都市のIPが必要なデータパイプラインを運用している方や、スクレイピングのブロックに毎日悩まされたくない方は、ぜひチェックしてみてください。

さて、動画に戻りましょう。構造化されたリトリーバル、メモリ、オーケストレーション、トポロジー。それらすべてをハーネスが制御します。今回のループの仕組みはこうです。エージェントによる提案（この場合はClaude 4.6 Opusを使用）が、失敗した実行トレースを読み取り、何が壊れたのかを診断して、完全に新しいハーネスを書き直します。最終スコアと実行トレースは蓄積され、ループが繰り返されます。

ここで効果を発揮するのはスケールです。1回の反復につき1,000万トークンを投入しており、これは以前のどの手法よりも400倍多いフィードバックです。1ラウンドにつき約82個のファイルを読み取ります。そして、これら生の実行トレースは代えがたいものです。トレースを削除すると、精度は50%から34%に低下しました。トレースを要約に置き換えた場合でも34.9%でした。重要な信号は生の細部に宿っているのです。過去の失敗を要約してモデルに与えるだけでは、エージェントのパフォーマンスを損なう可能性があります。

結果として、Opusで2位、Haikuで1位にランクインしました。つまり、ハーネスの最適化だけで、小型モデルが大型モデルを上回ったのです。Terminal Bench 2では76.4%という数字を叩き出しました。手動で設計されたエントリーが並ぶ中で唯一の自動最適化システムであり、215のテキスト分類タスクにおいて、4倍少ないトークンを使いながら、当時の最高水準を7.7ポイント上回るスコアを記録しました。

しかし、私が最も重要だと思う発見はこれです。あるモデルで最適化されたハーネスは、他の5つのモデルに転送しても、そのすべての性能を向上させたのです。これが何を意味するか考えてみてください。再利用可能な資産はモデルではなく、ハーネスなのです。一度構築すれば、あらゆるモデルで機能します。

「引き算の原理」：洗練されたハーネスへの道

ただ、あまり一般化しすぎたくはありません。これらは学術的な話に聞こえるかもしれませんが、皆さんもすでに気づいていることに関連しています。Claude 4.6や4.7、GPT-5、あるいはGeminiなど、どの最先端モデルでも構いません。全く同じプロンプトを、Claude Code、次にCursor、そしてAnti-gravityの中で実行してみてください。モデルは全く同じまま、ハーネスだけを変えるというアイデアです。プロンプトが比較的複雑であれば、顕著に異なる結果が得られるでしょう。推論パスが異なり、消費トークン数も異なり、成功率も変わる可能性があります。これらすべてはモデルではなく、エージェントで使用しているハーネスによって引き起こされるのです。Opus 47は、Claude Codeの中とCursorの中、あるいはOpenCodeのようなサードパーティのハーネスの中では、全く異なる挙動を示します。

さて、これらすべてから得られる最も重要な実践的な教訓であり、多くの開発者が間違えていると思うのが、Anthropicが「引き算の原理」と呼んでいるものです。すべてのハーネス構成要素（前回の動画で紹介した9つを思い出してください）は、モデルが単独ではできないことに対する仮説をコード化したものです。そして、モデルが進化すれば、それらの仮説は期限切れになります。Opus 46がコンテキストのリセットを必要としなくなった時、Anthropicはそれを完全に削除しました。エージェントプラットフォームのManisは、6ヶ月間でハーネスを5回書き直しました。Vercelはエージェントのツールの80%を削除し、より良い結果を得ました。これは非常に大きな意味を持ちます。

つまり、熟練したハーネス開発とは、構造を積み上げることではなく、むしろ枝を切り落とすような作業なのです。昨年までは、エージェントにより多くのツールを提供することが良しとされていましたが、その時代は終わりつつあります。シンプルな方がはるかに優れているのです。追加するのと同じくらい、削除することの技術が求められます。先ほどの清華大学の削減実験がそれを証明しています。検証ツールがエージェントを助けるどころか、大きな足かせになることもあるのです。

かつてはハーネス側で手作りしていた要素を、もしモデルが自前でこなせるようになったなら、ハーネスを簡素化し、その特定のツールを外すべきだ、と考えるのが正解です。

もしあなたがエージェントを構築しているなら、自覚の有無にかかわらず、あなたはハーネスエンジニアです。何かがうまくいかない時、私が提案する手順はこうです。まずモデルを切り替えるのではなく、ハーネスを監査してください。そして、自分自身に次の4つの質問を投げかけてみてください。