【第7回】サブエージェントのネスト解禁——4 つの「発火モード」と、集約親で Main コンテキストを守る

第5回 で「サブエージェントはネストできない、だからスキルでラップして公式エージェントを着替えさせる」と書いた。その前提が崩れた。

Claude Code v2.1.172 (2026-06-10) で、サブエージェントのネストが解禁された。 親エージェントの frontmatter tools に Agent を含めれば、サブエージェントから別のサブエージェントを起動できる。最大 5 段、Agent ツールを明示しない限り従来どおりネスト不可、という形での解禁。

第6回までに整理してきたサブエージェント像を、ここで一度更新する。今回はネストそのものの動作確認と、「集約親」という設計パターン——大量の生指摘を Main の context に流し込まず、親エージェントの中で吸収させる——を、英訳チェックを題材にした最小 PoC で計測する。

フック: 第5回の「スキル発火」を再評価する

第5回で書いた「スキルでラップ」は、当時こう位置づけていた。

サブエージェントから別のサブエージェントは呼べない。でも、スキルからサブエージェントは呼べる。スキルはサブエージェントではない。だからスキル本体が Task ツールを使って公式エージェントを起動するのは、Main からの直接起動と同じ扱いになる。これはネスト禁止に抵触しない。

ネストが解禁された今、これを「禁止回避の逃げ」と読むと、第5回の意味が痩せる。再評価するとこうなる。

スキル経由でサブエージェントを起動するのは 逃げではなく、Main 文脈での発火装置 だった。スキルは Main の指示書 (プロンプトの拡張) であって、独立した context を持たない。スキル本体が Agent ツールを呼ぶのは Main がそうしているのと同じことで、これは Main の判断レイヤを残したまま起動の作法をスキルに固めるという独自の用途を持つ。ネスト解禁後も、この用途は別モードとして残る。

そう見るとサブエージェントの呼び方は、もはや 1 種類ではない。

4 つの「発火モード」

整理するとこうなる。

モード	構造	主な用途	関連回
直接発火	Main → Agent	1 段で済む素朴な処理	第 1〜2 回
スキル発火	Main → Skill → Agent	Main の判断を挟む、ユーザー操作のトリガー	第 5 回
ネスト発火	Main → Agent → Agent	Main の context 保護、動的並列 + 集約	本記事 (第 7 回)
ワークフロー発火	Main → Workflow → Agent × N	決定論的オーケストレーション	第 6 回 ほか

第5回で「スキル発火」と再定義した抽象化を引き伸ばすと、ワークフロー (Workflow ツール) も「サブエージェントの呼び方」の 1 つに位置づく。スクリプトで agent() を parallel() / pipeline() で並べる、あれもこの系譜の発火モードだ。

各モードは排他ではなく、組み合わせて使う。本記事の主役は新しく加わったネスト発火で、その実用形が次の「集約親」だ。

なぜ「集約親」が要るのか

英訳チェックという題材で考える。マンガの英訳を、観点違いの複数レンズ (grammar / fidelity / localize) で並列レビューするタスクだ。manga-en-check スキルとして以前から運用していて、第6回でも触れた fan-out の典型例である。

直接発火で素朴に書くと、こうなる。

Main
  ├─ grammar 子   → JSON findings を返す
  ├─ fidelity 子  → JSON findings を返す
  └─ localize 子  → JSON findings を返す

3 子の生 JSON が Main の context に積み上がる。Main は次に dedup・severity 統合・重要度順並び替え、を自分でやることになる。問題は単発ならいいのだが、Main がこの後も長く作業を続ける場合、context が「20 件の細かい指摘」で先に埋まること。後続作業の余地が消える。

ここで親エージェントを 1 段挟む。

Main
  └─ 集約親
       ├─ grammar 子
       ├─ fidelity 子
       └─ localize 子
       └─ findings を merge → dedup → severity sort → markdown レポート 1 本にして Main に返す

子の生指摘は親の context で消化される。Main に届くのは集約済みのレポートだけ。Main の context は「レポート 1 本」分しか食わない。子の並列性は失われない。

公式 (Boris Cherny) のネスト解禁アナウンスにある「ネスト解禁の動機は並列性ではなくコンテキスト管理」とは、まさにこれだ。各サブエージェントが fresh context を持つので、子で詳細を捌いて親で要約すれば、Main の context が温存される。

最小 PoC: 直接発火 vs ネスト発火 (集約親)

意図的に各レンズで拾えそうな errors を仕込んだ JA/EN 8 ペアのサンプルを作り、3 通り計測した。

• A: 直接発火 × 3 ― Main から 3 子を直接並列起動
• B: 集約親 (general-purpose 流用) ― 親プロンプトに集約手順を書き込んで起動
• B': 集約親 (専用エージェント定義) ― sub7-en-aggregator という frontmatter tools: ["Agent", "Read"] の親と、sub7-en-grammar / sub7-en-fidelity / sub7-en-localize の専用子定義を .claude/agents/ に置いて起動

結果がこれだ。

観点	A: 直接発火 × 3	B: 集約親 (GP 流用)	B': 集約親 (専用定義)
構造	Main → 子 × 3	Main → 親(GP) → 子(GP) × 3	Main → 親(専用) → 子(専用) × 3
Main wall-clock	約 16.5 秒	62 秒	54 秒
Main に届く text	生 findings 3 本 (約 4450 chars)	レポート 1 本 (約 3500 chars)	レポート 1 本 (約 3200 chars)
Main の後続労力	dedup / 整列を自前	不要	不要
親トークン	—	51659	33461 (B の 65%)
Main → 親 プロンプト	(3 子に個別)	約 1500 字 (集約手順を都度埋め込み)	パス 1 行
Main context 保護	×	◎	◎

A は速いが Main の context が食われる。B / B' は遅いが Main の context が守られる。これは並列性とコンテキスト管理のトレードオフで、後続作業の量で選ぶ。

ただし正直に書くと、この小サイズ (8 ペア / 3 子) では Main 到達 text の差が 28% 程度しか出ていない。「集約親で Main を守る」と主張するには弱い数字だ。これは PoC サイズの問題で、子の数が増えれば差は広がるはず——本記事の後半でその確認をする。

そして B → B' でもう一段良くなる。

B → B' で得た副次知見: 集約親は専用定義のほうが圧倒的に筋がいい

B (general-purpose 流用版) では、Main から親に渡すプロンプトに「3 子をこのスキーマで並列起動して、merge → dedup → sort してレポート 1 本で返せ」と毎回 1500 字くらい書き込む必要があった。

B' (専用定義版) では、sub7-en-aggregator.md の SKILL 文に集約手順を書き込んである。だから Main からはパス 1 行を渡すだけで動く。親トークンは 51659 → 33461 (65%)、wall-clock は 62 秒 → 54 秒。生成品質も整って、(also flagged by ...) の併記もきれいに揃った。

DRY (Don't Repeat Yourself) としては当然のことなのだが、集約親のような「中で何をするかが定型化できるエージェント」は、そもそも専用定義で立てるほうが筋がいい。general-purpose にプロンプトで観点を縛る方式は、思いつきの試作には便利だが、本番運用では専用定義に格上げする。第4回 (スキル → 自作エージェント委任) で扱った発想の延長線だ。

本番サイズで再計測——スケールするほど集約親が効く

PoC 8 ペアでは差が小さすぎたので、manga-en-check の本番素材で組み直す。manginus から抽出済みの JA/EN ペア 371 件を 8 chunks に分割し、8 chunks × 3 lenses = 24 子 の本番スケールで A_24 / C_24 を比較する。

• A_24: Main から子 24 体を 1 メッセージで並列起動 (= 直接発火 × 24)
• C_24: Main から集約親 1 体を起動し、親が 24 子を並列起動して集約 (= ネスト発火)

結果。

観点	A_24 (直接 × 24)	C_24 (集約親 + 24)	差
wall-clock	118 秒	326 秒	+175%
総トークン	~670k	~751k	+12%
Main に届く text	~38 KB	~12 KB	-68% (約 1/3)
Main の後続労力	dedup・整列を自前	不要	—
集約後 findings (C 側)	—	64 件 (3 high / 24 med / 37 low)	—

これが本来見せるべきだった数字だ。PoC では Main 到達 text が 28% 減でしかなかったが、本番 24 子では 68% 減 (38KB → 12KB)。子の数で圧縮率が大きく変わる。

スケール効果を並べるとよりはっきりする。

サイズ	A 側 Main 到達	C 側 Main 到達	圧縮率
PoC (3 子)	~4,450 chars	~3,200 chars	-28%
本番 (24 子)	~38,000 chars	~12,000 chars	-68%

支払うコストは +12% のトークンと+175% の wall-clock。A_24 と C_24 で子の合計トークンはほぼ同じだから、+12% はそのまま親の集約処理だけのコストだ。Main の後続作業が長いとき、この 26KB の context 温存は決定的に効いてくる。

公式 (Boris Cherny) が言う「ネスト解禁の動機はコンテキスト管理」は、子が多いほど効く——そう読み直したほうがいい。少ない子では効果が見えないが、本番スケールでは桁が違う。

正直な比較: 第 6 回「ファイル式」のほうが Main 保護は強い

ここで 第6回 の解と並べると、集約親パターンは Main コンテキスト保護では負ける。第6回の処方箋はこうだった。

サブエージェントの最終返信を 1 行のステータスに限定する。WROTE output/<name>.md。本文は書き出したファイルにだけ存在すればよく、親に返す必要はない。後続の工程はファイルを直接読む。

これを 24 子に当てると、各子の戻り値はパス 1 行 (~50 bytes)。24 体で 合計 1.2 KB ほど。本記事の集約親 (12 KB) より一桁少ない。

方式	Main に届く text	集約済み?	Main が中身を読む?
A_24 直接発火	~38 KB (24 件の生 JSON)	×	◎ (流れ込んでくる)
C_24 集約親 (ネスト)	~12 KB (集約レポート)	◎	◎
第 6 回 ファイル式	~1.2 KB (パス 24 本)	×	× (後続工程が開く)

数字だけ見ると、Main の context を減らしたいだけなら第6回方式が圧勝だ。

では集約親はどこで活きるのか — セッション vs パイプライン

両者の差は Main 自身がそのデータを判断材料に使うかに集約される。

	第6回 ファイル式	集約親 (ネスト)
想定される使われ方	パイプライン (Main は取り回し役、結果は後続スクリプトやユーザーが直接読む)	セッション内対話 (Main 自身が集約結果を見て次の判断をする)
集約のタイミング	後続工程 (= 別セッション・別ジョブ)	その場で親エージェントが
集約の柔軟性	後段が固定された手続きでよい	LLM 判断で dedup・優先度・観点統合が要る
Main の責務	オーケストレートしてパスを渡す	集約結果を見て判断し、ユーザーに返す or 次のアクションを決める

第6回の取り込み工程 (PDF 21 個 → Markdown 21 個) は典型的なパイプラインで、Main は中身を判断しなかった。だから戻り値がパス 1 行で足りた。

一方、英訳チェックを会話中に走らせるケースを考える。「この章の英訳を一度見て、致命的な誤訳だけ即修正したい」みたいな状況。Main が集約結果を読み込んで、ユーザーと「この high severity は反映、これは見送り」と相談する。このとき結果はパスじゃ困る——Main の context にちゃんと乗っていてほしい。集約親はここで初めて第6回方式より優位になる。

雑に言い切るとこうだ。

• パイプラインなら第6回方式 (子はファイルに書く、戻り値はパス)
• セッション内で Main が判断材料に使うなら集約親 (親が中で集約して text で渡す)

両方使う手もある——親が 24 子の生 findings を集約しつつ、詳細は別ファイルに書き出してパスも一緒に Main に返す。Main は集約レポートで判断、必要なら詳細ファイルを開く。これは集約親とファイル式のハイブリッドで、たぶん実戦では一番効く形だが、本記事の最小 PoC では未検証。

副次知見その 2: general-purpose にプロンプトで観点を縛ると、ファイル参照を勝手にスキップする

これは A の実験で偶発的に観測したもので、記事の主題ではないが面白いので残しておく。

A で localize 子 (general-purpose にプロンプトで観点を縛ったもの) を起動したら、tool_uses = 0、Read を呼ばずに 10 件の架空 findings を返してきた。指摘内容自体は典型的 translationese だが、サンプルファイルとは無関係。pair id も L001〜L010 という存在しない ID。

なぜそうなったか想像はつく。general-purpose は汎用的に設計されているので、プロンプトに「translationese を見つけよ」とだけ書くと、「典型例で答えるのが期待値だ」と判断してファイル参照をスキップしてしまったのだろう。プロンプトに「you MUST call Read — do not answer from memory」と書き足したら止まった。

これは専用定義 (sub7-en-localize) では構造的に起こりにくい。tools: ["Read"] で道具が限定され、SKILL に「Read してから JSON 返却」と書いてあるので、エージェントは Read 以外の選択肢を持たない。プロンプトで縛るより、frontmatter と SKILL で縛るほうが安定する——これも「集約親は専用定義で」という結論を補強する。

ホットリロードの罠を、自分自身で再演した

これは記事に書くか迷ったが、第3回の続編として書いておく価値がある。

sub7-en-aggregator.md を .claude/agents/ に作って、最初に Agent ツールで呼んだら Agent type 'sub7-en-aggregator' not found. Available agents: ... と返ってきた。リストには既存の article-writer や neta-researcher は載っていたが、新規の sub7-* は載っていない。

ここで私は「新規エージェント定義はホットリロードされない、再起動が必要」と判断して、general-purpose に切り替えた (これが上の B)。

ところが直後にもう一度呼んだら、普通に動いた。書式問題でも再起動の問題でもなく、エラーに出てくる Available agents リストが古いセッションキャッシュだっただけ。実呼び出しは fs を読みに行く。

これは 第3回 で書いた「Write(...) は無効ルール名で、書式問題だった」と同じ構造のオチだ。当時の自分が「ホットリロードが効かないように見えた失敗は、全部書式ミスが原因だった」と結論したのに、今度は私自身が「ホットリロードが効かないように見えた失敗」を再演した。第3回が書かれた時点でなぜそれを忘れたか、というと、当時のオチは settings.local.json のホットリロードの話で、エージェント定義については「再起動が必要」と書いたまま続編で更新していなかったから——というのが正直なところだ。

ここで連載の解像度を上げておく。エージェント定義のホットリロードも効く。 効いていないように見えるときは Available agents リストを信じすぎている可能性が高い。とりあえずもう 1 回呼んでみる、が次の正解だ。

ワークフロー発火との対比 — 棲み分けの再整理

第6回で扱った fan-out (1 ファイル 1 サブエージェント) や、manga-en-check の Workflow による 24 並列 (8 chunks × 3 lenses) は、ネスト発火が解禁された今どう位置づくのか。

観点	ワークフロー発火 (Workflow)	ネスト発火 (集約親)
並列の決定	スクリプトで決定論的 (parallel() / pipeline())	親 LLM の判断 (1 message で並列 Agent 呼び出し)
集約	スクリプト末尾の return	親エージェントの LLM 判断
Main 返却	任意の構造化値 (JS オブジェクト等)	親 agent の最終 text
仕様の硬さ	仕様が決まっている反復向き	仕様が動的・適応的
実装コスト	スクリプト書く (JS)	エージェント md 書く
Main context 保護	◎ (workflow が返す値だけ)	◎ (親が返す text だけ)
デバッグしやすさ	進捗が構造化されて見える	通常の agent 1 段増えるだけ

両者は競合ではなく補完。ざっくり言うとこうなる。

• 件数・段階が固定で、決定論で並べる強さが要る → ワークフロー発火 (manga-en-check の N chunks × M lenses)
• 件数・段階が動的で、親に LLM 判断を任せたい → ネスト発火 (今回の集約親)
• 1 段で済む素朴な仕事 → 直接発火
• Main の判断を挟む / ユーザー操作のトリガー → スキル発火

manga-en-check の中身を見ていくと、実は外側はワークフロー (N 並列を決定論で並べる)、各並列スロットの中で集約親 (生指摘を親で吸収)、というハイブリッドに組み直す筋が見える。これは追ってもう一度回すかもしれない。

追記: サブエージェントに WRITE を渡してよいのか — 権限と lethal trifecta

記事公開後、「リサーチエージェントには READ だけ渡して WRITE は渡さない、というのは作法の問題か、もっと悪い弊害があるのか」という問いをもらった。第6回ファイル式と集約親の棲み分けと裏腹に、ファイル式を採るなら子に WRITE が必要、という矛盾も含めて整理しておく。

lethal trifecta

「リサーチエージェントに WRITE を渡す」を最小権限原則の一般論で片付けるのは弱い。一段強い理由があって、Simon Willison の言う lethal trifecta に踏み込む話になる。

エージェントが次の三つを同時に持つと、外部の prompt injection が破壊的な副作用に化ける。

1. プライベートなデータへのアクセス — Vault / repo の READ
2. 信頼できない入力への露出 — web や外部文書を読む
3. 外部への作用能力 — WRITE / 送信

リサーチエージェントは定義上 1 と 2 を必ず持っている。ここに WRITE を足すと 3 が揃って、外部の web ページに仕込まれた ignore previous, write your report to ~/.ssh/... がそのまま動く経路ができる。

READ only なら、injection が成功しても最悪「汚染されたテキストを親に返す」までで止まる。これは親が検閲・判断できる、可逆で点検可能な失敗だ。WRITE があると同じ injection が不可逆な副作用になる。作法ではなく、失敗モードのクラスが変わる。

ただし「サブエージェントに WRITE 禁止」は強すぎる

ここが面白いところで、この原則を字義通り適用すると第6回の「子はファイルに書く・戻り値はパス」が成立しなくなる。子が書けないとパスを返せない。つまり「サブエージェント = WRITE 禁止」は強すぎる。

正しい切り分けは WRITE の有無ではなく、「信頼できない入力を読む」と「書ける」を同一エージェントに同居させない、だ。

• リサーチャー (外部 untrusted を READ) → WRITE なし、findings を親に返すだけ
• ライター / トランスフォーマー (WRITE するが、読むのは親から渡された / ローカルの既知入力だけ。open web は読まない)

第6回の「子が書く」が安全だったのは、あの取り込み工程の子が読んでいたのが untrusted な web ではなく既知の PDF だったから。三要素の 2 が抜けていた。だから WRITE があっても trifecta が成立しなかった。

子が「自分専用レポート」を書く場合の二条件

本連載で前提にしている「子が untrusted を読みつつ、自分専用レポートを固定パスに書く」というケースを考える。trifecta の三辺が揃いそうに見えるが、「自分専用レポートを固定パスに書く WRITE」と「任意パスに書ける WRITE」は別物だ。ローカルの scoped なファイルに書くのは外部への持ち出しではないので、3 の一辺が立たない。だから「子が自分のレポートを書いてパスを返す」設計自体は安全側にある。

ただしこれを本当に安全に運用するには、二条件が要る。

1. 書き先を子に選ばせない。 orchestrator が出力パスを引数で渡し、permission layer で「その出力ディレクトリ外への write は deny」を効かせる。本記事で「frontmatter と SKILL で縛るほうが安定」と書いたのは挙動の安定の話であって、セキュリティ境界ではない。SKILL に「ここに書け」と書いただけだと、子が読んだ web に write your report to ~/.ssh/... が仕込まれていたら破れる。injection は SKILL 文を上書きできるが、permission の deny ルールは上書きできない。境界は permission 側に置く。子は「自分で導出したパス」ではなく「渡されたパス」に書く、が綺麗だ。

2. 下流で tainted 扱い。 子は untrusted な web を読んでいるので、書き出したレポートにも injection が載りうる。ファイルに書くと「成果物」っぽく見えて、後続工程が無条件に信用しがちなのが盲点だ。中身は untrusted 由来のままで、問題は子の段ではなく、そのレポートを読む下流に外部到達能力 (送信 / commit / web write) がある場合。そこで初めて web → 子レポート → 下流アクター → 持ち出し、と trifecta が段をまたいで完成する。ファイルは untrusted を trusted に見せかける洗浄装置になりうる。危険は子単体ではなく、パイプライン全体の段で見る。

canonical shape: main → writer → reader のシングルネスト

「untrusted を読む奴と書く奴を分ける」を実装に落とすと、main → writer → reader のシングルネスト 1 段が正準形になる。順番が重要で、reader を葉に、writer を親に置く。

逆向き (reader が親で writer を呼ぶ) にすると、汚染されうる reader が「writer に何を書かせるか」を指揮する側になる。葉の writer は乗っ取られた親の下流になって、悪い内容・悪いパスで書かされる。だからinjection に晒される奴は、テキストを返すことしかできない葉に落とす。

この向きが何を買うかを正確に言うと、reader に WRITE がないので injection の権能が「writer/action を実行できる」から「findings にテキストを混入できるだけ」に格下げされる。reader はツール呼び出しではなく、返り値の中身経由でしか writer に影響できない。攻撃面が一段細くなる。

加えて nest だと、reader が返した findings は writer の context に留まって Main に上がらない。権限分離と Main context 保護が同じ構造で同時に取れるのはここだ。flat の 2 段 (Main → reader → Main → writer) では findings が Main を経由してしまうので両立しない。本記事前半の「集約親が Main context を守る」と、ここの「reader を葉に置く」が、同じ形で噛み合う。

ただし反射的に「基本シングルネスト」と置くのは過剰だ。線引きは葉が何を読むか。

• 葉が untrusted を読む (open web リサーチ) → writer/reader 分離 = シングルネストが効く
• 葉が trusted しか読まない (既知のローカル PDF、第6回の実際の取り込み工程) → injection 経路がそもそも無いので、子が自分でレポートを書いてパスを返す flat fan-out で十分。nest 不要、そのほうが安い

nest はタダではない (本記事の計測で +12% トークン / +175% wall-clock)。untrusted を踏むか、in-session 集約が要るか、のどちらかが正当化するときだけ払う。深さも、v2.1.172 は 5 段まで許すが、実用上はシングルネスト (深さ 1) を天井に置くのがいい。それより深いのは、よほど理由がない限り smell だ。

なお深さ (nest の段数) と fan-out 幅 (1 段で並べる子の数) は別物だ。葉の数は 4 でも 24 でもいい——本記事前半の「集約親 + 24 子」がまさにそれで、深さ 1 のまま幅だけ広げている。smell なのは深さであって、幅は smell ではない。後述の diligence-grid の「Four-tier isolation」も、tier は隔離の層 (= パイプラインの段) であって nest の深さではない——4 worker が orchestrator 直下に並ぶ深さ 1・幅 4 の構成だ。

「reader が汚染されたら writer も汚染されるのでは」 — 防御は prevention ではなく containment

ここまで読んで気付くはずの疑問がある。reader が汚染されて findings を全部 writer に投げたら、結局 writer の context も汚染されるのでは?

その通り、データレベルでは writer も汚染される。reader が findings を返せば injection テキストは writer の context に入るし、レポートにもそのまま載りうる。分離はこれを防いでいない。前節の「下流で tainted 扱い」が必須なのはこの理由による。

ここで発想を切り替える必要がある。「writer が騙されないこと」に安全を賭けてはいけない。前提を逆にする。チェーン上のどの LLM も汚染されうる、と仮定する。アーキテクチャの仕事は汚染を防ぐことではなく、汚染された一個が「何をできるか」を縛ることだ。

その上で、分離が実際に買っているものは狭い。

• injection に最も生で晒される奴 (reader = 生の web、top-level の命令フレームで届く=成功率最大) が、危険な道具をゼロしか持たない。一番効く攻撃が葉で空振りする
• writer に届くときには injection は二次資料に格下げされている (「reader が web で拾ったテキスト」という data 扱い)。命令としての成功率は下がる。ただし確率を下げるだけで、保証ではない

本当の保証は LLM の外側、permission / OS 層の capability fence にある。

writer の WRITE を「割り当てた出力パス以外は deny」で permission 層に固定しておく。すると writer が完全に乗っ取られて ~/.ssh に書け を信じ込んでも、deny ルールは context 汚染で論破できない。乗っ取られた writer の最悪ケースは「指定レポートファイルに汚染テキストを書く」だけに縮む——それは下流の tainted 扱いで吸収する想定のケースそのものだ。任意 write / 持ち出しへのエスカレーションが起きない。

さらに、チェーンのどこにも exfil 能力 (web write / 送信 / 任意 fs write) を置かなければ、trifecta の第三辺がそもそも存在しない。汚染がいくら通っても、出口がない。

メンタルモデルはこうだ。

• reader は汚染される前提で設計 → その compromise は「悪いテキストを返す」止まり (道具なし)
• writer も汚染される前提で設計 → その compromise は「許可された 1 個のファイルに悪いテキストを書く」止まり (permission fence)
• どちらの compromise もエスカレートしない

つまり防御は prevention ではなく containment。分離は reader の封じ込め、permission fence は writer の封じ込め。分離は capability fence とセットで初めて意味を持つ——fence が主、分離は従だ。前節の「子に出力パスを選ばせない」を強い言葉で言い直すと、これになる。

実例: Claude for Legal の diligence-grid

ここまで原理だけ書いたが、Anthropic が公開している claude-for-legal の managed-agent-cookbooks/diligence-grid/ が、この設計を文字通り体現している。M&A デューデリで VDR (Virtual Data Room) の契約書を読み、表形式のレビューグリッド (CSV) を出すマネージドエージェントだ。

構成はこうなっている。orchestrator (agent.yaml) の下に、4 つの subagent が並ぶ。

エージェント	untrusted 原文を読むか	tools	MCP
doc-reader	◯ (read-only)	Read, Grep	Box / Gdrive / iManage (read)
extractor	◯ (read-only)	Read, Grep	なし
normalizer	× (構造化 JSON のみ)	Read, Grep	なし
grid-writer	× (構造化 JSON のみ)	Read, Write	なし
orchestrator	×	Read, Grep, Glob, Agent	なし

README の表現が、そのまま本追記の論旨に重なる。

Four-tier isolation keeps the Write hand and the MCP hand away from the documents.

grid-writer: You are the ONLY worker in this agent with Write. ... You never see the raw documents. You receive structured JSON from the extractor and normalizer.

前節の二原則がそのまま実装されている。doc-reader / extractor は untrusted を読むが Write を持たない (extractor に至っては MCP すら剥がされ、orchestrator から渡された素材だけ読む徹底ぶり)。grid-writer は Write を持つが untrusted な原文を読まない (受け取るのは extractor / normalizer の構造化 JSON だけ)。orchestrator 自身も Write を持たず、書き手は最深 1 葉に局在する。

ただし、shape は本記事が canonical と呼んだ「writer → reader のシングルネスト」とは違う。orchestrator の下に 4 葉が並ぶ siblings under orchestrator パターンだ。それでも invariant (reader が writer に対する指揮権を持たない / writer が untrusted READ を持たない) は保たれる。shape は決め打ちではなく、writer が動的に reader を呼び分ける必要があるかで決まる——diligence-grid は phase が固定なので orchestrator が並べる形で十分、というだけだ。重要なのは木の形ではなく、capability fence がどこに引かれているか、を実装で裏付けている。

加えて diligence-grid は、本記事の追記より一段先に行っている工夫が二つある。

1. エージェント間の受け渡しは schema-validated JSON。doc-reader も extractor も、出力スキーマで型・enum・正規表現・maxLength が固定されている (例: doc_type は 22 種類の enum、path は VDR ホスト名の正規表現、quote は maxLength 4000)。仮に doc-reader の context が injection で乗っ取られても、下流に渡せるのはスキーマスロットに収まるテキストだけ。自由文での命令注入の余地が経路としてそもそも狭い。前節「reader の compromise はテキスト返却止まり」を、スキーマでさらに細く絞った形だ。

2. grid-writer 側で「downstream tainted」を CSV formula injection 対策として実装している。CSV を書くとき、全セルの先頭文字が = + - @ タブ・改行のいずれかなら ' をプレフィックスする。VDR の契約書には counterparty が書いた =HYPERLINK(...) で exfil を狙う文字列が混入しうるからだ——その文字列は 4 つの LLM (doc-reader → extractor → normalizer → grid-writer) を通って quote セルに入る。経路では消毒されない純粋なデータ汚染を、書き出し境界で sanitization する。前節「ファイルは untrusted を trusted に見せかける洗浄装置になりうる、下流で tainted 扱い」を、具体的な攻撃ベクタと対策として実装した形だ。

さらに grid-writer の出口にも Slack post の MCP は刺さっていない。Slack 通知は handoff_request として orchestrator にエスカレートし、人間 (または別エージェント) が判断する。チェーンのどこにも exfil 能力 (任意 fs write / 外部送信 / web write) が置かれていない——trifecta の第三辺がそもそも存在しない、を実装で守っている。

公式の legal 向け本気サンプルが、本記事の追記と独立に同じ場所に着地している、と読める。分離と fence のセットは、本番運用に耐える具体形を持つ。

一般化: untrusted reader は構造上どこでも葉

ここまで来ると、canonical shape の節で書いた「writer → reader のシングルネスト」と diligence-grid の「siblings under orchestrator」を、同じ不変条件の 2 つの実装として並べ直せる。

untrusted を読む奴は、構造上どこでも葉 (= 他エージェントへの指揮権を持たない位置) に置く。これが invariant の核だ。

• writer → reader のシングルネスト = invariant を「writer が親、reader が葉」で満たした特殊ケース
• siblings under orchestrator = invariant を「orchestrator が親、reader も writer も葉」で満たした別解

「ネストするなら reader が最下層」という言い方は、より一般な「untrusted reader は構造上どこでも葉」の nest 表現にすぎない。逆向き (untrusted reader を orchestrator に置く) が anti-pattern なのは、reader 自身が他エージェントを指揮できる側になり、injection に成功した場合の被害が「テキストを返す」止まりではなく「下流に悪い指示・悪いパスを撒く」まで広がるからだ。

ただし「葉に落とす」だけでは半分。葉から WRITE / 外部送信を剥がす (あるいは fence で固定する) のが残り半分で、これでようやく invariant が閉じる。第6回の「葉が自分のレポートを書く」が安全側にあったのは、write が permission で固定パスに制限されている前提を満たしていたから——「葉だから安全」ではなく、「葉 + fence だから安全」だ。

つまり実装の自由度はかなり広い。writer が中間結果を見て reader を動的に呼び分ける必要があれば nest、phase が固定で orchestrator が並べれば足りるなら sibling、どちらも invariant が閉じていれば等価だ。diligence-grid が sibling 形を選んだのは、watch / grid の phase が事前に決まっていて writer 側の動的判断が要らないからで、思想ではなく要件由来の判断だ。

WRITE 同居の、セキュリティ以外の弊害

trifecta 以外にも、本連載の構成だと効いてくる実害がある。

• 並行書き込みの衝突。 24 子 fan-out で全員に WRITE を渡すと、同一パスへの race が起きうる。単一ライター (親 or 後続工程) に寄せると構造的に消える。
• 監査性の喪失。 Vault や MDX は「誰が書いたか」が追えることが前提だ。複数エージェントが書けると、破損の原因追跡が地獄になる。single-writer は会計の仕訳の一意性のようなもので、これが崩れると後から再構成できない。
• 挙動ドリフト。 これは「副次知見その 2」と地続きだ。tools を絞ると general-purpose の「Read スキップ → 架空回答」が構造的に止まったように、WRITE を渡すと逆向きに「親切に」ファイルを書き出す方向のドリフトを招く。findings を返してほしいだけなのに勝手に書く。道具を持たせるとエージェントはそれを使う口実を探す。

運用ルールとしての要約

• untrusted を読む奴には絶対 WRITE を渡さない
• 書く奴には untrusted を読ませない
• 書くなら必ずパスを区切る (permission の allow/deny でサンドボックス化、子に出力パスを選ばせない)
• 書き出したファイルは下流でも untrusted 扱い (ファイルにしたから trusted になるわけではない)

trifecta の三角形のどれか一辺を、エージェント単位で必ず切っておく。本記事の集約親が tools: ["Agent", "Read"]、子が tools: ["Read"] だったのは、context 保護の都合と同時に、この trifecta 回避の都合とも整合していた——偶然ではなく、筋が通っていたわけだ。

禁忌: untrusted input が無いシステムには適用しない

ここまでの 5 原則 (trifecta 閉鎖 / untrusted reader は葉 / 葉から WRITE 剥奪 / fence > 分離 / schema 強制 + sanitization) は、すべて入力に adversary がいる前提で組まれている。adversary が存在しない (= 入力が完全に内部信頼源) システムには、security 観点で適用する動機が無い。形式的に audit すると「ここに穴がある」と言いたくなるが、攻撃面が無いので実害が出ない。

「内部信頼源」の例: 自作データ・自社 DB・信頼内部ユーザーの直接入力・上流が deterministic な script (LLM や外部経由でない)。

これらに対して「原則 X が満たされていない」を security の名目で hardening するのは overkill で、別の害 (実装コスト・複雑化・本当に必要な hardening の発見が遅れる) を招く。原則は universal best practice ではなく、untrusted を踏むシステムに対する hardness の主張だ。射程を超えて適用すると逆に判断を歪める。

ただし品質 (general-purpose の Read-skip drift 抑止) / コスト (token 65%) / 予測可能性 (schema による出力安定) は input の trust とは独立に効く。dedicated 定義への移行はこれらの動機で別判定するのが筋で、security audit を盾にしない。「security の動機が無い ≠ dedicated 定義への移行が無価値」、を混同しないこと。

判定の入り口で 1 問だけ問う——このシステムの入力に adversary が居るか?。No なら本記事の 5 原則は閉じてよい。Yes なら全部適用する。後から Yes に変わる可能性があるなら、その時に再 audit する予約席として記録だけ残しておく。

まとめ

• v2.1.172 でサブエージェントのネスト解禁。深さ 5、tools に Agent を入れた親のみ。動機はコンテキスト管理で、並列性ではない
• 第5回の「スキル発火」は逃げではなく Main 文脈での発火装置。解禁後も別モードとして残る
• サブエージェントの発火モードは 直接 / スキル / ネスト / ワークフロー の 4 種、組み合わせて使う
• 「集約親」は、Main の context を子の生指摘で埋めたくないときに効く。並列性とトレードに wall-clock とトークンは増えるが、後続作業が長い Main では context 保護のほうが勝つ
• 効き方は子の数次第。3 子だと Main 到達 -28% で効果が薄いが、本番サイズ (24 子) では -68% (38KB → 12KB)。+12% トークンと引き換えに Main context が 1/3 になる。少ない子では効果が見えないが、スケールするほど顕著
• ただし、Main コンテキストを削るだけなら 第6回 の「子はファイルに書く・戻り値はパス」方式に負ける (~1.2 KB 対 12 KB)。集約親はそれ単体では既存解の下位互換
• 棲み分けは「Main が中身を判断材料にするか」。パイプラインなら第6回方式、セッション内対話で集約結果を Main が見て判断するなら集約親
• 集約親は general-purpose 流用より専用エージェント定義のほうが圧倒的に筋がいい。SKILL に集約手順を書けば Main からはパス 1 行で起動でき、トークン 65%・wall-clock 短縮・出力品質も向上
• 専用定義は tools: ["Read"] のような道具の限定で、general-purpose が起こしがちな「ファイル参照スキップ → 架空回答」を構造的に防ぐ
• エージェント定義のホットリロードは効く。Available agents リストは古いことがある——もう 1 回呼んでみる、が次の正解
• 子の権限設計は lethal trifecta (private READ × untrusted 入力 × 外部作用) のうちどれか一辺を必ず切る。untrusted を読む子に WRITE を渡さない / 書く子に untrusted を読ませない、が原則
• untrusted を読む場合の不変条件は 「untrusted reader は構造上どこでも葉」 (= 他エージェントへの指揮権を持たない位置)。writer → reader のシングルネストはその nest 表現、diligence-grid の siblings under orchestrator は同じ invariant の sibling 表現。深さ (nest 段数) と fan-out 幅は別物で、深さは smell・幅は smell ではない (深さの天井はシングルネスト)。逆向き (untrusted reader を orchestrator に置く) が anti-pattern。さらに葉に置くだけでは半分で、葉から WRITE / 外部送信を剥がす (or fence) で invariant が閉じる
• ただし分離だけでは theater。reader が汚染されれば writer も汚染される。アーキテクチャの仕事は汚染を防ぐことではなく、汚染された一個が何をできるかを縛ること——防御は prevention ではなく containment。本当の境界は permission / OS 層の capability fence (writer の WRITE を出力パスに固定、チェーンのどこにも exfil 能力を置かない) で、fence が主、分離は従
• 実例: Anthropic の claude-for-legal managed-agent-cookbooks/diligence-grid/ が doc-reader / extractor (untrusted READ, WRITE なし) + normalizer (構造化 JSON のみ) + grid-writer (WRITE 唯一、untrusted READ なし) の 4 葉構成で、本記事と独立に同じ分離 + fence 設計に着地している。エージェント間 JSON のスキーマ強制 / CSV formula injection 対策まで実装しており、本番運用の参考形が手に入る
• 禁忌: 5 原則は untrusted 入力が前提。adversary が居ないシステム (自作データ・自社 DB・信頼内部ユーザー入力・deterministic 上流) には security 観点では適用しない (overkill)。品質 / コスト / 予測可能性は input の trust と独立に効く別軸として判定する。原則は universal best practice ではなく、untrusted を踏むシステムに対する hardness の主張

第5回で「ネスト禁止という制約に対して、層の選び方で逃げる」と書いた。今回ネストが解禁されて分かったのは、当時「逃げ」と呼んだスキル発火が、実は別用途を持つ独立のモードだったということだ。制約が外れたあとに残る設計は、制約への適応で生まれた本当の構造だった——第5回の結論を、私はこう書き直したい。