前回の記事に引き続き、今回も仮想通貨botの開発状況をまとめていきます。
はじめに
実弾テスト初日(Day-1)で「環境まわり」に集中して得られたノウハウを 10 個 に凝縮しました。
対象読者は――
- Docker/Poetry/pyenv を使って Python × 仮想通貨 Bot を動かしたい人
- “動くが壊れやすい” 開発環境を 安全・再現可能 にしたい人
1. Python バージョンは “ホストで固定 → コンテナで保証”
手順 | 一行メモ |
---|---|
pyenv global 3.12.4 | ホストの minor を固定 |
poetry env use $(pyenv which python) | Poetry 仮想環境も 3.12.4 に揃う |
Dockerfile: FROM python:3.12-slim | 同じ 3.12 でビルドすると “本番だけ ImportError” を回避 |
2. Poetry の dev / prod 分離で軽量イメージ
[tool.poetry.group.dev.dependencies] pytest = "*" black = "*" mypy = "*"
- ビルド時は
poetry install --without dev
- イメージが -80 MB、CI では
pytest
付きで安全網を確保
3. envsubst × entrypoint で “API キー誤コミット” 撃退
# entrypoint.sh(抜粋) envsubst < /app/config.tpl.json > /app/config.json exec python /app/MMbot.py "$@"
.env.prod
にキーを置く(.gitignore
必須)docker compose up -d --env-file .env.prod
で起動- コンテナ内には 展開後の JSON だけが残るのでキー流出リスクが激減
4. コードを止めずに Patch を当てる “Docker Hot-swap”
docker compose exec mmbot \ bash -c 'python - <<PY from importlib import reload, import_module bot = import_module("mmbotbybit") reload(bot) # ← wait_for_fill() を差し替え print("⚡ Reloaded") PY'
- 5 秒 で新ロジックが LIVE に反映
- Fill が途切れないため実弾テストを中断しなくて済む
5. Slack × DB の一致を 10 行でチェック
# scripts/check_fill_consistency.py with sqlite3.connect("trades.db") as c: db_ids = {r[0] for r in c.execute("SELECT order_id FROM trades ORDER BY ts DESC LIMIT 10")} msgs = slack.conversations_history(channel=CH, limit=20)["messages"] slack_ids = {m["text"].split()[1] for m in msgs if m.get("text")} print("✅ 一致" if db_ids == slack_ids else "❗差分", db_ids ^ slack_ids)
watch -n 180 python check_fill_consistency.py
で 3 分ごと に差分検知- 連携齟齬を リアルタイム で洗い出せる
6. “小ロット × 高頻度” ストレステスト
パラメータ | 本番値 | テスト値 |
---|---|---|
lot | 0.001 | 0.0002 |
interval | 10 s | 3 s |
- 1 cycle ≤ 8 s を目標
- Slack 発火数が 4 msg/min を超えても Bot が落ちないか確認
7. 意図的 Fail で “連続失敗 3 回停止” を検証
docker compose exec mmbot python utils/force_fail.py 3
- キルスイッチ → graceful-exit → Docker healthcheck が異常検知 までを一気にテスト
- 本番前に “暴走ループ” シナリオを潰せる
8. Quick PnL サマリーは CSV ワンライナー
docker compose exec mmbot \ python scripts/quick_pnl.py --csv exports/$(date +%Y%m%d)_cycle1.csv
- 用意するのは 20 行未満 の pandas スクリプト
- 休憩タイマーがわりに眺めて「勝率・損益」を即チェック
9. パラメータ探索は “表+コメント” で見える化
# | s_entry | timeout | interval | Fill/Cyc | Win% | PnL | メモ |
---|---|---|---|---|---|---|---|
① | 0.0005 | 30 s | 10 s | 12/20 | 60 | +0.6 | baseline |
② | 0.0004 | 30 s | 10 s | ||||
③ | 0.0004 | 45 s | 8 s |
- 3 行埋めるだけで “改善 or 劣化” が直感的にわかる
- 後で Jupyter に貼れば即グラフ化できる
10. Git ブランチ運用を “feat/日付” に統一
git checkout -b feat/live-cycles-20250503 git add . git commit -m "feat: live test day-1 – execution-list patch" git push -u origin feat/live-cycles-20250503
- “日にち” を入れると タイムラインが一目瞭然
gh pr create -f
でレビュー用 PR を即生成 → 作業の 可視化 が楽
おわりに
Day-1 で得た最大の教訓は 「最小ロットで動かしながら環境を固める」 こと。
pyenv × Poetry × Docker を正しく連携させると、コード改修 → ホットスワップ → 成果確認 が分単位で回せます。
明日は ロット×10 へスケールさせつつ、パラメータ AB テスト と Private WS 即時化 に挑戦予定。
同じ課題に取り組む方は、ぜひここで紹介した Tips を試してみてください。
この記事は開発ノウハウのみを抽出した公開版です。API キー・Webhook URL 等の機密情報は
.env
管理し、リポジトリには一切含めていません。
👇ラジオで話したこと
MMBot開発ログ14|「実弾テストで得た10の学び」──Day-1ログの総整理
こんにちは、よだかです。
今回は、MMBotの本番テスト初日(Day-1)で得た環境まわりの知見10連発をお届けします。
Botを動かすのは一瞬ですが、
**その裏には「動かし続けるための小さな工夫」**が積み重なっています。
同じようにDocker + Poetry + pyenvを使って開発している方に、きっと役立つTipsばかりです。
1️⃣ Pythonのバージョンは“ホストで固定 → コンテナで保証”
- ホスト:
pyenv global 3.12.4
- Poetry:
poetry env use $(pyenv which python)
- Docker:
FROM python:3.12-slim
この3つで 開発環境と本番環境のPythonを一致させておくと、
**「動くのに本番だけImportError」**みたいな地雷が回避できます。
2️⃣ Poetryのdev/prod分離でイメージを軽量化
[tool.poetry.group.dev.dependencies] pytest = "*" black = "*" mypy = "*"
- 本番ビルドでは
--without dev
で不要な開発ツールを除外 - イメージがマイナス80MB
- CIでは
pytest
付きで品質担保
開発と本番の境界をしっかり分けられました。
3️⃣ envsubst × entrypoint で「APIキー誤コミット」撃退
envsubst < config.tpl.json > config.json
.env.prod
にキーを持たせて- 本番時に テンプレートに変数を埋め込む形式
- コンテナ内には
config.json
だけが残る=キー流出リスクが激減
「展開後だけ残す」っていう運用は、ほんとに強力です。
4️⃣ Dockerホットスワップでコードを止めずに修正
docker compose exec mmbot python - <<'PY' from importlib import reload, import_module bot = import_module("mmbotbybit") reload(bot) print("⚡ Reloaded") PY
これは感動した。
コードを直してもBotを止めずに即反映できる。
→ Fillの流れが止まらないので、実弾テストを中断せずに済みました。
5️⃣ SlackとDBの一致チェックを自動化
db_ids = {…} slack_ids = {…} print("一致" if db_ids == slack_ids else "差分")
- Slackで通知された注文と、DBに残っている注文を突き合わせて確認
watch -n 180
で3分おきに自動チェック
ちょっとしたスクリプトですが、通知と記録の齟齬を可視化できて助かります。
6️⃣ 小ロット × 高頻度でストレステスト
lot=0.0002
、interval=3s
など- 1cycle ≤ 8秒以内を目標に回し続けて
- Slack通知が4回/分でもBotが落ちないかを確認
「壊れるギリギリまで攻めておく」ことで、余裕ある設定の目安が見えてきます。
7️⃣ 意図的 Fail で「連続失敗3回停止」を検証
python utils/force_fail.py 3
- 故意にエラーを出して、停止→ヘルスチェック→通知までの流れをテスト
- 「暴走したときにちゃんと止まるか?」を先に潰しておくのは超重要
これがあると本番投入の不安がグッと減ります。
8️⃣ Quick PnL サマリーは CSVワンライナー
python scripts/quick_pnl.py --csv exports/20250503_cycle1.csv
- たった20行のPythonスクリプトで
- 「この1時間でどれだけ勝ってる?」を即チェック
開発者の休憩タイマーがわりに使えるくらいシンプルで良いです。
9️⃣ パラメータ探索は「表+メモ」で見える化
# s_entry timeout interval Fill/Cyc Win% PnL メモ ① 0.0005 30s 10s 12/20 60 +0.6 baseline ② 0.0004 30s 10s ③ 0.0004 45s 8s
- 実験結果を 数字とコメントで並べて見える化
- Jupyterに貼ればグラフ化も即できる
「改善してるのか、悪化してるのか」がすぐ分かるのは本当に大事です。
🔟 Gitブランチ名を“feat/日付”で揃える
git checkout -b feat/live-cycles-20250503
- ブランチ名に日付を入れるとタイムラインでの把握が楽
- GitHubのPRも
gh pr create -f
で即作成
→ コードの進捗が「記録」として残る安心感が大きいです。
✅ おわりに
Day-1の実弾テストで一番大事だったのは、
**「最小ロットで動かしながら、環境を整えていく」**という姿勢でした。
- Pythonのバージョンは揃える
- イメージは軽く
- 設定ファイルは安全に展開
- Slack / DB / PnL の整合性はスクリプトでチェック
この土台があれば、ロットを10倍にしても怖くない。
むしろ戦略だけに集中できるようになります。
🔜 今後の予定|
- ロットを×10にスケール
- パラメータABテスト
- Private WebSocketで約定検知を即時化
ここからがいよいよ収益最大化フェーズの入り口です。
というわけで、今回は“実弾Day-1の全ログ”をギュッと詰め込んでお届けしました。
- インフラが整ってると、テストもデバッグも10倍速になる
- 自分で仕掛けを作って“壊れるポイント”を先に潰しておく
- そして、それをいつでも再現できるようにコード化しておく
これがBot運用の真の強さになります。
良き開発と、安全なスケールアップを。
また次回、お会いしましょう!よだかでした。🎤