Azure AI FoundryでAIエージェントを運用する場合、今回の「What is Memory? – Microsoft Foundry」で最初に押さえるべき結論は、Memoryが単なるチャット履歴保存ではなく、ユーザーごとの長期的な文脈を抽出・統合・検索するマネージドな長期メモリ機能だという点です。特に管理者と開発者は、scopeによるユーザー分離、メモリストアの作成単位、保存してよい情報の範囲、リージョン、対応モデル、削除運用を導入前に確認する必要があります。なお、現在の公式ドキュメントでは、Azure AI FoundryはMicrosoft Foundryへ名称整理されていますが、Azure上のAI開発基盤として同じ流れで理解して問題ありません。(Microsoft Learn)
Azure AI FoundryのMemoryは何が変わるのか
Azure AI Foundry、現在の公式表記ではMicrosoft FoundryのAgent ServiceにおけるMemoryは、エージェントがセッションをまたいでユーザー設定や会話の要約を利用できるようにする機能です。従来の多くのチャットボットは、会話が終わると文脈を失い、次回も同じ確認を繰り返す必要がありました。Memoryを使うと、エージェントは過去のやり取りから意味のある情報を抽出し、メモリストアに保持し、次回以降の応答で必要に応じて呼び出せます。(Microsoft Learn)
重要なのは、Memoryが「会話ログをそのまま全部保存して毎回プロンプトに入れる仕組み」ではないことです。公式ドキュメントでは、Memoryは長期メモリ用に設計されており、会話から有用な情報を抽出し、重複や矛盾を整理し、必要なタイミングで検索して使う仕組みとして説明されています。(Microsoft Learn)
管理・開発の観点では、次の変更点が特に大きいです。
| 観点 | これまで起こりがちな実装 | Memory利用時の考え方 |
|---|---|---|
| 会話の継続 | 過去ログをDBに保存し、独自に検索・要約する | Memory Storeに長期メモリを保存し、検索ツールまたはAPIで利用する |
| ユーザー分離 | アプリ側でユーザーIDと履歴を厳密に管理する | scopeでメモリを分割し、ユーザーごとに分離する |
| パーソナライズ | 毎回ユーザーに好みや条件を聞く | ユーザープロファイルメモリを会話開始時に活用する |
| セキュリティ | プロンプトやログ保存設計に依存しがち | プロンプトインジェクション、メモリ汚染、削除要求への対応が必須になる |
| 運用 | チャット履歴の量とコストが増えやすい | メモリの種類、件数、更新頻度、モデル利用コストを管理する |
Memoryで保存される2種類の長期メモリ
Memoryでは、主に「ユーザープロファイルメモリ」と「チャットサマリーメモリ」の2種類を扱います。どちらも長期メモリですが、使いどころが違います。(Microsoft Learn)
| メモリの種類 | 保存される内容 | 使うべき場面 | 設定のポイント |
|---|---|---|---|
| ユーザープロファイルメモリ | 名前、言語設定、食事制限、好みなど、ユーザーに関する比較的安定した情報 | カスタマーサポート、旅行予約、ECレコメンド、社内アシスタント | user_profile_detailsで保存対象・除外対象を明確にする |
| チャットサマリーメモリ | 過去の会話で扱ったトピックやスレッドの要約 | 前回の相談の続き、長期案件のフォロー、研究・調査エージェント | chat_summary_enabledをtrueにする |
たとえば、旅行予約エージェントであれば「窓側の席を好む」「直行便を優先する」「ベジタリアン食を希望する」といった情報はユーザープロファイルメモリに向いています。一方、「先週、東京出張の候補日を相談した」「前回はA社向け提案資料の構成を検討した」といった文脈はチャットサマリーメモリに向いています。
実務では、すべてを記憶させようとするのではなく、「次回以降の応答品質を明確に上げる情報だけ」を保存対象にするのが安全です。特に年齢、詳細な位置情報、金融情報、認証情報、健康情報などは、業務要件と法務・セキュリティ要件を確認したうえで、保存しない設計を基本にしたほうがよいでしょう。
Memoryの動作は「抽出・統合・検索」の3段階で考える
Memoryは、エージェントとの会話から情報を取り出すだけではありません。公式ドキュメントでは、抽出、統合、検索の3段階で動作すると説明されています。(Microsoft Learn)
| フェーズ | 何が起きるか | 実務上の確認ポイント |
|---|---|---|
| 抽出 | 会話からユーザー設定、事実、関連コンテキストを取り出す | 保存してよい情報と保存すべきでない情報をプロンプトや設定で明確にする |
| 統合 | 重複や類似内容をまとめ、矛盾する情報を整理する | プレビュー中は挙動が変わる可能性があるため、検証環境で再現性を確認する |
| 検索 | 応答に必要なメモリをメモリストアから探す | ユーザーごとのscopeと検索タイミングを間違えない |
ここで注意したいのは、MemoryがLLMを使って抽出・統合する点です。便利な一方で、悪意ある入力や誤情報がメモリに混入すると、以後の応答やアクションに影響する可能性があります。Microsoftは、プロンプトインジェクションやメモリ破損への対策として、Azure AI Content Safetyのプロンプトインジェクション検出や、攻撃的テストの実施を推奨しています。(Microsoft Learn)
対象者別に見る影響範囲
Memoryの影響は、開発者だけに閉じません。管理者、セキュリティ担当、アプリ運用担当、場合によっては法務・コンプライアンス担当も確認が必要です。
管理者が確認すべきこと
管理者は、まずMemoryを使うプロジェクトが対応リージョンにあるかを確認します。公式ドキュメントでは、東日本を含む複数リージョンでMemoryが利用可能とされていますが、Azureのリージョンやモデルの提供状況は変わることがあるため、本番展開前に利用リージョンとモデルの両方を確認してください。(Microsoft Learn)
次に、権限設計です。Memoryの作成・管理にはMicrosoft Foundryプロジェクト、チャットモデル、埋め込みモデル、認証・アクセス許可が必要です。運用環境ではロールベースアクセス制御が推奨されており、プロジェクトのマネージドIDにFoundry Userロールを割り当てる手順が示されています。(Microsoft Learn)
また、RBACロール名はAzure AI UserなどからFoundry Userなどへ名称変更されています。ロールIDとコア権限は変わらないとされていますが、画面や既存ドキュメントに旧名称が残る可能性があるため、社内手順書では新旧名称を併記しておくと移行時の混乱を防げます。(Microsoft Learn)
開発者が確認すべきこと
開発者にとって最重要なのは、scopeの設計です。scopeはメモリをどの単位で分割するかを決めるパラメーターで、メモリストア内の各スコープは分離されたメモリ項目の集合として扱われます。カスタマーサポートのようにユーザーごとの記憶が必要な場合は、各顧客が独自のメモリを持つように設計する必要があります。(Microsoft Learn)
メモリ検索ツールを使う場合は、scopeを{{$userId}}に設定すると、ハードコードした識別子を使わずにユーザーごとの分離を実現できます。バックエンドから代理で呼び出す構成ではx-memory-user-idヘッダーを渡し、ヘッダーがない場合はMicrosoft EntraのテナントIDとオブジェクトIDにフォールバックします。低レベルのMemory APIを直接呼ぶ場合は、各リクエストでscopeを明示する必要があります。(Microsoft Learn)
セキュリティ担当が確認すべきこと
Memoryは長期的に使われる情報を保持するため、通常の一時的なチャット履歴よりもリスク管理が重要です。特に確認すべきなのは、次の3点です。
| 確認項目 | なぜ重要か | 実務での対策 |
|---|---|---|
| メモリ汚染 | 誤情報や悪意ある指示が保存されると、後続の応答に影響する | Content Safety、プロンプトインジェクション検出、敵対的テストを導入する |
| 個人情報の保存 | ユーザーの好みや属性が長期保存される可能性がある | user_profile_detailsで保存対象を絞り、不要な個人情報を保存しない |
| 削除要求への対応 | ユーザー単位の削除や監査が必要になる | scope単位の削除手順、監査証跡、問い合わせ対応フローを用意する |
Microsoftのベストプラクティスでも、ユーザーごとのアクセス制御、機密データの最小化、プライバシーとコンプライアンス対応、メモリ使用量の監視が推奨されています。(Microsoft Learn)
導入前に確認すべき設定
Memoryを使うには、メモリストアを作成し、チャットモデルと埋め込みモデルを指定します。公式手順では、Python、C#、JavaScript SDK、REST APIで、メモリストアの作成・更新・一覧表示・削除、メモリの更新・検索、プロンプトエージェントへのMemoryアタッチがサポートされています。(Microsoft Learn)
導入時は、次の設定を順に確認すると抜け漏れを防げます。
| 項目 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| プロジェクト | Microsoft Foundryプロジェクトが作成済みか | 旧ポータルや旧SDK前提の手順と混在する |
| モデル | チャットモデルと埋め込みモデルのデプロイがあるか | リージョンでモデルが使えない |
| メモリストア | エージェントごとに専用メモリストアを作るか | 複数エージェントで共有し、意図しない参照が起きる |
scope | ユーザー、チーム、テナントなど、分離単位を決めたか | 保存時と検索時のscopeが一致しない |
user_profile_details | 保存対象・除外対象を具体的に書いたか | 「何でも覚える」設定になり、不要情報が保存される |
chat_summary_enabled | 会話要約を使う必要があるか | 短期会話だけの用途でも有効化してしまう |
update_delay | メモリ更新の遅延をどう設定するか | すぐ検索しても結果が出ず、未保存と誤解する |
特にuser_profile_detailsは、品質とプライバシーの両方に関わります。たとえば旅行エージェントなら「航空会社の好み、座席の好み、食事制限を優先し、年齢、金融情報、正確な位置情報、資格情報は保存しない」といった形で、保存してよい情報と避ける情報を具体的に指定します。(Microsoft Learn)
Memory検索ツールとMemory Store APIの使い分け
Memoryの利用方法は、大きく「メモリ検索ツール」と「Memory Store API」に分かれます。多くのケースでは、プロンプトエージェントにメモリ検索ツールをアタッチする方法が扱いやすいです。エージェントが会話中にメモリストアを読み書きでき、scopeとupdate_delayで更新対象とタイミングを制御できます。(Microsoft Learn)
一方で、Memory Store APIは、アプリ側でメモリ更新や検索を細かく制御したい場合に向いています。たとえば、CRMやチケット管理システムと連携し、特定イベント後に明示的にメモリ更新を行う場合や、検索結果をアプリ側でフィルタリングしてからプロンプトに渡す場合です。
| 利用方法 | 向いているケース | 注意点 |
|---|---|---|
| メモリ検索ツール | プロンプトエージェントで自然にMemoryを使いたい場合 | scopeを{{$userId}}にするか、静的値にするかを明確に決める |
| Memory Store API | 更新・検索・削除をアプリ側で細かく制御したい場合 | 各リクエストでscopeを明示し、保存時と検索時を一致させる |
開発初期はメモリ検索ツールで検証し、本番要件が複雑になった段階でAPI制御を増やす進め方が現実的です。
移行時の注意点
既存のAzure AI Foundry、Azure AI Studio、Azure OpenAI Assistants API、独自RAG構成を使っている場合は、Memory導入を単なる機能追加として扱わないほうがよいです。公式ドキュメントでは、MicrosoftのAIプラットフォームがAzure AI Studio、Azure AI Foundry、Microsoft Foundryへ進化しており、Assistants APIからResponses APIへの移行や、SDKパッケージの更新も整理されています。(Microsoft Learn)
移行時に確認すべきポイントは次のとおりです。
| 移行対象 | 確認ポイント |
|---|---|
| 旧ポータルのエージェント | 新しいFoundryポータルで同等の構成ができるか |
| Assistants APIベースの実装 | Responses API前提のAgent Serviceへ移行する必要があるか |
| 独自の会話履歴DB | Memoryに移す情報と、アプリ側に残すログを分ける |
| 独自ベクトルDB | 組織ナレッジ検索、ファイル検索、ユーザー長期メモリの役割を分離する |
| SDK | azure-ai-projects 2.xなど、新しい開発体験に対応するパッケージを確認する |
特に混同しやすいのが、Memory、Foundry IQ、ファイル検索の違いです。Memoryは時間をまたいで保持されるユーザー固有の文脈に使います。組織が管理する社内文書やナレッジを根拠に回答させるならFoundry IQ、会話中にユーザーがアップロードした文書を検索するならファイル検索ツールが適しています。(Microsoft Learn)
展開時に見落としやすい制限とクォータ
Memoryには、プレビュー段階の制限とクォータがあります。公式ドキュメントでは、メモリストアあたり最大100スコープ、スコープあたり最大10,000メモリ、検索メモリと更新メモリはそれぞれ1分あたり1,000リクエストとされています。また、互換性のあるAzure OpenAIチャットモデルと埋め込みモデルのデプロイが必要です。(Microsoft Learn)
本番展開では、単純に「1ユーザー1スコープ」とした場合に、メモリストアあたり最大100スコープという制限が設計上のボトルネックになる可能性があります。大規模サービスでは、エージェントやテナント単位でメモリストアをどう分けるか、スコープ数が上限に近づいた場合にどう運用するかを事前に検討してください。
また、Memoryは現在パブリックプレビュー段階で、価格と課金はプレビュー中に変更される可能性があります。公式ドキュメントでは、構成した基盤のチャットモデルと埋め込みモデルの使用に対して課金されると説明されています。(Microsoft Learn)
よくある失敗と対策
Memory導入でよく起きる失敗は、設定ミスそのものよりも「設計意図が曖昧なまま使い始める」ことです。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| メモリ検索で結果が返らない | 保存時と検索時のscopeが違う | ユーザーIDの正規化ルールを決め、ログにscopeを出す |
| 会話後すぐにメモリが見つからない | update_delayにより更新がまだ完了していない | 検証時はupdate_delayを短くし、本番は更新遅延を前提にUXを設計する |
| エージェントが保存済みメモリを使わない | memory_search_previewツール未設定、またはメモリストア名が違う | エージェント定義とメモリストア名をデプロイ前チェックに入れる |
| 個人情報が過剰に保存される | user_profile_detailsが曖昧 | 保存対象と除外対象を明文化し、レビューする |
| 削除時に影響範囲が分からない | メモリストアを複数エージェントで共有 | エージェント単位で専用メモリストアを作り、依存関係を台帳化する |
公式トラブルシューティングでも、認証・承認エラー、メモリ更新の遅延、scope不一致、メモリ検索ツール未設定が代表的な問題として示されています。(Microsoft Learn)
Memoryを使うべきケース、使わないほうがよいケース
Memoryは便利ですが、すべてのAIエージェントに必要な機能ではありません。導入判断は、次の基準で行うと失敗しにくくなります。
| 判断 | 向いている例 | 理由 |
|---|---|---|
| 使うべき | カスタマーサポート、旅行予約、社内ヘルプデスク、継続的な研究支援 | 過去の文脈やユーザー設定が次回以降の品質に直結する |
| 慎重に使う | 医療、金融、人事、法務相談 | 機密性が高く、保存範囲・削除・監査の設計が必須 |
| 使わなくてよい | 1回限りのFAQ、匿名の簡易問い合わせ、公開情報の検索 | 長期メモリより、RAGやファイル検索で十分な場合が多い |
たとえば社内ITヘルプデスクなら、「このユーザーはMacを使っている」「Teams通知の問題で前回問い合わせた」といった情報は有用です。一方、パスワード、個人の評価情報、詳細な端末ログを長期メモリに保存するのは避けるべきです。Memoryで覚えるべき情報は、ユーザー体験を改善し、かつ保存してもリスクが管理できるものに限定します。
管理者・開発者向け導入チェックリスト
Memoryを検証から本番へ進める前に、次の順番で確認してください。
| フェーズ | チェック項目 |
|---|---|
| 企画 | Memoryを使う目的、保存する情報、保存しない情報を決める |
| 設計 | scopeの単位、メモリストアの作成単位、削除単位を決める |
| 権限 | マネージドID、Foundry Userロール、API呼び出し権限を確認する |
| 環境 | リージョン、チャットモデル、埋め込みモデル、SDKバージョンを確認する |
| 実装 | user_profile_details、chat_summary_enabled、update_delayを設定する |
| セキュリティ | プロンプトインジェクション対策、機密情報の除外、監査証跡を設計する |
| テスト | 正常系だけでなく、誤情報、悪意ある入力、削除要求、スコープ不一致を試す |
| 運用 | トークン使用量、メモリ操作、検索失敗、更新遅延を監視する |
まず何をすべきか
Azure AI FoundryのMemoryを導入するなら、最初にやるべきことはコードを書くことではなく、「何を覚え、何を覚えないか」を決めることです。そのうえで、対象エージェントごとに専用のメモリストアを作成し、scopeでユーザー分離を設計し、user_profile_detailsで保存範囲を絞ります。
小さく始めるなら、1つの検証用エージェントで、ユーザープロファイルメモリだけを有効にし、保存される内容、検索結果、削除手順を確認してください。次に、チャットサマリーメモリを追加し、過去会話の継続性が本当に改善するかを評価します。Memoryは、うまく使えばエージェントの体験を大きく改善しますが、長期的に残る情報を扱う機能です。利便性より先に、分離、最小化、削除、監査を設計することが、本番導入の前提になります。
コメント