🧠 技術調査 - Memory in the Loop：エージェントのメモリをループ内に置く設計

対象論文: Memory in the Loop: In-Process Retrieval as Extended Working Memory for Language Agents (arXiv:2607.05690v1, 2026-07-07)
分類: エージェントメモリ・コンテキスト設計 / 検証日: 2026-07-12

言語エージェントの memory を「ループの外の DB」から「ループの内側の作業メモリ」へ移す設計論です。C4 は提案フレームワークの論理構造として読み替え、実装は既存 ANN ライブラリと local embedder から補完します。補完箇所は「実装案」と明示します。

概要

何を主張する論文か

言語エージェントは observe → reason → act のループで動きます。しかし従来の memory は「ループの外」にある外部 DB として扱われ、1 ターンに最大 1 回しか参照されませんでした。本論文はその前提を覆します。

中核主張: memory をループの内側に置き、全 step で連想ストア (associative store) を read/write します。context window に触れるのと同じくらい安価にします。

障害はレイテンシ

ネットワーク越しの vector store は 50–200 ms で応答します。エージェントが毎 step 参照するとこのコストを繰り返し払います。論文は Yang et al. (2025, SearchAgent-X) を引用し、in-loop retrieval が end-to-end レイテンシを最大 83× 膨張させうると示します。83× は高コストな retrieval 条件で観測された最大値で、store レイテンシと reasoning レイテンシの比に依存します。50–200 ms の一般的な store で常に 83× になるわけではありません。

本論文の解法

per-turn network tax は S × RTT です。S は memory に触れる回数、RTT はラウンドトリップ時間を表します。networked store は retrieval を配給 (rationing) させます。in-process store はこの税を ~0 にし、rationing を不要にします。

論文はこの substrate-level (基盤層) の答えを、serving-layer (提供層) の答えと対立でなく補完と位置づけます (§3)。

理論的根拠: 拡張された心と parity principle

論文は Clark and Chalmers (1998) の extended-mind thesis (拡張された心) に接地します。外部リソースが認知の構成要素 (constitutive) になる条件は次の 3 点です。

• 常時利用できる
• 困難なく直接アクセスできる
• retrieval 時に自動的に受容される

本論文は parity principle を工学的基準 = レイテンシ予算 (latency budget) として再解釈します。

• 100 ms の network call はエージェントが consult するツールになる
• 100 μs の in-process store は「常にそこに在る」= parity の基準を満たし、真の extended working memory (拡張された作業メモリ) になる

レイテンシが store の「心への参加資格 (eligibility)」を決め、ループの配線が実際にそうなるかを決めます。

研究の位置づけ

本論文は「memory を cognitive resource として扱う研究系列の第一歩」と自己定義します。確立するのは「memory がいつ推論に参加できるか」です。retrieval が安価になれば毎 step で参加できます。「何を保持すべきか / どう整理すべきか」は次の問いとして残します。

特徴

論文が挙げる貢献は 4 点です。

1. retrieval frequency を agent-level design axis へ
   RAG 系の先行研究 (Fan et al., 2024; Hu et al., 2025b) では retrieval frequency は serving-layer のチューニング変数でした。本論文はこれを「per-turn か per-step か」というエージェント設計の軸に昇格させ、store latency がその軸の可動域を決めると示します。

2. parity principle を engineering criterion (latency budget) へ
   哲学的テーゼである Clark & Chalmers の parity principle を「in-process latency が外部 memory を構成的 working memory として eligible にする」という工学的基準に変換します。

3. store latency が task outcome に causal
   per-turn memory budget を固定し store latency だけを変えると、wall-clock だけでなく task outcome 自体が反転 (flip) します。

   • scripted loop guard: redundant actions が 0 → 10/10 に flip
   • real-LLM guard: 単調な用量反応 (monotone dose-response)。in-process 速度で 0.0、+15 ms で 1.4–1.6、+110 ms で 12 中 7.2 redundant
   • 条件: 2 モデル / rung ごとに 5 seeded workloads / exact permutation p = 0.0079 / guard errors ゼロ

4. GPT-5 ladder で end-to-end 実証
   4 モデル構成 (GPT-5 ladder) / bounded window 下で、recall が memory 無し baseline と window-aware run で 0/5 → in-loop memory で 3.6–4.8/5 に改善します。store ops は p50 80–165 μs で稼働します。別途 instructed の restate-every-reply baseline はこの 5-fact タスクで 5/5 に到達しますが、working set とともに per-turn コストが増えスケールしません。観測された miss はすべて agent の read policy が原因で、store が原因のものはゼロでした。

先行研究との比較

本論文は SearchAgent-X を「対立」でなく「補完」と明示します。serving-layer 解 (Yang et al.) と substrate-level 解は同じ in-loop retrieval を異なる層で支えます。

構造

本論文はプロダクト実装を提案しません。C4 の各レベルを「論文が定義するフレームワークの論理構造」として読み替えて図示します。図には論文の論理構造に加えて、記事独自の参照実装案 (ホット状態 / 作業メモリ / 長期記憶の 3 層永続化・非同期 flush・状態変化トリガー) を含みます。論文由来でない要素は各図・各節の注記で区別します。

システムコンテキスト図

コンテナ図

下図のレイテンシ層区分 (プロセス内 / ネットワーク境界) は論文の主張に沿います。「ホット状態 / 作業メモリ / 長期記憶」という 3 層の名称は Zenn 解説者による運用翻訳であり、論文本体の直接定義ではありません。

プロセス内境界の要素

外部要素

コンポーネント図

エージェントループ

in-process associative store

read policy - retrieval guard

embedder

networked long-term store

データ

論文に登場する概念をエンティティ化します。構造・配置・設定の詳細は含めません。論文に明示のない属性は「論文記述から推測 / 既存実装から補完」と注記します。

概念モデル

情報モデル

MemoryStore

Record

Embedding

ReadPolicy

LatencyBudget

Turn / Step

Guard / Workload / Metric

構築方法

前提: エージェントループの構成

Memory in the Loop を適用する前提は、observe → reason → act を繰り返す言語エージェントのループが既に存在することです。論文の主張は「store をプロセス内 (in-process) に置くことでレイテンシが ~100 μs に収まり、毎 step の read/write が成立する」です。既存ループがネットワーク越しの vector store を利用している場合は、それを下記の in-process store に差し替えます。

in-process associative store の初期化 (実装案)

補完注記: 論文は「in-process store を使う」方針を示しますが、特定ライブラリを指定しません。以下は実装案です。FAISS / hnswlib などの in-process ANN ライブラリが補完元です。

論文が示す要件は次の 2 点です。

• store がエージェントと同一プロセスに存在すること (co-located)
• 1 回の read/write が ~100 μs 以内で完了すること (parity principle の工学的基準)

# 実装案 — 補完元: hnswlib (https://github.com/nmslib/hnswlib)
import hnswlib
import numpy as np

DIM = 384             # 小型埋め込みモデルの次元数 (例: BAAI/bge-small-en-v1.5)
MAX_ELEMENTS = 5000   # タスク中に蓄積する最大 fact 数

# プロセス内に ANN インデックスを確保する
index = hnswlib.Index(space="cosine", dim=DIM)
index.init_index(max_elements=MAX_ELEMENTS, ef_construction=200, M=16)
index.set_ef(50)      # クエリ時の探索幅 (top_k より大きく設定)

# fact テキストとその ID を保持するメタストア (インデックスと同居)
id_to_fact: dict[int, str] = {}
next_id: int = 0

• init_index は一度だけ呼びます。エージェント起動時に実行します。
• MAX_ELEMENTS はタスク規模に応じて調整します。論文実験では 244 writes で 1 件も fact を失いませんでした。

# 実装案 (代替) — 補完元: FAISS (https://github.com/facebookresearch/faiss)
import faiss

DIM = 384
index = faiss.IndexFlatIP(DIM)   # 内積 (cosine 正規化済みベクトルを前提)
id_to_fact: dict[int, str] = {}
next_id: int = 0

• IndexFlatIP は exact search です。小規模 (数万 fact 未満) ならこれで十分です。
• スケールが必要な場合は IndexIVFFlat 等の近似インデックスを検討しますが、本セクションの対象外です。

local embedder の同居 (実装案)

補完注記: 論文 §7 は「ネットワーク埋め込みが ~200–400 ms のボトルネックになるが、小型 local embedder で complete operation が実測 ~40 μs に縮む」と報告します。どのライブラリを使うかは論文で指定されていません。以下は fastembed / sentence-transformers を使った実装案です。

# 実装案 — 補完元: fastembed (https://github.com/qdrant/fastembed)
from fastembed import TextEmbedding
import numpy as np

# エージェント起動時に 1 回だけロードする (プロセスに常駐させる)
_embedder = TextEmbedding(model_name="BAAI/bge-small-en-v1.5")

def embed_single(text: str) -> np.ndarray:
    """1 件のテキストを埋め込む。ONNX 推論のため CPU で高速に動作する。"""
    vec = next(_embedder.embed([text]))
    return (vec / np.linalg.norm(vec)).astype(np.float32)  # L2 正規化

• TextEmbedding の初期化は起動時に一度だけ行います。毎 step で再ロードしません。
• BAAI/bge-small-en-v1.5 (384 次元) は小型・高速モデルの代表例です。論文が示す ~40 μs は別の embedder・環境での実測値で、このモデルでの同等性能は保証されません。対象環境でベンチマークします。

# 実装案 (代替) — 補完元: sentence-transformers (https://www.sbert.net/)
from sentence_transformers import SentenceTransformer
import numpy as np

_model = SentenceTransformer("all-MiniLM-L6-v2")  # 384 次元

def embed_single(text: str) -> np.ndarray:
    vec = _model.encode([text], normalize_embeddings=True, show_progress_bar=False)[0]
    return vec.astype(np.float32)

write / query のラッパー実装 (実装案)

# 実装案 — in-process store の write/query インターフェース

def store_write(fact: str) -> int:
    """fact を埋め込んでインデックスに追加する。fact の ID を返す。"""
    global next_id
    vec = embed_single(fact)
    index.add_items(vec.reshape(1, -1), [next_id])  # hnswlib の場合
    id_to_fact[next_id] = fact
    fid = next_id
    next_id += 1
    return fid

def store_query(query: str, k: int = 5) -> list[str]:
    """クエリに最も近い k 件の fact を返す。"""
    if next_id == 0:
        return []
    vec = embed_single(query)
    labels, _ = index.knn_query(vec.reshape(1, -1), k=min(k, next_id))
    return [id_to_fact[lbl] for lbl in labels[0]]

論文の実験では store ops の p50 が 80–165 μs に収まります。id は衝突しない一意採番にします。§7 は「correct ids, not speed」を教訓に挙げ、id 衝突が起きた pre-fix 構成では書き込みの 47% が失われたと報告します。

利用方法

必須パラメータ・前提のまとめ

毎 step の read/write

論文の主張は「各 step で store を利用可能にすること」で、read の頻度は read policy が決めます。以下は実装案のフック配置例です。write は毎 step、read は条件付きにできます。

def agent_step(state: dict, observation: str) -> str:
    """1 ステップのエージェントループ。毎 step で store を read/write する。"""

    # --- observe 直後: 観測した事実を store に書き込む ---
    store_write(f"observation: {observation}")

    # --- reason の前: 現在のゴールに関連する fact を取得する ---
    relevant_facts = store_query(state["goal"], k=5)

    # --- context を組み立てて LLM に渡す ---
    context = {
        "goal":           state["goal"],
        "last_result":    state.get("last_result"),
        "relevant_facts": relevant_facts,
    }
    action = planner_llm(context)   # LLM による行動決定

    # --- act の結果を store に書き込む ---
    store_write(f"action: {action}, result: pending")

    return action

• store_query の k は per-turn budget (context window の残量) に応じて調整します。
• store_write は失敗理由・ゴール変更・ツール結果など、次 step の reasoning に必要な小さな事実に絞ります。

状態変化時だけ retrieval を走らせる read policy (実装案)

補完注記: 以下の next_step パターンは Zenn 解説記事が提示した実装案です。論文本体の主張ではありません。「goal_changed または tool_failed のときだけ retrieve_and_compact する」条件付き retrieval の具体化です。

# 実装案 — 補完元: Zenn 解説記事 (cec344d2e09371)

def retrieve_and_compact(goal: str, k: int = 5) -> list[str]:
    """長期記憶または作業メモリから関連 fact を取得して圧縮する。"""
    return store_query(goal, k=k)

def next_step(state: dict, event: dict) -> str:
    """状態変化 (goal_changed / tool_failed) があったときだけ working memory を補充する。"""
    if event.get("goal_changed") or event.get("tool_failed"):
        state["working"] = retrieve_and_compact(state["goal"])

    context = {
        "goal":        state["goal"],
        "last_result": state.get("last_result"),
        "working":     state.get("working", []),
    }
    return planner_llm(context)

• 毎 step で retrieval しない分、レイテンシを節約できます。ただし見落とし (miss) が増えるリスクがあります。論文は「観測されたミスはすべて read policy が原因」と報告しており、read policy の設計が精度を左右します。

3 層メモリの read/write の使い分け

補完注記: 以下の 3 層分類は Zenn 解説記事の運用翻訳 (実装案) です。論文本体の直接の主張ではありません。

# 実装案 — 3 層を使い分けるエージェントループの骨格

class AgentState:
    def __init__(self):
        # 層 1: ホット状態 (in-process dict、retrieval 不要)
        self.goal: str = ""
        self.last_result: str | None = None
        self.last_error: str | None = None
        # 層 2: 作業メモリ (in-process store から取得したキャッシュ)
        self.working: list[str] = []

def run_agent(initial_goal: str):
    state = AgentState()
    state.goal = initial_goal

    for step in range(MAX_STEPS):
        event = {}

        # --- observe ---
        observation = environment.observe()
        store_write(f"obs[{step}]: {observation}")   # 層 2 store への書き込み

        # --- reason ---
        hot = {"goal": state.goal, "last_result": state.last_result}  # ホット状態は dict アクセス
        if event.get("goal_changed") or event.get("tool_failed"):
            state.working = store_query(state.goal, k=5)              # 状態変化時のみ補充

        context = {**hot, "working": state.working}
        action = planner_llm(context)

        # --- act ---
        result, error = environment.act(action)
        state.last_result = result
        state.last_error = error
        if error:
            event["tool_failed"] = True
            store_write(f"error[{step}]: {error}")  # 失敗理由を in-process store に書く

        # 長期記憶への書き込みはタスク完了時か非同期で行う (ネットワーク越し・ループ外)
        # long_term_store.async_write(session_summary)

• ホット状態は通常の変数として持ちます。retrieval は不要です。
• 作業メモリは in-process store を使います。~100 μs で読み書きできます。
• 長期記憶はループの外に置きます。ネットワーク越しの往復 (50–200 ms) は毎 step では払わないようにします。

per-turn budget の管理

論文の理論値ではありません。Table 2 の per-turn retrieval blocking time は S=20・store op ~85 μs 条件で ~1.7 ms です。

• k (取得件数) を増やすほど context window を消費し、LLM の推論コストが上がります。
• context window に余裕がない場合は retrieve_and_compact 内で要約・圧縮して渡します。

運用

計測項目のログ設計

論文が設計レビューで並べることを推奨する指標を、最初のステージから収集します。

recall と S を同じ表で並べてレビューする運用が重要です。recall だけを追うと「検索を増やせば良い」という結論になりがちですが、S が増えると per-turn tax (≈ S × RTT) が増大します。両者のトレードオフを同時に可視化することで、「store をプロセスに寄せるべきか」「read policy を絞るべきか」の判断材料が揃います。

# 収集ログの構造例 (実装案: Zenn 解説の運用翻訳に基づく)
{
  "task_id": "...",
  "retrievals_per_task": 3,
  "total_retrieval_latency_ms": 0.9,           # in-process なら ~0.3 ms x 3 ops 程度
  "failures_recovered_without_retrieval": 0.0,
  "recall_at_task": 3.6,                        # /5 スコアで
  "S_memory_touches": 8,
  "cache_hits": 2,                             # 検索が走らなかった回数
  "time_from_failure_to_retrieval_ms": 12.5,   # 失敗から次の検索までの時間
  "decision_state": "hot"                      # どの状態層で判断したか: hot/working/long-term
}

キャッシュ有効期限と「検索が走らなかった回数」の管理

条件付き retrieval (状態変化時だけ検索を走らせる設計) を採用した場合、検索が走らなかった step の割合はチューニングの重要指標です。

• cache_hits が高すぎる場合は、read policy のトリガー条件が過剰に絞られており、miss recall の原因になっている可能性があります。
• cache_hits が低すぎる場合は、不要な検索でレイテンシを積み上げています。
• time_from_failure_to_retrieval_ms が大きい場合は、失敗の発生から read policy の反応まで複数 step かかっています。トリガー条件を見直します。
• decision_state で「どの記憶層の状態で判断が下されたか」を追うと、hot state と working memory の境界設定が適切かを事後に検証できます。

recall と S の並列レビュー運用

週次・スプリント単位で以下の形式のレビュー表を維持することを推奨します。

ベストプラクティス

1. 3 層メモリにレイテンシ予算を割り当てる

以下の 3 層分割は Zenn 解説者による運用翻訳 (実装案) です。論文本体の直接的な定義ではありません。

論文の実験では in-process store の p50 オペレーション時間は 80–165 μs です (§6 live ops)。この速度を「ホット状態」に割り当て、長期記憶への往復は周回の境目に限定することで、per-turn retrieval blocking time を Table 2 の ~1.7 ms 水準 (S=20) に抑えられます。

2. retrieval を必須処理でなく条件付き処理にする

すべての step で検索を走らせると、networked store では per-turn tax が S × RTT として線形に増大します。

• 状態変化時だけ (目標変更・ツール失敗・ホット状態のキー不足) working memory を補充します。
• in-process store でも「毎 step 全 fact を引く」構成は不要な I/O を増やします。条件付きにすることで S を最小化します。

3. store をプロセスに寄せる / local embedder を使う

• networked vector store (50–200 ms) をループ内で叩くと最大 83× のレイテンシ増大が起きます (論文が Yang et al., 2025 を引用して示す数値)。ただし 83× はネットワーク往復が高コストな構成での最大値であり、すべての構成で起きるわけではありません。
• in-process store (~100 μs) に移行するとこの増幅は消えます (論文の中核主張)。
• network embedding (~200–400 ms) は残るボトルネックです。小型の local embedder を導入すると complete operation が縮みます。論文は特定の小型 embedder・実行環境で ~40 μs を実測しました (§7)。同等値はモデルと環境に依存するため、対象環境でのベンチマークが必要です。
• 一意 ID 設計は速度より先に効きます。論文 §7 は「the fix is correct ids, not speed」と強調します。fix 後は 244 writes すべてを保持 (損失ゼロ) しましたが、fix 前は id 衝突で 47% の書き込みが失われました (network embed が競合 window を広げた。直接原因は ID 衝突)。移行時は衝突しない決定的な ID 採番を先に保証します。

ネットワーク往復の支配順 (大 → 小):
  network store + network embedder   : 200-400 ms/op
  network store + local embedder     : 50-200 ms/op (store RTT 支配)
  in-process store + network embedder: ~200-400 ms/op (embedder 支配)
  in-process store + local embedder  : ~40 マイクロ秒/op   ← 論文 §7 の目標点

4. 評価に必ずレイテンシを含める

「必要な文書を取れたか (recall)」だけを見るテストは危険です。

• 待ち時間を無視した正答率は、実運用の並列数が上がった瞬間に別のシステムを測っていることになります (Zenn 解説の指摘)。
• 評価セットに total_retrieval_latency_ms と S を必ず含め、recall 改善とのトレードオフを可視化します。

5. 反証・限界の明示

以下は本論文の結果を適用する際に注意すべき限界と反証です。

トラブルシューティング

まとめ

Memory in the Loop は、エージェントの memory を「ループ外の DB」から「ループ内の作業メモリ」へ移す設計論です。鍵はレイテンシで、store をプロセス内 (~100 μs) に置けば毎 step の read/write が成立し、ネットワーク越しで最大 83× に膨らむ増幅が消えます。検索精度を上げる前に、まず 1 周回の待ち時間と検索回数 S を測ることが、モデル選定より先に効く設計判断の起点になります。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

• 一次論文
  • Memory in the Loop (arXiv:2607.05690) — Abstract
  • Memory in the Loop (arXiv:2607.05690) — HTML 全文
  • Memory in the Loop (arXiv:2607.05690) — PDF
• 関連研究・系譜
  • SearchAgent-X / Yang et al., 2025 (arXiv:2505.12065)
  • SearchAgent-X — GitHub
  • Mem0 — Universal memory layer for AI Agents (GitHub)
  • The Extended Mind (Stanford Encyclopedia of Philosophy)
• 関連ツール
  • hnswlib — GitHub
  • FAISS — GitHub
  • fastembed — GitHub
  • sentence-transformers
  • ONNX Runtime — Performance
• 二次解説
  • 「メモリを毎ステップ読み書きする」論文 Memory in the Loop を読む (Zenn / hironakamura_ai)