NVIDIA、NemoClaw で記憶駆動型エージェント「Chief of Staff」を構築

企業の業務は、メッセージ、意思決定、プロジェクト、義務など多岐にわたり、時間とともに変化します。こうした文脈を持たない状態で AI エージェントが活動を開始した場合、貢献する前に自らその背景を再構築する必要があります。

エージェントに必要な文脈を提供するため、当チームでは NVIDIA NemoClaw を活用し、「メモリー駆動型チーフ・オブ・スタッフ」を構築しました。このシステムは「セルフモデル」と呼ばれる人間が読みやすい知識層を維持します。これは、関連する人物、プロジェクト、優先順位、そして作業パターンに関するエージェントの記憶です。スケジュールされたジョブが定期的に新しい活動を見直し、義務事項を追跡し、時間の経過とともにユーザーの意思決定を取り込んでいきます。これまでの経験から、有用なエージェントの記憶には、単なる保存機能だけでなく、構造化、選択的な検索、ガバナンスが不可欠であることがわかります。

本稿では、NVIDIA NemoClaw で構築したメモリー駆動型エージェントが、実際の企業ワークフローにおいて生産性をどのように向上させるかを示します。また、他のエージェント開発でも応用できる 5 つの設計教訓をご紹介します。

• 日常業務を通じて文脈を維持し、タスクの品質を高める
• エビデンス、知識、行動を分離し、エージェントがより適切な判断を下せるようにする
• メモリー駆動型エージェントを設計することで、短期的な緊急性よりもユーザーの意図を優先させる
• ユーザーがエージェントの決定を修正できる仕組みを作り、信頼関係を構築する
• NVIDIA OpenShell を活用して、セキュリティと権限管理の境界線を明確に守る

日々の業務を通じて文脈を維持する

会話履歴は短期的な連続性を提供しますが、現在の優先事項と過去の意思決定、一時的なリクエストが混在してしまいます。検索機能で関連するソース資料を見つけることはできますが、エージェントには時間を超えた情報の連携が必要です。

プロジェクトの進捗状況に関する質問への回答を想像してみてください。その答えは、以前の意思決定や後続のメッセージでの訂正、未解決の義務、そして異なる 2 つの名前が同じプロジェクトを指しているという知識に依存する可能性があります。

これらの課題を解決するには、構造化された Markdown ページ上でこれら関係性を維持する「自己モデル（Self Model）」を活用できます。このモデルは、人物、プロジェクト、優先事項、目標、概念、そして反復的な作業パターンに関する情報を整理します。そのスキーマには、インデックス作成、相互参照、出典の追跡、および成長制限の定義が含まれています。

自己モデルは、ソース証拠を置き換えるのではなく、そこから導き出された解釈を保存するものです。この 2 つを分離しておくことで、開発者であるあなたは、誤った回答が証拠に起因するのか、記憶の維持プロセスの問題なのか、検索機能の限界によるものなのか、それともモデルの最終的な判断によるものなのかを明確に区別できます。

証拠、知識、実行の分離

メモリ駆動型のチーフ・オブ・スタッフから得られる 3 つの調整層を活用することも可能です：

Evidence → Knowledge → Governed execution

証拠は自己モデルの更新を支えます。各タスクにおいて、エージェントは関連する文脈の限定されたセットを検索します。その後、その文脈を NVIDIA NemoClaw の例の中で活用します。このアーキテクチャを図 1 に示します。

このシステムが保存するのは、主に2種類の情報です。

• 知識: 人物、プロジェクト、優先順位、そして作業パターン
• 判断: どの項目に注力すべきか、その優先順位は何か、ユーザーが既に見送ったかどうか

「知識」はマークダウン形式のエージェントメモリに蓄積されます。一方、「判断」や義務、優先順位付け、訂正履歴、監査イベントなどはSQLiteの台帳（ledger）に記録されます。この設計により、エージェントの判断を、メッセージ自体に既読フラグやラベル、フォルダ分けといった形で書き込むことなく保持できます。

例えば、メモリページには「共同作業者はSlackを好む」といった文脈が記されています。エージェントはこの情報を元にSlackの利用を提案できますが、実際にメッセージを送信するかどうかは、認証情報、ツールの権限、実行時のポリシー、そしてユーザーの承認に依存します。

コンテキスト（文脈）は行動を導くことはできても、それを許可する権限を持つわけではありません。

短期的な緊急性よりも、ユーザーの意図を優先する

「緊急です」というリクエストはよく見かけますが、緊急性が高いことが必ずしもユーザーの優先順位を反映しているわけではありません。そのため、意図ゲート（intent gate）では、ユーザーが明示した優先事項に関連する義務に対して最も高い階層を割り当てる仕組みを採用しています。

公開されたレシピでは、「緊急の経費ポリシー承認」というタスクは表示されますが、明示的な優先事項に基づく静かなリクエストよりも低いランクに位置づけられます。NVIDIA NemoClaw はこうした関係性を解釈し、決定論的なコード（deterministic code）によって階層サイズ、オーバーフロー動作、およびランキング順序を厳密に制御します。

ユーザーがエージェントの判断を修正できるようにする

永続メモリは、正しい判断だけでなく誤った判断もそのまま保存してしまいます。公開レシピを利用すれば、ユーザーは特定の義務を別の階層へ移動させたり、無視したりできます。その後のエージェント実行でも、この決定は維持されます。すべての変更は、書き込み専用（append-only）の監査証跡に一度だけ記録されます。

繰り返し現れる修正パターンに基づき、小さく読みやすい「優先度ポリシー」を自動的に更新することも可能です。ユーザーはモデル内部の状態に隠された設定を確認するのではなく、このポリシー自体を検索・編集・削除できます。

フィードバックループは常に可視化されています：

エージェントの判断 → ユーザーによる修正 → 監査イベント → 優先度ポリシーの更新

メモリを追加してエージェントのタスク性能を向上させる

NemoClaw にメモリ駆動型のチーフオブスタッフ機能を追加したことで、複数のエージェントタスクにおいて測定可能な改善が見られました（表 1 参照）。Agent Memory Benchmark と評価例は、サンプルリポジトリに含まれています。このリポジトリでは、自己モデルとの多段階検索を行うエージェントベースの 検索拡張生成 (RAG) ベースラインとを比較しています。

表 1：例のリポジトリにおけるアジェンティック RAG ベースラインと自己モデルの評価指標。両方の構成では NVIDIA Nemotron 3 Ultra を使用しています。

ランタイムで境界を強制する

この分離は、自律型エージェント向けの NVIDIA OpenShell セキュアランタイムと組み合わせた NVIDIA NemoClaw によって実現されます。NemoClaw は例示されたシステムを NVIDIA OpenShell に統合し、ライフサイクルを管理します。一方、NVIDIA OpenShell はエージェントをサンドボックス内で実行し、ファイルシステム、プロセス、ネットワークアクセスに対するガバナンスとポリシーの強制を行います。Managed Inference や MCP 接続における認証情報は、サンドボックスの外側に保持されます。

これは極めて重要です。メモリや取得されたコンテンツはモデルへの入力であり、信頼できるセキュリティポリシーそのものではないからです。もしエージェントがその文脈を誤解釈したり、悪意のある指示に従ったりした場合でも、オペレーターが定義したランタイムの境界内でのみ動作します。これにより、エージェントのアクセス範囲と、失敗が生じた際の潜在的な影響が制限されます。

エージェントメモリ構築への着手

本記事で紹介するメモリの設計を、ご自身の NemoClaw 例に適用するには、NVIDIA/nemoclaw-community GitHub リポジトリにあるオープンソースの Memory-Driven Chief of Staff レシピ と、その 設計提案書 を確認してください。

このレシピは、NemoClaw 向けのデプロイ可能な Hermes プロファイルとして例をパッケージ化しています。主な構成要素は以下の通りです。

-構造化されたメモリスキーマ

-永続的な義務台帳（Obligation Ledger）

-制約付きのランキングロジック

ユーザーによる修正と監査パス

スケジュールされたメモリメンテナンス

合成メッセージとメモリページ

オフラインでのウォークスルー

一連のユニットテスト

サンプルとして登場する人物、組織、プロジェクト、およびメッセージはすべて架空のものであり、オフラインのウォークスルーでは記録されたモデルの判断が推論の代わりを務めます。その後、コードによってランキング処理、修正、永続化、検証の各機能が適用されます。

今回のレシピはメモリ基盤に焦点を当てています。メッセージの送信やソースシステムの改変は行いません。この範囲設定により、職場アカウントへの接続なしで設計内容を検討することが可能です。ライブコネクタを使用する場合は、認証情報、プライバシー、保持期間、削除処理について別途対応が必要です。

NVIDIA NemoClaw や NVIDIA OpenShell に関する詳細は、それぞれのドキュメントをご覧ください。