Azure AI Foundryで「エージェントに前回の会話やユーザーの好みを覚えさせたい」と考えている場合、確認すべき機能がFoundry Agent ServiceのMemoryです。結論から言うと、Create and Use Memoryは、AIエージェントにセッションをまたいだ長期記憶を持たせるためのプレビュー機能であり、導入時はメモリストアの作成だけでなく、scopeによるユーザー分離、RBAC、保存してよい情報の定義、削除運用、料金影響までセットで確認する必要があります。
本稿では、2026年5月16日時点で確認できるMicrosoft Learnの「Create and use memory in Foundry Agent Service」と関連するMicrosoft公式情報をもとに、Azure AI FoundryでMemoryを使う際の変更点、影響範囲、管理者・開発者が確認すべき設定を実務向けに整理します。なお、対象のMicrosoft Learnページ自体の表示上の最終更新日は2026年4月10日となっています。(Microsoft Learn)
まず押さえる結論：Memoryはエージェントの「長期記憶」を管理する仕組み
Foundry Agent ServiceのMemoryは、ユーザー設定、過去の会話の要約、継続的に参照したいコンテキストをメモリストアに保持し、別セッション・別デバイス・別ワークフローでもエージェントが利用できるようにするマネージドな長期メモリ機能です。Microsoft Learnでは、メモリストアを作成・管理することで、ユーザーの好みや会話履歴を保持し、パーソナライズされたエクスペリエンスを提供できると説明されています。(Microsoft Learn)
重要なのは、Memoryが「チャット履歴をそのまま全部保存する箱」ではないことです。会話から意味のある情報を抽出し、統合し、必要なタイミングで検索してエージェントの応答に利用する仕組みとして設計されています。たとえば、カスタマーサポートエージェントなら「前回問い合わせた製品名」「希望する連絡方法」「解決済みのチケット番号」を覚え、旅行エージェントなら「通路側席を好む」「ベジタリアン食を選ぶ」といった情報を次回以降の応答に活用できます。(Microsoft Learn)
一方で、社内規程や製品マニュアルなどの組織ナレッジを検索する用途は、MemoryではなくFoundry IQやRAG構成、ファイル検索ツールを使うのが基本です。Microsoftの概念ページでも、時間をかけて保持されるユーザー固有のコンテキストにはMemory、組織のキュレーション済みコンテンツにはFoundry IQ、ユーザーが操作中に指定したドキュメントにはファイル検索ツールを使うという整理が示されています。(Microsoft Learn)
| やりたいこと | 適した機能 | 判断基準 |
|---|---|---|
| ユーザーの好みや過去のやり取りを次回以降も使う | Memory | ユーザーごとに継続して保持したい情報か |
| 社内文書、FAQ、規程、製品仕様を根拠に回答する | Foundry IQ、Azure AI Search、RAG | 組織が管理するナレッジを検索したいか |
| 今回アップロードされたファイルを参照する | ファイル検索ツール | 一時的な添付ファイルや会話中の資料か |
| 同じ会話内の直前の発言を踏まえる | 会話履歴、短期メモリ | セッション内だけで完結する文脈か |
Create and Use Memoryで確認すべき主な変更点
今回の公式情報で実務上のインパクトが大きいのは、MemoryがFoundry Agent Service内でメモリストアとして管理され、Python SDK、C# SDK、JavaScript SDK、REST APIから作成・更新・検索・削除できる点です。Microsoft Learnでは、メモリストアの作成、更新、一覧表示、削除、メモリの更新と検索、プロンプトエージェントへのMemoryのアタッチが各SDKとREST APIでサポートされるとされています。(Microsoft Learn)
Microsoft公式ブログでは、Foundry Agent ServiceのMemoryがMicrosoft Agent FrameworkおよびLangGraphとネイティブに統合され、外部データベースを別途プロビジョニング、スケーリング、保護しなくても、管理された長期メモリを使えるようになったと説明されています。また、メモリ項目のCRUD APIや、独自のユーザーIDヘッダーでメモリのスコープを定義できる点も新しい確認ポイントです。(Microsoft for Developers)
実務で見るべき変更点は、単に「Memoryが使えるようになった」ではありません。既存のエージェント設計に、永続化されるユーザー情報、ユーザー単位の分離、削除要求への対応、メモリ更新タイミングという新しい設計項目が加わる点が本質です。
| 確認項目 | 何が変わるか | 影響を受ける担当 |
|---|---|---|
| メモリストア | エージェントごとに長期メモリの保存先を設計する必要がある | 開発者、アーキテクト |
scope | ユーザー別・チーム別・テナント別のメモリ分離を設計する必要がある | 開発者、セキュリティ担当 |
| RBAC | FoundryプロジェクトやマネージドIDの権限を確認する必要がある | Azure管理者 |
| 保存対象 | 何を覚え、何を覚えさせないかを明示する必要がある | 開発者、法務、セキュリティ担当 |
| 削除運用 | ユーザー単位の削除やメモリストア削除の手順が必要になる | 管理者、運用担当 |
| コスト | モデル利用、メモリ更新、検索の利用量を監視する必要がある | 管理者、FinOps担当 |
導入前に確認すべき前提条件
Memoryを使うには、Azureサブスクリプション、Microsoft Foundryプロジェクト、チャットモデルのデプロイ、埋め込みモデルのデプロイ、SDKや環境変数を含むローカル環境が必要です。公式ドキュメントでは、チャットモデルの例としてgpt-5.2、埋め込みモデルの例としてtext-embedding-3-smallが挙げられていますが、利用できるモデルやリージョンは環境によって変わるため、実際のプロジェクトで確認してください。(Microsoft Learn)
運用環境では、キー認証よりもロールベースのアクセス制御を優先して設計するのが安全です。公式ドキュメントでは、プロジェクトのシステム割り当てマネージドIDを有効にし、プロジェクトを含むリソース側でFoundry Userを割り当てる手順が示されています。また、Foundry RBACロールは旧称からリネームされており、Foundry User、Foundry Owner、Foundry Account Owner、Foundry Project Managerは、以前のAzure AI User、Azure AI Owner、Azure AI Account Owner、Azure AI Project Managerに相当します。ロールIDと中核的な権限は変わらないものの、移行期間中は旧称が表示される可能性があります。(Microsoft Learn)
管理者は、次の点を先に棚卸ししておくと導入時の手戻りを減らせます。
| 確認対象 | 見るべきポイント | よくある失敗 |
|---|---|---|
| Foundryプロジェクト | 対象プロジェクトと環境の分離 | 開発・検証・本番で同じメモリストアを使ってしまう |
| マネージドID | 有効化とロール割り当て | エージェント実行時だけ権限不足になる |
| モデルデプロイ | チャットモデルと埋め込みモデルの両方 | チャットモデルだけ用意してMemory作成で止まる |
| リージョン | Memoryの提供リージョンとモデルの可用性 | アプリ、モデル、関連リソースの配置が不整合になる |
| プレビュー条件 | SLA、サポート、料金変更の可能性 | 本番前提の要件にプレビュー機能を無条件で組み込む |
メモリストア設計で失敗しないための考え方
公式ドキュメントでは、各エージェントに専用のメモリストアを作成し、メモリアクセスと最適化の境界を明確にすることが推奨されています。メモリストア作成時には、メモリ内容を処理するチャットモデルと埋め込みモデルのデプロイを指定します。(Microsoft Learn)
実務では、次のように「エージェントの責務」と「記憶してよい情報」をセットで定義します。
| エージェント例 | 記憶すると有効な情報 | 記憶しない方がよい情報 |
|---|---|---|
| 顧客サポート | 製品カテゴリ、過去の問い合わせ概要、希望連絡手段 | パスワード、本人確認情報、不要な個人属性 |
| 社内ヘルプデスク | 利用OS、よく使う業務アプリ、前回の解決策 | 人事評価、健康情報、機密プロジェクト名 |
| EC接客 | サイズ傾向、好みの色、返品理由の傾向 | クレジットカード情報、詳細住所、過度な嗜好情報 |
| 旅行支援 | 座席の好み、食事制限、航空会社の好み | パスポート番号、正確な現在地、支払い情報 |
user_profile_detailsは特に重要です。これは、ユーザープロファイルとしてどの種類の情報を抽出・保存するかをメモリシステムに伝える設定です。公式ドキュメントでも、旅行エージェントなら「航空会社の好みと食事制限」を優先する、または「年齢、財務、正確な場所、資格情報などの無関係または機密性の高いデータを避ける」といった指定例が示されています。(Microsoft Learn)
設計のコツは、「便利そうだから何でも記憶する」ではなく、「次回以降の応答品質を明確に上げる情報だけを記憶する」ことです。メモリは増えるほど便利になるとは限りません。不要な情報が増えると、検索精度、コスト、プライバシーリスク、削除運用のすべてが重くなります。
scopeは最重要設定：ユーザー分離を先に決める
Memory導入で最も失敗しやすいのがscope設計です。scopeは、メモリストア内でメモリ項目をどう分割するかを制御するパラメーターです。たとえばカスタマーサポートエージェントでMemoryを使う場合、各顧客が自分専用のメモリを持つように設計する必要があります。(Microsoft Learn)
メモリ検索ツールをエージェントにアタッチする場合、scopeに{{$userId}}を指定すると、ユーザーごとのメモリ分離をハードコードなしで行えます。この場合、システムはx-memory-user-idリクエストヘッダーがあればその値をユーザーIDとして使い、ヘッダーがなければMicrosoft Entra認証トークンのテナントIDとオブジェクトIDにフォールバックします。一方、低レベルのMemory APIを直接呼び出す場合は、各リクエストでscopeを明示的に指定する必要があります。(Microsoft Learn)
| シナリオ | 推奨されるscope設計 | 注意点 |
|---|---|---|
| 個人向けチャットエージェント | {{$userId}}または安定した内部ユーザーID | メールアドレスなど変更されやすい値は避ける |
| B2B SaaS | tenantId:userIdのような複合キー | テナントをまたいだメモリ混在を防ぐ |
| チーム共有エージェント | teamIdやprojectId | 個人情報を保存しない方針を明確にする |
| 検証環境 | dev-user-001など固定値 | 本番と同じメモリストアを使わない |
| 管理者テスト | テスト専用scope | 実ユーザーの記憶にテストデータを混ぜない |
特に危険なのは、すべてのユーザーで同じ静的scopeを使うことです。共有メモリとして意図している場合を除き、別ユーザーの好みや過去の会話が応答に混ざるリスクがあります。業務システムでは、scopeの設計をアプリケーションの認証・認可設計と同じレベルで扱うべきです。
Memoryの使い方は「エージェントツール経由」と「API直呼び」の2通り
Foundry Agent ServiceのMemoryは、大きく2つの方法で利用できます。1つはメモリ検索ツールをプロンプトエージェントにアタッチし、会話中にメモリストアを読み書きさせる方法です。もう1つはMemory Store APIを直接呼び出し、メモリの更新や検索をアプリケーション側で制御する方法です。Microsoftの概念ページでは、メモリ検索ツールは多くのシナリオに適し、Memory Store APIはより高度な制御が必要なユースケース向けと説明されています。(Microsoft Learn)
| 方法 | 向いている用途 | メリット | 注意点 |
|---|---|---|---|
| メモリ検索ツール | 通常の会話エージェント、サポートボット、接客エージェント | エージェント定義に組み込みやすい | scopeとupdate_delayの設計が必要 |
| Memory Store API | 独自UI、監査、明示的なメモリ更新、管理画面 | 更新・検索・削除を細かく制御できる | 各リクエストでscopeを明示する必要がある |
開発者が最初に試すなら、メモリ検索ツールを使う構成が分かりやすいです。実際のアプリケーションでは、エージェントにはメモリ検索ツールを付けつつ、管理画面や削除機能ではMemory Store APIを使う、という組み合わせが現実的です。
update_delayの理解不足で「記憶されない」と誤解しやすい
Memoryは、エージェント応答のたびに即座に長期メモリへ書き込まれるとは限りません。公式ドキュメントでは、エージェント応答後に内部的にupdate_memoriesが呼ばれるものの、実際の長期メモリへの書き込みはupdate_delay設定によってデバウンスされ、一定時間の非アクティブ状態後に完了すると説明されています。(Microsoft Learn)
そのため、検証時に「ユーザーが好みを伝えた直後、新しい会話で聞いても思い出さない」という現象が起きることがあります。これは不具合ではなく、メモリ更新がまだ処理中、またはupdate_delay待ちである可能性があります。API経由で即時更新したい場合は、update_delayを0にして更新処理を開始できます。公式ドキュメントでも、メモリ追加処理は長時間操作となり、約1分かかる可能性があると説明されています。(Microsoft Learn)
| 状況 | 原因の候補 | 確認方法 |
|---|---|---|
| 会話後すぐに記憶が見えない | update_delay待ち、処理中 | 待機時間を延ばす、更新APIの結果を確認する |
| 検索結果が0件 | 保存時と検索時のscopeが違う | 同じscopeで更新・検索しているか確認する |
| エージェントが記憶を使わない | メモリ検索ツール未設定 | エージェント定義にmemory_search_previewがあるか確認する |
| 別ユーザーの情報が出る | 静的scopeの共有、ユーザーID設計ミス | x-memory-user-idと認証連携を確認する |
検証環境では短いupdate_delayで挙動を確認し、本番では会話体験、コスト、不要な書き込みの抑制を考慮して調整するのが現実的です。
セキュリティとプライバシーで見るべき注意点
Memoryは便利な一方で、エージェントが保持する情報の性質が変わるため、セキュリティレビューの対象も広がります。Microsoft Learnでは、Memoryがプレビュー条件の対象であること、またMicrosoft製品使用条件やData Protection Addendum、Azureプレビューの追加使用条件に従うことが示されています。(Microsoft Learn)
特に注意したいのは、プロンプトインジェクションやメモリ汚染です。会話内容からLLMがメモリを抽出・統合するため、不適切なデータや悪意ある指示がメモリに保存されると、その後の応答やアクションに影響する可能性があります。Microsoftの概念ページでは、Azure AI Content Safetyやプロンプトインジェクション検出機能の活用、敵対的テストの実施がリスク軽減策として挙げられています。(Microsoft Learn)
管理者と開発者は、少なくとも次のルールを決めてから展開してください。
| ルール | 具体例 |
|---|---|
| 保存してよい情報を定義する | 好み、言語設定、過去の問い合わせ概要など |
| 保存しない情報を明示する | 認証情報、金融情報、詳細住所、健康情報、不要な個人属性 |
| ユーザーに透明性を持たせる | 「このエージェントは設定や好みを保存する場合があります」と表示する |
| 削除手段を用意する | ユーザー単位のメモリ削除、問い合わせ窓口、監査ログ |
| 本番前に攻撃テストを行う | メモリ汚染、別ユーザー情報の混入、削除後の再表示を確認する |
削除運用は最初から設計する
Memoryを使うと、ユーザーごとの情報がメモリストアに蓄積されます。そのため、削除要求やリセット要求に対応できる設計が必須です。公式ドキュメントでは、特定のscopeに紐づくメモリを削除する方法と、メモリストア全体を削除する方法が示されています。特定ユーザーのデータ削除や、特定ユーザーのMemoryリセットにはdelete_scopeが適しています。(Microsoft Learn)
一方、メモリストア全体を削除すると、すべてのscopeにまたがるメモリが削除されます。これは不可逆な操作であり、依存するエージェントが履歴コンテキストへアクセスできなくなる可能性があります。運用では、削除対象が「個人のメモリ」なのか「エージェント全体のメモリストア」なのかを手順書で明確に分けてください。(Microsoft Learn)
| 削除対象 | 使う操作 | 主な用途 |
|---|---|---|
| 特定ユーザーの記憶 | delete_scope | 個人データ削除、ユーザー単位のリセット |
| 特定チームの記憶 | delete_scope | チーム解散、プロジェクト終了 |
| エージェント全体の記憶 | メモリストア削除 | 検証環境の破棄、エージェント廃止 |
| 個別メモリ項目 | Memory item CRUD API | 誤った記憶の修正、ユーザーからの訂正依頼 |
削除運用では、実際にメモリが検索結果に出なくなるか、エージェント応答で再利用されないかまで確認してください。削除APIを呼んだだけでテストを終えると、キャッシュや別scopeに残った情報を見落とす可能性があります。
クォータ、リージョン、料金は本番前に必ず確認する
Foundry Agent ServiceのMemoryには、メモリストアあたりの最大scope数、scopeあたりの最大メモリ数、検索・更新リクエスト数のクォータがあります。Microsoftの概念ページでは、メモリストアあたり最大100スコープ、スコープあたり最大10,000メモリ、検索メモリとメモリ更新はいずれも1分あたり1,000リクエストと記載されています。(Microsoft Learn)
また、リージョンの可用性も展開前に確認が必要です。公式ページには利用可能リージョンとして東日本を含む複数リージョンが記載されていますが、プレビュー機能では提供リージョンやモデル可用性が変わる可能性があるため、実際のサブスクリプション、プロジェクト、モデルデプロイ先で確認するのが安全です。(Microsoft Learn)
料金面では、公式概念ページに「メモリとMemory Store APIの価格と課金はプレビュー中に変更される可能性がある」と明記されています。構成したチャットモデルと埋め込みモデルの使用量に対して課金される点も押さえておきましょう。Microsoft公式ブログでは、Memoryの課金開始時期や消費ベース料金の説明も掲載されていますが、料金は変更される可能性があるため、見積もり時は必ず最新の公式価格表を確認してください。(Microsoft Learn)
既存エージェントへの移行で注意すべきこと
既存のAzure AI FoundryエージェントにMemoryを追加する場合、単にツールを追加するだけでは不十分です。まず、現在のエージェントがどの情報を短期的な会話履歴で扱い、どの情報を長期メモリとして保持すべきかを分けてください。
たとえば、既存のFAQボットにMemoryを入れる場合、社内文書の検索結果をMemoryに保存する必要はありません。保存すべきなのは「このユーザーはMacを使っている」「回答は日本語で短くしてほしい」「前回はVPN接続エラーを解決した」といった、ユーザー固有で次回の応答品質を上げる情報です。
移行時の実務フローは次のように進めると安全です。
| 手順 | 作業内容 | 完了条件 |
|---|---|---|
| 現状整理 | 既存エージェントの用途、ユーザー、保存済みデータを確認 | Memoryで保持すべき情報が明文化されている |
| メモリ設計 | メモリストア、scope、保存対象、除外対象を決める | ユーザー分離と削除方法が決まっている |
| 権限設定 | マネージドID、RBAC、モデルアクセスを設定 | 開発・検証環境で認証エラーが出ない |
| 小規模検証 | テストユーザーで記憶、検索、削除を確認 | 別ユーザーへの混入がない |
| セキュリティ確認 | プロンプトインジェクション、機密情報保存、削除後再表示をテスト | リスクと対策が記録されている |
| 段階展開 | 対象ユーザーを限定して有効化 | メモリ操作、トークン使用量、品質を監視できる |
特に、本番投入前には「ユーザーAが登録した好みをユーザーBが参照できないこと」「削除後に検索結果へ出ないこと」「誤った記憶を修正または削除できること」を確認してください。これは機能テストというより、信頼性とコンプライアンスのテストです。
管理者と開発者の最終チェックリスト
Memoryを導入する前に、以下を確認しておくとトラブルを減らせます。
| 担当 | チェック項目 |
|---|---|
| Azure管理者 | Foundryプロジェクト、マネージドID、RBACロール、モデルデプロイ、リージョンを確認する |
| 開発者 | メモリストア、scope、update_delay、メモリ検索ツール、Memory Store APIの使い分けを設計する |
| セキュリティ担当 | 保存禁止情報、プロンプトインジェクション対策、メモリ汚染対策、監査ログを確認する |
| 法務・プライバシー担当 | ユーザーへの通知、削除要求、データ保持方針、プレビュー条件を確認する |
| 運用担当 | メモリ更新失敗、検索0件、認証エラー、コスト増加時の対応手順を用意する |
| プロダクト担当 | Memoryによって改善したいUXを定義し、不要な記憶を増やさない基準を持つ |
よくある疑問
Memoryを有効化すれば、エージェントは何でも覚えてくれますか
いいえ。Memoryは会話から重要な情報を抽出・統合して長期記憶として扱う仕組みですが、何を重視するかはuser_profile_detailsなどで設計する必要があります。むしろ、覚える範囲を絞った方が、応答品質、コスト、プライバシーのバランスを取りやすくなります。
社内文書の検索にもMemoryを使うべきですか
基本的には使いません。社内文書、規程、マニュアル、FAQのような組織ナレッジはFoundry IQやAzure AI Searchなどの検索・RAG基盤で扱い、Memoryはユーザー固有の継続的コンテキストに使うのが適切です。
scopeにはメールアドレスを使ってもよいですか
技術的には可能でも、実務では安定した内部ユーザーIDや匿名化されたIDを推奨します。メールアドレスは変更される場合があり、個人情報そのものでもあるため、tenantId:userIdのような安定した識別子を使う方が管理しやすくなります。
Memoryが反映されない場合、最初に何を確認すべきですか
まず、保存時と検索時のscopeが一致しているかを確認してください。次に、update_delayによる待機中ではないか、メモリ検索ツールがエージェント定義に正しく追加されているか、メモリストア名が正しいかを確認します。公式ドキュメントのトラブルシューティングでも、認証・認可エラー、処理待ち、scope不一致、ツール設定漏れが代表的な原因として挙げられています。(Microsoft Learn)
まとめ：Memoryは「便利機能」ではなく状態管理の設計変更
Azure AI FoundryのCreate and Use Memoryは、AIエージェントを一回限りの会話ボットから、ユーザーごとに文脈を引き継ぐ継続的なアシスタントへ近づける重要な機能です。ただし、長期記憶を持つということは、ユーザー分離、データ保持、削除、監査、コスト管理も同時に発生するということです。
まずは小さく始めるのが安全です。検証環境で専用メモリストアを作成し、scopeをユーザー単位で分離し、保存対象をuser_profile_detailsで絞り、記憶・検索・削除の一連の流れを確認してください。そのうえで、セキュリティレビューと運用手順を整え、対象ユーザーを限定して段階的に展開するのが現実的な進め方です。
コメント