SE歴26年、初めての部下はAIだった
SE歴26年、ずっと「指示される側」だった。
設計書を書き、コードを書き、テストをして、リリースする。上から降ってくる仕様をどう実装するかを考える仕事だ。数人のチームでプロジェクトマネージャーを担ったことはある。ただし本格的なマネジメント——部門を運営する、組織を設計する——はやったことがない。
それがここ2週間で変わった。AIエージェントで小さな組織を作り始めて、初めてマネジメントというものをやってみた。まだ2週間の体験談だ。
やってみて分かったのは、「人間の組織で起きることが、驚くほどそのままAI組織でも起きる」ということだった。
ここで再現された人間の組織論については「Claude Codeのエージェント組織を管理していたら、人間の組織論が7つそのまま再現された」で7つの具体例として整理している。
前提: 1エージェント = 1部署として読んでほしい
この話を始める前に、1つだけ前提を置かせてほしい。
→ 組織の構成と作り方の具体手順は「Claude Code マルチエージェント構成の作り方 — 秘書・ライター・リサーチャーを6日で揃えた」で解説しています。この記事と合わせて読むと、「組織を設計する前後の変化」が立体的に伝わります。
「AIエージェント6体で組織？ 小さすぎて組織論と呼べないだろう」と思った人は、比較の単位を変えてみてほしい。
たとえばReaderエージェント（想定読者ペルソナで原稿を評価するAIエージェント）の話をする。6本の記事、それぞれ3通りのペルソナで読む——合計18回分のレビューを、このエージェント1体が同時に並行でこなした。18人分の評価を1体が担った、ということだ。
つまりAIエージェント1体が動かす手の速さは、人間数人分に相当する。Writerエージェントは記事を書き、Researcherエージェントは調査し、DevOpsエージェントはインフラを整備する——それぞれが、数人規模の機能単位を1体で担っている。
正しい対比は「AIエージェント6体 = 人間6人」ではなく、「AIエージェント6体 = 6部署を持つ会社」だ。この目線で読んでもらうと、話が自分ごとになるはずだ。
1. 新人に仕事を教えようとしたら、自分の組織の問題に気づいた
AIエージェントに仕事を任せるには、まず教えなければならない。
どんな仕事をするのか。どの順番でやるのか。こういうときはどう判断するか。人間の新入社員に仕事を教えるのと、構造は同じだ。
ただし、根本的に違うことが1つある。「背中を見て覚える」が一切通用しない。
人間の職場なら、明文化されていない慣習を先輩の振る舞いから学べる。「なんとなくこういうトーンで書く」「この手の案件はこの人に確認する」——そういう言葉にされていない知識を、AIは自分では拾えない。教えなかったことは、最初から存在しないものとして動く。
さらにもう1つ厄介な点がある。セッションが終わると記憶がリセットされる。今日うまくいった方法も、明日のセッションでは最初から教え直しになる。
だから引き継ぎ資料を整備し、ルールをファイルに書き、判断の積み重ねをメモリに残す——ということを徹底的にやることになった。
作業を進めるうちに、これが別の問題を照らし出した。
「今まで自分の組織で、言葉にされていない知識を言語化できていたのか？」
CLAUDE.md（会社で言えば全体方針と基本ルールにあたる）、agent-roles.md（誰が何をするかの組織図）、ops/playbooks/（具体的な手順書）——AIに教えようとして書いたものが、人間の組織でいう就業規則・職務記述書・業務マニュアルにそのまま対応していた。
そしてこれらのドキュメントは、一から自分で書いた訳ではない。AIがドラフトを作り、「ここが違う」「こういうケースはどうする」と著者が指摘して直す、という往復で作れた。うまく言語化できないことも、CEOエージェントとの対話の中から具体的な形になっていった。
AIに教えようとして初めて、「人間の組織でも本来やるべきだったこと」に気づかされた。
2. 「なぜ間違えたの？」に感情がなかった
フィードバックのやり方も変わった。
人間の部下に「なぜここを間違えたの？」と聞くと、まず「すみません」が返ってくる。謝罪が先に来て、原因の分析は後回しになる。場合によっては防御的になって、本当の原因が見えにくくなる。
AIに同じことを聞くと、「原因を調査します」という反応が返ってくる。謝罪なし、萎縮なし、言い訳なし。純粋に「なぜこうなったか」の調査が始まる。
これは便利だった。原因が分かれば、次から同じミスをしないための仕組みを作れる。フィードバックが機能として働く。
ただし、正直に書かないといけない限界もある。
AIは「すみません」と言わない代わりに、メモリに保存しなかった教訓を次のセッションで忘れる。人間は失敗を感情と結びつけて記憶するが、AIにはその経路がない。「書かなかったことは消える」という別の問題が代わりに発生する。謝罪や後悔がないぶん楽だが、その代わりに記録コストが必ず人間側に発生する。
3. 「あの人が辞めたら困る」が起きない構造——と正直な制約
組織を動かしていると「属人化」が怖くなる。Aさんしかわからない業務が生まれると、Aさんが休んだとき組織が止まる。
AI組織では、「経験」が個人に帰属しない形で蓄積される。
- MEMORY.md（プロジェクト全体で共有される判断の積み重ね）
- エージェント定義ファイル（専門知識とルールとして明示的に記述）
- ops/playbooks/（手順として組織に定着）
先日、3体のエージェントを廃止して1体に統合した。変更したファイルは26ファイル、1セッション以内で完了した。廃止したエージェントの経験——開発の手順、テストの方法、デプロイ先の設定——は、新しいエージェントの定義ファイルにそのまま引き継げた。
ただし「書かなかったことは消える」という問題はここにも現れる。セッションをまたぐと会話の記憶は消える。MEMORY.mdとops/handoff/（引き継ぎ資料）が補完するが、完全ではない。属人化が起きないのは、「定義ファイルに書いた範囲だけ」だ。AI運用が「言葉にされていない知識の言語化」を組織に強制するとも言える。
4. 26ファイルで終わるリストラ。ただし保守コストは実在する
人間の組織では、チームの統廃合は難しい。心理的な抵抗、残った人員のやる気の低下——「自然減を待つ」という回避策が多用されるほど、実際には大変だ。
AIエージェントの廃止は、上で書いた通り26ファイルの変更で1セッション以内に終わった。抵抗なし、やる気の低下なし、翌日の空気も変わらない。感情的コストがゼロというのは、この点で最も実感した。
ただし「地味なコストが実在する」とも正直に書いておきたい。
26ファイルを変更するということは、26ファイルを保守し続けるということでもある。「即日できる」と「タダでできる」は別の話だ。統合したからといって保守コストが消えるわけではなく、むしろ正しく統合できないと後で余計な修正が必要になる。
それに、エージェントの設計は組織設計そのものだ。「組織の形がそのまま仕事の形になる」という現象は、AIでも変わらない。3体を無理に1体に統合すると、1体の定義ファイルが膨れ上がって管理できなくなる。エージェントの統合は、部署統合の設計と同じ問題を解かなければならない。
5. マニュアルが増えすぎる問題は、AI組織でも同じだった
人間の組織でよく聞く「大企業病」がある。マニュアルが増えすぎて、「ルールを読むコスト」が「ルールが防ぐミスのコスト」を上回る状態だ。手続きが形骸化して、誰もマニュアルを読まなくなる。
AI組織でも、同じことが起きた。
現時点（2026-04-16実測）でPlaybook（手順書）ファイルは38ファイル、総行数は3,506行ある。ネタ帳にメモした段階では34ファイル/2,829行だった——この記事を書く数日の間に4ファイル・677行増えた。組織を整備しようとするほど、手順書が増えていく自己矛盾だ。
人間の組織と違うのは、AIエージェントが「マニュアルを読まない」という選択をしないことだ。理論上、全文を読み込もうとする。マニュアルが増えるほど処理コストが上がる、という問題として直接現れる。
対策として、187行あったdaily-research.md（手順書ファイル）から大部分のテンプレート記述をシェルスクリプトに切り出し、定義ファイルを116行に圧縮した。ドキュメントの重複を削ることで、同じ機能をより少ない行数で管理する——という整理を繰り返している。
解決したわけではなく、今も増え続けている。
このマニュアル肥大化問題がガバナンス事故と合流し、最終的に「trigger リスト付き憲法」として整備されることになります。その経緯は「Claude Code の憲法を書いたら、1日で法律になった話」に書きました。
6. 1人で見られる部下の数には限界がある。AIも人間も
1人のマネージャーが直接管理できる部下の数には限界がある。別の案件を並行処理するときに、6体を超えたあたりから「誰に何を頼んだか」を把握するのが怪しくなる。人間の組織でも、直属の部下が10人を超えると1人あたりの管理が薄くなる実感があるのではないだろうか。
現在、自分のAI組織はCEO配下に6体のエージェントがいる。今のところ把握できているが、余裕があるわけではない。
ただし、AIの管理限界の原因は「疲れ」ではない。一度に処理できる情報量の上限（コンテキストウィンドウ）がある。エージェントが増えるほど、各エージェントへの指示と確認に必要な情報量が増え、処理コストが上がる。
制約があること自体は同じ。原因が違うだけだ。
この制約から逃げようとすると、人間の組織と同じ解になる。階層を作る（中間管理役を置く）か、チームを小さく保つか。AIエージェント設計で「中間エージェント」を置く構成は、まさにこの問題への回答になる。
実際にやってみたことがある。別ウィンドウでCEOを起動して、同じ構成の組織にもう1つ別の案件を処理させた。人間の経営者には物理的に不可能なことが、AIでは「もう1つ会社を起動する」という操作になる。ただし、2つの組織が同じファイルを触ると衝突するので、案件の切り分けは人間が設計する必要がある。
やってみたら、自分はこの3つしかやっていなかった
6つの場面を振り返ってみると、自分がやっていたことは結局3つに絞られていた。
1. 成果物の確認 AIの出力を見て、期待していたものと違う場合に「これは違う、こうしてほしい」と伝える。
2. 原因を問う うまくいかなかったとき「なぜこうなったか」を問いかけて、原因を明らかにし、再発を防ぐ仕組みをファイルに残す。
3. 組織を監視する ルールが機能しているか、Playbookが肥大化していないか、エージェントの定義が実態と合っているかを定期的に見る。
先にこれを考えていたわけではなく、やっていたことを後から整理したらそうなった、という順序だ。あえて名付けるなら、1はQC（品質管理）、2はPDCA（改善サイクル）、3はガバナンス（統制）に近かった。会社員なら聞いたことのある言葉だと思う。
SE歴26年、「指示される側」だった自分が、初めてこの3つを意識してやっていた。相手がAIだったから、気づいた。
なお、AIが謝らず萎縮もしないぶん楽ではあるが、記録・整備・監視にかかる人間側の時間コストは確実に存在する。月額の金銭コストについても現時点で実測できていない。この点は正直に書いておきたい。
この3つ（QC・PDCA・ガバナンス）がどう4軸の自動化に発展するかは「タスク管理・リサーチ・記事公開を全部AIに振ったら、人間はどこで判断すればよくなったか」で整理しています。
もう1つ、正直に書いておきたいことがある。AIの処理は速い。速いぶん、確認・判断を人間がすぐに求められる。承認待ちのエージェントは止まったままだから、朝から晩までPCの前にへばりついて対応し続ける時間帯がある。これはかなり体力を使う。AIが速くなっても、そのペースに人間が追いつかなければ意味がない。「AIが速い」と「人間が楽になる」は、イコールではない。
「AIを部下として動かす」という発想そのものに興味を持った人には、『ClaudeによるAIエージェント開発入門』を薦めたい。この記事で書いた「教える」「原因を問う」「組織を監視する」の3つは、2週間手探りでやってみて後から気づいた経験則だ。この本はその手探りの部分を、最初からエージェント設計の技術として体系立てて説明してくれる。私にとっては答え合わせのような読書になった。
最後に: それが怖いか、それとも解放か
AIに「手を動かす」部分を任せると、人間には確認・原因究明・監視だけが残る。
言い換えれば、「手を動かしながらマネジメントもやる」という状態——プレイングマネージャーが常に抱える二重負荷——から解放される可能性がある。
ただし、これは別の問いを突きつける。
手を動かさなくなったとき、あなたは確認・原因究明・監視に集中できるか。それとも「何もしていない」という感覚に不安を覚えるか。言葉にされていない知識を言語化する作業は、思っているより時間がかかる。マニュアルを整備し続けることが仕事になる感覚は、最初は奇妙だった。
AIに任せると、あなたは初めてマネジメントに集中せざるを得なくなる。
それが怖いか、それとも解放か。
この10日間の実験全体（組織設計・崩壊・立て直し・ガバナンス整備）を総括した記事が「コードを1行も書かずに、AIエージェント編集部を作った話」です。シリーズを通して読みたい方はこちらもどうぞ。
数値の根拠: Playbookファイル数38・総行数3,506は2026-04-16に実測。コミットc4ecf47の26ファイル変更は git show --stat で確認。
この記事の実践例を一冊にまとめました。
