短期の文脈と長期の記憶を分けて扱う理由
エージェントが扱う情報には、その場のやり取りで完結するものと、次回以降も参照すべきものが混在しています。この二つを区別せずにすべて蓄積すると、参照すべき情報が雑多な履歴に埋もれ、必要なときに見つけられなくなります。逆に何も残さなければ、毎回同じ説明を求められ、作業の効率は上がりません。設計の出発点は、この二層を意図的に切り分けることにあります。
切り分けの基準は、その情報が時間の経過に耐えるかどうかで考えると整理しやすくなります。作業中の一時的な状態や、その場限りの試行錯誤は短期側に置き、方針、制約、繰り返し参照される前提条件などは長期側に置きます。この判断を自動化しようとする前に、まず人が明示的に指定できる仕組みを用意しておくと、後から挙動を検証しやすい構造になります。
記憶に残す情報と捨てる情報の線引き
長期記憶は多ければよいというものではありません。情報が増えるほど、参照時に無関係なものが混ざる確率が上がり、判断の精度がかえって落ちます。残す価値があるのは、繰り返し参照され、かつ再取得のコストが高い情報です。一度調べれば済むような事実よりも、その組織や利用者に固有の判断基準や好みのほうが、記憶として保持する意義が大きくなります。
同時に、残してはいけない情報の線引きも設計に含める必要があります。機微な情報や、一時的な認証に関わる情報を長期側に取り込んでしまうと、後から取り除くのが難しくなります。何を保存するかを決めるルールと同じ強さで、何を保存しないかのルールを定めておくべきです。この判断は技術的な制約というより、運用上の方針として明文化しておくほうが機能します。
記憶の陳腐化を防ぐ更新と検証の仕組み
長期記憶の厄介な点は、保存した時点では正しかった情報が、時間の経過とともに事実と食い違っていくことです。方針が変わり、担当者が交代し、前提が入れ替わっても、記憶はそのまま残り続けます。そして古い情報ほど、疑われることなく参照される傾向があります。定期的に内容を見直し、いつの情報なのかを追跡できるようにしておく仕組みが不可欠です。
更新の設計では、上書きするのか、履歴を残して新しい方を優先するのかという選択が生じます。上書きは構造が単純ですが、誤った更新をした際に元に戻せません。履歴を残す方式は安全ですが、参照時にどれを採用するかの判断が必要になります。扱う情報の性質に応じて方式を選び、少なくとも重要な項目については変更の経緯をたどれる形にしておくと安心です。
記憶設計の不備が誤動作として表れる兆候
記憶の設計に問題があるとき、症状はしばしば記憶とは無関係に見える形で現れます。以前と同じ指示なのに結果が変わる、指示していない前提を勝手に持ち込む、明示的に訂正したはずの内容が再び現れるといった挙動は、記憶の参照や更新の不備を疑うべき典型的なサインです。個別の出力を調整するより先に、参照された情報を確認するほうが原因に早く近づけます。
こうした調査を可能にするには、どの記憶が参照されたのかを後から追える仕組みが必要です。結果だけを見て推測すると、原因の切り分けに膨大な時間を要します。参照の記録を残しておけば、問題が記憶側にあるのか判断側にあるのかを短時間で切り分けられます。自律的に動く仕組みほど、こうした観測手段を最初から組み込んでおく価値が高くなります。
