Claude Code のサブエージェント構成は、業務形態で大きく変わる — 1人多案件横断者の設計例

はじめに

Claude Code のマルチエージェント設計パターンは、すでに classmethod の整理記事 などで体系化されています。Orchestrator-subagent、Agent Teams、Generator-Verifier、Message Bus、Shared State の5つです。

この記事の主張は、パターンの中身ではなく 「どのパターンを選ぶかは、業務形態が支配的な変数である」 という1点に絞ります。

きっかけは、社内で「同じツール（Claude Code）を使っているのに、人によってサブエージェントの構成がまったく違う」という話題が出たことでした。違いの理由を「個人の好み」で片づけると、後続のメンバーは慣れたパターンに固まって、業務にフィットしない構成のまま運用してしまう危険があります。

本記事では、

1. サブエージェント設計を 「分離・共有・捨てる」 の3点フレームに分解する
2. その例として、私の構成（1人で複数プロジェクトを横断調査するタイプ）を3点フレームに沿って公開する
3. 別の業務形態だったら3点がどう変わるかを対比する

の三段構成で書きます。パターンそのものの解説は最小限に留め、引用と参照で済ませます。

サブエージェント設計の3点フレーム

サブエージェント設計の本質は 「何を分離し、何を共有し、何を捨てるか」 の3点に集約できると考えています。

設計判断	何を決めるか	業務側で何に対応するか
分離	どのコンテキストを隔離するか	案件・ドメインの数と切り替え頻度
共有	何を持続させるか・誰に渡すか	チーム規模と、共有相手が人間か AI か
捨てる	何をやらないか	業務の本丸が「実装」か「判断」か

重要なのは、3点それぞれが コーディングスタイルや個人の好みではなく、業務側の物理制約に対応している という点です。1日にいくつの案件を切り替えるか、結果を誰と共有するか、自分の本丸はどこか — これらが先に決まれば、3点の答えはある程度絞り込めます。

もちろん、業務形態が同じでも認知スタイルや既存ツール環境で多少のブレは出ます。それでも、業務形態を無視して設計を語ると、後でほぼ確実に再構成することになります。設計を語る前に、まず業務形態を語るのが順序だと思います。

私の業務形態（抽象化）

具体的な業務内容は割愛しますが、構造だけ書くと次のとおりです。

• 1日に複数の異なるドメインの案件を切り替える（ドメインの違いは「フロントエンドとバックエンド」程度ではなく、「業務システム開発」と「経営判断資料作成」くらい違う）
• 本丸はコードを書くことではなく、判断と意思決定
• 成果物は人間も読む（チーム・上位者向けに残す必要がある）
• チーム並列開発はしない（私の手元で完結する案件が中心）

この業務形態には次の制約があります。

• 案件 A で読んだ大量のコードや議事録が、案件 B での判断ノイズになる
• 私の中だけに知見を持っていても価値がない（誰かと共有しないと意味がない）
• 実装の細部より、調査結果の要約と判断の根拠が重要

私の構成 — 3点フレームに沿って

ベースは Orchestrator-subagent です。以下、3点それぞれの設計判断を順に書きます。

分離：「隔離コンテキストで調査してサマリだけ返す調査員」を並べる

サブエージェントは「実装担当」ではなく、調査員として振り切っています。

エージェント	役割	持つツール
backlog-investigator	Backlog 課題の本文・コメント・親子・類似課題を調査	Backlog MCP の read 系
codebase-explorer	巨大コードベースの探索・関数追跡	Read, Grep, Glob, Bash
obsidian-researcher	Obsidian vault 横断検索	Obsidian MCP の read 系
Explore	高速な read-only 探索	検索系一通り
Plan	実装プランニング	検索系 + 計画立案

全員に共通する規約は 「隔離コンテキストで動き、結果はサマリだけ返す」 の1点に絞っています。具体的には次の3つです。

• 各エージェントの system prompt に「メインの会話に大量のファイル内容を流し込まずに済むよう、要点だけサマリで返す」と明記する
• 出力は固定フォーマット（経緯・要点・引用元）の構造化サマリで、生データは原則含めない
• read-only ツールだけ持たせ、書き込み権限は与えない

この設計の目的はシンプルで、メインの Claude のコンテキストを意思決定に必要な情報だけに保つ ためです。案件 A の50ファイル分の生コードを案件 B に持ち込まない、という業務制約に直接対応しています。

共有：永続化は「外部の人間可読ストア」に逃がす

AI 内部に閉じた共有ステートを作るのではなく、外部の人間可読ストア（私の場合は Obsidian と Backlog、組織によっては Notion や Confluence も該当）を共有ステートとして使っています。

• 技術調査・意思決定ログ：Obsidian vault
• 案件の経緯・タスク：Backlog
• 一過性のメモ：会話内の Plan / TaskCreate

共有の設計原則：AI だけが読む内部ストアを作らない

これは共有設計の上で、私が最も強く意識している原則です。

永続化される情報は 必ず人間も読める形にする。エージェント間専用のメモリ、AI 同士の内部対話ログ、暗黙のキャッシュ — こうした「AI だけが読む層」を作ると、組織知化されないまま情報が滞留します。

意図的に外部ストアに逃がすことで、次の利点があります。

• AI のメモがそのまま組織資産として残る
• 自分が休んでも、他のメンバーが同じ情報にアクセスできる
• AI 出力の品質を人間がレビューできる（AI だけの世界に閉じない）

「成果物は人間も読む」という業務形態の制約から逆算した設計です。組織で AI 運用を広げる場合、ここを最初に決めておかないと、後で「AI のメモが資産か負債か分からない」状態になります。

捨てる：実装の深掘り Worker と、エージェント側の Verifier

捨てたものが2つあります。

1つ目：実装を長期で進める Worker。Agent Teams パターンの「深い理解を持ったまま走り続ける Worker」は採用していません。私の本丸は実装ではなく判断なので、コードを長く育てるよりも、調査結果を早く意思決定に変換するほうが価値が高い。

2つ目：エージェント側の Verifier。レビュー・検証は専用エージェントを作らず、skill（自作スラッシュコマンド）に分業させています。

• /review：push 前のローカルレビュー
• /verify：実装が要件を満たすか実機確認
• /simplify：変更コードの重複・無駄を発見し修正
• /ultrareview：複数エージェントを並列分散させたクラウド実行レビュー

subagent と skill の切り分け基準

「Verifier をなぜ skill 側に逃がすのか」を一段掘り下げると、両者の使い分け基準は次の2軸に整理できます。

軸	subagent	skill
主目的	コンテキスト隔離：メインに大量の生情報を流したくない	再現性：同じ手順を何度も実行したい
起動	メインの判断で動的に呼び出す	ユーザーが明示的に発火する
出力	構造化サマリで戻る	プロセス完了

調査は隔離が要るので subagent、レビューは決定論的に走らせたいので skill、という分け方です。

メリット

実運用してきた所感です。

• 案件切り替えの認知コストが激減：案件 A の調査ノイズが案件 B に混ざらない。サブエージェントがサマリだけ返すので、メインの思考は意思決定に集中できる
• チーム知化と相性が良い：永続化先が外部の人間可読ストアなので、AI のメモがそのまま組織資産になる
• 責務分離が明示的：「調査はサブ、判断はメイン、検証は skill」と分かれているため、何かが詰まったときに犯人が見つけやすい

デメリット

正直に書きます。

• チーム並列開発には向かない：複数メンバーが同時に走るプロジェクトでは、調査員モデルではスループットが足りない。Agent Teams 寄りに作るべき
• 長期コンテキストを使い倒せない：Agent Teams のような「深い理解を持ったまま走り続ける Worker」の旨味は捨てている
• 構成の認知負荷が高い：「どのエージェントを呼ぶか」「どの skill を起動するか」を意識する必要がある。初期コストはそれなりにかかる

別の業務形態だったら3点がどう変わるか

私の構成を「正解」として提示する気はありません。3点フレームを別の業務形態に当てはめると、設計は次のように振れます。

業務形態	分離	共有	捨てる
1機能を3ヶ月以上育てる	コンテキストは長期保持、隔離より持続が重要	AI 内部の長期ステートで持つ	案件切り替え用の調査員は不要
バグ票・QA レビューが本丸	生成と検証を分離するのが主役	チケットシステムを共有ステートに	実装系 Worker は最小限
動的に対象が増減する	疎結合で新規エージェントを足せる構造	イベントバスで仲介	中央コーディネーターは捨てる
ペアで探索する	共有ストレージで知見を相互参照	Shared State に集約	個別エージェントの専有メモリは捨てる

同じ3点フレームでも、何を分離し、何を共有し、何を捨てるかは業務形態次第で逆向きにすら振れます。

数ヶ月運用しての定性所感

定量データは取っていないので、検証ではなく定性所感として書きます。

• 案件切り替え時の摩擦は明確に減った。以前は会話のコンテキストに案件 A の議事録引用が残ったまま案件 B を始めて、B の判断に A の文脈が混ざるという失敗が複数回あった。隔離後はこれが発生していない
• 逆にハマらなかった構成もあった。サブエージェント同士を直接対話させる構成（メインを介さず情報を渡す）を試したが、メインが進捗を把握できなくなり中断した
• 業務形態が変われば設計も変わるはず。今後チーム並列の比重が増えれば Agent Teams 寄りに振り直す予定

確証バイアスを除いた厳密な検証ではない点は、正直に書いておきます。

自己診断：あなたの業務形態はどの3点に振れるか

末尾に、3点フレームを使った自己診断の問いを置きます。記事を閉じた後にそのまま使えます。

問い	回答が示唆するもの
1日に切り替える案件数は？ ドメインの差は大きいか？	多くて差が大きい → 分離を強める（私の構成型）
成果物は自分だけのメモか、チーム・上位者にも共有するものか？	共有が必要 → 共有ステートを人間可読ストアに逃がす
本丸は「作る」か「決める」か？	決める → 実装系の長期 Worker を捨てる

3つの問いに答えた結果と、私が選んだ Orchestrator-subagent 中心の構成を比べてみてください。一致しないなら、別のパターンに寄せたほうが業務形態にフィットするかもしれません。

おわりに

マルチエージェント設計の議論は、パターン名の解説で止まりがちです。実運用に落とすと、本当に効いてくるのは 「自分の業務形態を言語化し、それに合うパターンを選ぶ」 という、地味で個別的な判断です。

Claude Code のエージェント構成を見直すときは、ツールから入るのではなく、自分の1日を最初に言語化してみる ことをおすすめします。3点フレーム（分離・共有・捨てる）は、その言語化を手早く済ませるための取っ手として使ってみてください。