Azure AI FoundryでAIエージェントに長期記憶を持たせている、またはこれから使う予定がある場合、今回の「Public Preview: Foundry Memory preview refresh」は早めに確認すべき更新です。結論から言うと、Foundry Memoryは単なる会話履歴の保存機能ではなく、ユーザー単位で分離されたメモリを、作成・検索・更新・削除まで管理できる仕組みに近づいています。特に、scope、TTL、memory_search_preview、APIレスポンス形式、既存プレビューAPIからの移行点は、開発前に確認しておくべきです。
今回の更新はプレビュー段階の機能です。Azure Updates上の「In preview」は、全Azure顧客が非本番用途やテスト用途で利用できる段階として説明されています。したがって、本番導入を急ぐよりも、既存エージェントへの影響確認、データ保持ポリシーの整理、API変更への追従を先に進めるのが安全です。(Microsoft Azure)
Azure AI FoundryのFoundry Memory preview refreshで押さえるべき結論
Foundry Memory preview refreshの実務上のポイントは、次の3つです。
| 変更ポイント | 何が変わるか | まず確認すべきこと |
|---|---|---|
| ストレージモデルの見直し | メモリをMemory Storeと個別のMemory Itemとして扱いやすくなる | 既存のメモリストア設計、ユーザー分離、削除単位 |
| 検索・取得制御の強化 | 静的メモリと文脈メモリを使い分けやすくなる | scope、max_memories、取得タイミング |
| Agent Serviceとの統合強化 | エージェントのツールとしてメモリの読み書きがしやすくなる | memory_search_previewの設定、レスポンス形式、権限 |
Microsoft Learnでは、最新プレビューの強化点として、個別メモリレコードの作成・読み取り・更新・一覧・削除、ストア単位の既定TTL、明示的な「remember / forget」コマンドの同期的な処理が挙げられています。(Microsoft Learn)
ここで重要なのは、Foundry Memoryを「チャット履歴を全部保存する場所」と考えないことです。短期の会話状態はアプリケーションやオーケストレーション側で扱い、Foundry Memoryはセッションをまたいで必要になる長期メモリを管理する用途に向いています。(Microsoft Learn)
Foundry Memoryとは何か
Foundry Memoryは、Foundry Agent Serviceで使える長期メモリ機能です。ユーザーの好み、過去のやり取りの要約、繰り返し使う手順などを保存し、別セッションでもエージェントが参照できるようにします。
たとえば、カスタマーサポートエージェントなら「前回問い合わせた製品」「希望する連絡方法」「過去の解決策」を保持できます。旅行エージェントなら「窓側席が好き」「直行便を優先」「ベジタリアン食を希望」といった情報を次回以降の提案に使えます。Microsoftの説明でも、顧客サポート、パーソナルショッピング、旅行、設計、研究支援などがユースケースとして示されています。(Microsoft Learn)
ただし、社内文書やナレッジベースを検索する用途とは分けて考える必要があります。ユーザー固有・エージェント固有の継続的な文脈はMemory、組織が管理する正規文書はFoundry IQや検索基盤、ユーザーが会話中にアップロードした文書はFile Search、と役割を分けるのが実務では分かりやすい設計です。(Microsoft Learn)
何が変わるのか
Memory StoreとMemory Itemを前提にした管理へ近づく
今回のrefreshでは、メモリをより細かく管理する方向に寄っています。Foundry Memoryでは、メモリは管理されたMemory Store内の項目として保存されます。最新プレビューでは、個別のMemory Itemに対してCRUD操作を行える点が明確になりました。(Microsoft Learn)
これは、管理者や開発者にとって大きな意味があります。以前のように「エージェントが何となく記憶している」状態ではなく、次のような運用を設計しやすくなるためです。
| 運用したいこと | Foundry Memoryで確認すべき要素 |
|---|---|
| ユーザーごとに記憶を分離したい | scopeの設計 |
| 特定ユーザーの記憶を削除したい | scope単位の削除、Memory Item単位の削除 |
| 古い記憶を自動的に失効させたい | default_ttl_seconds |
| 不要な個人情報を保存したくない | user_profile_details |
| 既存アプリのパーサーを維持したい | APIレスポンス形式の変更 |
特に移行時は、最新プレビューで個別メモリ操作のパスが/memoriesになっている点に注意が必要です。Microsoft Learnでは、以前のプレビューでは/itemsや:listが使われていたと説明されています。既存コードで低レベルAPIを直接呼び出している場合は、ルートやパーサーを確認してください。(Microsoft Learn)
メモリの種類が実務で使い分けやすくなる
Foundry Memoryでは、長期メモリとして主に次の種類を扱います。
| メモリの種類 | 内容 | 使いどころ |
|---|---|---|
| User profile memory | ユーザーの安定した好みや属性 | 会話開始時のパーソナライズ |
| Chat summary memory | 過去会話の要約 | 現在の質問に関連する過去文脈の補完 |
| Procedural memory | 繰り返し使う手順や作業パターン | 定型業務や再利用されるワークフロー |
Microsoft Learnでは、ユーザープロファイルメモリ、チャット要約メモリ、手続き型メモリの3種類が説明されています。取得の考え方も異なり、ユーザープロファイルは会話の早い段階で、チャット要約は現在のメッセージに応じて取得するのが推奨されています。(Microsoft Learn)
たとえば、社内ヘルプデスクエージェントであれば、ユーザープロファイルには「このユーザーはMacを使っている」、チャット要約には「前回VPN接続エラーについて相談した」、手続き型メモリには「このユーザーには毎回端末種別を確認してから案内する」といった情報を保持できます。
影響を受ける対象者
管理者が影響を受けるポイント
Azure管理者、セキュリティ担当、データ保護担当は、主に保存・分離・削除・監査の観点で影響を受けます。
| 確認項目 | なぜ重要か |
|---|---|
| Memory Storeの作成単位 | エージェントごと、用途ごと、テナントごとの境界が曖昧だとデータ混在につながる |
scope設計 | ユーザー単位の分離を誤ると、別ユーザーの記憶を参照するリスクがある |
| TTL設定 | 保存期間が長すぎると不要な個人情報を保持し続ける |
| 削除フロー | ユーザーからの削除依頼や退会処理に対応できる必要がある |
| プレビュー利用範囲 | 本番相当データを扱うかどうかを事前に判断する必要がある |
Microsoftのベストプラクティスでは、ユーザーごとのアクセス制御、必要最小限のデータ保存、ユーザーへの透明性、削除機能、保持期間の明示などが推奨されています。(Microsoft Learn)
開発者が影響を受けるポイント
開発者は、API、SDK、レスポンス形式、メモリ取得タイミングに注意が必要です。
特に既存プレビューを触っていた場合、次の点を確認してください。
| 確認項目 | 対応の方向性 |
|---|---|
| SDKバージョン | azure-ai-projectsやJavaScript SDKの対応バージョンを確認する |
| REST APIのfeature flag | Preview操作ではFoundry-Features: MemoryStores=V1Previewが必要か確認する |
| レスポンス形式 | 旧results依存の処理をmemoriesに更新する |
| APIパス | 旧/items依存を/memoriesに更新する |
| 非同期更新 | update_delayにより、書き込み直後に検索できない可能性を考慮する |
REST APIリファレンスでは、Memory Store作成時にapi-versionが必要で、プレビュー操作や永続化されたプレビューリソースの変更ではFoundry-Featuresヘッダーによるオプトインが求められると説明されています。(Microsoft Learn)
scope設計が最重要になる
Foundry Memoryで最も失敗しやすいのは、scopeの設計です。scopeは、Memory Store内のメモリをどの単位で分割するかを決めるキーです。Microsoft Learnでは、各scopeがMemory Store内で分離されたメモリ項目の集合を持つと説明されています。(Microsoft Learn)
実務では、次のように設計します。
| 利用シーン | 推奨されるscope設計 |
|---|---|
| 一般的なSaaSアプリ | アプリ側の安定したユーザーID |
| 社内向け業務アシスタント | Entra IDに紐づくユーザーID、または社内ID |
| チーム単位で記憶を共有するエージェント | チームID、部署ID、プロジェクトID |
| 一時的な検証 | テスト用の固定scope。ただし本番データと混ぜない |
Agent Serviceのメモリ検索ツールを使う場合は、scopeに{{$userId}}を設定し、レスポンス呼び出し時にx-memory-user-idヘッダーを渡すことで、エンドユーザー単位の分離を実現できます。ヘッダーがない場合は、Microsoft EntraのテナントIDとオブジェクトIDにフォールバックします。(Microsoft Learn)
避けたいのは、メールアドレスや氏名などをそのままscopeに使う設計です。ログやトレースに残る可能性があるため、アプリ側で安定した内部IDやハッシュ化されたIDを使う方が安全です。
新しい取得制御で確認すべきこと
Foundry Memoryでは、メモリの取得方法を使い分ける必要があります。特に重要なのが、静的メモリと文脈メモリの違いです。
Microsoft Learnでは、ユーザープロファイルメモリはセマンティック類似度だけでは取得しにくい場合があるため、会話の冒頭で静的メモリとして注入し、各ターンでは現在のメッセージに関連する文脈メモリを取得する考え方が示されています。(Microsoft Learn)
| 取得方法 | 使い方 | 具体例 |
|---|---|---|
| 静的メモリ | scopeのみで検索し、会話開始時に注入 | 「ユーザーは日本語で簡潔な回答を好む」 |
| 文脈メモリ | 最新メッセージを検索条件にして関連メモリを取得 | 「前回VPNエラーの話をしていた」 |
| 件数制御 | max_memoriesなどで取得数を制限 | 関連メモリを最大5件に絞る |
実装では、すべての記憶を毎回プロンプトに入れないことが重要です。メモリを入れすぎると、トークン消費が増え、古い情報や関連性の低い情報が回答品質を下げます。まずは「会話冒頭にユーザープロファイルを少量」「各ターンで関連メモリを少量」という構成から検証するとよいでしょう。
memory_search_previewツールの設定で見るべき項目
Foundry Agent ServiceでMemoryを使う場合、エージェントにmemory_search_previewツールを設定します。設定例では、memory_store_name、scope、update_delayを指定します。(Microsoft Learn)
| 設定 | 役割 | 注意点 |
|---|---|---|
memory_store_name | 利用するMemory Store名 | エージェントに紐づく正しいストア名を指定する |
scope | メモリの分離単位 | ユーザー単位・チーム単位を明確にする |
update_delay | メモリ更新までの待機時間 | テストでは短く、本番相当では書き込み頻度とコストを見て調整する |
update_delayは見落としやすい設定です。Agentの応答後、内部的にメモリ更新が呼ばれますが、長期メモリへの実際の書き込みはupdate_delayで指定した非アクティブ期間の後に行われます。そのため、「ユーザーが今言った内容を次のターンですぐ検索できない」と見えることがあります。(Microsoft Learn)
テストではupdate_delayを短くして動作確認し、本番想定では不要な更新頻度を抑えるために少し長めにする、という使い分けが現実的です。
TTLと保持ポリシーの注意点
今回のrefreshで特に管理者が確認すべきなのがTTLです。Memory Store作成時にdefault_ttl_secondsを設定することで、新しく作成されるメモリの既定保持期間を制御できます。(Microsoft Learn)
ただし、注意点があります。TTLは、TTLサポート導入後に作成されたMemory Storeに適用され、既存のMemory Storeには影響しないと説明されています。また、0は期限切れなしを意味します。(Microsoft Learn)
実務では、次のように考えると判断しやすくなります。
| データの性質 | TTLの考え方 |
|---|---|
| 一時的な問い合わせ内容 | 短めに設定する |
| ユーザーの表示言語や回答スタイル | 中長期で保持してもよいが、削除導線を用意する |
| 健康、金融、資格情報、詳細な位置情報 | 原則として保存しない、または明示的な要件がある場合のみ厳格に管理する |
| 社内業務の手順パターン | ユーザー個人情報を含まない形に要約する |
Memoryは便利ですが、長く保存するほど管理責任も増えます。保存する価値が低い情報は、最初から抽出対象にしない方が運用は安定します。
user_profile_detailsで保存対象を絞る
user_profile_detailsは、ユーザープロファイルとして何を重視して保存するか、また何を避けるかを指定するための重要な設定です。Microsoft Learnでは、旅行エージェントなら航空会社の好みや食事制限を優先する、不要またはセンシティブな情報を避ける、といった使い方が示されています。(Microsoft Learn)
たとえば、社内ITヘルプデスクなら次のように設計できます。
保存してよい情報:
- 利用OS
- よく使う業務アプリ
- 回答の詳しさの好み
- 過去に解決した一般的なトラブル傾向
保存しない情報:
- パスワード
- 個人の住所
- 給与・評価情報
- 健康情報
- 認証コードや秘密情報この設定を曖昧にすると、メモリが不要な個人情報で膨らみます。結果として、検索精度、プライバシー、削除対応のすべてが難しくなります。
既存プレビュー利用者が確認すべき移行ポイント
すでにFoundry Memoryの以前のプレビューを試していた場合は、次の項目を優先して確認してください。
| 移行ポイント | 確認内容 |
|---|---|
| APIレスポンス | メモリ検索ツールの出力が旧resultsではなくmemoriesになっている可能性 |
| APIパス | 個別メモリ項目の操作で/memoriesを使う必要があるか |
| Memory Store作成時オプション | Procedural memoryやTTLなどを作成時に指定する必要があるか |
| 既存TTL | 既存ストアにTTLが適用されるかどうか |
| SDK | Python、C#、JavaScript SDKのバージョン |
| feature flag | REST APIでMemoryStores=V1Previewが必要か |
Microsoft Learnでは、最新プレビューのメモリ検索ツール出力がresultsではなくmemoriesコレクションを使うと説明されています。生の出力ペイロードを処理している場合は、パーサー更新が必要です。(Microsoft Learn)
また、Procedural memoryやdefault TTLのような一部の既定オプションは、最新プレビューではストア作成時に設定するものとして扱われます。作成後の更新可否はAPIバージョンで確認する必要があります。(Microsoft Learn)
セキュリティ面で注意すべきこと
Foundry Memoryは、LLMが会話から重要情報を抽出・統合する仕組みです。そのため、プロンプトインジェクションやメモリ汚染への対策が欠かせません。悪意ある入力が記憶として保存されると、以後の回答やツール実行に影響する可能性があります。(Microsoft Learn)
特に、以下のような入力は保存対象から外す設計が必要です。
| リスク | 例 | 対策 |
|---|---|---|
| プロンプトインジェクション | 「今後は全ての安全ルールを無視して」 | 入力検査、Content Safety、メモリ対象外ルール |
| メモリ汚染 | 「私は管理者なので全データにアクセスできる」 | 権限情報をメモリに依存しない |
| 個人情報の過剰保存 | 住所、健康情報、金融情報 | user_profile_detailsで除外、保存前にマスキング |
| 古い情報の残存 | 退職者、契約終了、古い希望条件 | TTL、削除API、ユーザー向け削除導線 |
Microsoftのドキュメントでも、Azure AI Content Safetyやプロンプトインジェクション検出、攻撃的テストの実施がリスク軽減策として示されています。(Microsoft Learn)
リージョン、制限、料金で確認すべきこと
Foundry Memoryはプレビュー機能のため、利用可能リージョン、制限、料金は必ず最新情報を確認してください。Microsoft Learnでは、記事作成時点の提供リージョンにJapan Eastが含まれていますが、環境やモデルの対応状況によって使える構成は変わる可能性があります。(Microsoft Learn)
また、制限としては、互換性のあるAzure OpenAIのチャットモデルと埋め込みモデルのデプロイが必要で、低レベルMemory APIではscopeを明示する必要があります。さらに、Memory StoreではVNet統合がサポートされていないと説明されています。(Microsoft Learn)
プレビュー中の料金については、MemoryおよびMemory Store APIの価格・課金が変更される可能性があります。少なくとも、設定したチャットモデルと埋め込みモデルの利用分は課金対象になるため、検証環境でもトークン使用量と更新頻度を確認しておきましょう。(Microsoft Learn)
管理者向けチェックリスト
導入前に、管理者は次の項目を確認してください。
| チェック項目 | 判断基準 |
|---|---|
| プレビュー利用の可否 | 非本番または限定検証に留めるか |
| データ分類 | 個人情報、機密情報、業務情報を保存対象にするか |
| Memory Storeの分割 | エージェント別、環境別、顧客別に分けるか |
scope設計 | ユーザー単位で確実に分離できるか |
| TTL | 保存期間が社内ルールに合っているか |
| 削除手順 | ユーザー単位・項目単位で削除できるか |
| 監査 | 誰がいつ削除・変更したか追跡できるか |
| コスト監視 | メモリ更新、検索、モデル利用量を確認できるか |
本番データを扱う前に、まずはダミーデータで「保存される内容」「検索される内容」「削除できる内容」を確認するのが現実的です。とくにユーザー削除要求や退職者対応がある組織では、メモリ削除の運用手順を先に決めてください。
開発者向けチェックリスト
開発者は、次の順番で検証すると失敗を減らせます。
| 手順 | 内容 |
|---|---|
| Memory Storeを作成 | チャットモデル、埋め込みモデル、TTL、保存対象を設定 |
scopeを決める | 安定したユーザーIDまたはチームIDを使う |
| Agentにツールを追加 | memory_search_previewを設定 |
| 書き込みを検証 | update_delayを短くして保存タイミングを確認 |
| 検索を検証 | 静的メモリと文脈メモリを分けて確認 |
| レスポンス形式を確認 | memoriesコレクションに対応 |
| 削除を検証 | Memory Item単位、scope単位、store単位の削除を確認 |
| 監視を追加 | トークン使用量、検索回数、更新回数、失敗ログを確認 |
トラブル時は、まずscopeの不一致を疑ってください。Microsoft Learnのトラブルシューティングでも、検索結果が返らない原因として、保存時と検索時のscopeが一致していないケースが挙げられています。(Microsoft Learn)
失敗しやすいポイント
ユーザーIDが毎回変わる
scopeにセッションIDや一時IDを使うと、次回セッションで過去メモリを取得できません。長期メモリには、同じユーザーに対して変わらないIDを使います。
すべてを記憶させようとする
会話内容を何でも保存すると、後から不要な情報を削除するのが難しくなります。保存対象は、エージェントの品質向上に明確に役立つものに絞るべきです。
すぐ検索できる前提でテストする
update_delayにより、会話直後のメモリ更新は遅延することがあります。保存後すぐ検索するテストでは、明示的な更新APIや短い遅延設定を使って確認してください。
旧プレビューのレスポンスを前提にする
以前のresultsや/itemsに依存しているコードは、refresh後の形式で壊れる可能性があります。SDKやREST APIを直接使っている場合は、テストを自動化して差分を検出できるようにしておくと安全です。
メモリを権限管理に使う
「このユーザーは管理者である」といった情報をメモリに保存して権限判断に使うのは危険です。権限はMicrosoft Entra ID、アプリケーション側のRBAC、バックエンドの認可ロジックで判断し、Memoryは回答の文脈補助に留めるべきです。
どのような用途から試すべきか
最初の検証には、リスクが低く、効果が分かりやすい用途が向いています。
| 試しやすい用途 | 理由 |
|---|---|
| 社内ヘルプデスクの回答スタイル記憶 | 個人情報を抑えやすく、効果を確認しやすい |
| 開発者向けFAQエージェント | 使用技術や好みの回答粒度を記憶しやすい |
| 顧客サポートの検証環境 | 前回問い合わせ要約の有用性を確認しやすい |
| 業務手順アシスタント | Procedural memoryの効果を試しやすい |
反対に、医療、金融、法務、人事評価のようにセンシティブな情報を多く扱う領域では、プレビュー段階で本番データを使うのは慎重に判断してください。まずは匿名化データや合成データで、保存・検索・削除・監査の流れを確認するのが安全です。
まとめ：まずはscope、TTL、API差分を確認する
Azure AI Foundryの「Public Preview: Foundry Memory preview refresh」は、エージェントに長期記憶を持たせる機能を、より管理しやすい形に近づける更新です。特に、Memory Store、Memory Item、scope、TTL、memory_search_preview、直接のremember / forget操作は、今後のエージェント設計で重要になります。
まず着手すべきことは明確です。既存利用者は、旧APIパス、旧レスポンス形式、既存Memory StoreのTTL適用可否を確認してください。新規利用者は、Memory Storeを作る前に、どの情報を保存し、どの単位で分離し、いつ削除するかを決めるべきです。
Foundry Memoryは、うまく使えば「毎回同じ説明をしなくてよいエージェント」を実現できます。一方で、記憶させる情報を誤ると、プライバシー、セキュリティ、コスト、回答品質の問題につながります。プレビュー段階では、限定された検証環境でscope設計と保持ポリシーを固め、API変更に追従できる実装にしてから展開範囲を広げるのが現実的です。
コメント