# Claude Code Agent Teams ベストプラクティス

> 組織論の知見と実践から導き出された、自律分散型AIエージェントチームの設計・運用指針

## はじめに

Claude Code の Agent Teams は、複数の Claude インスタンスが独立したセッションとして並列に動作し、互いにコミュニケーションしながらタスクを遂行する仕組みである。

これは単なる技術的な新機能ではない。従来のサブエージェント（親エージェントが指示を出し、子が結果を返すトップダウン型）から、各エージェントが自律的に判断し、互いに直接コミュニケーションし、共有タスクリストから自発的にタスクを取得する自律分散型への転換である。

この構造は、人間社会における組織論の発展段階——軍隊型のヒエラルキーから、ティール組織のような自律分散型への進化——と驚くほど正確に重なっている。そしてその対応関係は、単なるアナロジーにとどまらず、実際の運用設計に直接応用できる深い示唆を含んでいる。

本ドキュメントでは、ティール組織の代表事例であるビュートゾルフの組織運営、Anthropic の Nicholas Carlini による16エージェントでの C コンパイラ構築プロジェクト（約 2,000 セッション、10万行、API コスト約 $20,000）の実践知見、そして対話の中で浮かび上がった組織論的考察を統合し、Agent Teams の設計・運用に関する包括的な指針を示す。

---

## 第1章：二つの組織モデル——サブエージェントと Agent Teams

### 1.1 サブエージェント＝中央集権型・トップダウン組織

従来のサブエージェントは、組織論でいえばピラミッド型の指揮命令系統である。

- マネージャー（親エージェント）が全権を握り、部下（サブエージェント）に個別タスクを指示する
- 部下は結果を親に返して終了する。横のつながりはない
- コンテキストウィンドウは親と共有される
- すべての情報はマネージャーを経由する

この構造は**目標と解決策が明確なときは速い**。単一の司令塔が全体を見渡し、効率的にリソースを配分できる。サイバーセキュリティ調査で1つのエージェントハーネスが最大9つのサブエージェントと100以上のツールコールを使って調査を行う、といったケースではこのモデルが適切である。

しかし、環境が複雑で予測不能な場合、マネージャーがボトルネックになる。すべての判断が一箇所を通過するため、**変化への対応が構造的に遅くなる**。

### 1.2 Agent Teams＝自律分散型・ホラクラシー的組織

Agent Teams は根本的に異なるアーキテクチャを持つ。

- **独立セッション**：各チームメイトが独自のコンテキストウィンドウを持ち、プロジェクトのコンテキスト（CLAUDE.md、MCP サーバー等）を独立して読み込む
- **直接コミュニケーション**：チームメイト同士が互いに直接会話できる。サブエージェントとの決定的な違いはここにある
- **共有タスクリスト**：中央のタスクリストがあり、各タスクは pending → in progress → completed の状態を持つ。タスクには依存関係を設定でき、依存先が完了するとブロックされていたタスクが自動的にアンロックされる
- **自律的なタスク取得**：エージェントは割り当てを待つだけでなく、自分でタスクを取りに行ける

### 1.3 組織論のアナロジーが示す具体的な対応関係

この二つのモデルの違いは、既存の組織論のフレームワークと詳細に対応する。

| 組織論の概念 | サブエージェント | Agent Teams |
|---|---|---|
| 意思決定 | トップダウン（親が判断） | 分散型（各自が判断） |
| 情報の流れ | 垂直（親⇔子） | 水平（チームメイト間直接） |
| タスク管理 | 親が配分・制御 | カンバンボード型の自律取得 |
| ボトルネック | マネージャー（親エージェント） | なし（分散） |
| 適した環境 | 目標・手段が明確 | 複雑・予測不能・多角的視点が必要 |
| コスト構造 | 親セッションの一部 | 各インスタンスが個別課金 |

Agent Teams の共有タスクリストはスクラムのカンバンボードに近く、依存関係管理は Jira や Linear のワークフローと同じ発想である。チームメイト同士の相互レビュー・異議申し立ては、心理的安全性のあるチームで起きる「建設的な対立」そのものだ。

---

## 第2章：ビュートゾルフに学ぶ——自律分散が実際にスケールした組織の設計パターン

ビュートゾルフはオランダの在宅ケア組織であり、ラルーの『ティール組織』で最も多くのページを割いて紹介されている事例である。15,000人の組織にマネージャーが一人もおらず、最大12人のチームが約1,000チーム、それぞれが完全に独立して運営されている。バックオフィスに約50人、コーチが約15〜21人いるが、彼らはあくまで現場のサポート役であって管理役ではない。

この組織の設計パターンは、Agent Teams の運用設計にそのまま適用できる。

### 2.1 MVV の言語化＝ CLAUDE.md の設計

**ビュートゾルフの仕組み**

ビュートゾルフでは「組織の基本目標」が明確に定義され、全メンバーに共有されている。しかしその内容は「利用者が自分の暮らしをできる限り長く自分でコントロールできるようにする」という原則レベルのものであり、個々のケースでどうするかは現場チームの裁量に委ねられている。決められた最低限の決まりごとは以下の通りである。

- チーム最大12人のメンバーが約40〜50人の利用者をサポートする
- 各チームは独立しており、ケア・採用・教育・財務すべてに裁量と責任が与えられている
- バックオフィスはサポートに徹する

注目すべきは、この「最小限のルール」の粒度である。「何時に訪問しろ」「このケアプランを使え」ではなく、チームサイズと自律性の原則だけを定めている。

**Agent Teams への適用**

CLAUDE.md はこの「最小限のルール＋原則レベルのミッション」として設計すべきである。

```markdown
## Mission
Rust で書かれた C コンパイラを構築する。
Linux 6.9 を x86, ARM, RISC-V でコンパイルできること。

## Design Principles
- 外部ライブラリに依存しない（Rust 標準ライブラリのみ）
- SSA IR を持ち、複数の最適化パスを可能にする

## Constraints
- 既存のテストを壊す変更は許容しない
- 新機能追加時は必ずテストを同時に書く
```

ここで重要なのは、Agent Teams のチームメイトは毎回新しいセッションで起動するため、**文字通り「毎回ゼロから MVV を読み直す」**という点である。人間の組織では朝会やオールハンズで繰り返し伝えることが大事と言われるが、Agent Teams ではこれが構造的に強制される。だからこそ CLAUDE.md の質が決定的に重要になる。

Carlini が「進捗ファイルや README を常に最新に保つよう指示した」のは、組織の情報透明性・ドキュメンテーション文化を技術的に実装したものである。

### 2.2 透明なフィードバック＝テストスイートと CI

**ビュートゾルフの仕組み**

Buurtzorg Web では、各看護師が提供したケアの質、治療時間などがデータで可視化され、自分でパフォーマンスを把握して改善につなげることができる。同僚からの評価や改善すべき点も記録される。

ここでの核心は、**上司が評価するのではなく、データが鏡となって自己修正が起きる**仕組みだという点である。マネージャーによる人事評価ではなく、客観的なデータと同僚のフィードバックによる自律的な改善ループ。

**Agent Teams への適用**

テストスイートと CI パイプラインがこの「鏡」の役割を果たす。

- **テストは「ほぼ完璧」を目指す**：エージェントはテストが通ることをゴールに動く。テストに欠陥があると、間違った方向に全力で走る。Carlini がプロジェクトで最も時間をかけたのがテストハーネスの設計だったのは、この鏡の精度が全体の品質を決めるからである
- **出力をエージェント向けに最適化する**：コンテキストウィンドウを汚染しないよう出力は数行に抑え、詳細はログファイルに書き出す。`ERROR: <理由>` の形式で grep しやすくする。集計統計を事前に計算して提供する（エージェントに再計算させない）
- **高速フィードバックループ**：デフォルトで 1〜10% のランダムサンプルで高速テストを実行できるようにする。サンプルはエージェントごとに決定的だが、エージェント間ではランダムにし、各エージェントが異なるテストをカバーしつつ素早くリグレッションを検出できるようにする
- **CI で「壊さない」を強制する**：新しい変更が既存テストを壊したらブロックする。これはバリューを技術的に強制するものであり、ビュートゾルフの「最小限のルール」のうち破ってはならない一線に相当する

### 2.3 コーチの役割＝介入しないが環境を整える人間

**ビュートゾルフの仕組み**

チーム内で問題解決の議論が行き詰まった場合、コーチが補助を行う。ただし、**コーチは問題解決をするのではなく、あくまでも議論をファシリテートし、質問の投げかけを行うだけ**である。最終的な問題解決の意思決定は、各メンバーが行う。

**Agent Teams への適用**

Carlini は記事のサブタイトルで「ほぼ放置した（mostly walked away）」と書いている。しかしこれは完全放置ではない。

- テストが失敗するパターンを**観察**した
- 全エージェントが同じバグに群がったとき、GCC をオラクルとして使う新しいテスト手法を**導入**した
- 既存機能が頻繁に壊れるようになったとき、CI パイプラインを**強化**した

つまり「仕事のやり方」には口を出さず、「環境や仕組み」を整えることに集中した。これはサーバントリーダーシップそのものであり、ビュートゾルフのコーチと完全に同じ振る舞いである。

**介入のタイミングと方法**

| シグナル | 対応（環境の調整） |
|---|---|
| 全員が同じ問題に群がっている | タスク分解の方法を見直す。オラクル比較型の並列化手法を導入する |
| テストは通るが品質が低下している | テストの網羅性を見直し、新しいテストケースを追加する |
| 新機能が既存機能を壊し続ける | CI パイプラインを強化し、リグレッション検出を厳格化する |
| マージコンフリクトが頻発する | タスクの分割粒度を見直す |
| 進捗が停滞している | PROGRESS.md を確認し、環境やツールの問題を調査する |

**介入の原則**：エージェントに直接コードの修正を指示するのではなく、テストケースの追加、CLAUDE.md の更新、ツールの導入といった環境側の変更で間接的に導く。

### 2.4 ピアレビュー＝横からのフィードバックで品質を保つ

**ビュートゾルフの仕組み**

Buurtzorg Web では同僚からの評価や改善すべき点を記録する仕組みがあり、管理者による上からの評価ではなく、横からのフィードバックで品質を保っている。看護師間には専門知識の差が存在するが、それは上下関係ではなく、評判や影響力、スキルに基づく流動的で自然発生的な階層として機能する。

**Agent Teams への適用**

エージェント同士が互いの成果をレビューし、異議を唱え合う構造を意図的に設計する。

```
セキュリティ監査チームを作成してください。4人のチームメイト：
1. 認証レビュアー - 認証フローとセッション管理に集中
2. 入力検証レビュアー - すべてのユーザー入力をチェック
3. DB セキュリティレビュアー - クエリとデータアクセスを分析
4. 統合レビュアー - API 境界と外部呼び出しを確認

初期分析の後、互いの発見をレビューし、
不一致や追加の懸念事項を指摘してください。
```

C コンパイラプロジェクトでも、コード品質担当、パフォーマンス担当、重複排除担当、ドキュメント担当など、専門的な視点でコードベース全体を横断的にレビューするエージェントが配置された。また、デバッグでは同じバグに対して複数のエージェントが異なる仮説を立て、互いの仮説を検証・反論し合う「敵対的デバッグ」パターンも有効であった。

---

## 第3章：自律分散型の前提条件——信頼の問題と AI 特有の逆説

### 3.1 人間の組織における信頼のボトルネック

ティール組織やホラクラシーが理論としては美しくても、現実に実践できる組織がごく一部に限られてきた最大の理由は「人」である。構成員全員に高い判断力、自律性、コミュニケーション能力が求められる。ビュートゾルフで働く看護師のチーム内メンバーの約70%が看護師資格（registered nurse）を持ち、40〜65%が学士を取得しているのは偶然ではない。

自主経営は、経営者と従業員、従業員同士の相互信頼なしには成り立たない。信頼できないと、間違いのないように命令やルールで縛ろうとして、現場の自主性に任せることができなくなる。

だから Valve や Gore-Tex のような特殊な企業、あるいはスタートアップの初期フェーズでしか成立しなかった。**個々の判断力が高くないとそもそも機能しない**——しかし、それができる状態であればかなり強いチームになる。

### 3.2 AI エージェントにおける「信頼の定量化」

ここに AI エージェント特有の面白い逆説がある。

人間の組織では「信頼の構築」に時間がかかる。個人の能力を見極め、関係性を育み、段階的に裁量を広げていく。これには数ヶ月から数年を要する。しかし Agent Teams の場合、**モデルの能力が「信頼に足るレベル」に達しているかどうかはベンチマークで客観的に測定できる**。

Opus 4.5 では大規模テストスイートに合格する機能的なコンパイラを生成できたものの、Linux カーネルなどの大規模プロジェクトのコンパイルには至らなかった。Opus 4.6 で Terminal-Bench 2.0 のスコアが 59.8% → 65.4%、OSWorld が 66.3% → 72.7% に上がったことで、初めて「16エージェントの自律分散で10万行のコンパイラを構築し、Linux カーネルをコンパイルする」というレベルのタスクが成立するようになった。

これは人間の組織では実現しにくい**「信頼の定量化」**である。ベンチマークスコアが閾値を超えた瞬間に、「この能力レベルならこの範囲の自律性を与えてよい」という判断が客観的にできる。人間の組織では数ヶ月から数年かかる「信頼の醸成」が、モデルのバージョンアップという形で一夜にして起きる。

### 3.3 運用への示唆

この「信頼の定量化」から導かれる実践的な指針がある。

- **モデル性能に応じて自律度を調整する**：Opus 4.6 で可能な自律度と、Sonnet 4.5 で適切な自律度は異なる。opusplan モデルが計画に Opus、実行に Sonnet を使うのはこの原則の実践例である
- **テストカバレッジを「信頼の指標」として使う**：テストが十分にカバーしている領域では自律度を高くし、カバーが薄い領域では介入頻度を上げる
- **段階的にスケールする**：2〜4 エージェントの小チームで信頼性を検証してから、大規模チームに拡大する

逆にビュートゾルフが人間の組織でこの問題をどう解いたかも、AI エージェントの世界に応用できる。透明なデータによる自己認識、ピアレビュー文化、介入しないが環境を整えるコーチ、最小限の原則と最大限の裁量——これらは「自律的なエージェントをどう運用するか」の設計パターンそのものである。

---

## 第4章：組織の進化の先にあるもの

### 4.1 三つの発展段階

これまでの議論を整理すると、AI エージェントの協調モデルは組織論の発展段階をなぞっている。

**第一段階：ヒエラルキー型（サブエージェント）**

産業革命以降の大企業モデル。目標と手段が明確なときは効率的だが、変化への対応が遅い。

**第二段階：自律分散型（Agent Teams）**

ティール組織やホラクラシーに対応。Opus 4.6 の登場で初めてこのレベルが技術的に成立した。

**第三段階：その先にある可能性**

ラルーの研究で示された重要な知見は、組織の発達段階は単純に「新しいほど良い」わけではないという点である。戦場では軍隊型が最適だし、工場ではプロセス管理型が合理的。自律分散型が最善なのは、環境が複雑で予測不能で、構成員の能力が高い場合に限られる。Agent Teams でも「書き込み中心のタスクではシングルエージェントの方が信頼性が高い」という知見が既に出ている。

では、その先には何があるのか。

### 4.2 生態系型——プロジェクト横断の相互依存

現在の Agent Teams は一つのプロジェクト内の一つのチームに閉じている。しかし現実の世界では、企業は単独で存在しているわけではなく、サプライチェーンやエコシステムの中で相互依存している。

Agent Teams が複数プロジェクトをまたぎ、あるチームの成果物が別のチームの入力になり、そこにフィードバックループが生まれる世界。Amazon が社内 API を強制した結果、各チームが事実上の独立サービスになったのと同じ構図がここに見える。

### 4.3 スティグマジー型——環境を介した間接協調

アリやシロアリのコロニーで見られるスティグマジー（環境痕跡を介した間接的協調）は、実は C コンパイラプロジェクトに既に萌芽が見られる。

各エージェントがロックファイルや進捗ドキュメントを「環境に書き込む」ことで、他のエージェントがそれを読んで次の行動を決めている。直接会話ではなく、**共有された環境の状態そのものがチームの行動を導いている**。

これがさらに洗練されると、明示的な指示やコミュニケーションなしに、環境の変化（テスト結果、コードの状態、ログの内容）だけでエージェント群が協調的に動く世界が見えてくる。誰が指示するでもなく、環境の状態そのものがチームの行動を導く。

### 4.4 自己組織化する組織

今はまだ人間が「チームを4人にして、役割はこう分けて」と設計している。しかし本当の自律分散の先にあるのは、タスクの性質に応じてチームが自発的に生成され、必要なくなったら解散し、メンバーの役割も固定ではなく流動的に変わっていく姿である。細胞が必要に応じて分化し、組織を形成し、役目を終えたらアポトーシスするように。

### 4.5 メタ組織——状況に応じた組織形態の動的切り替え

つまり未来の最適解は、おそらく「一つの組織形態」ではなく、**状況に応じて組織形態そのものがダイナミックに切り替わる「メタ組織」**である。

- 簡単なバグ修正 → サブエージェントが走る（ヒエラルキー型）
- 複雑な機能開発 → Agent Teams が組成される（自律分散型）
- プロジェクト全体の方向転換 → エコシステム全体が再構成される（生態系型）
- そしてその「どの形態を使うか」の判断自体も自動化される

人間社会では「状況に応じて組織形態を切り替える」こと自体がものすごく難しい。しがらみ、慣性、政治、感情がある。しかし AI エージェントにはそれがない。案外、メタ組織は AI 側で先に実現し、そこから人間の組織論にフィードバックされるかもしれない。

---

## 第5章：産業構造への影響——歴史的転換点としての Agent Teams

### 5.1 大企業の優位性の揺らぎ

今まで大企業が強かったのは、**規模の経済とコーディネーションコストの低減**に優位性があったからである。数千人の組織を統率するには階層構造が必要で、その階層構造を維持するにはコストがかかるから、それを負担できる大企業が有利だった。

しかし AI エージェントチームがコーディネーションコストを劇的に下げると、少人数の組織が大企業並みの複雑なプロジェクトを回せるようになる。C コンパイラの事例がまさにそうだ——一人の研究者が16エージェントで10万行のコンパイラを作った。従来ならコンパイラ開発チームとして何十人ものエンジニアが必要だった規模である。

コース（Coase）のトランザクションコスト理論では、企業の境界は市場取引のコストと組織内調整のコストの均衡点で決まるとされる。AI エージェントによって組織内調整のコスト構造が根本的に変われば、**企業の最適サイズも変わる**。むしろ小さくて意思決定が速く、明確な MVV を持った組織の方が、エージェントチームを効果的に活用できる可能性がある。

### 5.2 管理型組織の底上げ——自律分散型への引き上げ

もう一つの、おそらくより重要な視点がある。**AI エージェントによって既存の管理型組織が自律分散型のレベルに引き上げられる**可能性だ。

自律分散型組織の最大のボトルネックは「人」だった。構成員全員に高い判断力と自律性を求めるため、実践できる組織はごく一部に限られていた。しかし AI エージェントが各現場に入って、全体の文脈を理解した上で「今ここで何をすべきか」を判断できるようになれば、話が根本的に変わる。

たとえば従来の製造業では、トップが方針を決め、中間管理職が分解し、現場が実行する構造が必要だった。それは現場の一人ひとりが全体像を把握して自律的に判断するのが現実的に不可能だったからである。AI エージェントがその制約を外せば、中間管理層の役割は「管理・伝達」から「環境設計・ビジョン策定」へと根本的に変わる。

これはまさに Carlini が C コンパイラプロジェクトでやったことの産業スケール版である。そして、これまで一部のエリート組織でしか実現できなかったティール型の自律分散が、AI の支援によってあらゆる業種・規模の組織で実現可能になるとしたら、それは文字通りの歴史的転換点である。

### 5.3 歴史的な位置づけ

産業革命が肉体労働を機械に置き換えて工場制を生み、情報革命がコミュニケーションコストを下げてグローバル企業を可能にした。今起きているのは、**判断と協調のコストが下がることで、組織の在り方そのものが再定義される**転換点である。

---

## 第6章：ガバナンスの設計——自律分散型が暴走しないために

### 6.1 なぜガバナンスが重要か

Carlini は記事の最後に不安を記している。「誰も中身を検証していないコードが大量に生まれることへの懸念」。これは組織論でいえば、自律分散型が暴走したときの統制メカニズムをどう設計するかという問いである。

産業構造が変わるスピードが速すぎると、社会制度や法規制が追いつかない。**技術的にできることと、社会として受け入れ準備ができていることのギャップ**——これをどう埋めるかが、この歴史的転換点を良い方向に着地させるかどうかの分かれ目になる。

### 6.2 ビュートゾルフのガバナンスモデル

ビュートゾルフは「マネージャーなし」だが「ガバナンスなし」ではない。

- **Buurtzorg Web による透明性**：全チームのパフォーマンスがデータで可視化されている。問題があるチームは数字で見えるため、コーチが早期に介入できる
- **チーム間の情報交換**：チーム間での知識共有、助言の提供が制度として組み込まれている
- **最小限だが明確なルール**：チームサイズ上限、基本目標への準拠、バックオフィスのサポート機能への限定——破ってはならない一線は明確に引かれている

重要なのは「階層を捨てること」ではなく「階層的な意思決定を捨てること」である。ガバナンスの構造は残しつつ、意思決定は現場に委ねる。

### 6.3 Agent Teams のガバナンス設計

これを Agent Teams に翻訳すると、多層的な品質保証の設計になる。

**第一層：自動テスト（最低限のゲート）**

機能が正しく動くことの自動検証。CI パイプラインによるリグレッション防止。

**第二層：ピアレビュー（品質向上）**

他のエージェントによるコードレビュー。相互の発見に対する異議申し立て。

**第三層：専門エージェント（組織全体の健全性）**

コード品質、セキュリティ、パフォーマンスを横断的に監視する専門ロールの配置。

**第四層：人間によるスポットチェック（最終的な責任）**

完全放置ではなく、定期的に出力を検証する。エージェントの自律度が上がるほど、「誰がこのコードの品質に責任を持つのか」という問いが重要になる。現時点では人間がその責任を持つべきであり、Agent Teams は「人間の監督下で動く自律的なチーム」という位置づけから逸脱すべきではない。

**透明性の実装**

```markdown
## CLAUDE.md に追記
作業開始時と完了時に PROGRESS.md を更新すること。以下を含めること：
- 現在取り組んでいるタスク
- 試したアプローチとその結果（失敗も含む）
- 残っている既知の問題
- 他のエージェントの作業との関連性
```

特に失敗の記録が重要である。「何をやってダメだったか」のドキュメントが、次のエージェントにとって最も価値のある情報になる。これはビュートゾルフにおける「コーチがファシリテートする振り返りの場」のデジタル版ともいえる。

---

## 第7章：実践ガイド

### 7.1 タスク分解のパターン

自律分散が機能するには、各メンバーが独立して価値を生み出せるようにタスクが分解されている必要がある。ビュートゾルフの各チームが地域ごとに独立してケアを提供できるのは、業務が地域単位で自然に分割されているからである。

**良い分解と悪い分解**

```
✅ 良い分解（独立性が高い）
├── Agent 1: 認証モジュールの分析
├── Agent 2: データベース層の分析
├── Agent 3: API エンドポイントの分析
└── Agent 4: 横断的なセキュリティギャップの特定

❌ 悪い分解（依存関係が強い）
├── Agent 1: すべてのバグを修正（範囲が広すぎる）
└── Agent 2: Agent 1 の完了を待つ（不必要な依存）

❌ 悪い分解（コンフリクトを誘発する）
├── Agent 1: フロントエンドを担当
├── Agent 2: バックエンドを担当
└── ※ 一つの機能変更が両方に及ぶため頻繁に衝突する

✅ 改善案（機能単位で分割）
├── Agent 1: 認証機能（フロント+バック+テスト）
├── Agent 2: 決済機能（フロント+バック+テスト）
└── Agent 3: 通知機能（フロント+バック+テスト）
```

**並列化のパターン**

| パターン | 適用場面 | 例 |
|---|---|---|
| 独立テスト型 | 多数の独立したテストケースがある | 各エージェントが異なる failing test を修正 |
| コンポーネント分割型 | モジュール間の結合度が低い | 各エージェントが異なるライブラリのコンパイルを担当 |
| オラクル比較型 | 巨大な単一タスクを分割したい | GCC を正解として、ランダムに一部を自作コンパイラに差し替えてテスト |
| 多角レビュー型 | 品質の多面的な評価が必要 | セキュリティ、パフォーマンス、可読性を別々のエージェントが評価 |
| 敵対的仮説型 | 原因不明のバグの調査 | 各エージェントが異なる仮説を立て、互いに検証・反論 |

### 7.2 セットアップ

**有効化**

```bash
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
```

または `settings.json`：

```json
{
  "experimental": {
    "agentTeams": true
  }
}
```

**チームの起動例**

```
認証モジュールをリファクタリングします。エージェントチームを作成してください：
- Agent 1: 現在の認証フローを分析し、改善計画を策定
- Agent 2: テストカバレッジを確認し、不足しているテストを追加
- Agent 3: セキュリティ上の懸念点を洗い出し
各自の発見を共有し、計画を統合した上で実装に移ってください。
```

**操作**

| 操作 | キー |
|---|---|
| チームメイト間の切り替え | Shift+Up/Down |
| セッションの表示 | Enter |
| 作業の中断 | Escape |
| 全員の出力を同時確認 | tmux / iTerm2 の split panes モード |

### 7.3 適用判断

| | Agent Teams 推奨 | サブエージェント / 単一セッション推奨 |
|---|---|---|
| **タスクの性質** | 読み取り中心、多角的視点が必要 | 書き込み中心、同じファイル群を変更 |
| **依存関係** | タスク間の独立性が高い | 強い逐次依存がある |
| **目的** | 探索・レビュー・相互検証 | 集中した個別タスク |
| **規模** | 大規模コードベース、複数モジュール | 小規模な修正、単一機能 |
| **コスト許容度** | 並列化の価値がコストを上回る | コスト効率を優先 |

### 7.4 コスト意識

Agent Teams は各インスタンスが個別に課金される。C コンパイラプロジェクトでは 16 エージェント × 約 2,000 セッションで $20,000 のコストがかかった。

- 小さいチーム（2〜4 エージェント）から始める
- 読み取り中心のタスク（コードレビュー）で最初に試す
- トークン消費パターンを理解してからスケールする
- opusplan の思想を応用し、計画フェーズは Opus、実行フェーズは Sonnet にするなどコスト最適化を検討する

---

## まとめ：運用哲学

Agent Teams の運用は、ティール組織の三つの柱と直接対応している。

| ティール組織の柱 | Agent Teams での実践 |
|---|---|
| **自主経営**（セルフマネジメント） | 各エージェントが独自のコンテキストで自律的にタスクを取得・遂行する |
| **全体性**（ホールネス） | CLAUDE.md と共有タスクリストにより、全エージェントが全体像を把握できる |
| **存在目的**（エボリューショナリーパーパス） | テストスイートと設計原則が「何のために作るか」を常に示し続ける |

そして最も重要な教訓は、ビュートゾルフの創設理念と同じである。

> 構成員がプロフェッショナルとして信頼され、専門性を発揮できる場を作れば、管理コストを抑えたまま質の高い成果を生み出せる。

その前提は二つ。構成員の能力が信頼に足るレベルにあること（モデル性能）と、透明なフィードバックの仕組みが整っていること（テスト・CI・ピアレビュー）。

この二つが揃えば、管理するのではなく信頼して、環境を整えて、見守る姿勢が最も高い成果を生む。

これは Agent Teams の運用哲学であると同時に、AI によって組織そのものが再定義されつつある時代に、人間の組織論にも還元されるべき洞察である。管理型組織が AI によって自律分散型のレベルに引き上げられ、コーディネーションコストの構造変化が企業の最適サイズを変え、組織形態そのものが状況に応じて動的に切り替わるメタ組織が出現する——その入り口に、私たちは今立っている。

---

*本ドキュメントは 2026 年 2 月時点の情報に基づく。Agent Teams は Research Preview 段階であり、今後仕様が変更される可能性がある。*

---

## 参考文献・URL

### Anthropic 公式

- [Building a C compiler with a team of parallel Claudes（Nicholas Carlini）](https://www.anthropic.com/engineering/building-c-compiler)
- [Introducing Claude Opus 4.6](https://www.anthropic.com/news/claude-opus-4-6)
- [Agent Teams ドキュメント（Claude Code Docs）](https://code.claude.com/docs/en/agent-teams)
- [Claude Code モデル設定（opusplan 等）](https://code.claude.com/docs/en/model-config)
- [Claude's C Compiler（GitHub リポジトリ）](https://github.com/anthropics/claudes-c-compiler)

### ビュートゾルフ関連

- [Buurtzorg International - Our Organisation](https://www.buurtzorg.com/about-us/our-organisation/)
- [Buurtzorg: scaling up an organization with hundreds of self-managing teams but no middle managers（Journal of Organization Design, 2025）](https://link.springer.com/article/10.1007/s41469-024-00184-y)
- [Buurtzorg: revolutionising home care in the Netherlands（Centre for Public Impact）](https://centreforpublicimpact.org/public-impact-fundamentals/buurtzorg-revolutionising-home-care-in-the-netherlands/)
- [Buurtzorg's back office（Orgdesign Works）](https://orgdesignworks.com/buurtzorgs-back-office/)
- [Implementing Buurtzorg-derived models in the home care setting: a Scoping Review（ScienceDirect, 2022）](https://www.sciencedirect.com/science/article/pii/S2666142X22000017)
- [Buurtzorg's Healthcare Revolution: 14,000 Employees, 0 Managers（Corporate Rebels）](https://www.corporate-rebels.com/blog/buurtzorg)
- [Buurtzorg Nederland（Wikipedia）](https://en.wikipedia.org/wiki/Buurtzorg_Nederland)

### ベンチマーク・モデル比較

- [Claude Opus 4.6 vs Opus 4.5: Benchmarks Explained（Vellum）](https://www.vellum.ai/blog/claude-opus-4-6-benchmarks)
- [Anthropic debuts Opus 4.6 with standout scores（The New Stack）](https://thenewstack.io/anthropics-opus-4-6-is-a-step-change-for-the-enterprise/)

### 組織論

- Frederic Laloux『Reinventing Organizations（ティール組織）』（2014）