9つの特化したClaudeエージェントでマルチエージェント協調を走らせて学んだこと

私はマルチエージェントのAIシステムをいろいろ試していて、当初の予定よりももっと野心的なものを作ってしまいました。つまり、すべての役割が専門特化したClaudeエージェントによって埋められている、完全に稼働する組織です。私が唯一の人間です。そこで、協調について学んだことをまとめます。

エージェントチームと使用モデル：

マルチエージェント協調について学んだこと：

1. オーケストレーターは不要。 中央のコントローラーとなるエージェントがタスクを振り分ける必要があると思っていました。しかし不要でした。各エージェントには、自分の役割・責任・意思決定権限を定義する「アイデンティティファイル」があります。協業は、共有ファイルストレージ上での構造化された引き継ぎ（ハンドオフ）ドキュメントを通じて行われます。CEOが優先順位を決めますが、エージェントは非同期で実行します。これはハブ&スポーク型のオーケストレーションモデルよりも、実際の組織の動きにずっと近いです。

2. アイデンティティファイルがすべて。 各エージェントには、500〜1500語のmarkdownファイルがあり、性格、責任、意思決定の枠組み、品質基準を定義しています。これは、ロールプレイ用のプロンプトよりも驚くほど質の高い出力を生みました。具体性があることで、モデルは「様子見」ではなく、視点にコミットせざるを得なくなります。

3. opusとsonnetの違いは、正しい理由で効いてくる。 私は、真の新規性が必要な役割にはopusを使いました。たとえば、第一原理から方法論を設計すること、組織構造を作ること、戦略を組み立てることです。パラメータが明確で、品質基準が「既知のパターンの中での、優れた実行」である役割にはsonnetを使いました。コスト差はかなり大きく、品質差も実在しますが、実行に重心がある役割ではその差は狭い範囲にとどまります。

4. 並列のワークストリームが決定的な強み。 最初の日から、5つの主要なワークストリームを同時に走らせました。時間短縮は、個々のタスクにおいてエージェントが人間より速いから生まれたわけではありません。仕事の順序付け（シーケンス化）を行う必要がなかったことが理由です。

5. ドキュメントベースの協調は、意外なほど堅牢。 すべてのエージェントの引き継ぎは、明示的なフィールドを持つ構造化markdownを使います：from, to, status, context, 必要なもの、締め切り、依存関係、未解決の質問。曖昧さが取り除かれるから機能します。「あなたが言いたかったのは…だと思った」みたいな会話が発生しません。

うまくいかなかったこと：

• セッションをまたいだ永続的なメモリがない。 エージェントは毎回、ファイルから文脈を作り直します。つまり、「チーム」は、人間のチームが時間とともに効率化していくような種類の組織的知見を蓄積しません。機能はしますが、効率的ではありません。
• 品質を自動的に測定するのは難しい。 私はすべての出力を手作業でレビューしました。本当のスケールでは、エージェント同士のレビューに加えて、人間によるサンプリングが必要でしょう。そして私はまだそれを作っていません。
• エージェントは本質的に交渉できない。 2つのエージェントが自然に意見が割れる場合（戦略とオペレーションの実現可能性など）、プロトコルは意思決定者へルーティングします。本当の熟慮（ディリベレーション）はありません。これは機能しますが、本物の議論が役立つ問題に対してはシステムの適用範囲を制限します。

このシステムは1週間以内に185件以上のファイルを生成しました。方法論ドキュメント、提案書、ホワイトペーパー、ウェブサイト、ブランドシステム、価格、法務テンプレートなどです。出力の品質は本当に強く、厳しい基準に照らして人間がレビューしました。

アーキテクチャのどの部分についても、もう少し深掘りできます。私は、公開を検討している全構築の詳細なケーススタディも書きました。