本文へ
ハクソク

世界を動かす技術を、日本語で。

アンリアルエージェント

元記事: 原文(unreallabs.ai)

概要

Unreal Agent は、AIエージェントのコスト効率と応答速度を大幅に向上。 非同期ツール呼び出し によるモデル負荷軽減とユーザーステアリングの即時反映を実現。 Codex・Piと比較し20〜40%のコスト削減 を達成。 柔軟なSDK設計と堅牢なセキュリティ方針。 GitHubリポジトリ で詳細・導入方法を公開。

Unreal Agentの特徴と技術背景

  • AIエージェントのフロンティアコスト効率 を追求した設計思想
  • 非同期ツール呼び出し方式 により、モデル側でのツール管理負担を解消
  • ユーザーからの ステアリングメッセージ を即時に受け入れるハーネス設計
  • ツール呼び出しの完了待ち やポーリング、ハートビート管理が不要
  • 複数ツールの同時実行・並行処理による 実用的なワークフロー実現
  • イベントログ管理 ：ツール呼び出し時に即座に「進行中」記録を追加、完了時に結果をセッションログへ反映

コスト効率とベンチマーク結果

  • モデルターン数とトークン消費量の削減 でコスト削減を実現
    • ハーネスの最小フットプリント とツール出力最適化
    • サブエージェントや複雑なワークフロー不使用 によるシンプル設計
  • 非同期ツール呼び出し により、1ターンで多くのツール作業を実施
  • Codex比最大40%・Pi比最大20%のコスト削減 を実証
  • 主なベンチマーク（Harbor上で実施）
    • Terminal-Bench 4.0 ：Unreal Agent 57.9%、Codex 57.9%、Pi 55.0%
    • SWE-Atlas Codebase QnA ：Unreal Agent 65.8%、Codex 63.3%、Pi 64.0%
    • DeepSWE 1.1 ：Unreal Agent 72.4%、Codex 69.0%、Pi 69.6%
    • Agents’ Last Exam ：Unreal Agent 30.0%、Codex 29.0%、Pi 29.0%

Unreal Agentハーネス設計の動機とアーキテクチャ

  • CLIベースSDK （例：Claude Agent SDK）の運用課題
    • ローカルセッションやサブプロセス前提 の設計が本番環境に不向き
    • ライフサイクル管理の自作 が必要
  • 複数プロバイダ対応時の APIモード切替やSDKアップグレード互換性問題
  • 依存関係の肥大化 による保守・サプライチェーンリスク
  • セキュリティ・承認管理 はハーネス外での制御（ホスト許可/拒否、アクセストークン、承認ゲート付きプロキシ等）が堅牢

Unreal Agent SDKの導入方法

  • Goライブラリ として直接組み込み可能

  • Runner実行ファイル （claude -pやcodex exec類似）

  • Harbor互換ベンチマークランナー 提供

  • 詳細・導入手順は 公式GitHubリポジトリ 参照

    • https://github.com/unreallabsai/unreal-agent

まとめと今後の展望

  • ハーネス設計自体が研究分野 として今後も発展可能性
  • さらなるアイデア・最適化の余地 が多数
  • コスト効率・応答速度・拡張性 を重視するAIエージェント開発者への推奨

お問い合わせ

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

ヘッドラインのグラフ、ちょっと変だね。なんでAstra xhighでのハーネスをCodexとAstra maxで比較してるんだろう？ --- それと、OpenAIがハーネスに非同期ツール呼び出しのサポートを追加したことも注目すべきだね。これはこのアプローチと1:1ではないけど、似たようなものを提供できるように徐々に進化してる。Codexがこんなにトークンを使う大きな理由は、始めたポーリングタスクを無駄にホットループしてるからなんだよね。全く良い理由がないのにね。私もCodexのフォークでそれを直したし、1月か2月にやったんだ。誰かが欲しいなら、このパッチをリベースしてるよ: https://github.com/tekacs/codex/commit/9ffcf8db9078eae43d411... これ、Unrealがここで示してるトークンの節約と同じくらいの効果があるよ。 --- 私のハーネスは、~2月からUnrealが使ってるアプローチのちょっとおしゃれなバージョンを使ってるけど、確実にうまくいってるし、Astraや最近のモデルの方が非同期ツール呼び出しにもっと対応してるから、スムーズさも全然違うね。

└

Codexのポーリングを減らすために、~/.codex/config.tomlにこれを追加したよ: [features.multi_agent_v2] enabled = true wait_agent_enabled = true min_wait_timeout_ms = 10000 # 10s default_wait_timeout_ms = 300000 # 5m max_wait_timeout_ms = 3600000 # 1h これでうまくいって、使用量が減ったみたい。Astraを目標を使って約5時間動かしたら、最後の30%の使用量を使ったよ。そして、今GPT-6のSolとLunaがリリースされたんだけど（基本的に5.6 SolとLunaだけど、ちょっと良くて50%安い） ;_;

└

ヘッドラインチャートはちょっと手抜きだったね、指摘ありがとう！更新するよ。エージェントコーディングインデックスに組み込まれている各ベンチマークは、ua / codex / piの間でxhighで比較されて、ヘッドラインの改善はxhighで計算されたんだけど、エージェントコーディングインデックスのパレートチャートはデフォルトでcodex maxを含むから混乱しちゃったんだ。

Epicが超人気のUnreal Engineを出荷するとき、商標の問題があるみたいだね。

└

でも、Unrealみたいな一般的な言葉を商標登録するのは無理だと思うよ…。

└

一番下までスクロールしないと、これがUnreal EngineやEpicとは全く関係ないことに気づかなかったよ。Epicがソフトウェアエンジニアリングを助けるために「Unreal Labs」を作ってハーネスを作ってる可能性は全然あると思う。これ、同じドメインにいるし、他の人たちも私と同じように混乱してたみたいだから、商標の問題が進行中のように見えるね。

└

笑、これを読むまでこれがUnrealとは関係ないって気づかなかったよ。みんな、お願いだから、立ち上げる前に弁護士に相談して！

この分野はまだまだ開拓されてないと思う。モデルは面白いけど、ここ数年ずっと研究してきたことにめっちゃハマってるんだ: フラクタルツール発見：エージェントが「もっと深く掘り下げて」特定のツールを見つけられるツールの分類法。無駄に多いツールで文脈が汚れるときに役立つよ。スプレーツリーを活用するのが好きで、エージェントやハーネスの文脈ではあまり使われてないと思う。最近使ったワークフローやツールチェーンはまた使われることが多いから、検索階層のトップにそれらを置くのは素晴らしい最適化だよ。仮想コンテナ化されたノートブック：サンドボックス化された(WASI) Pythonノートブックで動くモデルはすごい。ローカルモデルも（十分な時間があれば）通常は良い解決策に収束するし、ツールやリソース、ファイルシステムをマウントできるのも、個人的にはまだまだ開拓されてないと思う。ここでの問題は、ネイティブなもの（numpyやpandasなど）をコンテナ内で動かすのが悪夢（または不可能）ってことだね。とにかく、この分野で真剣に取り組んでる人たちを見るのは嬉しいよ。もし誰かコラボしたいなら、気軽に連絡してね :) 私も今、仕事や契約の仕事を探してるところ。楽しい時代が待ってるよ。

└

それがフラクタルな理由は何？

└

フラクタルツールの発見って面白いアイデアだね！もうエージェントハーネスに実装して成功したことある？最初の印象は、エージェントが自分自身をフォークするみたいな感じで、サブエージェントを立ち上げて、その応答をメインエージェントに返すってことかな。

└

フラクタルツールの発見の代わりにスキルツリーアプローチも探ってみたけど、フロントマターにXREFの同等のものを入れると結構うまくいくみたいだね。

└

これをテストするためのワークフローやベンチマークはあった？実際に役立つユースケースがあるかどうかに興味があるんだ。

Hacker Newsで議論の続きを見る