記事公開日
Copilot Studio の「会話をリセットする」では履歴が消えない？ Teams で検証してみた
この記事で分かること
Teams に公開した Copilot Studio のエージェントでは、会話が自動で区切られず、過去のやり取りが残り続けます。
さらに、公式ドキュメントによると、既定の「会話をリセットする」トピックでは、会話履歴は消去されません。
本記事では、Teams 上の会話履歴を本当にクリアする方法と、履歴が消えたかを確かめる際の注意点を、2026年10月時点の実機検証をもとに解説します。
- Teams の会話は、自動ではリセットされない：
過去のやり取りが数日にわたって保持され、古いコンテキストが回答に影響する可能性があります。 - 既定の「会話をリセットする」だけでは、履歴は消えないと公式は説明している：
会話履歴を消すには、「現在のセッションの会話履歴」をクリアするノードを追加する必要があります。筆者の検証でも、追加したときだけ前の会話を引き継がなくなりました。 - 見た目上のリセットと、本当の履歴削除は異なる：
「リセット」という言葉を使うと、履歴が残っていても、エージェントが忘れたように振る舞うことがありました。 - 履歴が消えたかを正しく判定する方法が分かる：
前の発言を覚えていなければ答えられない質問を使い、ノードの有無による違いを比較します。
こんにちは！DXソリューション営業本部の大和矢です。
Copilot Studio のエージェントを Teams で使い続けていると、過去のやり取りに引っ張られ、期待していない回答が返ってくることがあります。
そんなとき、システムトピックの「会話をリセットする」を実行すれば、これまでの会話履歴も消えると思っていないでしょうか。
公式ドキュメントによると、既定の「会話をリセットする」トピックでは、会話履歴は消去されません。
画面上では会話がリセットされたように見えても、エージェントが以前の発言を引き継いで回答する可能性があります。
では、Teams のエージェントに残った会話履歴を、本当にクリアするにはどうすればよいのでしょうか。
今回は、「会話をリセットする」トピックを既定のまま使った場合と、会話履歴をクリアするノードを追加した場合を比較し、リセット後も過去の会話を覚えているかを実機で検証しました。
この記事では、2026年10月時点の検証結果をもとに、次の点を紹介します。
- Teams のエージェントで会話履歴が残り続ける理由
- 既定の「会話をリセットする」では消えないもの
- 会話履歴をクリアするノードの追加方法（YAML）
- 履歴が本当に消えたかを正しく確かめる方法
Teams にエージェントを公開していて、「過去の会話に引っ張られている気がする」「必要なタイミングで会話を最初からやり直したい」と感じている方は、ぜひ参考にしてください。
Teams のエージェントは、会話が自動では区切られない
Teams では、エージェントとの会話は時間が経っても自動ではリセットされません。
公式ドキュメントにも、次のように書かれています。
Teams の会話は、自動リセットなしで数日にわたって保持されます。
出典：Microsoft Teamsにエージェントをデプロイする（Microsoft Learn・2026年10月2日確認）
同じページでは、セッションが自動的にリセットされる Web ベースの展開と Teams は異なる、とも説明されています。
この永続性によるリスクとして、公式は次の2点を挙げています。
- 古いコンテキスト：
会話履歴はクリアされない限り残ります。 - コンテキストの制限：
累積メッセージがモデルの制限を超える可能性があります。
コンテキスト（エージェントが回答を考えるときに参照する、これまでのやり取りの情報）が増え続けると、いつか上限に近づく、ということですね。
筆者の体感としても、やり取りが長く続くと挙動がおかしくなる場面がありました。
ただし、これは体感であって、原因を切り分けたわけではありません。
そこで、履歴を狙ったタイミングで消せないかを調べることにしました。
既定の「会話をリセットする」は履歴を消さない
結論から言うと、既定の「会話をリセットする」システムトピックは、会話履歴を消去しないと公式は書いています。
システムトピックの解説ページには、次の注記があります。
既定では、このトピックでは会話履歴は消去されません。Microsoft Teamsなどの一部のチャネルでは、広範な会話履歴が維持されます。会話のどこかの時点で会話履歴をクリアする場合は、[会話のリセット] システム トピックに既に含まれている [変数値のクリア] ノードに加えて、現在のセッションの [会話履歴] オプションで [変数値のクリア] ノードを使用する必要があります。
出典：システム トピックを使用する（Microsoft Learn・2026年10月2日確認）
ここで、本記事で使う言葉を整理しておきます。
トピックは、「メッセージ」「変数値をクリアする」といった処理の部品を順番に並べて作ります。
この部品を、以降「ノード」と呼びます。
また、「現在のセッションの会話履歴」をクリアする「変数値をクリアする」ノードを、以降「会話履歴クリアノード」と呼びます。
会話履歴クリアノードを足していない構成を「ノードなし」、足した構成を「ノードあり」と表記します。
なお、Microsoft の CAT チームのブログも、同じトピックについて次のように書いています。
By default, it doesn't clear conversation history or redirect to Conversation Start.
（既定では、会話履歴をクリアせず、会話の開始にもリダイレクトしません。）
出典：Design Copilot Studio Agents for Teams (Because Test Chat Was Too Easy)（2026年10月2日確認）
実際に既定のトピックを開くと、「メッセージ」「変数値をクリアする（現在のセッションのグローバル変数）」「すべてのトピックを終了する」の3つが並んでいます。
つまり、既定のトピックが消しているのは「グローバル変数（会話全体で使い回せる変数）」だけです。
公式は、会話履歴を消すには、このノードに加えて、会話履歴用のノードをもう1つ足すよう案内しています。
| ノード | 消えるもの |
|---|---|
| 既定の「変数値をクリアする」（現在のセッションのグローバル変数） | グローバル変数 |
| 追加する「変数値をクリアする」（現在のセッションの会話履歴） | 会話履歴 |
検証の準備：リセット用カスタムトピックを作る
検証のために、リセット専用のカスタムトピックを作り、会話履歴をクリアするノードを足しました。
既定のトピックはオフにして（動かないようにして）、中身を同じにしたカスタムトピック「会話をリセットする（カスタム）」を使っています。
狙ったときにだけ、リセットのトピックを動かす
リセットのトピックが、狙ったタイミングで確実に動いてほしかったので、トリガーを少し調整しました。
特定のワードを送ったときに起動するようにしてあります。
今回の検証では、ワードに「aaaaa」を使いました（理由は注意点の節で説明します）。
会話履歴のクリアは、YAML で追加する
2026年10月2日時点の筆者の環境では、「変数値をクリアする」ノードの変数の選択画面（システム・カスタム・環境・計算式の各タブ）に、「現在のセッションの会話履歴」を選べる場所が見当たりませんでした。
そこで、トピックのコードエディターを開いて、YAML を直接編集しました。
YAML の書き方は、Microsoft の Copilot Studio CAT チームのブログで紹介されている、「会話をリセットする」トピックを更新する例を参考にしました。
出典：Design Copilot Studio Agents for Teams (Because Test Chat Was Too Easy)（2026年10月2日確認）
既存の「グローバル変数をクリアするノード」と「すべてのトピックを終了するノード」の間に、次のノードを追加します。
上の1つ目が既存のノードで、2つ目が追加したノード（variables: ConversationHistory）です。
筆者は、追加したノードを「すべてのトピックを終了する」より前に置きました。
終了ノードの後ろに置くと実行されない可能性があるためです。
参考にした YAML と id が違うのはなぜか：
参考にした CAT ブログの例では、会話履歴をクリアするノードの id が「SLgE7u」になっています。
id は、トピックの中でノードを区別するための名前です。
画面で作ったノードの YAML は自動で生成されるため、筆者のトピックにも「sendMessage_OPsT1O」のようなランダムな文字列の id が付いていました。
一方、YAML に手書きするときは、自分で名前を付けられます。公式のサンプルにも「search-content」のような読める名前の id があります。
公式は、ノードを複製して修正するときは「すべての ID と変数が必ず一意になるようにしてください」と案内しています。
そのため、他のノードと重複しない名前であれば、参考例と同じである必要はありません。
また、CAT ブログの例は、既定の「会話をリセットする」システムトピックそのものを書き換えたもので、リセット後に会話の開始トピックへ移動するノード（BeginDialog）も入っています。
筆者の例は、カスタムトピックに履歴のクリアだけを足したものなので、周りのノードは異なります。
共通しているのは、「variables: ConversationHistory」を指定したノードを、「すべてのトピックを終了する」ノードより前に置いている点です。
出典：コード エディターを使用してトピックの YAML を記述および編集する（Microsoft Learn・2026年10月2日確認）
保存すると、エラーは出ず、キャンバスにも「現在のセッションの会話履歴」と表示されました。
ノードが2つ並んでいれば、追加は成功です。
保存したあとは、公開してから検証しています。
YAML を編集するときの注意：
筆者は、YAML を下手にいじって、キャンバスの表示が崩れたことがあります。
編集前に、元の YAML 全文を控えておくと安心です。
検証の方法：前の発言を覚えていないと答えられない質問を使う
履歴が消えたかどうかは、「前の発言を覚えていないと答えられない質問」で判定します。
リセットの前後で同じ質問をして、答え方が変わるかを見ます。
| 手順 | 送る内容 | 見るポイント |
|---|---|---|
| 1 | 昨日は○○を作りました！おいしかったです！ | 料理の話を履歴に入れる |
| 2 | 昨日の料理に合うワインを教えて！ | リセット前の対照。料理を踏まえて答えるか |
| 3 | aaaaa | リセットのトピックを起動する |
| 4 | 昨日の料理に合うワインを教えて！ | 判定。料理を踏まえるか、聞き返すか |
質問の中では、料理名を一度も言っていません。
履歴が残っていれば、エージェントは料理名を踏まえて答えられます。
履歴が消えていれば、「何を食べたか教えてください」と聞き返すはずです。
比較した条件は、次の2つです。
どちらも、リセットのトピックの返答は意味のない文字列（ノードなし：「ccccc」、ノードあり：「bbbbb」）にしました。
返答文そのものが結果に影響しないようにするためです。
| 条件 | トピックの中身 |
|---|---|
| ノードなし | 既定と同じ（グローバル変数のクリアのみ） |
| ノードあり | 既定＋会話履歴のクリア |
料理は毎回変えて（カルパッチョ、ラザニア、カレーなど）、前の回の話が混ざっても見分けられるようにしました。
検証結果：ノードを足した構成だけが、リセット後に前の会話を引き継がなかった
結果は、ノードなしではいずれも履歴が残っており、ノードありではいずれもリセット後に前の会話を引き継ぎませんでした。
どの回も、リセット前（手順2）は、料理を踏まえてワインを提案しています。
| 条件 | 料理 | aaaaa のあとの応答 |
|---|---|---|
| ノードなし | ラザニア | ラザニアに合うワインを提案した |
| カレー | カレーに合うワインを提案した（直前に同じ質問をしたことにも触れた） | |
| ペペロンチーノ | ペペロンチーノに合うワインを提案した（直前の提案を踏まえ、前回と違う角度から答えた） | |
| ノードあり | カルパッチョ | 料理の履歴が見つからないと返し、何を食べたか聞き返した |
| デミグラスソースのハンバーグ | 同上 | |
| 牛肉のタリアータ | 同上 |
ノードなし：履歴が残っていた
ノードなしでは、ラザニアの話をしたあとにリセットのトピックを動かしても、履歴が残っていました。
下の画像は、リセット前の応答です。
「aaaaa」を送ると、返答は「ccccc」でした。
そのあとで同じ質問をすると、ラザニアを前提にしたワインの提案が返ってきました。
カレーの回でも同様で、リセット後もカレーを前提に答えました。
さらに、「さっきも同じ質問があった」という趣旨で、直前のやり取りにも触れていました。
ペペロンチーノの回でも、リセット後に「前回と違う角度からおすすめする」と、直前の提案を踏まえて答えました。
ノードあり：前の会話を引き継がなかった
こちらも、まずリセット前です。
カルパッチョを作った話をしたあと、「昨日の料理に合うワインを教えて！」と聞くと、カルパッチョを前提にワインを紹介してくれました。
次に、「aaaaa」を送ってリセットのトピックを動かし、同じ質問をします。
すると、料理の履歴が見つからないと答え、何を食べたかを聞き返してきました。
カルパッチョの話は、前の会話に残っているはずなのに、出てきません。
デミグラスソースのハンバーグ、牛肉のタリアータでも、同じ結果でした。
なお、応答の中に利用者の名前が出てきますが、これはエージェントが利用者情報として持っているもので、会話履歴の漏れではありません。
この結果をどう読むか
ノードを足したときだけ前の会話を引き継がなかった、という結果は、公式の記述と一致します。
「既定のままでは履歴は消えず、会話履歴をクリアするノードを足す必要がある」という説明どおりの動きでした。
公式の言うとおり、履歴はリセットされていそうですね。
注意点：「リセット」という言葉が、消えていないのに消えたように見せる
検証でもう1つ気づいたのは、リセットを連想させる言葉を使うと、履歴が残っていても消えたように見えることがある、という点です。
最初の検証では、リセットのトピックを起動するワードを「リセット」にしていました。
このとき、リセット後の返答は、「会話をリセットしました。ここまでのやり取りは引き継がれません。」と「分かりました！」の2通りを試しました。
どちらの場合も、ノードなし（履歴をクリアしていない状態）なのに、リセット後はラザニアの話を覚えていないように振る舞いました。
同じノードなしの構成でも、ワードを「aaaaa」、返答を「ccccc」に変えると、前の節のとおり履歴が残っていました。
考えられる理由は、「リセット」という言葉そのものの影響です。
最初に紹介したシステムトピック（「会話をリセットする」）には、「リセット」や「Start over」のような言葉で起動する定義もあるため、その動きが影響した可能性があります。
Teams では、会話中に「やり直す」と入力すると、すぐに新しい会話が始まると、公式にも書かれています。
これは筆者の推測です。
出典：Teams と Microsoft 365 のエージェントを接続して構成する（Microsoft Learn・2026年10月2日確認）
この結果から、次の点に気をつけると良さそうです。
- 履歴が消えたかを確かめるとき：
ワードも返答も、リセットを連想させない文字列にする。 - 実運用でユーザーに「リセットしました」と返すとき：
その返答自体が、エージェントの応答に影響する可能性がある。履歴が実際に消えているかの判定には使えない。
よくある質問
Q. Teams のエージェントの会話履歴は、時間が経つと自動で消えますか？
公式ドキュメントでは、Teams の会話は自動リセットなしで数日にわたって保持されると説明されています。
そのため、履歴はクリアしない限り残ります。
累積したメッセージがモデルの制限を超える可能性があることも、公式はリスクとして挙げています。
Q. 既定の「会話をリセットする」トピックで、会話履歴は消えますか？
公式ドキュメントでは、既定ではこのトピックで会話履歴は消去されないと説明されています。
筆者の検証でも、履歴をクリアする処理（ノード）を足していない構成では、リセット後も前の会話の内容を踏まえて答えました。
履歴まで消すには、「現在のセッションの会話履歴」をクリアするノードを追加します。
Q. 会話履歴をクリアするノードは、画面から追加できますか？
2026年10月2日時点の筆者の環境では、変数の選択画面（システム・カスタム・環境・計算式の各タブ）に、「現在のセッションの会話履歴」を選べる場所が見当たりませんでした。
そのため、コードエディター（設定を文字で直接編集する画面）で YAML を編集し、会話履歴をクリアするノード（variables: ConversationHistory）を追加しました。
画面の仕様は更新で変わる可能性があるため、お使いの環境でご確認ください。
Q. 履歴がクリアされたかどうかは、どうやって確かめますか？
前の発言を覚えていないと答えられない質問を、リセットの前後で同じように投げて、答え方が変わるかを見ます。
筆者の検証では、リセット用のワードや返答に「リセット」という語を使うと、履歴が残っていても消えたように見えることがありました。
そのため、ワードや返答は意味のない文字列にして確かめました。
まとめ：Teams のエージェントには、会話履歴をクリアする仕組みを組み込んでおこう
今回の検証で得られた学びは、次の4つです。
- 1. Teams の会話は、自動ではリセットされない：
公式も、履歴が残り続けることによる古いコンテキストや、コンテキストの制限をリスクとして挙げています。 - 2. 既定の「会話をリセットする」だけでは、履歴は消えない：
公式の説明どおり、ノードなしでは履歴が残り、「現在のセッションの会話履歴」をクリアするノードを足したときだけ前の会話を引き継がなくなりました（筆者の環境で複数回確かめた結果）。 - 3. 見た目上のリセットと、本当の履歴削除は異なる：
「リセット」というワードや返答を使うと、履歴が残っていても、忘れたように見えることがありました。 - 4. 履歴が消えたかは、前の発言を覚えていないと答えられない質問で確かめる：
リセットの前後で同じ質問を投げて、答え方が変わるかを見ます。
なお、Microsoft 365 Copilot にもエージェントを公開できます。
筆者の使用感では、Microsoft 365 Copilot は新しいチャットとして会話を分けて使えるため、同じセッションをずっと使い続けない限り、履歴を引きずる悩みは Teams ほど感じませんでした（この点の公式の記述は未確認です）。
ただし、Microsoft 365 Copilot 上でカスタムエージェントを使う場合には、プラットフォーム上の制約があります。
公式の「既知の制限事項」では、たとえば次のような点が挙げられています。
- 会話の開始トピックがサポートされていない。
- セキュリティのために、埋め込み URL が削除される場合がある。
- 画像（や基本カード、ビデオなど）のメッセージの種類がサポートされていない。
こうした制約があるため、要件によっては、Teams に展開することが必須になる場合があります。
そのようなときは、会話を分けにくい Teams 側で、履歴をリセットするトピックが必要になりそうだと感じました。
Teams では会話を分けられないことから始まった悩みでしたが、履歴をリセットする仕組みを入れることで、対処できそうだと分かりました。
Teams にエージェントを公開している方は、まず検証用の環境で、今回のようにノードを足して試してみてはいかがでしょうか。
履歴のリセットは、エージェントを長く運用するうえで、あらかじめ用意しておきたい仕組みの1つだと感じました。
QUICK E-Solutionsでは、Copilot Studio / Power Platform 環境のセキュリティ・ガバナンス設計から、エージェント開発のPoC・本番構築、運用・継続改善まで一貫して支援しています。
以下のリンクからご提供しているサービスの詳細をご確認いただけます。
※このブログで参照されている、Microsoft、Microsoft Teams、Microsoft 365 Copilot、Copilot Studio は、米国およびその他の国におけるMicrosoft Corporationの商標または登録商標です。
