1. 課題の整理：サブセッションは「チャットを増やす」ことではない
（1）身分と権限：コンテナ内 UID/GID と、ホスト側で編集した設定ファイルの所有者が一致しないと、子プロセスが openclaw.json を開けず EACCES になります。Gateway プロセスは動いているのに spawn だけが連続失敗するパターンです。（2）ツール集合の契約：minimal や messaging プロファイルは runtime／filesystem 系ツールを意図的に外します。Telegram 等で「Tool not found」と出ても、最初からモデル能力を疑う必要はありません。（3）thinking と無返信：ハートビートや cron が起動する子エージェントで thinking を残すと、モデルによってはユーザー向けテキストが reasoning チャネルに留まり、announce には空文字が届きます。（4）フォールバックの書き戻し：プライマリモデルが一時的に落ちたあと、フォールバックが設定ファイルに書き込まれ続け、復旧後も永遠に予備モデルだけが選ばれることがあります。手動で設定を戻し、セッションスナップショットを整理する必要があります。
2. 症状マトリクス：分類してから手を動かす
| 兆候 | まず疑う点 | 最小確認 |
|---|---|---|
| spawn ログに EACCES | 設定の所有者・権限 | コンテナ内 UID、バインドマウントが読み取り専用か |
| ツール名が UI で無効／エラー | tools.profile が狭すぎる | 一時的に coding または full に切り替えて再現が消えるか |
| 定期ジョブは成功だがチャネルに何も出ない | thinking または空の announce | 該当ジョブで thinking を off、announce の文字列長を確認 |
| プライマリが突然ずっと予備のまま | fallback が設定へ書き戻された | openclaw.json をバックアップや Git と diff |
3. 五つのステップ：再現から定着へ
ステップ1：再現経路を固定する——同一チャネル、同一ルーティング規則、同一モデルで、「たまにしか起きない」変因を除きます。ステップ2：実効 UID/GID と設定の実パスを記録する——spawn 入口で、思い込みのパスではなく実際に開こうとしているパスをログに残します。ステップ3：必要なツールグループを白名簿化する——profile ドキュメントからチェックリストを作り、いきなり full で隠すのをやめます。ステップ4：定期ジョブ用に設定断片を分ける——thinking off、出力長の上限、announce テンプレートを固定します。ステップ5：リモート Mac または Docker で冷起動テスト——Gateway 再起動後の最初の spawn が成功するか。ホットなセッションだけ緑だと本番では落ちます。
4. 参照チェック（運用向け）
- コンテナでは設定ディレクトリをプロセスユーザーと所有者が一致するようマウントするか、エントリポイントで
chownする。「ホスト root が編集、コンテナ UID 1000 が読む」ずれを避けます。 - 無人ジョブでは thinking を off（「低」ではなく）にし、変更前後で空出力率をログ比較します。
- フェイルオーバー試験の前に、最後に安定していた
openclaw.jsonのコピーを必ず残し、プライマリ復帰のリハーサルを一度行います。
5. いつリモート Mac へ役割分離するか
| 信号 | 提案 |
|---|---|
| 重い GPU／動画作業と多 spawn を同一ノートで兼務 | ゲートウェイと推論をリモートへ。端末は薄いクライアントに |
| 固定の公開入口と 7×24 spawn が必要 | 専用ノード＋監視。ノートのスリープで途切れないようにする |
| チームで同一 Gateway とスキルディレクトリを共有 | クォータと監査のため別マシンに。個人環境のドリフトを減らす |
6. FAQ
問：sessions_spawn と MCP は衝突しますか？本質的には別物ですが、コンテキストとツール schema の合計トークンは積み上がります。複数サブエージェントを同時に動かすときは Gateway のリロード順も含めて MCP 記事と合わせて読んでください。問：ローカルでは動くのにリモートだけ失敗する？九割はパス・権限・環境変数の差です。問：診断のために full プロファイルを常時運用してよい？切り分け専用にし、本番は最小限のツール面に戻してください。
切り分けでは ① spawn の終了コードと遅延、② 対話と子セッションのツール差分、③ announce の文字列長（0 か否か）をセットで記録します。③ が常に 0 で ① が成功なら thinking／テンプレートを疑います。週 3 回超の非計画対応なら環境固定化を先に検討します。
7. 深掘り：サブエージェントは「運用」の問題である
2026 年時点で OpenClaw 系は単一セッションのデモでは非常に滑らかですが、spawn・ルータ・複数チャネルを足すと、失敗パターンは「モデルの妄言」から「プロセス権限不足・ツール未ロード・出力未配達」へ移ります。従来のマイクロサービスにおける設定ドリフトと同型で、子プロセスが一つ増えるたびに明示的な契約が一層必要になります。個人ノートだけでデバッグしていると「自分の環境では動く」を製品状態と誤認しがちです。
ノート単体運用には限界があります。スリープで長寿命ゲートウェイが途切れたり、ユーザーごとにパスが変わったり、グラフィックスと推論が統合メモリを奪い合ったりします。モデルを差し替えても解決しません。Apple Silicon のリモート Mac は Metal と長時間バックグラウンドの前提に合い、時間課金で spawn トポロジを検証してから固定機を買う判断がしやすいです。重い Gateway／spawn を創作用ノートから切り離し、監査可能で再起動可能な環境を得たい場合、MACGPU のリモート Mac をレンタルする選択は、無限の chown とプロンプト調整より総コストで有利になりがちです。