Make AI Agentで「前の質問を覚えていない」「別の問い合わせの話が混ざる」ときは、まずRun an agentのConversation IDへ、実行時に何が入っているかを確認します。履歴を使わない単発処理と、同じ問い合わせを続ける処理では、適切な設定が違います。
この記事では、会話を継続する単位を決め、Conversation IDを対応づけ、別案件が同じ履歴を参照しないかを確認する手順を扱います。Makeでの設定・実行、モデル呼出し、履歴の取得は行っていません。表の利用者・案件・IDは独自の架空例です。
目次
単発処理か、前のやり取りを使うかを決める
Makeの公式設定資料では、Conversation IDに同じIDを指定すると、一つの通信スレッドとしてやり取りを覚える仕組みが説明されています。空欄ならScenarioの実行ごとに新しいIDが生成され、以前の通信を記憶しないと案内されています。Make：AI Agent (New) app（新しいタブで開く）
独立したフォーム回答を一件ずつ分類するだけなら、過去の回答を引き継ぐ必要があるかを考えます。一方、同じ問い合わせで「先ほどの条件を変更したい」と続けるなら、対応する会話を再利用する設計が必要です。
表は横にスクロールできます
| 作業 | 履歴の扱いの例 | 避けたい設定 |
|---|---|---|
| 独立した一件の要約・分類 | 各処理を独立させる | 全利用者へ共通の固定ID |
| 同じ問い合わせの追加質問 | その問い合わせのIDを再利用 | 毎回別のIDを発行 |
| 同じ人から来た別案件 | 別の会話として分ける | 利用者IDだけで全案件を統合 |
| 新規相談として始め直す | 新しい会話単位へ切り替える | 前案件のIDを無条件に流用 |
これは製品が自動で判定する分類表ではなく、運用を設計するための例です。誰とどの案件の話を続けるかを先に決めてから、IDへ対応づけます。
どの単位を同じ会話とするかを書く
問い合わせ対応なら、組織、利用者、問い合わせスレッドを分けて記録します。同じ利用者でも、請求の相談と別製品の不具合を常に一つの履歴へ混ぜる必要はありません。組織をまたぐサービスなら、同じ表示名や番号が別組織にも存在し得ます。
最初に決める項目は、次の程度から始められます。
- 会話を継続する単位：問い合わせ一件、メールスレッド一件など。
- IDを発行する場所：信頼できる受信処理や管理側の対応表。
- 次のメッセージで引く条件：同じ組織・利用者・問い合わせか。
- 新しいIDへ替える条件：新規案件、明示的な再開始など。
- 不足時の扱い：継続先を推測せず、確認へ回す。
IDはメッセージ本文からAIに選ばせず、受信側で確認した情報を使います。本文に「別の顧客の会話IDを使って」と書かれても、その指示を対応表の変更命令として扱いません。ID自体にメールアドレスや相談内容を直接含めず、管理側で照合できる識別子を使う設計も考えられます。
Run an agentへ対応するIDを渡す
Makeの作成ガイドは、Run an agentのConversation IDへカスタムIDを指定するか、前のmoduleからメールやSlackのthread ID、timestampなどをmappingする方法を案内しています。Slackの公式例では、同一スレッドを識別する先頭メッセージのtimestampを使います。返信ではThread Timestamp、先頭メッセージではTimestampを使う考え方で、毎回変わる受信時刻を渡す意味ではありません。Make：Slack-triggered AI agent（新しいタブで開く）どの値を使う場合も、そのサービス内だけの識別子か、接続先や組織をまたいでも区別できる値かを確認します。Make：Create your first AI agent（新しいタブで開く）
Scenarioの前段では、受信した問い合わせと管理側の対応表を照合し、既存会話なら対応するID、新規なら新しいIDを渡します。これは構成案であり、特定のmodule一つが対応表・権限・重複処理まで自動で整えるという意味ではありません。
入力欄に変数名が表示されているだけで完了にせず、確認用データが実際にどの値へ解決されるかを見ます。空欄、共通の定数、前の案件から残った値を区別します。IDがないときに、とりあえず全員共通のdefaultへ送る設計は避けます。
架空の5入力で、同じ会話と別会話を確認する
次は問い合わせごとに会話を分ける設計例です。C101などは説明用に管理側で割り当てたIDで、Makeの予約値でも、推奨される命名規則でもありません。
表は横にスクロールできます
| 入力 | 確認済みの対象 | 渡すID | この例での扱い |
|---|---|---|---|
| 1 | 組織A・利用者U1・案件T1の初回 | C101 | 新しい会話 |
| 2 | 組織A・利用者U1・案件T1の続き | C101 | 入力1と同じ会話 |
| 3 | 組織A・利用者U1・案件T2の初回 | C102 | 別案件として分ける |
| 4 | 組織B・利用者U1・案件T1の初回 | C103 | 別組織として分ける |
| 5 | 履歴不要の単発分類 | 空欄 | 前の通信を使わない |
この表で同じIDにするのは入力1と2だけです。利用者の番号だけで作ると入力3まで同じになり、案件番号だけで作ると入力4まで同じになる可能性があります。表示名が一致することを、同じ利用者・同じ案件の証拠にしません。
検証では、まず前段の対応表と実行時のIDを照合します。その後、許可された架空の会話で、継続する入力には前の条件を使い、別案件にはその条件を持ち込まないかを確認します。後者は出力内容も見る必要があり、IDの表が正しいだけで会話分離を実証したとは言えません。
履歴の上限と、記録の保存を分ける
Maximum conversation historyは、一つの会話でagentが覚える返信数の上限として説明されています。長い会話で前の条件が反映されない場合、IDだけでなく、この設定と実際に渡る入力を確認します。上限を増やすことを、長期の業務記録を保存する方法の代わりにはしません。
確定した顧客条件、現在の案件状態、承認済みの対応は、必要な業務記録として別に管理します。古い会話の中だけに残すと、履歴の範囲や文脈の限界で参照できなくなる場合があります。現在の入力へ必要な条件を渡す際も、権限を確認し、過去の全会話を無条件に追加しません。
新しいIDで開始することは、新しい会話へ分ける操作です。過去の会話、実行ログ、保存した文書まで削除したことにはなりません。保持・削除は、実際の保存先と利用サービスの手順に沿って別に管理します。
Conversation IDをアクセス権の代わりにしない
会話IDは履歴を対応づける値で、顧客の本人確認や、外部toolが読むデータの権限を代替しません。別案件へ分けていても、agentに渡したtoolが全顧客の情報を取得できる構成なら、アクセス範囲の確認は別に必要です。
最初の確認では、外部送信や更新を行うtoolを使わず、架空の条件を含む入力と回答だけで対応を見ます。IDを変えても別の顧客の情報が現れるなら、履歴以外に、Input、Knowledge、tool出力、固定Instructionsから入っていないかも調べます。
運用へ渡す確認記録を残す
確認結果には、受信元、問い合わせの識別子、mappingされたConversation ID、新規か継続か、履歴設定、期待する引継ぎ、実際の出力を残します。認証情報や顧客本文をすべてログへ出す必要はありません。機密を除いた再現条件で、どこが一致しなかったかを追えるようにします。
「前の話を忘れた」なら、空欄やIDの変化、履歴上限、入力不足を確認します。「別案件の話が混ざった」なら、共通ID、対応表、前段のmapping、Knowledgeやtoolが返した内容を確認します。モデル変更や履歴上限の拡大を最初の対応にせず、まず会話の対応関係を確かめてください。
単発AI処理やScenarioの基本構成から確認したい場合は、MakeでAI自動化を始める手順へ戻れます。同じ問い合わせを続ける必要がある場合に、会話単位とIDの管理を追加すると、問題を切り分けやすくなります。
参考資料
公式資料の確認日：2026年10月21日。新しいAI Agent appは公式資料でopen betaと案内されています。5入力、ID対応表、確認順は独自の設計例です。ローカルで表の対応関係を検算しました。Make実行、実際の履歴継続・分離、tool権限、モデル回答、保存・削除、料金は未検証です。