NavHarnessは、家の中を動き回るロボットが毎回新しい依頼を受けるとき、これまでに蓄積した地図と探索履歴を「会話が途切れた後でも」引き継いで使えるようにする仕組みだ。モデルを追加で学習させることなく(training-free)、メモリを読み書きする作業そのものをナビゲーションの一瞬一瞬の中に組み込んだ。地図の作成・復旧・完了検証までを束ねたこのハーネス全体の効果として、GOAT-Benchでは毎回白紙から始めるセッションよりも成功率をAstra基準で18.6ポイント、Opus 5基準で22.6ポイント引き上げ、SLAMで推定した位置を使いながらも従来の最高記録を上回った。
最近のフロンティアモデルは、シンプルなツール(観測・移動)を渡すだけでも、単一のナビゲーション課題はかなりうまく解く。何度も見て、考えて、動くマルチラウンド推論のおかげだ。問題はその先にある。家で働くロボットは一つの用事で終わらない。朝はリモコンを探し、昼は宅配便を運び、夜はメガネを取ってくる。それぞれの課題は、前の課題が終わったまさにその場所から始まる。
ここで従来方式の限界が露呈する。新しい依頼ごとに会話を最初から開き直すと、ロボットの体はその場にあるのに、頭の中の記憶はリセットされてしまう。すでに隅々まで探した部屋をまた探し、先ほど「リビングにはなかった」とメモしておいた記録を活かせない。
逆に記録を引き継いでも、また別の落とし穴がある。ある部屋で物を「見つけられなかった」という記録は、その部屋の隅々まで全部見たという意味ではない。以前メモしておいた「ソファは青色」という情報が、いま目の前の光景と食い違うこともある。記憶は不完全で、時には現在の観測と衝突する。だから記憶をそのまま鵜呑みにして従うのも、無視して毎回新しく始めるのも答えではない。著者らが狙ったのは、まさにこの隙間だ。
NavHarnessの発想はシンプルにまとめられる。記憶を読む作業を「出発前のブリーフィング」に押し込めるのではなく、道を歩いている間ずっと、随時取り出して目の前の光景と照らし合わせ、間違っているものは書き直せ、ということだ。
引き継ぎが丁寧な交代勤務を思い浮かべると近い。夜勤者が去り際に残した一枚のメモではなく、これまでどこを見て、何を除外し、どこがまだ未解決なのかを構造化して次の人に渡す。NavHarnessはこの構造をコードに埋め込んだ。いくつかの構成要素に分けて見ると、次のようになる。
| 要素 | 役割 |
|---|---|
| セッション(session) | 一回の探索を担うマルチターン・マルチモーダルの対話。推論の中核 |
| ハンドオーバー(handover) | 課題を閉じるとき、目標・探索した場所・結果の根拠・やり残した探索を要約して次のセッションに伝える |
| リカバリーノート(recovery note) | 同じ目標を再び試みるとき、これまでの根拠と残された選択肢を新しい試みへ引き継ぐ |
| 台帳(ledger) | 閉じた課題ごとに一行ずつ(目標・記録された状態・場所名)を残す圧縮インデックス。後のセッションが関連課題を探し、詳細な記録を閲覧する |
| 統合(consolidation) | ある家での作業(run)が終わるとき、課題の記録を「家ノート」にまとめ直し、次回の作業を助ける |
肝心なのは、これらの記録を対話ウィンドウ(context)の中にまるごと流し込まないという点だ。ロボットは必要なときにファイルを開いて読み、探索が展開していくにつれて追加の記録をさらに探しに行く。このアプローチが賢いのは、記憶の処理をメモリ専用モデルを別途学習させることなく、「コーディングエージェントがファイルを読んで直す」というすでに実証された習慣で処理している点にある。
もう一つ重要な仕掛けが検証だ。図ではVerify(止まる前の検証)とCertify(止まった後の認証)に分かれている。なぜ必要なのか。後の探索が先行する記録に依存するため、「見つけた」という誤った完了宣言がそのまま経験として固まってしまうと、後々まで後続を汚染する。だから完了を記録へと昇格させる前に、証拠を吟味する。
成果は二つの筋で読む必要がある。同じ実験から出た数値であっても、絶対値と向上幅は区別して読まなければ誤解が生じる。
第一に、白紙セッションに対する向上幅だ。各課題を外部メモリなしに新しい対話で解く「コンテキスト専用の独立セッション」と比較すると、GOAT-Benchでs-SR(成功率の指標)がAstraバックボーンで65.1%→83.7%(18.6%p)、Opus 5バックボーンで58.9%→81.5%(22.6%p)に上がった。同じ実験の中で、独立セッションの絶対性能とNavHarnessの絶対性能を並べ、その差を見た値だ。ただし、この向上幅は記憶の継承だけの効果ではない。著者らは、地図の作成・復旧・完了検証までを含めたハーネス全体の効果だと明記している。課題間の記憶継承だけを切り分けたOpus 5の実験では、向上は14.7%pだった。それでも、経験を引き継ぐ設計が単一課題の能力とは別に利得をもたらすこと自体は変わらない。
第二に、絶対性能だ。シミュレータが教えてくれる正解位置ではなく、SLAMで推定した位置を使いながらも、GPT-6とAstraの組み合わせによるNavHarnessがGOAT-Benchでs-SR 83.7%、e-SR 36.9%を、IR2R-CEでs-SR 85.9%を記録し、従来の最高成績を上回った。正解位置という有利な条件を外しても最高点だという点が、説得力を加える。著者らは、四つのバックボーンすべてで、同じバックボーンの独立セッションに比べて成功率と経路効率が上がったと述べている。
最も興味深い発見は、性能の数値ではなく、その原因分析にある。同じ分量に揃えたありふれた要約を渡すよりも、構造化されたリカバリー・ハンドオーバーを渡したときのほうが結果が良かった。つまり「どれだけ多く渡すか」ではなく「何をどう構造化して渡すか」が成否を分ける。複数の家を巡る長期配置の実験では、地図と課題の記録を単に保存するよりも、統合(consolidation)まで行ったときにナビゲーションがより良くなった。ケーススタディには、十九の課題が過ぎた後にようやく誤って打たれたマーカーを修正したり、失敗した探索を後のセッションが引き継いで完遂したりする場面が収められている。
著者らが自ら挙げる限界は少なくない。評価はシミュレーションのベンチマーク(GOAT-Bench・IR2R-CE)で行われており、実際の物理環境・リアルタイム性に対する検証範囲は限定的だ(論文のLimitationsにある実世界評価・実行速度の項目)。環境が静的だという仮定、より長い配置でarchiveへのアクセスがどう拡張されるか、小さなモデルの能力が支えになるかも、開かれた問いとして残されている。
そしてケーススタディの中には、失敗の場面も正直に含まれている。誤った完了がメモリに認証されて入り込んだ場合(Case 7)、診断はしたものの要約の過程でその情報が失われた場合(Case 9)、保存された経験をロボットが拒否した場合(Case 12~14)だ。記憶を引き継ぐ設計は、良い経験だけでなく悪い経験も伝播させる危険を併せ持つ — ここに落とし穴がある。だからこそ検証ゲートは選択肢ではなく必須になる。
この研究をロボットの話としてだけ読むと、核心を取り逃がす。NavHarnessが実際に扱っているのは、「セッションが途切れても経験を失わないエージェント」という、AI PM製品の心臓部そのものの問題だ。
ONTLEのAI PMが、ある顧客企業の依頼を処理する場面を一つ思い浮かべてみよう。先週のPMセッションで「決済連携の依頼を検討したが、カード会社の仕様書をもらえず保留」と書いておいた。今週、同じ顧客が「返金フローも付けてほしい」という新しい依頼を上げてくる。これまでのありふれたエージェントなら、新しい対話は白紙から始まり、先ほどの保留理由やすでに確認した制約を再び尋ねたり、最悪の場合まったく同じ無駄骨を繰り返したりする。
NavHarnessの構造をこの場面にそのまま当てはめると、話は変わる。台帳はこの顧客企業の閉じた依頼を一行ずつインデックスしておき、ハンドオーバーは「決済の検討でどこまで見て、何に詰まったのか」を構造化して次のセッションに渡す。新しい返金依頼を受けたPMセッションは、この記録をまるごとプロンプトに叩き込む代わりに、必要なときに開いて読み、現在の依頼と照らし合わせる。「決済が保留状態だから、返金も同じカード会社の仕様に縛られる」という判断を自ら引き出して使う。保留されていた決済依頼をリカバリーノートで蘇らせて続けるのは、論文の「失敗した探索を後のセッションが再開する」とまさに同じ動作だ。
ここでONTLEが持ち帰るべき教訓は、分量ではなく構造だという発見である。長い要約を次のPMに渡すよりも、「確認したこと/除外したこと/未解決のこと」を構造化して渡すほうが良い。そして完了を記録として固める前に検証ゲートを置くこと — 誤った「処理完了」が顧客の履歴に刻まれると、後に続くすべての判断を汚染するという警告は、ONTLEがすでに支払い系アクションに冪等性と検証をかけている理由と重なる。生涯働き続けるPMを作りたいなら、モデルをさらに大きくする前に、セッションの境界をどう設計するかから見るべきだ、という話である。
いいえ。training-freeの設計で、ナビゲーション専用の学習なしに、既製のフロンティアモデルにメモリ処理のループとツールを載せるだけです。だからバックボーンモデルを差し替えることができ、論文は四つのバックボーンすべてで向上を報告しています。
同じGOAT-Benchの実験から出た数値です。Astraバックボーン基準で独立セッションがs-SR 65.1%、NavHarnessが83.7%で、その差が18.6%pです(Opus 5は58.9%→81.5%で22.6%p)。つまり83.7%は絶対性能であり、18.6%pはその性能が白紙から始める独立セッションよりどれだけ高いかを示す向上幅です。ただしこの向上幅は、地図の作成・復旧・完了検証まで含めたハーネス全体の効果で、記憶の継承だけを切り分けると(Opus 5実験)向上は14.7%pです。条件が違うのではなく、同じ結果を絶対値と向上幅の二つの見方で見たものです。
多くのベンチマーク結果は、シミュレータが教えてくれる正解位置を前提にしています。NavHarnessはその有利な条件の代わりに、センサーで推定した位置を使いながらも従来の最高記録を上回りました。実際のロボットにより近い条件での成績だという点で、意味が大きいのです。
その通りです。論文も、誤った完了がメモリに認証されて入り込んだり(Case 7)、要約の途中で情報が失われたりする事例を正直に報告しています。だからこそ、止まる前の検証(Verify)と止まった後の認証(Certify)で完了の主張をふるいにかけ、経験として固める前に証拠を確認します。