OpenHands：AIソフトウェアエージェントのためのオープンプラットフォームと、それが財務自動化に意味すること
TheAgentCompany、InvestorBench、そして増え続ける評価論文の下層にある足場としてOpenHandsに遭遇し続けていますが、まだ一次論文を読んでいませんでした。これはこの分野の他の部分が静かに構築されているインフラであり、その上に構築された個々のベンチマーク結果よりも、それが実際に何を提供し、どこが不足しているかを理解することの方が重要です。
論文について
OpenHands（Wang et al., 2024; ICLR 2025）は、汎用的なソフトウェア開発者として機能するLLMエージェントを構築および評価するためのオープンソースプラットフォームです。Xingyao Wang氏とGraham Neubig氏を中心とする24名のチームによるこの論文の核心的な主張は、既存のエージェントフレームワークの多くは、研究コミュニティの共有基盤として機能するには、研究に特化しすぎている（ハードコードされたタスクループ）か、実用に特化しすぎている（クローズドソースまたは単一目的）かのどちらかであるということです。OpenHandsは、標準化されたランタイム、クリーンなエージェント抽象化、および15の統合された評価ベンチマークを1つのMITライセンスのリポジトリで提供することで、この問題を解決しようとしています。
ランタイムは、bashシェル、Jupyter IPythonサーバー、およびPlaywright制御のChromiumブラウザを含む、Dockerでサンドボックス化された環境です。エージェントは主に3つのアクションタイプを介して対話します。Python用のIPythonRunCellAction、シェルコマンド用のCmdRunAction、およびWebナビゲーション用のBrowserInteractiveActionです。マルチエージェント調整プリミティブであるAgentDelegateActionを使用すると、メインエージェントが特殊なサブエージェントを生成できます。デフォルトのバックボーンはCodeActであり、これは元々、コードがLLMエージェントにとって理想的な統一アクション空間であると主張する独立した論文として発表されました。プラットフォームには、一般的なCodeActAgentや特殊なBrowsingAgentを含む複数のエージェント実装が同梱されています。
主なアイデア
- ユニバーサルなアクション空間としてのコード: CodeActは、すべてのエージェントアクション（ファイル編集、API呼び出し、データ変換）をPythonまたはbashに統合し、LLMが最も重点的にトレーニングされた媒体と同じ媒体で推論できるようにします。これにより、関数呼び出しエージェントを悩ませる脆弱なJSONスキーマの脆さを回避できます。
- サンドボックス化されたDockerランタイム: すべてのエージェントは隔離されたコンテナ内で実行されるため、ホストマシンを危険にさらすことなく任意のコードを自由に実行できます。これは、実際の認証情報が渡される可能性のある本番環境の財務エージェントにとって必須条件です。
- 1つのハーネスに15のベンチマーク: SWE-Bench Lite（コード修復）、HumanEvalFix（バグ修正）、WebArena（Webナビゲーション）、GPQA（大学院レベルの推論）、GAIA（一般的なタスク解決）など10種類以上。これらを同じ場所に配置することで、都合の良い結果だけを抽出した評価を防ぎます。
- CodeActAgent + claude-3.5-sonnetがSWE-Bench Liteで26%、HumanEvalFixで79.3%を達成。BrowsingAgentはWebArenaで15.5%に達し、タスク固有のトレーニングなしで競争力のあるゼロショット結果を示しました。
- GAIAのパフォーマンス: GPTSwarmを使用して32.1%であり、人間のベースラインである92%を大幅に下回っています。これは、他のすべての汎用エージェントベンチマークが示す、人間とエージェントの60〜70ポイントのギャップと一致しています。
- コミュニティの規模: ICLR投稿時点で71.4KのGitHubスターと188人以上のコントリビューターを擁しています。TheAgentCompanyはOpenHandsを評価ハーネスとして採用し、事実上のベンチマークインフラとしての地位を確立しました。
維持されるもの、されないもの
サンドボックス化されたランタイム設計は、堅実なエンジニアリングです。エージェントの実行をDockerで隔離することは、後に実際の財務元帳への書き込みアクセス権が与えられる可能性のあるシステムにとって正しいデフォルト設定であり、ベンチマークが互換性のないリポジトリに分散されるのではなく、同じ場所に配置されていることは非常に有用です。
しかし、ベンチマークの範囲は、体系的というよりは野心的です。15のベンチマークは、結果をどのように集計または比較すべきかという明確なフレームワークなしに、大きく異なるタスクタイプと難易度にまたがっています。同じ論文内でSWE-Bench Liteの26%とHumanEvalFixの79.3%を並べて報告することは、同じエージェントが同時に平凡で優秀であるという印象を与えるリスクがあります。タスクは単に比較可能なものではありません。著者は、原則に基づいたマルチベンチマーク集計方法論を提供していません。
コードが正しいユニバーサルアクションフォーマットであるというCodeActの仮定には異論があります。これは開発タスクには適していますが、あらゆるアクションにPython/bashの仲介レイヤーを課すため、レイテンシが増大し、アクションのセマンティクスがコードにきれいにマッピングされない場合（曖昧なユーザー指示、自然言語のみのAPI）に破綻します。この論文では、非コードアクション空間との比較ベンチマークを行っておらず、その優位性がLLMバックボーンによる混同ではなく、本物であることを証明していません。
おそらく最も重要なギャップは、評価とデプロイメントの乖離です。SWE-Benchの26%という数字は、比較的クリーンで明確に指定されたベンチマークから得られたものです。コミュニティの報告やGitHubのイシュースレッドでは、曖昧なタスクや長期にわたる現実世界のタスクにおいて、信頼性が大幅に低いことが一貫して記述されています。これはTheAgentCompanyが文書化したのと同じ失敗モードです。この論文では、現実的なタスク指定のノイズの下で堅牢性を測定または向上させる方法については触れられていません。
なぜこれが財務AIにとって重要なのか
OpenHandsは、コミュニティが持っている共有エージェント基盤に最も近いものです。Bean LabsがBeancountエージェント用の評価インフラを構築する場合、ここにあるランタイムアーキテクチャ（Dockerサンドボックス、Python/bashアクション、プラグイン可能なLLMバ ックエンド）は、再構築するよりも採用する価値があります。AgentDelegateActionプリミティブは、トップレベルのオーケストレーターが、元帳読み取り用、異常フラグ立て用、人間がレビューする書き戻し提案用といった専門のサブエージェントに委任する財務エージェントパイプラインに自然にマッピングされます。
SWE-BenchとTheAgentCompanyの数値を合わせると、冷静な事実が浮き彫りになります。現在利用可能な最高のエージェントであっても、現実的で曖昧さのないソフトウェアタスクの約26〜30%しか完了できません。財務元帳の自動化はさらに困難です。トランザクションはしばしば曖昧であり、エラーの影響範囲は甚大で、ユーザーの意図は不十分に指定されることが多いからです。正しい推論は、エージェントの準備ができていないということではなく、最初の実用的なデプロイメントは、自律的な多段階の元帳編集ではなく、厳密に範囲を絞った1回限りのワークフロー（カテゴリの提案、照合のフラグ立て）になるべきだということです。
次に読むべきもの
- ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — 安価なモデルと高価なモデルを組み合わせ、不確実性が高い場合にのみ高価なモデルに委ねる手法。OpenHandsスタイルのエージェントが、いつBeancountの書き戻しを人間のレビューにエスカレーションすべきかを判断する方法に直接応えます。
- FinTrace: Holistic Trajectory-Level Evaluation of LLM Tool Calling for Long-Horizon Financial Tasks (arXiv:2604.10015) — 34の財務シナリオにわたる800のエキスパートが注釈を付けたタスクシーケンス。OpenHandsに欠けている、財務特有の長期ツール利用のための評価方法論を提供します。
- FinMCP-Bench: Benchmarking LLM Agents for Real-World Financial Tool Use under the Model Context Protocol (arXiv:2603.24943) — 65の実用的なMCP財務ツールにわたる613のサンプル。OpenHandsのランタイム上に構築されたBeancountエージェントが、実際のMCPデプロイメントでどのように評価されるかに直接関連します。
