メインコンテンツまでスキップ

非同期ファーストのエージェントハーネス: Unreal Agent が変えるもの

上級

2026 年 9 月 22 日、Unreal Labs は Unreal Agent — Go で書かれた MIT ライセンスの エージェントハーネス — をリリースし、Terminal-Bench 4.0 で Codex の合格率に並びつつ 2,350 ドルに対して 1,428 ドルというベンチマーク実行結果を公開しました。同じモデル、 同じタスク、同じスコアで、39% 少ない金額です。

興味深いのはその数字ではありません。お金がどこに消えていたのか、です。Unreal Agent の中心的な主張は、コーディングエージェントに支払う額の大きな部分は推論ですらない — それはモデルがループの中に座って、自分の待ち時間を管理している分だ、というものです。 このページはその仕組みについてのものです。あなたが作るあるいは買うどんなハーネスにも、 Unreal Labs とは無関係なものも含めて、転用できるからです。

What you'll learn
  • 非同期ツール呼び出しのイベントフローを理解する: 何が、いつセッションログに追記され、モデルが実際に何を見るのか
  • 出力の長さではなくターン数こそがエージェントのコストを動かす単位である理由と、それを自分のループで測る方法を学ぶ
  • 公開されたコスト表を誠実に読む: ドルの数字が何をカバーし、何をカバーしていないのか
  • Unreal Labs が意図的に作らなかった 3 つの設計（サブエージェント、ワークフロー、ハーネスレベルのセキュリティフック）と、それぞれの論拠を知る
  • すでに使っているハーネスが何であれ、転用可能なルールを自分のエージェントに適用する

一文で言うと​

Unreal Agent は MIT ライセンスの Go 製ハーネスで、すべてのツール呼び出しを追記専用の セッションログに進行中イベントとして追記し、実行はバックグラウンドで続行させます。そのため モデルはブロックもポーリングもしません — これがターンを削り、そしてターンこそが実際に 支払っているものです。

仕組みを正確に​

こちらが通常の同期エージェントターンです:

  1. モデルがツール呼び出しを出す。
  2. ハーネスがツールを実行する。ループは停止する。
  3. ツールが戻る。ハーネスが結果を追記する。
  4. ハーネスがトランスクリプト全体を添えてモデルを再度呼ぶ。

同じターンを Unreal Agent で見ると:

  1. モデルがツール呼び出しを出す。
  2. ハーネスは即座にその呼び出しが進行中であるというイベントをセッションログに追記し、 バックグラウンドで実行を開始する。
  3. 実行は続く。モデルはさらに呼び出しを出す自由がある。
  4. ツールが完了すると、その結果がログに追記される — そしてその追記が次のモデル呼び出しを トリガーする。

モデルは実行中の状態を見て、次に最終結果を、自分のトランスクリプトの中で順番に見ます。 「これを待て」とエンコードする必要はなく、ポーリングを出すこともなく、ハートビートの帳簿を 推論の中に抱え込むこともありません。Unreal Labs の表現では、このハーネスはモデルが 「ポーリングや待機にトークンを浪費することなく、モデルのターンあたりより多くの重いツール呼び出しを 出せる」ようにします。

これがアイデアのすべてです。小さなものです。そして、ほとんどのハーネスが間違える部分でもあります。 同期ループのほうが書くのに当たり前だからです。

なぜこれがお金として現れるのか​

モデルのターンごとに、蓄積されたトランスクリプトが再送されます。30 ターンのエージェント実行は 1 回の呼び出しの 30 倍のコストではありません — 30 回の呼び出しにわたる成長し続けるコンテキストの 総和におよそ等しいコストです。したがってターン数は線形というより二次に近いコスト要因であり、 システムプロンプトを削って節約できる分を凌駕します。

公開された実行結果が、ドルと並べて何を報告しているか見てください:

ベンチマーク合格率Unreal Agentターン数CodexPiPi のターン数
Terminal-Bench 4.057.9%$1,42828$2,350$1,82744
SWE-Atlas Codebase QnA65.8%$93616$1,303$1,033—
DeepSWE 1.172.4%$1,36726$1,633$1,584—
ALE-CLI30.0% 完全合格$217————

Terminal-Bench 4.0 では 28 ターン対 Pi の 44 ターン — ターン数で 36% の削減に対し、Pi との比較で コスト 22% の削減、Codex との比較で 39% です。因果の列はターンの列であり、ドルの列はその帰結です。

これは AILmanac が反対側から扱っているのと同じ教訓です （エージェントがトークンを燃やす理由）: エージェントで 高くつくのは答えではなく、読み直しです。

Pro tip
  • 他の何よりも先にターン数を計測すること。トークンだけをログに取っていると、プロンプトを最適化してループを見落とす。
  • 有用な診断: エージェントのターンのうち、ツール呼び出しもユーザーに見える出力も生まなかったものを数える。それらは純粋なループのオーバーヘッド — 待機、確認、再計画 — であり、非同期ハーネスが取り除くのはまさにそれ。
  • 並列実行できるツールは効果を増幅する。最も遅い 3 つのツールが同時に走れるなら、同期ループは実時間でもターン数でも 3 つ分を直列に支払うことになる。

彼らが意図的に作らなかった 3 つのもの​

コードよりも論拠のほうが重要です。これらは、あなたがすでに動かしているどんなハーネスにも 適用できる議論だからです。

1. サブエージェントなし、ワークフローなし​

Unreal Labs は、サブエージェントへの委譲や事前定義されたワークフローではなく「率直な非同期 ツール呼び出しモデル」を選びました。その理由は、ツール呼び出しが本当に非同期になれば、 サブエージェントが担っていたことの大半 — 親を止めずに物事を並列に走らせること — はすでに ループが処理している、というものです。そうなるとサブエージェントは、もはや存在しない問題のために コンテキストの分割、結果のマージ、そして自分自身のターンのオーバーヘッドを加えるだけになります。

これは一つの立場であって、唯一の立場ではありません。マルチエージェント設計は、単なる並列性ではなく 本当に隔離されたコンテキストが欲しい場面では依然として勝ちます。ただし「2 つのことを同時に やるにはサブエージェントが必要だ」という主張は、まず非同期ループに対して再検証する価値があります。

2. ハーネスレベルのセキュリティフックなし​

これはローンチ投稿で最も鋭い議論であり、その形を引用する価値があります。ハーネスのフックに依存した セキュリティと承認は「ハーネスの外にある決定論的な環境やサンドボックスの制約より、保守を多く要し、 堅牢さに欠ける傾向がある」。

彼らが代わりに推奨するのは、許可ホストと禁止ホスト、粒度の細かいアクセストークン、そして承認ゲートを 備えたプロキシです。言い換えれば、エージェントが物理的に手を届かせられない場所に制御を置くということです。

いったん述べられてしまえば論理は単純です。ハーネスのフックはエージェントループと同じプロセスで 走るコードであり、エージェントがすでに呼び出せるツールをゲートしています。サンドボックスの境界は カーネルやネットワークによって、エージェントよりも下のレイヤーで強制されます。あなたのエージェントが bash ツールを持っているなら — そして Unreal Agent は持っています — プロセス内の許可リストは 壁ではなく減速帯です。AILmanac の ローカルおよびハイブリッドエージェントのセキュリティ が、外側の境界を構築する方法を扱っています。

3. ベンダーのエージェント SDK なし​

Unreal Labs はベンダー SDK（Anthropic の Agent SDK が名指しされています）から離れました。 それらが「ローカルセッション、サブプロセス、そして本番利用にきれいには対応しないリソース制限」を 前提としているからです。

これは品質の議論ではなく、デプロイ形態の議論です。ローカル CLI セッションをモデルにした SDK は、 1 プロセス、1 マシン、1 ライフタイムを前提とします。本番のエージェントフリートが求めるのは、 プロセスより長生きし、別のマシンで再開できるセッションです — それこそが Unreal Agent の 追記専用でバージョン管理されたセッションストアが提供するものであり、セッションをフォークして 実行を分岐させることも含みます。

エージェントループの上に製品を作るなら、どの SDK に対しても問うべきはこれです: セッションは、それを作ったプロセスより長生きできるか?

アーキテクチャ、手短に​

このハーネスは意図的に小さく、明示的に組み替え可能です — ドキュメント化されたインターフェースの 背後にある 8 つの差し替え可能なコンポーネントです:

  • セッションインボックス — 入力を重複排除します。すべての入力はグローバルに一意で安定した 呼び出し元 ID を持つため、リトライが二重適用になりません。
  • コーディネーター — LLM のターンを所有し、オペレーションをディスパッチします。
  • セッションストア — 追記専用で永続化された履歴。フォークをサポートし、バージョン管理されます。
  • コンテキストビルダー — モデル入力を組み立てます。I/O を一切行いません。
  • LLM アダプター — プロバイダーと通信します。
  • ツールレジストリとトランスレーター — 呼び出しを同期的に検証し、「I/O を行ったりループを 停止させたりしてはならない」。
  • オペレーションマネージャー — 耐久性のあるバックグラウンド作業を実行します。

このリストの中で重い仕事をしていて、見落としやすい制約が 2 つあります。 コンテキストビルダーとツールトランスレーターは I/O を禁じられていることです。これこそが コーディネーターのホットパスを決定論的かつ非ブロッキングに保つものです — すべてのレイテンシは オペレーションへ押し出され、オペレーションこそが非同期であるよう設計されたものです。自分でハーネスを 作るなら、盗むべきルールはこれです。

ストレージ形式とオペレーションはバージョン管理されており、サポートされていないセッションバージョンは 再開時に明示的にエラーになります — 中途半端に読み込まれることはありません。これは耐久性のある 状態にとって正しい失敗モードであり、そうあるべき頻度より稀です。

組み込みのツール表面は 3 つのツールです: Bash、ViewImage、そして Skill-use — 最後のものは AILmanac が オープン標準としての SKILL.md で扱っている可搬なスキル形式に接続します。ツールが 3 つであることが要点です。小さくトークンの安い ツール表面は、コストの物語の一部です。

動かす​

Guided walkthrough1 of 5
  1. Go 1.27 以上のツールチェーンを用意し、cmd/ 配下のランナーを go install するか、クローンして同梱の Makefile を使います（make build、make test）。

インストールと実行（Unreal Labs のドキュメント化された使い方より）

go install github.com/unreallabsai/unreal-agent/cmd/unreal-agent-runner@latest

export OPENAI_API_KEY="..."
unreal-agent-runner -p 'Inspect this project and explain how to run its tests.'

別のプロバイダーに向けつつトランスクリプトを保存する

export UNREAL_HARNESS_LLM_PROVIDER=openrouter
export UNREAL_HARNESS_LLM_MODEL=<model-id>

unreal-agent-runner \
-workspace ./my-project \
-p 'Summarize this project.' > run.jsonl

ベンチマーク表を誠実に読む​

数字が精査に値するほど良いので、注意点を 4 つ挙げます:

  • すべての実行がベンダー自身のもの。 執筆時点で第三者による再現はありませんでした。
  • モデルは 1 つ。 公開されたすべての実行は GPT-6 Astra を xhigh reasoning で使いました。 非同期の優位性は一般化するはずです — それはモデルの性質ではなくループの性質だからです — しかし「はず」は「計測された」ではありません。
  • ドルはスイート全体の合計であり、タスクあたりのコストではありません。互いに比較可能ですが、 あなたのワークロードとは比較できません。
  • 合格率は上回ったのではなく同等。 主張は明示的に同じスコアで、より安くです。DeepSWE 1.1 では Unreal Agent は 72.4% を 1,367 ドルで報告し、Codex の 1,633 ドルに対して 19% の節約 — Terminal-Bench での 39% より明らかに小さい値です。優位性は、タスクがどれだけツール中心で どれだけ長時間走るかに比例して伸びます。ツール呼び出しの少ない短いタスクでは、ほぼゼロだと 思ってください。

最後の点が実務上の要点です。エージェントがツール呼び出しを 3 回して終わるなら、非同期はほとんど 何ももたらしません。30 分かけて 60 回するなら、2 つの列の差額をもたらします。

自分のエージェントに転用できるもの​

これらを使うために Unreal Agent を採用する必要はありません:

  • ターンを測る。 多くのチームがログに取っていないコスト変数です。
  • 遅いツールを非ブロッキングにする。 ハーネスが他の点で同期的であっても構いません。 即座にハンドルを返し、結果を後続イベントとして届けるのは、たいていのループの内側でできる変更です。
  • ホットパスを I/O フリーに保つ。 コンテキストの組み立てとツール呼び出しの検証は、 決してネットワークを待つべきではありません。
  • 承認をプロセスの外へ動かす。 ネットワークポリシー、スコープを絞った資格情報、ゲートするプロキシは、 bash ツールの隣に住むプロセス内の許可リストに勝ります。
  • ツール表面を縮める。 良いツール 3 つは、凡庸なツール 15 個よりターンあたりのトークンが安く、 それが毎ターン効いてきます。

Check yourself

0/5
  1. Unreal Agent では、モデルがツール呼び出しを出した瞬間に何が起きますか?
  2. エージェントループにおいて、出力の長さを削るよりターン数を削るほうが節約になるのはなぜですか?
  3. Unreal Labs が承認をハーネスのフックとして実装することに反対するのはなぜですか?
  4. コンテキストビルダーとツールトランスレーターは I/O を行うことを禁じられています。この制約は何をもたらしますか?
  5. どのような種類のワークロードで、非同期の優位性が最も小さいと考えるべきですか?
Enter キーまたはスペースキーでカードを裏返します。左右の矢印キーでカードを移動できます。用語を表示しました。
1 / 8
Key takeaways
  • エージェントループにおけるコスト変数はトークン数ではなくターン数。まずそれを計測すること。
  • ツール呼び出しを非ブロッキングにするとポーリングと待機のターンが消える — Terminal-Bench 4.0 で同じ合格率を 28 ターン対 44 ターンで達成したことが議論のすべて。
  • 優位性はツール中心度に比例する: Terminal-Bench で 39%、DeepSWE で 19%、3 回呼び出しのタスクでは約 0。
  • セキュリティはハーネスの外にある。bash ツールの隣にあるプロセス内の承認フックは減速帯であり、サンドボックスとゲートするプロキシが境界である。
  • コンテキストの組み立てとツールの検証を I/O フリーに保つこと。あらゆる待ちを耐久性のあるオペレーションへ押し出す。
  • 公開された数値はすべて 1 つのモデルでのベンダー実行。あなたのワークロードの計測結果ではなく、よく論じられた仮説として扱うこと。

出典と参考文献​

次へ​