AIに仕事を任せたのに、返事が来ない。管理画面では処理済みに見える。担当者は「成功したのか、黙って止まったのか」を判断できず、結局ログを掘る。
複数のAIをつないだ運用では、この「完了したのに結果が戻らない」が厄介です。派手な新機能より地味ですが、現場ではここが壊れると委譲そのものを信用できません。
2026年10月3日に公開されたOpenClaw 2026.9.8は、この穴をかなり正面から塞ぎました。内部セッションは結果を返すか、作業を続ける必要があります。別のAIへ依頼した結果は、依頼元の会話へ一度だけ戻る設計になりました。
私がこの更新で見るべきだと思うのは、新しいモデルの追加より「仕事の受け渡しに受領証が付いた」ことです。
何が変わったのか
公式リリースでは、あるエージェントが別のエージェントへ作業を頼んだ場合、結果を元の依頼者へ戻すと説明されています。すぐ終わればその場で返し、時間がかかれば完了後に一度だけ届けます。戻し先は、依頼時の利用者と現在のセッション状態を照合します。
従来のように、内部セッションがNO_REPLYで静かに終わる動きは使えません。REPLY_SKIPやANNOUNCE_SKIPで返答を消す仕組みも、廃止された自動往復では効かなくなりました。追加の会話や外部チャンネルへの送信は、明示的なフォローアップかメッセージ呼び出しに切り替える必要があります。
これは単なる通知改善ではありません。「依頼」「実行」「結果回収」の3点が同じ会話に結び付くようになった、という変更です。
中小企業の業務では何が変わるか
たとえば、営業担当が「昨日届いた問い合わせを調べ、会社情報と優先度を付けて」とAIへ頼む場面を考えます。入口のAIは調査を別のAIへ委譲し、さらに社内データの照合を別の処理へ回すかもしれません。
最終結果が元の会話へ戻らなければ、依頼者には何も見えません。管理側では処理済みでも、人間側では未完了です。この食い違いは、件数が増えるほど発見しにくくなります。
2026.9.8以降は、内部作業が無言で完了する前提をやめられます。結果を元の依頼へ戻す。まだ終わっていないなら作業中として残す。これだけで、担当者が監視画面とチャットを往復する時間を減らせます。
使いどころは、問い合わせ調査だけではありません。見積の下調べ、請求漏れの確認、会議前の資料集め、商品登録前の情報照合など、「一つの依頼を複数のAIへ分ける仕事」に合います。
更新だけでは直らない部分もある
注意点は、古い自動往復に依存した独自フローです。AI同士が暗黙に会話を続け、最後だけ外部へ知らせる設計は、そのままでは挙動が変わる可能性があります。公式文書も、追加会話やチャンネル配信を明示的な呼び出しへ移すよう求めています。
グループチャットの無言設定は残りますが、直接会話と内部セッションの無言設定はDoctorの移行対象です。つまり、「通知を減らすために内部結果も黙らせる」という設定は分離して考える必要があります。人に見せる通知量は絞っても、内部の完了記録まで消してはいけません。
もう一つ、結果が一度戻ることは、内容の正しさを保証しません。誤った調査結果でも配送自体は成功します。受け渡しの信頼性と、成果物の品質は別の検査です。
設定変更中の仕事をどう扱うか
今回の更新では、接続ポリシーの再読み込み中でも、すでに受理した仕事を継続できるようになりました。利用者のアクセス権が有効なら、接続を張り直した後も処理を続けます。
ただし、権限の取り消しや認証方式の変更まで無視するわけではありません。IDの範囲、プロキシの許可、ブラウザの接続元、認証情報などが無効になれば、該当作業はキャンセルされます。認証方式や待受設定の変更には再起動も必要です。
この境界は妥当です。設定を触るたびに受理済みの仕事が落ちるのは困りますが、権限を消した後までAIが走り続ける方が危険です。「作業継続」と「アクセス失効」を分けた点は、本番運用に向いています。
導入判断は限定GO
私なら、全面更新の前に一つの委譲フローだけで試します。対象は、結果を人がすぐ確認でき、失敗しても顧客送信や金銭処理へ進まない仕事がよいでしょう。
- 親AIから子AIへ依頼を送り、結果が元の会話へ一度だけ戻るか確認する
- 処理中に接続ポリシーを再読み込みし、受理済みの仕事が継続するかを見る
- 権限を取り消した場合は、対象処理が止まるか確かめる
- 同じ結果が二重配送されず、監査ログと会話の内容が一致するか照合する
合格条件は、10回の試行で結果の未着と二重配送がゼロ、権限失効後の継続もゼロ。内容の正確性は別のチェック項目にします。ここを混ぜると、配送不良なのか回答品質の問題なのか切り分けられません。
失敗したら更新を戻すのではなく、まず古いNO_REPLY、REPLY_SKIP、ANNOUNCE_SKIPへの依存を探します。独自フローが暗黙の往復を前提にしているなら、明示的な呼び出しへ直してから再試験します。
運用記録に残す項目
試験の記録は、成功・失敗だけでは足りません。依頼元セッション、委譲先、受付時刻、完了時刻、結果が戻った時刻、配送回数、権限状態を一行で追えるようにします。内容の採点は別欄です。
結果が返らなかった場合は、子AIの実行失敗と配送失敗を分けます。子AIが成果物を作っているのに親AIへ戻らなければ配送の問題。成果物自体がなければ実行側の問題です。ここを一緒にすると、再実行で直ったように見えて原因が残ります。
二重配送も同じです。二つの結果が届いたとき、処理が二重実行されたのか、一つの結果が二度送られたのかを確認します。請求書作成や顧客連絡へつながるフローでは、この違いが事故の大きさを左右します。
本番へ進めるなら、結果が届かなかった時だけ人へ通知し、正常完了は翌朝の一覧へ回す設計が扱いやすいでしょう。人の通知を減らしても、内部の受領記録は残します。静かな運用と、記録の欠落は別物です。
担当者の判断も決めておきます。未着なら再送の前に実行状態を確認し、二重配送なら後続処理を止める。権限失効による停止は障害ではなく、意図した安全動作として記録します。これで夜間の自動処理でも、朝に何を確認すべきかが分かります。最初の一週間は自動再送を切り、人が原因を分類してから再開する方が安全です。判定を曖昧にしないためです。
AIへの委譲は「返ってくる」までが仕事
AIエージェントの評価は、難しい仕事を解けるかに偏りがちです。でも会社で使うなら、依頼した場所へ結果が戻り、誰が受け取ったかを追える方が先です。
OpenClaw 2026.9.8は、その当たり前を実装側で強めました。AIを増やす前に、仕事の入口と結果の戻り先を一本につなぐ。今回の更新は、その確認に使えます。