Claude マルチエージェント連携:Architect + Engineer + Reviewer + Optimizer の四役割パターン

Claude マルチエージェント連携:Architect + Engineer + Reviewer + Optimizer の四役割パターン

Claude に「システムを構築して」と入力すると、モデルはアーキテクチャ設計、コード記述、品質レビュー、パフォーマンス最適化の 4 つの役割を同時に演じる必要がある。コミュニティは、これら 4 つの役割を分割してパイプラインで実行すると、出力品質が大幅に向上することを見つけた。

四役割の分担

このワークフローは Claude の会話を 4 つのステージに分割し、各ステージに独立した役割設定と出力要件を設定する:

役割責任成果物
Architect要件理解、システムアーキテクチャ設計、技術選定アーキテクチャ図、モジュール分割、インターフェース定義、技術決定記録
Engineerアーキテクチャに基づくコード実装、テスト記述完全なコード、単体テスト、結合テスト
Reviewerコード品質、セキュリティ、保守性のレビューコードレビューレポート、課題リスト、修正提案
Optimizerパフォーマンスチューニング、リファクタリング、ドキュメント整備最適化されたコード、パフォーマンスベンチマーク、使用ドキュメント

なぜ効果的か

このパターンの核心的な利点は、役割の分離が認知負荷を軽減することだ。Claude が一つの役割のみに集中するとき:

  • Architect は実装の詳細にこだわらず、システム設計をよりマクロに考えられる
  • Engineer は明確なアーキテクチャドキュメントを受け取り、実装効率が向上する
  • Reviewer は「間違い探し」の視点に立ち、同じモデルによる「自己レビュー」より問題を見つけやすい
  • Optimizer は安定したコードに対してパフォーマンス最適化を行い、「書きながら最適化」による手戻りを回避する

具体的な手順

第一段階:Architect

あなたは资深システムアーキテクトです。以下の要件に基づいてシステムアーキテクチャを設計してください:

要件:[プロジェクト要件を記述]

以下を出力してください:
1. システムアーキテクチャ図(モジュール関係をテキストで記述)
2. 技術選定とその理由
3. モジュール分割とインターフェース定義
4. 潜在的なリスクと対応策

注意:設計のみを出力し、コードは記述しないでください。

第二段階:Engineer

あなたはシニアエンジニアです。以下はシステムアーキテクチャ設計です:

[Architect の出力を貼り付け]

アーキテクチャ設計に基づいてコードを実装してください。要件:
1. モジュールごとに順に実装
2. 各モジュールに単体テストを含める
3. アーキテクチャで定義された技術選定に従う
4. コードコメントを明確にする

注意:アーキテクチャ設計に厳密に従い、アーキテクチャの決定を独自に変更しないでください。

第三段階:Reviewer

あなたはシニアコードレビュアーです。以下は実装済みのコードです:

[Engineer の出力を貼り付け]

以下の次元からレビューしてください:
1. コード品質と可読性
2. アーキテクチャ設計への準拠
3. セキュリティ問題
4. テストカバレッジ
5. エラーハンドリングの完全性

出力形式:重要度 + 位置 + 問題説明 + 修正提案

第四段階:Optimizer

あなたはパフォーマンス最適化の専門家です。以下はレビュー済みのコードとレビューレポートです:

[元のコード + Reviewer の出力を貼り付け]

以下を行ってください:
1. Critical および Warning レベルの問題を修正
2. パフォーマンス最適化を実施
3. ドキュメントとコメントを改善
4. 最終バージョンと最適化説明を出力

コストと制限

コスト: 4 回の API 呼び出し、トークン消費は単一呼び出しの約 2〜3 倍。Claude Sonnet を使用する場合、中型プロジェクトの 4 ラウンド会話で約 50〜150K トークンを消費し、コストは約 $0.5〜5/回。

制限:

  • コンテキストウィンドウ制限: プロジェクトのコード量が多い場合、ステージ間で分割して渡す必要がある
  • 役割切替時の「忘れ」: 役割切替時にモデルが前段の詳細を遗漏する可能性があり、プロンプトで明示的に参照する必要がある
  • 小規模タスクには不向き: 単純なタスクには、単一役割プロンプトの方がコスト効率が良い

適用シナリオ

  • ✅ 適している:中大型プロジェクト、複数ステージ設計が必要なプロジェクト、チームコラボレーション前のプリリサーチ
  • ⚠️ 使用可能:小規模プロジェクトだがコード品質を向上させたい場合
  • ❌ 不向き:ラピッドプロトタイピング、使い捨てスクリプト、単純なデータ変換

主要ソース: