このシリーズでは、仮想通貨botterである私が実際にMMbotの開発サイクルに採用している技術とシステム周りの理解を整理するための記事です。
はじめに
graph LR
A[docker compose up] --> B(build image)
B --> C(run container)
C -->|entrypoint| D(gen+validate json)
D -->|exec| E(core.py)
E --> F{exit reason?}
F -- normal stop --> G(コンテナ終了)
F -- error & restart policy --> C仮想通貨Botの開発において「いかに素早く、安全に、柔軟に、改修しながら動かせるか？」は極めて重要です。本稿で紹介する配線図は、Mac上で開発 → Dockerで隔離環境構築 → コンテナでロジック実行 → 実際の取引所APIと接続という一連の流れを、ファイル構成・起動スクリプト・コンテナライフサイクルごとに可視化し、開発効率と運用安定性を両立させる構成となっています。
このような構成を取る目的、そしてそれに伴う利点・課題をここで整理します。
🎯目的：なぜこの構成にするのか？
| 目的 | 解説 |
|---|---|
| 開発と実運用の分離 | Mac側で開発・実験を行い、Docker内で本番同等の環境を再現することで、事故を防ぐ。 |
| 設定とコードの明確な分離 | .env.prodとテンプレート (config_mainnet.tpl) により、環境パラメータとロジックを分けて管理。 |
| 改修・再起動が速い | コードはホットスワップでき、Docker再起動により即反映。時間効率が非常に良い。 |
| 安全性の確保 | エントリーポイントでバリデーション（jq empty）を実施し、誤った設定でのBot起動を防ぐ。 |
| 監視・通知の仕組み内蔵 | Slack通知やPnLチェックにより、Botの挙動を人間が把握しやすい状態で運用できる。 |
✅メリット
| メリット | 詳細 |
|---|---|
| 環境の一貫性 | Dockerを使うことで「どこでも同じ環境」で動かせる。依存関係のズレで動かない、を防げる。 |
| トラブル検出が早い | JSON生成失敗やAPIキーのミスなどが即座に検出され、即再起動により「放置で事故」が起きにくい。 |
| 再現性が高い | ローカルでの挙動がそのまま本番にも適用できるため、テストの精度が高い。 |
| メンテ性が高い | 実際に触るべきファイルが .env.prodとcore.py にほぼ集約されているため、改修が迷子になりにくい。 |
⚠️デメリット・注意点
| デメリット | 回避・対策 |
|---|---|
| Dockerへの習熟が必要 | 最初はvolumeやentrypointの仕組みが難解。→ 本稿で順を追って学べる構成に。 |
| restartループ時のデバッグがやや煩雑 | jq emptyで落ちると無限再起動になる。→ docker compose logs -f で確認。 |
| ログ肥大化やディスク消費の管理が必要 | ログは外部書き出しされるが、放置すると肥大化。→ ローテーション設計済。 |
| 複数Bot運用時のスケーリングには限界がある | Macローカルで複数起動するとリソースを食う。→ 次項参照。 |
🔁他の手段との比較（ざっくり）
| 手法 | メリット | デメリット | 向いている人 |
|---|---|---|---|
| 直接Python実行（裸運用） | セットアップが簡単 | 環境バラツキ／再現性なし | 超初学者、単発実験 |
| Conda/venvで環境分離 | 標準的な開発方法 | 他マシン展開しにくい | ローカル開発者 |
| Docker + entrypoint.sh構成（本稿） | 可搬性・安全性・再現性◎ | 学習コストあり | 継続的開発者、運用者 |
| KubernetesでBot群を管理 | スケーラブル／死活監視◎ | 初期コスト／設計難 | 複数戦略運用者・上級者 |
| クラウドCI/CDデプロイ（GitHub Actionsなど） | 自動反映／共同開発向け | 初期構築が複雑 | チーム運用 or 上級個人 |
🚀今後スケールしていくための発展パス
以下は、現状の構成をベースにより大規模 or 高信頼性な運用へ進化させていくロードマップ例です：
🔹Step1: 複数Bot対応
- Docker Compose を複数サービス定義に拡張
.env.mmbot,.env.arbbotなどを分離し、同一構成で複数Botを走らせる- ホストのリソース管理（CPU/メモリ制限）を導入
🔹Step2: 自動再デプロイ + Git管理
mainブランチPushでdocker compose down && upを自動化- Gitリポジトリを活用した差分追跡とrollback体制
🔹Step3: リモート稼働・クラスタ化
- VPS（例：さくら／ConoHa／Lightsail）などで稼働
- docker contextやGitHub Actionsでリモート構築・再起動
🔹Step4: Kubernetes（K8s）構成へ拡張
- BotごとにPod管理 → 自動スケーリング・エラーレスポンス・健全性チェック
- ConfigMap / Secretでセキュアな設定分離
- Prometheus / Grafana による可視化
🧵まとめ：この構成は「中級者の壁」を越えるための通過儀礼
- 脱・スクリプト一発芸
- 脱・動いたらOK主義
- 脱・"設定が本体" なのに雑に扱う罠
この構成を使いこなせば、「開発」と「実運用」が自然に連携したBot開発」が可能になります。これが仮想通貨botterとしての中級者から上級者への登竜門です。