前回の記事に引き続き、今回も仮想通貨botの開発状況をまとめていきます。
本記事では「暗号通貨のパンプ＆ダンプスキームの検出」に関する論文をベースにbot開発の過程をまとめていきます。
Detecting Crypto Pump-and-Dump Schemes: A Thresholding-Based Approach to Handling Market Noisehttps://t.co/ctCJEV1MBs
— よだか(夜鷹/yodaka) (@yodakablog) March 22, 2025
ここでは、他通貨ペアのBotを追加し、複数のBotを並列で運用する方法について、設計から実装、運用までを具体的に説明します。
✅ なぜ複数通貨ペアでBotを運用するか？
- 📊 相場分散：BTCだけでなく、ETH、XRP、SOLなども対象にしてリスク分散
- 💰 チャンスの最大化：通貨ごとに異なるP&Dやトレンドに対応
- ⚙️ 再利用可能な設計：共通ロジックを活かして効率的に展開できる
🧩 複数Bot運用の構成イメージ（Docker/Kubernetes運用想定）
├── bots/ │ ├── btcusdt/ │ │ └── config.yaml │ ├── ethusdt/ │ │ └── config.yaml │ └── solusdt/ │ └── config.yaml ├── core/ │ ├── scheduler.py │ ├── detector.py │ ├── executor.py │ └── utils/ ├── deploy/ │ └── deployment-template.yaml
各Botは 通貨ペア別の設定ファイルとインスタンスを持ちます。
🛠️ 1. 各Botの設定ファイル（例：btcusdt/config.yaml）
symbol: BTCUSDT strategy: breakout stop_loss: 3.5 take_profit: 6.0 trade_amount: 0.01 slack_webhook: "https://hooks.slack.com/services/..."
🧠 2. 各Botを個別に起動（Python版）
import yaml
from core.scheduler import get_mode
from core.executor import run_executor
from core.detector import run_detector
from core.logger import get_logger
def launch_bot(config_path):
with open(config_path) as f:
config = yaml.safe_load(f)
logger = get_logger(config["symbol"])
mode = get_mode()
logger.info(f"起動モード: {mode}")
if mode in ["full", "monitor"]:
run_detector(config, logger)
if mode == "full":
run_executor(config, logger)
if __name__ == "__main__":
import sys
launch_bot(sys.argv[1]) # ex. python bot_launcher.py ./bots/btcusdt/config.yaml
🐳 3. Docker/K8sでの同時起動（通貨ペアごとにPod分離）
✅ deployment-template.yaml（テンプレート化して自動展開）
apiVersion: apps/v1
kind: Deployment
metadata:
name: bot-{{PAIR}}
spec:
replicas: 1
selector:
matchLabels:
app: bot-{{PAIR}}
template:
metadata:
labels:
app: bot-{{PAIR}}
spec:
containers:
- name: bot
image: your_dockerhub_user/crypto-bot:latest
args: ["bots/{{PAIR}}/config.yaml"]
env:
- name: PAIR
value: "{{PAIR}}"
PAIRにbtcusdt,ethusdt,solusdtなどを渡して展開します。
📈 4. 複数Botのモニタリング例（Grafana）
| ペア | 勝率 | PnL | アラート |
|---|---|---|---|
| BTCUSDT | 62% | $1,250 | ✅ |
| ETHUSDT | 55% | $870 | ⚠️ |
| XRPUSDT | 67% | $1,040 | ✅ |
🔄 5. 次の拡張ポイント
| 拡張案 | 内容 |
|---|---|
| ✅ Bot追加自動化 | 設定ファイルと通貨ペア名だけでデプロイできる仕組み |
| ✅ 通貨ごとの戦略切替 | config.yaml に個別戦略を記述 |
| ✅ モジュール共通化 | core/ 以下で全通貨共通のロジックを持たせる |
| ✅ 戦略別Botの比較分析 | 勝率・P&LでBotランキング作成可能 |
🔜 次に進めるなら
- 🛠️ 各Botの
config.yaml雛形作成 - 🐳 K8sでの自動デプロイ（Helmやテンプレート）
- 📊 複数Botの統合ダッシュボード構築（Grafana）
次は、上記のテンプレートやKubernetes用マニフェストなどをセットで扱う方法をまとめます。
-
-
開発記録#167(2025/4/3)「論文ベースのbot開発フローpart.29 Bot Ops Full Stack“運用フルスタック”を構築する方法」
続きを見る
👇ラジオで話したこと
複数通貨ペアBotの並列運用
タイトル：Botをスケールさせる──複数通貨ペアの並列運用手法
【オープニング】
こんにちは、よだかです。
今回は「複数通貨ペアBotを並列で運用する方法」をお届けします。
BTCだけでなくETHやSOL、XRPなども同時に動かすことで、リスク分散とチャンス最大化を狙います。
設計から実装、そしてKubernetesでのデプロイまで、初めから終わりまでの流れ全体を解説しますので、ぜひ最後までお付き合いください。
【セクション1｜なぜ複数通貨ペアで運用するのか？】
まずは目的の整理から。
📊 相場分散
- BTCだけに集中すると、BTC特有の急変動リスクを受けやすい。
- ETH、XRP、SOL…それぞれ異なる値動きがあるので、ポートフォリオ全体の安定性が向上します。
💰 チャンスの最大化
- 通貨ごとにパンプ＆ダンプのパターンやトレンド形成タイミングが違う。
- 複数ペアで動かすと、片方が静かなときに他方で稼ぐことが可能です。
⚙️ 再利用可能な設計
- コアロジック（検出・実行・スケジューラ）は共通モジュール化。
- 通貨ペアごとに設定ファイルだけ変えれば新Botを立ち上げられる効率的な構成を目指します。
【セクション2｜並列運用のファイル構成イメージ】
全体をフォルダ構成で見るとこんなイメージです。
bots/
├── btcusdt/
│ └── config.yaml
├── ethusdt/
│ └── config.yaml
└── solusdt/
└── config.yaml
core/
├── scheduler.py
├── detector.py
├── executor.py
└── utils/
deploy/
└── deployment-template.yaml
- bots/：通貨ペアごとの設定
- core/：全Bot共通ロジック
- deploy/：Kubernetesテンプレート
このように分けることで、通貨ペアを増やすときはbots/にフォルダとconfig.yamlを追加するだけ。コア部分には手を入れずに済みます。
core/ フォルダ配下のざっくり役割は以下のとおりです：
- scheduler.py
起動モード（full／monitor）や時間帯ごとの動作切り替えを担います。
例：深夜は監視のみ、日中は検出＋実行のフル稼働、などのスケジュール制御。 - detector.py
論文で示されたしきい値方式をベースに、P&D（パンプ＆ダンプ）を検出するロジックを実装。
市場データの取得→特徴量計算→シグナル生成までを行います。 - executor.py
detector.pyや戦略モジュールから渡されたシグナルを受け取り、実際の注文発注・キャンセル・ロスカットなどを実行。
注文の成功/失敗管理や再試行ロジックもここに収めます。 - utils/
共通で使うヘルパー関数群やユーティリティをまとめたディレクトリ。
例：設定ファイル読み込み、ロガー初期化、APIレスポンスの整形、日時処理など。
【セクション3｜Bot起動スクリプト例】
Pythonでの起動は単純。bot_launcher.pyに設定ファイルパスを渡すだけです。
import yaml
from core.scheduler import get_mode
from core.detector import run_detector
from core.executor import run_executor
from core.logger import get_logger
def launch_bot(config_path):
with open(config_path) as f:
config = yaml.safe_load(f)
logger = get_logger(config["symbol"])
mode = get_mode()
logger.info(f"起動モード: {mode}")
if mode in ["full", "monitor"]:
run_detector(config, logger)
if mode == "full":
run_executor(config, logger)
if __name__ == "__main__":
import sys
launch_bot(sys.argv[1])
- **
get_mode()**でモニタリング専用かフル稼働かを切替 - **
detectorでP&D検出、executor**で発注を実行
このスクリプトを通貨ペアごとに並列実行すると、各ペアが独立して動きます。
【セクション4｜Docker & Kubernetesでの同時起動】
次はクラウド環境。本番はK8s（Kubernetes）推奨です。
🛳️ deployment-template.yaml（一部）
apiVersion: apps/v1
kind: Deployment
metadata:
name: bot-{{PAIR}}
spec:
replicas: 1
selector:
matchLabels:
app: bot-{{PAIR}}
template:
metadata:
labels:
app: bot-{{PAIR}}
spec:
containers:
- name: bot
image: youruser/crypto-bot:latest
args: ["bots/{{PAIR}}/config.yaml"]
env:
- name: PAIR
value: "{{PAIR}}"
- **
{{PAIR}}**にはbtcusdt,ethusdtなどを渡して複数Deploymentを作成 - HelmやKustomizeでテンプレート化すると、自動で全通貨ペアを展開可能
こうすれば、K8sクラスター上にペアごとにPodを分離して同時稼働させられます。
【セクション5｜複数Botのモニタリング例】
Grafanaでダッシュボード化すると、こんな表が常時見られます。
| ペア | 勝率 | PnL | アラート |
|---|---|---|---|
| BTCUSDT | 62% | $1,250 | ✅ |
| ETHUSDT | 55% | $870 | ⚠️ |
| XRPUSDT | 67% | $1,040 | ✅ |
- Prometheusで各Podのメトリクス収集
- Grafanaで勝率・利益・エラーも可視化
- 異常時はAlertmanager経由でSlack通知
これで「どのBotが絶好調か？」「どれに問題があるか？」を一目で判断できます。
【セクション6｜次の拡張ポイント】
並列運用ができたら、さらに以下を検討しましょう。
| 拡張案 | 内容 |
|---|---|
| Bot追加自動化 | 通貨ペア名と設定ファイルだけでデプロイ |
| 通貨ごとの戦略切替 | config.yamlで個別戦略を設定 |
| モジュール共通化 | core/以下のロジックを完全共通化 |
| 戦略別Botの比較分析 | 勝率・PnLでBotランキングを作成 |
これらを組み合わせると、数十ペアのBot管理も視野に入ってきます。
【ラストセクション｜まとめと次回予告】
今日は、複数通貨ペアBotの並列運用を設計からKubernetesデプロイ、ダッシュボードまで解説しました。
次回はさらに踏み込んで、
「テンプレート＆マニフェストセットで一括管理する方法」
をお届けします。
Helmチャート化やGitOpsによる自動化など、運用効率を劇的に上げる手法を紹介しますので、お楽しみに！
おまけトーク｜テーマ：本番環境は「小さく始めて大きく育てる」スモールステップ運用
【タイトル】
「Kubernetesはまだ早い？まずはk3s＆段階的拡張で安全に進もう」
今回のおまけトークは「複数Bot並列運用」の本編に続き、現役のbotter視点からのリアルトークをお届けします。
開発初期にありがちな“やりすぎ”を抑えて、リスク少なくスケールするコツをお話ししますね。
【セクション1｜K8sはオーバースペック？まずはk3sでOK】
本番といっても、最初から大規模Kubernetesクラスターを立てる必要はありません。
軽量版の k3s（ケースリーエス） や Docker Compose で十分カバーできます。
- リソース節約：k3sなら単一マシンでPod管理でき、クラウド費用や運用工数を大幅に削減
- 学習コスト：最小構成で「Deployment」「Service」「ConfigMap」だけ押さえれば、K8sの基本概念は身につきます
- 移行容易：開発環境でk3s→ステージング/本番でフルK8s、とスムーズにスケールアップ可能
**「完璧を目指して導入が遅れる」より、「小さく動かして調整する」**ほうが一歩先に進めます。
さらに「軽量 Kubernetes＝k3s」 と 「Docker Compose」 を比べながら、どんな場面で使い分けると良いのかをサクッと整理します。
1️⃣ そもそも何者？
k3s とは
- CNCF公式の “軽量 Kubernetes ディストリビューション”。
- フルK8sと同じ API／マニフェスト形式で動くのに、バイナリは 100 MB 以下。
- 単一バイナリ・単一プロセスで起動するため、Raspberry Pi や低スペックVPSでも快適。
- スケジューラ／Service Mesh など “周辺機能” を最小構成にして、必要に応じプラグイン追加。
Docker Compose とは
- 複数の Docker コンテナを 1 つの YAML でまとめて起動するツール。
- ボリューム共有、ネットワーク設定、依存順序などの“立ち上げ手順”を簡略化。
- Kubernetes 相当の自動復旧・オートスケール機能は持たない――あくまで「単一マシン上の開発〜小規模運用」に最適。
2️⃣ 私の理解、微修正(今回のおまけトークのために詳しく調べてみた)
誤解ポイント
「k3s はリアルタイム性が求められるアプリにも向く」
▸ 補足：k3s そのものは通信レイテンシを縮めるものではなく、あくまで“軽量化”と“単純化”が強み。リアルタイム要求は ノード性能・ネットワーク設計で決まる側面が大きい。
それ以外のイメージ──「k3s＝軽量K8s凝縮版」「Compose＝Docker群を一括管理」──はバッチリ合っていました。
3️⃣ 何がどう違う？5 つの比較軸
| 比較軸 | k3s | Docker Compose |
|---|---|---|
| 目的 | 小〜中規模でも Kubernetes の運用モデルを維持 | 単一ホストでの 開発・簡易本番 |
| スケール | 複数ノード構成OK、HPA・ローリング更新等も可 | 単一ノード前提。スケールは手動 or docker-compose scale |
| 自己回復 | Pod再スケジュール、ヘルスチェック自動再起動 | restart: always 依存。ノード障害に弱い |
| リソース負荷 | フルK8sより70–80 %軽いが、Composeより重い | 非常に軽い（Docker Engine のみ） |
| クラウド移行 | マニフェストそのまま EKS/GKE へ持ち込み可 | Kubernetesに移す際は 再書き換え必須 |
4️⃣ どちらを選ぶ？
- まずは Compose
- 開発環境／小規模サービス／お試し Bot 1〜2 本 → Compose が手軽。
- Bot が増え始めたら k3s
- 再起動・監視・リソース隔離をコードで完結できる。
- 後に本番クラウド K8s へ“ほぼノー変更”で昇格できるのが最大の利点。
- フルK8sは“さらに先”
- ノード10台以上・オートスケール必須レベルになってからで十分。
【まとめ1】
- Compose＝単機でお手軽、学習コスト最小。
- k3s＝軽い Kubernetes。小さく始めて大きく育てる橋渡し役。
まずは Compose でサクッと動かし、複数 Bot の並列運用が視野に入ったら k3s を試す──このステップアップが、私のような個人開発者には最適解です。
【セクション2｜拡張もスモールステップで】
Botの機能追加も、いきなり全戦略・全通貨ペアを展開するのは危険です。
- まずは1通貨ペア×1戦略で安定稼働
- 次に2通貨ペア×同じ戦略で並列運用をテスト
- 戦略追加は、片方のBotだけに適用→効果測定
- 設定自動化やテンプレート化は、手動運用が安定してから
こうした 小刻みなステップアップなら、バグやミスで大損するリスクを最小化できます。
【まとめ2】
- k3sでライトに始める
- 1→2→nの段階的拡張
これが、中長期でBot運用を成功させる鍵です。
大規模インフラはあとからでも導入できますから、まずは小さく始めて、確実に育てていきましょう。
──以上、現役botterからのおまけトークでした。
最後まで聞いてくださってありがとうございます。
次回の放送でお会いしましょう。よだかでした！