フレームワークとマルチエージェント

🔄 Quick Recall: 前回のレッスンでガードレール、ヒューマンチェックポイント、モニタリングでエージェントを安全にした。ここからスケールアップ——単一エージェントから、複数の専門エージェントが協働するシステムへ。

1つのエージェントから複数へ

単一エージェントでうまくいくタスクは多い。しかし、タスクが複雑になるとこんな問題が出る：

システムプロンプトが長すぎて焦点がぼやける
1つのエージェントに異なるスキル（リサーチ、分析、執筆）を求めると品質が落ちる
すべてのステップが直列処理で遅い

マルチエージェントシステムはこの問題を解決する。

マルチエージェントのアーキテクチャ

パターン1：パイプライン型

エージェントが順番に処理し、前のエージェントの出力を次が入力にする：

リサーチャー → アナリスト → ライター → エディター

各エージェントが専門タスクに集中。一番シンプルなマルチエージェントパターン。

パターン2：オーケストレーター型

中央の調整役が全体を管理：

        オーケストレーター
       /    |    \    \
  リサーチ 分析  執筆 レビュー

オーケストレーターがタスクを分配し、進捗を監視し、結果を統合する。

パターン3：協調型

エージェント同士がフィードバックループで相互作用：

ライター ←→ レビュアー
   ↑            ↓
   └── 修正 ←──┘

ライターがドラフトを書き、レビュアーがフィードバックし、ライターが修正、品質基準を満たすまで反復。

✅ Quick Check: オーケストレーター型とパイプライン型の違いは？どちらがどんなタスクに適している？

パイプラインは各ステップの順序が固定で、シンプルなワークフロー向き。オーケストレーターは動的にタスクを割り当て、失敗時の再割り当てや並列実行が可能。複雑で予測しにくいワークフローにはオーケストレーター型が適している。

マルチエージェントの設計

以下のタスクにマルチエージェントシステムを設計して。

タスク：[記述]
必要な専門分野：[リスト]

設計に含めるもの：

1. エージェントの一覧
   - 各エージェントの役割
   - 各エージェントのシステムプロンプトの要約
   - 各エージェントのツール
   - 入力と出力

2. オーケストレーション
   - どのアーキテクチャ（パイプライン/オーケストレーター/協調型）
   - タスクの分配方法
   - エージェント間の通信方法
   - 失敗時のハンドリング

3. ガードレール
   - 各エージェントのスコープ制約
   - ヒューマンインザループのポイント
   - 全体のコスト上限とタイムアウト

現行のフレームワークとプラットフォーム

ノーコード/ローコード

Claude Projects — 複数のシステムプロンプトとツールでエージェント的ワークフローを構築
ChatGPT GPTs — カスタムエージェントをActions（API連携）付きで作成
Dify / FlowiseAI — ビジュアルなフローでエージェントを設計

開発者向けフレームワーク

LangChain / LangGraph — Python/JSのエージェント構築フレームワーク
CrewAI — ロールベースのマルチエージェントフレームワーク
Anthropic Agent SDK — Claudeのネイティブエージェント構築SDK
OpenAI Agents API — OpenAIのエージェントフレームワーク

選び方

以下の要件に最適なエージェントフレームワークを推薦して。

要件：
- ユーザーのスキルレベル：[技術者/ビジネスユーザー]
- タスクの複雑さ：[シンプル/中程度/高い]
- 使用するAIモデル：[Claude/GPT-4/オープンソース/未定]
- マルチエージェントが必要か：[はい/いいえ/未定]
- デプロイ環境：[ローカル/クラウド/エッジ]

3つの選択肢を比較して、理由付きで推薦して。

マルチエージェントのアンチパターン

やりがちなミス	なぜ問題か	正しいアプローチ
エージェントが多すぎる	通信オーバーヘッドとデバッグの困難	必要最小限のエージェント数
責任の重複	どのエージェントが担当か曖昧	各エージェントの責任を明確に
ガードレールの欠如	1つの暴走が全体に波及	エージェントごとに独立した制限
テストなしでデプロイ	個別には動いても連携で壊れる	エンドツーエンドのテスト

✅ Quick Check: 「エージェントを増やす＝常に良い」ではない理由は？

複雑さにはコストがある。エージェントが増えると通信オーバーヘッド、デバッグの困難、失敗ポイントの増加が起きる。まず1つのエージェントで始め、「専門化が品質または速度を測定可能に改善する」と示せたときだけエージェントを追加。証拠に基づいてアーキテクチャを決定する。

Key Takeaways

専門エージェントはそれぞれの役割に長ける——複雑なタスクをジェネラリスト1人より良くこなす
オーケストレーターがタスク割り当て、進捗管理、出力統合を担う調整役
3つのアーキテクチャ：パイプライン（順次処理）、オーケストレーター（動的管理）、協調（相互フィードバック）
専門化または並列化のメリットが明確なときだけマルチエージェントを使う
ノーコード（Claude Projects, GPTs）から開発者向け（LangChain, CrewAI）まで選択肢がある
複雑さにはコストがある——エージェントを増やすのは証拠に基づいて判断

Up Next

レッスン8：本格エージェントシステムの構築では、これまで学んだすべてを統合し、実際に使える本番レベルのエージェントシステムを設計・構築する。