領域責任者エージェントパターン — Claude Code を組織化する

課題: 平らなエージェント群では何が壊れるか

Claude Code でエージェントを使い始めると、新しい定型作業が発生するたびに「これ専用のエージェントを作ろう」という判断に陥りやすい。スクレイピング担当・書類作成担当・レビュー担当——責務が明確に見えるため、増設を正当化しやすい。しかし複数のエージェントが並行して走り始めると、別の層の問題が浮かぶ。

第一に、判断の文脈が分散してしまう。「なぜこの提案書を送ったのか」「なぜそのコミットが実行されたのか」は個別エージェントのセッション記録に埋没する。組織全体で何が起きているかを問う横断的な問いに答えられなくなる。

第二に、同じ情報源を複数エージェントが重複して参照し始める。案件マスターシートをスクレイピング専用エージェントと営業判断エージェントがそれぞれ読みに行き、取得タイミングのズレでデータ整合が崩れる。「各エージェントが自分のコンテキストを完結させたい」という圧力が Single Source of Truth を蝕む。

第三に、責任の所在が曖昧化する。同じ案件に複数エージェントが非同期で並行アクセスすると、どちらの判断が意思決定の起点なのかがわからない。エラーが発生したとき、原因特定の調査起点がない。

これらは「ドキュメントで禁止すれば守る」問題ではない。エージェントの数が増えるたびに同じ問題が再発する。構造的に解決しなければならない。

パターン定義: 3人の領域責任者 + その下のスキル層

我々が採った解は、エージェントを判断レイヤーのみに限定する設計だ。現在 Synapse 基盤に定義しているエージェントは、3 人の領域責任者と 1 つのスコープ限定ワーカーのみである。

エージェント	責務	プリロードスキル（呼び出し権限）
`@director`	事業・P/L・ポートフォリオ全体の統括判断	`/pipeline`, `/recap`, `/minutes`, `/estimate`, `/invoice`, `/publish`
`@sales-director`	営業面（クラウドソーシング・アウトバウンド・案件受注）	`/scrape`, `/propose`, `/submit`, `/pipeline`
`@dev-director`	開発進捗・リソース・技術判断の統括	専用 system-developer への委譲権
`@lead-reviewer`	リード品質レビュー（媒体×ランク固定）	`/review`, 自スコープ内リードへのアクセスのみ

定型作業はすべてスキル（スラッシュコマンド）として実装する。提案書作成・議事録生成・シート更新・データ提出——判断を含まない実行業務はスキルに委ねる。スキルは「何をするか」のみを知り、「なぜするか」の判断文脈は持たない。責任者が「この提案を送るべき」と判断した後、/propose スキルはそれを淡々と実行する。

この階層分離により、何かが起きたとき追跡ルートが明確になる：

@sales-director が案件の勝率を判断
→ /propose スキル呼び出し
→ 提案書が生成・送付
→ 提案内容に疑問が出た場合、sales-director セッションを遡れば判断根拠が残っている

設計の核: メインスレッドが直接スキルを呼ばないルールとその理由

プロジェクト CLAUDE.md に明記しているルール：

業務実行を AI が自律的に行う場合は、必ず領域責任者エージェント経由で実行する。メインスレッド（会話の AI）が直接スキルを呼ぶことは禁止。

このルールが存在する理由を説明するために、逆向きに考えてみる。メインスレッドが直接 /propose を呼び出した場合、何が失われるか。

判断痕跡が消える。スキル実行の記録は残るが「なぜそのスキルを実行することになったのか」という意思決定プロセスが記録されない。後で監査・レビュー・設計見直しをするとき、「営業責任者がこの案件を判断したから提案書を作成した」という文脈が欠けたままになる。

責任者としての学習が起きない。 sales-director が 10 件の案件提案をリードしたとき、セッションに残る判断鎖は「この業界にはこういうアプローチが効く」「このタイプの企業には◯◯が刺さりやすい」という責任者固有の暗黙知になる。次の判断を改善する材料になる。メインスレッドが直接スキルを叩く運用では、この蓄積が起きない。

並列委任が機能しない。 @lead-reviewer media-A premium と @lead-reviewer media-B budget が同時に動いているとき、共有リソース（提案文テンプレート・成約ロジック）を両方が参照する必要があっても「どちらのリード判断が優先か」が不明確になる。責任者層が判断を集約していれば、必要なときに調整できる。

補足として、ユーザーが直接 /スキル名 をコマンドで実行した場合の扱いは別だ。この場合 Claude Code harness が直接そのスキルを動作させる設計であり、これは正常な操作である。制約は「AI エージェントが自律判断で動くとき」に限定される。

実装の具体形: Yakumo での適用例

Synapse 設計で領域責任者パターンを導入した具体的なフロー例を示す。

営業フロー例

ユーザーが @sales-director 今月のホットリードをリスト化してください と指示
@sales-director が CRM スプレッドシートから今月のリード抽出・企業情報確認を判断
案件の内容に応じて提案戦略を立案（新規営業か既存案件か、金額帯に応じた提案文体など）
提案を実行することを判断 → @sales-director が /propose スキルを呼び出し
/propose スキルが、@sales-director の判断に基づいて提案書を生成・送付
提案結果（返信率・成約率）を tracking → 次回の判断改善に繋がる

ここで重要なのは、ユーザーが直接 /propose を叩かないという点だ。@sales-director が「この案件は提案すべき」「このタイミングで提案すべき」という 2 つの判断を経た上で、スキル実行が起こる。

開発フロー例

開発系のタスクは例外設計として扱われる。メインスレッドで直接 system-developer に委譲する。理由は 3 つ：

コンテキストウィンドウの効率: 大量のコード読み書きには Sonnet ベースの専用エージェントが適している
スキルプリロード: dev-pipeline dev-impl dev-verify など開発系スキル群は、開発エージェントにプリロードされており、メインスレッドからの呼び出しより効率的
技術判断の集約: 「何のコードを、誰が、どういう設計で書いたか」は @dev-director に一元化したい

ユーザーが marine 案件の開発進捗はどうなってますか？ と問うと、メインスレッドは @dev-director marine 案件の開発進捗を確認してください と委譲し、@dev-director が必要に応じて @web-developer や @system-developer に実装委譲する。この連鎖により、詳細な実装コンテキストをメインスレッドに乗せずに済む。

落とし穴と運用の現実

効果（実績）

判断履歴が追跡可能になった。提案書の内容に異議が出たとき、@sales-director のセッション記録を遡れば「なぜこのアプローチを選んだのか」「どのデータに基づいているのか」が復元できる。エージェント間の整合確認コストが 40% 程度削減された。

責任者ごとに経験が蓄積される。 @sales-director が 20 社への提案を重ねると、「電子部品商社には ◯◯ アプローチが刺さりやすい」「SaaS 企業には初期段階で ××を見せるべき」という業界別の判断パターンがセッション内に蓄積される。次の提案判断がより精密になる。

スキルの再利用性が上がった。 /pipeline スキルは @director, @sales-director, @lead-reviewer から呼ばれる。それぞれ文脈は異なるが、実行ロジックは共通だ。判断と実行の分離が、スキルの汎用性を高めている。

落とし穴（現在進行中の調整）

ルール記述だけでは AI が守らない。 CLAUDE.md に「メインスレッドが直接スキルを呼ばない」と書いても、Claude が自律的に /propose を実行してしまう場合がある。言語化だけでなく、.claude/settings.json の PreToolUse hook や、エージェント定義内の constraint として実装まで落とす必要がある。

責任者が「何でも受け付ける窓口」になりやすい。 @director に曖昧な指示を投げると、文脈から何でも引き受けようとする傾向がある。「開発進捗の確認」と「営業判断」の両立を求められると、どちらかが雑になる。事前に依頼を分解してから渡すほうが、並列委任が機能しやすい。

「スキルを作れば解決」への回帰圧力。新しい定型作業が出るたびに「スキル化しよう」という判断が起きる。これ自体は正しいが、設計をリセットして「これはエージェント化すべき新領域なのか、既存責任者配下のスキルなのか」を毎回問い直す必要がある。ルールの劣化を防ぐコストが継続的にかかる。

非自明な洞察: パターンの本質

領域責任者エージェント設計の本質は「AI に作業させる」のではなく「AI が組織として動くための意思決定フレームを構築する」ことにある。

エージェントと人間の組織に例えるなら：

判断レイヤー（エージェント）: 企業の役員会議。事業方針・リソース配分・案件判断を行う。
実行レイヤー（スキル）: オペレーション部門。役員の判断を実行する。

組織が成長するとき、オペレーション効率を上げるために現場が独断で動き始めると組織は分裂する。判断を役員層に集約し、実行を定型化することで、スケール可能な組織が成立する。

エージェント組織も同じ原理が働く。判断と実行を分離することで、初めて複数エージェント・複数スキルの並列運用が追跡可能になる。

まとめ

領域責任者エージェントパターンは、複数 AI エージェントの増殖によって判断文脈が散逸する問題に対する構造的解答である。

実装の要点：

エージェントを判断レイヤーに限定する — 責務の広さではなく「経営判断を持つか」で層を分ける
定型業務はスキルとして分離する — 判断なしで実行だけを行う処理は一切スキル化
メインスレッドが直接スキルを呼ばないルール化 — 委任チェーンとして判断履歴を記録可能にする
開発系は例外として専用エージェント委譲 — コンテキストウィンドウと技術判断の効率化

理論としては単純だが、運用を継続する地道さが大半だ。「また新しいスキルを作ろう」という圧力に対して「それは既存責任者配下なのか、新領域なのか」を毎回問い直す。ルールを CLAUDE.md に書くだけでなく、hook や settings で強制する。エージェント間の整合が崩れたとき、何が原因なのかを体系的に追跡する。

現在も運用しながら調整を続けている。判断履歴が追跡可能なエージェント組織を構築することで、初めて AI 駆動開発が「AI 任せ」から「AI との責任分担」へ転換する。