Bot mmnot Tips 環境構築・インフラ 開発ログ

🛠️開発記録#206(2025/5/3)MMbot開発ログ14「実弾テストで得た10の学び」

2025年5月3日

前回の記事に引き続き、今回も仮想通貨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 "$@"
  1. .env.prod にキーを置く(.gitignore 必須)
  2. docker compose up -d --env-file .env.prod で起動
  3. コンテナ内には 展開後の 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.py3 分ごと に差分検知
  • 連携齟齬を リアルタイム で洗い出せる

6. “小ロット × 高頻度” ストレステスト

パラメータ本番値テスト値
lot0.0010.0002
interval10 s3 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_entrytimeoutintervalFill/CycWin%PnLメモ
0.000530 s10 s12/2060+0.6baseline
0.000430 s10 s
0.000445 s8 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 1803分おきに自動チェック

ちょっとしたスクリプトですが、通知と記録の齟齬を可視化できて助かります。


6️⃣ 小ロット × 高頻度でストレステスト

  • lot=0.0002interval=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運用の真の強さになります。

良き開発と、安全なスケールアップを。
また次回、お会いしましょう!よだかでした。🎤

-Bot, mmnot, Tips, 環境構築・インフラ, 開発ログ