MemmyでVPSにAIエージェント共通メモリを構築

Memmy とは何か、何を保存するか

Memmy は、自分の VPS（仮想プライベートサーバー）上で動作する AI エージェント向けのローカルメモリーハブです。エージェントが学習した内容を 1 つの SQLite データベースに保存し、そのサーバー上のすべてのエージェントが同じストアを読み書きします。このプロジェクトは MemTensor の memmy-agent で、MIT ライセンスで提供されています。2026 年 11 月 1 日時点のバージョンは 1.2.401 です。Memory は独立してバージョン管理されており、バージョンは 2.1.7 です。

サーバー上で必要なのは、その一部だけです。Memmy には http://127.0.0.1:18960 で待ち受けるメモリーサービス、サービスと通信する memmy-memory コマンドラインインターフェース（CLI）、デスクトップワークベンチが含まれます。ワークベンチは macOS と Windows 用のみ提供されているため、Linux VPS ではサービスと CLI を実行します。これだけで、Claude Code、Codex、Cursor に共有メモリーを提供できます。

Memmy は保存する内容を 4 つのレイヤーに分類します。Capture はまず個別の Raw Turn を保存し、取得した各ステップについて、リクエスト、レスポンス、ツール呼び出し、結果を含む L1 Trace アイテムを 1 つずつ書き込みます。L2 Policy は、トレースから導出された手順で、実用性が確認されたものです。L3 World Model は、プロジェクトや環境に関する安定した知識です。Skill は、ポリシーから具体化された呼び出し可能な手順です。Capture は L1 トレースを作成し、バックグラウンドジョブが上位レイヤーを発展させます。明示的な書き込みでは、保存先のレイヤーを選択できます。これらの区別が抽象的に感じられる場合、メモリーは エージェント構築を学ぶ段階的な流れの後半に位置します。自分で単純なエージェントループを書き、実行するたびに状態をすべて忘れる様子を確認すると、各レイヤーの意味を理解しやすくなります。

ツールごとのメモリと比較した共有メモリハブの変更点

現在の各エージェントには、それぞれ独自のメモリがあります。Claude Code はリポジトリ内に指示ファイルを保持します。Cursor はワークスペースのデータベースにルールを保持します。Codex は ~/.codex 以下にセッションログを保持します。各ストアは 1 つのツールに属しているため、あるツールで月曜日に教えた事実を、別のツールは火曜日になっても認識できません。同じプロジェクトを再説明するために消費するトークンと、別の場所ですでに修正した前提に基づいてエージェントが誤った作業をすることの両方で、二重にコストが発生します。

ハブを使うと、ストアをツールの外部に移せます。Memmy は既存のストアも読み取るため、空のデータベースから始める必要はありません。スキャナーには、10 個の組み込みソースが登録されています。Claude Code は ~/.claude/projects/**/*.jsonl、Codex は ~/.codex/sessions/<YYYY>/<MM>/<DD>/rollout-*.jsonl、OpenCode は ~/.local/share/opencode/opencode.db、Cursor は state.vscdb ファイル、OpenClaw は ~/.openclaw 以下の SQLite データベース、Hermes は ~/.hermes、DeepSeek Harness は ~/.dsh/sessions、WorkBuddy は ~/.workbuddy/projects、Pi は ~/.pi/agent/sessions、QwenWork は ~/.qwenworkcn/projects です。デスクトップのワークベンチでは、エージェント名を指定して別のエージェントを追加できます。エージェントを自動検出できない場合にのみ、その履歴パスの入力を求められます。サーバー側のスキャナーにはカスタムソースがないため、ヘッドレス VPS では組み込みソースを使用します。

インポート時のカウンターが一致しないのは想定された動作です。スキャナーはメッセージをソースと会話ごとにグループ化し、完全なターンごとに 1 件の L1 メモリを書き込みます。空でないユーザーコンテンツがあり、空でないアシスタントメッセージで終わる場合、そのターンは完全とみなされます。不完全なターンは、後続の同期で完成するまで何も追加しません。メッセージは、会話のチェックポイントと安定したターン ID を使って重複排除されます。同じ実行でも、スキャン件数、インポートしたメッセージ数、新しいメモリ件数はそれぞれ異なります。

これは、Claude Code が 1 つのセッション内でコンテキストを管理する方法と対になる内容です。コンテキスト管理は、1 つのウィンドウに収める内容を決めます。メモリハブは、そのウィンドウを閉じた後も残る内容を決めます。

VPS に必要なもの

• Node.js 22 以降。Memmy のドキュメントで必要とされており、Ubuntu 24.04 に付属する Node.js は 18 です。
• git とビルドツールチェーン。better-sqlite3 は、インストール中にコンパイルされる場合があるネイティブモジュールです。
• root ワークスペースのインストールとフロントエンドのビルドチェーンに必要な RAM。
• node_modules とデータベース用の空きディスク容量。

sudo apt update
sudo apt install -y git build-essential python3 curl ca-certificates sqlite3
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs
node --version

node --version の結果は、ドキュメントに記載されたソースビルドでは v22 以上になるはずです。ここで v18 となる場合は、NodeSource の手順が適用されていません。npm の engine-strict のデフォルト値は false であるため、互換性のない engine 宣言があっても、通常は警告が表示されるだけで、インストールが自動的に失敗することはありません。

Ubuntu 24.04 にソースから Memmy をインストールする

git clone https://github.com/MemTensor/memmy-agent.git
cd memmy-agent
cp .env.example .env
npm install
npm run memory:build

npm run memory:build は @memmy/memory workspace を Memory/dist にコンパイルします。さらに、@memmy/memory workspace に必要な AgentSourceCore、メモリビューアー、統合用アセットもビルドします。ネイティブモジュールが読み込まれたことを確認します。

node -e "const Database = require('better-sqlite3'); const db = new Database(':memory:'); db.close(); console.log('better-sqlite3 loads')"

その行で出力されずに例外が発生した場合は、エラーを確認して、読み込みまたはデータベース初期化の失敗箇所を特定します。ネイティブモジュールの不一致が原因なら、npm rebuild better-sqlite3 を実行します。これは、プロジェクト独自の start script が処理を開始する前に実行するコマンドと同じです。

README では、bash scripts/dev-start.sh を 1 コマンドで起動する方法として説明しています。ヘッドレス VPS では実行しないでください。このコマンドは、メモリサービスと同時に Electron デスクトップシェルと port 19000 の Vite dev server を起動します。Electron にはディスプレイが必要なため、グラフィカルセッションのないサーバーでは script が停止するか終了します。

最近のリリースでは、Linux x64 および arm64 向けに memmy-agent-linux-cli.tar.gz と install.sh も提供されています。installer には、22.x では Node.js 22.23.4 以上、24.x では 24.22.1 以上、26.x では 26.12.1 以上と、systemd user session が必要です。これ以外の major version は拒否されます。installer は memmy と memmy-memory の launcher を ~/.local/bin に配置し、メモリサービスを 127.0.0.1:18960 の user unit として起動します。このガイドでは、実行前にすべての script を確認できるため、引き続きソースビルドを使用します。

メモリーサービスを起動して応答を確認する

npm run memory:serve:dev

これは、ソースからメモリーサービスを実行するための公式の方法です。サービスは 127.0.0.1:18960 にバインドし、データベースを ~/.memmy/memory-service/memory.sqlite に保持し、設定を ~/.memmy/config.yaml から読み込みます。明示的に指定する場合は、同じ値をフラグとして渡せます。

npm run memory:serve:dev -- \
  --host 127.0.0.1 --port 18960 \
  --db ~/.memmy/memory-service/memory.sqlite \
  --config ~/.memmy/config.yaml

2 つ目のシェルから、サービスが稼働しているか確認します。

curl -sS http://127.0.0.1:18960/api/v1/health

Health エンドポイントではトークンを要求しません。そのため、稼働確認に適しています。curl が終了コード 7 と Failed to connect to 127.0.0.1 port 18960 メッセージを返した場合、接続に失敗しています。ただし、それだけではリスナーの有無は判断できません。アドレス、ポート、ローカルファイアウォールを確認し、サービスを実行しているターミナルで起動エラーを確認します。サービスの起動後は、ss -lntp | grep 18960 によってソケットの存在を確認できます。

残りの HTTP API（アプリケーションプログラミングインターフェイス）は /api/v1 以下にあります。

• POST /api/v1/memory/add はメモリーを書き込み、POST /api/v1/memory/search はクエリを実行します。
• GET /api/v1/memory/:id と DELETE /api/v1/memory/:id は 1 件のエントリを読み取り、削除します。
• POST /api/v1/sessions/open と POST /api/v1/sessions/:sessionId/close はエージェントセッションの開始と終了を示します。
• POST /api/v1/turns/start と POST /api/v1/turns/:turnId/complete は 1 ターンを記録します。
• GET /api/v1/panel/overview、/api/v1/panel/analysis、/api/v1/panel/items はダッシュボードにデータを送ります。

Memmy は複数のポートを予約します。ヘッドレス構成では、最初のポートだけを使用します。18960 はメモリー用、18970 はゲートウェイのヘルスチェック用、18980 は Web UI と管理用 HTTP 用、18990 は memmy serve が起動する OpenAI 互換 API 用です。続いて、19000 はデスクトップフロントエンドの Vite 開発サーバー用、19001 はそのホットリロードソケット用です。プロジェクトのポート一覧には現在もホットリロード用として 19010 が記載されていますが、Vite の設定では 19001 になっています。使用環境ですでにいずれかのポートが使用されている場合は、その一覧を確認してください。

memmy-memory コマンドの由来

初回インストールで失敗しやすい箇所であるため、推測せずにパッケージから確認してください。コマンド名はリポジトリ名とは無関係です。これは、それを定義するワークスペースの bin フィールドから生成されます。

node -p "JSON.stringify(require('./Memory/package.json').bin)"

これを実行すると {"memmy-memory":"./dist/src/cli/index.js"} が出力されます。したがって、ビルドされたエントリーポイントは Memory/dist/src/cli/index.js となり、npm run memory:build を実行した後にのみ存在します。ビルドによって dist が作成され、ファイルに実行権限が付与されるためです。直接実行するには以下のようにします。

node Memory/dist/src/cli/index.js health

短い名前を PATH に追加したい場合は、同じファイルにリンクを作成してください。

sudo ln -s "$PWD/Memory/dist/src/cli/index.js" /usr/local/bin/memmy-memory
memmy-memory health

CLI はデフォルトで http://127.0.0.1:18960 を使用し、--url、--token、--config、--source、--user-id を受け付けます。サブコマンドには init、health、search、add、get、delete があり、さらに人間ではなくエージェントが使用する session および turn 呼び出し、そしてサービス自体を管理するための install、upgrade、service、stop があります。memmy-memory search "deploy steps" と memmy-memory add "staging migrates on deploy" は、エージェントが最も頻繁に実行する2つのコマンドです。

Claude Code を Memmy に接続するにはどうすればよいですか？

Memmy は Claude Code 内部にサーバーとして登録されません。Claude Code がすでに読み込むファイルを通じて接続し、動作範囲は実行する memmy-memory によって異なります。ソースチェックアウトから実行する場合、memmy-memory init --agent claude は memmy-memory Skill を ~/.claude/skills/ に、マーク付きのメモリーブロックを ~/.claude/CLAUDE.md に書き込みます。その後、Claude Code は、該当する指示に従うと memmy-memory を通常の shell command として実行します。Linux インストーラーが ~/.local/bin に配置するランチャーは、さらに処理を行います。同じ command が ~/.claude/settings.json に SessionStart、UserPromptSubmit、Stop、PostCompact、SessionEnd 用の hook も登録します。これにより、関連するメモリーが注入され、モデルが自分で判断しなくても、完了した各ターンが保存されます。

指示は一度手動で記述してください。そうすれば、agent に何を指示したかを正確に把握できます。Claude Code は各セッションの開始時にプロジェクトルートから CLAUDE.md を読み込みます。そのため、ソースから利用する場合は、次のようなセクションだけで統合できます。

## Memory

Before starting a task, run `memmy-memory search "<topic>"` and read what comes back.
When a task is done, run `memmy-memory add "<what you learned>"` for anything that will matter next session.

この統合で得られる効果を正しく理解してください。hook がなければ、これは指示レベルの統合です。モデルが command の実行を選択した場合にだけ機能します。実行を強制する仕組みはありません。セッションが add なしで終了した場合、指示だけでは何も保存されません。ただし、後から履歴をスキャンして完了したターンをインポートできます。これは Claude Code 自体のメモリーファイル と同じトレードオフです。ただし、1 つ違いがあります。ストアは共有されるため、同じマシン上の Codex と Cursor からもそのメモにアクセスできます。hook を使えば、モデルに依頼するだけでなく、この抜けを埋められます。そのため、永続メモリーは 導入する価値がある DeepSeek Harness プラグイン の中で、予算上限や権限ルールと並ぶ機能になります。

逆方向の連携には設定が必要ありません。Memmy のスキャナーはすでに ~/.claude/projects/**/*.jsonl を読み込みます。これは Claude Code がセッションのトランスクリプトを書き込む場所です。tmux セッション内で Claude Code を実行しているのと同じサーバーで Memmy を実行すれば、昨日の作業が設定なしでメモリーになります。

MemmyはClaude CodeのMCPサーバーとして動作しますか？

いいえ。この方向性を理解しておくと、時間を無駄にせずに済みます。MCP（model context protocol）にはクライアントとサーバーがあります。Memmyはクライアントです。MCPサーバーに接続し、そのツールを自身のエージェントランタイムに提供します。claude mcp addが接続できるMCPエンドポイントを公開することはありません。リポジトリ内で唯一のMCPブリッジは、desktop local API内のComposio統合に属しています。このAPIは127.0.0.1でランダムなポートを待ち受け、独自のx-memmy-mcp-tokenヘッダーで保護されます。

クライアント側の設定は~/.memmy/config.yamlで行います。このファイルはMEMMY_CONFIGが参照し、tools.mcpServersの下に配置されています。

tools:
  mcpServers:
    example:
      type: stdio
      command: npx
      args:
        - "-y"
        - "your-mcp-server"
      toolTimeout: 30
      enabledTools:
        - "*"

typeはstdio、sse、streamableHttpを受け付けます。stdioサーバーはMemmyの子プロセスとして実行されます。そのため、コマンドは同じホスト上に存在し、同じユーザーとして実行できる必要があります。すでにVPS上で実行しているMCPサーバーがある場合は、それらをここに記載します。

メモリストアを非公開に保つ

Memmy が所有するデータはすべて ~/.memmy 配下にあります。config.yaml、ワークスペース、memory-service/memory.sqlite、ランタイムファイルが含まれます。スキャンと取り込みはローカルで実行され、メモリはローカルの SQLite ファイルに書き込まれます。そのため、デフォルトの構成は実質的にローカル限定です。

クラウド接続は確認が必要な経路の 1 つです。MEMMY_CLOUD_SERVICE はクラウドの送信先を指定します。コードにはデフォルト値がありませんが、インストール手順で .env.example を .env にコピーすると、https://api.memmy.cn が設定されます。この設定により、試用トークンを使うアカウントモードが機能します。また、設定されている場合は、API key モードでも Memmy の分析コードが使用状況イベントを送信します。送信内容はイベント名とコマンド名、バージョン、インストール ID です。CLI が報告するのは固定されたコマンド名だけで、検索クエリやメモリの本文は送信されません。分析コードは値が未設定の場合には何も送信しません。そのため、API key のみを使用するサーバーでは、何かを開始する前に .env の該当行を空にしてください。メモリ改善プログラムは、プライバシー設定にある別の切り替え項目です。

モデル呼び出しも別の経路です。ホスト型の embedding provider を設定すると、embedding の対象となるメモリ本文がその provider に送信され、ベクトルに変換されます。ローカルストレージを使っていても、この送信は防げません。この経路を閉じるには、組み込みのローカル embedding provider、または自分でホストする embedding endpoint を使用してください。ホスト型の summary、evolution、relevance-filter モデルにも、これらのジョブの実行時にメモリ内容が渡されます。これらのモデル設定も確認してください。

port 18960 は loopback address にバインドしてください。127.0.0.1 にバインドされたサービスはホスト外部から到達できないため、firewall rule は必要ありません。代わりに、SSH 経由で laptop から接続します。

ssh -N -L 18960:127.0.0.1:18960 you@your-vps

現在の memory service は、loopback 以外の bind address を拒否します。設定で storage.token、または MEMMY_MEMORY_TOKEN や MEMORY_SERVICE_TOKEN の environment variable を設定すると、通常の memory API call を bearer token で保護できます。health endpoint は認証されないままで、browser viewer は local request に対して別のチェックを使用します。設定値では ${ENV_NAME} 参照を使用できるため、token と model API key をファイル自体に記載せずに済みます。これは、他の場所でも AI agent の外部に secret を置かない ための習慣と同じです。また、将来のバージョンでデフォルトの bind address が変更された場合に備え、デフォルト拒否の ufw policy が最後の防御線になります。

~/.memmy を信頼する前にバックアップする

memory.sqlite がストア全体です。ベクトルも sqlite-vec 拡張機能によって同じファイルに保存されるため、バックアップ対象はこの 1 ファイルだけです。サービスの書き込み中に cp でコピーすると、不完全なデータベースになる可能性があります。SQLite 自身のバックアップコマンドを使用してください。

mkdir -p ~/memmy-backup
sqlite3 ~/.memmy/memory-service/memory.sqlite ".backup '$HOME/memmy-backup/memory.sqlite'"

これにより、サービスを実行したまま整合性のあるコピーを作成できます。スケジュールを設定して別のマシンへ転送してください。オフサイトストレージへの restic がその用途に適しています。config.yaml を失っても、プロバイダー設定を再入力すれば済みます。memory.sqlite を失うと、最後に使用可能だったバックアップ以降に記録されたメモリーを失います。サービスはスキーマ移行の前にもローカルバックアップを作成しますが、これは最新のオフサイトコピーではありません。

systemd でメモリサービスを実行する

npm run memory:serve:dev をシェルで実行すると、シェルの終了時に停止します。unit ファイルを使えば、再起動後もサービスを稼働させられます。サービスは memmy ユーザーとして、そのユーザーのホームディレクトリに設定を置き、/opt/memmy のチェックアウトから実行します。シェルで実行中のコピーを停止してから、チェックアウトと設定を移動し、memmy-memory リンクの参照先を変更します。

sudo useradd -m -s /bin/bash memmy
sudo mkdir -p /opt/memmy
sudo mv ~/memmy-agent /opt/memmy/memmy-agent
sudo chown -R memmy:memmy /opt/memmy
sudo ln -sfn /opt/memmy/memmy-agent/Memory/dist/src/cli/index.js /usr/local/bin/memmy-memory
sudo install -d -o memmy -g memmy -m 700 /home/memmy/.memmy
sudo install -o memmy -g memmy -m 600 ~/.memmy/config.yaml /home/memmy/.memmy/config.yaml
sudo install -d -m 755 /etc/memmy

サービスは /home/memmy/.memmy にデータベースを保持するため、空のストアで起動します。

[Unit]
Description=Memmy memory service
After=network-online.target

[Service]
Type=simple
User=memmy
WorkingDirectory=/opt/memmy/memmy-agent
EnvironmentFile=/etc/memmy/memory.env
ExecStart=/usr/bin/npm run memory:serve:dev
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

トークンを unit に記述しないでください。/etc/memmy/memory.env に保存し、root が所有し、mode 600 に設定します。

MEMMY_CONFIG=/home/memmy/.memmy/config.yaml
MEMMY_MEMORY_TOKEN=replace-this-with-a-long-random-string

sudo systemctl daemon-reload
sudo systemctl enable --now memmy-memory
systemctl status memmy-memory --no-pager
curl -sS http://127.0.0.1:18960/api/v1/health

ステータス出力の status=203/EXEC は、systemd が ExecStart 自体を実行できなかったことを示します。そのため、which npm を確認してください。NodeSource でインストールした場合は /usr/bin/npm にあり、nvm の場合はユーザーのホームディレクトリ配下にあります。systemd は後者を見つけられません。起動直後に終了する unit では、終了ステータスと journal を確認する必要があります。code 0 は正常終了です。それ以外には、ゼロ以外の終了、シグナル、タイムアウトがあります。サービスの出力を確認するには journalctl -u memmy-memory -n 50 を実行します。基本的な仕組みは、VPS 上の他の systemd サービス と同じです。

このプロジェクトでは、ユーザーレベルで実行する方法も 2 つ提供されています。ソースからビルドする場合の README の方法は memmy-memory install --service-only です。固定された Memory runtime をダウンロードし、ユーザーサービスを登録します。Linux installer は memmy-memory.service を systemd --user unit として設定します。どちらも linger を有効にしないため、ログアウト後もそのユーザーの service manager を実行し、ブート時に起動するには sudo loginctl enable-linger <user> を実行してください。

Memmy がまだ行わないこと

• Linux デスクトップ版はありません。パッケージ作成スクリプトは macOS と Windows を対象としているため、workbench とオンボーディングウィザードはサーバー上では利用できません。memory service には http://127.0.0.1:18960/viewer/ のブラウザービューアーが追加されており、上記の SSH トンネル経由でアクセスできます。Linux では、代わりに CLI の tarball と install.sh が提供されます。
• memory:serve:dev は、開発用の経路である tsx を通じて TypeScript のエントリーポイントを実行します。リポジトリには、コンパイル済み出力用の memory:serve も含まれています。引数なしで npm run を実行すると、使用中の checkout に実際に存在するスクリプトを確認できます。
• Retrieval は、最新の 2,000 件の vector 行から検索範囲を作成し、その範囲内で Top-K 選択を行います。非常に大きなストアでは、古い memory が検索範囲の外に存在することがあります。
• Embedding は capture の後に実行されます。失敗した場合は agent のターンを停止せず、retry queue に送られます。直前に追加した memory は、vector search でまだ見つからないことがあります。
• 独自のローカル SQLite database を持つ別のサーバーには、別の memory があります。

2026 年 11 月 1 日時点の Version 1.2.401 は、急速に変化する初期段階のプロジェクトであることを示しています。リリースによって flags、paths、script names が変わることがあります。どこかからコピーしたコマンドをそのまま信用せず、ここにあるものも含めて、使用中の checkout の bin フィールドと npm run の出力を確認してください。

FAQ

ヘルスチェックで connection refused が返るのはなぜですか？

Failed to connect to 127.0.0.1 port 18960 を指定した curl の終了コード 7 は、接続に失敗したことを示すだけです。Memmy が停止している、クラッシュした、別の場所で待ち受けている、アクセスできない、といった原因までは示しません。アドレスとポートを確認し、ss -lntp | grep 18960 を実行してください。サービスを起動した端末または journal も確認します。ログにネイティブ SQLite モジュールの不一致が出ている場合は、npm rebuild better-sqlite3 を実行してください。Node のバージョンも確認します。ソースドキュメントでは Node 22 以降が必要です。一方、Linux installer が受け付けるのは、22.x では Node.js 22.23.4 以降、24.x では 24.22.1 以降、26.x では 26.12.1 以降だけです。

ソースからビルドした後、memmy-memory コマンドはどこから来ますか？

リポジトリ名ではなく、@memmy/memory workspace package の bin フィールドから来ます。checkout 内で node -p "JSON.stringify(require('./Memory/package.json').bin)" を実行すると、{"memmy-memory":"./dist/src/cli/index.js"} が表示されます。このファイルは npm run memory:build の後にだけ存在します。ビルドによって dist が作成され、ファイルに実行権限が付与されるためです。node Memory/dist/src/cli/index.js health として実行するか、/usr/local/bin にシンボリックリンクを作成して短い名前で実行します。

claude mcp add で Memmy を Claude Code に追加できますか？

いいえ。Memmy は MCP クライアントであり、MCP サーバーではありません。~/.memmy/config.yaml の tools.mcpServers に登録されたサーバーへ接続し、そのツールを自身のランタイムに提供します。Claude Code から Memmy に接続する場合は、逆に memmy-memory CLI を shell コマンドとして実行します。memmy-memory init --agent claude は、実行するタイミングを指定する Skill と CLAUDE.md ブロックを書き込みます。Linux installer の launcher も Claude Code hooks を追加し、turn を自動的に保存します。

Memmy を実行すると、メモリがクラウドサービスに送信されますか？

スキャンと取り込みはローカルで実行され、メモリは自分のディスク上の ~/.memmy/memory-service/memory.sqlite に書き込まれます。.env.example で https://api.memmy.cn に設定された MEMMY_CLOUD_SERVICE は、アカウントモードと試用トークンを提供します。また、設定されている間はメモリ本文を含めずに利用状況の分析データを受信します。API key だけを使用する場合は、この設定を空にしてください。メモリ改善プログラムには、別のプライバシー切り替え設定があります。ホスト型の embedding model には、ベクトルに変換するメモリ本文が送信されます。この処理もローカルに保つには、組み込みのローカル provider か、自分で運用する endpoint を使用してください。ホスト型の summary、evolution、relevance-filter model にも、これらのジョブの実行時にメモリの内容が送信されます。