AIエージェントを24時間動かすと、派手な新機能より先に気になるものがあります。止まった処理が戻るか。ブラウザから社内ネットワークへ抜けないか。障害時のログに認証情報が混ざらないか。
OpenClaw 2026.6.34は、この運用上の穴をまとめて塞いだ保守リリースです。新しい機能を増やす更新ではありません。ブラウザとネットワークの境界、途中で切れた実行の回復、チャネル配送、資格情報の扱いを堅くしています。
今回変わったこと
公式リリースで最初に挙げられたのは、ブラウザとネットワークの境界です。サンドボックス化したブラウザ経路、信頼済みDNS、独自ブラウザの接続元、ループバック上のプロバイダー接続について、安全でない経路を拒否する修正が入りました。
次は、長時間実行の回復です。セッション書き込み、プロバイダーのフォールバック、ストリーム進捗、標準入出力の障害が起きても、実行中の仕事を黙って終了しないよう修正されています。チャネル側も、回復後に保留作業を再開し、同じ確認応答を二重処理しない設計へ寄せられました。
運用者向けの画面では、所有者だけが使える操作を守り、アカウントURLや要約に資格情報を出さない修正が入っています。SQLiteのチェックポイント、ワークスペース読み込み、ゲートウェイのプロセス通知も、ホスト側の一時的な不調で実行全体を失敗させにくくなりました。
「復旧した」と「正しく完了した」は分ける
再試行や自動復旧が強くなるほど、運用では二重実行に注意が必要です。問い合わせの要約や社内調査なら、同じ処理をもう一度走らせても被害は小さい。一方、メール送信、記事公開、請求処理、在庫更新は別です。復旧後に同じ操作が再実行されると、顧客へ直接影響します。
仕事を再開するときは、依頼IDと処理状態を正本に残します。状態は少なくとも「受付」「処理中」「成果物作成済み」「外部反映済み」に分ける。エージェントが落ちた場合、外部反映済みかを確認してから再開します。
この区別がないと、障害に強いシステムが、同じメールを二度送るシステムへ変わります。復旧機能は便利ですが、冪等性まで自動で保証してくれるわけではありません。
ブラウザを使うAIには出口を決める
ブラウザ操作を任せる場合、ログインできるサイトだけでなく、アクセスしてよいネットワークも決めます。社内管理画面、ルーター、クラウドのメタデータ、ローカル開発環境は、通常のWeb検索から到達させる必要がありません。
実務では、公開Webの調査用ブラウザと、管理画面を操作するブラウザを分けます。管理画面側は対象ドメインを許可リストにし、公開、削除、決済などの操作に人の承認を残す。OpenClaw側の境界修正に加え、業務側でも「どこへ行けるか」「何を実行できるか」を絞る形です。
導入前に確認する3つのログ
1つ目は、実行ログです。開始時刻、終了状態、成果物の保存先、再試行回数を残します。2つ目は、外部操作ログ。送信先、公開URL、更新対象IDのように、外へ何を変えたかを記録します。
3つ目は、回復ログです。どの障害を検知し、どの地点から再開したか。復旧後に人が見るべき箇所も残します。チャットの「完了しました」は通知にすぎません。仕事の完了は、正本の保存先と外部反映の確認で決めます。
OpenClaw 2026.6.34は、extended-stable向けの保守版です。公式リリースにはnpmパッケージ、コンテナのタグとダイジェスト、SLSA provenanceへのリンクまで掲載されています。更新するなら、バージョン番号だけでなく配布物の出所も照合できます。
最初の一手は単純です。自動復旧を有効にする前に、外部へ影響する操作を一覧にし、自動再試行から外すものを決める。AIへ仕事を委譲するための手綱は、障害時にどこから再開するかまで含みます。
公式情報
- OpenClaw 2026.6.34 release
- openclaw 2026.6.34 npm package
- npm provenance attestations
- OpenClaw container packages
確認日：2026年8月10日。変更内容、配布物、ダイジェストはOpenClaw公式リリースを基に整理しました。運用ルールはmonobloによる実務上の解釈です。