マルチエージェント構成でClaude Opusの性能が出ない理由と、オーケストレーター設計の落とし穴

「高性能なモデルを使えば高品質な結果が得られる」——これは一見正しいように思えますが、マルチエージェント構成においては必ずしも真実ではありません。Claude Codeでマルチエージェント設計を行う際、多くの開発者が陥りがちな罠があります。それは、**オーケストレーターのモデル選択がボトルネックになる**という問題です。

村瀬雅俊氏が指摘したこの課題は、AIシステム設計における重要な教訓を含んでいます。単純にClaude Opusのような高性能モデルをサブエージェントとして呼び出せば解決すると考えがちですが、実際にはシステム全体のアーキテクチャを見直す必要があるのです。

典型的なマルチエージェント構成では、以下のような階層構造を考えます。

コンシェルジュ（Sonnet）
  ↓
Agent(model="opus")

この構成の何が問題なのでしょうか。**オーケストレーター（この場合Sonnet）の能力が、システム全体の天井になってしまう**という点です。

オーケストレーターは、タスクを理解し、適切に分解し、各エージェントに指示を出す役割を担います。しかし、Sonnetのような比較的軽量なモデルがオーケストレーターの場合、複雑なタスクを適切に分解・指示する能力に限界があります。結果として、いくら実装側でOpusを使っていても、**不十分な指示しか受け取れないため、Opusの真の能力を発揮できない**のです。

具体例を挙げると：

これは、優秀なエンジニア（Opus）に対して、経験の浅いプロジェクトマネージャーが曖昧な指示を出しているような状態です。

村瀬氏が提案する解決策は明快です。**オーケストレーターと実装者のモデルを一致させる**こと、そして**設計と実装を別セッション・別モデルに分離する**ことです。

パターン1：モデル統一アプローチ

コンシェルジュ（Opus）
  ↓
Agent(model="opus")

オーケストレーターもOpusにすることで、高度なタスク分解と詳細な指示が可能になります。コストは上がりますが、システム全体のパフォーマンスは大幅に向上します。

パターン2：セッション分離アプローチ

より洗練された方法として、設計フェーズと実装フェーズを完全に分離する手法があります。

【セッション1: 設計】
Opus → 詳細な設計書・仕様書を出力

【セッション2: 実装】
Sonnet（またはOpus） → 設計書をもとに実装

このアプローチの優れた点は、**各モデルの強みを最大限に活かせる**ことです。設計には高度な思考力を持つOpusを使い、実装には効率的なSonnetを使う、といった使い分けが可能になります。

他のAIエージェントシステムとの比較

この問題は、Claude Code特有のものではありません。OpenAIのAssistants APIやLangChainなどのマルチエージェントフレームワークでも同様の課題が存在します。

**ChatGPTのカスタムGPTsとの比較**では、GPTsは単一モデルベースのため、この種の「オーケストレーター問題」は発生しにくいですが、その代わりタスクの並列処理や役割分担の柔軟性に欠けます。

**AutoGPTやBabyAGIなどの自律型エージェント**と比較すると、村瀬氏の提案する「明示的なセッション分離」は、より制御可能で予測可能な結果を生み出します。完全自律型は柔軟性が高い反面、コストと予測不能性がネックになります。

メリットと注意点の両面分析

**メリット：**

**注意点：**

適用範囲の考察

このアプローチが特に有効なのは以下のケースです。

1. **複雑なアーキテクチャ設計を伴う開発**：マイクロサービス設計、データモデル設計など

2. **品質要求が高いプロジェクト**：金融システム、医療アプリケーションなど

3. **繰り返し使われるテンプレート開発**：一度高品質な設計を作れば、実装は軽量モデルで回せる

逆に、以下のような場合は従来のシンプルな構成で十分です。

アクション1：現在の構成を診断する

あなたのマルチエージェント構成を見直してください。オーケストレーターに軽量モデルを使いながら、実装側で高性能モデルを使っていませんか？以下のチェックリストで確認しましょう。

- [ ] オーケストレーターのモデルは何か？
- [ ] サブエージェントのモデルは何か？
- [ ] オーケストレーターの指示は十分に詳細か？
- [ ] サブエージェントは期待通りのパフォーマンスを発揮しているか？

アクション2：小規模な実験を実施する

同じタスクを以下の3パターンで試し、品質とコストを比較してください。

1. **Sonnetオーケストレーター + Opusエージェント**（従来型）

2. **Opusオーケストレーター + Opusエージェント**（モデル統一型）

3. **Opus設計セッション → Sonnet実装セッション**（分離型）

具体的には、「RESTful APIの設計と実装」のような中規模タスクが比較に適しています。

アクション3：段階的な移行戦略を立てる

いきなりすべてを変更する必要はありません。以下の優先順位で段階的に導入しましょう。

1. **高優先度タスク**：まず品質が最も重要なタスクでOpusオーケストレーターを試す

2. **テンプレート化**：成功パターンを見つけたら、設計・実装分離のテンプレートを作成

3. **チーム展開**：効果が確認できたら、チーム全体にベストプラクティスとして共有

---

この情報は @村瀬 雅俊 さんの投稿を参考にしています。

マルチエージェント設計において、「どのモデルを使うか」だけでなく「どう組み合わせるか」が決定的に重要です。オーケストレーターの選択は、システム全体のパフォーマンスを左右する最重要の設計判断なのです。