【要約】OSSのマルチエージェントシステムで18本のBotを動かすまで — multi-agent-shogun Bot運用体制の全容 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
[WARN: Partial Data] 本記事は連載の序章（Vol.0）であり、実装やバックテストの詳細、インシデントの深掘りは次号以降に続く構成であるため。
// Problem
Bot数の増加に伴う、管理業務の雪だるま式な増大。
- ・毎日のPL（損益）集計と記録。
- ・バックテストの実行と合否判定。
- ・ログファイルの異常監視。
- ・ポジション状態の確認と不一致の検出。
// Approach
マルチエージェントシステムによるタスクの委譲と、多層的な監視体制の構築。
1.エージェントへの役割分担
- ・Ashigaru（足軽）: 実装、デバッグ、ログ異常検知。
- ・Gunshi（軍師）: バックテストのレビュー、品質チェック。
- ・Karo（家老）: タスク割り当て、進捗管理。
- ・Shogun（将軍）: 戦略立案、最終承認。
2.3層監視アーキテクチャの導入
- ・L1: Bot内蔵の最大ドローダウンによる自動停止。
- ・L2: cronによるログ更新時刻の定期監視。
- ・L3: 日次サマリー作成とポジション照合（Reconcile）。
// Result
18本のBotをペーパートレード環境で運用中。厳格なBT基準（IS期間PF≥1.20、OOS/IS比≥0.7等）に基づき、全BotをTier分類。基準をクリアしたETH/JPY Donchian(48h)を筆頭に、2026年5月より本番移行を開始する予定である。
Senior Engineer Insight
> 運用負荷をAIエージェントに委譲する設計は、スケーラビリティの観点で極めて合理的だ。特に「人間は意思決定と承認に集中する」という役割分離が、金融ドメインの安全性とAIの効率性を両立させている。ただし、ファイルベースの通信やtmux上での並列動作は、大規模運用における単一障害点やリソース競合のリスクを孕む。実戦投入には、エージェント自体の死活監視と、通信レイヤーの堅牢化が不可欠である。また、AIによるバックテスト評価の妥当性をどう担保するかが、運用の成否を分ける鍵となるだろう。