サブエージェントはルーティングとスコープのメカニズムであり、チームのメタファーではない

説明フィールドはルーティングルールであり、ツールリストが保証である

Claude Code のサブエージェントが機能するのは、二つのメカニズムが一つの markdown ファイルに組み込まれているからだ：仕事を正しい専門家へルーティングする説明と、専門家が自分のレーンから出られないことを保証するツール制限である。Professor Glitch の 2026 年 7 月のガイド『Claude Code Subagents: Turn One AI Into a Whole Team』は、説明を「ルーティングルール」、ツール制限を「その機能」と呼んでいる——まさに Everythink が構築の基盤とする枠組みであり、ここでは the space is the router。

記事の中心的なトレードは正確だ：サブエージェントは冗長な仕事を短い回答に変換するので、約 40,000 トークンの生リサーチが専門家のコンテキストで死に、メイン会話は三段落を受け取る。それはチームのメタファーではない。ルーティングの決断にスコープの保証が続いたものであり、両方とも測定可能だ。[UNIQUE INSIGHT] the-space-is-the-router reframing：チャットボットは答える；AI OS はルーティングする。サブエージェントはそのルーティングの最小単位である——名前付きのレーンに、ガードされたツールセットを備えた。

なぜ過負荷のゼネラリストは劣化するのか

コンテキストの腐敗は測定の問題であり、能力の主張ではない

ソース記事は失敗モードを明確に名指しする：モデルの作業記憶は満たされるにつれて劣化する。150,000 トークンのファイルダンプと古い指示を一つの会話に読み込むと、モデルは見落とし始める——愚かだからではなく、信号が埋もれているからだ。これは私たちが Sisters を Oracle から分離するのと同じ理由である。各 Sister は型付きのパーソナリティ（analyst、contrarian、historian、institutionalist、disruptor）であり、自分のコンテキストで起草する；Oracle は草稿を正規化された ensemble にマージする。もし一つのモデルが各 Sister の生草稿とマージの数学を同時に保持したら、信号は崩壊するだろう。

コンテキストの腐敗は現実であり、測定可能であり、それを修正するメカニズムは隔離である——より大きなウィンドウではない。Everythink の HAI Engine ✅ は 2016 年から生産でこの隔離パターンを運用している。私たちはトークンを買い増してコンテキストの腐敗を解決したのではない。各想像パスをそれ自身のきれいな部屋へルーティングし、圧縮された結果を返すことで解決した。

きれいな引き継ぎが測定隔離メカニズムである

[PERSONAL EXPERIENCE] the engine has run in production since 2016——そして私たちを驚かせた部分は、記事が報告する通り、どの部分が最も重要かということだ。自動化ではない。きれいな引き継ぎだ。Sister が草稿を終えると、Oracle が受け取るのは草稿であり、Sister が噛み砕いた何百ページものソース素材ではない。

その圧縮は測定境界である。それを横切るトークンを数えられる。記事の数字——40,000 トークンの生素材が三段落に縮約——は、Sister から Oracle への引き継ぎと同じ形をしている。「メインコンテキストがきれいに保たれる」というプロパティは、引き継ぎメカニズムが実装され強制されるときに正確に保証される。Theorem 3：プロパティはそのメカニズムが実装され測定しているときに正確に保証される。引き継ぎがメカニズムであり；トークン数が測定である。

説明フィールドはルーティングルールである

「Use proactively」がルーティング述語である

記事は、説明がドキュメントではないことを明示する。それはルーティングルールである：Claude は各サブエージェントの説明を読み、入ってくるタスクをそれらにマッチさせる。「use proactively」のようなフレーズは、Claude に頼まれずともエージェントに手を伸ばさせる。曖昧な説明はエージェントが発火しないことを意味し；鋭い説明はまさに発火すべきときに発火することを意味する。

これは the space is the router であり、単一の prompt の粒度においてである。Everythink では、同じ原則がプラットフォーム全体を構造化する：network は communities を含み、community は rooms を含み、リクエストは何かが応答する前に、その能力を持つ room へルーティングされる。network-to-community-to-room トポロジーは URL 空間として実装されたルーティングルールであり；サブエージェントの説明フィールドは自然言語として実装されたルーティングルールである。

クエリタイプが間違っていればルーティングが検索に勝る

記事が間接的に浮かび上がらせるよくある間違い：人がサブエージェントに手を伸ばすが、実際に必要なのは skill——オンデマンドで現在の会話に読み込まれる繰り返し可能な手順——である。ドキュメントは線を引く：あなたの会話で走る再利用可能なワークフローは skill であり；自分の部屋で行われ要約として戻るべき冗長または制限された仕事はサブエージェントである。サブエージェントが必要だと思っている人のほとんどは skill を必要としている。

メカニズムの読み：クエリタイプはルーティング先と一致しなければならない。skill 型のリクエストをサブエージェントへルーティングすると、隔離コスト——新しいコンテキスト、状況を再説明——を払うが利益はない。サブエージェント型のリクエストを skill へルーティングすると、40,000 トークンの生素材でメインコンテキストを汚染する。

ツール制限が Theorem 3 の保証である

「Nova can't send email」はプロパティであり、ツールリストがそのメカニズムである

記事で最も荷重を担う文は見逃しやすい：「None of them can touch each other's work. Nova can't send email. Quill can't touch a server. That's not a bug I tolerate, it's the design.」それは Theorem 3 の平易な表現である。「Nova cannot send email」というプロパティは、そのメカニズムが実装され測定しているときに正確に保証される——そしてメカニズムは frontmatter のツールリストである。メールツールが Nova の tools: フィールドになければ、プロパティは成り立つ。あれば、成り立たない。中間状態はない。「Nova should not send email」というポリシーは望みであり；メール API を省いたツールリストは保証である。違いは、メカニズムが境界で測定できるかどうかである。

スコープは境界であり、感情ではない

Everythink は同じ境界規律をモジュール表面に適用する。Social ✅、Campaigns ✅、Whitelabel Network ✅ はスコープ付き権限を持つ Production モジュールである——コミュニティモデレータは Eye Key を mint できず、キャンペーン編集者は network のブランディングを書き換えられない。なぜなら権限スコープがアクションをデータベースに届く前にルーティングするからだ。Matchmaking ⚠️、Marketplace ⚠️、Calendar ⚠️ は Partial である——スコープメカニズムは存在するが、まだ生産トラフィックで測定されている。Wallet & Token 🔵、Super App 🔵、Community Credit 🔵 は Roadmap である——スコープは仕様化されているが、メカニズムは未実装であり、そうなるまで保証を主張しない。

Honest Architect の規則：状態を昇格させない。Roadmap モジュールは主張によって Production にはならない。「Community Credit balances are non-inflatable」というプロパティは、その会計メカニズムが実装され測定しているときに正確に保証される——いかなる結果も約束される前に Howey 審査に服する。それまでは 🔵 マークを帯びる。

workers-plus-reviewer パターンは ensemble であり、組織図ではない

レビュアーはショートカットの記憶を持たない

記事は Anthropic の Building Effective Agents の orchestrator-workers パターンを説明する：リードエージェントが仕事を分解し、workers が並行で実行し、別のエージェントがレビューする。それを組織図以上にする部分は、レビュアーが workers が取ったショートカットの記憶を持たず、彼らのアプローチへの執着も持たないことだ。ただそこにあるものを読む。

それはまさに、私たちの Oracle を投票ラウンドではなく校正されたマージにする構造的プロパティである。Oracle はどの Sister がどのシナリオを起草したかを知らない。正規化された出力を受け取り、確率でマージし、降順にソートし、エントロピーは nats で測る。独立性が、ensemble を平均ではなく校正されたものにするメカニズムである。[ORIGINAL DATA] the 21-paper academic series plus Theorem 3 がこれを形式化する：マージされた予測は、貢献者が独立しておりマージメカニズムが自身の分散を測定しているときに正確に校正される。

計画は実際の仕事から来る、フローチャートからではない

記事は、真の orchestrator をスクリプト化された pipeline から切り離す一点に慎重である：マネージャーがその場で計画を決める。「always spawn three workers」とはスクリプトしない。目標を渡し、リードエージェントが実際の仕事を見て、何人の workers、誰が何を、何をレビューすべきかを決める——サブタスクを事前には予測できないからだ。これがワークフローエンジンと AI OS の違いである。前者はあなたが先月描いたフローチャートを実行し；後者は目の前の仕事の形に従って仕事をルーティングする。それが 2016 年から私たちが HAI Engine を構築してきた形である——まずルーティングし、それから応答する。

いつサブエージェントを使わないか

結果を委譲し、ステップを委譲しない

一年の運用の後の記事の経験則：結果を委譲し、ステップではない。一文でタスクを渡し、プロセスを見ずに結果を判定できるなら、それはサブエージェントの仕事である。監督する必要があるなら、メイン会話に留める。それはルーティングのテストである：境界はきれいな結果を運べるか、それとも仕事が漏れるか。

一つの帰結：フェーズがコンテキストを共有するなら、サブエージェントに委譲しない。計画、構築、テストがすべて同じ蓄積された理解を必要とするなら、それらを隔離されたエージェントに分けることは、各引き継ぎで状況を再説明することを意味する。メインコンテキストを守る隔離が、ワークフローを殺す税になる。

常駐の専門家は使い捨てサブエージェントではない

記事は有用な区別を引く：タスクのために生成され消える使い捨てサブエージェントは請負人であり；永続的な記憶を持つ常駐の専門家は従業員である。請負人から始め；呼び戻し続ける者を雇う。メカニズムの違いは、セッション間で生き残る記憶である。

Everythink では、Sisters は常駐の専門家である。それらのパーソナリティは実行時に TOML ファイルから読み込まれ、一つの編集は再コンパイルを必要とせず、prompt のバージョンは再現性のために各実行にスタンプされる。それらはデスクと測定された出力を持つ従業員である。Oracle はショートカットを一度も見なかったレビュアーである。

これがあなたの network にとって何を意味するか

顧客主権はスコープの保証である

サブエージェントパターンの最も深い教訓は AI についてではない。主権についてである。記事の著者は、自分が定義し、スコープし、所有する五人の専門家でビジネス全体を動かす——Nova、Quill、Rack、Atlas、そして彼自身。彼が境界を配線したので、誰も互いの仕事に触れられない。それが顧客主権である：あなたの network、あなたのブランド、あなたのデータ、あなたのルーティングルール。

Everythink では、顧客主権は同じ方法で実装されたスコープの保証である。Whitelabel Network の所有者は communities、rooms、権限スコープ、モジュール表面を定義する。Eye Key ——スペースを持ち、決してハイフンを持たない——は開発者のスコープ付き資格情報である：所有者が認めた権限を正確に運び、それ以上はない。「ゲストは Eye Key を mint できない」というプロパティは、auth メカニズムによって保証され、ポリシーの文によってではない。

スコープの倫理：民生と防御のみ

サブエージェントパターンはスコープについて中性である。Nova をサーバーの外に留めるのと同じメカニズムが、targeting エージェントを民生の境界内に留めることもできる——あるいはできない。メカニズムはスコープを決めない；オペレーターが決める。だから Everythink の文書化されたポリシー境界は民生と防御の用途のみであり、だからその境界はスコープの決定であり、マーケティングの文ではない。「このエージェントは攻撃的ターゲットに触れられない」を保証するメカニズムは、Nova のツールリストが彼女がメールを送れないことを保証するのと同じ方法で実装される：境界で能力を省くことによって。

包容 by design はもう一つの方向での同じ規律である。より小さなモデルで価格の何分の一かで走るサブエージェントは、低接続性の包容メカニズムである——記事はコストのダイヤルを明示的に名指しする。私たちの多言語、マルチモーダル、低接続性の設計は同じ論理に従う：ルーティング層は高速接続や単一言語を仮定しない。

主要な要点

• サブエージェントは一つのファイルの中の二つのメカニズムである：ルーティングする説明（the space is the router）と、スコープを保証するツールリスト（Theorem 3）。
• コンテキストの腐敗は測定の問題である；修正は隔離であり、より大きなウィンドウではない。HAI Engine ✅ は 2016 年から生産でこのパターンを運用している。
• きれいな引き継ぎは測定境界である——40,000 トークンが入り、三段落が出る——そして「メインコンテキストがきれいに保たれる」プロパティは、引き継ぎが実装され測定しているときに正確に保証される。
• 「Nova can't send email」は Theorem 3 の平易な表現である：プロパティはツール制限メカニズムが実装されているときに正確に成り立ち、リストを読んで測定できる。
• workers-plus-reviewer パターンは ensemble である。Oracle は誰が何を起草したか知らずに Sisters の出力をマージする——独立性が校正メカニズムである。
• 状態を昇格させない：Social ✅、Campaigns ✅、Whitelabel Network ✅ は Production；Matchmaking ⚠️、Marketplace ⚠️、Calendar ⚠️ は Partial；Wallet & Token 🔵、Super App 🔵、Community Credit 🔵 は Roadmap であり、Howey 審査に服し、結果は約束されない。
• 結果を委譲し、ステップではない。ルーティングのテストは、境界がきれいな結果を運べるかどうかである。

よくある質問

サブエージェントはマルチエージェントチームと同じですか？ いいえ。チームはメタファーであり；サブエージェントはルーティングルールにスコープの保証を加えたものである。説明フィールドが仕事を専門家へルーティングし；ツールリストが専門家がレーンから出られないことを保証する。

なぜツール制限が prompt より重要なのですか？ prompt は要求であり；ツールリストはメカニズムである。「Nova cannot send email」というプロパティはツールリストによって保証され、Nova にメールを送らないよう頼むことによってではない。Theorem 3：プロパティはそのメカニズムが実装され測定しているときに正確に保証される。ツールリストは境界で測定可能であり；prompt はそうではない。

いつサブエージェントではなく skill を使うべきですか？ 仕事が現在の会話で走る繰り返し可能な手順のとき。サブエージェントは隔離コスト——新しいコンテキスト、状況の再説明——を払い、それは冗長または制限された仕事には価値があり、あなたのコンテキストを共有するワークフローには無駄である。

これは Everythink の network-to-community-to-room トポロジーとどう関係しますか？ どちらもルーティングメカニズムである。サブエージェントの説明は prompt を専門家へルーティングし；URL 空間はリクエストをその能力を持つ room へルーティングする。ルーティングは何かが応答する前に起こる。それが the space is the router である。

Sisters はサブエージェントですか？ Sisters は実行時に TOML から読み込まれる永続的なパーソナリティを持つ常駐の専門家である。それらは自分のきれいなコンテキストで起草し；Oracle はどの Sister がどのシナリオを書いたか知らずに草稿を校正された ensemble にマージする。独立性が予測を平均ではなく校正されたものにする。

Sources

• 2026 — Professor Glitch, askglitch.com, "Claude Code Subagents: Turn One AI Into a Whole Team" — https://www.askglitch.com/blog/claude-code-subagents
• 2026 — Anthropic, "Building Effective Agents"（orchestrator-workers パターンのためにソースから参照）— https://www.anthropic.com/research/building-effective-agents
• 2026 — Claude Code documentation, "Sub-agents" — https://code.claude.com/docs/en/sub-agents

---

あなたの network を作り、ルーティングルールを自分で配線しよう——the space is the router であり、保証はメカニズムの中に生きている。