AI エージェントにツール、メモリ、複数ステップの実行を追加しても、フィールド欠落、呼び出しの重複、長いタスクでの目標逸脱は起こり得ます。こうした問題が出たら、ハーネス（実行基盤）がコンテキストをどう渡し、アクションを実行し、状態を保存し、完了を判定しているか確認します。
NVIDIA Developer Blog は 2026-07-27 に Six Agent Harness Capabilities for Higher Model Performance を公開し、NVIDIA Labs Object-Oriented Agents（NOOA）を紹介しました。2026-07-28 時点で NOOA のリポジトリは公開されていますが、CHANGELOGでは初回公開がまだ Unreleased に置かれています。コードと評価手法は確認・再現できる形で公開されていますが、NOOA は研究プレビューであり、既存基盤の安定版代替ではありません。
既存チームは6つの機能を使い、現在の基盤を順に点検できます。入出力契約とコンテキスト参照を固定し、モデル生成コードを隔離して実行ループに制約を設け、状態を明示化したうえでモデルから呼び出せるハーネス API を制限します。固定評価セット、完全な実行軌跡、ロールバック手順がそろうまでは、変更を隔離環境に限定してください。
どのチームが先に実行基盤を点検すべきか
対象は、すでにエージェントの試作があり、タスクの実行軌跡を保存でき、同じモデルとタスクセットで変更前後を比較できる開発者またはプラットフォームチームです。単発回答の品質が低いなら、先にモデル、プロンプト、検索を確認します。ベースラインを再現できない場合は、基盤を変える前に評価とログを整備します。
| 現在の症状 | 最初に確認する場所 |
|---|---|
| ツール結果が長く、プロンプトが増え続ける | オブジェクト参照と上限付きプレビュー |
| 出力フィールドが欠ける、または形式エラーが多い | 型付き契約と戻り値検証 |
| 長いタスクで状態を失う、または処理を繰り返す | 明示的な状態とイベント履歴 |
| 固定評価セットまたは完全な実行軌跡がない | 基盤変更を止め、先にベースラインを作る |
実装前に4つの完了条件を書きます。タスク成功率が上がったか、タスク当たりのトークンが減ったか、失敗の種類が減ったか、旧版では成功したタスクが後退していないか、の4点です。1つでも答えられない場合は、新しい基盤に本番トラフィックを流しません。
NOOA がエージェントを表現する仕組み
NOOA は1つの Python クラスで1つのエージェントを表します。メソッドシグネチャと docstring（ドキュメント文字列）がタスクと型の境界を定義し、フィールドがモデルに見せる状態を保持します。メソッド本体が ... なら LLM 駆動ループが実行し、通常のメソッド本体は決定論的なコードとしてそのまま動きます。NVIDIA の技術レポートに、プログラミングモデルと評価手法の詳細があります。
| Python の構造 | NOOA での役割 |
|---|---|
| 1つのクラス | エージェントの機能、状態、プロンプト境界 |
| メソッドシグネチャと docstring | 型付き入出力とタスク指示 |
本体が ... のメソッド |
モデル駆動の生成または CodeAct ループ |
| 通常のメソッドとフィールド | 決定論的な規則、外部機能、明示的な状態 |
CodeAct ループでは、モデルが Python を書き、現在のオブジェクトのメソッドを呼び、実行環境内のオブジェクトを操作できます。NOOA は抽象構文木を検査し、利用できるモジュールを制限しますが、これだけではホストを隔離できません。モデル生成コードを実行するエージェントは、コンテナ、仮想マシン、NVIDIA OpenShell など、OS レベルのサンドボックス内で動かす必要があります。リポジトリの安全上の注意にも、ファイル削除、環境変更、データ流出の危険が明記されています。
次の表では、第2列が NOOA の公式メカニズム、第3列が既存の本番システムに対する本サイトの保守的な提案です。両者を同じ主張として扱わないでください。
| 公式機能 | NOOA のメカニズム | 既存システムで確認する点 |
|---|---|---|
| 型付き入出力（typed input/output） | メソッド引数と戻り値を型検証する | ツール引数、ツール結果、最終回答に実行可能な検証があるか |
| 参照渡し（pass by reference） | オブジェクトを実行環境に残し、モデルには上限付きプレビューだけを見せる | 大きなオブジェクトを毎回プロンプトへ直列化していないか |
| コードをアクションとして使う（code as action） | モデルが実行ループ内で Python を書いて動かす | コードが隔離され、副作用が決定論的なゲートを通るか |
| プログラム可能なループ設計（programmable loop engineering） | 開発者とモデルが通常の Python でループを組める | 停止、再試行、予算、権限をシステムが強制するか |
| 明示的なオブジェクト状態（explicit object state） | 型付き状態をエージェントオブジェクトに置く | タスク、証拠、リスクの状態が会話履歴から分離されているか |
| モデルから呼び出せるハーネス API（model-callable harness APIs） | モデルがコンテキストブロックとイベント履歴を確認できる | 書き込み権限より先に読み取り専用の確認手段を用意しているか |
第1段階：契約とコンテキストを固定する
最初に、直接測定できる2つの問題を扱います。入出力の検証エラーと、大きなオブジェクトが繰り返しプロンプトに入る問題です。変更後は、構造検証の失敗率とタスク当たりのトークン変化をそれぞれ確認できる状態にします。
手順1：自由記述の境界を型付き契約に変える
モデルに「JSON を返す」と指示するだけでは契約になりません。入力、ツール結果、最終回答をスキーマまたは同等のコードで検証します。検証に失敗したらフィールド単位のエラーを実行ループへ返し、再試行または停止を選ばせます。
| 境界 | 必須の検証 | 失敗時の処理 |
|---|---|---|
| ツール入力 | 型、必須フィールド、列挙値、長さ制限 | 実行を拒否し、フィールド単位のエラーを返す |
| ツール出力 | 成功状態、エラーコード、主要な結果フィールド | エラー種別に応じて再試行または停止する |
| 最終回答 | タスク状態、証拠、制限、次のアクション | 必須フィールドが欠けた回答を渡さない |
次の例はフィールド契約を示すもので、実行可能な JSON Schema ではありません。フィールド名と検証器は、実際の業務に合わせて実装してください。
{
"action": "create_ticket",
"input": {
"customer_id": "string",
"priority": "low | medium | high",
"evidence_ids": ["string"]
},
"output": {
"status": "created | rejected",
"ticket_id": "string | null",
"errors": ["string"]
}
}
構造検証の失敗、自動修正の成功、最終停止を分けて集計します。以前は人がログを読まないと見つからなかった形式エラーを、検索可能な指標へ変えます。
手順2：大きなオブジェクトを実行環境に残す
NOOA の参照渡しは、実体のある Python オブジェクトを実行環境に残します。モデルは最初に上限付きプレビューを見て、完全な内容が必要なときだけメソッドで問い合わせます。技術レポートでは、SWE-bench Verified でコンテキストトークンを減らした仕組みの1つとして説明されています。
既存システムで Python オブジェクトを直接参照できない場合は、監査可能なオブジェクトハンドルから始めます。
- 長い文書は
doc_idで保存し、コンテキストには要約、見出し索引、要求可能な抜粋だけを入れる。 - 検索結果はタイトル、出典、要約、証拠 ID だけを返し、全結果を一度に入れない。
- 表は問い合わせ関数で小さな範囲だけ返し、フィルター条件と行範囲を記録する。
- ログ、画像、バイナリはリソース参照として保持し、必要なときだけエラー要約または抽出結果を見せる。
各ハンドルには出典と更新日時を記録し、オブジェクトサイズ、問い合わせ可能なフィールド、アクセス権限も確認できるようにします。本番投入の判断では、平均プロンプトトークンとタスク成功率を同時に見ます。成功率が下がった場合は、プレビューを広げるか問い合わせ API を追加してから再評価します。
第2段階：コードと実行ループを制約する
モデルにコードを書かせると、ファイル、ネットワーク、プロセスに対する操作能力も広がります。コードは最初から OS レベルのサンドボックスで実行し、外側の制御ループで予算、権限、承認、停止条件を強制します。
手順3：モデル生成コードをサンドボックスに入れる
NOOA の CodeAct 戦略は、モデルが生成した Python コードをエージェントのプロセス内で実行します。技術レポートの制限事項には、プロセス内検証だけではホストを保護できないと記載されています。本番では、モデルは意味の判断とアクション案の作成だけを担当し、権限確認、冪等性、監査、最終コミットは決定論的なコードに任せます。
| アクション種別 | モデルが決めてよいこと | システムが強制すること |
|---|---|---|
| 情報の読み取り | 問い合わせ対象と条件 | 権限、範囲、返すフィールド |
| 下書き作成 | 候補内容 | 形式、機密データ、引用の検査 |
| システム状態の変更 | 変更意図とパラメータ案 | 冪等性、承認、監査、コミット |
| 高リスク操作 | 確認待ちの計画 | 既定で停止し、人の承認を待つ |
コンテナまたは仮想マシンでは、少なくともマウント先、外向き通信、認証情報、プロセス資源を制限します。アクションが失敗したら、モデルまたは契約のエラー、権限またはポリシーによる拒否、外部システム障害を実行軌跡上で区別します。原因を特定できない間は、ツールを増やしません。
手順4：停止と再試行をコードに書く
NOOA のプログラム可能なループでは、開発者とモデルが通常の Python で制御フローを組めます。モデルに制約付きの内部手順を組ませることはできますが、完了判定、最大ステップ数、費用、高リスク承認は、モデルが回避できない外側のプログラムで制御します。
- 完了と停止：必要なフィールドと証拠、最大ステップ数、人へ切り替える条件を定義する。
- 再試行と予算：一時的なエラーだけを再試行し、回数、トークン、費用、総時間に上限を置く。
- ツールと権限：タスク段階に応じてツールを公開し、権限を広げる前に停止して再承認を取る。
- コンテキストと失敗出力：短期コンテキストへ入れる情報を決め、次に取るべき行動が分かる失敗理由をユーザーへ返す。
システムプロンプトは規則を説明し、プログラム境界は規則を強制します。正常完了、再試行可能なエラー、再試行できないエラー、予算超過の4経路をテストしてください。
第3段階：状態を分離し、自己管理 API を制限する
長いタスクでは、完了条件、証拠、ツール結果、リスクフラグを確認可能な状態として保存します。最初はイベントとコンテキストの読み取り専用 API だけをモデルに渡します。権限制御、監査、再生が安定してから、書き込み可能な自己管理 API を開放します。
手順5：状態を会話履歴から切り離す
NOOA は明示的なオブジェクト状態をエージェントインスタンスに保持し、各ターンで実体のあるオブジェクトから公開フィールドを再レンダリングします。会話履歴から状態を作り直す必要はありません。既存システムでは、まず4種類の型付き状態を定義できます。
| 状態 | フィールド例 | 用途 |
|---|---|---|
| タスク状態 | goal、current_step、blocked_reason |
次のアクションを選び、完了を判定する |
| 証拠状態 | source_ids、verified_claims、unknowns |
重複検証と根拠のない結論を防ぐ |
| ツール状態 | failed_calls、resource_refs |
再試行とリソース参照を制御する |
| リスク状態 | needs_approval、policy_flags、rollback_plan |
未承認の副作用を止める |
状態は直列化、監査、再生できる必要があります。会話履歴だけにある計画は、信頼できる状態ではありません。履歴の圧縮やセッションをまたぐ復元で失われる可能性があります。
手順6：読み取り専用のハーネス API から始める
NOOA は、コンテキストブロック、各ターンの動的コンテキスト、イベント履歴をモデルから呼び出せる API として公開します。開発者は、各エージェントに見せるインターフェースを選べます。技術レポートの定義では、これは通常のツール呼び出しとは異なります。モデルが自分の作業コンテキストを直接確認し、管理できるためです。
- 読み取り専用：イベント履歴、リソース参照、現在の状態を確認する。
- 制限付き書き込み：作業メモまたは未検証の事実を示すフラグだけを追加する。
- メモリ候補：長期メモリ候補を提出し、ポリシーまたは人が採用可否を決める。
- 本番 API：権限、監査、再生の検証を通った操作だけを公開する。
NVIDIA Technical Blogで説明されているオプションの長期メモリは、種類、重要度、タグ、関係を記録し、タスク後に重複または矛盾する記録を統合します。これは研究上のメカニズムであり、業務メモリを自動的に信頼できるという意味ではありません。本番システムでは、出典、書き込み理由、訂正、削除の経路も残します。
同じタスクセットで本番投入を判断する
NVIDIA の報告では、SWE-bench Verified で GPT-5.5 の推論強度を xhigh にした場合、NOOA は82.2%に達し、1タスク当たりの平均は約28回のモデル呼び出しと110万トークンでした。比較対象の PI 基盤は78.2%、66回、220万トークンです。この結果が当てはまるのは、レポート内のモデル、エージェント、ツール、評価設定だけです。カスタマーサポート、社内ナレッジ、運用エージェントで同じ効果を保証するものではありません。NVIDIA の技術レポート
| 指標 | 記録方法 |
|---|---|
| タスク成功と後退 | 固定タスクセットを使い、旧版では成功したが新版では失敗したタスクを列挙する |
| トークンとモデル呼び出し | プロンプト、出力、ツール結果のトークンと呼び出し回数を分けて記録する |
| 契約とツールのエラー | 検証、権限、外部システム、停止理由で分類する |
| 実行軌跡の確認可能性 | レビュー担当者が重要なアクションを再生し、失敗原因を特定できるか確認する |
一度に変更する機能は1種類だけにし、モデル、タスクセット、採点規則は変えません。型付き契約が安定してからオブジェクト参照を評価します。コード用サンドボックスと外側の制御ループが障害テストに通った後で、状態書き込みまたは長期メモリを開放します。
本番投入の条件
- モデル生成コードは、制限されたコンテナ、仮想マシン、OpenShell のいずれかで実行する。
- アクセス制御と冪等性は決定論的なコードが担当し、承認、予算、停止規則もプログラムが強制する。
- 固定タスクセットに成功、後退、障害、高リスク操作の拒否を含め、ロールバックを実際に演習する。
- 実行軌跡からモデルのアクション、システムゲート、外部副作用、人の承認を復元できる。
この記事が扱うのはモデルとハーネスの間のインターフェースです。長いタスク全体の安全制御や評価セット作成を置き換えるものではありません。長時間の自律タスクには長時間タスクの安全ゲートも必要です。固定タスクセットがない場合は、AI エージェント評価セットの作成手順でベースラインを作ります。モデル生成コードを実環境へ入れる前に、NVIDIA OpenShell とローカル Agent の安全チェックリストで隔離境界を確認してください。
FAQ
NOOA で LangGraph、AutoGen、自社基盤をそのまま置き換えられますか？
推奨しません。2026-07-28 時点でコードは公開されていますが、リポジトリには安定版タグがなく、研究プレビューとして扱う必要があります。まず既存システムを6項目で点検し、同じ条件の評価結果を見てから NOOA の実装を採用するか判断します。
SWE-bench や CyberGym がない場合は、どう評価しますか？
自社領域の固定タスクセットを使います。カスタマーサポートなら匿名化した過去チケットと人の採点、コーディングなら単体テストとレビュー用チェックリストを使えます。調査エージェントは引用の正確性と証拠カバレッジで採点します。ベースラインと新版では、同じタスク、モデル、採点規則を使ってください。
モデルの結論をすべて長期メモリへ自動保存してよいですか？
保存しないでください。誤った結論が後続タスクへ持ち越されます。長期メモリには出典、時刻、書き込み理由、訂正状態を残し、高リスクの事実はポリシーまたは人が確認します。
どの時点で基盤変更を中断すべきですか？
完全な実行軌跡を保存できない、ベースラインを再現できない、または失敗原因がモデルとシステム境界のどちらにあるか判別できない場合は中断します。ツールやメモリを増やすと旧版と新版を比較できなくなります。ログ、評価セット、最小限の型付き契約を整えてから再開してください。