Microsoft EdgeのStep 4: Memory & Persistence更新ポイント|管理者が確認すべき影響と設定

Microsoft Edge の「Step 4: Memory & Persistence」を調べている人が最初に押さえるべき結論は、これは Edge本体のボタン追加やUI変更ではなく、Microsoft Agent FrameworkでAIエージェントに“記憶”と“永続化”を持たせるための実装ステップだという点です。2026年6月26日に更新された公式情報では、エージェントがユーザーの好み、過去のやり取り、外部知識を文脈として扱えるようにする方法が説明されています。Edgeで業務アプリやAIエージェントを利用する組織では、ブラウザー設定を急いで変更するよりも、「何を保存するのか」「どこに保存するのか」「誰のデータとして扱うのか」「監査・削除できるのか」を先に確認することが重要です。(Microsoft Learn)

目次

Microsoft Edge の「Step 4: Memory & Persistence」とは何か

「Step 4: Memory & Persistence」は、Microsoft Agent Framework の入門チュートリアルに含まれるステップです。チュートリアル全体では、最初のエージェント作成から、ツール追加、複数ターンの会話、メモリと永続化、ワークフロー、ホスティングへと段階的に進む構成になっており、Step 4 は「context providers によって永続的な文脈を注入する」段階として位置付けられています。(Microsoft Learn)

ここでいう「メモリ」は、単にチャット履歴を保存する機能だけではありません。たとえば、次のような情報をエージェントが次回以降の応答に利用できるようにする考え方です。

メモリの種類具体例実務での使いどころ
ユーザー設定表示言語、回答の詳しさ、よく使う部署名社内ヘルプデスク、FAQボット、営業支援
過去のやり取り直前の相談内容、前回の未完了タスク問い合わせ対応、申請支援、作業継続
外部知識ナレッジベース、社内規程、製品情報RAG、社内検索、教育コンテンツ
監査用履歴入力、応答、注入された文脈品質評価、インシデント調査、改善分析

Edgeとの関係で見ると、これは「Edgeに記憶機能が追加された」というより、Edge上で動くWebアプリ、社内ポータル、Copilot系の業務体験、AIエージェント画面をどう安全に使わせるかという管理・設計テーマに近い内容です。

2026年6月26日の更新で確認すべきポイント

公式ページで最も重要なのは、エージェントのチャット履歴が既定で InMemoryChatHistoryProvider、または基盤となるAIサービス側の仕組みに保存される場合があると説明されている点です。OpenAI Chat Completion のようにサービス側の会話履歴保存を前提としない場合は、ローカルのインメモリ履歴プロバイダーが使われる例が示されています。(Microsoft Learn)

つまり、管理者や開発者は「メモリがあるかないか」ではなく、どのレイヤーで履歴を持つのかを確認する必要があります。インメモリであればアプリ再起動やセッション破棄で失われる可能性があります。一方、サービス管理型や外部ストレージを使う場合は、保存期間、暗号化、リージョン、アクセス権、削除要求への対応が設計課題になります。

セッションを使って複数回の実行で文脈を共有する

Step 4では、同じ AgentSession を使うことで複数回の RunAsync や run にまたがって文脈を共有する例が示されています。たとえば、ユーザーが「私の名前はAliceです」と伝えた後、同じセッション内で「私の名前は?」と聞くと、エージェントが前回の入力を参照できる設計です。(Microsoft Learn)

業務アプリで考えると、これは便利な反面、扱いを誤ると「別ユーザーの文脈が混ざる」「不要な個人情報を保持する」「退職者や異動者の情報が残る」といったリスクにつながります。ユーザーID、セッションID、テナントID、部署IDなど、どの単位で記憶を分けるのかを明確にしておくべきです。

Pythonでは ContextProvider と HistoryProvider の扱いに注意する

Python向けの説明では、永続化やメモリは ContextProvider と HistoryProvider の実装で扱うとされています。また、ローカル永続化を確実に使いたい場合は InMemoryHistoryProvider を明示的に追加すること、複数の履歴プロバイダーで load_messages=True を使って同じ呼び出しに履歴を重複投入しないことが注意点として示されています。(Microsoft Learn)

これは実装上の細かい話に見えますが、本番運用では重要です。履歴が二重に読み込まれると、回答がくどくなったり、古い文脈を過剰に信じたり、トークン消費が増えたりします。AIエージェントの精度低下はモデル性能だけでなく、メモリ設計の不備でも起こります。

本番環境では認証方式も見直す

公式ページでは、開発時に便利な DefaultAzureCredential について、本番環境では意図しない資格情報探索や遅延などに注意し、ManagedIdentityCredential など具体的な資格情報の利用を検討するよう警告されています。(Microsoft Learn)

Edgeから利用される社内エージェントであっても、裏側ではAzure OpenAI、Microsoft Foundry、外部API、ベクトルストアなどに接続する場合があります。ブラウザー側の見た目がシンプルでも、バックエンドの認証と権限設計が甘いと、不要なデータ参照や監査不能なアクセスにつながります。

影響範囲:誰が何を確認すべきか

この更新で、一般ユーザーがMicrosoft Edgeの設定をすぐ変更しなければならないわけではありません。影響が大きいのは、Edgeを業務ブラウザーとして使い、AIエージェントや社内AIアプリを提供している組織です。

対象者影響確認すべきこと
一般ユーザー直接の設定変更は少ないAIアプリが何を記憶するか、記憶の削除方法があるか
開発者メモリ実装の選択が必要AgentSession、履歴プロバイダー、外部ストレージの設計
Edge管理者ブラウザー利用環境の統制が必要Edge for Business、プロファイル分離、拡張機能、DLP
セキュリティ担当データ保持・監査・漏えい対策が必要PII、機密情報、ログ、リージョン、第三者サービス
グローバル管理者国・地域をまたぐデータ流通に注意データ所在地、契約条件、各国拠点の運用ルール

Microsoft Edge for Businessでは、仕事用ブラウザーと個人用ブラウザーを分離し、それぞれ別のキャッシュやストレージ場所を持つ設計が説明されています。AIエージェントのメモリを業務データとして扱う場合は、個人プロファイルではなく、Microsoft Entra IDでサインインした仕事用プロファイルで利用させる設計が基本になります。(Microsoft Learn)

設定変更は必要か

今回のStep 4は、Edgeのポリシーを一律で変更する更新ではありません。そのため、「全ユーザーにすぐ配布すべき新しいEdge設定」や「期限までに切り替えるべき移行作業」として捉えるより、AIエージェントをEdge上で提供する際の設計・運用チェック項目が増えたと見るのが実務的です。

ただし、組織でEdge for Businessを使っている場合は、既存の管理基盤を見直す価値があります。Microsoft Edge management serviceでは、構成ポリシーをMicrosoft Entraグループに割り当てられ、設定競合時には優先順位が使われる仕組みがあります。Intuneポリシーとして作成した構成はIntune管理センターにも同期されますが、割り当てやRBACなどに制約があるため、どこでポリシーを作成・管理しているかを整理しておく必要があります。(Microsoft Learn)

管理者が見直したいEdge関連設定

Edge自体にStep 4専用の設定が追加されたわけではありませんが、AIエージェント利用時には次の周辺設定が効いてきます。

確認項目見直す理由実務上の判断基準
仕事用プロファイルの利用業務データと個人利用を分けるためEntra IDサインインを前提にする
拡張機能の管理AI拡張や外部連携の過剰権限を防ぐため許可リスト方式を検討する
クリップボード制御応答内容や機密文書の持ち出しを防ぐためIntune MAMやDLP要件と合わせる
ダウンロード制御AIが生成・取得したファイルの保存先を統制するためOneDrive for Businessなど管理領域へ誘導する
監査ログ事故時に入力・出力・参照元を追えるようにするため個人情報を含むログは最小化・マスクする

Edge for Businessでは、Intune App Protectionや条件付きアクセスと組み合わせることで、クリップボード制限、保護されたダウンロード、透かし、漏えい防止などを仕事用プロファイルに適用できる説明があります。AIエージェントが社内文書や顧客情報を扱う場合、アプリ側のメモリ設計だけでなく、ブラウザー側のデータ保護も合わせて確認するべきです。(Microsoft Learn)

移行期限はあるか

公式のStep 4ページは2026年6月26日に更新されていますが、確認できる範囲では、Edge管理者向けの期限付き移行や強制変更は示されていません。内容はMicrosoft Agent Frameworkのチュートリアルであり、期限対応というより、AIエージェントを本番運用へ近づけるための設計ガイドとして読むのが自然です。(Microsoft Learn)

ただし、既に社内でAIエージェントを試験導入している場合は、移行期限がなくても早めに棚卸しを行うべきです。特に、PoCで作ったインメモリ履歴やローカル保存をそのまま本番に持ち込むと、再起動で履歴が消える、削除要求に対応できない、監査ログと回答履歴の整合性が取れないといった問題が起きやすくなります。

メモリ設計で失敗しやすいポイント

「チャット履歴の保存」と「業務知識の参照」を混同する

チャット履歴は、ユーザーとの過去の会話です。一方、業務知識は、社内規程、FAQ、製品マニュアル、顧客対応ルールなど、組織として管理すべき情報です。この2つを同じ場所に無造作に保存すると、古い会話を正しい規程のように扱ったり、個人の入力内容が別の回答に混ざったりします。

業務知識はRAGや検索基盤で管理し、ユーザーごとの好みや作業状態はセッションまたはユーザースコープのメモリで管理する、という分離が必要です。Agent Frameworkでは、会話履歴をベクトルストアに保存し、現在の入力と意味的に近い過去メッセージを取り出して文脈に追加する ChatHistoryMemoryProvider も説明されています。(Microsoft Learn)

ログに個人情報や機密情報を残しすぎる

メモリ機能を有効にすると、入力、応答、検索クエリ、検索結果、注入された文脈など、記録される情報の種類が増えます。ChatHistoryMemoryProvider の説明では、機微なテレメトリデータを有効にするとユーザーIDやメッセージ内容がそのままログに出る可能性があり、Traceログでは検索クエリや結果にPIIが含まれる可能性があるため、本番ではリダクターの利用や機微データの無効化が重要です。(Microsoft Learn)

「後で分析したいから全部残す」という運用は危険です。実務では、保存目的を「問い合わせ品質改善」「監査」「不正検知」などに分け、目的ごとに保存項目と期間を決めるほうが安全です。

Edgeの個人プロファイルで業務エージェントを使わせる

Edge for Businessでは、仕事用と個人用のブラウザーウィンドウでキャッシュやストレージ場所が分かれ、パスワードやお気に入りなども共有されない設計が説明されています。業務AIエージェントを個人プロファイルで使わせると、管理ポリシーやDLPの適用範囲が曖昧になりやすくなります。(Microsoft Learn)

特にグローバル企業では、地域ごとに個人利用端末、委託先端末、共同利用端末が混在します。Edgeでアクセスできるから安全、ではなく、どのプロファイルで、どのIDで、どのポリシーが適用されているかを確認する必要があります。

管理者が確認すべきチェックリスト

まず、社内で利用しているAIエージェントやAIチャット機能を一覧化します。Microsoft Agent Frameworkで実装されているものだけでなく、Edgeから利用する社内AIポータル、問い合わせボット、RAG検索、拡張機能型のAIツールも対象に含めます。

確認項目OKの状態要注意の状態
利用者の範囲Entraグループで対象者が明確URLを知っていれば誰でも使える
保存データ保存する項目が定義されている入力・応答をすべて無期限保存
保存場所テナント、リージョン、ストレージが明確外部サービスやローカル保存が混在
削除方法ユーザー単位・セッション単位で削除可能どこを消せばよいか分からない
ログ設計PIIをマスクし、必要最小限を保存Traceログを本番で常時有効
Edge管理仕事用プロファイルとDLPを前提化個人プロファイル利用を黙認
認証Managed Identityなど本番向け資格情報開発用資格情報を流用
監査入力、応答、参照元、実行者を追跡可能回答結果しか残っていない

次に、保存対象を「覚えてよい情報」「一時的に必要な情報」「保存してはいけない情報」に分けます。たとえば、表示言語や回答の長さは保存しやすい情報です。一方、マイナンバー、医療情報、未公開の人事情報、顧客の認証情報などは、AIエージェントのメモリに入れない設計を優先すべきです。

開発・検証時の進め方

実装チームは、いきなり全ユーザーにメモリ機能を有効化するのではなく、段階的に確認すると安全です。

手順作業内容確認ポイント
現状把握エージェントのセッション管理を確認履歴がどこに保存されているか
最小実装1ユーザー、1セッションで記憶を検証名前や好みが正しく保持されるか
永続化検証再起動後や再ログイン後に復元必要な範囲だけ復元されるか
分離検証別ユーザー、別部署、別テナントで試験文脈が混ざらないか
削除検証ユーザー単位で記憶を削除削除後に回答へ反映されないか
Edge検証Edge for Businessと個人プロファイルで比較DLP、ポリシー、拡張機能制御が効くか

Agent FrameworkのConversations & Memoryでは、AgentSession を作成し、各実行に渡し、必要に応じてシリアライズされた状態やサービス側の会話IDから復元する流れが説明されています。実装時は、このセッション状態を単なる技術情報としてではなく、業務データの一部として扱う必要があります。(Microsoft Learn)

グローバル組織で特に注意したい点

グローバル向けに整理する場合、最大の論点はデータ所在地と第三者サービスです。Microsoft Agent Frameworkの概要では、第三者サーバー、エージェント、コード、非Azure Directモデルなどを使う場合、利用者側がデータ共有、保持、所在地、権限、承認を確認する責任があると説明されています。(Microsoft Learn)

日本、EU、米国、APACなどで同じAIエージェントを展開する場合でも、同じメモリ設計がそのまま通用するとは限りません。少なくとも、次の観点は地域別に確認しておくべきです。

観点確認すること
データ所在地会話履歴、ベクトルDB、ログが保存されるリージョン
契約条件第三者サービスに入力・応答が渡るか
保存期間国・地域ごとの保存ルールに反しないか
ユーザー権利開示、訂正、削除要求に対応できるか
管理者権限地域管理者が閲覧できる範囲は適切か
言語差翻訳によって機密分類や禁止語がすり抜けないか

よくある疑問

Edge利用者は何か設定を変える必要がある?

通常のEdge利用者が、今回のStep 4だけを理由に設定を変更する必要は基本的にありません。確認すべきなのは、利用しているAIアプリが「記憶する」と表示している場合に、何を保存するのか、どこから削除できるのか、業務プロファイルで使っているのかという点です。

管理者に移行期限はある?

公式のStep 4ページ自体には、期限付きの移行作業は示されていません。移行期限よりも、既存のAIエージェントPoCが本番運用に近づいているかどうかを基準に、メモリ設計を見直すべきです。(Microsoft Learn)

ブラウザーのキャッシュやCookieと同じもの?

同じではありません。ブラウザーのキャッシュやCookieはWebサイトの表示や認証状態に関わるデータです。一方、Step 4で扱うメモリは、AIエージェントが会話や外部知識を文脈として利用するための設計です。ただし、Edge上で動く業務アプリから見れば、どちらもユーザー体験やデータ保護に影響するため、管理者はまとめて確認する必要があります。

どの情報から記憶させるべき?

最初は、機密性が低く、業務価値が高い情報に限定するのが安全です。たとえば、回答言語、部署名、よく使う業務分類、前回の作業状態などです。個人情報、認証情報、未公開の経営情報、顧客の秘匿情報は、保存しない設計を優先してください。

まず取るべき対応

Microsoft Edgeの「Step 4: Memory & Persistence」更新ポイントは、Edgeの見た目の変更ではなく、Edgeから利用されるAIエージェントを安全に賢くするための設計テーマです。管理者が最初にやるべきことは、Edgeの設定画面を探すことではなく、社内で使っているAIエージェントがどの情報を記憶し、どこに保存し、誰が管理し、どう削除できるのかを棚卸しすることです。

開発者は、AgentSession、ChatHistoryProvider、ContextProvider、外部ストレージ、ログ設計を確認します。Edge管理者は、Edge for Businessの仕事用プロファイル、Microsoft Edge management service、Intune App Protection、DLP、拡張機能管理を見直します。セキュリティ担当は、保存データ、テレメトリ、第三者サービス、リージョン、削除手順を確認します。

PoCの段階では「覚えてくれるAI」は便利に見えます。しかし本番環境では、「何を覚えないか」を決めることが同じくらい重要です。Step 4をきっかけに、AIエージェントのメモリを機能追加ではなく、ガバナンス対象の業務データとして扱う体制を整えましょう。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次