パーソナライゼーションは、Agent が「会話相手は誰か」を安定して把握するためのレイヤーです。経験レベル、リスク許容度、好みの資産、過去の取引サマリー、応答スタイルを定義するペルソナ指示が含まれます。

2 つのサブレイヤーで構成されます。

• ワークスペースファイル（手動編集の Markdown）: Agent のペルソナ、起動時の指示、ユーザープロフィール、厳選された長期メモリ。エディタで管理します。
• 金融プロフィールとユーザータグ（自動再構築される DB テーブル）: スケジュールされた LLM パスがチャット履歴と取引履歴を読み取り、構造化フィールドを管理します。取引サマリー、11 次元のタグ、パーソナライゼーションクラスのメモリが含まれます。

両方がプロンプトビルダーに入力されます。ファイルレイヤーは安定していて明示的、DB レイヤーは実際の行動を反映して継続的に更新されます。

なぜ 1 つにまとめないのか？ ファイルレイヤーだけにすると、ユーザーが自分自身に関するメモを手動で最新に保つ必要がありますが、ほとんどの人はそうしません。推論レイヤーだけにすると、LLM の「このユーザーは誰か」という認識が取引のたびにずれていき、意図的な設定を上書きしてしまいます。2 つに分けることで、ユーザーが書いた意図（ペルソナ、明示的な設定）を上位に置きつつ、推論されたプロフィールは Agent が参照する証拠として扱い、上書きはしません。履歴書と取引実績が別々のファイルに存在するのと同じ理由です。作成者も更新サイクルも異なります。

実際の動作を確認する: 機能 → メモリ では、両レイヤーに入力される「Minara に自分のことを教える」フローを説明しています。

ロールごとの意思決定リフレクション（まったく異なる種類のメモリ）については、ロールメモリ を参照してください。

ワークスペースファイル（ペルソナレイヤー）

Minara はセッション開始時に少数の Markdown ファイルを読み込み、アイデンティティ、ユーザープロフィール、厳選された長期メモリをカスタマイズします。このディレクトリは OpenClaw のレイアウトと互換性があるため、--workspace で既存の OpenClaw ワークスペースを Minara に向けることができます。

レイアウト

デフォルトの場所: ~/.minara/workspace/。

workspace/
├── SOUL.md        — agent identity / persona
├── AGENTS.md      — session startup instructions
├── IDENTITY.md    — agent self-description (name, vibe, emoji)
├── USER.md        — profile of the user being helped
├── MEMORY.md      — curated long-term memory
├── TOOLS.md       — tool reference (informational)
├── BOOTSTRAP.md   — first-run only, deleted after initial read
├── HEARTBEAT.md   — session state file
└── memory/
    └── YYYY-MM-DD.md  — daily memory notes (3-day window)

minara setup がディレクトリを作成し、適切なデフォルト値を設定します。任意のエディタで編集できます。ワークスペースは起動時に一度だけ読み込まれてセッション中は固定されるため、変更は次のセッションから反映されます。

ファイル一覧

各ファイルのプロンプトへの反映方法

SOUL.md     ──┐
              ├─▶ systemPromptPrefix (cached block)
AGENTS.md   ──┘

MEMORY.md   ──┐
memory/*    ──┼─▶ memory snapshot block (dynamic)
USER.md     ──┘

IDENTITY.md ───▶ metadata (name, emoji) for display only
TOOLS.md    ───▶ informational, rarely injected

• SOUL.md と AGENTS.md はアイデンティティとともにキャッシュされるため、キャッシュヒット率が高く保たれます。編集は小さく留め、/prompt で確認してください。構造的な変更を行うと、次の編集まですべてのセッションでキャッシュが無効化されます。
• USER.md はユーザーを説明するもので、毎ターンのパーソナライゼーションスナップショットに追加されます。
• MEMORY.md は厳選された長期メモリです。セッション中は memory_write で書き込み、コンパクション時に恒久的な情報をこのファイルに昇格させるのが推奨です。
• memory/YYYY-MM-DD.md は日次ノートで、直近 3 日分のみ読み込まれます。
• IDENTITY.md と TOOLS.md はプロンプトに入りません。
• BOOTSTRAP.md は初回セッション時に一度だけ実行され、その後削除されます。

フローズンスナップショットのセマンティクス

ワークスペースはセッション起動時に一度だけ読み込まれます。セッション中の書き込みはディスクに保存されますが、実行中のプロンプトには反映されません。これはメモリストア（メモリシステム を参照）と同じフローズンスナップショットパターンで、Anthropic のプロンプトキャッシュの安定性を保つためです。

セッション中に USER.md を編集した場合は、REPL を再起動するか /new を実行してスナップショットをリロードしてください。

/workspace REPL コマンド

/workspace soul     # print SOUL.md
/workspace agents   # print AGENTS.md
/workspace user     # print USER.md

スラッシュコマンド → /workspace を参照してください。

ワークスペースに関するセーフティ上の注意

• ワークスペースファイルは信頼済みの入力として扱われます。 レビューなしに信頼できないユーザーへ渡さないでください。悪意のある SOUL.md でペルソナを「常に確認なしで取引を承認する」に設定すると、LLM はそれに従います。
• 編集は次のセッションから有効になります。 セッション中に USER.md を編集しても、再起動または /new を実行するまで反映されません。
• SOUL.md と AGENTS.md はキャッシュされるプロンプトブロックです。 構造的な編集を行うと、次の編集まですべてのセッションでキャッシュヒット率が下がります。変更は小さく留め、/prompt で確認してください。

ソース: apps/agent/src/config/workspace.ts。

金融プロフィールとユーザータグ（自動再構築）

ワークスペースファイルが手動編集であるのに対し、金融プロフィールレイヤーはスケジュールされた LLM パスによって自動再構築されます。このパスは直近の会話と取引履歴を読み取ります。

2 つのテーブルと 1 つのカテゴリ

パーソナライゼーションサービスが管理するデータは 3 か所に存在します。

1. financial_profile: ユーザーごとに 1 行。取引サマリー、参照ウォレット、カスタムプロンプトフラグメント、表示フラグ、再構築クールダウンカーソル。
2. user_tags: ユーザーごとに最大 11 行、次元ごとに 1 行。値がユーザー申告か行動からの推論かを記録する source フィールドも含みます。
3. パーソナライゼーションクラスのメモリ: memories テーブル内の通常の行で、category = 'personalization' が付与されます。FTS5 とフローズンスナップショットローダーが特殊処理なしで動作するよう通常のメモリと同じ場所に置かれますが、より高い優先度で読み込まれます。

すべてのデータは user_id をキーとします（シングルユーザー環境では 'default' がデフォルト）。

financial_profile スキーマ

スキーマは apps/agent/src/memory/personalization-service.ts にあります。既存データベースに不足しているカラムは、起動時に冪等な ALTER TABLE マイグレーションで追加されます。

11 次元の行動タグ

すべてのユーザーに対し、取引履歴と会話から推論された金融特性タグのベクトルが生成されます。各次元には機械可読な value（スラグ、または段階評価の level_N）が格納されます。以下の人間が読めるラベルは UI とプロンプトで表示されるものです。7 つの次元は v2 / ユーザーポートレートセットで、4 つのパーソナリティ次元は v1 から変更なし（value と label が一致）です。

markets は複数選択で、単一の user_tags.value カラムに JSON 配列文字列として格納されます。他のすべての次元は 1 つの値を保持します。スキーマは apps/agent/src/memory/tags-schema.ts にあります。呼び出し元はスキーママップを直接読み取るのではなく、型付きヘルパー（allowedValues、isValidTagValue、serializeTagValue、parseStoredTagValue、renderTagSchema）を経由します。許容値以外の書き込みは PersonalizationService.upsertTag によって暗黙の変換なしに拒否されます。

オンボーディングと会話推論に加えて、markets には客観的なソースがあります。24 時間ごとの cron（MarketsObjectiveUpdater、apps/agent/src/memory/markets-updater.ts）が、ユーザーの現在の autopilot 戦略のシンボルと、過去 30 日間に記録された perps 約定をスキャンし、各シンボルを市場に分類して、PersonalizationService.unionMarkets を通じて結果を和集合としてタグに push します。追加のみで削除は行わず、行の既存の source を保持するため、推論による push がユーザー宣言の選択をダウングレードしたりクリアしたりすることはありません。オフエージェントの perps 活動は、クールダウンで制限されたより早い実行を促します。

既存の v1 行は、一回限りのスクリプト pnpm --filter @minara/agent migrate:user-tags-v2 でこのスキーマに移行します（デフォルトはドライラン、書き込む場合は --apply）。移行では Risk Profile → risk、Web3 Knowledge Level → web3_knowledge_level、Decision-Making Style → style、Asset Preference → markets にリマップし、廃止された Asset Tier / Trading Frequency / Learning Preference 次元を削除します。4 つのパーソナリティ次元はそのまま保持されます。

キャピタルメトリクス（客観的、Agent 内部）

ユーザーのコミットキャピタルは客観的な指標であり、自己申告ではなく設定画面にも表示されません。v1 の自己申告制 Asset Tier タグに代わるものです。専用の capital_metrics テーブル（ユーザーごとに 1 行）に格納され、Agent の推論にのみ利用されます。ユーザー向けパーソナライゼーションスナップショットには含まれません。

capital_total_usd = spot_holdings_usd + perp_value_usd

spot_holdings_usd はクロスチェーンのポートフォリオ資産価値の合計、perp_value_usd は永続先物サブアカウントのエクイティ合計です。合計値は 8 段階のティア（tier_1 が $10 未満、tier_8 が $50k 以上）に分類されます。再計算は 24 時間の cron とオフ Agent アクティビティのきっかけで実行されます。クールダウンで制御され、読み取りソースが利用できない場合は誤ったゼロを書き込まずに直前の値を保持します。スキーマとティアは apps/agent/src/memory/capital-metrics.ts にあります。

ストラテジー実行履歴（Autopilot 履歴）

strategy_runs は Autopilot のアクティベーション履歴の追記専用テーブルです。有効化から無効化までの 1 サイクルごとに 1 行が記録されます。割り当てキャピタル、開始・終了時刻、ステータス、stop_reason（user_manual / insufficient_balance / drawdown_protection / liquidated / strategy_expired / other）、および停止時に遡って記入される実現損益が含まれます。キャピタルと同様に Agent 内部のデータであり、ユーザー向けスナップショットには含まれません。

完全管理型ストラテジーを有効化するとランが開始され、Agent を通じて無効化すると user_manual としてランが終了します。Web UI からの無効化や、ドローダウン・清算による自動停止など Agent が関与しない停止は、調整パスで補足されます。Agent がストラテジー一覧を取得する際、実行中セットにもはや存在するオープンランは other として終了されます。なお、有効化直後のランが実行中として表示される前に終了されないよう、短いグレースウィンドウが設けられています。ストアは apps/agent/src/memory/strategy-runs.ts にあります。

手動取引プロフィール

TradingProfileReader は、ユーザーのオフ Agent 永続先物アクティビティ（perps_fills ミラー、つまり Web・モバイル・手動での取引）を 30 日間の集計でコンパクトな情報としてまとめます。内容は取引件数、件数・取引量別のトップシンボル、ロング/ショートの割合、実現損益、決済取引のウィン率、平均取引サイズ、最終取引時刻です。また search_user_trades Agent ツールも支えており、1 つの資産について最近の約定（売買方向、建玉開閉方向、USD 規模、価格、実現損益）を返します。いずれも Agent 内部のデータで、ユーザーの実際の履歴に基づいた分析を提供します。ミラーはレバレッジや手動・Autopilot の区別を持たないため、それらはここでは対象外です。ソース: apps/agent/src/memory/trading-profile.ts。

オンデマンドパーソナライゼーション呼び出し

キャッシュを壊さずにパーソナライゼーションを意図に応じて活用する方法は、常にすべてをキャッシュ済みプレフィックスに注入するのではなく、モデルが必要なものを引き出せるようにすることです。search_conversation_memory（conversation-memory-tool.ts）は、ユーザーの恒久的なパーソナライゼーションメモリ（好み、プロフィール情報、制約、目標）を personalization カテゴリに絞ってオンデマンドで取得します。FactLayer のハイブリッド検索を再利用します。ツール結果はキャッシュ済みプレフィックスの後に追加されるため、呼び出しがプロンプトキャッシュを乱すことはありません。personalization_snapshot（オンデマンドのフルポートレート）や memory_search（全カテゴリ）と組み合わせて使います。

オンボーディング

ユーザーレベルのオンボーディングフローが、明示的な回答からポートレートの初期値を設定します。POST /v1/profile/onboarding は回答をユーザー申告タグ（finance_knowledge、frequency、risk、markets）にマッピングし、回答された次元ごとにパーソナライゼーションメモリを 1 件書き込みます（初回完了時のみ。再送信はタグを更新しますがメモリは重複しません）。また、自己申告の投資キャピタルをメモリとして記録します。タグやキャピタルメトリクスとしては記録されません（キャピタルは客観的なデータのため）。生の回答と完了フラグは financial_profile 行に保持され、GET /v1/profile/onboarding でステータスを取得できるため、Web UI がフローを表示するかを判断できます。この呼び出しは冪等で、書き込み前に無効なタグ値を拒否します。実装は PersonalizationService の completeOnboarding / getOnboardingStatus にあります。

user_tags の各行にも source フィールドがあり、値がユーザー申告か LLM 推論かを記録します。プロンプトビルダーはこれを利用して表示するタグに重みを付けます。申告値と推論値が両方存在する場合、申告値が優先されます。

3 つの再構築フロー

パーソナライゼーションは apps/agent/src/memory/personalization-rebuilder.ts によって定期的に再構築されます。ハートビートモニターが、それぞれ独立したクールダウンウィンドウを持つ 3 つのメソッドをスケジュールします。これにより、1 つの遅い再構築が他をブロックすることがありません。

各再構築は 1 回の安価な LLM 呼び出しです（デフォルトは Haiku）。クールダウンは v1 と同等になるよう調整されています。取引サマリーは頻繁に更新（新しい取引が重要）、タグはほとんど更新しない（ゆっくりと変化するプロフィールデータ）、メモリ抽出は頻繁に更新（ユーザーが表明した新しい好みを素早く捕捉）します。

last_indexed_chat_id カーソルにより、rebuildMemories は未読のチャットのみを処理します。このカーソルがなければ、毎回フルのチャット履歴を再読み込みして token 予算を消費してしまいます。

3 ソース取引サマリーの詳細

rebuildTradingSummary() は 3 つの独立したソースを読み取り、合算した閾値でゲートを設け、3 つの独立したカーソルを前進させます。これにより、1 回の再構築での解析失敗が他のソースのデータをサイレントに失わせることがありません。

                ┌──────────────────────────────────────────┐
trade event ────►│ trade_history (in-session)               │──┐
                └──────────────────────────────────────────┘  │
                                                              │
                ┌──────────────────────────────────────────┐  │
Minara web/    ►│ perps_fills (cross-sub mirror)            │──┤
mobile perps    └──────────────────────────────────────────┘  │
   (via                                                        ▼
    MinaraHistorySync.syncAll)                ┌─────────────────────────┐
                ┌──────────────────────────────────────────┐ │ rebuildTradingSummary │
Minara web/    ►│ external_spot_activities (mirror)         │►┤ gates: newTrades +      │
mobile spot     └──────────────────────────────────────────┘ │  newPerpsFills +        │
                                                              │  newExternalSpot ≥      │
                                                              │  threshold               │
                                                              │                          │
                                                              │ LLM emits 4 fields →    │
                                                              │   platformWalletSummary │
                                                              │   spotBreakdown          │
                                                              │   perpsBreakdown         │
                                                              │   referenceWalletsSummary│
                                                              │ → composed into one      │
                                                              │   platform_wallet_summary│
                                                              │   string with Spot: /    │
                                                              │   Perps: prefixes        │
                                                              └─────────────────────────┘

3 つの独立したカーソルが financial_profile 行に存在します。

• trading_summary_last_trade_id_seen（既存）
• trading_summary_last_perps_fill_id_seen（新規）
• trading_summary_last_external_spot_id_seen（新規）

3 つすべてのカーソルが前進するのは、LLM が解析可能なレスポンスを返し、新しいサマリーが書き込まれた後に限られます。解析が失敗した場合はすべてのカーソルが現在位置に留まり、次の再構築で同じウィンドウを再試行します。ソースがサイレントに失われることはありません。

MinaraHistorySync のトリガー

オフ Agent ミラーテーブルは MinaraHistorySync（apps/agent/src/memory/minara-history-sync.ts）によって埋められます。同期はファイア＆フォーゲット方式で、自己スロットルされており、失敗時は常に 0 行の追加に留まります。トリガーのパスは 3 つあります。

1. 取引イベントへのピギーバック: eventBus.on("trade:recorded", () => minaraHistorySync.scheduleSync())。Agent 自身が取引を記録すると、ユーザーが Web やモバイルでも活動している可能性が高いため、ミラーを最新に保つ安価な方法です。5 分のスロットル（historySyncMinIntervalMs）でバーストをまとめます。
2. セーフティネットのティック: 30 分ごとにアプリのティッカーが minaraHistorySync.runIfStale() を呼び出し、イベントの取りこぼしによってミラーが永続的に止まることを防ぎます。
3. 強制リフレッシュ: CLI の /profile refresh（または HTTP の POST /v1/profile/refresh）はスロットルを迂回して runOnce() を再構築前に実行し、次のサマリーが最新のオフ Agent アクティビティを確実に反映します。

historySyncMaxFailures（デフォルト 5）回の連続失敗が 1 つの (source, sub_account_id) 行で発生すると、通常のスケジューリング中はそのキーをスキップします。last_synced_at から historySyncFailureCooldownMs（デフォルト 30 分）が経過すると、プローブが実行されます。プローブが成功すると consecutive_failures が 0 にリセットされます。これにより、一時的な障害でミラーが永続的に無効化されることを防ぎます。

memory.trading-cases との境界

memory.trading-cases（methodology_cases SQLite テーブル）は、パーソナライゼーション情報と並存しながら重複しない別のメモリです。2 つの記録は対象とする消費者が異なり、混在させると互いに破損するためこの分離が存在します。

• memory.trading-cases は Agent の学習ループです。各行はセッション内で Agent が行った 1 つの意思決定であり、1 つ以上のメソドロジー ID に紐づき、後にスコアリングされる Wilson 基準の結果を持ちます。消費者はメソドロジーシステムで、メソドロジーを引き続き提案すべきかを判断するために使用します。
• パーソナライゼーション情報（このページ）は、「このユーザーはどのような人物か」を Agent が把握するためのものです。セッション内取引、オフ Agent 永続先物、オフ Agent 現物を読み取り、システムプロンプトに常に含まれる段落としてまとめられます。

MinaraHistorySync からの外部約定は意図的に methodology_cases に書き込まれません。それらはメソドロジー ID やヒントハッシュを持たないため、遡って帰属させると、メソドロジー昇格を制御する Wilson 統計を汚染してしまいます。同様に、Web UI の trading-cases ページは読み取り専用の監査ダッシュボードです。編集すると学習コーパスが破損します。

通常の memory_write との関係

パーソナライゼーション再構築は監査ログフックを経由しません。これは意図的な設計です。

• 再構築はスケジュールで実行されます。毎回の実行で何十もの監査エントリが生成され、出力は派生データであってユーザーアクションではありません。監査ログが再構築のノイズで埋まってしまいます。
• ユーザーが起動した memory_write は引き続き通常のツールディスパッチパスを経由し、完全な推論とともに audit に記録されます。ユーザーがリクエストしたアクションであるため、監査可能であるべきです。

パーソナライゼーション再構築がいつ最後に実行されたかを確認するには、行の trading_summary_updated_at または tags_next_update を直接クエリしてください。個々のパーソナライゼーションメモリの書き込みについては、memories テーブルを category = 'personalization' でフィルタリングし、created_at で絞り込むことができます。

設定

クールダウン間隔、LLM モデル、起動時再構築の動作は apps/agent/src/memory/financial-profile-config.ts で設定します。デフォルトは v1 をそのまま引き継いだものです。

• tradingSummaryCooldownMs: 30 分
• tagsCooldownMs: 30 日
• memoriesCooldownMs: 10 分
• rebuildOnBoot: false

LLM クライアントが提供されない場合（テスト用）、再構築は何もしません。本番環境でサービス全体を無効化する場合は MINARA_PERSONALIZATION_REBUILD=disabled を設定してください。ただし、これを設定すると恒久的なメモリが personalization カテゴリに昇格されなくなります。

/profile REPL コマンド

REPL 内から現在のパーソナライゼーションスナップショットを確認するには:

/profile

金融プロフィール行、アクティブなユーザータグ、直近のパーソナライゼーションメモリ、カスタムプロンプトフラグメント（設定している場合）が表示されます。「なぜ Agent がこのような動作をしているのか」をデバッグする最速の方法です。プロフィールに risk: conservative とあるのに Agent が 10 倍レバレッジを提案する場合は、上流で何かが壊れています。

プロフィールフィールドの編集

フィールドの直接編集は設定 CLI で行います。

minara config get financial.custom_prompt
minara config set financial.custom_prompt "Always prefer stablecoin pairs."

タグの編集はパーソナライゼーションサービスを通じて行います。最も簡単な方法は、会話から Agent に推論させることです。CI のシード用として内部ヘルパーで直接の手動アップサートもサポートされていますが、CLI コマンドとしては公開されていません。

セーフティ上の注意

• パーソナライゼーション再構築は LLM 主導です。 Haiku 呼び出しは安価ですが無料ではありません。本番環境では MINARA_DAILY_CAP_USD を設定してください。再構築ループの設定ミスにより、気づかないうちに予算を消費する可能性があります。
• custom_prompt は SOUL.md と同様に信頼済みの入力として扱われます。 編集できるユーザーは Agent の動作を変更できます。マルチテナント環境では、書き込みを独自の認証レイヤーで保護してください。
• タグ推論はグランドトゥルースではありません。 タグベクトルはチャットと取引のサンプルからのベストエフォートの推論です。Agent は申告値を推論値より強く扱いますが、どちらもセッション中の明示的なユーザー指示を上書きするために使用すべきではありません。
• 部分的な再構築は古い状態を残す可能性があります。 再構築の途中で LLM 呼び出しがタイムアウトした場合でも、クールダウンは進みます。次の再構築は通常通り実行されますが、その間は短い古いウィンドウが生じます。クールダウンは適切に調整してください。