CLAUDE.md を整え、Skills を書き、MCP を繋ぎ、Hooks で自動チェックを回す。ここまで来ると「中級者」を名乗れます。
でも、その次で多くの人が同じ壁にぶつかります。エージェントを2体3体と増やした瞬間に、なぜか全体が遅くなり、しかも事故が起きやすくなる。 私も最初はここで盛大に転びました。
この記事は入門〜中級のロードマップ（CLAUDE.md / Skills / MCP / Hooks）のその先、つまり「1体のエージェントを使いこなす」から「複数のエージェントを“組織”として運営する」に踏み込むときの運用パターンを4つに絞って書きます。個人で12部門ぶんのエージェント体制（庶務の約90%を自動化、運用は月$200のプランのみ）を回してきた中で、実際に効いたものだけを残しました。
中級までの“おさらい”と、上級で変わる関心事
まず立ち位置の確認です。中級までは「1体のエージェントの精度」を上げるゲームでした。CLAUDE.md はその中心です。
私も新規プロジェクトで毎回同じ前提を説明するのに1回5〜10分かけていた頃、技術スタック・規約・ディレクトリ構成・禁止事項を約200行の CLAUDE.md にまとめただけで、前提説明が不要になり1日あたり約30分が浮きました。これは「AIへの引き継ぎ書」を書く感覚で、新人向けドキュメントとまったく同じです。
ところが、エージェントを増やして“組織化”しはじめると、関心事がガラッと変わります。
| 観点 | 中級（1体を極める） | 上級（複数体を運営する） |
|---|---|---|
| 中心ファイル | CLAUDE.md | ペルソナ + ルーティング + 承認キュー |
| 速さの源 | プロンプト最適化 | 役割分担・コンテキスト分割 |
| リスク | 出力ミス | 外部への誤操作・暴走 |
| 並行性 | 気にしない | git 競合・同時書き込み |
| コスト | ほぼ意識しない | トークン単価×体数で急増 |
上級で効くのは、プロンプトの巧さより運用設計です。以下、順に見ていきます。
パターン① 役割分担 — 「一人に全部」をやめる
最初にやりがちなのが、優秀な1体に何でも頼むことです。これが罠でした。
ある個人プロジェクトで全業務を1体に集約したところ、コンテキストが肥大化して応答が遅くなり、的外れな回答が増えていきました。人間で言えば、経理も開発も営業も一人に押し付けてパンクさせている状態です。
そこで役割別にエージェントを分割し、受付役（秘書）が用件を振り分ける構成に変えました。
agents/
├── secretary.md # ルーティング担当（受付）
├── dev.md # 開発担当
├── writer.md # 文章担当
└── ops.md # 運用・自動化担当
各エージェントには専用のペルソナファイルを持たせます。ポイントは、話し方・一人称・語尾・専門分野・対応方針を明文化すること。私の場合は約50行のペルソナ定義でトーンが安定し、「場面によって別人のように応答がブレる」問題が消えました。カスタマーサポートの対応マニュアルと本質は同じです。
役割分割の結果は明確でした。各エージェントの応答精度が約40%向上し、処理速度は平均2倍。「一人に全部頼む」より「適材適所に振る」ほうが圧倒的に良い——人間の組織設計とまったく同じ原理です。
判断の目安はシンプルにこうしています。
- 1体のコンテキストが「複数の専門領域」にまたがり始めたら分割のサイン
- 分割したら、受付役（ルーター）を1体だけ立てて入口を一本化する
- 増やすのは役割単位。「なんとなく2体目」は作らない
パターン② 承認フロー — 外部への操作だけは自動化しない
組織化して怖いのは、エージェントが外向きのアクションを自律実行することです。
一度、エージェントにメール送信や外部API呼び出しまで自律で任せたところ、誤送信を1回やらかして冷や汗をかきました。内部でファイルを書き換えるのと、外に向けてメールを飛ばすのは、事故ったときの重さが桁違いです。
そこで、外部向けアクションには必ず「承認キュー」を挟みました。ドラフト生成 → キュー格納 → 人間承認 → 実行の4ステップです。
# 承認が必要 vs 自動でよい の線引き（チートシート）
自動でOK（内部・可逆） 承認必須（外部・不可逆）
-------------------------- --------------------------
ファイル読み書き メール送信
内部データ集計 SNS投稿
下書き生成 請求書発行
テスト実行 本番デプロイ
ローカルのコード修正 外部APIへの書き込み
実装イメージはこれだけです。
# エージェントは「実行」ではなく「キューへの投函」までしかやらない
queue_action() {
local type="$1" payload="$2"
echo "$(date -Iseconds) | $type | $payload | PENDING" >> approval-queue.md
echo "承認待ちに積みました。承認後に実行します。"
}
# 人間が queue を確認 → APPROVED に書き換え → 実行スクリプトが拾って実行
効果は劇的で、誤送信・誤操作がゼロに。承認作業そのものは1日5分程度なので、安全性と効率をきちんと両立できます。「内部操作は自動、外部操作は承認必須」が、体感でいちばん安全なラインでした。
パターン③ git 並行制御 — 複数の書き手が同じブランチに触る問題
これは中級記事がまず触れない、上級ならではの課題です。
エージェント・複数ターミナル・cron・常駐ワーカーが同じブランチに同時に commit しようとすると、index の競合や rebase の途中停止が普通に起きます。1体で使っていたときは存在しなかった問題が、組織化した瞬間に牙をむきます。
解決の原則は「全ての書き手を1つのロックに通す」こと。commit / push / pull --rebase を直接叩かせず、ラッパー経由に一本化します。
#!/bin/bash
# ai-git.sh — 全エージェント共通の書き込みゲート
LOCK=/tmp/repo.lock
exec 9>"$LOCK"
flock 9 || { echo "他の書き手がロック中"; exit 1; }
git add "${@:2}" # 明示パスのみ add（全部 add しない）
git commit -m "$1"
git push
# flock はスクリプト終了時に自動解放
ルールとしては次の3つを守るだけで、競合はほぼ消えます。
-
書き込みは必ずラッパー経由（
git commitの直接実行を禁止にする） -
git add .をしない。触ったファイルパスだけを明示的に add する - 大きく独立した作業は worktree で物理的に分離して並走させる
読み取り系（status / log / diff）は自由にやらせてOKです。ロックが要るのは書き込みだけ。「全書き手が同一ロックを通る」——この一点を徹底できるかどうかで、並行運用の安定性がまるで変わります。
パターン④ コスト管理 — 体数×トークンで静かに膨らむ
最後はお金の話です。エージェントを増やすと、トークン消費は体数ぶん掛け算で効いてきます。ここを設計しないと、気づいたら請求が跳ねています。
私も一時期、LLMのAPI利用料が月5万円を超えていました。内訳を調べると、犯人は「不要に長いプロンプト」と「重複したコンテキストの送信」でした。
やったことは3つです。
- プロンプトの共通部分をシステムプロンプト側に集約（毎回送らない）
- 会話履歴の要約機能を実装（全履歴を毎回積まない）
- キャッシュ可能なレスポンスはローカルにキャッシュ
結果、トークン使用量が約60%削減、月額は2万円に収まりました。しかも応答品質は落ちていません。コスト最適化は「何を送るか」の設計が9割で、不要なコンテキストを削るだけで劇的に下がります。
運用として効くのは、消費量を「1件あたり」で測っておくことです。ドラフト1本あたり、タスク1件あたりの $ を把握しておくと、「この自動化はペイしているか」を判断できるようになります。
まとめ — 上級とは「精度」から「運営」への視点の移動
中級までは1体のエージェントの精度を上げるゲーム、上級は複数のエージェントを事故なく安く走らせる運営のゲームです。最後に4パターンを一覧にしておきます。
| パターン | 課題 | 打ち手 | 効果（実測） |
|---|---|---|---|
| ① 役割分担 | 1体の肥大化 | 役割別分割＋受付ルーター＋ペルソナ | 精度+40% / 速度2倍 |
| ② 承認フロー | 外部への暴走 | draft→キュー→承認→実行 | 誤操作ゼロ / 承認1日5分 |
| ③ git並行制御 | 同時書き込み競合 | 単一ロックのラッパー経由 | index競合の解消 |
| ④ コスト管理 | 体数×トークン増 | 共通化・要約・キャッシュ | トークン-60% |
順序も大事です。私の経験では ①役割分担 → ②承認フロー → ③git並行制御 → ④コスト管理 の順に必要になります。先に承認フローだけ作っても、役割が割れていないと結局1体がボトルネックになるからです。
特別なフレームワークは要りません。中身は Markdown とシェルスクリプト、そして CLAUDE.md の延長線上にある“運用設計”だけです。中級の道具立てはそのまま活きます。
この記事が参考になったら、いいね・ストック していただけると励みになります。
Claude Code・AIエージェント・業務自動化の実装Tipsを継続的に発信しています。フォロー しておくと新着が届きます。
みなさんは何体目のエージェントで「増やすと逆に遅くなる」壁にぶつかりましたか？ ぜひコメントで教えてください。