.bashrc の一行で約32時間停止――Muse と Grok Bot の実践ノート

1. エージェントにPCを渡した後に残ること

今回比較した二つの製品には共通点がある。返信を生成するだけでなく、永続的なクラウドPC上でブラウザーやファイル、ツールを使い、クライアントを閉じた後もバックグラウンドで作業を続けられる。[1][2][3]

複数の手順からなる仕事を実際のツール上で完了できる一方、管理する環境が一つ増える。環境設定、ファイルの永続化、ログイン状態、復旧経路が、仕事の成否に関わってくる。前半で扱う約32時間の停止も、利用者側の起動設定の一行が発端だった。

最初に、情報の根拠を分けておく。

• 公式の一次情報：Muse は Meta の発表記事と製品ページ、Grok Bot は Cursor の文書と SpaceXSI の発表ページを参照した。リンクは末尾にまとめ、いずれも2026-11-06に確認した。
• メディアによる二次情報：公式ページで裏付けられなかった情報は、今回の仕様比較には使わない。Muse の具体的な月額料金と Windows ネイティブアプリの開発状況についても、二次情報だけでは断定しない。
• 筆者の実体験：Grok Bot の障害の症状、復旧の試行、修復結果は私の利用記録に基づく。サポートによる個別事例への説明は別途明記し、公開文書の一般的な保証とは区別する。
• 筆者の解釈・推測：技術的な仕組みや選び方についての判断には、その旨を記す。Muse は同条件で検証していないため、実際の成功率や使い心地の優劣は比較しない。

2. 起動設定の一行から始まった障害

2.1 症状

障害時は、クラウドPCで echo ok や ls といった簡単なコマンドを実行しても、タイムアウトまで応答が返らなかった。発見から最終的な復旧まで、約32時間かかった。

Update と Reset を繰り返し試した。復旧直後は短時間使えたものの、その後またコマンドがタイムアウトする状態に戻った。短い復旧が何分続いたのかを正確に示せる記録はない。

ここで、ボタンの意味を整理しておきたい。現在の Cursor 文書では、次のように説明されている。[4][5]

• ソフトウェア更新は Grok Bot のソフトウェアだけを更新し、インストール済みアプリを残す。
• PCの更新はクラウドPCを再構築する。ファイルとログイン状態は引き継ぐが、インストール済みアプリやパッケージは削除される。どちらの更新かは Update ボタンの説明で確認できる。
• Reset / Recoverは最後に保存されたデータから再構築する。障害中のPCで事前保存できなければ、直近の変更が失われる可能性がある。Reset は最終手段であり、利用者の設定をすべて消す操作ではない。

引き継がれる設定自体が原因なら、システムを再構築するだけでは解決しないことがある。

2.2 サポートの指摘と修復の行き詰まり

今回のサポートから最初に示されたのは、.bashrc や .profile にあるバックグラウンド起動のコマンドが、繰り返し停止する原因になり得るという指摘だった。これらの利用者ファイルは、保存済みデータとともに復元される。

当時は、次のように修復が行き詰まっていた。

失敗していたのは、その時点で使っていたコマンド実行経路である。すべてのファイル操作が shell に依存するとも、PCのカーネル自体が停止していたとも、この症状だけでは言えない。

2.3 公式に確認された範囲と筆者の推測

公式に確認されたこと

事後のサポートの説明では、利用者の起動ファイルにあったバックグラウンド起動コマンドが引き金だった。設定が復旧後も残るため、再構築を繰り返しても、先に原因の設定を取り除く必要があった。

当時、私の .bashrc の末尾には、バックグラウンドで常駐するネットワーク補助スクリプトを起動する一行があった。環境が復旧した後に自動起動させるために置いたものだ。この行をコメントアウトし、PCの更新を行った後、簡単なコマンドは正常に返るようになった。

今回確認できたのは、起動ファイル内のバックグラウンド起動設定が繰り返す停止に関係し、その設定を外した後に復旧したという範囲である。サポートの確認は、ロック競合、プロセス数、リソース枯渇まで特定したものではない。

筆者の推測（各項目は未検証）

以下はリスクを理解するための shell の仕組みであり、この障害の詳細な原因調査結果ではない。

1. Bash の対話的な非ログイン shell は、通常 .bashrc を読む。ログイン shell は所定の順序で起動ファイルを読み、優先されるファイルがなければ .profile を読む場合がある。実際の動作は起動オプションやファイル間の読み込みにも左右される。今回の Agent のコマンド経路がどう shell を起動していたかは個別に確認しておらず、毎回必ず .bashrc を読むとは断言できない。
2. 起動ファイル内の通信、同期的な待機、ロック取得は、shell の初期化を止める可能性がある。nohup ... & でも、バックグラウンドプロセスが呼び出し元の標準出力・標準エラーのパイプを引き継ぐと、呼び出し元が EOF を待ち続ける場合がある。& があるだけで実行経路がすぐ戻るとは限らない。
3. 初期化が繰り返されれば、プログラムが重複起動する可能性もある。flock の待機設定や、setsid 後のプロセスの寿命は確認点になる。ただし、ロック待ち、インスタンスの増加、リソース枯渇は今回いずれも個別に検証していない。ロックファイルが残っているだけでは、ロックが保持されている証拠にはならない。
4. コマンドのタイムアウトから分かるのは、実行経路が想定どおりに応答しなかったことまでである。当時のプロセス一覧やシステム指標がないため、カーネル、サービス、リソースの状態は断定できない。

Bash の設定で対話モードかを判定することや、バックグラウンドプログラムに出力パイプを継承させないことは、防御策の候補になる。ただし、既存設定と呼び出し方の確認が先だ。一般的なコード片を、今回検証済みの修復方法として扱うことはできない。より直接的なのは、常駐サービスを shell の起動ファイルから起動しないという原則である。

2.4 修復結果

最終的には次の手順で復旧した。

1. 起動ファイルをバックアップする。
2. 特定できたバックグラウンド起動の一行をコメントアウトする。
3. PCの更新を一度実行する。
4. echo ok や ls ~ を繰り返し実行し、その後のタスクでも再発しないかを見る。

この結果は、§2.3 の公式に確認された範囲と整合する。上に挙げた停止や重複起動の仕組みが、すべて実際に起きていたことを証明するものではない。

2.5 ファイルを読むこともできない場合の復旧経路

今回サポートが示した方針は、失敗しているコマンド実行経路に依存しないファイルコピー経路を使い、手元のPCで起動ファイルを直すことだった。以下は個別事例の手順を整理したもので、すべてのバージョンに無条件で適用する指示ではない。

1. まず別の復旧経路を確認し、バックアップする。 .bashrc、.profile などをコピーして原本を残す。編集時にファイル名、権限、改行形式が変わらないようにする。独立したコピー経路も使えない場合は、再構築を繰り返すのではなく、公式サポートに方法を確認する。
2. 一行ずつ確認する。 バックグラウンド起動や待機を行うと確認できた行だけをコメントアウトする。nohup、setsid、flock、& は検索の手がかりであって、一括削除の条件ではない。正常なセッション初期化にも含まれ得る。
3. 確認済みのファイルだけを書き戻す。 コピー先を確認し、戻せるように元のファイルを残す。
4. 今回の公式サポートの案内に従い、数分程度待つ。 この事例での案内であり、すべてのプロセスがその時間内に終了するという保証ではない。
5. 現在の画面と公式の案内に従って復旧する。 影響の小さい方法から試し、必要ならPCの更新を行う。Reset は、直近のデータが失われる可能性を理解し、ほかの方法が有効でない場合に限って検討する。[4][5]
6. 繰り返し確認し、その後も観察する。 最初の一回だけでなく、新しいターミナルや後続タスクでも確認する。

ボタンの名前より重要なのは、修復経路を、障害が起きている経路に依存させないということだ。

2.6 自分の運用に残した三つのルール

1. 起動ファイルでは、短時間で終わり、繰り返しても問題のない初期化だけを行う。 環境変数、エイリアス、PATH も、毎回追記して重複させない。一度だけの処理や定期処理には routine を使えるが、常駐サービスには明確なライフサイクル管理とヘルスチェックが必要だ。routine 自体はサービスマネージャーではない。
2. 成果物は永続化し、実行環境は再構築可能にする。 公式文書に従い、長期保存するプロジェクトファイルは /workspace などの明確な作業領域に置く。一時ディレクトリー、手動で入れたパッケージ、未保存の状態だけに依存しない。[5] 特定のフォルダーが必ず残る、必ず消えると決めつけず、依存関係やビルド成果物は定義ファイルから再生成できるようにする。
3. 正常なうちに、独立した修復経路を試す。 ファイルのコピー方法、起動ファイルのバックアップ、切り戻し手順を確認する。.bashrc を変えたら新しいターミナルで echo ok を実行し、時間を測る。普段より明らかに遅ければ調べる。1秒は個人的な注意の目安であり、プラットフォームの障害判定基準ではない。

3. Muse と Grok Bot を比較する

3.1 公式の位置付けから見る

Meta は2026-09-08に Muse を発表した。Muse Spark と Muse Secure VM を使ってアプリをまたぐ仕事や目標の進捗を扱い、承認が必要なときに利用者へ確認する。メール、買い物、旅行、カレンダーは公式に挙げられている用途だ。[1][2]

Grok Bot の説明は、**Cursor 文書と SpaceXSI の発表ページ（2026-11-06確認）**に基づく。名前を付けた複数の Bot が役割を分担し、永続的なクラウドPCを共有しながら、コネクター、ブラウザー、ターミナルで作業する。[3][6] ここでは両者を製品情報の出典として扱い、企業の帰属や内部の組織関係までは推測しない。

両製品とも日常の用事と仕事の両方を扱う。一方は生活専用、もう一方は開発専用と単純に分けることはできない。

3.2 仕様と解釈を分けた二つの表

表1：確認できる事実と仕様。 いずれも公式の説明であり、私が独立したセキュリティ監査や全項目の実測を行ったという意味ではない。

Muse の Mac 版は製品ページで確認できた。Windows ネイティブ版の状況は未確認のため、ここでは判断しない。発表時の米国展開という情報も、現在の全地域の提供状況を確認したことにはならない。SpaceXSI の発表ページと現在の Cursor 文書では対応プラットフォームの記載が異なるため、表には現在の文書を採用した。[3][6]

表2：設計上のトレードオフとリスク（筆者の解釈）。 仕様表でも、総合的な安全性の順位表でもない。

安全面についての私の解釈は、両者とも文章の生成と操作権限を分けようとしている、というものだ。根拠は Muse の Sentinel と重要操作の確認、Grok Bot の Auto-review と承認ルールにある。仕組みは異なるが、それだけで総合的な安全性や、想定利用者の技術水準までは判断できない。

3.3 現時点での制約

Grok Bot

• 地域判定が障害になる場合がある。 特定地域の IP や地域判定に依存するサービスが、クラウドPCからのアクセスを受け入れるとは限らない。ブラウザー操作に対応していても、あらゆるサイトを使えるわけではなく、追加確認や人による操作が必要な場合がある。[3] こうした確認を、必ず回避すべき障害として扱うべきではない。
• PCの共有は、PC単位の障害の影響範囲を広げる。 今回の引き金は利用者の起動設定であり、複数 Bot の共有そのものではない。この事例が示すのは、PC単位の実行環境が使えなくなる影響である。公式の共有モデルに照らせば、同じPCに依存する同一アカウントの Bot は影響を受け得る。[3][5] 今回は Bot ごとの可用性を比較した記録がないため、約32時間を全 Bot の停止を独立して実測した結果とは扱わない。共有設計の欠陥を示すものでもない。
• PC更新には再インストールの負担がある。 ソフトウェア更新とPCの再構築を区別し、依存関係の定義を用意しておく必要がある。[4]
• 承認も作業手順の一部になる。 私の外部メッセージ送信では、下書きを確認してから送る手順を取っている。一段階増えるが、すべての操作やルールで同じ待ち時間が発生するという意味ではない。

Muse

• 提供地域は別途確認が必要。 公式発表時は米国展開だった。初期の対象地域外から使う場合は、利用できると決めつけず、現在の提供範囲を確認したい。[1]
• 計画を提供済みの機能として扱わない。 引用した発表記事では Confidential VM は今後の計画となっている。今回は提供開始を確認しておらず、現在の隔離の強さを評価する根拠にはしない。
• 能動的な実行にも権限の境界が必要。 製品ページでは、一度だけ許可、常に許可、拒否を選べる。[2] 継続的な許可が適切かはサービスごとに考える必要があり、安全機構が最小権限の原則を不要にするわけではない。
• 用途の例から開発能力の上限は分からない。 公式ページには文書作成、ツール構築、小規模事業向け機能もある。[2] 複雑なデプロイの比較検証はしていないため、開発用途の限界や、どちらが使い始めやすいかは断定できない。

3.4 私ならこう分ける

両方使えるなら、次の境界で割り当てたい。これは私の選択基準であり、Muse の優位を実測した結論ではない。

• 個人の用事は、Muse が公式に挙げるメール整理、買い物の準備、旅行の下調べなどを小さく試し、可用性、権限、承認の使い勝手を確認する。
• 仕事の成果物は、引き続き Grok Bot で資料整理、文章作成、ターミナルを使う作業を行う。Bot の分担はできても、共有PC上の資料は同じアクセス範囲にあると考える。

基準は、機能だけでなく、データとリスクで分けること。責任を持つ担当を決めずに、二つの Agent に同じカレンダー、受信箱、プロジェクトファイルを同時更新させない。まず読み取りと下書きで検証し、その後に書き込み権限を開く。

4. おわりに

選ぶ際は、提供地域、必要なコネクター、承認の方法、復旧経路を先に確認し、その上で個々の仕事の結果を比べたい。同条件の検証なしに、総合的な優劣は付けない。

今回の約32時間の障害で停止時間を左右したのは、モデルではなく起動ファイルと修復経路だった。常駐プログラムを shell の起動ファイルから外し、戻せるバックアップを残し、コマンド実行経路に依存しない修復方法を用意する。モデルを替えるより、今回の問題に直接効く改善である。

出典

以下はすべて公式の一次情報。確認日は2026-11-06であり、製品ページと文書は今後も更新され得る。個別のサポート説明は筆者の記録に基づき、公開の一般仕様として検証できるものではない。

1. Meta：Introducing Muse: The World’s First Personal AI Agent Built for Everyone。2026-09-08公開、ページには2026-09-30の更新日も記載。
2. Meta：Muse 製品ページ・FAQ。
3. Cursor：Grok Bot 文書。
4. Cursor：Settings and notifications。
5. Cursor：Work with Grok Bot。
6. SpaceXSI：Introducing Grok Bot。
7. Cursor：Grok Bot security。