L5 ─ Sub-agent と MCP で多体システム化

階段の最上段。Claude を 1 体から N 体に増やす + 外部システムを道具として持たせる ことで、1 体では捌けない複雑なワークフローを組む。

ただし最初に強く釘を刺しておく：全員が L5 まで登る必要はない。前章までで多くの業務は十分自律化できる。L5 は「それでも必要な時だけ」の段階。

なぜ L5 は最後なのか

L5 は強力だが、複雑性のコストが急上昇する：

graph LR
  L1[L1: 型化] -->|低| Cost1[設計コスト 1x]
  L2[L2: Hooks] -->|+| Cost2[2x]
  L3[L3: Actions] -->|++| Cost3[3x]
  L4[L4: Scheduled] -->|+++| Cost4[4x]
  L5[L5: Multi-agent] -->|++++| Cost5[10x]

  style Cost5 fill:#ffe1e1

L5 は L4 の 2-3 倍 の設計コストがかかる感覚。Sub-agent 間の調整、context isolation の設計、MCP server の認証管理、debug の困難さ ── これらすべてが乗っかってくる。

L4 までで十分な大半のタスクを、L5 にしないこと。これが L5 の唯一にして最重要の心得。

L5 を構成する 2 つの軸

L5 には 2 つの直交する軸がある：

graph TB
  subgraph "Sub-agent 軸"
    S1[Main Claude]
    S1 --> SA[Sub-agent A<br/>generator]
    S1 --> SB[Sub-agent B<br/>validator]
    S1 --> SC[Sub-agent C<br/>researcher]
  end

  subgraph "MCP 軸"
    M1[Claude]
    M1 -.MCP.-> Tool1[GitHub]
    M1 -.MCP.-> Tool2[Slack]
    M1 -.MCP.-> Tool3[Database]
    M1 -.MCP.-> Tool4[Browser]
  end

• Sub-agent：Claude を複数体に増やす（縦の多体化）
• MCP：1 体の Claude に外部システムを道具として持たせる（横の拡張）

両者は組み合わせる。「外部 DB に MCP でアクセスする sub-agent A」と「Slack に MCP で投稿する sub-agent B」を、main Claude が調整する、のような構成。

Sub-agent ─ 役割分担と context isolation

定義方法

.claude/agents/<name>/agent.json：

{
  "name": "validator",
  "description": "生成されたコンテンツが制約を満たすかを検証する。文字数 / 禁止語 / フォーマット規則 / 引用元の正しさをチェック",
  "system_prompt": "あなたは厳格な検証者です。創造性は不要、機械的に制約違反を検出してください。",
  "tools": ["Read", "Bash"],
  "model": "claude-haiku-4"
}

ポイント 4 つ：

• description が起動の鍵。main Claude がこれを読んで使うかを判断
• system_prompt で人格を絞る。validator なら「創造性不要」と明示
• tools を絞る。validator に Edit を渡すと validator が編集を始めて役割が崩れる
• model でコスト調整。検証なら Haiku で十分、生成なら Sonnet/Opus

起動方法

main Claude から：

このコンテンツを validator agent で検証してください。
[Agent: validator]

または Task tool 経由で並列起動。

Context isolation の効果

main Claude は sub-agent の中身（やりとりの全文）を見ない。結果サマリーだけ受け取る。これが重要：

graph TB
  M[Main Claude<br/>context: 50K tokens]
  M -->|delegate| S[Sub-agent<br/>独自 context: 20K tokens]
  S -->|summary 500 tokens| M

  Note1[Main は sub-agent の<br/>20K 全文を読まない]

  style M fill:#e1f5ff
  style S fill:#fff4e1

これで main の context を圧迫せずに重い処理を委譲 できる。リサーチ系 task や大量ファイル読み込みは特に効く。

実例 1：Anthropic Growth Marketing の二体構成

Anthropic 公式 PDF「How Anthropic teams use Claude Code」 に詳述されている事例。

やっていること

広告コピーの大量生成。Google Ads / Meta Ads など各プラットフォームには 文字数制限 や 禁止語リスト があり、人間が手作業で variation を作るのは退屈で時間がかかる。

graph LR
  Input[入力 CSV<br/>商品 / ターゲット / トーン] --> Gen[Generator Agent<br/>文案 100 件生成]
  Gen --> Val[Validator Agent<br/>制約チェック]
  Val -->|pass| Out[出力 CSV]
  Val -->|fail| Gen

  style Gen fill:#e1f5ff
  style Val fill:#fff4e1

Generator は creative にコピーを書く。Validator は機械的に：

• 文字数（各プラットフォームの上限）
• 禁止語（「No.1」「最高」など景品表示法引っかかり語）
• フォーマット（CTA 必須、商品名含有率）
• 引用元の事実関係

これで 数百 variation が数分で生成 される。

なぜ 2 体に分けるのか

1 体でやらせると、Claude は creative と検証を 同時に やろうとして、両方が中途半端になる。役割を分けると：

• Generator は制約を意識せず creative になれる
• Validator は厳格にチェックできる
• 失敗（reject）を generator にフィードバックして再生成できる

これは 「責務分離」のコード設計と同じ思想 を agent に適用したもの。Single Responsibility Principle for agents。

実例 2：研究アシスタントの 3 体構成

リサーチ系 task の典型構成：

graph TB
  Main[Main Claude<br/>調整役] --> R[Researcher<br/>web 検索 + URL 取得]
  R --> S[Summarizer<br/>各 URL を要約]
  S --> W[Writer<br/>統合した記事 draft]
  W --> Main
  Main --> User[ユーザーに提示]

  style Main fill:#e1f5ff
  style R fill:#fff4e1
  style S fill:#fff4e1
  style W fill:#fff4e1

各 agent の役割：

• Researcher：WebSearch で情報源を 10-20 件収集、信頼度評価
• Summarizer：各 URL を 200-300 字に要約（並列実行）
• Writer：統合した記事 draft を書く（main と人格が違う、文体特化）

これで main の context を圧迫せず、各 agent が専門性を発揮 できる。

MCP ─ Claude を外部システムに繋ぐ

MCP の本質

Model Context Protocol は、LLM と外部システムを繋ぐプロトコル。Claude Code に MCP server を登録すると、Claude が そのシステムをツールとして使える ようになる。

.claude/mcp.json：

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    },
    "slack": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-slack"],
      "env": {
        "SLACK_BOT_TOKEN": "${SLACK_BOT_TOKEN}"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-postgres"],
      "env": {
        "POSTGRES_URL": "${DATABASE_URL}"
      }
    }
  }
}

これで Claude は GitHub の PR を読んだり、Slack に投稿したり、DB をクエリしたりできる。

公式 / コミュニティで人気の MCP サーバー

カテゴリ	サーバー	用途
GitHub	@modelcontextprotocol/server-github	PR / Issue / repo 操作
Slack	@modelcontextprotocol/server-slack	メッセージ送受信
DB	@modelcontextprotocol/server-postgres / -sqlite	クエリ実行
Browser	Puppeteer / Playwright MCP	スクレイピング / 自動操作
メモリ	@modelcontextprotocol/server-memory	永続化記憶
Drive	Google Drive MCP	ファイル読み書き
検索	Perplexity MCP	高品質 web 検索

awesome-claude-code のような curated list が充実してきている。

MCP の現実的な勝ちパターン

調査した一次事例から、MCP が本当に効く 用途は限定的：

勝ちパターン A：GitHub MCP で PR コンテキスト集約

LINE ヤフー事例の核。gh CLI でも同じことはできるが、MCP は：

• LLM が自然に呼び出せる（権限管理は MCP server 側）
• レスポンスが構造化されている（JSON 直接利用）
• 認証を一箇所に集約できる

勝ちパターン B：Slack MCP で「人への通知」

「scheduled task の結果を通知する」「障害を即報する」など、人間の意識を使う 場面。

勝ちパターン C：DB MCP で「プロダクション読み取り」

read-only 接続で「ユーザー数の現状確認」「異常データの検出」など。書き込みは MCP 経由でやらない（事故が起きると致命的）。

勝ちパターン D：Memory MCP で session 跨ぎの記憶

「先週このプロジェクトで何を決めたか」を MCP server に保存しておくと、次の session で参照できる。CLAUDE.md より動的、.claude/local.md より永続的。

MCP の落とし穴

落とし穴 1：tool 数の爆発

MCP を多数登録すると、Claude が見える tool 数が膨大になる。context が圧迫される + 選択ミス頻発。

対策：必要な MCP だけ project 単位で有効化。

落とし穴 2：認証情報の管理

各 MCP server に token / API key が要る。複数環境（local / CI / Cloud Routines）で同期するのが地獄になる。

対策：.env + direnv / Doppler / 1Password CLI など、shared secret manager を使う。

落とし穴 3：MCP server 自体のバグ

community 製の MCP は品質バラつき。Claude が「動かない tool」を呼び続けて context を消費する事態がある。

対策：使う前に手動で動作確認、使わなくなったらすぐ外す。

L5 設計の 3 原則

原則 1：「分けるべき時にだけ分ける」

役割分担が 本当に効くか を最初に問う。

graph TB
  Q1[1 体でやると<br/>役割が混じって品質が落ちる?] -->|Yes| Split[Sub-agent に分ける]
  Q1 -->|No| One[1 体で OK]

  Q2[Context が爆発して<br/>main が処理しきれない?] -->|Yes| Split
  Q2 -->|No| One

  Q3[並列実行で時短になる?] -->|Yes| Split
  Q3 -->|No| One

  style Split fill:#e1f5ff
  style One fill:#e1ffe1

「multi-agent が流行りだから使う」は最悪のアンチパターン。

原則 2：「Sub-agent の output を必ず構造化する」

main → sub の prompt は自由でいいが、sub → main の output は必ず構造化（JSON / YAML / 表）。自然言語の感想文を main が解釈するのは脆い。

[Sub-agent への prompt]
結果は以下の JSON で返してください：
{
  "violations": [{"type": "...", "detail": "..."}],
  "passed": true/false,
  "confidence": 0.0-1.0
}

原則 3：「コストを segment ごとに測る」

L5 は コストが見えにくい。Sub-agent 起動ごとに：

• どの model を使うか
• 何 token 消費したか
• 結果サマリーは何 token で main に戻したか

を計測する。Hooks の PostToolUse で sub-agent 起動を log すると後から分析できる。

L5 で最もやらかしがちな 3 つの過剰設計

過剰設計 1：「とりあえず 5 体構成」

Generator / Validator / Reviewer / Fixer / Reporter の 5 体構成 ── みたいなやつ。3 体以上は調整コストが指数的に上がる。最大 2-3 体で済むワークフローに分解する。

過剰設計 2：「sub-agent の中で sub-agent」

ネストするほど debug 困難。1 階層 に留める。

過剰設計 3：「全部 MCP で繋ぐ」

GitHub も Slack も DB も browser も email も calendar も MCP で繋ぐ ── 結果、context が tool definition で埋まり、本題に進めない。3-4 個まで に絞る。

副業視点での L5

L5 が「副業で月100万」と謳われる時、たいてい：

Generator agent が記事を量産し、SEO agent が最適化し、Publisher agent が WordPress に投稿する全自動システム

を売っている。これが破綻する理由：

1. Google は AI 量産記事に厳しい（Helpful Content Update 以降）
2. Validator がない構成は事故る（誤情報 / 著作権侵害）
3. 「全自動」は監査責任の所在を消す（誰が誤情報の責任を取る?）

本物の L5 副業活用は地味で：

• 特定領域のリサーチ自動化（自分の専門領域だけ）
• 顧客向けレポート生成（最終承認は人間）
• コードベース横断 refactoring（PR 単位で人間レビュー）

「自分が責任を取れる範囲を超えない」のが L5 の本物の使い方。

L5 のチェックリスト

graph TB
  Pre[L1〜L4 が固まっているか] --> C1[1 体では駄目な理由が明確か]
  C1 --> C2[2-3 体に分割できるか]
  C2 --> C3[各 agent の output 構造化]
  C3 --> C4[MCP は 3-4 個に絞る]
  C4 --> C5[コスト計測の仕組み]
  C5 --> C6[fail-safe 設計]
  C6 --> Live[本番投入]

  style Pre fill:#e1f5ff
  style Live fill:#e1ffe1

この章の要点

• L5 = 多体化 (Sub-agent) + 外部システム接続 (MCP)
• L1〜L4 で十分な大半のタスクを L5 にしないこと
• Sub-agent：description で起動判断、system_prompt で人格絞り、tools を最小化、model でコスト調整
• Anthropic Growth Marketing：generator + validator の 2 体で広告コピー大量生成
• MCP の勝ちパターン：GitHub / Slack 通知 / DB read-only / Memory
• 3 原則：分けるべき時だけ / output 構造化 / コスト segment 計測
• 過剰設計の罠：5 体構成 / 入れ子 / MCP 詰め込み
• 副業視点：「全自動」を売る商材は監査責任を消している。本物は範囲を絞る

次章への問いかけ

ここまで階段を 5 段登り切った。だが本当に登るべき相手はどれか?

世の中には L5 を売りつける情報商材も、L1 すら扱わない地味な記事もある。次章では 偽物の指紋・本物の指紋 を表裏一体で並べる。30 秒で見分けるためのチェックリスト。

＋ － ⟳ ✕