AIに仕事を任せたあとでGatewayを再起動すると、返事が消えたのか、まだ処理中なのか分からない。担当者は待つか、同じ依頼をもう一度出すかで迷います。公開や発注を含む処理なら、二重実行も起きかねません。
OpenClaw 2026.9.2は、この地味だが厄介な部分を直しました。実行中、待機中、別エージェントへ委譲した返信を再起動後に復旧し、長い会話を準備している間もGatewayの応答を保つ更新です。
再起動を「例外」ではなく通常運用に入れる
公式リリースによると、2026.9.2では実行中、キュー待ち、委譲済みの返信をGateway再起動後に復旧します。一つの返信が完了しても、別の返信の復旧情報を捨てないよう修正されました。会話の圧縮や再試行を挟んでも、継続用の指示を保持します。
更新処理も見直されています。自動更新時に現在の設定、有効なスキル、既定エージェントの所有情報を保持し、Git更新後のGateway再起動を復旧します。更新結果は成功、失敗、意図的なスキップを区別し、再開に必要な案内を返します。
これで再起動が無害になるわけではありません。外部サービスへ送ったメールや発注は、OpenClaw側の会話復旧だけでは取り消せません。復旧時の状態管理と再実行の境界は、止まったAIを安全に戻す運用設計でも整理しています。再起動後に「同じ指示を出し直す」運用をやめるのが先です。
中小企業では、仕事を三つの状態で管理する
私は、AIへ渡す仕事に次の状態を持たせるのが現実的だと考えます。
- 受付済み：依頼IDと入力元を記録した
- 実行中：担当エージェントと開始時刻が分かる
- 完了確認済み：成果物と外部反映を人が確認した
再起動が起きても、受付済みの依頼を新規作成しません。まず元のセッションと復旧した返信を確認します。成果物が見つからない場合だけ、同じ依頼IDのまま再実行する。これなら、担当者が不安になって同じ仕事を重ねる事故を減らせます。
たとえば記事公開なら、本文作成、WordPress下書き、公開確認を別々の記録にします。Gatewayが途中で落ちても、公開URLが存在するかを先に確認し、なければ未完了工程から戻します。「返事が来ていない」ことを「何も実行されていない」と扱わないのがポイントです。
長い会話と定期実行も止まりにくくなった
長い会話履歴を準備するとき、Gatewayのイベントループ外で永続履歴を読むようになりました。画面に見えている会話を先に読み込み、背景の履歴準備を後へ回す変更も入っています。履歴準備中のキャンセルも維持されます。
Cronでは、ジョブが自分自身を削除した場合も最終返信を保持し、削除された条件をメインセッションへ渡す前に停止します。ジョブの編集や複製では失敗通知ポリシーを引き継ぎます。夜間処理では「成功したか」だけでなく、「失敗を誰に知らせるか」まで残る方が重要です。
設定変更の反映範囲は、更新前に確認する
エージェント、モデル、ツール、チャンネル、ブラウザなど、より多くの設定を稼働中の担当コンポーネントへ反映できるようになりました。再起動が必要な項目は設定リファレンスに残ります。
便利ですが、権限やセッション可視範囲を変更した直後は確認が要ります。2026.9.2では通常のエージェント間セッション参照が有効で、セッションツールの初期可視範囲は全セッションです。共有環境で範囲を狭めるなら、tools.sessions.visibilityをagentまたはselfに設定します。ツール権限やサンドボックスの制限は別に残るため、可視範囲だけで安全設計を終えない方がいい。
最初の確認は、再起動テスト1回でいい
公開情報だけを使った長めの要約を一つ走らせ、処理中にGatewayを再起動します。確認するのは、元の返信が復旧するか、二重に開始されないか、完了結果が決めた保存先へ残るか、失敗時に通知されるかです。
四つを通過したら、次は社内文書の整理へ広げます。発注、送信、削除のように戻せない操作は後回し。復旧機能は便利ですが、最後の確認者まで自動化する理由にはなりません。
一次情報
この記事は2026年9月6日に、上記の公式リリースと公式ドキュメントを確認して作成しました。製品側で確認できる変更と、導入時の運用提案を分けて記載しています。