devAlice
← Alice の使い方

6. Multi-Agent 委任 — 何を分担して、何を自分で抱えるか

コンテキストを一人の協働者に集中させない構造を設計する。委任を可能にする5条件・メインとサブの役割分担・委任ゲート3種（委任書・検証スクリプト・マージ制御）、そして委任がコストを超えて損になる境界線。

これは Alice Way シリーズの第6回だ。第5回 Hooks と自動化 までで、一人の協働者の意図をどう設計するかを扱った。この投稿は、その一人の協働者がすべてをやらない構造について — 意図を横に分散させることについて書く。

0. 委任はひとつのコンテキストがすべてを抱えないために意図を分割すること

すべてのタスクを一人の協働者に渡せば、context window はすぐに埋まる。埋まれば判断の質が落ちる。質の低下は運営者が毎回ダブルチェックすることを強いる。すると運営者の意図の負荷が戻ってくる。

委任はこのループを断ち切る。大きなタスクを分割して Subagent に渡し、メインは各結果の要約だけを受け取る。 各サブは独自のコンテキストで一つのことに集中する。メインのコンテキストは判断に必要なものだけで埋まっている。

委任の本質は分散ではなく、判断モードの保護にあると考える。以前はすべてを一人のエージェントに抱えさせることが「責任ある設計」だと思っていた。いまでは判断に必要なものだけをメインが持つからこそ品質が上がるためだとわかっている。

ただし委任にはコストがある — 書面を書かなければならない、結果を検証しなければならない、統合しなければならない。分散の利得がそのコストを超えなければ、委任は損だ。書面 + 検証 + ゲートを三点セットで出荷するのは手間に見えるが、約束をコードで強制しなければドリフトが積み重なるためだ — 以前はそれを軽視した結果、後から整合性の修正コストを払った経験がある。

この投稿は、どの作業が委任する価値があるか、委任を説明責任に縛るゲートをどう構築するか、そして避けるべき落とし穴についての記録だ。

Subagent の仕組み自体は Anthropic Claude Code の subagents システムから借用している。この投稿はその仕組みをどのように活用するかの記録であり、発明ではない。

1. メインとサブの分担 — 誰が何を持つか

収束した分担。

領域メインサブ
判断権限すべての判断なし（メインに報告）
コンテキスト判断に必要なものだけタスクに必要なすべて
出力の長さ短く、判断中心長く、詳細（メインは要約を受け取る）
モデルポリシー分析・計画には強いモデルコード・ビルド・検索には高速モデル
メモリ全メモリインデックスを自動ロードタスクが触れるサブセットだけ
報告フォーマット運営者の目に向けてメインが吸収できる要約

核心は — メインは判断権限とメモリを持ち、サブは作業と深いコンテキストを持つこと。同じものを両方が持つことはない。重複は無駄なコンテキストだ。

この分担が崩れる最も一般的なパターン — メインがサブの作業の詳細をすべて知ろうとする。するとメインのコンテキストが埋まり、サブを使う理由が消える。

メインは何を知らないかを把握していなければならない。その知らない部分はサブが保持する。

2. 委任できるもの — 5つの条件

すべての作業が委任できるわけではない。以下の5つすべてをパスした作業だけがサブに渡る。

2.1 入力が閉じているか？

サブはメインのコンテキストのワンショットのスライスを受け取る。「X についてもっと教えて」のような双方向のやり取りはタスク中に難しい。だから最初に必要なすべてが書面の中に閉じていなければならない。

入力が閉じていなければ、サブは推測で埋める。推測はしばしば外れる。

2.2 出力を要約できるか？

サブの結果がメインコンテキストに戻るとき、入ってくるのは要約だけであるべきだ。結果が本質的に長く要約できない場合 — 例えば「100ファイルすべてをレビュー」— 委任の価値が縮む。メインはどうせ 100 ファイルの要約を吸収しなければならない。

2.3 判断権限はメインに留まっているか？

サブはタスク中に運営者の判断領域に踏み込んではならない。「DBスキーマを変更していいか？」はサブが決めることではない。そのような判断がタスク中に出うる場合 — 書面に権限テーブルを事前宣言するか、判断ポイントで停止して報告するようサブを設計する。

2.4 検証が自動化できるか？

運営者がサブの結果を毎回手動でチェックしなければならないなら、委任の利得は消える。自動検証スクリプトが付属している作業だけが委任できる。（§4 のゲートを参照。）

2.5 一つのことに集中しているか？

サブは一つのことをする。「このコンポーネントをリファクタリング + テストを追加 + ドキュメントを更新」のような複合作業は一つとして委任しない。三つに分割して三つの別々のサブに渡す。複数のことを抱えた単一サブは、絡まったコンテキストと曖昧な出力を生む。

3. 委任のコスト — 直接やったほうが良いとき

委任は常にネットポジティブではない。コストをまとめると。

  • 書面作成コスト — 何を・なぜ・どのように・どこで止まるかを書き出す
  • コンテキスト準備コスト — サブに必要なものだけを抽出して渡す
  • 検証コスト — 自動チェック + 結果を信頼するためのメインの再確認
  • 統合コスト — 結果をメインコンテキストに吸収する

この四つの合計が、直接やるコストを下回って初めて委任が合う。私の経験上 — 30分以内で終わる作業は委任すると損。2時間以上かかるか5ファイル以上触る作業は委任で得をする。

タスクサイズを無視した委任は委任ではない — ただの責任転嫁だ。

4. 委任ゲート — 約束をコードで強制する

委任が失敗する最もよくあるパターンは、書面は書かれるが検証とマージゲートがスキップされることだ。すると約束と結果のドリフトが積み重なり、ずっと後になって初めて表面化する。

このパターンで一度痛い目を見てから、今は委任のたびに同じ PR に必ず三点セットをまとめる。

4.1 書面（ブリーフ）

何を・なぜ・どのように・どこで止まるかを書き出した文書。サブは開始前に一度読む。書面には以下が含まれる：

  • ゴールと完了の定義
  • 入力（メインコンテキストから抽出したもの）
  • 出力フォーマット（どのファイル、どの構造）
  • 判断権限テーブル（自律 / メインに報告 / 禁止）
  • 検証方法（名前のついた自動スクリプト）
  • マージゲート（CI でパスしなければマージできないもの）

4.2 自動検証スクリプト

毎回手動で結果を確認しなくてよいよう、実行可能なスクリプトを用意する。「コンポーネント X のリファクタリング」の委任には、書面と同じ PR に npm run verify:component-x のようなものを含める。

検証スクリプトのない書面は書面ではない。意図の表明に過ぎない。

4.3 マージゲート

検証スクリプトが CI で実行され、通らなければマージがブロックされる。ゲートなしで約束を検証しようとすると — いつか検証が一度も実行されないままマージされる。

三点セット（書面 + 検証 + ゲート）は一緒に動く。どれか一つを落とすと、約束がコードで強制されなくなり、約束は崩れる。

約束がコードで強制されなければ、ドリフトが積み重なる。

5. 実際のローテーションの委任

毎週委任するものの一部。

5.1 広範なコードベース探索

「X キーワードが使われているすべての場所とその使われ方を探す」— サブへ。サブはリポジトリ全体を grep/glob/find で調べて結果をまとめる。メインは報告書だけを受け取る。

メインが直接やると — 何百ものマッチ結果がメインのコンテキストを埋める。判断のための空間が残らない。

5.2 ビルド・テストの実行

「この変更でリント + ビルド + テストを実行して要約して」— こちらもサブへ。サブが完全な出力を受け取り、メインには「passed」または「failed (3件、最初の2行: ...)」形式の要約だけが届く。

5.3 レビュー

「この PR をセキュリティの観点からレビュー」— サブが全体を読んで問題リストをまとめる。メインは件数と最も重要な3点だけを受け取る。

5.4 広範な外部調査

「このライブラリの既知のセキュリティ問題と代替案」— 外部調査。サブが複数のソースから集めてまとめる。メインは判断に必要な短い要約だけを吸収する。

5.5 積み重なった効果

タスクごとのコンテキスト節約は小さい。しかし一日5〜6回の委任が積み重なると — メインコンテキストは一日中、判断モードだけで稼働する。運営者が見る報告フォーマットが一貫し、「メインがすべてを抱えたせいで混乱している」パターンが消える。

6. 落とし穴 — 委任が失敗するパターン

少なくとも一度は踏んだ失敗パターン。

6.1 未検証の委任

最も一般的な落とし穴。書面を書いて委任した。結果が戻ってきた。検証方法がないので毎回手動チェック。すべての利得が消える。→ §4の三点ゲートが答えだ。

6.2 開いた入力の委任

「いい感じにやって」— サブが推測で埋め、推測は外れる。→ 短くても書面を閉じておく。

6.3 曖昧な権限

サブが「これは変えていいか？」という場面に直面し、自己判断で進む。運営者は意図と乖離した結果を見る。→ 書面に権限テーブル + 判断ポイントで停止して報告するパターン。

6.4 細かく切りすぎた委任

5分のタスクを委任する。書面作成コストがタスク自体を超える。直接やったほうが速い。→ 30分未満は委任しない。

6.5 統合コストを無視する

一度に統合しにくいサブの結果。異なるファイルを触る5つのサブが同時に動いて衝突する。→ 書面でサブの作業領域を事前に分割して重ならないようにする。

7. 委任か直接かの判断フロー

新しい作業が来たときに頭の中で回す判断フロー。

新しい作業
  ↓
30分以内か？ → yes → 直接
  ↓ no
入力が閉じているか？ → no → 直接（または先に入力を準備）
  ↓ yes
検証が自動化できるか？ → no → 直接（リスクが高い）
  ↓ yes
一つのことか？ → no → 分割して各々を委任
  ↓ yes
→ 委任（書面 + 検証スクリプト + マージゲートをまとめて）

このフローが内面化されると、委任か直接かの判断が速くなる。毎回新たに熟考しなくていい。

8. 一つの原則に圧縮する

委任設計の核心は一文に圧縮できる。

「メインは判断とメモリを持ち、サブは作業と深いコンテキストを持つ。委任は常に書面 + 検証 + ゲートをひとまとめで出荷する。」

これが成立するとき、委任はメインコンテキストを判断モードに保つ加速装置になる。壊れるとき、委任は責任転嫁になり、結果の統合が運営者の繰り返しの負担になる。

次の投稿では、委任された（そして直接行われた）作業が「完了」と言ったときに本当に完了しているかを強制するデバイス — 検証ループ、すなわちコード作業における「完了」の定義をどう固定するか — を扱う。