この記事は、エージェント組織論シリーズ全14本のナビゲーションとして書いた。「AIエージェント組織」とは、Claude Codeで役割を持たせた複数のAIエージェントが分業・連携しながら動く仕組みのことだ。1ヶ月でClaude Codeを「1人運用」から「9体のAIエージェント編集部」に育てた経過を記録した記事群で、シリーズ全体は14本ある。本記事ではそのうち主要12本を5段階の読者ジャーニーに沿って案内する（残り2本はシリーズ総まとめ系の位置づけで、「AIエージェント組織論」カテゴリから辿れる）。
1ヶ月前、Claude Codeを使い始めたばかりの私は——コードは1行も書けないが——当然1人で動かしていた。
CLAUDE.md という1つの設定ファイルに、コーディングルール・タスク管理のフロー・記事の書き方・パスの方針を全部詰め込み、200行を超えたあたりで「Claude が指示を守ったり守らなかったり」するようになっていた。
今、私のフォルダには9体のAIエージェントがいる。COOがオーケストレーションし、architectが設計し、devopsがインフラを面倒みて、writerが執筆し、secretaryが情報整理と公開スケジュールを担い、skill-devがスキルを開発し、researcherが調査し、reviewerとreaderがレビューする。この1ヶ月で、AIエージェント組織論シリーズだけで14本のネタが溜まった。
以下では、その14本のうち主要12本を「あのとき何があって、何がわかったか」で紹介し、対応する記事へのリンクを置いた。
5段階の読者ジャーニー（興味→構築→運用→改善→自走）に沿って読み進められる構成にしてある。気になる段階から読んでほしい。
段階1: 興味 — AIエージェントに仕事を任せるとはどういうことか
「人手」を借りたことのない個人が、初めて部下を得る。その感覚を記録した2本。
1. AIエージェントは「人」として扱える
朝、6人のAIチームに「出社指示」を出した。リサーチャーに調査を頼み、レポートを精査し、インフラを整え、指示書をレビューして差し戻し、ネタを収集してライターに渡す——これが1日で全部回った。設計図は描けた。では、本当に動くのか。
→ AIチーム6人と過ごした1日 — Claude Code マルチエージェントで知的生産ラインを回してみた
2. 部下が初めてできた感覚
SE歴26年、ずっと「部下」がいなかった私が、AIエージェントを部下として迎えた。「なぜ間違えたの？」と聞いても感情がない。「あの人が辞めたら困る」が起きない。けれど、保守コストは実在した。AI組織でも人間組織でも、1人で見られる部下の数には限界がある。
→ SE歴26年、初めての部下はAIだった
段階2: 構築 — Claude Codeで自分もエージェント組織を作る
「動いた」で終わらず、「再現できる設計」に変えるまでの2本。
3. 役割を分けると守られる
1つのCLAUDE.mdが200行を超えたところで、Claudeが指示を守らなくなった。1人の万能アシスタントから、役割を持ったチームへ。CEO・DevOps・Writer・Researcherに分けて、それぞれの責務だけをCLAUDE.mdに書く設計に切り替えた。
→ Claude Code でAIチームを組織した — CEO・DevOps・Writer・Researcher の役割分担と運用設計
4. 6日で構成は揃う
秘書・ライター・リサーチャーをそれぞれ「役割定義＋プロンプト＋権限」で立てる手順を6日間でまとめた。再現性のある構成手順として整理してある。
→ Claude Code マルチエージェント構成の作り方 — 秘書・ライター・リサーチャーを6日で揃えた
段階3: 運用 — マルチエージェントを動かすと何が起きるか
設計図を実際に動かすと、設計時に想定しなかった問題が出てくる。
5. 3日で組織は散らかる
役割を定義したあと、3日でディレクトリが散らかった。各エージェントが「ついでに」ファイルを作り、命名規則がブレ、責務が重なる。チャットだけで立て直した実録。
→ AIエージェント組織、3日で散らかった話 — チャットだけで立て直したマネジメント実録
6. 6日間の対話で組織が形になる
8体のAIエージェント組織を作るまでの6日間で、人間とAIがどんな対話をしたかを時系列で残した記録。設計の意図、迷い、判断のターニングポイントが全部ある。
→ Claude Codeで8体AIエージェント組織を作った6日間 — 人間とAIはどんな対話をしたか
段階4: 改善 — AIエージェントのレビュー体制をどう設計するか
組織が動き始めると、次に気になるのは「出力の品質」だった。
7. 批評家を加えると初めて誤りが見える
Reviewer（事実検証）とreader（読者ペルソナ）を追加したら、自分では気づかなかった誤りが3件出てきた。1人で見落としていたものを、AIの批評家が拾ってくれた。
→ AIチームに「批評家」を加えたら、自分では気づかなかった誤りが3件出てきた——レビュワー・読者ペルソナ追加の実演
8. AIの上司になると人間の組織論がそのまま再現される
1on1、評価制度、フィードバックの設計——人間組織で議論されてきたことが、AIエージェントの上司になった瞬間にすべて再現された。マネジメントの古典が、AI時代に役立つことを実感した記録。
段階5: 自走 — AIエージェント組織はなぜ自律的に改善されるか
組織がある程度回ると、「誰かが言わなくても改善が湧く」段階に入る。
9. 組織は作ったら腐る
244ファイルを整理した直後、「ついで」に組織の健康診断をしたら、8件の不整合と3つの気づきが出てきた。組織は作って終わりではなく、定期的に健康診断が必要だった。人間組織でも組織再編が定期的に必要なのと同じ構造だ。
10. 増やすより見直す方が難しい
todo-dev / health-dev / blog-dev の3体を skill-dev に統合した実録。エージェントは「増やす」のは簡単だが、「見直す」のは難しい。統合の判断軸と、絡みつき問題の話。組織体制の見直しは管理職の中核業務だが、その難しさはAI組織でも変わらなかった。
11. ガバナンスは構造で持たせる
auto modeで動くAIに「承認」をどう持たせるか。憲法・trigger リスト・上申経路の3層で、AIの提案権とユーザーの承認権を分離した設計。「規程やルールを書くだけでは現場は守らない」という古典的な組織論への、AI時代の答えとして書いた。
12. トークンは削れる箇所と削れない箇所がある
マルチエージェントは確かにトークンを食う。しかし「削れる無駄」と「払うべきコスト」は明確に分かれていた。冗長なエージェント呼び出しと、必要な多段レビューを区別する設計の話。「コストカットで質を落とすか、必要なコストを認めるか」という判断問題そのものだ。
Claude Codeでエージェント組織を1ヶ月動かして何がわかったか
回す段階に入って初めて見えるもの
AIにチームを「持たせる」ことは、想像より簡単だった。1週間で形になる。
しかし、持ったあと「回す」段階に入って初めて、組織の難しさ・ガバナンスの必要性・自走の兆しといった本当に面白い問題が出てきた。1ヶ月運営してみた振り返りとしては、これが一番大きい発見だ。「回す」段階に入って初めて見える問題——AIに任せても、組織論の古典的問題は変わらず再現される、ということだった。
ここから先は2冊目で
1冊目「コードを書けない私がClaude Codeで『AIチーム』を作るまで」はZenn Booksで公開中。1ヶ月運営の経験は、現在準備中の2冊目（仮題：コードを書けない私が、AIに『編集部』を回させるまで）に蓄積されている。
あなたなら、AIエージェントに何を任せ始めますか? 1ヶ月後の組織図を想像してみてください。
番号付き12本のほかに、シリーズの総まとめ系記事として2本あります:
- コードを1行も書かずに、Claude Codeで8体のAIエージェント編集部を作った話（10日間の総まとめ）
- 9体のAIエージェントと電子書籍を2日で作った話（成果物としての電子書籍制作記）
シリーズの全記事は「AIエージェント組織論」カテゴリにまとまっている。新しい記事を出すたびに、ここに追加していく。
この記事は はてなブログ からのクロスポストです。