Microsoft Foundryエージェントサービスに学習型Memoryを組み込む設計

MicrosoftはFoundry エージェントサービスのMemoryを使い、エージェントが会話を越えて利用者の好みや作業上の事実を保持する設計を紹介しました。全履歴を毎回プロンプトへ詰め込む方法とは異なり、再利用する情報を抽出して必要な場面で呼び戻します。

今回のブログ記事で語られていること

Memoryの目的は、単に会話ログを長く保存することではありません。過去のやり取りから今後も役立つ好み、役割、制約、継続中の仕事などを選び、後の会話で関連する記憶を検索して応答へ加えます。たとえば、利用者が好む出力形式、担当顧客、プロジェクトの前提を覚えていれば、毎回同じ説明を求めずに作業を続けられます。一方、一時的な依頼や誤った情報まで永続化すると応答品質を下げるため、何を記憶し、いつ更新し、いつ忘れるかが重要です。

実装では、ユーザーやテナントごとに記憶の境界を分け、エージェント実行時に関連情報だけを取得します。新しい事実が古い記憶と矛盾する場合は追記だけでなく更新が必要で、重複した記憶を統合する仕組みも要ります。記憶の取得結果はモデルへの追加コンテキストなので、元の業務データへの権限を超えてはいけません。組織の共有知識と個人の好みを同じ領域へ混ぜず、作成者、出典、時刻、対象範囲を追跡できる形にすることが運用上の鍵です。

また、利用者には何が保存されているかを理解し、訂正・削除できる経路が必要です。個人情報、機密情報、推測から生じた属性を無条件に記憶させると、プライバシーと説明責任の問題が生じます。記憶を使わない会話や保存を拒否する選択、保持期間、監査ログを用意し、応答が記憶に依存した場合に原因を調べられるようにします。便利さはモデルの能力だけでなく、抽出精度、検索精度、テナント分離、削除の確実性で決まるという内容です。

評価では、古い好みを新しい指示で上書きできるか、別利用者の記憶が混ざらないか、削除要求後に検索結果から確実に消えるかを、記憶の作成・検索・更新・削除の各段階で確認します。

今回のブログ記事が関係する人

継続的な業務支援、顧客対応、社内アシスタントをFoundry エージェントサービスで構築する開発者と、ID・データ保護・監査を担当するチームに関係します。

結局、今回のブログ記事をどう読むべきか

記憶してよい情報の分類、保存期間、更新と削除、ユーザー・テナント分離を先に定義します。誤った記憶、古い記憶、権限変更後の情報が応答へ混ざらないかをテストし、利用者が内容を確認・修正できる画面も用意します。