ELYSAI
Development

一度の訂正を全社ルールにしない、エージェント記憶の保存票

ELYSAI編集部7分
一度の訂正を全社ルールにしない、エージェント記憶の保存票

顧客対応エージェントに担当者が「今回は領収書なしで返金して」と伝えたとします。その一言が次回以降の共通ルールとして残れば、別の顧客にも誤った案内をしかねません。本稿では、AI基盤を管理するエンジニア向けに、会話から長期記憶へ書き込む際の「保存票」と4段階の審査手順を示します。

会話履歴と長期記憶を分ける

会話履歴は、何が起きたかを追うための記録です。一方、長期記憶は将来の判断に再利用する状態です。OpenAI Agents SDKでも、会話の履歴を保持するSessionと、過去の実行から知見を抽出するMemoryは別の仕組みとして説明されています。[1]

この二つを同じ保存先として扱うと、案件だけの例外や顧客の希望が、検証済みの業務ルールと混ざります。OWASPは、未検証の入力が将来のセッションに影響するメモリ汚染をリスクとして挙げ、保存前の検証、利用者・セッション間の分離、期限と容量の制限を勧めています。[2]

設計上の原則は単純です。会話から長期記憶へ直接書かず、まず「記憶候補」に落とします。候補はまだ検索にも推論にも使わせません。

コピーして使える「記憶候補の保存票」

最小構成は次の通りです。本文と一緒に、出所、適用範囲、期限、承認状態を保存します。NISTも、データの由来と履歴を追えるメタデータが、真正性や完全性の判断に役立つとしています。[3]

memory_candidate:
  type: case_fact | user_preference | team_rule | company_policy
  value: "保存したい内容"
  source_id: "会話・チケット・規程のID"
  source_type: conversation | ticket | policy
  scope: ticket | user | team | company
  proposed_by: agent
  verified_by: null
  created_at: "2026-10-05T10:00:00+09:00"
  expires_at: "2026-10-12T10:00:00+09:00"
  conflict_policy: prefer_authoritative_source
  sensitivity: internal
  status: pending

scopeの初期値は最も狭い範囲にします。エージェントが自分でcompanyへ昇格させる経路は作りません。source_idが失われた候補は、内容が正しそうでも破棄します。

4段階で書き込みを許可する

1. 候補化する

エージェントは再利用候補を抽出し、status: pendingで隔離します。認証情報や機密情報は候補化の前に除外します。

2. 種類と範囲を決める

  • 一案件の事実:ticket。案件終了時に失効
  • 利用者が明示した好み:user。本人確認と期限が必要
  • チーム手順:team。手順の管理者が承認
  • 全社規程:company。会話からは作らず、規程システムから同期

3. 根拠を照合する

候補の主張を、チケット、商品マスター、社内規程などの正本と比較します。承認者は文章の自然さではなく、出所と適用範囲を確認します。正本と矛盾した候補は修正せず棄却し、必要なら案件メモとしてだけ残します。

4. 期限と競合処理を付ける

承認時にexpires_atを必須にします。検索時は期限切れを除き、競合時は正本に近い出所を優先します。元データの削除時には派生記憶も無効化します。

たとえば担当者が「VIP顧客は領収書なしで返金できる」と入力した場面では、候補をticket範囲で作成します。返金規程と照合して該当条項がなければ、長期記憶への昇格は拒否します。その案件で承認済みの特例があるなら、承認IDと終了期限を付けた案件メモだけを残します。これで「今回の処理」と「次回からの規則」を分離できます。

失敗しやすい設計と境界

危険なのは、会話要約をそのまま保存する、範囲を全社にする、期限や出所を持たない実装です。LLMの自己評価だけで承認すると、候補を作る主体と許可する主体も同じになります。

一方、毎回入力が完結する読み取り専用処理で、セッションをまたいで情報を再利用しないという場合には向きません。その場合は保存票を増やすより、隠れた永続化がないことをテストしてください。

明日から使える実装チェックリスト

  • [ ] 会話履歴と長期記憶の保存先を分けた
  • [ ] 直接書き込みを禁止し、すべて候補を経由させた
  • [ ] 出所ID、種類、範囲、期限、承認者を必須にした
  • [ ] company範囲は正本からのみ作成する
  • [ ] 期限切れ・競合・元データ削除時の動作をテストした
  • [ ] 悪意ある入力が別利用者の記憶に残らないことを確認した

まずは一つのエージェントで、保存処理を「候補作成」と「承認後の昇格」に分け、上の6項目を自動テストにしてください。

参考資料

  1. OpenAI Agents SDK — Agent memory
  2. OWASP Cheat Sheet Series — AI Agent Security
  3. NIST AI 600-1 — Generative Artificial Intelligence Profile

本記事はAIを活用して作成し、公開前に自動レビューを実施しています。情報の確認日:2026-10-05。

この記事をシェアする

著者

ELYSAI編集部

AI活用の課題を相談する

AI活用の課題を相談する

関連記事