この記事の要点（2026年5月）: Claude Code でマルチエージェントを運用していて「委任するほど遅くなる」という体験をした。ネタ帳1件のクイックキャプチャで、COO直接実行が8秒、writerへの委任が約1分と実測。その原因を「委任税」として分析し、「推論の深さ × 出力の量」の2軸で委任判断を設計し直した記録。
「委任は善」という思い込みから始まった
マルチエージェント構成を組むと、最初は委任に頼りすぎる。専門エージェントがいるなら使うべきだ、という感覚になる。
私が気づいたのは2026年5月のことだ。ネタ帳に短いメモを1件追加したくて、writer エージェントへ委任したところ、思いついてから書き始めるまでに1分かかった。同じ内容を COO が直接書いたら8秒で終わった。
4〜10倍の開きがある。アイデアは揮発性が高いので、この時間差は致命的になりうる（著者の所感）。
なぜこうなるのか。原因を分解したのが本記事だ。
なぜサブエージェント委任は重くなるか — 準備フェーズのコスト
委任コストはエージェント側だけでなく、COO側にも発生する。
COO側のコスト（委任前）: - 何をやってほしいかを整理する - 委任プロンプトを組み立てる（参照Playbook・制約・出力形式を記述） - 委任処理を実行する
エージェント側のコスト（起動後）:
- Playbook（
netacho-management.md、netacho-creation.md）を読む - 既存ネタ帳を探索して重複確認
- frontmatter・出典タグ・cross-reference の整合チェック
- ようやく3〜5行のメモを書く
実測29秒は委任プロンプトを渡してからエージェントが起動完了するまでの時間（執筆開始前）だ。その前にCOO側でプロンプト組み立てのコストがかかっている。合計すると「委任税」はさらに高い。
writer は長文生成が本職のエージェントなので、エージェント側の準備フェーズは正しく設計されている。問題は3〜5行のメモにCOO・エージェント両側の固定コストが丸ごとかかることだ。タスクとエージェントの粒度がミスマッチしている。
Claude Codeで委任税を「払うべきか」の判断基準
委任税をゼロにすることはできない。エージェントが起動して文脈を読み込む以上、固定コストは必ずかかる。問題は「その税額がアウトプットに見合うか」だ。
私が使っている判断基準は 推論の深さ × 出力の量 の2軸だ。
| 推論が深い | 推論が浅い | |
|---|---|---|
| 出力が多い | 委任する（章単位の執筆・設計書） | 委任を検討（量が多いなら専門ツール化）※著者の判断 |
| 出力が少ない | 委任する（専門知識が必要なレビュー） | 直接やる（1〜数行・判断基準が単純） |
どちらの軸も「小さい」なら直接やる。どちらかが「大きい」なら委任を検討する。
ネタ帳のクイックキャプチャは「推論が浅い（フォーマット通りに書く）× 出力が少ない（3〜5行）」なので、右下の象限に入る。委任税を払う価値がない。
「委任しない経路」を設計する
この判断を毎回行うのは認知コストが高いので、あらかじめ「委任しない経路」をルールとして明文化した。
現在 COO が直接やる作業として運用ルール（.claude/rules/coo-rules.md）に定義しているのは以下だ。
- git add / commit / push（数行で完結、判断が単純）
- GitHub Issue の close・コメント（
/todo done等のスキル経由） - 軽微なファイル修正（URL差し替え、数行の追記）
- ネタ帳クイックキャプチャ（
maturity: rawかつ3〜5行以内）
興味深いのは、これらが「暗黙の慣習」として定着していたわけではなく、事故（フォーマット品質の崩壊）を経てルールとして明文化された点だ。
実際、COO が直接ネタ帳を書いた初期の事例（2026-05-03）では、出典タグ欠落・frontmatter 欠落・意見と事実の混入が起きた。そこで「raw キャプチャ」と「整形済みネタ帳作成」を分離し、raw キャプチャに限って COO 直接を許可する設計にした。条件を3つに絞ることで品質を保つ。
maturity: raw（整形しない断片でよい）- 本文 3〜5行以内（長くなったら writer へ切り替え）
- 重複がない（既存ネタ帳と同テーマでないこと）
「委任しない経路の設計」とは、暗黙の慣習ではなくルールとして明文化することで初めて安定するというのが実感だ。
逆に「削れない委任コスト」もある
委任コストを削りすぎると壊れる部分もある。
マルチエージェント構成では、各エージェントは独立したコンテキストウィンドウを持つ。COO が writer に情報を渡しても、次に呼んだ secretary にはその情報が届かない。そのため、各エージェントが同じ Playbook を毎回読む「重複」は、シングルプロセスで見ると無駄に見えるが、マルチエージェント設計上の必然だ（2026-04-27 のセッションで確認した）。
「重複 = 無駄」ではない。独立プロセスでは各自が必要なものを持つのが正しい設計だ。
削れる委任コスト（クイックキャプチャを writer に投げる）と、削れない委任コスト（各エージェントの Playbook 読み込み）は別物として扱う必要がある。
Claude Codeマルチエージェントの委任設計まとめ
委任は善ではない。タスクの粒度とエージェントの粒度が合っているときだけ善になる。
- 「推論が浅い × 出力が少ない」タスクは委任税のほうが高くつく
- 「委任しない経路」を明文化することで、都度の判断コストを削れる
- ただし、マルチエージェント固有のコスト（独立コンテキスト起因の重複読み込み）は削るべきでない
マルチエージェントの設計は「どこに委任するか」だけでなく「どこで委任しないか」を決めることでもある。
マルチエージェントの委任設計を整理すると、次の問いが出てくる——そもそもCOOとwriterとresearcherをどう組み立てて、Playbookや役割分担をどう設計したのか。
委任税の最適化は「チームが動いている」前提の話だ。私はその前段階――エージェント構成をゼロから設計した過程――を Zenn Book にまとめている。Vol.1では役割設計・委任ルール・CLAUDE.mdの書き方を、Vol.2では運用・自動化・Routinesの組み方を扱っている。
関連記事: マルチエージェントで「本当の無駄」と「必然」を見分けた話
関連書籍: コードを書けない私がClaude Codeで「AIチーム」を作るまで / コードを書けない私がClaude Codeで「AIチーム」を回すまで
この記事のテーマを深掘りした本
Claude Codeで作る1人エージェントチーム エンジニア向け。writer + reviewer の2体から始めるサブエージェント設計（序章無料）
シリーズ全6冊: Vol.1 作るまで ／ Vol.2 回すまで ／ Vol.3 書き続けるまで ／ Vol.4 仕組みを渡すまで ／ Vol.5 仕事を任せるまで ／ Vol.6 1人エージェントチーム
