AIエージェントに「私のこと」をテキストではなくコードで覚えてもらうメリットと方法

本記事のテーマで作成したエージェントスキルを文末に記載します。

AIエージェントが会話をまたいでユーザーを覚えておく「記憶」は、ほぼ例外なく事実の寄せ集めとして保存されています。しかしこの一般的な形式では、矛盾を整理できない、記録を数え上げられない、聞かれる前に警告できないという根本的な制約があります。

そこで、ユーザーの状態をテキストではなくコードとして保持する方式が考案されました。この新方式、どこで差が出て、どこでは出ないのか。コスト構造や限界も含めて、実務で使える判断材料を整理します。

事実を並べるだけでは数えることも警告することもできない

現在の記憶システムが抱える構造的な問題

AIエージェントのパーソナライズには、会話をまたいで「この人はどんな人か」を覚えておくユーザー記憶が欠かせません。現状では、整理されていないテキスト、知識グラフ（情報を点と線のネットワークでつないだ形式）、会話から抜き出した事実のリストなど、いずれも「事実の寄せ集め」の形で保存されています。使うときは、今の質問と似ている項目を上位から検索して取り出すやり方が一般的です。

寄せ集め型に共通する3つの弱点

個々の事実を思い出すぶんには問題ありません。しかし「保存する工程」と「使う工程」が分離しているため、次のような問題が出てきます。

• 前の会話で「パクチーが好き」と言っていた人が、あとから「やっぱり嫌い」と言った場合に、矛盾を整理できない
• 「去年は何回海外に行った？」のように記録を数え上げる問いに対応できない
• 「パスポートが旅行日の180日以内に切れるなら警告して」といった論理的な条件を表現する手段がない

ユーザー記憶の3段階と、見落とされていた第3段階

ユーザー記憶のタスクは、三つの段階に分けて捉えることができます。

第3段階が厄介なのは、ユーザーが何も聞いていないのにシステム側から自発的にアラートを出さなければならない点です。この「きっかけが質問ではない」という非対称な性質が、既存の評価体系からまるごと抜け落ちていました。

会話をコードに変える二段階の仕組み

コードで持つ発想ではなく、何をコードにするかが新しい

テキストの代わりにコードを使う発想そのものは、目新しいものではありません。計算や論理をプログラムの実行環境に任せたり、エージェントの行動をコードに統一したり、習得したスキルを関数として蓄えたりする取り組みはすでに数多くあります。ただし、どれもひとつのタスクのためにコードを作っては使い捨てるものでした。今回の着眼点は、この発想を、これまでずっとテキストのまま扱われてきた「ユーザーの持続的な状態」そのものへ当てはめたことです。

ユーザー像を「小さなソフトウェアプロジェクト」にする

具体的には、ユーザーの状態を型付きのPythonオブジェクトとして保持し、制約やルールもPythonの関数として書きます。「型付き」とは、日付・数値・文字列などデータの種類があらかじめ決まっている状態のことです。種類が定まっていれば、日付どうしの引き算のような計算がたった一行で書けます。状態の保存もルールの検証も同じ実行環境で完結するので、保存と検証が切り離されるという根本問題が解消されます。

追記専用ログと定期的な再構築

方式は、二段階のパイプラインです。

①記憶（追記専用）

会話ごとに事実をひとつずつ文字列として抜き出し、追記専用のリストに足していきます。追記専用とは、付け足すだけで上書きも削除もしないという意味です。「好き」も「嫌い」も両方そのまま残します。「昨日」のような相対的な日付は、会話の日時をもとに絶対的な日付へ変換しておきます。

②構造化（定期再生成）

たまった事実リスト全体から、型付きPythonコードを定期的にゼロから再生成します。少しずつ書き換えるやり方だと、以前の事実がだんだん抜け落ちてしまうため、あえて毎回まるごと作り直す設計です。実際に、抜け落ちた事実は全体の0.2%未満にとどまっています。この「追記専用の記録＋定期的な再構築」は、データベースの世界で長く使われてきたパターンを記憶に応用したものです。

三つの経路を組み合わせて質問に答える

回答時には、型付きコード本体・事実のベクトル検索・生の会話ログという三つの経路が組み合わされます。

能動的なアラートは、コードを書いてサンドボックス（隔離された安全な実行環境）で動かし、結果を見て残すか修正するか判断するループから生まれます。有効だと分かったチェックは恒久的な制約に昇格し、以降の会話では常にアラートとして表示されます。記憶は旅行・健康・お金といった生活ドメインごとに独立した部品として分割され、必要な部分だけが読み込まれます。

集計と先回り警告で決定的な差がつくことがわかった

標準的な事実参照では既存手法と互角

標準的な事実参照ベンチマークのLOCOMOでは、78.8%というスコアが出ています。全文をそのまま丸ごとモデルに読ませる理想条件（79.8%）との差はわずか1ポイントで、統計的にはほぼ互角です。別のベンチマークLongMemEvalでも83%に達し、トップ層と同等の位置にあります。パイプラインのモデルをGeminiからGPTに入れ替えてもスコアに有意差はなく、特定モデルへの依存は確認されていません。ただし、比較対象の既存手法はもっと強力なモデルで動かした場合のスコアのほうが高く、それとの直接比較はできない点に注意が必要です。

集計タスクで一気に実力を発揮

差が決定的になるのは、記録の数え上げや集計が必要な問いです。検索は似たものを上からランキングして返す仕組みですが、集計では関係する記録を一件残らず拾わなければなりません。たとえば「去年は何回海外に行った？」に正しく答えるには、旅行の記録を全件見る必要があります。上位数件だけ取り出す検索では、大半を拾えていても、抜けた数件のぶんだけ答えがずれます。

記録件数が増えるほど検索型の正答率は崩れていきますが、型付きデータに一行の計算を走らせる方式は件数に左右されません。

ここで見落とせないのは、生データを全件渡したうえでコード実行を許す方式（表の「全文渡し＋コード実行」）も100%を達成している点です。つまり「実行できる形で持つ」こと自体は、この方式だけの強みではありません。本質的な貢献は、雑多な会話ログを実行可能なコードへ自動で変換する前段の仕組みにあります。生データを毎回まるごと渡せる小規模なうちは差が出ませんが、ノイズの多い実際の会話履歴では、この変換工程が集計の前提条件になります。

十ヶ月前のアレルギー情報から薬の危険を自動で警告できた

もっとも際立つのが、能動的なアラートの結果です。ある検証シナリオでは、ユーザーがある会話で「ペニシリンに重度のアレルギーがある」と話し、十ヶ月後の別の会話で「アモキシシリンという抗生物質を処方された」と報告しています。アモキシシリンはペニシリン系の薬ですが、二つの会話は何ヶ月も離れているため、通常の検索ではまず同時に引っかかりません。しかし型付きの薬分類情報どうしを照合することで、状態が更新された瞬間に危険な組み合わせだと自動判定され、次の会話の冒頭で警告が表示されます。

検索型の記憶はこの能力を原理的に持てません。起点になる質問が存在しないためです。

薬の飲み合わせやパスポートの期限切れのように、見落とすと実害があるシナリオほど、この差が意味を持ちます。

構造化のコストは3〜11回の問い合わせで回収できる

コード化にかかる費用は最初の一回だけで、同じユーザーへの問い合わせが3〜11回を超えると元が取れます。保持する記録が多いほど損益分岐は早まり、500件規模なら3回で回収できます。繰り返し問い合わせる実運用では、毎回全文を読み込み直す方式に比べておよそ15倍安くなります。ただし初回の構造化コスト自体は検索型より高いため、やり取りが単発で終わる用途にはコスト面の利点がありません。応答時間は中央値3.6秒で、七つの比較システムの中では最も遅いものの、差はわずかで、会話のテンポとしては実用範囲内です。

一番効果的なのは追記専用の事実抽出

構成要素をひとつずつ外す検証（アブレーション）の結果、性能の出どころが明確になっています。

興味深いのは、型付きコード本体が単純な事実参照にはほとんど寄与していない点です。コード化の恩恵は集計と制約チェックに集中しており、事実の思い出しを支えているのは、むしろ追記専用のログとベクトル検索の組み合わせです。構成要素ごとに担う役割がはっきり分かれています。

集計・制約・アラートの三用途で使えることに注意

既存の検索手法と競合ではなく補完の関係

既存の高性能な検索手法は、この方式と競合するものではなく、上に積み重ねて使えます。実際、検索型を併用した検証ではスコアが数ポイント伸びる傾向が確認されています。データの設計図（スキーマ）も制約ルールもすべてLLMが自動で生成し、ユーザーの変化に応じて作り直されます。人間が手で固定したデータ設計を持たないので、ユーザーの生活が変われば記憶の構造も自動的に追従します。「手で作り込んだ構造は、いずれデータと計算でスケールする汎用手法に追い抜かれる」という、いわゆる「苦い教訓」（Bitter Lesson）に沿った設計です。

ドメイン分割は情報漏れと監査の面でも有効

記憶を生活ドメインごとに独立させる設計には、副次的な実務メリットもあります。健康の情報が金融の文脈にしみ出すようなドメイン間の混線を抑えられるほか、変更がバージョンとして残るため履歴を監査でき、不要になった情報をコードとして明示的に削除できます。持続的な記憶では、ドメイン間の漏れや、ユーザーに迎合して事実をゆがめる挙動がリスクとして指摘されており、個人情報を扱う運用では見逃せない論点です。

使いどころを間違えると処理コストだけが増える

この方式が効果を発揮するのは、集計・制約チェック・能動的アラートの三用途に限られます。単純な事実の思い出しだけが目的なら、従来の検索型で十分であり、コード化の工程は不要です。導入を検討する際は、次の制約も押さえておく必要があります。

• 書き込みにLLMを二回通すため、一回で済む方式より処理が重い
• 毎回全体を作り直す方式は数百セッション規模で頭打ちになり、段階的な構造化が今後の課題
• 能動的アラートの性能は表現形式よりも事前計算パイプラインに強く依存する
• 集計ベンチマークは合成データかつ一回限りの問い合わせが前提であり、ノイズの多い実データでは事情が変わりうる
• ユーザーの状態を実行可能なコードで保存する以上、サンドボックスでの実行と厳格な隔離が大前提になる

まとめ

記憶をテキストの寄せ集めから実行可能なコードに変えることで、単純な事実参照では従来手法と互角を保ちつつ、集計（99% vs 6〜43%）と先回り警告（100%/85%）で決定的な差が生まれています。ただし、その恩恵は集計・制約・アラートの三用途に集中しており、単純な事実の思い出しだけが目的なら導入の必要はありません。記憶の「形」を変えるべきかどうかは、エージェントに何をさせたいかで決まります。

手軽に試してみたい方は以下のスキルを使ってみてください。論文内容を完全に再現できるわけではありませんが、エッセンスはなぞっています。

本記事の関連研究