III.4 Memory

本章の位置づけ

LLM は、渡した文章の外は見ない。前回の続きも、他システムのつながりも、どこかに残しておかないと、その場の推測になる。本章は Memory 層の担当を決める。製品の選定はしない。

4.1 毎回取りに行く設計の限界

「A 社の担当は誰で、いまの案件はどうなっているか」と聞くとする。顧客の仕組み、案件の仕組み、履歴の仕組みを、その場で順に叩くと、答えは組み立てになる。一番遅い呼び出しが全体を遅らせる。渡す文章は毎回ゼロから増える。仕組みをまたぐ関係は、モデルがその場でつなぐ。つながりを推測すると、ずれる。

この取り方を scatter-gather と呼ぶ。ツールを足すほど、賢くなるとは限らない。関係を残す層が無いと、複雑な問いは伸びない。

答えは、考える前に関係をまとめておくことである。推論のときは、まとめた記憶を聞く。関係をその場で作らない。

MCP で取った値を Memory に流し、普段の参照は Memory で済ませ、いま必要なときだけ MCP を叩く、というつなぎ方がある。MCP は原文と操作、Memory は関係である。同じではない。

Memory を、ただ速いキャッシュだと思ってはならない。本義は、関係を残すことである。

残すものは、出所で性質が分かれる。

実務では両方を行き来する。「A 社とは以前こう約束した（Memory）。ただし下請法のこの条を確認する（MCP）」が、その形である。

ドメイン MCP を作る人は、自分の MCP の中に小さな関係のまとまりを持っている、と考えてよい。法令なら条と通達、RFC なら依存する RFC、である。それは Memory の代わりではない。原文の側の代理である。

最初から大きなグラフを組む必要はない。痛みが出てから段を上げる。

次の段へ進む合図は、同じデータを何度も取りに行っていること、「A 社」と英語名を別人と誤ること、3 段以上の関係をよく聞かれること、「前回の続き」が仕事の要件であること、である。

ドメインが一つで、関係が 1〜2 段で足り、過去の文脈が要件でないなら、Memory 層を急いで足さなくてよい。

誰が、誰の代理として動くかは、Agent の識別の話である。詳細はエージェント ID を見る。

Memory は、会話が終わっても残る記憶と関係を置く。毎回 MCP を並べて集める設計は、遅さとずれを生む。考える前に関係を持っておく。キャッシュではなく、関係の残り方である。小さな仕事では、ファイルからで足りることが多い。

Data と Knowledge の還流、および「散在したデータの上に AI を載せない」前提は、全体地図に短い図がある。