AI エージェントの Memory を、訂正・検査・削除から考えてみた

はじめに

こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。

AI エージェントに、以前伝えた事情や好みを覚えていてほしい。毎回背景を説明し直す手間を減らせるなら、長期 Memory を持たせたくなります。ただ、使い続けることを考えると、覚えられるか以外にも気になることがあります。事情が変わったときに訂正できるか。間違った記憶に気付けるか。不要になった情報を、どこまで消せるか。

NVIDIA は Memory-Driven Chief of Staff レシピで、業務の文脈を整理して更新し、人間の訂正を次の判断につなげる設計を紹介しています。その考え方を手がかりに、記憶を使い続けるための仕組みを追ってみました。

https://developer.nvidia.com/blog/building-a-memory-driven-agent-with-nvidia-nemoclaw/

元記事の設計を支える保存処理を見るため、公開レシピを合成データで動かし、人間の訂正、Memory の検査、本文の保持期間を確かめました。製品の導入評価ではなく、そこから自分のエージェントに取り入れたい運用を考えるための検証です。

NemoHermes と OpenShell の実行基盤については、2026 年 6 月時点の記事で扱いました。今回はそのセットアップの続きではなく、保存した情報の扱いに焦点を当てます。

https://dev.classmethod.jp/articles/dgx-spark-nemohermes-openshell-hermes-agent/

この記事では、NVIDIA の設計思想を手元の挙動と照らし合わせながら、長期 Memory を使い続ける運用を考えます。後半では、その考え方を架空の業務ケースへ広げ、優先事項が変わり、元に戻り、不要な記録を消すところまで追います。NemoHermes に限らず、業務エージェントへ継続的な記憶を持たせようとしている人に刺さるといいなと思っています。

NVIDIA の元記事が伝えたいこと

2026 年 9 月 4 日公開の元記事は、日々変わる業務の文脈をエージェントへ引き継ぎ、判断の質を上げるための設計を紹介しています。中心にあるのは self model と呼ぶ知識層です。人物、案件、優先事項とその関係を整理し、定期的に新しい活動や本人の判断を取り込んで更新します。仕事ごとに取り出すのは、そこから必要な文脈だけです。会話を大量に保存することより、過去の決定と現在の状況をつなげて使えることを目指しています。

そのために、原文と派生した知識、実行を分ける。依頼に書かれた緊急度だけでなく、本人が示した優先事項を基準にする。誤った判断には本人が訂正を入れ、その訂正を後の判断にも反映する。こうした設計が、元記事の柱になっています。さらに、記憶は判断材料であって操作の許可ではなく、実行時の権限は OpenShell 側で制御する点も強調しています。

元記事が示す関係を、概念図に整理しました。

NVIDIA 元記事に基づく概念図。業務の記憶と人間の訂正を判断につなげる流れを示す。手元の実行構成ではない。

性能面では、両構成に NVIDIA Nemotron 3 Ultra を使った 186 問の評価で、複数回検索する agentic RAG の全体正答率が 82.8%、self model を使う構成が 90.9% だったと報告しています。一方、単一の情報を探す設問などでは下がった項目もあり、何でも Memory を足せばよくなるという結果ではありません。これは元記事の報告値で、自分の実測ではありません。

つまり、元記事の狙いは記憶容量を増やすことではなく、文脈の整理と人間による訂正、権限制御を業務の判断につなげることです。本稿ではそこを出発点に、状況が変わった記憶をいつまで使ってよいか、不要になったらどこまで消すかを掘り下げます。

困るのは忘れることだけではない

元記事が挙げているのは、会話履歴には現在の優先事項と過去の決定、一時的な依頼が混在するという問題です。本稿でも Memory を、会話や業務から得た情報を次回以降の判断へ引き継ぐ記録として扱います。モデルの重みを追加学習する話ではありません。

たとえば、これは架空の例です。ある案件では通常、顧客への返信を優先しています。そこへ障害が発生し、復旧までは障害対応を優先すると指示したとします。過去の方針を覚えていても、障害対応中に通常の優先順位へ戻ってしまえば困ります。

一方、この一時的な変更を継続的な好みとして保存するのも違いそうです。今回の障害だけに適用する指示と、通常時の方針。同じ優先順位の話でも、使う条件が違います。

元記事の考え方なら、新しい優先事項を既存の文脈と結び付け、判断に使う記憶を更新していきます。自分はその更新を、一時的な指示を追加するときだけでなく、適用を終えるときまで追ってみたいと思いました。以下では、その手がかりになる訂正・検査・削除の処理を確かめます。

公開レシピを題材に Memory の役割を分ける

NemoHermes は Hermes を使う NemoClaw の構成です。Memory-Driven Chief of Staff は、その環境で受信メッセージを整理し、本人の返信・判断・フォローが必要な用件を示すための公開レシピです。Hermes の標準 Memory そのものではなく、業務の状況を継続して把握するための仕組みを追加します。

レシピでは、業務の知識を Markdown の Memory として持ち、優先度や訂正などの業務状態を SQLite の Ledger に記録します。Ledger は判断と変更履歴を残す台帳です。本稿では、どちらも次回以降の判断へ持ち越す情報として扱いますが、以下の訂正の試験で確認するのは台帳側の状態です。

元記事では、証拠、知識、権限を制御した実行を分けています。その考え方にレシピの台帳を重ね、本稿では次の四つの役割として整理します。

これは説明のための分け方で、保存先を四つの製品に分割する提案ではありません。たとえば Memory に操作手順が書かれていることと、その操作を実行してよいことは別の話です。今回は実行権限を試したのではなく、保存された状態の変化を確認しています。

検証日は 2026 年 9 月 5 日、環境は Python 3.13.12 と SQLite 3.50.4 です。バージョンを固定した NVIDIA 公開版のスクリプトに合成メッセージと準備済みの判断結果を渡しました。次からは、観測した挙動と、それを踏まえた設計上の考えを分けて見ていきます。

人間の訂正は次回にも残るか

元記事では、本人による優先度の変更や無視の指定を、後続の実行でも守る設計が紹介されています。ここを保存処理でどう支えるかを見るため、人間の訂正が次の評価で上書きされないかを確かめました。合成データの用件に対して優先度を low に下げる訂正と無視の指定を行い、そのあと優先度を上げようとする合成レビュー結果を適用しています。ここでの無視は用件を対応対象から外す指定で、原文の削除ではありません。

この試験では手動の low 指定と無視の状態が維持され、元の本文も変わりませんでした。同じ訂正を再送した結果は次のとおりです。changed は、その操作で状態が変わったかを表します。

その後の無視の解除も含めて、ユーザーによる変更のイベントは 3 件でした。同じ指定の再送を新しい訂正として数えず、別の変更は履歴に残す挙動です。

ここで確認できたのは、LLM が人間の意図を理解したことではなく、保存処理が手動の指定を守ることです。人が直した内容を次に生かすには、更新後も訂正が残る仕組みが土台になります。自分が取り入れたいのは、本人の指示とエージェントの推測を区別して残し、何を優先したのか後から追えることです。

元記事はさらに、繰り返す訂正を、本人が確認・編集できる方針へ反映する流れも紹介しています。自分ならこの流れに、一時的な指示なのか、継続して使う方針なのかの区別を加えます。冒頭の例なら、復旧後には障害対応を優先する指定の適用を終えるためです。

方針更新の品質や、訂正の期限・適用範囲の管理は、今回の保存処理の試験では確かめていません。ここから自分の運用へ広げるなら、訂正した値とともに、誰の指示で、どの案件に適用し、いつ見直すかを持たせたいところです。

検査に通った Memory は正しいのか

self model を更新し続けるための土台として、元記事では索引、ページ間の参照、出典などの規則を持たせています。では、その構造が崩れたときに何が分かるのでしょうか。

次に、正常な合成 Memory に欠陥を一つずつ入れ、公開レシピの memory_check.py を実行しました。検査は 6 種類の構造上の異常を検出し、実行前後で Memory 自体は書き換えませんでした。

出典情報の検査は、今回対象としたページの規則に対する結果です。すべての記述について、原文との整合性を検証したわけではありません。

形式を壊さずに案件名を変えた最後の例は、検査を通りました。これは検出率の評価ではなく、検査合格だけでは原文との整合性を確認できないことを示す例です。

原文と派生した知識を分ける意味が、ここで具体的になります。元記事は、答えを誤ったときに、証拠、記憶の更新、検索、最後の判断のどこに原因があるかを調べやすくするための分離だと説明しています。構造検査の合格を内容の承認とするのではなく、形式を確かめたうえで、原文へ戻って内容を照合できるようにしておく設計です。

自分なら、機械的に拾える構造の異常と、要約や現在の方針が根拠に合うかを分けて確かめます。LLM に修復を任せる場合も、修復後の形式だけでなく、何を根拠に直したかを確認するところまでを一続きに扱いたいです。

忘れるとは何を消すことか

原文と知識を分ける設計は、削除の場面にも関わります。公開レシピに付属するデータライフサイクルの説明では、期限を過ぎた本文を消しても、判断や変更の記録は残す方針です。

保持期間を設定したときに、どの情報が消えるのかも確かめました。合成データの保存先へ古い本文 8 件と新しい本文 1 件を用意し、保持期間を 7 日にして処理しています。7 日は試験条件で、実運用の推奨値ではありません。

基準時刻は、実行時点から保持期間をさかのぼった時刻です。メッセージの日時がそれより前なら消去対象になります。厳密な境界比較は、CLI ではなく、公開レシピの関数に固定時刻を渡して確かめました。ここでの消去は本文フィールドに対する処理で、ストレージからの物理消去を確認したものではありません。

本文を消したあとも、メッセージの付随情報、未完了の用件、監査イベント、派生した Memory は残っていました。すでにエクスポートしていたファイルも残っています。

本文と判断履歴が分かれているため、本文を読み直せなくなっても、その用件をどう扱ったかは追えます。これは付属ドキュメントが示す使い方です。一方、関連情報そのものの削除が目的なら、本文を消す処理だけでは足りません。

ここから自分の運用で決めたいのは、派生した知識をいつまで使うかです。本文を 7 日で消すなら、そこから作った要約はいつまで使ってよいのか。人物情報や判断の履歴はどうするのか。原文の保持期間とは別に、保存先ごとに決める必要があります。

ここには、根拠を残すことと、不要な原文を消すことの間の難しさがあります。判断を説明できるよう原文へ戻れる状態を保ちたい一方で、そのために原文をいつまでも残すのでは、保持期間を設けた目的に合わないかもしれません。

知識を更新して使うという元記事の方針を採るなら、原文を参照できなくなった場合の扱いも更新の一部にしたいです。本人へ再確認するのか、履歴としてのみ保持するのか、派生情報も消すのか。自分なら、情報の使い道と保存の目的に合わせて、この扱いまで決めます。

記憶の保存と、判断への採用を分ける

ここまで、元記事の設計思想と、公開レシピの保存処理で確認した挙動を見てきました。ここからは、必要な文脈を取り出すという考え方を、今の判断に採用してよい記憶を選ぶ設計へ広げます。以下のデータ例と業務ケースは自分の考察を具体化したもので、レシピの実装仕様ではありません。実 LLM による判断品質や修復、外部指示への耐性、実環境での継続運用は未検証です。

自分なら、記録を保存する段階と、現在の判断へ採用する段階を分けます。過去に言われたことが、今も有効な指示とは限らないからです。この設計では、有効期間や適用条件が終わって指示を使わなくなることを失効、保存した内容を取り除くことを削除として区別します。失効した指示を履歴として残す場合でも、保存できる期間は別に決めます。

たとえば、冒頭の障害対応を優先する指示を、次のように記録するとします。この例は、Memory に持たせたい情報を示すための YAML で、そのままレシピへ渡す設定ファイルではありません。

kind: temporary_instruction
statement: この案件では、顧客への返信より障害対応を優先する
scope: 案件 A の今回の障害対応
asserted_by: user
source_ref: 本人の指示を確認できる原文への参照
status: active
end_condition: 本人による復旧完了の確認
review_after: 次の営業日の開始時

end_condition は指示が終了する条件、review_after は有効性を見直すタイミングです。翌営業日になっただけで復旧済みと見なさないよう、二つを分けています。説明用の例では日本語で書いていますが、実装では案件の識別子、復旧確認の記録、タイムゾーンを含む日時など、アプリケーションが照合できる値を持たせます。文章を置くだけで条件が自動判定されるわけではありません。

asserted_by: user も、LLM が自由に書けば本人の指示になる、という扱いにはしません。本人が確認した訂正の入力経路から設定し、エージェントが推測した候補とは区別します。外部メッセージに「最優先」と書かれていても、それだけで本人の指示へ昇格させない設計です。この区別の実装と権限の検証は、別に必要になります。

検索で関連する記録が見つかったら、対象の案件に適用できるか、終了していないか、見直しが必要ではないかを確かめます。形式的に判定できる条件はアプリケーション側で確認し、有効な指示だけを現在の判断用の入力に選ぶ方針です。候補や履歴を調査のために LLM へ渡す場合は、現在の指示ではない参照情報として区別します。

記録を使う直前の判断を図にすると、次の三つに分かれます。

本稿の設計案であり、レシピの実装仕様ではない。判断への採用可否と、保存データの削除は別に扱う。

適用範囲や状態を更新し続ける手間はかかりますが、構造検査に通っただけで古い指示を採用するのは避けられます。有効性を確認できないものは、推測で補わず本人へ確認する扱いにします。

優先事項が変わって戻るまでを追ってみる

元記事が示す、状況の変化と人間の訂正を次の判断へ反映する流れを、冒頭の架空の案件に当てはめます。ここでは、訂正を守るところから一歩進めて、必要がなくなった指示の適用を終えるまで追います。

案件 A では、本人が通常時は顧客への返信を優先すると決めています。障害が発生したため、復旧を確認するまでは障害対応を優先する、という一時的な例外を追加しました。通常方針と例外を分けて確認できたと仮定した設計例です。

この流れで大切なのは、優先度を一度下げたり上げたりできることより、通常時の判断へ戻る理由が残ることです。単に新しいメッセージが来たからではなく、本人が定めた終了条件を満たしたので、一時的な例外の適用を終える。復旧後に返してほしい説明は、たとえば次のようなものです。

案件 A は復旧の確認が取れ、一時的な障害対応優先の指示は終了しています。
引き続き有効な通常方針に従い、顧客への返信案から用意します。

これは実 LLM の出力ではなく、設計上期待する応答例です。過去の指示を覚えているだけでなく、なぜ今は適用しないのかまで説明するところを、このケースの到達点にします。記憶と操作の許可を分けるという元記事の方針に沿い、ここでは返信案の作成までとします。返信を優先する指示だけで、本人の承認なしに送信してよいとは扱いません。

復旧の確認が取れないまま見直しのタイミングになったら、状態を要確認へ変え、新たな優先順位の提案を保留して本人へ確認します。通常方針へ勝手に戻すことも、例外を確認なしに使い続けることもしません。ここで保留するのはエージェントによる優先付けであり、現場の障害対応を止める指示ではありません。通常方針も有効か不明なら、あわせて確認します。

削除でも、原文だけを消して終わりにはしません。この例では、終了した一時指示は今後使わない方針を選び、その原文と派生要約を削除対象にします。そのため、派生要約にも source_ref のような元の指示への参照を残し、対象の指示に依存する記録を探せるようにします。複数の情報をまとめた要約では、該当部分の除去や残す原文からの再生成を検討し、他の案件まで一括で消さない扱いです。

検索索引やエクスポートへ複製していた場合は、そちらへの反映も追います。訂正履歴に同じ本文をコピーして残しているなら、それも削除対象に含めます。

一方で、監査のために何かを残す要件があるなら、履歴を無制限に保存するのではなく、残す項目と期間、参照できる人を先に決めます。削除処理の記録にまで元の指示内容を複製する必要があるかは、別に考えたいです。バックアップや外部保存まで削除済みと説明するには、その保存先ごとの確認も必要になります。

もちろん、確認のたびに人を呼ぶと、任せるためのエージェントなのに手間が増えます。自分なら確認を厚くするのは、優先順位の変更や対外的な操作に関わる判断です。文体の好みのように誤っても直しやすいものは別の扱いにし、すべての Memory を同じ厳しさで管理するのは避けたいです。

更新し続けるために、保存する情報も選ぶ

元記事が述べる選択的な取得は、保存した知識からタスクに必要な範囲を取り出すことです。保存する情報そのものを減らす話とは区別します。自分はそれに加え、記憶を更新し続けられるように、何を長期保存するかも選びたいと思いました。

たとえば、受注金額や最新の期限のように別のシステムが正本を持つ情報は、判断の前にその正本を参照する設計を先に検討します。Memory に値を写しても、更新を追い切れなければ、古い値をもっともらしく使う経路が増えるからです。記憶するなら、値そのものではなく、どこで現在の値を確認できるかを残す選択もあります。

過去に一度だけ調べた情報も、再び必要になったときに原文を検索するだけで足りるかもしれません。検索は記録を探す手段なので、整理した Memory を検索する使い方もできます。両者は排他的な選択肢ではありません。原文を探す場合も Memory を探す場合も、見つかった記録が今も有効かの確認は必要です。

一方、本人が確認した継続的な方針や、何度も参照する案件の背景は、毎回履歴を読み直さずに使いたい情報です。そうしたものから対象を絞り、出所と有効範囲を持たせて保存する。長期 Memory を導入するなら、自分はその順で始めます。

目的は Memory を小さくすることではなく、再利用したい文脈を古いまま放置しないことです。これは元記事の性能評価を再現した結論ではなく、自分が更新と訂正を続けられる範囲から始めるための運用上の選択です。

まとめ

NVIDIA が示しているのは、会話を保存するだけでなく、業務の文脈を整理して更新し、必要な部分を判断に使う Memory の設計です。原文、派生した知識、判断と訂正の履歴を分け、人が直した内容を後の判断にも反映する。

自分はこの考え方を、指示の適用を終える条件や、不要な派生情報を消す範囲まで広げて扱いたいです。架空の案件で追ったように、障害対応中の指示を守るだけでなく、復旧後は有効な通常方針へ戻す。覚えた内容を固定して残すのではなく、事情の変化に合わせて直し、次の判断に使える状態を保つところまでを、Memory の運用として考えたいところです。

参考リンク

• Building a Memory-Driven Agent with NVIDIA NemoClaw
• Memory-Driven Chief of Staff README
• Memory-Driven Chief of Staff fixtures
• memory_check.py
• Data lifecycle
• NemoHermes で Hermes Agent を DGX Spark の OpenShell に載せてみた（2026 年 6 月時点の記事）