同じモデルでも完了率は30%から81%へ――CUGA・Hermes・Deep Agentsのハーネス比較
同じモデルでハーネスを変えると、AppWorld完了率は大きく変わる
IBM Researchは、CUGA、Hermes、Deep Agentsに同一のオープンウェイトモデルGLM-5.3-flashを接続し、AppWorldの90タスクで比較した。AppWorldは9つのアプリと457のAPIをまたぐマルチステップ課題を含み、ログイン、APIドキュメントの確認、ページング、複数アプリ間の状態変更などを評価する。業務アプリそのものを再現したベンチマークではないが、企業向け自動化に必要な能力の一部を測る代理指標として位置づけられている。
実験は30シナリオ、各タスク1回の試行で、全実行にHarbor評価フレームワークを使用した。結果は次の通りである。
| ハーネス | 成功タスク（TGC） | 全バリアント成功シナリオ（SGC） |
|---|---|---|
| CUGA | 73/90（81.1%） | 20/30（66.7%） |
| Hermes | 42/90（46.7%） | 8/30（26.7%） |
| Deep Agents | 27/90（30.0%） | 2/30（6.7%） |
TGCが個々のタスクの成功率を示す一方、SGCはシナリオ内の3バリアントすべてが成功した場合にのみカウントされる。そのためSGCは、単発の成功だけでなく、関連する複数タスクを一貫して処理できるかを見る指標となる。CUGAと他2構成の差がSGCでさらに広がっていることは、マルチステップ業務での安定性を検討するうえで重要だ。
ただし、この数値を各プロジェクト全体の優劣と解釈するべきではない。記事自身が、Hermesは常時稼働する個人アシスタント、Deep Agentsは長い調査タスクに適した設計だと説明している。さらにCUGAはAppWorld向けの設定を使い、Deep Agentsでは469ツール向けにツール選択、コンテキスト要約、To-doリスト、リトライ、呼び出し上限を構成し、不正形式のモデル応答で実行が終了しないよう小規模な修正を加えている。タスク標本は90件で、ポリシー適用も評価していない。比較結果は、ハーネスとワークロードの適合性を示す実験として読むのが適切だ。
CUGAの差を生む設計：判断を絞り、実行前後に検査する
CUGAのAppWorld構成では、モデルに全469ツールを一度に提示するのではなく、タスクをアプリ単位のステップへ分割し、各ステップには対象アプリのツールと共通ツールを中心に見せる。追加のツールが必要になれば、find_toolsによるツール短縮・検索を利用する。これにより、モデルが候補ツールの中から選ぶ負担を減らし、不要なツール選択の誤りを抑える設計になっている。
実行経路は、準備、モデル呼び出し、実行を繰り返すコンパクトなループを基本とする。モデルはCodeAct方式でPythonコードを書き、アプリAPIを呼び出す。コードは時間制限付きの制限環境で実行され、データを変更するコードブロックは実行前に検証される。実行後には自動リフレクションが結果を見直し、必要なら計画を修正する。ページングについても、一覧取得が1ページ分で終わり次ページが要求されていないケースを検出する監査機能がある。
これらは単なるプロンプト追加ではなく、エージェントの処理経路に設けられた制御点である。タスク分解は作業範囲を小さくし、フォーカスされたツール集合は選択空間を絞る。実行前検証は状態変更に対する誤りを未然に確認し、実行後検査はAPI応答やページングの取りこぼしを修正する。モデルの能力だけに依存せず、誤りが生まれやすい地点でハーネスが検査することが、記事の結果を理解するうえでの主要な設計上のポイントだ。
CUGAのループは、単一エージェントのCugaAgentから、複数のエージェントを協調させるCugaSupervisorへ拡張できる。連携先はローカルまたはA2A経由のリモート構成とされている。したがって、個々のツール呼び出しだけでなく、複数エージェントを含む構成でも同じ制御の考え方を使える。
エンタープライズ利用で重要な、実行時ポリシーと配置境界
CUGAが企業向けとして強調するのは、業務ルールをシステムプロンプトだけに置かず、ハーネスが実行時に扱えるポリシー層へ移すことだ。記事は、支払い承認や顧客PIIの組織内保持などをプロンプト上の指示だけにすると、モデルの誤読、ユーザーによる誘導、タスク途中の注入メッセージに影響されうると論じる。
ポリシーは処理の複数段階に配置される。Intent Guardはエージェントが動く前に該当する要求を拒否または応答する。Playbookは手順を案内する。ツール実行時のTool Approvalは人間の承認まで処理を停止し、実行予定のコードを提示する。Tool GuideとToolGuardはツール実行前にガードコードを動かし、違反時にはツールを呼び出さずポリシー違反を返す。最後にOutput Formatterが応答を承認済みの形式に整える。
ここでは「指針」と「強制」の違いが重要になる。Playbookはモデルを導く一方、承認待ちやToolGuardはランタイム側で処理を止める。記事中のPolicy Playgroundでは、「Pay everything I owe.」という要求に対し、ポリシーなしのエージェントは回収中の否認済み請求を含めて90ドルを支払い、ポリシーありのエージェントは承認を保留した後、支払うべき10ドルだけを処理した例が示されている。
配置面では、CUGAはApache 2.0で提供され、OpenAI互換エンドポイントを利用できる。ローカル、プライベートまたはソブリンクラウド上のKubernetes、エアギャップ環境での実行に対応すると説明されており、OIDCサインインとチャット・管理の分離ロールも挙げられている。コスト管理には予算上限があり、実行レシートにはトークン数、ツール呼び出し数、実行時間を記録できる。IBM Sovereign Coreは、顧客境界内でエージェントを稼働させる基盤としてCUGAを利用する。
なお、記事は過去の実績として、ホスト型モデルを使ったCUGAがWebArenaで2025年2月から9月、AppWorldで2025年7月から2026年2月まで1位を維持したと述べている。今回のGLM-5.3-flash比較とは条件が異なるため、同一のベンチマーク結果として混同すべきではない。
開発者・エンジニア視点での考察
-
評価では、モデル固定に加えて構成差を明記する。 同一モデルの比較はハーネスの影響を切り分ける有効な方法だが、今回も各実装の設定は同一ではない。ツール公開範囲、ミドルウェア、リトライ、呼び出し制限、例外修正を記録し、タスク数や試行回数、シナリオ単位の成功率も併記すれば、再現性と比較可能性が高まる。記事が公開しているHarbor forkの
harbor-eval設定は、追試の出発点となる。 -
業務ルールを「指示」と「実行阻止」に分けて実装する。 手順を守らせるだけならPlaybookのような誘導が適するが、支払い上限やPIIの扱いなど、違反を許容できない条件はツール呼び出し前のガードや人間の承認へ置くべきだ。設計時には、どのルールがモデルの判断に委ねられ、どのルールがランタイムによって強制されるのかを明確にし、ポリシー違反時にツールが実際に呼ばれないことをテストする。
-
ツール数・状態変更・観測可能性を一体で設計する。 大量のツールを一括提示するより、タスク分解と段階的なツール選択でモデルの判断空間を制御する方法がある。さらに、実行前検証、ページング監査、結果のリフレクション、トークン・呼び出し数・所要時間の記録を組み合わせれば、誤動作の予防と原因分析の双方を支えられる。選定時は単純なタスク成功率だけでなく、複数タスクの一貫性、コスト、監査要件、実行環境の境界を、実際のワークロードに合わせて評価したい。
Source / 元記事
この記事について
この記事は、公開されているニュース、論文、公式発表、RSSフィードなどをもとに、AIが要約・補足調査・考察を行って作成しています。
元記事の完全な翻訳・逐語的な要約ではなく、AIによる背景説明や開発者向けの考察を含みます。
重要な技術仕様・価格・提供状況などは、必ず元記事または公式情報をご確認ください。
