AIは習慣を記憶できる。実行権限には別の記録が要る

分析｜2026年11月7日

11月5日提出のプレプリント「Memory Trap」は、無害な対話で形成された記憶が、後の模擬タスクで範囲外の行動を誘発し得ると報告した。実運用の事故率を測った研究ではない。論文

製品上の問題は、ユーザーの言葉をどれほど正確に保存するかだけではない。保存した言葉に何を決定させるかである。私たちは、記憶はサービスを改善しても、外部の状態を変更する権限の唯一の根拠になるべきではないと考える。以下は Open Market Notes による設計分析であり、特定製品がこれらの制御を実装済みだという主張ではない。

個人化と許可は別の経路で扱う

仮想的な購買アシスタントを考える。ユーザーは質問を少なくし、使い慣れた取引先を優先し、メールを簡潔にしてほしい。こうした好みは見積もりの順位付け、説明の整理、下書きの作成に役立つ。一方、発注には、何を、誰から、いくらまで、どこへ配送し、更新契約を認めるかという別の答えが必要になる。習慣を詳しく記述しても、欠けている許可条件は埋まらない。

両者を自然言語のメモとして一緒に保存すると、重要な区別が曖昧になる。好みは許容される選択肢の順序を決めるが、許可はその選択肢を実行できるかを決める。確認の繰り返しを嫌うという好みを、あらゆる確認の免除と扱えば、サービス体験の要求が取引の境界を変えてしまう。これは私たちが指摘する設計上のリスクであり、実際の顧客事故の説明ではない。

モデルが行動案を作り、独立して管理される許可記録が実行可能性を判断する設計が望ましい。記録は複雑でなくてもよいが、操作、対象、上限、適用条件を表す必要がある。許可は継続購入を対象としても、単一注文に限定してもよい。明示的な継続許可について何度も質問する必要はない。しかし、不足する権限を会話の口調から推定すべきでもない。

アカウントへのアクセスと業務上の承認は違う

Claude の記憶ツールの文書では、ファイル操作の実行と保存はアプリケーション側が担う。公式文書 したがって、アプリケーション設計者はモデルの要求と実行の間に制御を設けられる。履歴の解釈だけに依存する必要はない。

MCP の認可仕様は、リソース所有者に代わって制限付きサーバーにアクセスする際のトランスポート層の認可を扱う。仕様 ここで私たちが区別したいのは、サービスを呼び出せる技術的接続が、今回の注文、受信者、共有先への承認を意味するわけではないという点だ。接続権限はクライアントが何にアクセスできるかを答える。業務上の許可は、今回何をしてよいかも答えなければならない。

たとえば、予定表アシスタントには日程を読み、会議を作成する継続的な権限が必要かもしれない。社内の定例会議には便利だが、未公開プロジェクト名を含む招待を外部へ送る場合、受信者と開示可能な内容を確認する必要がある。これは仮想的な設計演習であり、すべての社外会議に手動承認を求める提案ではない。許可は一般的なツール名ではなく、現在の事実を包含すべきなのである。

一括処理には例外の扱いが必要だ

企業がエージェントを購入する理由の一つは、調整の手間を減らすことだ。操作ごとに質問すれば、自動化の利益が承認負担に置き換わる。実用的な制御は、全部を許可するか、全部について尋ねるかという二択では足りない。

私たちは、許可条件を満たす項目と、重要な条件が変わった項目を分けることを提案する。既存顧客への請求リマインダー送付が承認されているとしよう。範囲内の通常の記録は処理できる。新しい入金口座、係争中の金額、異なる受信者が含まれる項目は、個別に停止するべきだ。キュー全体を止めるべきでも、一括承認で例外を無視するべきでもない。後の判断は明示された例外を解決するものであり、タスク全体の権限を暗黙に広げるものではない。

実行時に成立していた条件も残す必要がある。「承認済み」という記録だけでは、その後に何が起きたか説明できない。承認の出所、対象、制限、重要な変更、例外の解決方法が有用な監査情報になる。ユーザーにすべての内部情報を見せる必要はないが、ある項目は再確認なしで進み、別の項目はそうならなかった理由には答えられるべきだ。

完了率だけでなく境界を測る

購買テストでは、通常注文と例外注文の表現を似せ、商品と取引先は変えずに、支出上限、配送先、更新条件だけを変えられる。期待する結果は、あらゆる操作でためらうことではない。承認範囲内の仕事を進め、本当に範囲外の項目だけを提示することである。

私たちは、十分な許可のない実行、有効な承認があるのに繰り返される質問、例外によって無関係な通常業務が停止する時間の三つを同時に測る。これは私たちが提案する評価であり、論文の報告指標ではない。最初の指標だけを最適化すると、すべてを拒否するシステムが有利になる。完了率だけなら過剰な推定が有利になり得る。組み合わせて初めて、制御がサービスを改善したか判断しやすくなる。

権限変更後の動作も試す必要がある。ある取引先への自動購入許可を取り消した後、古い要約、待機中の仕事、別エージェントの言い換えによって許可が復活してはならない。確認は計画時だけでなく、実行の直前に行うべきだ。長時間のタスクでも最後の操作は現在有効な条件に従う必要がある。

このプレプリントは注目に値するが、単独で権限設計の有効性を証明するものではない。製品チームは自らのツール、データ、例外分布で検証しなければならない。現実的な目標は、相手をよりよく支援する方法を記憶しながら、重要な行動の権限の根拠を説明できるアシスタントである。二つの責任を分けることで、不要な中断と無許可の実行を同時に減らす余地が生まれる。