Claude Codeのエージェント組織を管理していたら、人間の組織論が7つそのまま再現された
マネジメントで悩んだことはありますか？
「部下に仕事をうまく任せられない」「マニュアルが増えすぎて誰も読まない」「あの人が辞めたら困る、でもどうにもならない」——そんな悩みを抱えたことがある人に、少し変わった視点からの話をしたいと思います。
ずっと「指示される側」として働いてきた私が、初めてマネジメントを体験することになりました。ただし、相手が人間ではなくAIエージェントでした。
Claude Codeというツールを使って、複数のAIエージェントを組織化して仕事をさせるようになって数ヶ月。気づいたら、教科書に書いてあるような組織の問題が、驚くほどそのまま再現されていました。
前提：Claude Codeで「1エージェント＝1部署」という設計を選んだ理由
話を始める前に、1つだけ前提を置かせてください。
AIエージェントは手を動かすスピードが人間より格段に早い。「1エージェント = 1人」ではなく、「1エージェント = 1部署（数人〜十数人規模の機能単位）」と考えたほうが実態に近い。
たとえば私のところではreaderというエージェントが記事のレビューを担当しています。以前、6記事×3ペルソナ = 18回のレビューを同時並行で回したことがありました。人間に例えると、1つの部署に18人のレビュアーがいるような状態です。
だから今から話す「7体のエージェントによる組織」は、人間7人の話ではありません。7部署からなる会社の話です。
1. 新人教育：暗黙知を言語化させられた
AIエージェントに仕事を任せようとしたとき、最初にぶつかった壁は「言葉にしなければ伝わらない」という当たり前の事実でした。
人間の組織では「背中を見て覚える」が通用します。先輩の仕事ぶりを観察して、雰囲気をつかんで、少しずつ動き方を学ぶ。でもAIにはそれが一切通用しない。
-
CLAUDE.md（社内規定・就業規則に相当） -
agent-roles.md（組織図・職務記述書） - Playbook（業務マニュアル・SOP）
- ops/handoff/（引き継ぎ資料）
こういった文書を整備しないと、エージェントはまともに動かない。さらに厄介なのは、セッションが切れるたびにエージェントの記憶がリセットされることです。毎朝、昨日の文脈を忘れた状態でスタートする。だからこそ引き継ぎ資料が異常に重要になる。
書いていくうちに気づきました。「これ、人間の組織でも本来やるべきだったことだ」と。
SE歴26年の間、私はずっとその「書かれなかった側」にいました。属人化が進んだ組織では、ベテランの頭の中に業務フローが全部入っている。でもそれを文書化しろと言っても「忙しくてできない」「暗黙の了解で通じてるから不要」となる。AIを使い始めたら、その暗黙知を言語化しない限り仕事が動かないので、サボれなくなりました。
経営者・マネージャーへの問い: あなたの組織の暗黙知は、言語化されていますか？明日、部署の全員が入れ替わっても回る仕組みがありますか？
2. フィードバック：「今なんで間違えたの？」に感情がない世界
AIへの指摘で驚いたのは、「なぜ間違えたの？」と聞いたときの反応でした。
エージェントはそのまま原因を調べてくれます。「〇〇の条件を確認していませんでした。今後は△△のように対応します」という返答が来る。
人間に同じことを言うと全然違う展開になります。「今なんで間違えたの？」という言葉は「叱責」として受け取られ、防御反応（謝罪・萎縮・言い訳）が先に来て、原因分析が後回しになる。
心理的安全性を確保しないとフィードバックが機能しない——これが人間の組織の常識です。AIにはその問題が存在しない。
ただし、AIにも制約があります。感情がない代わりに、「すみません」と言わない代わりに、メモリに保存しなければ次のセッションで同じミスを繰り返します。人間は感情を通じて学習しますが、AIには記録という手段しかない。感情的な痛みを学習に変える経路がないんです。
フィードバックのコストは下がりますが、記録と仕組みへの依存度が上がる。そういうトレードオフがありました。
3. 属人化：「あの人が辞めたら困る」が起きない——ただし条件つきで
エージェントの「経験」は3つの形で組織に蓄積されます。
- メモリ（MEMORY.md）: プロジェクト全体で共有される判断の蓄積
- エージェント定義: 専門知識・ルールとして明示的に記述されたもの
- Playbook: 手順として組織に定着したもの
これらは特定のエージェントに帰属せず、組織全体で共有されます。実際に3体のエージェントを廃止・統合した際（後述）、旧エージェントの経験は新エージェントの定義ファイルにそのまま引き継げました。
「あの人が辞めたら困る」が発生しない——理論上はそうです。
ただし正直に書くと、制約もあります。「書かなかったことは消える」という別の属人化が起きます。セッションをまたいだ「会話の記憶」はリセットされるので、MEMORY.mdとops/handoff/（引き継ぎ資料）に書き残した範囲だけが組織に残る。書かなかったことは誰も覚えていない。
結局、「書く文化」があるかどうかが全てを決めます。これも人間の組織と変わらない。
4. 統廃合：26ファイルの変更で終わった組織再編
人間の組織における統廃合・リストラは、経営上の最難関の1つです。労働法の制約、心理的抵抗、モラル低下、訴訟リスク。「自然減を待つしかない」という回避が多用される。
AIエージェントの場合はどうか。
2026年4月のある日（git commit c4ecf47）、私は3体のエージェントを廃止して1体の新エージェントに統合しました。変更されたファイルは26個（実測）、所要時間は1セッション以内でした。翌日の「空気」は何も変わりませんでした。そもそも空気がない。
「感情的コストがゼロ」——これは最初に驚いた点です。人間の組織なら「あの人たちのポジションをどう伝えるか」「残ったメンバーの士気はどうなるか」といった問題が延々と続く。AIにはそれがない。
ただし「即日完了」であっても「無料」ではありません。26ファイルの変更には保守コストがかかります。変更後の動作確認、ドキュメントの整合性チェック、引き継ぎ内容の検証——地味だが実在するコスト。「簡単にできる」と「コストがゼロ」は別の話です。
コンウェイの法則との関係: エンジニアリングの世界に「コンウェイの法則」という概念があります。「組織の構造がそのままシステムの構造になる」というものです。今回の3体統合は、通信経路の単純化でもありました。エージェント設計は、そのまま組織設計なんです。
5. 官僚化：Playbookが増えすぎる自己矛盾
これが一番笑えない話でした。
私が運用するエージェント組織には、業務マニュアルに相当するPlaybookがあります。2026年4月16日時点で34ファイル（当時実測）でした。それが現在（2026年4月末）は61ファイルに増えています。
組織を整備しようとするたびにPlaybookが増える。「この手順を標準化しよう」「この判断基準を文書化しよう」——そのたびに1ファイルずつ増える。
人間の組織でも同じことが起きます。マニュアルが増えすぎて「ルールを読むコスト > ルールが防ぐミスのコスト」になった瞬間、組織が機能不全に陥る（大企業病と呼ばれる状態）。ルールが多いほど現場は「どのルールを使えばいいのか」で混乱する。
AIエージェント固有の問題もあります。人間なら「マニュアルを読まない」という選択が可能ですが、エージェントは理論上すべてのルールを参照しようとします。Playbookが増えるほど処理コスト（トークンコスト）が上がる。官僚化のコストが金銭的に可視化されるんです。
対策として、今はPlaybookの一部を「文章で書かれたルール」から「自動的に実行される仕組み」に置き換える取り組みをしています。あるPlaybookは187行あったものが116行まで減らせました。人間の組織でいえば、分厚い手順書を読ませるのをやめてチェックリストやシステムに置き換える——あの改善とやっていることは同じです。
マニュアル削減の努力は、人間の組織でも同じ悩みのはずです。
6. 管理の限界：スパン・オブ・コントロール
組織論に「スパン・オブ・コントロール」という概念があります。1人のマネージャーが直接管理できる部下の数は5〜8人が限界、というものです。古代ローマの軍団から現代のAmazon（「ピザ2枚ルール」）まで、階層構造はこの制約から生まれた「情報ルーティングの仕組み」です。
私のエージェント組織でCEOエージェントが直接管理しているのは7体。適正範囲（5〜8）に収まっていました。
ただし制約の原因が人間とは違う。人間は「認知的疲労」で限界に達します。AIは「トークンコスト（情報処理コスト）」で限界に達します。管理下のエージェントが増えるほど、1回の指示で参照すべき文脈が増え、処理コストが上がる。
限界があること自体は同じ。原因だけが違う。
このことに気づいたとき、「組織の階層構造って、人間固有の問題ではなく情報処理の普遍的な問題なんだ」と少し違う視点で見えるようになりました。
7. 気づき：やってみたら、結局この3つしかやっていなかった
いくつかの対比軸を書いてきましたが、振り返ってみると自分がやっていることは3つに集約されていました。
- 成果物の確認: AIの最終成果物を確認して、期待値と違う場合は「期待値はこうだった」と伝えて修正を求める
- 原因究明: 「なぜ違ってしまったのか」を問いかけて原因を探り、再発防止の仕組みを作らせる
- 組織の監視: その仕組みを維持するために、組織が機能しているか目を光らせる
「確認・改善・監視」——QCの基本とかPDCAとかガバナンスとか、いろいろなラベルが付けられそうです。でも私が体験したことを素直に言えば「気づいたらこの3つしかやっていなかった」というだけの話です。
AIは手を動かすのが速い。指示さえ正しければ即座に完了する。逆に言えば、指示が悪ければ即座に間違えます。指示の質がそのままマネジメントの質になる。
ボトルネックはずっと「指示する側」にあった。
締め：それが怖いか、それとも解放か
この体験が「60人規模の会社に適用できるか」と聞かれたら、正直に言えば分かりません。私の組織は7エージェント（7部署相当）の小さな実験です。
ただ、ここで起きたことは——属人化、マニュアルの肥大化、管理の限界、組織再編のコスト——どれも規模の大小に関係なく成立する構造的な問題でした。大きな組織ほど深刻かもしれません。
AIに仕事を任せると、手を動かすことがなくなります。残るのは「何を任せるか決める」「ちゃんとできているか確認する」「うまくいかなかったとき原因を探る」——これだけです。
それは、マネジメントの本質そのものだと思います。
AIに任せると、あなたは初めてマネジメントに集中せざるを得なくなる。それが怖いか、それとも解放か——答えは人によって違うと思います。でも少なくとも私は、この体験を通じて「マネジメントって、こういうことだったのか」と初めて腑に落ちた気がしています。
もし気になったなら、まずは小さく試してみることをおすすめします。Claude Codeを使って、何か1つだけ仕事を任せてみる。「自分が何を確認して、何を決めているのか」——それがくっきり見えてくるはずです。
参考書籍
Claude Codeを実際に使ってみたい方は、以下の書籍が参考になります。
- Claude CodeによるAI駆動開発入門（平川 知秀）
- 実践Claude Code入門――現場で活用するためのAIコーディングの思考法（西見 公宏・吉田 真吾・大嶋 勇樹）
この記事は はてなブログ からのクロスポストです。