Palace · Imported Insights · 意思決定表 · 7 歩 Runbook · グラフィカル検証
OpenClaw を安定運用できている中上級の方にとって、v2026.4.x 系のメモリサブシステムは、より検証しやすい振る舞いを強調します。Memory Palace は召回の経路を可視化し、Imported Insights は外部コーパスを検索可能な洞察へ取り込みます。運用コストは「モデルの当て推量」から、データ統制・インデックス体積・Gateway の可観測性へ移ります。本稿ではSOUL／MEMORY ファイル層との役割分担、膨張に類する症状の意思決定表、doctor から Runbook 公開までの 7 ステップ、チケットに貼れる四つの結論、およびSSH 単体では代替しにくいグラフィカルセッションでの突合せ表を示します。SOUL／MEMORY／IDENTITY の実践、無応答の切り分け、v2026.4.5 のアップグレードと doctor チェックリストと相互に参照できるようリンクしています。
境界を先に描かないと、Palace でブロックを編集し、MEMORY.md から段落を消し、CSV で同一事実を再取り込みする、といった三本の真実が衝突し、Gateway ログが十分でも挙動の左右ブレを説明しにくくなります。以下の五項目はリリース前のゲートとして扱うことをおすすめします。SecretRef の監査と同じレビューパッケージで開くと効果的です。
Memory Palace：「今回なぜこれらのチャンクが召回されたか」「現在の会話テーマと矛盾しないか」を示します。ランタイム上の鏡であり、MEMORY.md における長期事実の代替ではありません。両者は突き合わせ可能・差分可能であることが望ましいです。削除済みの内容が Palace に残る場合は、インデックス未再構築・ワークスペースパスの重複・旧ツリー残存を疑ってください。
Imported Insights：ChatGPT のエクスポートやチケット抜粋など、外部コーパスを検索可能な洞察へ変換します。リスクは体積・重複除去・機微フィールドにあります。未マスキングのまま取り込むと、顧客名やトークン断片が既定の検索コンテキストへ入り込み、プロンプトだけでは覆い隠しきれません。
SOUL／MEMORY ファイル：人格と長期事実については、引き続きディスク上の正本です。Palace とファイルが長期にわたり食い違う場合、まずモデルを責めず、「意図的なグレー運用」か「パス／インデックスの誤り」かを切り分けてください。
SecretRef と監査：秘密情報は openclaw secrets plan／apply／audit のリズムに従います。Palace に鍵らしき断片が見えたら、ブロック削除より先にローテーションし、監査をパスするための画面テキスト編集に逃げないでください。
コンプライアンスと保持：「検証可能」はしばしば「説明責任可能」を意味します。社内 Wiki に、誰がどのワークスペースへ何を何日保持できるかを明記してください。レンタルノードでは、暗号化ストレージに入れる前に Downloads に唯一の原本だけを置かない運用を徹底してください。
当サイトの「SOUL／MEMORY／IDENTITY 実践」はディスク上の読み込み順と編集規律が主題です。本稿はランタイムのサブシステムがファイルとどう整合するか、取り込み後にコストをどう抑えるかが主題です。両方を読むと、「ファイルを書く」と「Palace を見る」を同一の変更依頼に載せやすくなります。
次の表は、社内で転送しやすい言い回しで現象 → 優先して疑う層 → 次に見る層 → 典型的な誤診を示しています。いきなり最大モデルへ切り替えたり、人格プロンプトだけを書き換えたりする前に参照してください。表の列構成は他言語版へそのまま流用できます。
| 現象 | 優先して疑う | 次に見る | 典型的な誤診 |
|---|---|---|---|
| 初トークン遅延・全体遅延 | 検索候補過多、チャンク過大、再ランキング負荷 | Gateway 上流のタイムアウト、キュー、地域ネットワーク | 直ちに最強モデルへ |
| 事実が古い／ファイルと不一致 | MEMORY と Palace インデックスの非同期 | 複数ワークスペースパスの混在、旧インデックスディレクトリ | システムプロンプトのみ書き換え |
| 同一スレッド内の矛盾 | 召回ブロックの衝突、Imported Insights と SOUL の境界衝突 | ツールが更新した外部データ | 「モデルが不十分」への単純帰結 |
| コンソールに memory 系エラー | アップグレード後の doctor 未実施、設定移行の不完全さ | ディスク満杯による索引書き込み失敗 | ログを読まず再起動の繰り返し |
運用上は対照サンプルを固定することをおすすめします。業務に近い長さと主題のプロンプトを二つ選び、取り込み前・試験取り込み後・全量取り込み後にそれぞれ実行し、初回チャンクまでの時間・合計時間・召回件数または候補規模を記録してください。召回件数が取り込み量にほぼ比例して増え初回チャンクがほぼ変わらない場合、ボトルネックは多くの場合検索と再ランキングです。初回と合計がともに不安定なら、上流モデルとネットワークを同一チケットにまとめ、問題の二重化を避けてください。
まず体積と命中を測り、それからモデルを換える。MEMORY と Palace を揃えてから人格を書き換える。
順序を守って実行することをおすすめします。前半は環境の指紋を固定し、中盤で取り込みと検索の体積を抑え、終盤で秘密情報と手順を文書化します。第 1 歩の前後でチャネルが沈黙したり、Heartbeat が異常だったり、インバウンドが途切える場合は、無応答の切り分けを並行して開き、ゲートウェイ問題を記憶膨張と取り違えないでください。
バージョンと設定ルート：openclaw --version と openclaw doctor を実行し、設定ルートとワークスペースを記録します。doctor 出力のうち memory／index／workspace に関する行は、チケットにそのまま貼り、アップグレードやロールバック時の対照にしてください。
取り込みテンプレートとマスキング：許可フィールド／禁止フィールドの一覧を固定します。巨大ログは主題ごとに分割し、エクスポート類にはハッシュや段落フィンガープリントで重複除去し、同一洞察が何度も格納されないようにします。
小ロット試験取り込み：目標量のおおよそ 5〜10% だけ先に取り込み、Palace の件数・ディスク・Gateway の所要時間を観察します。バッチ ID と時間窓を記録し、ロールバックや基線対照に使います。
召回の安定性：固定したプローブ用プロンプトを二つ、それぞれ二回ずつ実行し、Palace の命中が揺らぐか確認します。揺らぐ場合はインデックスパス、再構築完了の有無、他者ワークスペースとの交差を疑ってください。
Gateway の可観測性：取り込み前の三段階（取り込み前・試験取り込み後・全量取り込み後）のログで、初回チャンクまでの時間・総トークン・候補規模を比較します。遅延が候補数に線形で追従する場合は、まずマシン追加ではなく取り込みの絞り込みや top‑k の見直しを検討してください。
秘密情報の監査：openclaw secrets audit を SecretRef 台帳と突き合わせます。監査の差分は口頭ではなく変更記録に残してください。
Runbook と保持：承認者、保持期間、暗号化エクスポート、インデックス再構築の権限とロールバック手順を明記します。法務と「誰が Palace を閲覧でき、ログをどれだけ保持するか」を揃えてください。
{
"baseline_probe": { "prompt_id": "A", "runs": 2 },
"metrics": ["ttfb_ms", "total_ms", "recall_hits", "total_tokens"],
"compare_at": ["before_import", "trial_import", "full_import"]
}
補足：キー名は例示です。重要なのは同一プローブ・同一チャネル・三つの時点が再現可能であることであり、レビューで「どの段階から遅くなったか」に答えられることです。
プラットフォームのサポートや社内 SRE と責任境界を揃えるため、貼り付けやすい文体にしています。数値レンジは、御社環境のヒストグラムに置き換えてください。
注意：根因に「モデルが弱い」と書く前に、前述の三段階の基線表を添付してください。レビューで差し戻されます。
SSH とグラフィカルセッションは、キーチェーン、ブラウザ証明書、画面収録、操作補助（アクセシビリティ）などの文脈で完全には等価ではありません。Palace、ブラウザの Network、システムのプライバシーは、Gateway と同一の対話ユーザーのデスクトップで確認するのが確実です。三列表は多言語テンプレート向けに、見出しと説明だけ差し替えられる形にしています。
| 突合せ項目 | 操作の要点 | 合格基準 |
|---|---|---|
| Gateway とネットワーク | ローカルブラウザでコンソールを開き、Network で memory／recall をフィルタします。 | 401／429 の嵐がなく、失敗がパスや認証に対応付けられること。 |
| プライバシーと権限 | システム設定の「プライバシーとセキュリティ」で、収録・操作補助などを確認します。 | パスとバイナリが一致し、変更後に関連プロセスを再起動済みであること。 |
| タイムゾーンと言語 | メニューバー時刻、Palace の表示言語、ログのタイムゾーンを揃えます。 | チケットの時刻とログが一致し、跨地域の場合は UTC 表記があること。 |
| メモリとディスク | アクティビティモニタでメモリ圧力を、空き容量を確認します。 | 大規模取り込み時に異常なスワップの尖りがなく、ディスクが安全閾値を上回ること。 |
| 多利用者の分離 | 作業ディレクトリと索引パスが他者と交差していないか確認します。 | Palace に他人の名前空間が混ざらず、再インデックスに承認があること。 |
レンタルノードを複数名で共有する場合、「誰がインデックス再構築を起動できるか」を Runbook に書いておくと、事後に Palace で「誰が取り込んだか」を推測するよりコストが低くなります。
いずれも公開ブログです。第 3 節・第 4 節とあわせて読むと、変更フローに「見える記憶」を載せやすくなります。他言語サイトへ移植するときは、区切りラベル・見出し・カードグリッドを保ち、URL と要約だけ差し替えてください。
ディスク上の役割、読み込み順、リモート Mac での編集チェックリスト。
読む →plan／apply／audit と、Palace に鍵らしき断片が出たときの扱い。
読む →記憶以外の失敗を先に分流し、本稿の表へ戻る。
読む →多くの場合、検索候補の増加・チャンク過大・インデックス未収束が先です。Gateway ログの初回チャンクまでの時間と召回件数を確認してからモデル交換を検討してください。本稿第 2 節の表と、第 3 節の第 5 歩の基線と併用するとよいです。
ワークスペースパスが一意か、インデックスを再構築したか、設定の複製がないかを優先して確認してください。Palace はランタイム上のビューであり、ディスク上の正本と突き合わせ可能であることが望ましいです。第 1 節とファイル実践の記事を参照してください。
一時的な緩和にはなりますが、根本原因が取り込みと秘密管理にある場合、次回のインデックス再構築で再露出し得ます。マスキングと SecretRef の手順に戻ってください。
定義上は必ずしも衝突しません。Skill がより新しい事実を返す場合は、MEMORY に権威ある情報源の優先順位を明記し、Palace で召回順を確認してください。
検証可能なメモリは、コストを「プロンプトの暗記」からデータ統制と Gateway の可観測性へ移します。Palace で召回を見えるようにした一方で、取り込みバッチ・インデックス・監査の責任も伴います。SSH だけで設定を変え、Gateway と同一ユーザーでコンソールやシステムのプライバシーを開かない運用では、しばしばキーチェーン・証明書・権限ダイアログがログと噛み合わず、同一チケット内で切り分けが分岐しがちです。
常時稼働の高スペック物理 Mac を自前で用意する負荷（スリープ方針、更新窓、電気・減価償却）に加え、ローカル機のスペック不足は索引再構築や大規模取り込みでディスクとメモリを圧迫します。一方、グラフィカルセッションを突合せ可能なリモート Macは、稼働率とベースイメージをプロバイダに任せつつ、記憶ポリシーと秘密管理は利用側が握れ、平均復旧時間をより予測しやすい帯に収めやすくなります。
自有ハードへの投資を抑えつつ、本文第 5 節と同様の受入れを Gateway と Palace で行いたい場合は、VNCMac でクラウド Mac をご利用いただけます。下の主ボタンから購入ページへ進み、プランや納品情報を比較される場合はトップページをご覧のうえお申し込みください。