技術要約：メモリ・イン・ザ・ループ（Memory in the Loop）

問題提起

言語エージェントは、「観察、推論、行動、反復」という標準的なループに従って動作する。しかし、彼らが推論の対象とするメモリは、通常、ターンごとに最大一度だけクエリされる外部リソース（ターンごとの検索）として扱われる。この設計は、検索レイテンシが極めて高いという仮定に基づいている。ネットワーク化されたベクトルストアは通常50〜200ミリ秒で応答する。もしエージェントが推論ステップごとにそのようなストアを照会すれば、エンドツーエンドのレイテンシは最大83倍に膨れ上がる可能性がある。その結果、現在の業界のガイダンス（「メモリ・ファースト」）やシステム設計では、検索を1ターンに1回に制限するか、あるいはスケジューリングを通じてサービング層でコストを隠蔽している。

本論文は、このレイテンシ制約はエージェント設計の根本的な法則ではなく、ストアが「どこに存在するのか」というアーティファクト（副産物）であると主張している。ネットワークレイテンシ（数十から数百ミリ秒）は、ループ内での検索をコストの高いものにするが、プロセス内（in-process）のストアであれば約100マイクロ秒で回答できる。中心となる問題は、メモリを推論ループの「内部」へと移動させ（毎ステップの読み書き）、レイテンシの障壁が取り除かれた場合に、それが実現可能であり、かつ有益であるかどうかである。

手法

コア・アーキテクチャ

著者らは、WorkingMemoryプリミティブとしてラップされた、エフェメラル（一時的）なプロセス内セマンティックストア（vxdb）を用いて「メモリ・イン・ザ・ループ」を実装している。このストアはadd、recall、match操作をサポートする。決定的なのは、このストアはネットワークサービスに接続されておらず、エージェントまたはタスクごとに割り当てられ、マイクロ秒レベルのレスポンスタイムを目指している点である。

実験設定

本研究では、主に2つの実験レジームを採用している。

1. ウィンドウ型想起タスク（エンドツーエンドの性能）:

   • シナリオ: 6ターンの旅行計画に関する会話。ユーザーは会話の早い段階で5つの永続的な制約を述べる。エージェントは最後にこれら5つの制約をすべて列挙しなければならない。
   • 制約: コンテキストウィンドウはメッセージ数 $w=4$ に制限されており、初期の制約は可視コンテキストから押し出されてしまう。
   • 条件:
     • Baseline/Aware: メモリツールなし（自身の履歴が短いことを知らされている）。
     • Notes: すべての返答ですべての制約を再述するよう指示されている（「ツールなし」の上限値）。
     • Memory: in-processストアをバックエンドとするremember/recallツールを備えている。
   • モデル: 「GPT-5ラダー」（gpt-5-nano, gpt-5-mini, gpt-5, gpt-5.5）にわたってテスト。

2. 因果的ループ・ガード・タスク（レイテンシ vs 結果）:

   • シナリオ: エージェントがセキュリティアラートのストリームを処理し、INVESTIGATE（調査）するか、重複に対してSKIP（スキップ）するかを決定する。
   • メカニズム: コード・ガードが、冗長な調査を防ぐために、アクションの前にストアをチェックする。
   • 変数: ストアのレイテンシを、注入されたラウンドトリップ遅延（0 µsから200 ms）によって操作し、1ターンあたりのメモリ予算は100 msに固定する。
   • アーム（比較群）:
     • In-process: リアルタイム速度（~17.5–85 µs）。
     • Delayed Ladder: 同一のロジックだが、遅延を注入したもの（+5, +15, +30, +50, +110 ms）。
     • Per-turn RAG: 業界標準（ターンごとの検索）。
   • 指標: 実行された冗長なアクションの数（12個の重複のうち）。

コストモデリング

著者らは、検索コスト（$f \cdot c$）が推論ステップの時間（$r$）に対して無視できる場合、イン・ループ・メモリが実行可能であるという実現可能性の境界を定義している。彼らは、LLMのステップに対して「無料」であるかどうかを判断するために、完全な操作コスト（埋め込み + ストア）を測定している。

主な結果

1. 実現可能性とレイテンシ・タックス

• プロセス内速度: プロセス内ストアの中央値レイテンシは 80–165 µs で動作する。
• レイテンシ・タックス: 1ターンあたり20回のイン・ループ検索を行うと、プロセス内ストアによる総ブロッキング時間は ~1.7 ms である。対照的に、クラウド型ベクトルストア（RTT 110 ms）は、1ターンあたり 2.2 秒 のタックスを課す。
• 実現可能性: プロセス内速度であれば、エージェントは（レイテンシ予算を10%と仮定した場合）1ステップあたり約953回の検索を行う余裕がある。一方で、ネットワーク経由のストアは1ステップあたり1回未満のルックアップしか行えず、結果として検索の制限（配分）を強いることになる。

2. タスク性能（ウィンドウ型想起）

• ベースラインの失敗: すべてのBaselineおよびAwareの実行では、制約の想起スコアは 0/5 であった。コンテキストウィンドウの制限により、モデルのサイズに関わらず完全な失敗が生じた。
• 再述ベースライン: すべての返答で制約を再述するように指示されたベースラインは 5/5 を達成した。これは、エージェントが能動的にコンテキストを管理すればタスクが解決可能であることを示しているが、これはワーキングセットの規模に応じてスケールするトークン「賃料（rent）」を支払うことになる。
• メモリ・イン・ザ・ループ: イン・ループ・メモリ条件では、モデル間で 3.6–4.8/5 の想起率を達成した。
  • 失敗分析: ストアは事実を失わなかった（244/244の書き込みが保持された）。ミスはすべて 読み取りポリシーの失敗 であった。エージェントが制約を上書きしすぎ（重複の作成）、その後、固定の $k=8$ ウィンドウを通じて一度だけ読み取ったため、ウィンドウ内が冗長なエントリで混雑してしまった。失敗の原因は、メモリ基盤ではなく、エージェントのツール使用法にあった。

3. レイテンシの因果的影響（ループ・ガード）

• 単調な用量反応関係: 固定された予算の下で、ストアのレイテンシが増加すると、冗長なアクションも単調に増加した。
  • In-process (0 ms): 冗長なアクションは 0.0。
  • +15 ms: 1.4–1.6 の冗長なアクション。
  • +110 ms (Cloud): 12個中 7.2 の冗長なアクション。
• 統計的有意性: 両方のテスト済みモデルにおいて、インプロセスと110 msのレイテンシの差は統計的に有意であった（$p=0.0079$）。
• メカニズム: 110 msの場合、予算（100 ms）内にルックアップを行うことができなかったため、ガードが実質的に無効化された。これらの「間違い」は、検索エラーではなく、チェック自体の欠如によるものであった。
• Per-turn RAG: 業界標準のターンごとの検索は良好な結果（0.4–0.6の冗長なアクション）を示したが、単一ターン内で発生する重複を捉えるという構造的な失敗があった。一方、インプロセス・ガードはすべての重複を捉えた。

4. 埋め込みのボトルネック

• イン・ループ・スタックにおける支配的なコストは、ストアではなく 埋め込み（embedding） である。ネットワーク経由の埋め込みAPIは200–400 msを要する。
• プロセス内ストアを小さなローカル・エンベッダー（32Mパラメータ、約32 µs）と組み合わせることで、完全な操作（埋め込み + ストア）は ~40 µs まで低下する。これにより、イン・ループ・メモリへの最後の障壁が取り除かれる。

意義と主張

理論的貢献：拡張されたワーキングメモリ

本論文は、そのエンジニアリング上の知見を 拡張された精神テーゼ（Extended-Mind Thesis; Clark & Chalmers, 1998）に結びつけている。著者らは、外部リソースが認知の「構成要素」（すなわち、エージェントのワーキングメモリの一部）となるためには、以下の条件を満たす必要があると主張している。

1. 常に利用可能であること。
2. 困難なく直接アクセスできること。
3. 自動的に承認されること。

著者らは、最初の2つの基準を レイテンシ予算 と解釈している。100 msのネットワークコールはエージェントが「参照する」ツールであるが、100 µsのプロセス内ストアはエージェントが「持っている」リソースである。レイテンシが十分に低く、推論ステップに対して透明（透過的）であれば、そのストアは外部データベースから 拡張されたワーキングメモリ へと移行する。

エンジニアリング的貢献

• 設計変数としてのレイテンシ: 本論文は、検索頻度をサービング層の制約から、エージェントレベルのデザイン軸へとシフトさせている。ストアのレイテンシこそが、イン・ループ・パターン自体の成否を分けるゲーティング・ファクターであることを実証している。
• 因果関係の提示: ストアのレイテンシが、モデルの能力とは独立して、固定された予算下でのタスク結果（冗長なアクション）を決定することを因果的に示した。
• アーキテクチャの転換: メモリは、接続されたサービスとしてではなく、タスクごとに割り当てられるループ・プリミティブ（スクラッチパッドのようなもの）として扱うべきであると提案している。

謙虚さと限界

著者らは、その範囲について明確に述べている。

• ストアがモデルを「賢くする」と主張しているのではない。モデルは依然として、ガードなしでは重複を認識できなかった。システムが成功したのは、足場（scaffold） がメモリをチェックする余裕があったからである。
• 「Notes」ベースライン（再述）は、小さな5つの事実のタスクにおいてメモリツールよりも優れた性能を示した。これは、再述がワーキングセットの規模に応じて増大する「ターンごとのコスト」を支払うものであることを浮き彫りにしている。
• 本研究は、特定のタスクファミリー（制約想起、ループ・ガード）と特定のウィンドウサイズに焦点を当てているが、感度分析によって「ウィンドウの崖（window cliff）」現象は確認されている。また、何を保持すべきか、どのように整理すべきか、およびライフサイクル管理（忘却/優先順位付け）といった問題は、今後の課題として特定されている。

結論として、本論文は、メモリ基盤がプロセス内であり、ネットワークレイテンシを排除するためにローカル・エンベッダーと組み合わされている限り、「イン・ループ」体制は実現可能であるだけでなく、ターン内の状態の一貫性を必要とするタスクにおいて因果的に優れていると断言している。