🧭 この記事でわかること

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枚で作成する