🤖

OSSのマルチエージェントシステムで18本のBotを動かすまで — multi-agent-shogun Bot運用体制の全容

に公開
2件
Python
Bot
仮想通貨
自動売買
マルチエージェント
tech

はじめに

「自動売買Botを1本作ったはいいが、管理が追いつかなくなってきた」

仮想通貨Botを運用していると、こういった壁にぶつかります。Bot数が増えるにつれて、バックテスト結果の管理・実行ログの監視・収益集計など、やることが雪だるま式に増えていきます。

私はこの問題を解決するために、OSSのマルチエージェントシステム「multi-agent-shogun」を導入・カスタマイズしました。現在このシステムを使って18本のBotをペーパートレード環境で運用しながら、本番移行に向けた検証を進めています。

この記事は 「なぜマルチエージェントシステムでBot運用するのか」「どんな体制で動いているのか」 を技術者向けに解説するオーバービュー記事（Vol.0 / 序章）です。Vol.1から始まる本編では、実装・バックテスト・運用・AI活用の4領域を深掘りしていきます。

multi-agent-shogunとは

multi-agent-shogun （GitHub: yohey-w/multi-agent-shogun）は、おしおさん（yohey-w）が作成・公開しているOSSのマルチエージェントフレームワークです。筆者はこのリポジトリをforkして運用しています。

Claude Code（Anthropic）を各エージェントのランタイムとして使用し、複数のAIエージェントがtmuxセッション上で並列協調動作します。エージェント間の通信はファイルベースのメールボックス方式で実装されており、人間への通知はntfyを通じてスマートフォンに届きます。

エージェントの役割分担

システムは4種類のエージェントで構成されています。

エージェント 役割
Shogun（将軍） 最高意思決定者。戦略立案・最終承認
Karo（家老） 統括管理者。タスク分解・足軽への指示・進捗管理
Ashigaru（足軽） 実装担当。コード生成・スクリプト実行・分析
Gunshi（軍師） 分析・QC担当。バックテストレビュー・品質チェック

私はこのOSSを導入・カスタマイズして、仮想通貨Bot運用に特化した体制を構築しました。

なぜマルチエージェントシステムでBot運用するのか

手動管理の限界

Bot数が増えると、以下の作業が積み重なっていきます。

  • 毎日のPL（損益）集計と記録
  • バックテストの実行と合否判定
  • ログファイルの異常監視
  • 新しいBot候補の調査・実装
  • ポジション状態の確認とアンマッチ検出

これを人間が1人でやると、本業や他のことに割ける時間が削られます。特に 「監視作業」 は定型的で認知負荷が高い割に、付加価値が低い作業です。

エージェントが解決すること

multi-agent-shogunを導入すると、以下の作業をエージェントに委譲できます。

足軽（Ashigaru）が担当:

  • Bot実装・デバッグ
  • バックテストスクリプト実行・結果記録
  • 日次PL集計の自動実行
  • ログ異常検知アラートの実装・運用

軍師（Gunshi）が担当:

  • バックテスト結果の合否判定レビュー
  • 新戦略のブレインストーミング（複数視点からの独立分析）
  • 月次Bot入替の判定分析

家老（Karo）が担当:

  • 足軽へのタスク割り当てと優先順位管理
  • 進捗管理・ダッシュボード更新

人間（殿）は 意思決定と承認 に集中できます。本番移行の判断、リスク許容度の設定、戦略の方向性など、AIに任せにくい判断を担当します。

Bot運用体制の現状

稼働Bot一覧

現在、GMOコインのAPIを使ってPythonで18本のBotをペーパートレード環境で稼働させています。Botは大きく3種類に分類されます。

シングルポジション型（単一ポジション管理）

価格ブレイクアウトやテクニカル指標を使ったシグナル型のBotです。1度に1ポジションのみを保有します。

  • ETH/JPY: Donchian(48h)・Volume Breakout・BB+ADX+MA100・CCI Trend
  • BTC/JPY: Donchian(96h)・Keltner Breakout・CCI Trend
  • XRP/JPY: CCI Trend

バックテスト合格基準は厳格で、IS期間（2022〜2024年・36ヶ月）でPF≥1.20、OOS期間（2025年・12ヶ月）でPF≥1.00、OOS/IS比≥0.7、取引数≥50（OOS単独≥10）、DD≤25%、Calmar Ratio≥1.0を要求しています（手数料: GMO Taker 0.05%込み）。この基準を現時点でクリアしているのは ETH/JPY Donchian(48h) の1本です。

マルチポジション型（複数ポジション同時保有）

複数のエントリーポイントに注文を並べる手法です。グリッドトレードや増分建てなど、含み損を許容しながら相場の往来を取る戦略が中心です。

  • ETH/JPY: グリッドトレード、増分型
  • XRP/JPY: グリッドトレード
  • BTC/JPY: グリッドトレード、増分型、ピラミッディング、DCA積立

FX型

AUD/JPY向けのBotです。グリッドトレードと増分型の2本体制で動かしています。

Tier分類と本番移行計画

全Botはバックテスト結果と実績に基づいてTier分類されています。

Tier 条件 移行方針
Tier 1 BT合格 + 取引≥10 + PF≥0.8 1/2ロットで本番移行
Tier 2 BT合格 + 損失なし + 取引<10 1/4ロットで条件付き移行
Tier 3 損失発生 延長・経過観察

旧基準ではTier2が5本存在しましたが、2026年4月16日のBT基準改訂（X案：IS36ヶ月＋OOS=2025年＋手数料込み）で全Bot再評価した結果、Tier2=1本（ ETH/JPY Donchian(48h) ）に絞り込まれました。残りはBT再挑戦待ち（bt_pending）またはペーパートレード中です。本番移行は2026年5月14日を予定しており、BT基準をクリアした ETH/JPY Donchian(48h) を先頭に単独で移行します。

3層監視アーキテクチャ

稼働中のBotは3層の監視体制でカバーしています。

L1（Bot内蔵）: 最大ドローダウンが閾値を超えると自動停止します。Botが自律的に自分を止める仕組みです。

L2（cronによる定期監視）: 1時間ごとにログファイルの更新時刻をチェックします。2時間以上更新がないBotがあればntfyで通知が届きます。

L3（日次サマリー）: 全Botの収支集計とポジション reconcile（GMOコイン APIの実際のポジションとBotの記録を突き合わせる）を行います。

この3層設計は、 2026年4月のサイレント停止インシデントを経て確立 しました。詳細は連載第2弾で解説します。

連載で扱う4領域

この連載では、Bot運用を構成する以下4つの領域を深掘りしていきます。

領域1: 実装（GMOコインAPI・Bot設計）

GMOコインのREST APIとWebSocket APIを使ったBot実装の詳細を解説します。

  • GMOコインAPIの認証・レート制限・エラーハンドリング
  • シングルポジション型Botの設計パターン
  • マルチポジション型の注文管理ロジック（増分建て・ピラミッディング）
  • cronによる定期実行とログ設計

領域2: バックテスト（合格基準・評価フレームワーク）

「どうすれば過学習を避けられるか」という問いに対するアプローチを共有します。

  • IS/OOS（In-Sample/Out-of-Sample）2段階評価の実装
  • PF・Calmar Ratio・OOS比率（≥0.7）を使った合否判定ロジック
  • Bot種別ごとの異なる基準（単ポジ / マルチポジ / DCA）
  • Alphaマイニング: エージェントが自律的にBot候補を生成・評価するパイプライン

領域3: 運用（Tier分類・ポジション管理・IC Monitor）

稼働Botをどう管理するか、実運用での知見を共有します。

  • bot_registry.yamlによる統合管理（単一ソース・オブ・トゥルース）
  • Position Reconcileの設計（ポジション不一致の検出と対処）
  • IC Monitor: Bot間の相関を監視して動的ロット調整を行う仕組み

領域4: AI活用（multi-agent-shogunによる自動化）

マルチエージェントシステムをBot開発にどう活用するか、具体的な事例を紹介します。

  • Alphaマイニングパイプライン: エージェントが自律的にBot候補を生成・BTを実行・合否判定
  • 軍師によるBTレビュー: 人間が見落としやすいパターンをエージェントが検出
  • cron×エージェント協調: 深夜の自律実行フロー設計

現在の収益状況と目標

ペーパートレード開始からの累計収益はプラスで推移しており、黒字化に向けて稼働中です。具体的な数値は月次レポートの記事で公開予定です。

本番移行後は、Tier1 Botが育つにつれて段階的にロットを増やしていく予定です。また、アルファマイニングパイプラインを通じてBotの補充・入替を継続します。

この連載で学べること

この連載は、以下のような方を想定読者としています。

  • Pythonで仮想通貨Botを作っているが、管理が追いつかなくなってきた
  • バックテストが「本当に正しいのか」自信が持てない
  • AIエージェントをBot開発に活用してみたい
  • ペーパートレードから本番移行する際の判断基準を知りたい

コードの実装例、バックテストの設計思想、運用中に発生したインシデントの詳細まで、実際の運用経験をもとに書いていきます。「教科書どおりに作ったのに動かない」「バックテストは優秀なのになぜ本番でうまくいかないのか」といった問いへの答えを、実例から共有します。

次回予告

次回 Vol.1 では、 「11本のBotが約1週間気づかれずに止まっていたインシデント — 検知から対応完了までの2時間の記録」 を詳しく解説します。実際に何が起きたか、どう気づいたか、何を改善したかを一次ソースから紐解きます。

連載記事一覧

  • Vol.0（本記事 / 序章）: OSSのマルチエージェントシステムで18本のBotを動かすまで
  • Vol.1: 11本のBotが約1週間気づかれずに止まっていたインシデント — 検知から対応完了までの2時間の記録
  • Vol.2以降: 実装・BT・運用・AI活用の各領域を深掘り（随時公開）

フォローしておくと新着通知が届きます。

OSSのマルチエージェントシステム「multi-agent-shogun」はおしおさん（yohey-w）が作成・公開しています。筆者はfork版を使用しています。
GitHub（オリジナル）: https://github.com/yohey-w/multi-agent-shogun

GitHubで編集を提案

Discussion