2026 OpenClaw マルチ Agent スケジューリング実践：`sessions_spawn` runtime=acp vs subagent 決定マトリクス、streamTo 誤設定トリアージと ACP 1008 ハンドシェイク失敗 Runbook

マルチ Agent スケジューリングで最も多い六つの誤判断（runtime を変える前に整理）

1. デフォルト runtime=acp なのに ACP bridge が未整備：メインチャネルは会話できるが spawn すると ACP_TURN_FAILED——原因は acpx 未登録または queue owner オフラインであり、モデルクォータではありません。
2. runtime=subagent に streamTo / resumeSessionId を入れる：これらは ACP セッション継続専用です。subagent は Gateway 内蔵 RPC を通るため、誤設定はパラメータ無効またはサイレントにフィールド破棄となり、「サブ Agent がコンテキストを受け取っていない」ように見えます。
3. 1008 をすべて Docker ペアリング問題とみなす：Compose シナリオはtrustedProxies 専記事を参照；ローカル acp パスの 1008 は handshake バージョンまたは bridge 競合が多いです。
4. アップグレード後 reload せず spawn をテスト：CLI は新版、Gateway は旧プロセスのまま——acp と subagent のスタックが分裂します。先に受け入れラダーを揃えてからスケジューリングを試してください。
5. Windows で acpx 起動プローブを無視：provider 拡張が起動を遅らせると、bridge 準備前に ACP ハンドシェイクが走り、ログに invalid handshake が出ます。OPENCLAW_ACPX_RUNTIME_STARTUP_PROBE で延長またはリトライしてください。
6. Completions と Responses API を混在させ streamTo 自動入力を確認しない：2026 ルーティング層は Responses セッションで streamTo 先を推論しますが、Completions パスではしません——spawn 障害と誤認しやすく、実際は API 形態と runtime の不一致です。

2026 上流は sessions_spawn を二つの排他的ランタイムに明確化しました：runtime=acp は ACP bridge 経由で外部 acpx プロセスと通信し、streamTo でサブ Agent 出力をメインセッション UI に戻せます；runtime=subagent は Gateway プロセス内で軽量サブエージェントを起動し、レイテンシが低く acpx 非依存ですが、ACP 専用の継続フィールドは非対応です。runtime 誤選択に誤フィールドを重ねると、on-call で最も時間を消費する「偽の複雑さ」になります——まずパスを揃え、モデルとツール allowlist はその後（tools.profile トリアージ参照）。

実務では各 spawn 呼び出しをスケジューリング契約として記録することをおすすめします。契約には runtime、UI 戻しの要否、メインセッションが Completions か Responses か、失敗時のフォールバック（subagent またはロールバック）を明記してください。この契約がないと、「昨日は spawn できたのに今日は不可」という事象の説明が困難になります——変更は Gateway プロセスよりテンプレートフィールドや API 形態に起きることが多いからです。

runtime=acp vs runtime=subagent：どちらのスタックをいつ使うか

選定の覚え方：UI 戻し、既存 ACP セッション継続、Cursor/IDE 側 acpx との整合が必要 → acp；Gateway 内完結、低依存、acp が現時点で使えない → subagent。下表は本番で最も多い四つのタスク形態です（網羅ではありませんが、チケットの 80% をカバーします）：

streamTo / resumeSessionId：acp 専用の誤設定トリアージ

コミュニティで多い「spawn パラメータは正しそうだがサブ Agent が空返答」は、フィールドと runtime の交差汚染が原因です。Gateway は subagent パスで ACP 専用フィールドを剥離または拒否します。メイン Agent テンプレートが Completions 例から streamTo: "main" をコピーし、実際の呼び出しが runtime=subagent だと、ログは汎用 RPC error のみで「フィールド無効」とは出ません——呼び出し JSON を照合してください。

runtime=acp では resumeSessionId が既存 acpx セッション継続に使われ（同一スレッドで複数 spawn など）、streamTo がサブ Agent トークンストリームをメイン Control UI または指定 channel 描画先へ向けます。2026 Responses API ルーティングは一部設定で streamTo を自動推論します（メインセッションが Responses 形態にバインドされ未明示入力の場合）；Completions 形態では自動入力されません——Responses 環境から Completions へ移行し spawn テンプレートを変えないと、「以前は戻せたのに今はサブ Agent が裏で完走する」回帰が起きます。これは upgrade 無関係で、API 形態 + runtime の組み合わせ問題です。

トリアージではフィールド剥離実験が有効です：失敗した呼び出し JSON を複製し、streamTo と resumeSessionId を除いて runtime=subagent で再試行してください。subagent が即成功すれば、元の障害は ACP パスまたは誤設定とほぼ断定でき、task 内容やモデル能力の問題ではありません。失敗が続く場合は pairing、Token、またはツール面へ。本実験は Runbook 第 4 步に記載し、on-call が acp ログで空転しないようにしてください。

ACP ハンドシェイク失敗トリアージ：ACP_TURN_FAILED、1008、queue owner

runtime=acp が失敗しメインチャットは正常な場合、ログ指紋で分流してください——「Gateway が完全無応答」と混同しないでください（後者はチャネル/モデル専記事へ）。

Windows と OPENCLAW_ACPX_RUNTIME_STARTUP_PROBE

Windows では provider 拡張と Defender スキャンが acpx コールドスタートを数秒以上遅らせることがあります。bridge 準備前に spawn すると ACP_TURN_FAILED または invalid handshake に見えます。環境変数 OPENCLAW_ACPX_RUNTIME_STARTUP_PROBE=1（意味はインストール版ドキュメント準拠）を設定すると、Gateway が初回 spawn 前に acpx ヘルスプローブを追加で待ち、競合による偽失敗率を下げられます。それでも失敗する場合は、同一マシン subagent 最小タスクで Gateway スケジューリングスタック自体が健全か確認し、acpx インストール/権限問題を切り分けてください——Windows 起動遅延を「OpenClaw バージョンをロールバック必須」と誤判断しないためです。

アップグレード護航との分担：護航記事は「バージョン移行後の probe/ACP 全サイト回帰」；本記事は「バージョン安定後、spawn スケジューリング層の誤選択または handshake 偶発失敗」。連携時は upgrade ラダー通過を先に確認し、本記事の runtime マトリクスへ——さもないと split-brain を streamTo 誤設定と誤判断します。

acp 障害時は先に subagent：修復継続 vs ピン留め vs フォールバックの決定マトリクス

七步「選定—プローブ—spawn—トリアージ—フォールバック—記録」Runbook

1. 呼び出し JSON を固定：runtime、streamTo / resumeSessionId の有無、メインセッション API 形態（Completions vs Responses）を記録。
2. Gateway ベースライン：openclaw gateway status + gateway probe；アップグレード後は必ず単回 reload（アップグレード護航参照）。
3. 選定セルフチェック：UI 戻し必要 → acp + streamTo；バックグラウンド → subagent、ACP フィールド除去。
4. 最小 spawn プローブ：先に subagent で読み取り専用一文；通過すればスケジューリングスタック正常、失敗なら pairing/Token。
5. acp 专项：acpx プロセスと bridge 確認；Windows で OPENCLAW_ACPX_RUNTIME_STARTUP_PROBE；1008 / queue owner ログ取得。
6. フォールバックまたはロールバック：acp 二回連続失敗 → チケットに subagent フォールバック；両パス全断 → digest ロールバック。
7. クローズ指標：spawn 成功率、フォールバック比率、MTTR を記録；内部 runtime 選定メモ更新。

変更チケットに書く三つの定量指標

• spawn 成功率（runtime 別）：単位時間の sessions_spawn 成功回数 / 総呼び出し；acp 桶が 95% 未満で subagent 桶が正常なら、モデル変更より bridge 修復を優先。
• acp→subagent フォールバック比率：UI 戻し必須タスクを長期フォールバック依存すべきではありません；一週間連続で >30% のチケットが subagent 代替なら、バージョンピンまたはトポロジ移行を推進。
• streamTo 誤設定イベント数：runtime=subagent 呼び出しに streamTo/resumeSessionId が残る監査カウント；本番目標 0（アプリ層 lint またはテンプレートレビュー）。

ノート PC Gateway で acpx、蓋閉じスリープ、複数 provider プラグインを混在させると、spawn 失敗が「OpenClaw 不安定」と誤記録されがちです。より安定した方法は、権威 Gateway と acpx を常時電源のリモート Macに同居させ、ローカルは SSH で Control UI を転送のみ——spawn と probe を同一ノードで受け入れ、ログタイムラインを揃えます。

まとめ：runtime 選定はスケジューリング契約であり、調参の玄学ではない

メイン Agent の prompt だけを繰り返し変更し、runtime と streamTo の整合を確認しないと、ACP ハンドシェイク問題が「マルチ Agent 不可用」の錯覚に拡大します。逆に acp/subagent 決定マトリクス、誤設定トリアージ、subagent フォールバックを runbook に書けば、on-call を一晩の盲試から、プローブ・フォールバック・指標のある分単位インシデントに圧縮できます。

Windows ノートまたは Docker 分離コンテナトポロジで acp bridge を無理に維持する場合、三つの隐性コストを受け入れてください：起動競合による偽 1008、Completions/Responses と streamTo 自動入力の不一致、subagent と acp 故障面の重なりによる調査半径の拡大。7×24、spawn をチケット化、acp と subagent を切替可能な本番 Gateway には、MACCOME Mac mini（M4 / M4 Pro）と六地域柔軟リースが、蓋閉じノートで queue owner と格闘するより総コストが低いことが多いです。公開プランは多地域ノード・リースガイドを参照し、SSH 常駐 Runbookでトポロジを連結してください。