サブAgentとOrchestratorはどのように役割分担しますか？どの決定をどの層で行うべきですか？
OrchestratorとサブAgentの役割分担はマルチエージェントシステム設計の核心です——役割分担が不明確だとシステム全体のパフォーマンスとセキュリティの両方が低下します。
Orchestratorの決定（「何をするか」）：
サブAgentの決定（「どのようにするか」）：
サブAgentの4つの主要タイプは何ですか？DeFi Agentシステムではそれぞれどのような役割を果たしますか？
機能的特性による分類では、サブAgentは通常4つのタイプに分類できます：
タイプ1：データ収集サブAgent（Read-only Agent） 読み取りツールのみ（APIクエリ・オンチェーン状態の読み取り）——書き込みツールは一切なし。DeFiシステムでは：各プロトコルのAPY・Gasコスト・トークン価格・流動性深度・オンチェーンアドレスの保有量を照会します。このサブAgentタイプはセキュリティリスクが最も低く——Prompt Injection攻撃を受けても、オンチェーン操作を実行できません。
タイプ2：分析サブAgent（Analysis Agent） データ収集サブAgentの出力を受け取り、推論分析を行います。DeFiシステムでは：プロトコル間の金利差を比較し、Gasコストウィンドウを評価し、市場センチメントを分析し、リバランス推奨を生成します。このサブAgentタイプはLLM推論能力のみが必要で、オンチェーンツールや生の外部データへのアクセスは不要です。
タイプ3：実行サブAgent（Execution Agent） オンチェーン書き込みツール（トランザクションへの署名・コントラクトの呼び出し）を持ち、Orchestratorが承認した操作をオンチェーンで実際に実行します。セキュリティリスクが最も高く、最も厳格なツールホワイトリストと支出上限で設定すべきです。
タイプ4：モニタリングサブAgent（Monitor Agent） システム状態を継続的に監視し、サーキットブレーカーとアラートをトリガーします。DeFiシステムでは：操作ウォレットの残高・戦略ポジションのPnL・市場異常（価格フラッシュクラッシュ・Gasコスト急騰）を監視します。このサブAgentタイプは「観察とアラート」のみを行い、操作上の意思決定は行いません。
サブAgent間の通信プロトコルはどのように設計すべきですか？Agent間のデータ転送にはどのようなセキュリティ考慮事項がありますか？
ほとんどのマルチエージェントシステムでは、サブAgentは直接互いに通信しません——すべての通信はOrchestratorを経由します。この「ハブアンドスポーク」アーキテクチャは設計の選択だけでなく、セキュリティ要件でもあります：
サブAgentが直接通信できない理由：サブAgentAがサブAgentBに直接出力を送れる場合、この通信チャネルがOrchestratorに監視されていなければ、攻撃者はサブAgentAの出力を汚染するだけで、Orchestratorの知らないうちにサブAgentBの行動に影響を与えることができます。これはOrchestratorが見えないコマンドチャネルを開くことになり——重大なセキュリティ脆弱性です。
Orchestratorルーティングのフォーマット要件：サブAgentの出力は厳密にフォーマットされた構造化データ（JSON Schemaで検証）であるべきで、自由テキストではありません。自由テキスト出力は隠れたPrompt Injectionを含む可能性があります。構造化出力 + Schema検証により、OrchestratorはデータをパスするBeforeに異常フィールドをフィルタリングできます。
出力サイズ制限：各サブAgentの出力には明確な最大長制限（例：最大2,000トークン）があるべきです。これにより、侵害されたサブAgentが長い「悪意ある命令」を出力に隠して、システム全体に伝播させるのを防ぎます。
実装推奨：LangGraphの有向グラフ設計を使用する場合、サブAgent間のエッジはサブAgent→Orchestrator、Orchestrator→サブAgentのみを許可し、サブAgent→サブAgentの直接エッジは許可しません。
サブAgentのセキュリティ境界設計原則は何ですか？マルチエージェントシステムでの最小権限の原則はどのように実装されますか？
最小権限の原則（Principle of Least Privilege）をマルチエージェントシステムに適用することは、最も重要なセキュリティ設計の決定の一つです。各サブAgentは具体的なタスクに必要な最小ツールセットと最小承認のみを保持すべきです：
ツールセットの最小化：
get_aave_rates()・get_morpho_rates()・get_gas_price()のみ——書き込みツールは一切なしexecute_deposit(protocol, amount)・execute_withdraw(protocol, amount)——ホワイトリストプロトコルの操作のみ、「任意のアドレスへの転送」ツールはなしget_wallet_balance()・get_position_status()のみ——読み取り専用、書き込みなしコンテキスト情報の最小化：各サブAgentのSystem Promptはタスク実行に必要な情報のみを含み、他のサブAgentの作業ロジックや戦略の完全な設計は含みません。
障害隔離設計：1つのサブAgentの失敗（クラッシュ・攻撃・異常出力）がシステム全体をダウンさせてはなりません。Orchestratorはサブの異常出力をキャプチャし、「サブタスク失敗」としてマークし、リトライ・スキップ・人間へのエスカレーションを決定します。
検証チェックポイント設計：OrchestratorがサブAgentの出力を次に渡す前に「整合性検証」を実行します：出力フォーマットは期待されるJSON Schemaと一致するか？値は合理的な範囲内か？現れるべきでないフィールドや命令が含まれていないか？
具体的なアーキテクチャ：4層サブAgentのDeFi利回り最適化システム
DeFi利回り最適化Agentを4つの協力するサブAgentに分割します：
サブAgent 1：レートコレクター（Rate Collector）
get_aave_usdc_apy()・get_morpho_usdc_apy()・get_compound_usdc_apy()・get_gas_price(){"aave_apy": 4.2, "morpho_apy": 5.1, "compound_apy": 3.8, "gas_gwei": 12}サブAgent 2：戦略アナライザー（Strategy Analyzer）
{"recommended_action": "move_to_morpho", "reason": "APY差0.9%、閾値0.5%超過",...}サブAgent 3：取引実行器（Trade Executor）
withdraw_from_aave(amount_usdc)・deposit_to_morpho(amount_usdc)サブAgent 4：モニター（Monitor）
get_wallet_balance()・get_position_pnl()・check_market_volatility()Orchestratorの役割：サブAgent 1のデータを受け取り、サブAgent 2に渡して分析；金額 > $100の場合はTelegramで人間の確認をトリガー；確認後にapprovalトークンと命令をサブAgent 3に渡して実行。
サブAgentの分業が細かいほど → 各サブAgentのセキュリティ境界がより明確で・ツールセットがより小さく・侵害された場合の影響範囲がより小さくなります；しかしシステムの複雑さ・通信レイテンシ・Orchestratorのスケジューリングロジックの複雑さはすべて線形に増加します。サブAgentが少ない → システムがシンプルで・レイテンシが低く・維持コストが低い；しかし各サブAgentはより広いツール承認が必要（セキュリティ境界が広い）。ベストプラクティス：「機能隔離」と「セキュリティ境界」を主な分割基準とし、「メンテナンスの複雑さの軽減」を制約条件として、現在のビジネス規模に適したバランスを見つけます。