MicrosoftがOrchardを公開、再利用可能なエージェント訓練にはなおスケールの課題

Microsoft Researchは、各エージェントプロジェクトに固有の専用インフラが必要だという考え方に一石を投じる形で、3種類のエージェント訓練レシピを備えたOrchardを公開した。このフレームワークは、ソフトウェアエンジニアリング、ブラウザー操作、パーソナルアシスタントのタスクを対象とする。中核となる約束は再利用性だ。1つの環境レイヤーで、データ収集、教師あり訓練、強化学習、評価を支援できる。

これは重要だ。オープンなエージェント研究にはインフラ上の問題があるためだ。研究者は多くのオーケストレーションライブラリーを精査できる一方、高性能なエージェントを支える訓練システムの再現は依然として難しい。サンドボックス、ツールインターフェース、報酬関数、長時間にわたる軌跡は、しばしば単一のタスクに密結合する。

Microsoft Orchardは、これらの要素を分離しようとしている。別のアプリケーションフレームワークを提示するのではなく、エージェントが行動し学習する環境に焦点を当てる。この違いにより、主として開発者によるエージェントアプリケーションの構築・運用を支援するMicrosoft Agent FrameworkやAutoGenよりも、実験的な訓練プラットフォームに近い位置付けとなる。

報告された成果は大きい。しかし、これらはプロジェクトチームによる研究結果であり、性能や利用しやすさについて独立に確認されたものではない。今回の公開には実務的な緊張関係もある。再利用可能なソフトウェアはエンジニアリングの重複を減らせる一方、大規模なエージェント訓練には依然としてモデル、計算資源、タスク環境、運用上の専門知識が求められる。

Orchardはエージェント環境を共有インフラへと変える

重要な変化は、また1つエージェント用インターフェースが増えたことではない。エージェントの訓練サイクル全体に追随する、再利用可能な環境レイヤーである。

このプロジェクトの中心にあるのは、隔離された環境を管理するKubernetesネイティブのサービス、Orchard Envだ。サンドボックスとは、エージェントがホストシステムへの無制限なアクセスなしに、コマンドを実行し、ファイルを変更し、アプリケーションを閲覧し、観測結果を受け取れる、制御された作業空間を指す。

プロジェクトのagentic modeling frameworkによると、このサービスはRESTインターフェースを通じて共通操作を公開している。操作には、サンドボックスの作成・削除、コマンド実行、ファイルの読み書き、ネットワークポリシーの適用が含まれる。

環境は、モデル出力をツール操作へ変換するソフトウェアであるエージェントハーネスから分離されたままだ。また、推論システムや訓練アルゴリズムからも分離される。そのため研究者は、すべての環境管理コンポーネントを再構築することなく、モデルやハーネスを変更できる。

この分離は、繰り返し生じる摩擦の原因に対処する。コーディングエージェントには、リポジトリーのスナップショット、ビルドツール、非公開テストが必要になる場合がある。ブラウザーエージェントには、視覚的なインターフェースとWebサイトの状態が必要だ。パーソナルアシスタントには、ツールAPIとタスク固有の検証が必要になる。

これらの設定はアプリケーション層では異なって見える。その一方で、いずれにも隔離された環境、ライフサイクルマネージャー、観測チャネル、結果を採点する方法が必要となる。このフレームワークは、こうした共通要件を明確化しようとしている。

Microsoftによると、このサービスはテストでコマンド実行あたり平均0.28秒を記録した。付随する論文では、1,000個のサンドボックスを用いたストレステストで成功率100％だったことも報告されている。これらの測定値は研究者の構成を示すものであり、普遍的な本番環境の保証として扱うべきではない。

このアーキテクチャはランタイムエージェントインジェクションを採用しており、タスク固有のコンテナーイメージを制御サービスから分離したままにできる。また、実行とファイル操作はサンドボックスのPodアドレスへ直接ルーティングされる。論文は、これによりKubernetesの実行チャネルに伴う一部のオーバーヘッドを回避できるとしている。

ほかの運用上の詳細からも、エージェント訓練にどれほど多くのインフラが必要かが分かる。このシステムには、非同期のサンドボックス作成、準備完了状態の監視、ハートビートベースのクリーンアップ、ネットワーク隔離、リトライ、リソース拡張が含まれる。華やかな機能ではないが、いずれかが失敗すれば訓練実行が無効になったり停止したりする可能性がある。

この幅広さが、プロジェクトの研究上の価値を説明する。異なるエージェントタスクを研究するチームは、自らのモデル、ツール、報酬システムを維持しながら、同じ制御レイヤーを再利用できる。原理的には、実験間で変化するインフラ変数が減るため、比較もしやすくなる。

このフレームワークが、特化したタスク設計を不要にするわけではない。研究者は依然として、有効な環境の作成、許可する操作の定義、サンドボックスの保護、意味のある評価器の開発を行わなければならない。こうした判断を不要にするのではなく、それらを巡る重複したエンジニアリングを減らすものだ。

真の負荷はタスク固有の訓練スタックにかかる

Orchardは、コーディング、ブラウザー、アシスタントの各エージェントに別々のエンドツーエンド訓練システムが必要だという前提に問いを投げかける。

公開されているエージェントフレームワークの多くは、オーケストレーションに重点を置く。モデルによるツール呼び出し、メッセージ交換、ワークフロー実行、複数エージェントの協調を支援する。これらの機能はアプリケーションにとって重要だが、モデルを改善するために必要なデータとフィードバックを自動的に生み出すわけではない。

訓練では、さらに別のレイヤーが加わる。エージェントは制御された環境でタスクに取り組み、複数ステップの軌跡を生成し、信頼できる報酬を受け、そのやり取りをモデル更新へ変換しなければならない。各段階は異なるソフトウェアとインフラに依存しうる。

軌跡とは、タスク中に生成される推論、操作、ツール応答、環境状態の完全な連続記録である。これらの記録は訓練例になり得るが、それにはシステムがその構造を保持し、どの行動が有効だったかを判断できなければならない。

この課題は、長い時間軸のタスクでより深刻になる。コーディングエージェントは複数のファイルを調査し、パッチを試み、テストを実行し、アプローチを修正しても、最後には失敗するかもしれない。単純な成功・失敗ラベルだけでは、どの中間判断が有益だったのかを説明できない。

このプロジェクトの答えは、パイプラインの各段階で環境と軌跡の両方を再利用することだ。同じ環境サービスが、教師モデルによるデータ収集、教師ありファインチューニング、強化学習ロールアウト、最終評価を支える。研究者は各段階ごとに別のサンドボックスシステムを用意する必要がない。

この設計は、本番指向のオーケストレーションとは対照的だ。Microsoftの別のagent application frameworkは、Pythonと.NETでのエージェント構築とデプロイを対象としている。AutoGenも、マルチエージェントの会話とツール利用に関する共通パターンを確立した。

新しい研究スタックが扱うのは別の問いだ。エージェントが次に何をすべきかを決める基盤ポリシーを、チームはどのように訓練できるのか。この違いにより、直接的な製品比較は成り立たない。アプリケーションフレームワークと訓練環境は相互補完できる。

むしろ圧力がかかるのは、クローズドで垂直統合された研究パイプラインだ。同じオープンな環境レイヤーが複数の領域で機能するなら、チームがモデル、ハーネス、サンドボックス、評価器を切り離せない一体型の束として受け入れる理由は少なくなる。

理論上、最も恩恵を受けるのは小規模な研究グループだ。分散サンドボックスサービス全体をエンジニアリングする代わりに、共有の環境プリミティブと公開されたレシピから始められる。また、これまで遥かに大規模なシステムと結び付けられてきたタスクで、小型モデルを試すこともできる。

ただし、「小規模」は相対的な概念にとどまる。Kubernetesサンドボックス、推論サーバー、教師モデル、強化学習ジョブを動かすには、依然として高度な技術力が必要だ。今回の公開は複雑さの一領域を減らすが、エージェント訓練を一般的なノートPCのワークフローに変えるものではない。

組織は、こうした実験を巡る知識管理にも規律を持つ必要がある。軌跡、評価失敗、構成変更、タスク定義は、すぐに検索しにくくなる。技術ナレッジベースは、最終的なベンチマークスコアだけでなく、結果に至った推論も保存できる。

したがって、戦略的な変化の核心はモジュール性にある。研究者は好みのモデルとエージェントインターフェースを維持しつつ、カスタム環境バックエンドを置き換えられる。このパターンが広く採用されれば、インフラの再利用はオープンなエージェント研究の基本的な期待値になる可能性がある。

Microsoft Orchardは失敗の有用な部分から学ぶ

このフレームワークで最も強力な発想は、失敗したエージェント実行にも価値ある訓練証拠が含まれ得るという点だ。

Orchard-SWEと呼ばれるソフトウェアエンジニアリング向けレシピは、MiniMax-M2.5とQwen3.5-397Bから蒸留した約107,000件の軌跡から始まる。Microsoftは、このコーパスが2,788のGitHubリポジトリーにまたがると報告している。

プロジェクトのtrajectory datasetには、107,185件のソフトウェアエンジニアリング記録が記載されている。内訳は解決済み軌跡74,649件と未解決軌跡32,536件だ。解決済みの記録とは、最終パッチがそのタスクの非公開テストスイートに合格したことを意味する。

従来の教師ありファインチューニングでは、成功した例が重視される。正しい結果に到達した行動をモデルが再現するよう学ぶため、これは直感的に理解しやすい。しかし、失敗した軌跡をすべて捨てると、有益な中間作業まで無駄にしかねない。

失敗したコーディング実行でも、関連するモジュールを正しく見つけ、誤った条件を特定し、有効なパッチの大部分を書けていることがある。その後の1回の編集で解決策が壊れる可能性がある。軌跡全体を無価値と見なせば、それまでの進展を失う。

このレシピは、そのシグナルを回収するためにクレジット割り当て教師ありファインチューニングを導入する。クレジット割り当てとは、1つの結果をすべてのステップに付与するのではなく、どの操作が進展に寄与したかを特定することを意味する。

未解決の実行については、教師モデルが最終テスト結果とともに軌跡全体をレビューする。そして、各ステップの後にタスクを解決できる確率がどのように変化したかを推定する。パイプラインは次に、その推定確率が上昇した連続区間を選択する。

こうした上昇区間が教師あり学習のターゲットとなる。先行する観測はコンテキストとして引き続き利用可能であり、訓練損失は進展を示すと判断されたアシスタント生成の推論と操作に焦点を当てる。ツール応答は予測損失から除外される。

この手法は失敗を成功へ変えるものではない。主張はより限定的だ。失敗した試行の一部は、生産的な探索がどのようなものかをモデルに教えられる可能性がある。その学びの信頼性は、事後的な教師モデルによる推定に依存する。

続いてこのレシピは、モデルが新たな試行を生成し、タスクレベルの報酬を受ける強化学習を加える。難しいのは、予算の大半を一様な結果に費やすことなく、有益な試行グループを得ることだ。

すべての試行が成功すれば、どのポリシー選択が優れていたかについて、そのグループが提供する情報は少ない。すべての試行が失敗する場合にも同じ問題が起きる。標準的な固定サイズのサンプリングでは、こうした低分散グループの生成に相当な計算資源を費やす可能性がある。

Microsoftは代替手法をBalanced Adaptive Rolloutと呼ぶ。この手法は試行を段階的に生成し、正負の報酬が有用なバランスで含まれる訓練グループを組み立てようとする。有益なグループが見つかった時点で停止することも、固定された最大予算の範囲内で継続することもできる。

このアプローチは、単なる精度ではなく効率性を重視している。意味のある比較を得るために追加の試行が必要なプロンプトへ、より多くのサンプリングを割り当てる。依然として不適切なグループはフィルタリングし、他のタスクから補充できる。

プロジェクトによれば、Qwen3-30B-A3B-Thinkingから初期化したモデルは、教師ありファインチューニング後にSWE-bench Verifiedで64.3％に到達した。強化学習後には67.5％に達したという。

SWE-bench Verifiedは、エージェントが再現可能なリポジトリ環境で実際のGitHub課題を解決できるかを検証する。スコアはベンチマークのバージョン、ハーネス、推論設定、評価手順に依存するため、比較には手法上の厳密な整合が必要となる。

Microsoftは、この結果を同程度の規模を持つオープンモデルの中で新たな最高水準だと説明している。この限定は重要だ。この結果は、異なる計算予算や非公開のスキャフォールディングを用いるクローズドモデルを含め、あらゆるエージェントシステムに対する優位性を示すものではない。

それでも、ランキング上の位置よりも仕組みのほうが興味深い。部分的な進捗から学習する手法と、有益な報酬変動を得るためのサンプリングは、他チームも独立して検証できる技術だ。その価値は、報告された単一のスコアだけに完全に依存するものではない。

1つの環境が大きく異なる3種類のエージェントを支える

この3つのレシピは、モデル規模、インターフェース、タスク構造、報酬設計が変化しても、インフラの再利用が成立するかを検証する。

コーディングは最大規模の実証例だが、それだけではない。Orchard-GUIは、ブラウザインターフェースと対話する40億パラメータの視覚言語モデルに、同じ環境抽象化を適用している。

このレシピでは、およそ400件の蒸留済み軌跡と2,200件のオープンエンド型タスクを使用したと報告されている。Microsoftによると、得られたモデルはWebVoyagerで74.1％、Online-Mind2Webで67.0％、DeepShopで64.0％の成功率を達成した。

これらのベンチマークは、異なる形態のWeb操作を対象としている。ブラウザエージェントは視覚的な状態を解釈し、行動を選択し、Webサイトの応答に適応しなければならない。コーディングタスクとは異なり、成功はテスト可能なパッチの生成ではなく、動的なインターフェースのナビゲーションに左右される場合がある。

報告されたデータ量は、ソフトウェアエンジニアリング用コーパスより大幅に少ない点で注目される。これは、焦点を絞ったレシピと安定した環境があれば、パラメータ数で最大級のプロプライエタリシステムに匹敵しなくても、小規模モデルの競争力を高められるというMicrosoftの主張を支えている。

ただし、ベンチマークでの成功は、テスト分布外での信頼できるブラウジングを保証しない。Webサイトは変化し、インターフェースは曖昧な状態を示し、小さな視覚的差異でもエージェントを別の行動へ誘導しうる。評価者には、タスク完了の正確な定義も必要となる。

3つ目のレシピであるOrchard-Clawは、パーソナルアシスタントエージェントを対象とする。論文によれば、Qwen3-30B-A3B-Thinkingをバックボーンに用い、約200件の合成タスクを使用する。

Microsoftは、Claw-Evalでpass@3が59.6％だったと報告している。Pass@3では、エージェントに最大3回の試行を許可し、少なくとも1回が成功すればタスクを成功と数える。より強力なZeroClawハーネスでモデルを動作させた場合、この結果は73.9％まで上昇する。

この差は、エージェントベンチマークに関する本質的な教訓を示している。モデルはエージェントシステムの一部にすぎない。ハーネス設計、ツールの形式、再試行の挙動、コンテキスト管理、評価ルールは、最終結果に大きく影響しうる。

これは小規模モデルに関する主張も複雑にする。効果的なインフラに囲まれれば、コンパクトなポリシーでも高い性能を発揮できるが、システム全体の運用要件は依然として厳しい可能性がある。パラメータ数だけでは、導入コストや複雑性を測れない。

3つのレシピを合わせることで、単一のコーディングベンチマークの3つの変種よりも、移植性に関する説得力のある検証となる。テキストと視覚、決定論的テストとオープンエンドなインターフェース、さらに異なるモデル規模をまたいでいる。

共通レイヤーが、すべての領域を同一のものにするわけではない。各レシピには、それぞれ独自のデータ収集、報酬計算、モデルバックボーン、エージェントハーネスがある。再利用されるのは、こうしたタスク固有の選択より下位の層だ。

この境界設定は妥当だ。汎用的な環境サービスは、ブラウザタスクとリポジトリ修復が同じ成功基準を持つかのように扱うことなく、ライフサイクルと通信の基本要素を標準化すべきである。

より大きな問いは、外部チームがこの分離を再現できるかどうかだ。社内研究システムは図ではモジュール型に見えることが多いが、文書化されていない慣例、クラウド構成、データ準備手順に依存している場合がある。コミュニティでの利用が、インターフェースが真に移植可能かを明らかにするだろう。

オープンソースという主張は、なお再現性の試練に直面している

公開されたアーキテクチャと強力なベンチマーク結果は、オープンな研究リリースの始まりにすぎない。

論文は、広範な実装詳細、アルゴリズムの説明、実験設定を提供している。Microsoftのプロジェクト資料も、研究者、モデル、タスクの出所、主要な評価結果を明示している。

しかし、実用上のオープン性には複数の層がある。研究者には、アクセス可能なコード、インストール手順、互換性のあるデータセット、モデルチェックポイント、環境イメージ、ライセンス、そして実験を再現するために十分な構成の詳細が必要だ。

データセットページには現在、リリースを保留しておりデータを再アップロードする予定だという通知が表示されている。文書化されたスキーマは正確だが、最終形態を表していない可能性があるとしている。チームは、それを前提としたパイプラインを設計する前に、ページの状態を確認すべきだ。

この保留は研究そのものを無効にするわけではない。ただし、特に価値が軌跡収集に大きく依存するソフトウェアエンジニアリングのレシピについて、即時の再現性を制限する。

ライセンスにも慎重な注意が必要となる。データセット文書は、軌跡が独自のライセンスを持つ上流リポジトリを参照していると警告している。パッチ、テスト資料、派生物を再配布する研究者は、それらの条件を個別に確認しなければならない。

セキュリティももう1つの制約だ。エージェント訓練では、モデルが生成した行動を意図的に実行する。隔離された環境であっても、ネットワークポリシー、リソース制限、認証情報の制御、イメージスキャン、クリーンアップ手順が必要となる。

論文はネットワーク分離と障害処理の仕組みを説明しているが、各導入環境は独自の脅威境界を管理する。公開リポジトリを扱う研究クラスターは、プライベートコードや社内ツールを含む企業環境とは異なるリスクを持つ。

ベンチマーク汚染を決定的に排除することは、依然として難しい。教師モデルが事前学習中に公開された課題、パッチ、または関連コードに遭遇していた可能性がある。非公開の評価テストは一部のリスクを減らすが、記憶に関するあらゆる疑問を解消するわけではない。

回顧的なクレジット割り当て手法も別の不確実性を加える。教師モデルは、中間ステップが成功確率を高めたかを推定する。こうした推定が有用なラベルとなるのは、教師が軌跡とテスト結果を信頼性高く解釈できる場合に限られる。

誤った推定は、もっともらしいが無関係な行動に報酬を与えうる。また、価値が後になって初めて明らかになるステップを見落とす可能性もある。独立したアブレーションでは、部分的な失敗データによる性能向上が、モデル規模、教師の品質、データセット構成によるものと比べてどの程度かを検証すべきだ。

Balanced Adaptive Rolloutにも同様の精査が必要となる。有益な報酬変動を持つグループを選択すれば訓練効率を改善できるが、実際の環境障害はポリシーの失敗に見えることがある。タイムアウト、コンテナエラー、壊れたテストが、誤解を招く報酬になってはならない。

Microsoftは、再試行ロジック、タイムアウト制御、使用不能なグループ向けのフィルターを報告している。外部チームは、こうした保護策が異なるクラスター、ワークロード、タスク分布でも有効に機能するかを判断する必要がある。

したがって、報告された数値は一般性の最終的な証明ではなく、設計を支持する証拠として読むべきだ。独立したインフラで再現されれば、その主張は強まる。新たな領域での結果は、環境抽象化が3つの準備済みレシピを超えて拡張できるかを検証することになる。

最も重要な成果は、別のベンチマーク記録ではないかもしれない。研究者が各実験の基盤となる仕組みを再構築せずに訓練手法を比較できる、共有された実験基盤になる可能性がある。

研究者が次に注目すべき点

Orchardが一般的な研究インフラになるのか、それとも印象的なMicrosoftの参照実装にとどまるのかは、3つのシグナルが決める。

第1のシグナルはリリースの完全性だ。研究者は、データセットアクセスの復旧、安定したコードリポジトリ、再現可能なインストール手順、モデル成果物、バージョン管理された環境定義を注視すべきである。

完全なリリースは、小規模チームでもシステムを再利用できるというMicrosoftの主張を強める。ギャップが続けば、その主張は弱まる。エージェント訓練で最も困難な部分は、多くの場合データ準備と運用構成にあるためだ。

第2のシグナルは独立した再現だ。説得力のある検証では、公開されたレシピを別管理のインフラ上で使用し、ベンチマーク結果と総リソース要件の両方を報告することになる。

見出しとなった正確なスコアに一致させることだけが有用な成果ではない。研究者は、セットアップ時間、サンドボックスの障害率、軌跡のスループット、計算消費量、ハーネス選択への感度を文書化すべきだ。こうした測定によって、再利用が意味のある節約を生むかが明らかになる。

独立した実験では、クレジット割り当てファインチューニングの寄与も分離すべきだ。比較では、成功した軌跡のみ、未解決の完全な軌跡、選択された進捗セグメントを用いて、同等のモデルを訓練できる。

同じアプローチは適応型ロールアウトにも当てはまる。モデル、タスク、報酬関数、予算を一定に保ちながら、固定サンプリングとバランスサンプリングを比較できる。これにより、この手法が生成された軌跡あたりでより多くの学習シグナルを生むかが分かる。

第3のシグナルは、Microsoftが準備した領域を超えた採用だ。新しい環境、特に異なるツールや報酬構造を持つ環境が、最も強力な検証となる。

セキュリティ分析、データ作業、科学ワークフロー、オフィスアプリケーションは、もっともらしい候補だ。それぞれ、リポジトリ修復やブラウザナビゲーションとは異なる環境要件をもたらす。再利用に成功すれば、この抽象化が真にハーネス非依存であるという主張を支えることになる。

競合他社の反応も重要だが、主題ではなく補足的な証拠にとどめるべきである。他のエージェント訓練プロジェクトが互換性のある環境インターフェースを採用したり、代替バックエンドを公開したり、軌跡形式を標準化したりする可能性がある。

フレームワークの乱立よりも、相互運用性のほうが大きな価値を生む。研究者は、すべての行動・観測形式を変換することなく、データセット、ポリシー、評価器をシステム間で移動できるようになる。

一方で開発者は、このリリースをすぐに使える本番エージェントと解釈すべきではない。このプロジェクトは、ポリシーの作成と評価のための研究インフラだ。本番システムには依然として、アプリケーションロジック、ユーザー権限、監視、フォールバック動作、セキュリティレビューが必要となる。

企業の購入担当者にとって重要な問いは、このフレームワークが1つのベンチマークで勝つかどうかではない。モジュール型の訓練インフラが、単一のプロプライエタリモデルやベンダー管理の評価スタックへの依存を減らすかどうかだ。

研究者にとって、次の実践的なステップはより絞られている。research paperを確認し、利用可能な成果物を検証したうえで、既存の評価環境に合うレシピを1つ選ぶことだ。タスク性能と併せて運用コストも測定する。

Microsoftは明確な提案を示した。環境が隠れたプロジェクト内部の仕組みではなく、再利用可能なインフラとなるとき、オープンなエージェント研究は進展する。今、コミュニティはその提案の難しい後半を検証しなければならない。独立したチームは結果を再現できるのか。その仕組みを新たなタスクへ移し、Microsoft自身の環境を離れても、約束された効率性を維持できるのか。