Claude Codeで16体のエージェントに会社を運営させてみた

Claude Code のサブエージェント機能を使って、Claudeに「会社」を1つ作ってもらった。事業部門（アフィリエイト・SNS運用・サイト監視）と個人部門（秘書・健康・資産）を持つ計16エージェントの組織で、週次の経営会議コマンド /company weekly を叩くと10部署が並列に走って報告・提案・承認・議事録・commit までを一気にやる。

初回の週次会議が最後まで完走した。仕組みと設計の要点は次のとおり。

/company weekly 初回実行の完了報告。proposal 2件の採択・KPI反映・commit完了に加え、戦略担当の誤認を補正注記付きで採択した点や、データ不足で「提案なし」と正直に見送った部署があったことがターミナルに表示されている

全体構成：ディレクトリが会社、CLAUDE.md が定款

会社の実体はただのディレクトリとファイルだ。

knym-company/
├── CLAUDE.md          # 定款（承認ゲート・優先度式・禁止事項）
├── board/             # KPI.md / TASKS.md / minutes/（議事録）
├── finance/           # ledger.md（台帳）/ budget.json（予算キャップ）
├── queue/             # drafts/ → approved/ → published/（投稿パイプライン）
├── proposals/         # エージェントからの改善提案
├── scripts/           # LLM不要の処理（投稿・集計・死活監視・コスト取得）
└── infra/             # 監視レポート・セキュリティ監査

部署は .claude/agents/ に置いたサブエージェント定義で、frontmatter でモデルと使えるツールを部署ごとに絞る。

---
name: company-cfo
description: お金管理。usage/とbudget.jsonからledger.mdを更新し異常検知を行う
tools: Read, Write, Edit, Glob, Grep
model: haiku
---
（役割・手順・報告フォーマットの指示）

CFO に Bash を持たせない、事業部門エージェントは personal/ を読まない、という権限分離をツール制限そのもので担保するのがポイント。プロンプトで「読むな」と書くだけより確実だ。

/company weekly の流れ

/company はスラッシュコマンド（スキル）として定義していて、weekly サブコマンドの手順はこうなっている。

KPI.md・TASKS.md・台帳・直近議事録を読む
全部署（PM・CFO・SNS分析・戦略・効率化・検閲・アフィリ監査・インフラ・セキュリティ、月初は組織分析も）を並列起動
報告を集約し、優先度式 期待収益 × 確度 ÷ 工数 で裁定する
承認が必要な事項（ドラフト公開・支出・提案の採否）を AskUserQuestion で一括確認
承認された分だけメインセッションがファイルに反映
議事録を書いて git commit

初回は10部署が並列で走り、報告が揃うまで数分。人間がやることは途中の承認クリックだけだった。

暴走させないための設計4点

エージェントに「会社を経営させる」と聞くと危なっかしいが、以下の4つで手綱を握っている。

1. 承認ゲート＝ファイル移動

いちばん気に入っている設計。SNS投稿の公開許可は「queue/drafts/ から queue/approved/ へのファイル移動」そのものであり、移動を実行できるのはユーザー承認を経たメインセッションだけ。エージェントには approved/ への書き込みを禁止している。「公開してよいか」を言葉で判断させるのではなく、ファイルシステムの構造として承認を表現すると、すり抜けが起きない。

支出・メール送信・カレンダー変更・売買はすべて「提案止まり」で、実行は必ず人間がやる。

2. モデル経済：定期ジョブは haiku 固定

16エージェントを Opus 級で回すと予算が溶ける。定期ジョブは haiku 固定、執筆・戦略・ブラウザ操作だけ sonnet。さらに投稿・集計・死活監視・コスト取得など LLM が不要な処理はぜんぶ Node スクリプトにして、トークンを1つも使わない。エージェントの報告は200トークン以内に制限し、詳細はファイルに書かせる。

月次の LLM 予算キャップは budget.json に置き、超過したら guard スクリプトが定期 LLM ジョブを止める。……という設計にしたのだが、これは後日まったく動いていないことが分かった。記事末尾の追記を参照。

3. キルスイッチ：touch PAUSED

ディレクトリ直下に PAUSED ファイルが存在する間、全ジョブは何もせず終了する。緊急停止が touch PAUSED の1コマンドで済むのは精神衛生上とても良い。

4. proposal テンプレの強制

エージェントからの改善提案は「現状 / 提案 / 期待効果（数値）/ 変更対象ファイル / リスク / 検証方法」の6項目が揃っていないと審議しない。これを定款に書いておくと、ふわっとした思いつき提案が上がってこなくなる。

実際に回して分かったこと

初回 weekly で早速、設計の効果と限界の両方が見えた。

エージェントは平気で誤認する。 戦略担当が「投稿パイプラインが未構築」という前提で提案を書いてきたが、実際にはパイプラインは稼働済みで投稿も1件公開されていた（探索したパスが違った模様）。メインセッションが採択前に提案ファイルを検分して誤認を発見し、補正注記を付けて採択した。採択前にメインが提案ファイルを検分していなければ、この誤認はそのまま通っていた。

効率化担当と組織分析担当は「構築初週でデータ不足のため提案なし」と正直に見送ってきた。提案テンプレに数値根拠を要求しているおかげで、無理やりひねり出した提案でノイズが増えることがない。

報告200トークン制限は効く。 10部署分の報告が返ってきても、集約・裁定がメインセッションの数往復で終わる。制限なしだと各部署が長文を返してきて、それだけでコンテキストが埋まる。

まとめ

サブエージェント＝部署、ディレクトリ＝会社、CLAUDE.md＝定款という対応で「会社型組織」が素直に作れる
承認はプロンプトでなくファイル移動＋ツール制限という構造で担保した
定期ジョブは haiku 固定＋LLM不要処理のスクリプト化で、コストは現実的な範囲に収まる
エージェントの報告・提案は、上位モデル（またはユーザー）が検分してから採択している

「AIに会社を経営させる」というより「会議の下ごしらえと定型業務を全部やらせて、人間は承認だけする」が実態に近い。週次会議の所要時間は、承認クリック込みで5分だった。

追記：予算キャップは動いていなかった（2026-07-26）

この記事を書いた3週間後にコストを確認したら、月次キャップとして設定した金額の6.7倍まで積み上がっていた。調べると、上に書いた guard スクリプトは一度も機能していなかった。

理由は3つ重なっていた。

定期ジョブを launchd に登録していなかったので、そもそも guard が呼ばれる機会がなかった
guard スクリプトが参照する node のパスをバージョン番号込みで直接書いていた。nvm で node を更新した結果そのパスが消えており、仮に呼ばれてもキャップの判定を素通りしていた。エラーは出ない
警告の通知先も未設定だった。Telegram の鍵を登録しておらず、代わりに使うはずのコマンドもインストールされていなかったので、警告はどこにも記録されずに消えていた

3層とも独立に壊れていて、22日間だれも気づかなかった。

そもそもの前提も間違っていた。Claude を定額プランで使っている以上、API 換算の金額が積み上がっても請求は増えない。累計でジョブを止める設計自体に意味がなかったので、いまは「1日あたりの使用量が閾値を超えたら通知するだけ」に作り替えている。

設計したものが動いているかどうかは、設計とは別に確かめないと分からない。この記事の「4点で手綱を握っている」は、正確には握っているつもりだった、が正しい。