AIエージェントの内部挙動を可視化する「NVIDIA NeMo Relay」――タスク成功の裏に潜む非効率をトレースで特定
要点
- NVIDIAは、AIエージェントの動作プロセスやライフサイクルを追跡・可視化する基盤技術「NVIDIA NeMo Relay」の活用手法を公開した。
- オープンソースのエージェント実行基盤「Hermes Agent」にNeMo Relayがネイティブ統合され、モデル呼び出しやツール実行の親子関係や所要時間を構造化データとして記録可能になった。
- 隔離されたDocker環境でのスクリプト実行や複数ツールを用いた調査タスクにおいて、OpenTelemetry連携による詳細なトレース検査が実証された。
- 評価ベンチマーク「Hermes ToolPerf」を用いたケーススタディでは、ハーネスの改修によってタスク成功率が向上する一方、呼び出し回数やレイテンシが増加するというトレードオフが可視化された。
米NVIDIAは2026年9月30日、公式技術ブログにおいて、AIエージェントの実行挙動を詳細に追跡・分析する可観測性レイヤー「NVIDIA NeMo Relay」の活用に関する技術解説を公開した。同社およびNous Researchの研究者らによって執筆された記事では、エージェントの実行制御基盤である「Hermes Agent」との連携を通じて、タスクの成否判定だけでは把握できない非効率な処理過程を浮き彫りにする手法が紹介されている。
タスク成功の裏に潜む非効率と可観測性の課題
AIエージェント（自律的にツールを選択・実行して課題を解決するシステム）は、最終的に正しい答えを出力できたとしても、内部で非効率な処理経路をたどっている場合がある。検索の失敗による再検索や、ファイルの切り詰めによる再取得といった無駄なステップは、最終結果が正しければ表面化しないものの、処理遅延（レイテンシ）を増大させ、不要なトークン消費を引き起こす。また、処理ステップの増加自体が潜在的な失敗リスクを高める要因にもなる。
記事では、エージェントの挙動を根本から改善するためには、タスクが完了したかどうかだけでなく、「どのように完了に至ったか」を把握する必要があると指摘されている。単なる成否チェックだけでは、ツールエラーからの復帰理由や途中停止の原因、予期せぬモデル呼び出しの増加などを説明できないため、実行ログを構造的に追跡する可観測性（オブザーバビリティ）が不可欠だという。
NeMo Relayのアーキテクチャと3つの出力形式
こうした課題に対し、NeMo Relayはモデルやツールの実行を監視・制御するための共通レイヤーを提供する。エージェントの実行基盤であるHermes AgentはNeMo Relayをネイティブに組み込んでおり、セッション、ターン、モデル呼び出し、ツール呼び出しをNeMo Relayのスコープ階層として表現する。これにより、各処理の開始と終了に伴うライフサイクルイベントが記録され、処理時間の計測や親子関係の保持が可能になる。
NeMo Relayを通じて出力される実行データは、主に以下の3つの形式で扱われる。
- ATOF（Agent Trajectory Observability Format）: 発生したライフサイクルイベントを時系列のイベントストリームとして記録する形式。
- ATIF（Agent Trajectory Interchange Format）: エージェントのステップごとの実行軌跡（トラジェクトリ）を構造化して表現する形式。
- OpenTelemetryスパン: 分散トレーシングの標準規格に準拠した形式で、「OpenInference」のラベルが付与される。これにより、「Arize Phoenix」などの外部可視化ツールへスパンを送信して直感的に検査できるようになる。
単一ツールおよび複合ツールタスクでの検証
記事では、NeMo Relayを組み込んだHermes Agentの動作を確認する2つの実践例が示されている。
1つ目は、ターミナルツールを用いたタスクである。Hermes Agentが隔離されたDockerコンテナ環境内でスクリプトを実行し、実行ランナー側で期待通りの出力文字列（VALUE=42）が得られたかを検証する。この際、単に出力結果を確認するだけでなく、トレースデータを照合することで、モデルスコープの正常完了、トークン消費量、ツールエラーの発生件数がゼロであったことなどを合わせて裏付ける手順が示された。
2つ目は、複数のツールを組み合わせた調査タスクである。旅行記録の読み取りから始まり、Web検索、公式サイトでのカンファレンス情報の照合、レポートの作成を経て、最終的に「COLT 2026」という名称を特定して返す一連のワークフローが実行された。このプロセスでは、モデルおよびツールのすべての実行スパンがArize Phoenixに送信され、どの段階でどのツールが呼び出されたかが詳細に可視化される。
ハーネス改修の影響を評価するケーススタディ
さらに記事では、エージェントハーネス（エージェントの実行環境やツール連携を司る制御層）の変更が全体に与える影響を検証するため、ベンチマーク「Hermes ToolPerf」を用いたケーススタディが紹介されている。
ベースラインとなるリビジョンと修正版リビジョンを比較するため、計108回の実行テストが実施された。言語モデルに「Qwen Coder 30B」を用いた検証では、修正版によってエラーから復帰してタスクを完遂できる割合は向上したものの、トレースの分析によってツール呼び出し回数、送受信データ量、全体のレイテンシが増加している実態が明らかになった。成否スコアの数値だけでは見落とされがちなコストや処理速度へのトレードオフを、トレースデータによって定量的に評価できることが実証された形だ。
動作環境と関連リソース
本チュートリアルを実施するための前提環境として、macOSまたはLinux、Git、curl、Docker環境のほか、「NVIDIA Nemotron 3.5 Lightning」を利用するためのNVIDIA Build APIキーが必要とされている。なお、実際に動作可能なサンプルコードや検証手順をまとめたリポジトリ、ならびにコードの解説動画が公開されている。