AI-First 組織のつくり方: 120体のエージェントを統制する6原則

はじめに: 120エージェントは "多すぎる" ことの方が問題だった

2025 年春、mixednuts 内部の業務自動化プロジェクトで、AI エージェントの数が 100 を超えた瞬間から、私は "増やすこと" ではなく "統制すること" が主な課題であることに気づきました。

よくある誤解は、「エージェントを増やせば増やすほど生産性が上がる」というものです。実際には、100体を超えた時点で以下のような問題が顕在化しました:

• 同じ作業を複数エージェントが並行実行し、結果が食い違う
• どのエージェントに何を任せるべきか、人間側も判断できなくなる
• 一部のエージェントが "ドラマ化" (数字を盛る) をし、意思決定を歪める
• コストが思わぬところで跳ね上がる
• エラーが起きても、どこで起きたのか追跡できない

この記事では、これらの問題を解決するために私が採用した 6つの設計原則 を共有します。自社のサイズ (個人の副業から100名規模の組織まで) に応じて、そのまま取り入れていただける形で解説します。

原則 01: 3階層のスパン・オブ・コントロール

人間の組織論から借用した、スパン・オブ・コントロールの原則。1人の C-Suite Lead (例: CTO) が直接監督する Head エージェントを 5–7 体までに制限し、各 Head が Worker エージェントを同じく 5–7 体までまとめます。

結果として、120体の構造は以下のようになります:

• Lead (Opus モデル、6体) — C-Suite 相当: CTO, CFO, COO, CRO, CMO, CoS
• Head (Sonnet モデル、15体) — 部門長相当: Engineering Head, Finance Head 等
• Worker (Sonnet/Haiku、100体+) — 専門スキル担当

"エージェントを人間の組織のように設計する" と、マネジメントの既知の問題 (スパン過多、指揮命令の混乱) を既知の解法 (階層化、委任) で解ける。

原則 02: 委任の強制ルール

人間のマネジメントと同じく、Lead が実務に手を出すと組織は機能しなくなります。Lead エージェントには明示的に:

• 実装コードを直接書かせない (Head → Worker に委任)
• データ取得を直接させない (同上)
• 分析結果の "最終ジャッジ" だけを担わせる

mixednuts では、これを auto-delegation rule として成文化し、全 Lead エージェントのシステムプロンプトに強制的に組み込んでいます。

原則 03: Calibration の埋め込み (盛らない原則)

LLM エージェントは、時に "優秀に見られたい" バイアスで事態をドラマ化します。「Google Ads で異常値検出!」→ 実は¥3 の誤差だった、というのは典型的な例です。

これを防ぐために、全エージェントのシステムプロンプトに以下のルールを埋め込んでいます:

• 異常値を見たらまず実害 (金額・件数) を計算
• 「致命的」「深刻」「壊滅的」等の感情語を禁止
• 仮説形 ("〜の可能性") と事実形 ("〜で観測された") を分離
• 信頼度 (高/中/低) をつける
• 一度出した結論が誤っていたら、即座に撤回して修正する

"地味な事実を地味に出す" のが最大の価値。過剰演出は意思決定を歪める。

原則 04: 構造化された引き継ぎ

LLM は基本的にステートレスで、セッション間で記憶を持ちません。これを補うために、私は以下の場所に意図的にデータを残します:

• projects/*/context.md — プロジェクト別の TODO / 状態 / 直近決定
• memory/decisions.md — 組織横断の意思決定ログ
• _reports/YYYY-MM-DD_*.md — 時点の分析・報告書 (不変)
• auto-memory — セッション横断の学習パターン

エージェントはセッション開始時に必ず該当ファイルを読み、終了時に更新します。この "ファイル経由の記憶" により、100+ エージェントが時間を超えて協調できるようになります。

原則 05: 自己修復の仕組み

100+ のエージェントが稼働すると、何かしらは壊れます。これに人間が逐一対応するのは非現実的。私は self-heal エージェント を常時稼働させ、4時間ごとに以下をチェックします:

1. 全エージェントの設定ファイル (YAML) の文法
2. API 接続状態 (freee, Google, Slack 等)
3. ディスク / ログの肥大化
4. 停止しているはずのプロセスが動いていないか

異常を検出すると、単純なケースは self-heal が自動修復し、複雑なケースは Slack 通知 + 推奨対処法を添えて人間に escalate します。3回連続失敗すると CEO に直接通知する escalation policy を設定しています。

原則 06: 継続的コスト可視化

AI エージェントのコストは、使い方次第で簡単に桁違いに膨らみます。私は cost-tracker エージェント を毎日実行し、以下を可視化しています:

• エージェント別のトークン消費 (前日比、前週比)
• 案件別のAPI料金 (予算に対する消化率)
• 非効率なエージェント (トークン高・成果低) の自動検出
• 月額予算に対する消化ペース

これにより、コストが "気づいたら膨張していた" という事態を防げます。

おわりに: "Just Enough Structure" が鍵

AI エージェント組織の設計でありがちな失敗は、"柔軟性を最大化しようとしてカオスに陥る" か、逆に "厳格にしすぎて AI のメリットを殺す" の両極端です。

私が 1 年の試行錯誤で辿り着いた答えは、"Just Enough Structure" (必要最小限の構造) — つまり 6 つの原則くらいは守らせつつ、それ以外は任せる、というバランスでした。

これから AI-first 組織の構築を始める方、既に運用していて混乱している方にとって、この記事が何らかのヒントになれば幸いです。

mixednuts では、この組織設計ノウハウをクライアントの事業に実装する AI 実装支援サービス を提供しています。

---

FAQ

Q. 100 体未満でもこの 6 原則は適用すべきか？ A. 20 体を超えたあたりから恩恵が出ます。10 体未満ならフラットで十分。階層化は組織が複雑化したときに初めて効く設計パターンです。

Q. Claude 以外の LLM (GPT / Gemini) でも同じ設計でよいか？ A. はい。「考える層 / まとめる層 / 実行層」の 3 階層はモデル非依存。どの LLM でも同じ原理で組めます。

Q. self-heal エージェントが暴走するリスクは？ A. 単純な復旧 (再起動・キャッシュクリア) のみ自動化し、設定変更・データ書き換えは人間 escalation を必須にしています。3 回連続失敗で CEO に通知する escalation policy で歯止めをかけています。

Sources

• Anthropic — Building Effective Agents — エージェント設計の基礎原則
• Anthropic — Multi-Agent Research System Engineering — orchestrator-worker パターンの設計
• Anthropic — Equipping Agents for the Real World with Agent Skills — Skills の progressive disclosure
• 内部ドキュメント: .claude/rules/calibration.md — Calibration ルール 7 ヶ条
• 内部ドキュメント: .claude/rules/auto-delegation.md — 委任強制ルール