TL;DR
- 「queen agent が worker agent を呼ぶ mesh」は技術的に不可能。Anthropic 公式 doc が
Subagents cannot spawn other subagentsと明文化している。 - 純粋 mesh のかわりに Queen-Mediated 2-Round Dispatch を採用。worker が
🔁 Escalation Hintを出力し、main context の queen skill が hint を集めて 2nd-wave dispatch する形。 - 発見の経路は Plan agent を 3 体・段階起動。1 体目は user 構想のまま、2 体目が C1 制約を発見、3 体目が 5 framework と比較。
- 長期予防として refs/subagent-constraints.md（C1〜C9 の SSOT）+ Stage 7 gatekeeper worker + design-notes の三点セットを構築。
- 「親切設計の reminder」は罠になる。Stop hook の
wrap-up を実行してくださいは邪魔と判明、削除して C9 として運用方針化した。
multi-agent な構造を Claude Code の plugin で組みたかった。素朴に考えると、queen を agent にしておけば、queen が必要に応じて worker agent を呼べるはずだと思う。queen を hub に、worker が網目状に繋がる mesh。Roo Code のような OSS にも「Queen-Mesh」を謳う実装はある。
だけど Anthropic 公式 doc に明確な制約があった。subagent からは subagent を呼べない。Task tool そのものが subagent の tools 配列から除外されている。私の構想は runtime レベルで成立しない。
その壁にぶつかってから現実解にたどり着くまで、Plan agent を 3 体段階起動して周辺フレームワークと比較した。本記事はその記録。
intro前史出発点 — Queen-Mesh をやりたかった
もとは keito-work-iroha という個人 plugin の話だった。Queen orchestrator が入力を判定して、複数の worker (task-orchestrator / doc-reviewer / comms-translator) を Task tool で並列 dispatch する形は既に動いていた。Pure hierarchical な構成。
ただ、案件によっては worker 同士の判断連鎖が要る。たとえば doc-reviewer が文書をレビューしている途中で「これは規制水準の話を含むから framework-strategist の判断も要るな」と気づくケース。
そのとき worker が自分で他 worker を呼べると嬉しい。そう思った。
「queen を Proxy ライクに使って、エージェント群が各々の判断で他の Agent も呼びうる Queen-Mesh Hybrid」
これが本人の言葉。要するに hierarchical と mesh の中間で、queen が入口を担いつつ worker 同士は限定的に直接 dispatch できる構造。
📝 当初の構想を具体化したスケッチ
- Queen = supervisor with delegation routing（LangGraph 用語）かつ proxy with allowed_agents whitelist（CrewAI 用語）
- Worker = constrained peer handoff（OpenAI Swarm の handoff を whitelist で絞った形）
- Hybrid = アカデミックには "Hierarchical supervision with controlled lateral delegation"
言葉だけ並べると production-grade に見える。だけど Claude Code 上で動くかは別問題だった。
01first wavePlan agent × 3 体・段階起動
plan mode で Plan agent を 1 体起動した。user 構想（queen を agent 化、skill は薄いラッパー）を前提に実装計画を立てさせる。15 分後、agent は妥当な実装計画を返してきた。
だけど本人から待ったがかかる。
あ、ごめんでも上記は俺の思いつきだから、世の中的なベストプラクティス調べたうえで決定がいいと思う。
これが大きかった。思いつきを「実装可能」と確かめずに走らせない。Plan agent #2 を起動して、Queen-Mesh Hybrid という構想を multi-agent literature と公式 doc に照らし合わせる調査をさせる。さらに Plan agent #3 で Ruflo の思想抽出と、LangGraph / CrewAI / OpenAI Swarm / AutoGen / Anthropic 公式の 5 framework 比較をさせた。
段階起動だから、後の agent が前の agent の結論を踏まえて補強できる。並列起動だと結論が独立に出てきて統合が面倒だった。
🔍 Plan agent × 3 体に渡したそれぞれの prompt 要旨
- #1（古い案）: 「queen を agent 化、skill は薄いラッパーで agent を起動するだけ」を前提に実装計画を立てる
- #2（ベストプラクティス調査）: 「Queen-Mesh Hybrid」を multi-agent literature の語彙で再定義 + Claude Code 公式 doc + LangGraph / CrewAI / Swarm / AutoGen / Anthropic blog で裏取り
- #3（Ruflo 思想抽出）: Ruflo の実装は粗大ごみ前提で 思想だけ抽出。「Queen-led hierarchy + swarm consensus + shared semantic memory」の三軸と OSS framework の比較表化
Plan mode の Phase 2 で「up to 3 Plan agents」と書いてあるが、最大値の活用を default にしてよかった。1 体目だけだと user 構想の前提を疑えない。
02the wall公式ドキュメント明文 — Subagents cannot spawn other subagents
Plan agent #2 が決定打を持ってきた。Anthropic の Create custom subagents に、はっきり書いてある。
Subagents cannot spawn other subagents. If your workflow requires nested delegation, use Skills or chain subagents from the main conversation.
これで純粋 mesh は終わった。subagent の tools list には Agent / Task が含まれない。意図的に除外されている。Issue #4182 でも closed 扱いで対応予定なし。
Subagent から別 Subagent を呼ぶ設計は、どれだけきれいに見えても動かない。claude -p を Bash 経由で呼ぶ workaround は「No visibility / 別 rate limit / context 非共有」で公式非推奨。
🐛 私の元構想がここで死んだ理由
「queen agent」を作っても、その queen agent は Task tool を持てない。だから worker agent を呼べない。queen を agent 化したら、queen がそもそも何もできなくなる。skill のまま使うのが正解だった。
これは Claude Code の plugin runtime に依存した制約。理屈で考えればコンテキスト管理やコスト爆発の予防策として理解できる。ただ、知らずに設計に走ると 1 サイクル無駄になる。
03decision三差路 — 純 mesh / Pseudo-Mesh / Pure Hierarchical
選択肢は三つに整理できた。看板で見る。
04solution採用した現実解 — Queen-Mediated 2-Round Dispatch
worker 同士で判断を連鎖させたい case では Pseudo-Mesh を採用した。仕組みは単純。worker が「自分の焦点を超える論点がある」と気づいたら出力フォーマットに 🔁 Escalation Hint セクションを書く。queen がそれを集めて 2nd-wave dispatch する。
worker 同士は直接呼び合わない。あくまで queen を経由する。だけど worker から見た振る舞いとしては mesh 相当の柔軟性がある。
📝 worker 側の Escalation Hint フォーマット
### 🔁 Escalation Hint (optional)
本 worker の焦点を超える論点があり、別 worker の判断が要ると気づいた場合のみ記入:
- needs_followup: [<worker-name>] 例: [framework-strategist], [comms-translator]
- reason: <なぜその worker が必要か 1 行>
worker は判断しても、直接 dispatch しない。hint を出すだけ。dispatch するかどうかは queen が決める。
⚙️ queen 側の 2-Round Dispatch ロジック
- Step 3: 1st-wave parallel dispatch。worker prompt に scratchpad パスと mesh_depth=1 を渡す
- Step 3.5: 1st-wave 完了後、各 worker の
🔁 Escalation Hintを抽出 → 1st-wave 既出 worker を除外 → 2nd-wave 構成 - Step 4: 2nd-wave dispatch（必要時のみ）。mesh_depth=2。2nd-wave で新しい hint が出ても 無視（ハードキャップ）
- Step 5: 1st + 2nd wave の全 worker 出力を集約。重複は scratchpad 経由で dedup
無限ループは起きない。mesh_depth=2 を超えたら hint を捨てる。実用上 2 段で大抵の判断連鎖は捌ける。
worker 間の共有 state — scratchpad
2nd-wave で起動された worker は、1st-wave の指摘を知らずに同じことを指摘してしまうかもしれない。それを防ぐため ~/.claude/.session_state/<plugin>-<session-id>/scratchpad.md を全 worker が読み書きする。
仕組みは単純なファイル。worker は自分のセクションに ## <worker-name> @ <ts> ヘッダで append する。読むときも普通の Read tool で開ける。file は素朴で強い。
05codifyC1〜C9 — 制約を SSOT 化する
同じ壁にまた未来でぶつかる。それは確実。だから refs に集約して名前を付けた。claude-code/global/shared/refs/subagent-constraints.md に C1 から C9 まで番号を振って一箇所にまとめた。
| 番号 | 制約 | 影響 |
|---|---|---|
| C1 | subagent → subagent dispatch 不可 | 純 mesh 不可能、回避策で迂回 |
| C2 | subagent → skill は可能（skills: frontmatter で preload） | worker の専門性強化に使える |
| C3 | skill → subagent は可能（main context にいるから） | queen が skill の根拠 |
| C4 | Background subagent は deferred tools を auto-deny | WebSearch を呼ぶ subagent は foreground 必須 |
| C5 | context: fork skill から subagent 不可 | fork は further fork を生めない |
| C6 | skill / agent はセッション開始時ロード、編集は再起動 or /agents で反映 | 同セッション内 dogfood の Catch-22 |
| C7 | project scope MCP は subagent に継承されない | global MCP に格上げか Bash CLI |
| C8 | subagent の tools 指定なしは main 継承、ただし Agent/Task は除外 | tools 設定の前提 |
| C9 | Stop hook で wrap-up / review を auto-prompt しない（運用方針） | 毎セッション邪魔 reminder の罠 |
🔍 C6 の実例 — Stage 7 自身を呼べない Catch-22
この plugin 改修と同じセッションで stage-7-subagent-design という gatekeeper worker を新設した。「subagent 設計の C1-C8 違反を検出する」のが役目。
では Stage 7 を自分の commit に対して dogfood してみよう、と思って起動したら Agent type 'keito-dev-iroha:stage-7-subagent-design' not found エラーが返ってきた。available agents 一覧に stage-7 が居ない。
原因は C6 だった。cache に install されても、現セッションの agent registry には セッション開始時にロードされた agent だけが並ぶ。新規追加した agent は次セッションから使える。
つまり Stage 7 を作ったセッションでは Stage 7 を呼べない。自分が作った道具を、作った直後には使えない。回避策は /agents コマンドで session reload、または素直に次セッションを待つ。
06prevention構造的予防 — refs + gatekeeper + design-notes の三点セット
制約を SSOT 化しても、人間が読まないと意味がない。だから三層で守る。
（C1-C9 の正本）
（diff から違反検出）
（なぜそう決めたか）
ぶつからない予防
refs だけあっても読まれないと機能しない。gatekeeper だけあっても判定根拠が薄いと信頼されない。design-notes だけあっても自動 review されないと埋もれる。三点セットで初めて構造的に予防になる。
📝 三点セットの具体ファイル配置
claude-code/global/shared/refs/subagent-constraints.md— C1-C9 SSOT。3 plugin が参照plugins/keito-dev-iroha/agents/stage-7-subagent-design.md— diff に C1-C9 違反がないか機械的に検出する workerplugins/keito-dev-iroha/references/design-notes/2026-05-26_*.md— 「Pure Hierarchical 維持の根拠」「Stage 7 導入経緯」を判断経緯として保存plugins/keito-work-iroha/references/design-notes/2026-05-26_queen-form-finalized.md— 「2-Round Dispatch 採用の経緯」
design-notes は retro_events と棲み分けしている。retro = 結果ログ、design-notes = 判断経緯。同じ事象でも別軸で記録すると後参照価値が高い。
07side quest反省 — 親切設計の reminder は罠だった
この記事を書くきっかけになった作業の最後で、もう一つ反省ポイントが出た。~/.claude/settings.json の Stop hook で "💡 セッション終了。学びを記録するには /generic-hermes:wrap-up を実行してください" という systemMessage を出していた。
これが本人から「邪魔」「無意味に思えてきている」と却下された。pull 型のスキル（/work-complete）が既に整っているのに、push 型の reminder が毎回出る。最初は親切のつもりでも、慣れた後は認知ノイズ以外の何ものでもない。
shared/CLAUDE.md の引き算思想に「これが無いと意味が壊れるか」を hook 設計にも当てたら、壊れなかった。削除が正解。
削除だけでは将来また誰かが復活させる可能性がある。だから C9 として運用方針に組み込み、3 plugin の hooks/stop-hook.example.json に DEPRECATED マークと警告コメントを入れた。短期的に時間を 15 分余計に使ったが、長期的に「同じ罠に踏み込まない」予防が手に入った。
EOFあとがき得たもの
主に三つ。
一つ目、思いつき設計を実装に走らせる前に、世間的なベストプラクティスを必ず照合すること。Plan agent を 1 体だけ起動して満足するのではなく、段階起動で前提を疑える agent を後段に置く。これは Plan mode の使い方が変わった瞬間だった。
二つ目、Claude Code subagent の制約は思っていたよりはっきりしている。mesh をやりたい欲求は理解できるけど、Claude Code 単体では成立しない。multica 等 Issue ベースの別 framework に寄せるか、Anthropic の experimental Agent Teams（CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1）が stable 化するまで待つか、現実解の Queen-Mediated 2-Round Dispatch で済ませるか。
三つ目、設計判断は記録しないと再蒸し返しが起きる。retro_events は短文・反復パターン用、design-notes は長文・個別判断用と棲み分けるとどちらも生きる。今回の作業も、半年後の自分がこの記事を読んで「なぜ mesh を諦めたか」がすぐ分かるようにしたい。
同じ壁にぶつかった人の何かに役立てば。
後日2026-05-27 追記Mesh 概念ごと廃止する案
TL;DR
- 5/26 では
mesh_depth=2ハードキャップで止めていた。これは mesh という構造を抽象レイヤに残した前提 での解だった。 - 1 日経って気付いた: mesh 概念ごと廃止し、main が context state を保持する Hub-and-Spoke / StateGraph 駆動にすると、表現力を失わずに実装は単純化できる。
- 「制約の前提を疑うと、その制約自体が消えることがある」という学び。
記事公開後の翌日、本人が「queen の dispatch ロジックをもう少し練り上げてもいい」と言い出した。「mesh みたいな概念はなく、main がすべてのコンテキストと結論を持ちつつ、段階的処理で疑似 mesh を実現できる」 という方向に話が進んで、ここまで来てしまった。1 日違っていれば 5/26 の記事に最初から書けていたが、思考は時間順にしか進まないので追記として残す。
抽象フロー
[User Input] ↓ [Butler agent] ← 前捌き: どのパターンで処理するか判断 ↓ パターン選択 [Queen skill] ← phase 配列を実行する orchestrator（薄い・仮想存在） ↓ phase 実行 [Workers] ← stateless 関数（input → output） ↓ 並列出力 [Synthesizer] ← 集約・dedup・矛盾検出 ↓ [Gate] ← 人間 or LLM 判断点 ↓ [Queen rollup → User]
各 phase 間で main プロセス（Queen skill 内部）が context state を保持し、次 phase に渡す。Worker は他 worker を一切知らず、main から渡された input だけを見て output を返す純粋関数になる。
Mesh と StateGraph の対比
| 観点 | Mesh モデル（5/26） | StateGraph 駆動（5/27 追記） |
|---|---|---|
| State 保持 | 分散（各 worker / scratchpad） | main の context state（SSOT） |
| Worker の性質 | mesh 内のピア（他を知る） | stateless 関数（input → output） |
| 通信 | worker 同士で呼び合う | main hub だけと通信 |
| 複雑度 | O(N²) 関係 | O(N) 関係 |
| Depth Cap | mesh_depth=2 ハードキャップ | 不要（stopping criteria 駆動） |
| Replay | 順序依存で困難 | 同じ state + phase 配列で再現可 |
Redux / Elm Architecture と同型: State = main の context / Action = phase 実行 / Reducer = synthesizer or main の state 更新。純粋関数の合成で表現できるので、各 phase は単体テスト可能・再現可能になる。
疑似 Mesh の表現例
Mesh で表現したいトポロジー（例: A↔B / C↔D の交差依存・サイクル）も、phase 配列の DAG + cycle で同等表現できる。
P1: parallel [A, B] P2: synthesizer (input: A.out, B.out) P3: parallel [C(input=P2), D(input=P2)] P4: synthesizer (input: C.out, D.out) P5: queen rollup
フィードバックループも cycle phase で:
P1: A P2: B(input=P1) G1: gate (synthesizer judge: A の修正必要?) P3: A(input=P2) if G1=="revise" ← サイクル P4: queen rollup
cycle は stopping criteria で制御する: cycle_count <= N / 同じ pattern_class が M 回出たら止める / 全 worker PASS で止める。 mesh_depth のような構造的 cap は不要になる。
Butler と Pattern Library
Queen は 「仮想存在・薄い skill」 のまま、事前定義されたパターンライブラリから Butler agent が選ぶ構造にする。
- Butler（前捌き agent）: 入力を見てパターン選択。執事のように客の意図を汲んで適切なものを差し出す
- Pattern Library: md で 5-10 個。
doc-review/meeting-post/framework-decision-seq/send-precheck等を事前定義 - Queen: 選ばれたパターン定義に従って phase 配列を実行する薄い orchestrator
- Synthesizer（domain-specific 複数）: 並列 worker の出力を集約・dedup・矛盾検出
- Gate: phase 間の判断点（human / llm / condition の 3 type）。
draft:answer-gui連携で人間判断 SOP 化
なぜ「mesh 概念ごと廃止」が引き算なのか
Mesh は実装パターン、Hub-and-Spoke も実装パターン。一方、段階的処理（phase 配列）は より抽象的な計算モデル で、両方を包含する。
ここで「mesh 概念」を あってもなくても良い と評価できる: 表現力は失わない（DAG + cycle で同等）、実装は単純化される、main が SSOT を持つので debug / replay が容易。shared/CLAUDE.md の引き算思想に従えば、あってもなくても良いものは、ない方がいい。
制約は「障害」ではなく「設計思想の合図」
5/26 では C1 制約（subagent が subagent を呼べない）を 「諦めの起点」 として扱った。だが Hub-and-Spoke / StateGraph 駆動に移行すると、そもそも worker が worker を呼ぶ必要がなく、C1 制約はむしろ自然な設計境界 として再評価できる。
Anthropic がこの制約を入れた理由は、おそらく「worker mesh は危険で不要、Queen 集約型を推奨する」という思想の表現だったのかもしれない。制約は 「障害」 ではなく 「設計思想の合図」 として読むほうが、結果的に綺麗な解にたどり着く。
具体実装は別案件で凍結中
Butler agent 設計 / Pattern Library 整備 / Synthesizer 複数 / Gate 機構の具体実装は、別途 _draft/2026-05-27_queen設計改良/ に PLAN/SPEC/TODO/KNOWLEDGE を起こして凍結した。実装着手は当面後（自作 PJ/タスク管理ツール構想とも合流の可能性あり）。本記事ではここまでが 思想として残しておきたい部分。