なぜこれを取り上げるか。数値が付いているからである。SWE-bench Verified で GPT-5.5 を使い 82.2%（著者いわく提出時点の公開リーダーボード SOTA 79.2% を上回る）、Opus 4.6 では 253 行の汎用エージェントで 79.8%。CyberGym L1 は 86.8%、ARC-AGI-3 は GPT-5.5 で平均 RHAE 50.2%、GPT-5.6-sol では 85.1%（1ゲームあたり 20 ドル未満）。いずれも NVIDIA 自身の報告であり、ベンチマークの測定条件は素材に明示がなく、非査読の企業ブログである点は割り引いて読む必要がある。それでも、設計の切り口の変更にこれだけの成果報告が伴っているなら、何が変わったのかを見ておく価値はある。
何が「クラス」になると変わるのか
NOOA の中心にあるのは、Python の文法をそのままエージェントの設計面にする発想である。本体が省略記号（…）の標準メソッドは、実行時に LLM 駆動のループで補完される。通常の本体を持つメソッドは、決定的な Python としてそのまま動く。つまり一つのクラスの中に、モデルに委ねる能力と、コードで固める能力が同居する。
この二重性が効く例として、素材は脆弱性発見のケースを挙げている。NOOA は3つのメソッドを決定的ゲートに割り当てた。第1は検証器の生出力をクラッシュの有無という明確な判定に変え、第2はそのクラッシュが報告された脆弱性と一致するか確認し、第3は入力を再実行して再現性を確かめる。これらのゲートが自由形式のテキストではなく通常の型付きメソッドであるため、コードが認めたときにのみ finding が受理される。結果として実行全体が、検査でき、テストできる単一のトレースになる。プロンプトのやりとりを跨いで判断が漏れていく作りとは、検証可能性の性質が異なる。
型付きの入出力、参照渡し（pass by reference）、アクションとしてのコード、プログラム可能なループ、オブジェクト上の明示的な状態、モデルが呼べるハーネス API――これらが NOOA の設計の柱として並ぶ。要点は、モデルが自由テキストで指示を受け取って動くのではなく、型付きの引数と検証済みの戻り値を持つ Python を書いて動く、という点にある。
「メモリ」と「長いコンテキスト」の従来手法が抱えていた代償
NOOA が何を得たのかは、従来のエージェントが何を代償として払っていたかと並べると見えてくる。素材が背景として立てているのは、メモリと長コンテキストという2つの系譜である。
まずメモリ。従来の多くのエージェントは、ファイルや markdown にメモを書き溜める file-based notes 型の記憶を使ってきた。この方式の限界について、Zep はこう指摘している。「2つの事実の間の関係を辿ることができず、未検証の傍論を検証済みの記録と同等に扱ってしまう」。メモがフラットなログである限り、何が何を支持し、何が何と矛盾するのかは記憶の中に保たれない。
NOOA のメモリは、この点を型付きの関係で置き換える。「supports」「contradicts」「derived-from」といった型付き関係がレコードを知識グラフに接続し、フラットなログではなくなる。さらにメモリは自動のバックグラウンド要約パイプラインではなく、エージェント自身がモデル呼び出し可能なツールを通じて書き込み・照会・修正しながらキュレートするストアとして設計されている。現ターンに関連する記憶は自動的にコンテキストへ浮上する。背後ではリフレクションのパスが、重複のマージ・関連レコードのリンク・エピソードからのインサイト蒸留・不要情報のプルーニングを行ってストアを整理する。ARC-AGI-3 では、このメモリ subsystem が同じエージェントの file-based notes 版に対して RHAE を +11.8 ポイント改善したと報告されている。
もう一つが長いコンテキストの扱いである。コンテキストが窓に収まらなくなったとき、従来手法は要約でそれを畳んできた（context compaction / summarization）。だがこの畳み込みには代償がある。arXiv の論文（2605.23296）は、同期的な compaction が長時間のエージェントフローでボトルネックになり、エンドツーエンドの実時間のかなりの割合を食うと述べる。加えて「要約は本質的に lossy であり、ブロッキング呼び出しが数十秒にわたって推論を stall させる」。畳むたびに情報が落ち、そのたびに待たされる。
NOOA はここで参照渡しを選ぶ。ツールの結果はテキストとしてコンテキストの窓を往復するのではなく、コードの中で直接組み立てられるライブな Python 変数になる。モデルが見るのは型付きで境界の付いたプレビューであり、完全な値は実行環境にライブのまま残る。この性質のおかげで NOOA は context compaction を必要としない。トランスクリプトは append-only かつ cache-valid のままで、要約のパスが不要になり、prefill キャッシュのヒットがタスク全体で積み上がっていく。
要約という工程を捨てて、参照を保持することを選んだ――メモリでフラットなログを捨てて型付きの関係を選んだのと、同じ方向の判断である。
より高いスコアに、より少ない呼び出しとトークンで到達している、という報告である。 本稿「数値が示すのは効率の側」より
数値が示すのは効率の側
この設計変更が数字に現れているのが効率である。素材によれば、GPT-5.5 の NOOA は SWE-bench Verified で 82.2% に達するのに 29 回の LLM 呼び出しと1タスクあたり約 110 万トークンを使う。比較対象のハーネス群は 78.2% に届くのに 66 回の呼び出しと 220 万トークンを、78.6% に届くのに 29 回・130 万トークンを要したという。より高いスコアに、より少ない呼び出しとトークンで到達している、という報告である。プロンプトトークンのピークも、200〜400k の窓に対して中央値のセッションで 22〜72k に収まる。
ただし、これらの比較対象ハーネスが具体的に何であるかは素材に示されていない。1タスク 110 万トークンという量が業界の相場に照らして多いのか少ないのかを測る外部の参照点も、素材の範囲には含まれていない。ここで言えるのは、NVIDIA が報告した内部比較の中では NOOA がスコアとコストのフロンティアを前に進めている、というところまでである。
読者のメンタルモデルはどこが更新されるか
NOOA が問い直しているのは、「エージェントとは、プロンプトとツール呼び出しを束ねてループで回すもの」という当たり前の像である。その像を、型付きのクラス・決定的なゲート・参照で保持される状態・キュレートされる記憶という語彙に置き換えたとき、エージェントの一部は「検証できるコード」の側に移る。脆弱性発見のゲートが単一のトレースとして検査可能になったのは、その移動の具体例だった。
もっとも、これは一社の企業ブログが自社報告の数値とともに提示した設計であり、測定条件も査読も、失敗モードの記述も、素材の手元にはない。設計の切り口が変わったこと、そしてその変更に成果報告が伴っていること――ここまでが素材の届く範囲である。この作りが自分の関心のどこに触れるのか、従来のハーネスと引き比べて何を捨て何を得るのか。その線は、素材を手にした読者が自分で引くところに残しておきたい。