第 21 章 バックアップと復元：コンピュータがリセットされても慌てない

クラウドコンピュータがリセットされると環境は完全に初期化されます。記憶を頼りに apt-get や pip install を実行しても依存関係や環境変数を漏らしやすく、調整を重ねた Bot の記憶にもエクスポートボタンはありません。解決策は、ディザスタリカバリを2系統の並行パイプラインに分割することです。

1. 仮想マシンサービス：登録台帳と自動復元スクリプトでシステム依存関係を管理する。
2. エージェントの記憶：専任の記憶マネージャーが設定と動的事実を Markdown に書き出し、プライベート Git リポジトリにプッシュする。

構築完了後は、システムがリセットされたり移行したりしても、最小限の人的介入ですべてのサービスと記憶を復元できます。

21.1 クラウドコンピュータの実態を把握する：更新、Recover、Reset の違いとは

同一アカウント下のすべての Bot は同じ仮想マシンを共用しており、/workspace ディレクトリとシステムプロセスを共有しています。1台のマシンにグローバルツールをインストールすれば他の Bot も呼び出せますが、マシンがリセットされるとすべての依存環境が同時に失われます。

参考：『4.6 仮想マシン、記憶とバックアップ』。

クライアントの Settings > 计算机 にある Bot's 计算机 の下でコントロール項目が提供されています。3者の違いは以下のとおりです：

操作	仕組み	保持される内容	失われる内容
更新（Update）	環境イメージをアップグレード。ソフトウェア更新とコンピュータ更新の2種類がある	ソフトウェア更新はすべて保持。コンピュータ更新はボット、ファイル、ログイン情報を保持	ソフトウェア更新での損失なし。コンピュータ更新ではグローバルアプリケーションとパッケージが削除される
Recover	保存済みデータをもとに最新イメージで新しいマシンを作成し、まず古いマシンに接続してデータを保存しようとする	保存済みのボット、ファイル、ログイン情報	グローバルアプリケーションとパッケージ。古いマシンに接続できない場合、未同期の変更は失われる
Reset	直近に保存されたデータをもとに直接新しいマシンを作成し、実行中のタスクを中断する	保存済みのボット、ファイル、ログイン情報	グローバルアプリケーションとパッケージ。未同期の変更は失われる

対話履歴はクラウドに保存されているため、マシンのリセットやファイルの誤削除による影響はありません。しかし、グローバルにインストールされたアプリケーションパッケージ、node_modules、Python 仮想環境は公式には保存されず、コンピュータ更新、Recover、または Reset の際にすべて消去されます。

詳細は 『Grok Bot コンピュータ』 を参照してください。

仮想マシンがフリーズしたり応答が異常になったりした場合は、次の順序でトラブルシューティングを行ってください：

1. Reconnecting または Couldn't Reach Grok Bot's 计算机 と表示される：ネットワークの揺らぎによるものです。少し待ってから Retry をクリックしてください。再接続中にファイルが失われることはありません。この段階で Reset をクリックすることは厳禁です。

2. クライアントを再起動する。Mac ユーザーは必ずトップメニューバーから Quit を選択してください。単にウィンドウの赤い「×」ボタンをクリックしただけでは終了しません。

3. アップデートを確認する。Settings > 计算机 に進み、利用可能なアップデートがあれば先に 更新 をクリックします。エージェントが一時停止していない旨が表示された場合は、現在のタスクが終了するのを待ってからクリックします。

4. 復元を試みる。それでも接続できないか、更新が停止して 恢复计算机 と表示された場合は Recover をクリックします。Update 仍在运行 と表示された場合は、Keep waiting を選択します。

5. Reset を実行する。ステップ1〜4が無効な場合のみ Reset をクリックします。失敗した場合は Retry Recover または Retry Reset で再試行し、エラーが続く場合は公式サポートにお問い合わせください。

6. ディスク容量のアラートに対処する。

   Computer is low on disk space または Computer is critically low on disk space という通知を受け取っても、手動でファイルを削除しないでください。サイドバーの Go to Disk Saver をクリックして解決策を確認します。確認なしにシステムがファイルを削除することはありません。

   詳細は 『Grok Bot コンピュータ』 を参照してください。

クラウドコンピュータは使い捨てのコンテナにすぎません。手動で環境を微調整しないでください。環境構築プロセスをすべてスクリプト化し、設定と自作ソースコードは必ず外部のプライベート Git リポジトリに保存してください。

21.2 仮想マシンサービス台帳と自動復元パイプライン

『4.6 仮想マシン、記憶とバックアップ』

クラウドコンピュータでは低レイヤーのスナップショットが提供されないため、再構築プロセスをワンクリックスクリプトにするのが最も低コストです。

サービス台帳と汚染防止バックアップ

プライベートリポジトリに vm-services/ ディレクトリを作成し、人間が読むための REGISTRY.md テーブルと、自動化スクリプトが解析する registry.json を配置します。

台帳とバックアップには、遵守すべき厳格なルールがいくつかあります。

• 登録フィールドには、サービスID、担当Bot、コードパス、インストール依存関係（apt/pip/Docker/cron）、起動・停止およびヘルスチェックコマンド、復元が必須かどうかを含めます。
• 認証情報のパスにはローカルの絶対パス（~/.env など）のみを記述し、平文での保存は厳禁です。QRコード読み取りや OAuth などの手動手順は個別にハイライトします。
• 自作スクリプトは単独で service-src/ に保存し、venv/、node_modules/、ログを除外します。コミット前には必ず正規表現で秘密鍵やシークレットのスキャンを実行してください。

自動復元パイプライン

vm-services/restore/ 内に各サービス専用のサブスクリプトを作成します。スクリプトは必ず冪等性を担保してください。2回連続で実行してもディレクトリの重複やポートの競合エラーが発生しないようにします。

メインエントリである restore-all.sh は、依存関係の順序に従って順次直列実行します。

1. 基本依存関係：cron、ffmpeg、yt-dlp などのシステムツールをインストールします。
2. ソースコードの配置：service-src/ から自作スクリプトをコピーし、既存のファイルはスキップして不足分のみを補完します。
3. 環境とパッケージ：Python 仮想環境を作成し、pip install -r requirements.txt を実行します。
4. 常駐プロセスの起動：バックグラウンドの常駐プロセスを起動します。
5. 定期タスクの登録：統一された crontab スケジュールを復元します。
6. ヘルスチェック：プロセスの稼働を1つずつ確認します。失敗した場合はエラーログを記録して次の項目に進み、処理を中断・ブロックさせません。

『Grok Bot 仮想マシンリセット後にツールが全部消えた？バックアップ・復元チュートリアル（プロンプト付き）』

21.3 記憶マネージャー：Bot の中核記憶をプライベートリポジトリに格納する

公式には完全な記憶をエクスポートするボタンが用意されていないため、アカウント変更やシステム移行時に設定や好みが非常に失われやすいです。専任の「記憶マネージャー」Bot を用意し、形のない記憶をプライベート Git リポジトリのプレーンテキストスナップショットに変換するのが最も安全です。

『Grok Bot 百万撤退：完璧な Agent システムバックアップソリューション』

記憶の階層化と保守原則

階層	含まれる内容	説明と権限
共有層	アカウント共有記憶、共通 Skill、プラグイン設定	すべての Bot が読み取り可能
専有層	Description ルール規約、専有の独立記憶、Routine タスク	個々の Bot が排他的に保持

• 動的な事実はコンテキストに長期的に溜め込まず、アクセス方法のみを記録し、使用時にオリジンから再取得します。
• 共有記憶は、相互汚染を防ぐため、人間によるレビューまたは標準化されたワークフローによる検証を経る必要があります。
• ビジネス定義は記憶に書き込み、固定された操作フローは必ず Skill コードとして定着させます。

『4.6 仮想マシン、記憶とバックアップ』

アーカイブ仕様とワークフロー

アーカイブ仕様とワークフロー

├── bots/                     # 各 Bot 独立配置与记忆
│   ├── cyber-xiaowan/        # 单个 Bot 文件夹
│   │   ├── agent-spec.md     # 身份设定、名称、bot-id、slug、description
│   │   ├── MEMORY.md         # 核心记忆全量快照
│   │   ├── profile.md        # 角色信息与权限边界
│   │   └── archive/          # 历史版本与过往日志
│   └── ...                   # 其他 Bot 目录
├── meta/                     # 全局元数据与多 Bot 拓扑关系
├── shared-user-memory/       # 账号级共享记忆
├── vm-services/              # 虚拟机服务总账与恢复脚本（见 21.2 节）
├── README.md                 # 仓库使用说明与最新状态
├── RESTORE.md                # 跨环境恢复操作 SOP
└── registry.md               # 登记索引

個々の Bot ディレクトリ配下の MEMORY.md には、「ID・権限」「意思決定の責務」「現場スナップショット」の3層が含まれます。

1. リストの列挙：永続化バックアップが必要なコア Bot を選定します。
2. スケジューリングと指示の配信：各 Bot が自身の設定と記憶を読み取り、要約した上で /workspace 内の対応する Markdown ファイルに書き込みます。
3. 取得・検証・リポジトリ登録：平文の Token が含まれていないことをスキャン・確認した上で一括コミットし、日付タグ（例: tag-2026-10-15）を付与してリモートのプライベートリポジトリにプッシュします。

Bot はフルスナップショットを担当し、Git は増分追跡を担当します。Bot は毎回直接ファイルをフル上書き保存し、過去の変更履歴は Git エンジンに蓄積させるため、プロンプト内で差分を計算する必要はありません。

21.4 実践事例：铁柱AGI の百万撤退とサービスマネージャー

記憶マネージャーによるバックアップ

铁柱（@cgnot996）は 21 体の Bot を運用・保守しています。アカウント停止による記憶消失を防ぐため、彼は「記憶マネージャー」Bot を構築し、Gitee のプライベートリポジトリと連携させてアーカイブを行いました。

1. コアの選定：21 体の Bot から、まずは 7 体のコアを選んでテスト運用しました。
2. エクスポートと確認：7 体の Bot に設定と記憶をエクスポートするよう通知します。一部の Bot はエクスポート完了後に無言になるため、指示の中で「書き込み完了後に報告すること」を必須とし、同時にマネージャーが /workspace ディレクトリをスキャンして照合します。
3. 登録とタグ付け：初回の 73KB をリポジトリにアーカイブし、tag 2026-09-10 タグを付与してシークレットスキャンを通過させました。
4. 個別プロファイル構造：「サイバー小晩」のように、MEMORY.md（約 21KB）にアイデンティティとスナップショットを保存し、agent-spec.md に bot-id と説明を保存します。
5. 定時実行の有効化：定期的な自動アーカイブを設定します。

新しいアカウントにインポートした際の記憶再現率は約 80% でした。ローカルでバックアップされていないファイル、対話履歴、サードパーティのログイン状態は復元できません。

Hermes や OpenClaw に移行する際は、MEMORY.md を記憶ディレクトリに配置し、agent-spec.md の description をシステムプロンプトに変更するだけで動作します。

『Grok Bot 百万撤退：完璧な Agent システムバックアップソリューション』

仮想マシンサービスマネージャー

クラウドコンピュータがクラッシュしてリセットされると、ツールがすべて失われます。著者は Gitee の grok-bot-memory リポジトリにある vm-services ディレクトリに再構築台帳を記録しています。

1. 台帳への登録：2026-10-10 時点で、10 体の Bot の 20 項目（常駐 4 項目、オンデマンドツール 14 項目、秘密鍵関連 2 項目）を登録し、そのうち 18 項目を「復元必須」とマークしました。
2. サービスの分類：常駐サービスにはスクレイピングサービス、Muse API ラッパー、メールエンジン、送信トンネルが含まれます。オンデマンドツール（ffmpeg、Chrome など）はインストールコマンドのみを記録し、Metaso と TikHub は秘密鍵のパスのみを記録します。
3. クリーンなソースコードバックアップ：自作ソースコードは約 5.1MB で、秘密鍵、ログ、ステータス履歴を除外しています。
4. 直列的な復元：マネージャーが restore/ ディレクトリと restore-all.sh を保守します。マネージャーは普段は勝手に実行せず、人間の指示を待って依存関係順に起動し、受け入れチェックリストを提出します。

『Grok Bot 仮想マシンリセット後にツールが全部消えた？バックアップ・復元チュートリアル（プロンプト付き）』

21.5 認証情報のセキュリティと手動承認ゲート：画面は渡してもパスワードは渡さない

複数の Bot が仮想マシンのディスクとブラウザセッションを共有しているため、Bot を新設するだけでは機密データを隔離できません。 スクリプトやチャット内に一度平文で書き込んでしまうと、他の Bot や外部ログからも読み取られてしまいます。

『4.6 仮想マシン、記憶とバックアップ』

認証情報はパスのみを残し平文は残さない

• Token や秘密鍵は、Git の管理対象外である ~/.env またはグローバルシークレットディレクトリに保存します。
• REGISTRY.md、registry.json、および記憶ファイル内では、認証情報に関するものはディスクの絶対パスのみを記録します。
• チャット欄へのパスワード送信は厳禁とし、プッシュ前には必ず正規表現によるマスキングスキャンを実行します。

画面は渡してもパスワードは渡さない

1. Bot が 2FA、QRコードスキャン、またはデバイス認証のポップアップに遭遇した場合、直ちに一時停止して人間に引き継ぎを通知します。
2. ユーザーはクライアントでクラウドコンピュータを全画面表示にし、自分でパスワードを入力するかQRコードをスキャンします。
3. 完了後に制御権を戻すと、Bot はセッション Cookie を引き継いで処理を続行し、平文パスワードに触れることはありません。

高リスク操作には Ask-first を設定する

• 投稿、決済、データ削除、低レイヤー環境の変更などの不可逆な操作は、必ずポップアップを表示して人間の承認を待つ必要があります。v0.70.2 ではこの種の確認ロジックが最適化されました。
• Bot の自律権限は読み取り、公開検索、/workspace 内部の読み書きのみに限定され、ルールが衝突した場合は Ask-first が優先されます。

21.6 すぐに使える3つのプロンプトセット

以下に、実際の運用で検証済みの3つのプロンプトを提供します。コピーして対応する Bot に送信するだけで、デプロイして使用できます。

プロンプト1：クラウドコンピュータに「仮想マシンサービスマネージャー」を設定する

「仮想マシンサービスマネージャー」Bot を作成し、設定に貼り付けます：

プロンプト1：クラウドコンピュータに「仮想マシンサービスマネージャー」を設定する

你是「虚拟机服务管家」，只管一件事：记下这台虚拟机上部署过的所有第三方服务，并在电脑更新或换账号之后，按记录把它们原样恢复。

你维护的东西
1. 一份登记总账，人和机器各读一份：REGISTRY.md（表格）和 registry.json（给脚本读）。
2. 每个服务一个恢复脚本 restore/restore-<服务>.sh，必须幂等，重复跑也不会出错。
3. 一个总入口 restore/restore-all.sh，按依赖顺序调用各个恢复脚本，最后汇总哪些失败了。
4. 一份源码备份 service-src/：各 Bot 自己写的服务代码和脚本，同步时排除密钥、日志、运行状态、虚拟环境和个人数据，并先扫一遍明文密钥，命中就停。
5. 以上全部跟着一个私有 Git 仓库存（「你的备份仓库地址」）。总账、恢复脚本、源码都在仓库里，密钥永远不进仓库。

登记规则（其他 Bot 部署任何服务都必须来找你登记）
每项必须包含：
- 名称和短 id、用途、负责的 Bot
- 路径：代码、配置、数据分别在哪
- 安装方式和依赖（apt / pip / npm / Docker / 系统定时任务）
- 启停命令、健康检查命令
- 更新后的恢复步骤，或者对应的恢复脚本
- 是否必恢复：是 / 否
- 密钥：只写存放路径，绝不写明文
- 需要真人完成的步骤（OAuth 登录、扫码、导入 cookie）单独标出来

你的工作方式
- 先弄清哪些会丢、哪些能留：电脑更新一般保留工作目录，但系统包、常驻进程、全局安装的命令行工具会丢；重置则什么都不留。所以要记的是“怎么重建”，不是去拷整台机器。
- 能从公开渠道重装的（apt、pip、npm、上游 Git 仓库）只记安装命令；自己写的代码必须进源码备份，否则重置后就找不回来。
- 收到登记先核对：路径是否真实存在、健康检查能不能过。登记写的和实际不一样时，以实际为准，并告诉负责的 Bot。
- 多个定时任务合并成一份 crontab 真源时，检查每一条是不是都在真源里，不在的要靠恢复脚本补回去。
- 故意停掉的服务要写清楚“为什么停、什么条件下重开”，免得被当成漏装。
- 只有主人说“电脑更新完了”才跑总恢复，不盲跑。跑完交验收：每项是成功、失败，还是要真人处理。
- 每次有服务新增、删除或源码大改，先重新同步源码备份，再把总账、脚本、源码一起提交推送到备份仓库。换账号或重置时，就靠这份备份把整套设定带走。
- 删掉的服务要彻底清除：总账只反映现在真实的状态。

プロンプト2：コンピュータのリセット後に Bot に全面復元を実行させる

Git アクセストークン を設定し、括弧内の内容を置き換えて Bot に送信します。

プロンプト2：コンピュータのリセット後に Bot に全面復元を実行させる

这台电脑刚重置过（或者是换了新账号），之前部署的服务都没了。请按我的备份把它们恢复到可用状态，规则如下。

备份在哪
- 备份仓库：<你的备份仓库地址>，分支 <分支名>
- 仓库里有：登记总账（REGISTRY.md 和 registry.json）、每个服务的恢复脚本（restore/）、自写服务的源码备份（service-src/）
- 仓库里没有密钥，这是故意的

请按这个顺序做
1. 把备份仓库拉到工作目录，先读总账，告诉我一共登记了几项、哪些标了「必恢复」、哪些只留密钥不用恢复。先列出来，不要动手。
2. 把自写服务的源码从 service-src/ 放回总账写的原位置。只补缺失的，已经存在的目录不要覆盖。
3. 按总账的依赖顺序逐项恢复：先装系统依赖（比如 cron、ffmpeg），再装命令行工具，最后拉起常驻服务和定时任务。每项都用它自己的恢复脚本，脚本要能重复跑。
4. 每装完一项就跑它登记的健康检查。失败了先看日志、试着修一次；修不好就记下原因，接着做下一项，不要卡住。
5. 把需要我本人做的事汇总成一张清单：要重新提供的密钥（只说放哪个路径、叫什么名字，别让我把密钥贴进聊天）、要重新登录授权的工具（OAuth、扫码、设备码）。然后一项一项带我做，每做完一项马上复查。
6. 故意暂停的任务保持暂停，总账里写了原因和重开条件的照办。别因为“看起来漏装了”就自作主张打开。
7. 最后交验收清单，每项一行：服务名、结果（成功 / 失败 / 等我处理）、健康检查输出摘要、花了多久。再告诉我总共用了多少时间、成功了几项。

不要做的事
- 不要把任何密钥写进仓库、日志或聊天
- 不要跑总账没登记的安装
- 不要用“重置电脑”当修复手段
- 恢复完如果有任何改动（路径变了、版本升级了），更新总账，提交推回备份仓库

プロンプト3：記憶マネージャーの定期アーカイブ指示

Routine または手動アーカイブ時にこちらを送信します：

プロンプト3：記憶マネージャーの定期アーカイブ指示

请开始执行本周的智能体记忆与设定归档任务。

执行步骤：
1. 枚举当前工作区内所有处于活跃状态的 Bot 名单，核对 bots/ 目录下的已有目录。
2. 逐个通知名单内的 Bot：读取各自的 Description、人设规则与当前核心记忆，按三层结构（身份profile、历史决策与职责、当前现场快照）提炼并覆盖写入 /workspace/bots/<bot-slug>/MEMORY.md。同时将身份元数据更新至 agent-spec.md。
3. 检查各 Bot 回执，并在 /workspace 目录核对文件生成情况，确保所有目标 Bot 的 Markdown 均已写出。
4. 提取账号级共享记忆，更新至 shared-user-memory/ 目录下的 Markdown 文件中。
5. 对本次生成的所有 Markdown 文件进行敏感信息正则扫描，检查是否存在明文 API Token、密码或私钥。如果发现疑似凭证，立即中断并报警。
6. 扫描无异常后，执行 Git 操作：将所有更新文件暂存，提交信息标记为「memory snapshot YYYY-MM-DD」，推送到远端私有 Git 仓库，并打上对应日期的 Git Tag。
7. 完成后向我汇报：本次归档了哪几个 Bot、总文件大小、是否有失败或超时的 Bot。

21.7 よくある落とし穴

1. Reconnecting と表示された際はReset をクリックしないでください。単なるネットワークの揺らぎやメンテナンスであり、クリックすると古いスナップショットで未保存データが上書きされてしまいます。
2. 複数デバイスで Codex の認証を共有すると互いにログアウトさせられるため、独立したサブアカウントまたは固定された認証情報を割り当てる必要があります。
3. 定期タスクは統一して crontab 設定ファイルにまとめ、Git で管理して、マシンのリセットによる漏れを防ぎます。
4. サービス台帳は実際の運用コマンドを基準とし、環境に Docker がインストールされていないと復元スクリプトが停止する原因になります。
5. Bot のエクスポートは無言になりがちなため、マネージャーが積極的にディスクを確認し、指示で「書き込み完了後は必ず報告すること」を強く義務付けます。
6. バックアップリポジトリは必ずプライベートに設定し、正規表現スキャンを追加してください。Token が Git push によってパブリックリポジトリに流出するのを防ぎます。

21.8 完了後の受け入れテスト方法

サービスとスクリプト

1. 台帳確認：vm-services/REGISTRY.md と照合し、ps aux でプロセスを、netstat または ss でポートを確認します。パスの過剰記録や漏れがあってはなりません。
2. テスト実行：個別に restore-<服务名>.sh を実行し、エラーなく繰り返し実行できるか確認します。
3. 全体リハーサル：一時ディレクトリにクローンした後、bash restore/restore-all.sh を実行し、「復元必須」の項目がすべて成功することを確認します。手動対応が必要な手順がリストアップされていることも確認します。

リポジトリと記憶

1. 構造確認：Web画面で bots/ を確認し、各 Bot に独立した agent-spec.md と MEMORY.md が存在することを確認します。
2. サンプリング検査：MEMORY.md を開き、「ID profile」「意思決定の履歴と責務」「現在の現場スナップショット」の3層が完全であり、空のテンプレートや文字化けがないことを確認します。
3. シークレット検索：全体を sk-、Bearer、password で検索し、認証情報はローカルの絶対パスのみを残し、平文 Token は厳禁です。

関連リンク

• 公式ユーザーガイドおよびサポートページ：
  • 『Grok Bot コンピュータ』
  • 『機密情報の安全な保管』
  • 『ヘルプの利用』
  • 『Grok Bot 利用ガイド』
• コミュニティ実践参考記事：
  • 铁柱AGI @cgnot996：『Grok Bot 仮想マシンリセット後にツールが全部消えた？バックアップ・復元チュートリアル（プロンプト付き）』
  • 铁柱AGI @cgnot996：『Grok Bot 百万撤退：完璧な Agent システムバックアップソリューション』
  • ナレッジベース連携整理：『4.6 仮想マシン、記憶とバックアップ』