Muse Code長時間タスク中断の復旧手順

Metaが公開したMuse Spark 1.1は、最大100万トークンのコンテキストを管理し、長い作業や複数Agentの連携を想定しています。これは長時間のコード作業に有利ですが、復旧時に「どこまで終わったか」を自動的に保証する意味ではありません。(Muse Spark 1.1の公式発表)

判断：Muse Code長時間タスク中断後の即時再実行は不適切です。 先にイベントログ、作業ツリー、外部操作の結果が一致しているか確認し、証拠がそろった場合だけ継続します。一致を証明できない場合は、ロールバックまたは新しい作業ツリーで再構築します。

この内容は、Muse Codeで大規模リポジトリを扱う開発者、リモートのMac環境でセッションを管理するプラットフォーム担当者、Agentの変更をレビューする技術責任者向けです。

最終更新：2026年8月12日。Museシリーズの公式発表、Meta Model APIの公開情報、長時間Agent運用に関するコミュニティ報告を確認し、復旧手順は実際の中断試験で再検証する前提です。Muse Codeのバージョンやイベントログ形式が変わった場合は、以下の確認をやり直してください。

中断の種類と復旧判断

最初に切り分けるのは、作業の消失ではなく「接続だけが切れた」可能性です。端末のSSH接続が切れた場合、Muse Codeのプロセスは動き続けていることがあります。一方、プロセス終了なら新しいセッションを起動する必要があり、モデル要求の失敗ならファイル変更が途中まで残っている場合があります。

次の3点を同じ時刻軸で確認します。

1. イベントログの最後に記録された成功イベント。
2. 現在のGit差分と未追跡ファイル。
3. ツール実行の戻り値と外部サービス側の処理結果。

確認用のコマンドは、Muse Code固有のログパスを決め打ちせず、実行環境で読み替えます。git statusの表示内容は、公式マニュアルでも作業ツリーとステージ領域の状態確認に使うものとして定義されています。(Git公式マニュアル：git status)

git status --short
git diff --stat
git diff --check
find . -maxdepth 2 -type f -name '*log*' -o -name '*event*'

出力例です。

 M src/router.ts
 M tests/router.test.ts
?? .muse/checkpoints/task-07.json

この状態だけでは「失敗」とは判断できません。最後の成功イベントがtests/router.test.tsの編集完了を示し、Git差分も一致していれば、テストだけを再実行できる可能性があります。

外部操作の再実行と二重処理

最も危険なのは、ファイル編集ではなく外部操作です。ローカルファイルは差分で確認できますが、コミット、通知、チケット更新、デプロイ、API送信は、実行済みでもクライアント側に成功結果が返らないことがあります。

復旧前に、次の表で処理の種類を分類します。

操作	差分で確認できるか	再実行の判断	推奨する保護
ファイル編集	できる	差分とログが一致すれば検証後に継続	Git差分、チェックポイント
テスト実行	一部できる	生成物と終了コードを確認	実行ID、出力保存
Gitコミット	できる	HEADとログを照合	固定コミットメッセージ
メッセージ送信	できない場合がある	人工確認なしで再送しない	冪等キー、送信ID
デプロイ・決済・削除	原則できない	成否確認まで停止	手動承認、監査ログ

Muse Codeが同じツールを再び呼び出したように見える場合、モデルだけを原因にしないことが重要です。復旧処理が「開始イベント」を見て未完了と判断し、外部側の実行結果を照合していない可能性があります。Muse Sparkはツール利用やAgent連携を前提に設計されていますが、イベントログを完全なトランザクションシステムとみなしてはいけません。(Muse Sparkの公式発表)

外部APIを再実行する場合は、処理済み識別子を保存し、同一要求を一度だけ受け付ける設計にします。GitHubのワークフローでも、ジョブの再実行や失敗後の継続を考慮した実行単位の管理が必要です。(GitHub Actions公式ドキュメント：ワークフローの再実行)

作業ツリーとイベントログのずれ

コード復旧で判断を誤りやすいのが、ログにはない変更が現在の作業ツリーに存在するケースです。手動修正、別のターミナル、バックグラウンドAgent、フォーマッターの自動実行が原因になります。

まず、現在の基準点を保存します。

git rev-parse HEAD
git status --short
git diff --binary > recovery.diff
git ls-files --others --exclude-standard > untracked-files.txt

次に、イベントログ側から以下を抜き出します。

• 編集対象のファイル名。
• 操作開始と完了の時刻。
• ツールが返した終了コード。
• テスト結果と生成物の場所。
• バックグラウンドAgentのタスク識別子。

ログとコードを照合し、変更単位ごとに「Agentが作った」「人が作った」「出所不明」に分類します。出所不明の変更を含むまま続けると、後から正しい修正だけを取り出せなくなります。

状態	継続	ロールバック	新しい作業ツリー
ログ、Git差分、テスト結果が一致	可	不要	不要
ファイル差分は一致するが外部操作が不明	保留	条件付き	推奨
手動変更や別Agentの編集が混在	不可	推奨	強く推奨
基準コミット自体が不明	不可	不可	必須

新しい作業ツリーを作る場合は、元の証拠を残してから分離します。git worktree addの用途と制約はGit公式ドキュメントで確認できます。(Git公式マニュアル：git worktree)

git worktree add ../repo-rebuild known-good-commit
cd ../repo-rebuild
git status --short

ここでいうknown-good-commitは、テスト通過とログ上の成功イベントを両方確認できたコミットです。単に最新のコミットを選ぶのではありません。

バックグラウンドAgentの結果

子Agentが返ってこない場合は、失敗と完了を同一視しないことです。タスク識別子、起動時刻、対象ブランチ、参照したコミット、結果ファイルを確認します。

結果が返ってきても、その内容が現在の基準コードに対して生成されたものとは限りません。古いコミットを対象にしたテスト結果や、別の作業ツリーに出力されたパッチは、そのまま統合できません。

次の条件を満たさない結果は、参考資料として保存し、直接マージしない方が安全です。

• 対象コミットが現在の基準と一致する。
• 実行時刻が中断前後の記録と整合する。
• テスト条件と依存関係が再現できる。
• 結果ファイルのハッシュまたは差分が確認できる。

バックグラウンド処理がセッションの一時停止後に消える問題は、別のコードAgentでもコミュニティから報告されています。これはMuse Codeの確定した不具合を意味しませんが、子Agentを信頼する前に、タスク状態と作業ツリーを別経路で確認する必要性を示す事例です。(GitHubの関連Issue)

Muse Code長時間タスク中断の復旧手順

実際の復旧は、次の順番から変えない方がよいです。

1. 新しい操作を止める
   同じ指示の再送、コミット、通知、デプロイを停止します。

2. 証拠を保存する
   イベントログ、エラー出力、Git差分、未追跡ファイル、ツールの戻り値を別の保存先へコピーします。

3. 最後の成功点を決める
   ログ上の成功イベントと、Git状態、テスト結果が一致する地点を探します。

4. 外部副作用を照合する
   送信ID、コミットID、ジョブID、デプロイ履歴を確認します。確認できない操作は保留します。

5. 処置を選ぶ
   一致していれば継続、不一致ならロールバック、証拠不足なら新しい作業ツリーで再構築します。

6. 小さな単位で再開する
   「全作業を続ける」ではなく、最後の確認済みファイル、次のテスト、外部操作のない編集から再開します。

7. チェックポイントを記録する
   作業単位ごとにコミット、テスト結果、次の作業、外部操作の状態を残します。

チェックポイントは、単なる会話の要約では不十分です。最低限、次のような機械可読の記録にします。

{
  "checkpoint": "task-07",
  "base_commit": "known-good-commit",
  "files_changed": ["src/router.ts", "tests/router.test.ts"],
  "tests": "passed",
  "external_actions": [],
  "next_action": "run integration tests"
}

FAQ：中断後に迷いやすい判断

Muse Codeが途中で落ちた場合、最初に何を確認すべきですか？

同じ指示をすぐ再実行せず、まず最後に成功したイベント、現在のGit差分、未追跡ファイル、ツールの戻り値を保存します。端末だけが切れたのか、プロセスが終了したのか、モデル要求が失敗したのかで復旧方法が変わります。外部送信やコミットが絡む場合は、実行済みか確認できるまで停止します。

Muse Codeが同じツール操作を繰り返す原因は何ですか？

復旧時にツール呼び出しの開始記録だけが残り、成功した戻り値や外部サービス側の結果を確認できない場合、未完了と誤認して再実行することがあります。ファイル編集だけなら差分で検証できますが、コミット、通知、API送信などは冪等キーや処理済み記録がないと二重実行を防げません。

復旧後にコードとイベントログが一致しないときはどうしますか？

人工的な変更、別のAgent、別ターミナルからの操作が混ざった可能性があります。現在のブランチをそのまま続けず、Gitの差分、作業ツリー、ログの編集記録を保存し、対応関係を説明できるか判定します。説明できない場合は新しい作業ツリーを作り、既知のコミットから計画を再構築する方が安全です。

Muse Codeの長い作業にチェックポイントを設定する方法は？

機能単位、テスト通過単位、外部操作の直前にチェックポイントを置きます。各時点でコミット、実行済みコマンド、変更対象、次の作業、外部操作の処理IDを記録します。大規模な変更を一つのセッションに詰め込まず、復旧後に検証可能な小さな単位へ分割することが重要です。

ロールバックと再構築の境界

復旧失敗後にログを削除してはいけません。ログ、差分、ツール出力、エラー発生時刻を残しておけば、次の試験で同じ条件を再現できます。

処置の基準は明確に分けます。

• 継続：最後の成功イベント、Git差分、テスト条件が一致している。
• ロールバック：変更範囲を特定でき、既知の正常コミットへ戻せる。
• 終了：外部操作の成否が不明で、再実行による損害を評価できない。
• 再構築：作業ツリーやAgentの出所が混ざり、現在の状態を説明できない。

Muse Spark 1.2やMuse Codeの新しい版を試す場合も、いきなり本番リポジトリへ投入しないことを勧めます。まず短期の隔離環境で端末切断、プロセス終了、モデル要求失敗を個別に再現し、イベントログとGit差分がどの範囲まで復元されるか確認します。公式のMuseシリーズはツール利用、長いコンテキスト、Agent連携を重視していますが、復旧精度やバージョン間の互換性は環境ごとの検証が必要です。(Meta AI公式情報)

現在のローカル環境や共有サーバーだけで長時間タスクを運用すると、スリープ、SSH切断、権限差、ログ保存先の不足、他の開発者との作業ツリー競合が起きやすくなります。短期検証なら手元の環境でも足りますが、継続的にMuse Codeを走らせるなら、隔離されたMac環境の方が復旧条件を固定しやすく、実行ログや作業ツリーも管理しやすくなります。

まずは小さなリポジトリで中断試験を行い、条件が固まった段階でleapmacのMacレンタル環境を正式な長時間タスク用ノードとして比較してください。物理機器への直接アクセスや長期の常時稼働が必要な場合は自前Macが適しますが、検証、短期開発、チーム用の再現環境であれば、復旧手順を試せる隔離環境から始める方が現実的です。

よくある質問

Muse Codeが途中で落ちた場合、最初に何を確認すべきですか？

同じ指示をすぐ再実行せず、まず最後に成功したイベント、現在のGit差分、未追跡ファイル、ツールの戻り値を保存します。端末だけが切れたのか、プロセスが終了したのか、モデル要求が失敗したのかで復旧方法が変わります。外部送信やコミットが絡む場合は、実行済みか確認できるまで停止します。

Muse Codeが同じツール操作を繰り返す原因は何ですか？

復旧時にツール呼び出しの開始記録だけが残り、成功した戻り値や外部サービス側の結果を確認できない場合、未完了と誤認して再実行することがあります。ファイル編集だけなら差分で検証できますが、コミット、通知、API送信などは冪等キーや処理済み記録がないと二重実行を防げません。

復旧後にコードとイベントログが一致しないときはどうしますか？

人工的な変更、別のAgent、別ターミナルからの操作が混ざった可能性があります。現在のブランチをそのまま続けず、Gitの差分、作業ツリー、ログの編集記録を保存し、対応関係を説明できるか判定します。説明できない場合は新しい作業ツリーを作り、既知のコミットから計画を再構築する方が安全です。

Muse Codeの長い作業にチェックポイントを設定する方法は？

機能単位、テスト通過単位、外部操作の直前にチェックポイントを置きます。各時点でコミット、実行済みコマンド、変更対象、次の作業、外部操作の処理IDを記録します。大規模な変更を一つのセッションに詰め込まず、復旧後に検証可能な小さな単位へ分割することが重要です。