ケーススタディ
パートナー
モデルではなくハーネスを調整する：Nemotron 3 Ultra実践ガイド
2026年7月8日
ブログに戻る
エージェントを作成
重要ポイント
- フロンティアに近いエージェント品質を低コストで実現。ハーネスのみの調整により、Nemotron 3 UltraはDeep Agentsスイートで最高0.86を記録し、Opus 4.8の最高0.87にほぼ匹敵。実行コストは約10分の1（フルスイートで約4.48ドル対43.48ドル）、レイテンシーは同等。
- 評価はハーネス作業のトレーニングデータ。各変更はトレース駆動ループを経て、まず低コストでスクリーニングし、勝利が複数試行で繰り返され、他の指標を悪化させない場合のみ保持。
- 適合度がタスクにどれだけ能力を発揮できるかを決定。適合したハーネスはモデルが作業に集中できるようにし、不適合なハーネスは足場との戦いに能力を浪費させる。その差は重みに触れずともスコアに現れる。
- ハーネス調整には上限がある。足場に起因する失敗は修正できるが、重みに存在しない能力を追加することはできない。そのため、すべてのハーネス変更で結果が横ばいの場合は、別のフックではなくポストトレーニングが必要であることを示す。
エージェントはモデルとハーネスから成る。モデルは思考を行い、ハーネス（システムプロンプト、ツール説明、ミドルウェア）はその足場として機能する。我々はこれまでにもフロンティアモデルのハーネスを調整してきたが、今回はオープンモデルでどこまでできるかを試したかった。
オープンモデルは興味深い。実際のエージェント作業に十分な性能を持ち、コストはフロンティアAPIの数分の一である。重みを入手できるため、自分でホストしてファインチューニングすることも、さまざまなクラウドプロバイダーのエンドポイントをロックインなしで利用することもできる。問題は、能力の高いモデルでも、それ用に設計されていないハーネスではパフォーマンスが低下する可能性があることだ。我々はこの部分を修正することにした。
Nemotron Coalitionのメンバーとして、Deep Agents内で調整するモデルとしてNemotron 3 Ultraが適切だと考えた。NVIDIAはNemotronをエージェントハーネス内で動作するように構築しており、我々はそれがどこまで可能かを検証したかった。
ハーネスは制御可能な部分
デフォルトの汎用ハーネスはモデルに調整されていない。モデルをハーネス調整なしで使用するのは妥当なデフォルトだが、最善策ではない。
ハーネスはモデルを取り巻くすべてであり、モデルはその内部のエンジンである。両者が適合すると、モデルは能力をタスクに集中できる。適合しない場合、モデルは足場との戦いに能力を浪費し、既に持っている情報を再度要求したり、早期停止したり、ループしたりする。
適合度の重要性は多くの人が考える以上に大きく、我々は以前にも実証している。Terminal-Bench 2.0では、gpt-5.2-codexのスコアを52.8から66.5に、モデルに触れることなく引き上げた（当時、トップ30からトップ5程度に）。モデル別のハーネスプロファイルをリリースした際には、プロンプトガイドに従うことでtau2-benchの厳選サブセットを10～20ポイント改善した。同じ重みでも異なる足場で異なるスコアになる。
我々はデータ駆動型のアプローチでハーネス側の作業を行い、トレースから障害パターンを抽出した。今回のケーススタディはNemotron 3 Ultraに焦点を当てている。このオープンモデルはそれ自体で既に優れている。NVIDIAが、シングルターンチャットだけでなく、長時間のツール使用タスクを含む大規模スイートでエージェントハーネス間で一貫した動作をするように特別にポストトレーニングしたからだ（NVIDIAの発表記事ではエージェントポストトレーニングとアーキテクチャについて詳述されている）。
我々はモデルを固定し、ハーネスのみを変更した：システムプロンプト、ツール説明、モデル呼び出しとツール呼び出しの間のミドルウェア。生成設定はベンダー推奨のデフォルトのままとした。したがって、以下の改善はすべて、温度、top-p、思考予算の変更によるものではない。
評価から始める
ハーネスをモデルに調整する際は、常に評価から始める。学習シグナルがなければ推測するしかなく、推測で調整したハーネスは最後に見たものに過剰適合する。我々は評価をハーネスエンジニアリングのトレーニングデータとして扱う。各ケースは、エージェントが適切なアクションを取ったか、適切な結果を生み出したかについてのシグナルを提供し、そのシグナルが次の変更を導く。
エージェント開発は通常のソフトウェア開発とは異なる。通常のソフトウェアでは、入力、出力、期待される動作が通常分かっている。エージェントでは、入力空間は広く、多くの出力が許容可能であり、プロンプト、ツール、オーケストレーションの小さな変更が一つのケースを修正しながら別のケースを壊す可能性がある。そのため、作業は反復的であり、LangSmithトレースを真実の源としてループで実行される：
- 評価：行動スイートでモデルを実行。
- 観察：失敗した各実行のトレースを読み、どこでどのように失敗したかを確認。
- 診断：失敗した軌跡を行動パターンにクラスタリング。
- エンジニアリング：ハーネスの一部に的を絞った変更を1つ加える。
- 再評価：変更をコストラダーに昇格させ、勝利が持続する場合のみ保持。
以下の図は、エージェント開発ライフサイクルループのバリエーションであり、評価環境を使用したハーネス調整用に特別に変更したものである：
2つの規律がループを正直に保った。第一に、単一の良好な実行だけでは不十分である。ランダム性により実行がわずかに変化するためだ。これを考慮し、変更は試行を繰り返しても勝利が再現され、他の何も悪化させない場合にのみ保持された。第二に、シグナルを失うことなくテストのコストを低く抑えた。すべての変更でフルスイートを実行する代わりに、候補はまず小さく安価なスクリーニングから始め、実績を上げた場合にのみ、より広範囲で高価な実行に進んだ。
スライスでスクリーニングするリスクは、スライスが触れないタスクでの後退を見逃すことだ。我々はスクリーニングを代表的なものにすることでこれを防いだ：異なる行動をカバーするサンプルで保持される変更は、通常フルランでも保持される。代表的なサンプルを取ることで、スクリーニングは高価なパスの前に実際の信頼性を提供した。
2つの層
プロンプト
プロンプトに関して、最初の直感はシステムプロンプトを書き直すことだった。これは変更するのに最も安価な部分なので、誰もがそこから始める。しかし、我々の経験では、それは最も過大評価されている。広範な書き直しや「より良いエージェントであれ」といった一般的な指示は、効果が薄い傾向がある。なぜなら、能力の高いモデルの実際の失敗は、通常、言葉遣いの問題ではないからだ。
効果を発揮するのは、書き直しの逆である：トレースで失敗した特定の行動を狙った、短く単一目的のブロック。例えば、モデルがタスクを完了しても結果を報告しない場合、次のような指示を正確に書く：「ツール呼び出しが成功した後、最終回答は具体的な結果を報告しなければならない。単にタスクが完了したと述べるだけでは不十分。ユーザーの要求に答えるキーエンティティ、アクション、識別子、タイトル、受信者、サービス、ステータス、または値を含めること。ユーザーが複数の質問をした場合は、それぞれのツール出力から対応する回答を提供すること。」
ただし、これらのブロックは相互作用するため注意が必要である。単独では効果がない指示でも、ハーネスの別の場所での変更と組み合わせると効果を発揮し始めることがある。そのため、組み合わせもテストした。
ミドルウェア
行動が「ほとんどの場合」ではなく「毎回」発生する必要がある場合、プロンプトでは不十分である。ミドルウェア（モデルとツール呼び出しの周りで動作するフック）は2つの異なる役割を果たしており、それらを分離する価値がある。
1つ目はコードによる強制である。モデルとツールの呼び出し回数に上限を設けることで、タイムアウト前にループを終了させる。ワンショットリトライは一時的なツール障害を吸収する。どちらもモデルに何かを要求するわけではなく、ループの動作を変更する。
2つ目の役割であり、Nemotronで最も効果を発揮したのは、コンテキストエンジニアリングである：適切なシグナルを、それが関連する瞬間にモデルの前に置くこと。すべてのルールをシステムプロンプトに詰め込み、それが定着することを期待する代わりに、トレース内の軌跡を監視し、モデルが誤った時点でガイダンスを注入した。
最も明確な例は、守りたいルールがあったことだ：ファイル読み取りが1ページ丸ごと返ってきた場合は、さらに内容があると仮定して読み続ける。これをread_fileツールの説明に書き込んでも効果はなかった。モデルは最初のページを読み、それがファイル全体だと仮定して回答した。我々は同じ文言を、変更せずにツールが返す内容に移動した。するとそれが機能し始めた。なぜなら、今やモデルが読んでいるデータのすぐ隣に表示されるからだ。同じ言葉、異なる場所、正反対の結果。その後、我々はルールが何を言うべきかだけでなく、読まれるためにはどこに現れるべきかを問うようになった。
同じパターンは、シグナルがどのメッセージに乗るかにも見られた。プロンプトかツール結果かというだけでなく、Nemotronは、システムプロンプトの固定ルールではなく、必要時に会話内のメッセージとして配信されるガイダンスに最も確実に反応した。そこで我々は、エージェントに行動前に計画を立てるよう指示するミドルウェアを追加し、計画が書かれた後、実行前に計画をレビューするよう促す2番目のメッセージを注入した。トレースでは、これらの注入されたメッセージを拾い上げて行動し、計画を立ててからチェックに戻った。同じ指示をシステムプロンプトに入れると、見過ごされがちだった。
効果がなかったこと
試みた変更のほとんどは生き残らなかった。これは明確に述べておく価値がある：勝利だけを報告する調整ループは、通常過適合である。もっともらしい変更の多くは何の効果もなく、いくつかは状況を悪化させ、複数のレバーは単独ではなく他のレバーと組み合わせた場合にのみ効果を発揮した。
我々が守ったルールは、ベンチマークのトリックではなく、行動クラスの修正を保持することだった。優れたレバーは、適切に構築されたツールと同様に、実際の条件（例えば、ファイル読み取りが1ページ丸ごと返す場合）で発火し、目の前の特定のテストについての知識は不要である。我々は、単一の評価のフレーズに依存しているために役立っていた変更を1つ除外した。それはスコアを水増しするが、次のエージェントについて何も教えてくれなかったからだ。
調整がもたらしたもの
単一のスコアは、エージェントが良くなったか悪くなったかを示すだけで、どこが変化したかは示さない。そのため、ハーネスの変更を信頼する前に、LangChainのDeep AgentsスイートでNemotronを実行し、エージェントが時間を費やすジョブ（ファイル操作、ツール呼び出し、情報検索、マルチターン会話、長いコンテキストの要約）で個別にスコアリングした。このようにスコアリングすると、結果は特定の能力を指し示し、ハーネスの問題とモデルの問題を区別する方法となる。
調整により、Nemotron 3 Ultraはプロファイルなしのベースライン約0.80から、典型的な実行で約0.84に向上し、最高実行では0.86に達し、Opus 4.8の最高0.87にほぼ匹敵した（Opusは典型的に約0.86）。プロファイルなしで約0.80からスタートするのは、強力な箱出し結果であり、NVIDIAのエージェントポストトレーニングの直接的な成果である：モデルはツール使用やマルチステップ作業にすでに熟達しており、ハーネスに高いベースラインを提供した。
要約能力は調整前が最も大きな改善余地があり、調整によって完全に解消された。プロファイルがない場合、ハーネスは圧縮のガイダンスを提供しないため、実行は新しい大きなタスクに移行する際に圧縮をスキップするか、オフロードされた履歴ファイルを読む代わりに要約された会話から回答した。プロファイルは明示的な圧縮ガイダンスを追加し、モデルを適切な圧縮行動に導く。ツール使用も大幅に改善された。検索とファイル操作は箱出しで既に強力であり、これもモデルが実際のエージェント作業用にポストトレーニングされている兆候であり、調整によってさらに向上した。これらの改善を合計すると、エージェントが実際に依存するタスクで優れたパフォーマンスを発揮するモデルが得られる。
会話は例外であり、横ばいのスコア自体が情報を提供している。これらはハーネスが修正できる低レベルの失敗ではなかった。マルチターンタスク全体でバックエンド状態を保持するような長期的な行動であり、これは足場ではなくモデルのポストトレーニングが対処すべきものである。プロファイルでそれらを調整することは、一般化するプロファイルを構築する代わりに、ベンチマークの形状に合わせることを意味する。すべてのハーネス変更を通じて結果が安定していることは、ハーネスの範囲を超えた問題を示している。
（原文はコスト管理のため途中で切れています）