第5章 共有クラウドコンピュータ：ファイル、ブラウザ、操作の引き継ぎ

Grok Bot を使い始めたばかりのユーザーは、通常いくつかの共通した誤解を抱きがちです。これらの誤解は、後々の開発や保守で障害となることがよくあります。

• 新しい Bot を作成すると、独立した仮想マシンが1台増えるという誤解。
• 複数の Bot に共同作業をさせる際、お互いのチャット履歴を直接読み取れるという誤解。
• サードパーティツールのログインが必要な際、アカウントやパスワード、さらには API Token をチャットウィンドウに直接貼り付けてしまうこと。

クラウドコンピュータがシステムメンテナンスや基盤のアップデートによって突然初期化され、セットアップした環境やスクリプトがすべて消えて初めて、このクラウドコンピュータの低レイヤーの仕組みを何も理解していなかったことに気づくのです。

同一アカウント下のすべての Bot は同一のクラウドコンピュータ上で動作し、同じディスクおよびファイルシステムを共有しています。互いのセッション履歴を見ることはできず、コラボレーションはすべてディスク上のファイルの受け渡しに依存します。

ログイン認証が発生した際の正しいアプローチは、パスワードをモデルに渡すのではなく、クラウドブラウザの画面操作を引き継いで直接認証情報を入力することです。また、このクラウドコンピュータは本質的にいつでも再構築され得る一時的なコンテナであり、プラットフォーム基盤のアップデートや管理者のメンテナンス時には手動でインストールしたパッケージはすべて失われます。

本章では、このクラウドコンピュータの実際の動作メカニズムを解き明かします。複数の Bot 間で安全にファイルや画面を引き継ぐ方法、ホワイトリスト制限に対応するためにローカルデスクトップ経由でネットワークトラフィックをルーティングする方法、そしてリセット後も環境全体を秩序正しく迅速に復元できる軽量で標準化されたバックアップパイプラインの構築方法を学びます。

共有コンピュータの内部メカニズム：1台のマシンと複数のBot

アカウント内のすべての Bot は、同じマネージド Linux コンピュータを共有しています。 どの Bot に切り替えても、アクセス先は同一の /workspace ルートディレクトリおよび永続ディスクです。

チャット履歴は外部に独立して保存されているため、マシン内で rm -rf を実行して全消去したりシステムがクラッシュして再起動したりしても、会話やリストはそのまま残ります。

新しい Bot の作成はセキュリティ上の隔離を意味しません。 いずれの Bot もコマンドライン権限を取得しさえすれば /workspace 内のすべてのデータを読み書きできるため、暗号化されていない機密情報は絶対に置かないでください。

バージョンの変遷：

• v0.68.0：設定で他のコンピュータを削除する機能をサポート
• v0.68.1（2026-10-07 リリース）：画面解像度が 1280×800 から 1920×1200 に向上し、操作やスクリーンショットの応答が高速化
• v0.70.2：専用メールアドレスの追加、ウェブページから直接 PDF として保存する機能をサポート

内部の詳細については 『4.6 仮想マシン、記憶、バックアップ』 を参照してください。

複数 Bot の画面およびステータス監視

ステータスと設定

サイドバーには常時3種類のステータスが表示されます。

• 要対応：回答、承認、または引き継ぎ待ち。
• 未読アクティビティ：タスク完了、結果の確認待ち。
• 作業中：スクリプト実行中、ウェブスクレイピング中、またはツール呼び出し中。

上部の名前をクリックして「会話の詳細を表示」に入ると、現在の Bot の名前、タグ、アバターを変更できます。個人の Bot には個別の説明欄がありませんが、直接メッセージを送信するだけで役割を調整できます。

監視と通知

クラウド上の操作はリアルタイムでの画面確認をサポートしています。

フォーカスされている間は通知が自動的に抑制され、サイドバーと Dock にのみ未読が表示されます。オフライン時は設定ファイルで通知を有効にすることで、デスクトップやスマートフォンへプッシュ通知できます。

ブラウザ操作の引き継ぎ：画面を渡し、パスワードは渡さない

アカウント情報やパスワードをチャット欄に送信しないでください。あなたと Bot はブラウザを共有しており、画面を渡し、パスワードは渡さないのが原則です。

引き継ぎの手順

1. 一時停止のトリガー：Bot がログインページを開き、ID/パスワード、QRコードスキャン、または 2FA に遭遇した際に一時停止します。
2. 入力の引き継ぎ：フルスクリーンをクリックしてキーボードとマウスの操作を引き継ぎます。
3. 手動でのログイン：自身でID/パスワードを入力するか、QRコードスキャン認証を行います。
4. 実行の返却：ログイン後、Bot に通知して Cookie を再利用して実行させます。プレーンテキストのパスワードには一切触れません。

承認ゲート

Cmd+, を押し、「一般」-「Bot」で設定します。

• ルールの競合時は「先に確認」（Ask first）が優先されます。
• 企業ルールに Required by your admin. You can't edit or delete this rule. と表示されている場合は変更できません。
• v0.70.2 では、メール送信や投稿、決済、および本番環境の変更前の確認が強化されました。

詳細は 設定と通知 を参照してください。

複数 Bot のファイル引き渡し規約とディレクトリ設計

ファイルによる連携パターン

Bot 間でチャット履歴を読み取ることはできず、複数 Bot の連携における唯一の経路は共有ディスクファイルです。

プロンプトには前の担当のファイルパスを渡すだけで済みます。詳細は 『4.6 仮想マシン、記憶、バックアップ』 を参照してください。

1. 整理担当がスクレイピングして tweets.md を生成
2. アナリストが要約・抽出して profile.md を出力
3. デザイナーがプロファイルに基づいて design.md を生成
4. エンジニアが設計を読み込んでコードを構築

ディレクトリ設計

複数 Bot によるファイルの乱立を防ぐため、マシンの作成当初にディレクトリを定めておきます。

ディレクトリパス	格納内容	書き込み規約
/workspace/handoff/	中間生成物	Markdown または JSON に統一し、タスクのプレフィックスを付与
/workspace/projects/	プロジェクトコードとアセット	プロジェクトごとに独立したサブディレクトリに分け、Git リポジトリに関連付け
/workspace/tools/	ローカルの自作スクリプト	シークレットを含まないソースコードのみを残し、確認後にバックアップリポジトリへ同期
~/.env またはローカルファイル	API キー	ローカルにのみ保存し、リポジトリへのコミットやセッション内での出力は厳禁

ディスククリーンアップと Disk Saver

システムが Computer is low on disk space または Computer is critically low on disk space という警告を発した場合は、サイドバーで Disk Saver の「Go to Disk Saver」をクリックしてクリーンアップの提案を確認します。

確認なしにファイルを勝手に削除することは決してなく、既存ファイルのクリーンアップを拒否した場合はそのまま保持されます。

ローカルネットワーク出口：ルーティングとプライベートネットワークへのアクセス

WeChat 公式アカウント、企業内ネットワークの IP ホワイトリスト、またはローカルエリアネットワーク（LAN）へのアクセスを解決するには、ローカルデバイス経由でトラフィックを中継するだけで十分です。

有効化の手順

1. Cmd+, を押して設定を開き、コンピュータ をクリックします。
2. あなたのコンピュータ で現在のコンピュータを見つけ、現在のコンピュータ経由でトラフィックをルーティング をオンにします。

制限事項と注意点

• 1回につき1台に制限されます。外部からはローカル IP として認識され、Bot も直接 LAN にアクセスできるようになります。
• 新しいリクエストに対してのみ有効であり、既存の TCP ロングコネクションは元のルートを通ります。
• 管理者が Allow Local Egress Routing を無効にした場合、スイッチはグレーアウトされて Disabled by your admin. You can't turn this on. と表示され、5分以内に強制切断されます。設定と通知 を参照してください。
• Execution on this computer はローカル Shell を制御し、デフォルトでは1行ずつ確認を求められます。安易に完全自動化を許可しないでください。

再構築、更新、終了：クラウドコンピュータのライフサイクル

再構築を行うと、独自にインストールした環境は消去されますが、ディスクとログイン状態は保持されます。

Grok Bot コンピュータ および Grok Bot コンピュータの管理 を参照してください。

操作	保持されるもの	消去されるもの・注意点
ソフトウェア更新	すべて	なし
更新 / 再構築	ディスクとファイル	自作環境の消去、スクリプトの再実行が必要
VM の終了	ディスク	30日間アイドル状態が続くとシャットダウンされ進捗が失われる
Recover / Reset	保存済みデータ	タスクの中断、未保存コードの消失

Reconnecting と表示された際にむやみに Reset を押さないでください。以下の順序でトラブルシューティングを行います。

1. Retry をクリック。再接続中もディスクは無傷です。むやみに操作すると状況を悪化させます。
2. 完全終了。macOS の場合は赤の「×」ボタンを押すだけでなく、Cmd+Q で完全に終了してから再起動してください。
3. 更新の確認。「設定」>「コンピュータ」を開き、Bot が待機中（アイドル状態）であることを確認してから更新します。
4. Recover を優先。ポップアップの選択肢が出たらまずこれを選び、可能な限りスナップショットを保存します。
5. 最終手段として Reset。未保存のコードがなく、すべてが完全に機能しなくなったことを確認した上でリセットします。

災害復旧パイプライン：サービス台帳と冪等な復元スクリプト

アップデートやリセットにより環境は消去されます。铁柱AGI（@cgnot996）は 2026-10-10 に、マシン全体を保存するのではなく、立ち上げ手順のみをバックアップするアプローチを提案しました。

彼は 5.1MB のプライベートリポジトリを用いて、10個の Bot に対する20個のサービス（必須復元18項目：常駐4個、オンデマンド14個、シークレットパス2項目を含む）を管理しています。詳細はチュートリアルを参照してください。

標準構造と台帳登録

リポジトリ vm-services は4つの部分から構成されます。

• REGISTRY.md および registry.json：台帳と設定。
• restore/restore-<服务名>.sh：単一サービス用スクリプト。必ず冪等であること。
• restore/restore-all.sh：順序に従ってライブラリや CLI をインストールし、バックグラウンドサービスを起動して失敗をカウント。
• service-src/：ソースコードのアーカイブ。.env、ログ、仮想環境は除外。

新しいサービスの登録には以下の項目を含めます：短い ID と担当 Bot、コードおよびデータのパス、インストール方法（apt/pip/npm/Docker）とシステム依存関係、起動コマンドとチェックコマンド（--version やポート）、復元が必須かどうか、シークレットの絶対パス（平文の記録は厳禁）、QRコードスキャンや OAuth などの手順。

2種類のプロンプト

「仮想マシンサービス管理者」Bot に送信し、他の Bot のデプロイはこれに基づいて完了報告を行います。

デプロイと登録のプロンプト

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

你维护的东西：
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 真源时，检查每一条是不是都在真源里，不在的要靠恢复脚本补回去。
- 故意停掉的服务要写清楚“为什么停、什么条件下重开”，免得被当成漏装。
- 只有主人说“电脑更新完了”才跑总恢复，不盲跑。跑完交验收：每项是成功、失败，还是要真人处理。
- 每次有服务新增、删除或源码大改，先重新同步源码备份，再把总账、脚本、源码一起提交推送到备份仓库。换账号或重置时，就靠这份备份把整套设定带走。
- 删掉的服务要彻底清除：总账只反映现在真实的状态。

リセット後に Git 認証情報を設定して復元 Bot に送信します。検収基準はチェックリストに従って結果、所要時間、チェック状態を報告させることです。

リセット後のワンクリック復元プロンプト

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

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

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

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

陥りやすい落とし穴

認証情報と権限

• チャット欄にシークレットを貼り付けない：Web 側では手動で入力し、CLI の Token は ~/.env に書き込んでスクリプトから環境変数を読み取ります。
• Bot 間に隔離はない：/workspace および権限は共有されます。機密性の高いアセットはプライベートリポジトリと手動承認に依存する必要があり、Bot を複数立ち上げても意味がありません。

コラボレーションと依存関係

• 引き継ぎは必ずディスクに保存する：Bot 同士で会話を読み取ることはできません。A の結果は Markdown または JSON として保存してください。口頭の説明だけでは B にハルシネーションが発生します。

• 依存関係は永続化されない：更新、Recover、または Reset によって apt install や npm install -g の内容は消去され、node_modules や .venv もバックアップされません。

  復元スクリプトには npm install および pip install -r requirements.txt を含める必要があります。

運用とネットワーク

• Reconnecting が表示されても Reset を押さない：未保存の変更が失われ、強制的に再構築されます。まずはリトライするかクライアントを再起動してください。
• 定期実行タスクは一元管理する：crontab は統一して Git リポジトリに保存して管理する必要があります。
• ローカルルーティングを有効化したら再起動が必要：「現在のコンピュータ経由でトラフィックをルーティング」をオンにしても IP が変わらない場合は、該当プロセスを再起動してください。

完了後の検証手順

1. Bot A が /workspace/handoff/test.json にタイムスタンプを書き込みます。Bot B がそれを読み取って正確に答えることができれば疎通成功です。
2. 「設定」>「コンピュータ」で「現在のコンピュータ経由でトラフィックをルーティング」を有効にし、ターミナルで curl -s https://api.ipify.org を実行します。グローバル IP がデータセンターの IP ではなくローカルと一致している必要があります。
3. Bot に GitHub のログインページを開かせ、必ずパスワード入力欄の前で一時停止して引き継ぎを促すことを確認します。手動でログインした後に続行し、ログに平文のパスワードが残っていないことを確認します。
4. プライベート Git に REGISTRY.md、registry.json、およびスクリプトがコミットされていることを確認します。テストディレクトリにプルして実行します：

bash restore/restore-all.sh

ヘルスチェックがすべてパスし、コンフリクトのエラーがなく、台帳記載のサービスが正常にリッスンしている必要があります。

参考資料

公式ドキュメントとナレッジベース

• Grok Bot コンピュータの管理：Enterprise 版における複数コンピュータの一括再構築、終了、および30日間のアイドルクリーンアップに関する公式の完全なルール。
• 設定と通知：デスクトップアプリの設定、ローカルコマンド実行、トラフィック中継ルーティング、Auto-review モードに関する公式の解説。
• Grok Bot コンピュータ：Update、Recover、Reset の違いとトラブルシューティングのセルフチェックリストに関する公式の解説。

コミュニティの実践事例

• 『4.6 仮想マシン、記憶、バックアップ』：クラウドコンピュータの内部アーキテクチャ、コンテキスト構成マップ、複数 Bot によるファイル連携を詳細に解説。
• 『Grok Bot 仮想マシンをリセットしたらツールが全部消えた？バックアップ・復元チュートリアル（プロンプト付き）』：コミュニティ作者の 铁柱AGI（@cgnot996）による仮想マシンサービス管理者の設計、台帳登録表、ワンクリック復元の実践解説。