現在私が行なっているbotの複数同時展開にあたって、必要なことをまとめてみました。
記事の最後には「私の実行環境であれば、こんな運用体制になる」という例もまとめてあります。
前提
・レンタルサーバーは使用しない
・１台のPCでK8sなどのツールを使うのはOK
・個人開発者が取り組むことが可能な方法
・費用、実装難易度、維持や管理のコストなどの観点も取り入れる
・個人開発者に向いているものという観点で各手法をスコアリング
■ 複数Botを同時展開する主な手法とスコアリング
レンタルサーバーを使わずに複数のBotを同時展開する主要手法を整理し、それぞれを**「個人開発者にとっての推奨度（スコア：5点満点）」付きで比較**します。また、用途別（Botタイプ別）・計算リソース別・コスト/難易度/管理性などの軸で整理した表も含めます。最後に、見落としがちな観点や注意点も提案します。
| 手法 | 概要 | 初期費用 | 実装難易度 | 管理コスト | 推奨度 (5点満点) |
|---|---|---|---|---|---|
| 1. 自宅PC複数台運用 | 複数のPCを用意し、Botごとに実行 | 高 | 中 | 高（ハード管理） | ★★☆☆☆（2点） |
| 2. 1台のPCでDocker並列運用 | 各BotをDockerコンテナで分離 | 低 | 中 | 低（構成が整理されていれば） | ★★★★☆（4点） |
| 3. 1台PCでKubernetes (minikube/k3s) | K8sでBotを管理・自動化 | 中 | 高 | 中～高（学習コスト大） | ★★★☆☆（3点） |
| 4. WSL2 + Docker | Windows環境でも仮想Linux上で動かす | 低 | 中 | 中（Windowsアップデート等の影響あり） | ★★★☆☆（3点） |
| 5. VPS以外の無料クラウド（Colab/GCP F1など） | 一時的な稼働に無料枠を使う | 0 | 中 | 高（制限あり） | ★★☆☆☆（2点） |
| 6. Raspberry Piクラスタ | 小型ボードでBotを分散 | 中 | 高 | 高（電力/配線/熱など） | ★★☆☆☆（2点） |
| 7. リモート実行 with Tailscale/VPN | 自宅に複数Botを走らせ、外部から制御 | 中 | 中 | 中（ネット環境依存） | ★★★☆☆（3点） |
■ Botの種類 × 実行リソース × 推奨手法マトリクス
| Botタイプ | CPU負荷 | ネットI/O | 推奨構成（低コスト順） |
|---|---|---|---|
| Market Making (MM) | 低～中 | 高 | Docker単独 > K8s（複数） |
| アービトラージ | 中 | 高（複数取引所WS） | Docker + 高速ネット回線 |
| 価格予測 + DQN/DDPGなど | 高（GPU使用） | 中 | Google Colab Pro / 専用GPU PC |
| Pump & Dump検出Bot | 中 | 高 | Docker or k3sで分散 |
| 清算Bot（狙い撃ち） | 低 | 高 | 軽量Bot複数 = Docker◎ |
| FRヘッジBot | 低～中 | 高 | 並列実行しやすい = Docker |
| NFTミントBot | 高速反応＆同時WS多数 | 高 | マシンスペックより回線命 |
■ 推奨構成と運用コストの概算比較（目安）
| 手法 | 構成イメージ | 初期費用 | 月次費用 | 運用対象 |
|---|---|---|---|---|
| Docker単体 | 自宅PC + Docker + VSCode | 0円（既存資産） | 電気代のみ | MM / FR / 清算など |
| K8s (minikube/k3s) | 自宅PC or 自宅サーバー上で構築 | 0～3万 | 電気代 + 保守 | 構成が多段になったBot群 |
| 複数PC | ノートPC or 中古PC追加 | 3万～10万/台 | 電気 + メンテ | 高負荷Botを分離運用 |
| Colab/GCP F1 | 無料GPU枠利用 | 無料（上限あり） | 無料（制限付き） | 予測系モデル限定 |
| Raspberry Pi | Pi4 × n台 | 1万台～（台数×） | 電気 + SD破損注意 | ロジック軽めのBot群 |
■ スコアによるランキング（個人開発者向け）
| 順位 | 構成 | 総合スコア（5段階評価） | 解説 |
|---|---|---|---|
| 1位 | Docker（1PC） | ★★★★★ | 学習コストと維持費のバランス最良、MMBotに最適 |
| 2位 | Docker + k3s構成 | ★★★★☆ | 多Bot運用に強い。将来スケーラビリティ良好 |
| 3位 | Colab等無料枠活用 | ★★★☆☆ | 一時的な検証に便利。安定運用には向かない |
| 4位 | PC追加による並列 | ★★☆☆☆ | 高コスト＆保守労力が割に合わない |
| 5位 | Raspberry Piクラスタ | ★★☆☆☆ | 趣味・学習用としては◎、本番向きではない |
■ 補足：追加すべき観点と注意点
| 観点 | 内容 |
|---|---|
| 通信の同時接続数 | BybitなどはWS同時接続数に制限あり。Bot分離だけでなくWS統合設計も検討要 |
| APIキーの分離管理 | 複数Botが同一取引所を利用する場合、キー分離 or Rate Limit調整が必要 |
| 障害時の影響範囲 | 1台に依存しすぎると障害時に全Bot停止。K8s構成なら自動復旧も可 |
| 電源管理 | UPS（無停電電源）を導入すべきかどうかの判断も必要 |
| ネット回線品質 | Bot数が増えると家庭用WiFiでは足りなくなる可能性。PingやJitterの監視も考慮 |
構成例とベンチマーク比較
1台のPCでDockerを使って3種類のBotを並列展開する構成例と、そのベンチマーク比較を整理します。
【前提条件】
- PCスペック例（一般的な開発者向け構成）
- CPU：Intel i7 / Ryzen 7（6〜8コア程度）
- メモリ：16GB以上
- SSD：500GB以上
- OS：Ubuntu or macOS or WSL2（Windows）
- 展開するBot（例）
MMBot：スプレッド監視＆指値リワーク戦略FRBot：Funding RateヘッジBotLiquidationSniperBot：清算トリガー監視 → 成行発注Bot
【構成例：Docker Composeで並列運用】
1. ディレクトリ構成（例）
/my-bots/
│
├── docker-compose.yml
├── mmbot/
│ └── app.py
│ └── Dockerfile
├── frbot/
│ └── app.py
│ └── Dockerfile
├── liqbot/
│ └── app.py
│ └── Dockerfile
└── shared/
└── .env
2. docker-compose.yml の例
version: '3.8'
services:
mmbot:
build: ./mmbot
restart: always
env_file: ./shared/.env
volumes:
- ./logs:/app/logs
frbot:
build: ./frbot
restart: always
env_file: ./shared/.env
volumes:
- ./logs:/app/logs
liqbot:
build: ./liqbot
restart: always
env_file: ./shared/.env
volumes:
- ./logs:/app/logs
【簡易ベンチマーク結果（開発Botの典型パターン想定）】
| Bot名 | CPU使用率 | メモリ使用 | ネットI/O | レイテンシ耐性 | 影響度 |
|---|---|---|---|---|---|
| MMBot | 3–5%/core | 150–250MB | 中（WS継続） | 中（10ms程度） | 低 |
| FRBot | 2–3%/core | 100–150MB | 中（API+WS） | 低（数分単位） | 低 |
| LiqBot | 4–7%/core（待機中は低） | 150MB前後 | 高（WS+高速成行） | 高（~50ms） | 中〜高 |
※このベンチマークは実装が軽量な前提（非GPU, pandas or asyncioベース）で測定した想定値
【運用上の注意】
- CPUはピークで15～20％程度に収まる
→ 通常の開発用PCなら問題なし（他アプリと共存も可） - 同時接続WS数
→ 上限あり（Bybitは同時接続制限あり）
→ WebSocketの共有またはマルチチャネル設計が有効 - ログ保存場所（volume）を統一して
./logsに集約するのが便利（障害時調査がラク） - ネットワークの遅延が最も問題になるのはLiqBot
→ LAN直結・ping監視・自宅ルーター設定確認推奨
【推奨改善オプション】
| 改善項目 | 方法 | 効果 |
|---|---|---|
| WS統合 | 各BotでWS共有モジュールを使う | 接続制限の回避 |
| モニタリング | Prometheus + Grafana導入 | 資源使用量の可視化 |
| フォールトトレランス | restart: always + ヘルスチェック | 自動復旧対応 |
| 時間分散 | Botの実行タイミングずらす（例: 5s差） | スパイク負荷の軽減 |
【まとめ】
- 並列Bot運用はDocker Composeで極めて安定・簡単に管理できる
- 軽量なBotであれば1PCで3〜5Bot同時展開も十分可能
- 本番運用を想定するなら以下が肝：
- ネット回線の品質管理
- WS制限やレートリミット回避設計
- ログ・エラーのリアルタイム監視（Slack通知など）
私の場合：MacBook Air (M2, 2023)／8 GB RAM
MacBook Air (M2, 2023)／8 GB RAM で３種類のBotをDocker Composeで並列運用すると以下の例のようになります。
1. 必要リソース見積もり
| Bot名 | 推定メモリ | 推定CPU | ディスク I/O | ネットI/O |
|---|---|---|---|---|
| MMBot | 200 MB | 5 %／core | ログ出力：1–2 MB/min | WebSocket常時接続 |
| FRBot | 150 MB | 3 %／core | ログ出力：0.5 MB/min | REST＋WS |
| LiqBot (清算狙い) | 250 MB | 7 %／core | ログ出力：1–3 MB/min | WebSocket＋成行発注 |
| 合計 | 600 MB | 15 %／core | 最大6 MB/min | 複数WS／REST |
- RAM：約0.6 GB消費 → 8 GB中問題なし（macOS＋Dockerデーモンで約1–1.5 GB消費を見込む）
- CPU：M2 8コア中2コア程度占有 → 他作業への影響少
- ストレージ：ログで1日最大 ~10 MB/min×60 min×24 h ≒ 14 GB/日の極端ケース。実運用ではローテーション設定で数GB/日以内に抑える必要あり。
2. Docker Desktop 設定
- Docker Desktop → Preferences → Resources
- CPUs：4 （M2の8コアの半分を割当）
- Memory：6 GB （残りはmacOS＋他アプリ用）
- Swap：1 GB（メモリ不足時の保険）
- ディスクイメージサイズ：デフォルトのまま問題なし（245 GB中残45 GB → ログ管理必須）
3. Docker Compose の例（リソース制限付き）
version: '3.8'
services:
mmbot:
build: ./mmbot
restart: always
env_file: ./shared/.env
volumes:
- ./logs/mmbot:/app/logs
deploy:
resources:
limits:
cpus: '1.0'
memory: 512M
frbot:
build: ./frbot
restart: always
env_file: ./shared/.env
volumes:
- ./logs/frbot:/app/logs
deploy:
resources:
limits:
cpus: '0.8'
memory: 384M
liqbot:
build: ./liqbot
restart: always
env_file: ./shared/.env
volumes:
- ./logs/liqbot:/app/logs
deploy:
resources:
limits:
cpus: '1.2'
memory: 512M
deploy.resources.limitsで各コンテナの上限を設定- ログはそれぞれ別フォルダにマウントし、意図しない肥大化を防止
4. ログ管理とディスク圧迫対策
- logrotate をホスト側で設定し、各
/logs/*/*.logを日次ローテート - 古いログを 7日分に限定するスクリプト例（
/etc/logrotate.d/bots）:
/path/to/my-bots/logs/*/*.log {
daily
rotate 7
missingok
compress
notifempty
copytruncate
}
5. モニタリングと障害対策
- docker stats でリソース使用量を定期チェック
- Slack通知など ヘルスチェック用スクリプト を１分おきに実行し、応答しないコンテナを再起動 or 通知
- （オプション）Prometheus + cAdvisor + Grafana を軽量構成で導入
6. プランを詰めていくために追加で必要な情報
通知手段：Slack/Webhookなどリアルタイムで欲しいか
稼働時間帯：24hフル稼働か、開発時間帯のみか
ログ保存ポリシー：詳細ログが要るか、サマリのみで良いか
同時WS接続数：各Botが接続するチャネル数
ネットワーク環境：有線LAN利用可否、ISPのアップリンク容量
まとめ
複数bot展開・運用を考えている方の参考になれば幸いです。
レンタルサーバーを利用しなくても、まずは自分のPC1台でできることから取り組み、それでも運用に困った場合は外部リソースを活用するという手順で今後も開発に取り組んでいきます。
私はPCは2台持ち(型の古いMacBook Airも所持)なので、当面は個人の機材のみでbot運用ができそうですね。MLなどを本格的に取り入れて計算リソースを食いそうになってきたら、外部リソースの利用も検討していこうかなと思います。
👇ラジオで話したこと
1台のPCで複数Botを展開する方法と、運用スタイルの選び方
こんにちは、よだかです。
今回は、自分の開発体制を一歩進めて──複数のBotを同時に動かす方法について話していきます。
レンタルサーバーは使わず、自分のPC1台でDockerやKubernetesを駆使して並列稼働するにはどうすればいいか？
その方法と、私が実際に試してみて良かった構成、負荷のかかり方、注意点などをまとめました。
数Botを同時展開する7つの構成とスコア比較
まずは7つの運用方法をざっくり比較したものからご紹介します。
| 構成 | 初期費用 | 管理コスト | 推奨度（5点満点） |
|---|---|---|---|
| 自宅PCを複数台運用 | 高 | 高（配線や電源） | ★★☆☆☆ |
| 1台のPC + Docker | 低 | 低（構成が整理されていれば） | ★★★★☆ |
| 1台のPC + Kubernetes（k3s） | 中 | 中～高（学習コストあり） | ★★★☆☆ |
| WSL2 + Docker | 低 | 中（Win更新の影響） | ★★★☆☆ |
| Google Colabなど無料枠 | 無料 | 高（制限多い） | ★★☆☆☆ |
| Raspberry Piクラスタ | 中 | 高（電源・熱問題） | ★★☆☆☆ |
| 自宅 + VPN（Tailscale） | 中 | 中（回線次第） | ★★★☆☆ |
私の個人的なおすすめとしては、Docker Composeで1PC内に複数Botを立てる構成が、
コスパ・安定性・学習コストのバランスが一番良かったです。
Botのタイプ別にベスト構成を考える
例えば──
- Market Making（MMBot） → ネットI/Oが高めなので、Dockerで軽く並列展開
- FRヘッジBot や 清算狙いのLiqBot → WSの同時接続に注意しながらDockerで分離実行
- 価格予測系（DQN/DDPG） → 計算負荷が高いため、Colab ProやGPU PCの方が適している
といったように、Botの性質によって構成を選ぶ必要があります。
実例：Dockerで3つのBotを並列展開する構成
実際に私がMacBook Air (M2)／8GB RAMで動かしている構成です。
- Botの構成：
- MMBot（スプレッド監視）
- FRBot（Funding Rateヘッジ）
- LiqBot（清算狙い）
- すべてDockerコンテナで個別に立てて、
docker-compose.ymlで一括管理。
services:
mmbot:
build: ./mmbot
env_file: ./shared/.env
volumes:
- ./logs/mmbot:/app/logs
deploy:
resources:
limits:
cpus: '1.0'
memory: 512M
この形式でログも別フォルダに整理すれば、障害調査もスムーズです。
運用して分かったこと
- RAM消費：合計で約0.6GB → 8GB中なら全然余裕
- CPU：3Bot合わせて2コア分ぐらい。日常作業とも併用可能
- ログ出力：最大で1日10～15GBになるので、logrotateでローテーション設定が必須
また、WebSocketの同時接続数制限にも注意が必要。
Bybitなどは上限があるので、WS共有設計 or マルチチャンネル対応が有効です。
運用を安定させるためのTips
| 項目 | 方法 | 効果 |
|---|---|---|
| WebSocket統合 | WSクライアントを共有化 | 接続制限を回避できる |
| モニタリング導入 | Prometheus + Grafana | 資源使用量がグラフで分かる |
| フォールトトレランス | restart: always + healthcheck | 落ちたら自動復旧 |
| 負荷分散 | 実行タイミングをずらす | CPUやネットのスパイクを軽減 |
あと、Slack通知で異常が即分かるようにするのもかなり効きました。
今後の改善ポイント
- Private WebSocketへの対応（低レイテンシ＆即時fill検知）
- AIによるパラメータ最適化（ABテストを自動化）
- ログ分析 → BigQueryでグラフ化
- 開発Botと本番Botの資源分離（プロファイル管理）
今回のまとめはひとことで言うと、
「PC1台でもここまでできる！」という実感と、そこにたどり着くまでの設計ノウハウ
です。
- まずはDockerで3Bot並列起動
- Slack通知とWS設計を押さえる
- あとはパフォーマンスを少しずつ磨いていく
このフェーズに来ると、ようやく**“Botを運用する面白さ”**が見えてきます。
本番運用に向けた設計で迷っている方は、今回紹介した構成をぜひ参考にしてみてください。
次回も、Botの“中身”と“まわり”の話、両面からお届けしていきます。
🎙️おまけ解説コーナー
「Bot運用の話で出てきた、ちょっと気になる用語まとめ」
ここからはおまけ解説コーナーです。
今日の開発ログの中で出てきた用語の中から、初心者の方にとって聞き慣れないかもしれない言葉を、まとめてざっくり解説していきます。
✅ WSL2（ダブリュー・エス・エル・ツー）
Windows Subsystem for Linux の略。
「Windowsの中に仮想的なLinux環境を作って使える仕組み」です。
DockerやPython環境がLinux想定のまま動かせるので、Windowsユーザーでも開発がしやすくなる便利な機能です。
✅ Google Colab（コラボ）など無料枠
「グーグル・コラボ」と読みます。
Googleが提供しているクラウド上のノートブック実行環境です。
無料でGPUが使えるため、機械学習系のモデルテストや計算負荷の高いBot開発に人気。
✅ VPN（ブイ・ピー・エヌ）と Tailscale（テイルスケール）
VPNはVirtual Private Network の略。
インターネット越しに“自宅のPCを安全に遠隔操作する仕組み”。
Tailscale はそのVPNを超簡単に構築できるサービス名。
Botをリモートから監視したいときに便利です。
✅ Raspberry Pi（ラズベリーパイ）クラスタ
「ラズベリーパイ」は名刺サイズの小型PC。
「クラスタ」はそれを複数台つないで並列処理する構成。
ロジックの軽いBotを分散して動かすのに使われることもありますが、
電源・熱・配線などの管理コストが高く、本番運用よりは実験や学習向けです。
✅ Win更新（ウィンドウズこうしん）
これはWindowsの自動アップデートのこと。
WSL2やDockerを使ってると、再起動で設定が飛ぶことがあるため、Bot運用には注意が必要です。
✅ 清算狙いの LiqBot（リクボット）
「リクボット」＝Liquidation（清算）Bot の略。
- 他人のポジションが清算されそうな瞬間を検知して、
- 先回りして成行で注文を入れるBotです。
高頻度・高速性が求められる戦略のひとつです。
✅ 価格予測系（DQN/DDPG）
読み方は「ディーキューエヌ」「ディーディーピージー」。
どちらも強化学習のアルゴリズム名です。
- DQN：Deep Q Network
- DDPG：Deep Deterministic Policy Gradient
簡単に言えば「学習して勝ち方を覚えていくAI」を作るための方法。
Botに導入すると未来の価格を予測してエントリーするような挙動が実現できます。
✅ 8GB RAM（ラム）
「エイトギガ・ラム」。
RAMは**パソコンの“作業スペース”**のこと。
今回のようなBot運用では
- 1Botあたり200MBくらい
- 合計600MB程度で済むので
8GBのPCでも3Botぐらいは問題なく動かせるという話でした。
✅ RAM消費（ラムしょうひ）
Botやシステムが使っているメモリの使用量のことです。
少なければ少ないほど、他のアプリと共存しやすくなります。
✅ 2コア分
CPUのコア数のうち、Botが使ってる分を表します。
たとえば「M2チップが8コア中2コアを使ってる」なら、
Botは全体の1/4くらいの処理能力を使っている、という意味になります。
✅ logrotate（ログローテート）でローテーション設定
**「古いログを自動で整理する仕組み」**です。
放っておくとログは延々と増え続けるので、logrotate で「1日ごとに新しいログファイルに切り替える」ように設定しておくと安心です。
✅ WebSocketの同時接続数制限（ウェブソケット）
WebSocketはリアルタイム通信のしくみ。
Bybitなどの取引所では「同時に何本までしか接続できない」という制限があります。
Botを増やすとここにぶつかるので、設計で対策が必要です。
補足
✅ Private WebSocket（プライベート・ウェブソケット）は
誰でも自由に使えるわけではありません。
アクセスには 本人確認（認証）＝ログインが必要です。
🔒【どうやって使えるの？】
- 取引所のAPIキー（とシークレット）を使って認証します
- たとえばBybitなら、まずAPIキーを作成し、
それを使ってログインリクエストを送る必要があります
- たとえばBybitなら、まずAPIキーを作成し、
- 認証が成功したら、そのユーザー専用の情報だけが流れてくるようになります
たとえば：- 自分の注文が約定したとき
- ポジションが清算されたとき
- 残高が変わったとき
👥 【Public WebSocketとどう違う？】
| 種類 | 誰でも使える？ | 情報の中身 |
|---|---|---|
| Public WS | ✅ Yes（ログイン不要） | 板情報、価格、出来高など「みんなが見られるもの」 |
| Private WS | ❌ No（ログイン必要） | 自分の注文や残高など「本人専用の通知」 |
**Private WebSocketは、API認証を通過した人だけが使える“本人用のダイレクト通知チャネル”**です。
自由に使えるわけではありませんが、APIキーさえ持っていれば、Botからでも使えます。
なので、Botのなかで「まずログイン」→「専用イベントを受信」という流れを作っておく必要があります。
✅ WSクライアント共有化／WS共有設計 or マルチチャンネル対応
WSクライアント：WebSocketを使う部分のコードのこと。
- 共有化 → 複数のBotが1本のWSコネクションを共有する
- マルチチャンネル → 同じコネクションで複数のチャネル（シンボルなど）を扱う
接続数の制限を超えないようにするテクニックです。
✅ フォールトトレランス
「フォールト」は故障・障害、
「トレランス」は耐性。
つまり「Botが落ちても自動で復旧できる仕組み」のことです。
たとえば：
restart: always healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
みたいに書いておけば、エラー時に再起動してくれるBotになります。
✅ Private WebSocket（プライベート・ウェブソケット）
これは「本人だけが受け取れる通知を流してくれるチャンネル」です。
- たとえば「自分の注文が約定したよ」とか
- 「ポジションが清算されたよ」とか
そういう個人用のイベント通知はPrivate WebSocket経由でリアルタイムに届きます。
✅ BigQuery（ビッグクエリ）
これは Googleが提供する超高速なクラウド型データベース。
CSVやJSONLで出力したBotの損益ログなどを突っ込んで、
SQLで分析・グラフ化・フィルタリングなどができます。
大量データの可視化や傾向分析がしたい人向けのツールです。
今日の用語解説コーナーでした。
気になってた単語がスッキリしたらうれしいです。
Botの運用ってコードだけじゃなくて、その周辺の知識も一緒に育てていく感じが面白いですよね。」
それでは、良き開発と、強い運用を。また次回！よだかでした。🎤