🧭 この記事でわかること
- Copilot StudioのMemory機能が何を変えるのか、技術的に正確に理解できる
- Knowledge・Tools・Memoryの違いと、エージェント設計における役割分担が整理できる
- Memory導入前に整理すべきガバナンス観点と、使うべき業務・使わない業務の判断軸がわかる
👤 対象読者
- Copilot Studioで業務エージェントを設計・開発している人
- 社内AI活用の企画・導入を推進しているDX推進担当者・情シス
- 「チャットボット」と「AIエージェント」の違いを設計面で理解したい人
✅ 結論（先に言い切る）
Copilot StudioのMemoryは「AIが自動的に賢くなる」機能ではない。正確には「過去の経験をコンテキストとして引き継げるエージェント」になる機能だ。その違いを理解したうえで設計しなければ、ガバナンスリスクを抱えたまま運用することになる。
背景：なぜこの問題が起きるのか
現場で起きがちな状況
Copilot Studioで社内エージェントを作った組織が直面する典型的な不満がある。
- 毎回同じ前提を説明し直さなければならない
- 営業担当Aと担当Bが同じエージェントを使っても、個人に応じた支援ができない
- 継続中の案件やプロジェクトの経緯をエージェントが知らない
これはCopilot Studioが「会話をまたいで文脈を保持する仕組み」を標準で持っていなかったためだ。これまでも変数やDataverse、SharePointに情報を保存して疑似的に実現することはできたが、「何を保存するか」「いつ呼び出すか」「誰を識別するか」をすべて開発者が設計しなければならなかった。
放置すると何が困るか
- エージェントの「使い捨て体験」から脱却できず、継続利用率が上がらない
- 利用者ごとの業務文脈を引き継ぐために独自の記憶基盤を構築し、保守コストが増大する
- Memoryを誤解したまま「AIが自動学習する」として導入説明すると、後にユーザーの信頼を損なう
全体像：解決アプローチ（まず設計）
Copilot StudioにおけるMemoryの位置づけを整理すると、エージェントを構成する要素の中の「経験・文脈レイヤー」にあたる。
MemoryはKnowledgeでもToolsでもなく、「このユーザーとの関係の継続性」を担う層だ。設計時にこの役割分担を明確にしないと、何でもMemoryに詰め込もうとして設計が崩れる。
解決策：実装手順（再現できる形で）
Step 0. 前提（権限/環境/準備）
- 対象画面：Copilot Studioの新しいエージェント作成体験（New agent experience）
- 利用条件：Microsoft 365 Copilotのエンタープライズライセンス（M365 Copilot Chat側のMemoryはGA済み。Copilot Studio側のエージェントMemoryは2025年時点でPreview）
- 注意：Microsoft Learn の「What's new in Copilot Studio」によると、Memoryは新エージェント体験（New agent experience）でのみ有効化できる。クラシック体験では表示されない
- テナント管理者権限：テナント全体でMemoryを制御する場合はPeople Administratorロールが必要
Step 1. エージェントでMemoryを有効化する
新しいエージェント作成画面右ペインの「Memory」トグルをオンにする。
# エージェント設定の概要（Copilot Studio UIでの設定値イメージ）
agent:
name: "営業支援エージェント"
model: "gpt-4.1" # 既定モデル（GPT-5 ChatはGA済み、より自律的な動作が必要な場合に選択）
memory:
enabled: true
scope: "per_user" # ユーザーごとに記憶を分離（共有エージェントでは必須）
knowledge:
- source: "SharePoint/営業ナレッジ"
- source: "Dataverse/顧客マスター"
tools:
- name: "CRM更新"
- name: "議事録生成"
ポイント：KnowledgeにDataverseの顧客マスターが含まれる場合、Memoryとの優先順位を指示文（Instructions）で明示する。「公式データと記憶が矛盾した場合はKnowledgeを優先する」と明記しておくことが重要。
Step 2. 記憶させる情報の分類と指示文設計
Memoryは「何でも覚える」ようにするのではなく、記憶対象を明示的に設計する。以下の分類をInstructionsに記述する。
# エージェントの記憶設計指示文（抜粋）
## 記憶してよい情報
- ユーザーの役職・担当業務・担当案件名
- 回答形式の好み（箇条書き/文章、詳細/要約）
- 継続中の業務フェーズと直近の意思決定
- フィードバック（良かった点・修正依頼の内容）
## 記憶してはいけない情報
- 顧客の個人情報・連絡先（Dataverseから参照するのみ）
- 契約金額・与信情報（マスターデータを参照するのみ）
- 人事評価・個人の勤怠情報
## 矛盾時のルール
- KnowledgeのDataverse・SharePoint情報とMemoryが矛盾した場合は、Knowledgeを優先する
- 6ヶ月以上前の記憶は「古い可能性がある情報」として扱い、ユーザーに確認する
Step 3. 動作確認（テスト観点）
期待値
- 1回目の会話：担当案件名・好みを伝える
- 2回目以降：前回の文脈を踏まえて応答が変わる（毎回説明不要）
- 記憶更新時：「Memory updated」的な通知またはログが残る
失敗したときの切り分け
| 症状 | 原因の仮説 | 確認手順 |
|---|---|---|
| 記憶が引き継がれない | 新エージェント体験でない | 作成画面のURLとUIを確認 |
| 全ユーザーの記憶が混在する | per_userスコープ未設定 | Memory設定のスコープを確認 |
| 古い情報を優先する | Instructionsの優先順位が未定義 | 指示文に矛盾時ルールを追加 |
| M365 Copilot側と挙動が異なる | M365 CopilotのMemory（GA）とCopilot StudioエージェントのMemory（Preview）は別機能 | テナント管理者に確認 |
🔥 実務Tips（やると差がつく）
- 「Memory ≠ 再学習」をチームで合意してから導入する：Memoryを「AIが成長する」と説明すると、ユーザー期待値が現実を超える。正確には「コンテキストを継続利用できる」と説明する。
- 記憶のライフサイクルを設計段階で決める：「いつまで記憶を残すか」「誰が削除できるか」は機能有効化前に決めておく。後から決めようとすると、消せない情報が蓄積する。
- Memoryと相性の良いユースケースから小さく始める：継続的な個人秘書・営業伴走・育成支援など、「前回の文脈が価値を生む業務」から着手し、公式情報案内系には適用しない。
- 「Memoryを使わない」判断も設計だと伝える：情報系のエージェント（社内規程案内・申請手続き案内）にMemoryは不要どころか有害なケースがある。選択的に使う旨をガバナンスドキュメントに明記する。
⚠️ ハマりやすいポイントと回避方法
-
ハマり：「Memory = 自動学習」として展開説明し、ユーザーが「AIが賢くなっていない」と感じて不信感が生まれる
回避：「過去の文脈を次の会話に引き継ぐ機能」と正確に説明し、具体的な活用シナリオを事前にデモする -
ハマり：誤った情報をエージェントが記憶し、その後の回答に影響し続ける
回避：Instructionsに「6ヶ月以上前の記憶は要確認」ルールを入れ、ユーザーが随時記憶を削除できることをUI上で案内する -
ハマり：KnowledgeにあるDataverseの公式データとMemoryの情報が矛盾し、どちらが正しいかわからない
回避：指示文に優先順位を明示する（「Knowledgeソースの情報をMemoryより優先する」） -
ハマり：複数人が共同利用する窓口系エージェントにMemoryを適用し、利用者をまたいで文脈が混在する
回避：共同利用エージェントにはMemoryを適用しない。またはper_userスコープを明示的に設定する
運用・セキュリティの補足（ガバナンス設計の詳細）
テナント管理者によるMemory制御
M365 CopilotのMemoryは、Microsoft Graph APIを通じてテナント全体の有効/無効を制御できる。
# Copilot Memory のテナント設定確認
Connect-MgGraph -Scopes "PeopleSettings.ReadWrite.All"
$Uri = "https://graph.microsoft.com/beta/copilot/settings/people/enhancedpersonalization"
Invoke-MgGraphRequest -Method Get -Uri $Uri
# isEnabledInOrganization: True が既定
# テナント全体で無効化する場合
$Settings = @"
{
"isEnabledInOrganization": false
}
"@
Invoke-MgGraphRequest -Method Patch -Uri $Uri -Body $Settings -ContentType "application/json"
注意：このAPIはM365 CopilotのMemory（GA機能）に対するもの。Copilot StudioエージェントのMemory（Preview）の管理エンドポイントは別途Learnドキュメントを参照。
eDiscoveryとコンプライアンス
- Memory関連のデータはMicrosoft Purview eDiscoveryの対象となる
- 法的保全（Legal Hold）シナリオでは、Memory保存内容も対象に含まれる可能性がある
- 社内コンプライアンス部門と事前に連携し、保存対象・保存期間のポリシーを決定する
事故りがちなパターン
- 個人情報を含む発言が記憶される：ユーザーが自発的に顧客氏名・連絡先を発言→記憶される可能性。Instructionsで記憶禁止対象を明示しても完全防止は難しいため、利用者への運用ガイドラインが必要
- 退職・異動後の記憶が残る：担当者変更後に前任者の記憶が残り、後任者に影響する。定期的なMemoryレビューと削除フローを設計する
- Memory有効化で既存エージェントの挙動が変わる：既存エージェントのInstructionsがMemoryを想定していない場合、指示と記憶が競合する。既存エージェントへの適用は検証環境で先行確認する
📊 結果 / 効果（仮でもOK）
- 定量：「毎回の前提説明コスト」がなくなることで、1回の会話セッション開始に要するプロンプト入力が削減。M365 Copilot Memoryの先行事例では週あたり数時間の節約報告事例がある（Vodafoneグループで週3時間/人の効率改善報告）
- 定性：「使うたびに仕事を説明し直す疲れ」が解消され、エージェントの継続利用率が向上する
- エージェントが「単発で答えるAI」から「業務の経緯を知っているAI」へと位置づけが変わり、ユーザーの信頼度が変化する
| 観点 | Memoryなし | Memoryあり |
|---|---|---|
| 会話開始コスト | 毎回前提を説明（高） | 差分情報のみ伝えればよい（低） |
| パーソナライズ | 全員同じ応答 | 利用者ごとに応答が最適化 |
| 継続業務の支援 | 各会話は独立。経緯を知らない | 前回の意思決定・状況を踏まえた支援が可能 |
| 開発コスト | 記憶基盤を独自設計（高） | 標準機能で代替できる範囲が広がる（低） |
| ガバナンスリスク | 低（記憶しない） | 要設計（何を記憶させるか明示が必要） |
| 向いている業務 | 公式情報案内・申請案内 | 継続的伴走・個人秘書・育成支援 |
学び・まとめ
- 学び1：MemoryはRAGでもファインチューニングでもない。「過去の経験をコンテキストとして引き継ぐ」仕組みであり、モデル自体を更新するものではない。この正確な理解がないと、導入説明で誤解を生む。
- 学び2：「何を覚えさせるか」が設計の核心になる。Memoryをオンにするだけでは優秀なエージェントにならない。記憶対象・禁止情報・優先ルール・ライフサイクルを設計段階で決める必要がある。
- 学び3：Copilot StudioはチャットボットツールからAIエージェント基盤へ変わっている。Model・Instructions・Knowledge・Tools・Connected agents・Memoryという構成要素を見ると、Microsoftがエージェントをどう捉えているかが明確だ。これからのCopilot Studio開発は、この6要素を組み合わせる設計力が問われる。
✅ 次のステップ（ここから行動）
- 自分が担当するエージェントの業務が「継続的文脈が価値を生む」タイプか「毎回同じ正式回答を返すべき」タイプかを分類する
- Memoryを適用するエージェントについて「記憶してよい情報・禁止情報・優先ルール」をInstructionsに書く
- テナント管理者と「Memoryのテナント設定・eDiscovery対象・保存期間ポリシー」を事前確認する
- Copilot StudioのNew agent experienceで、テスト用エージェントにMemoryを有効化し、2セッション以上にわたる動作を検証する
- Memory導入に関する社内向け運用ガイドライン（何を言わない・どう削除するか）を1枚で作成する