前回の記事に引き続き、今回も仮想通貨botの開発状況をまとめていきます。
0. はじめに
前回は “可観測性” をテーマに、メトリクス取得とログ設計を整えました。
今回は 「手数料を負け筋から勝ち筋へ反転させる」 が主眼です。
データを収集しながらMaker 固定 に到達するまでの試行錯誤と、
安全にデプロイするためのシェル改善を共有します。
1. 到達点（公開版サマリ）
| 項目 | ステータス |
|---|---|
| 注文方式 | PostOnly 100 %（Maker リベート –0.02 %） |
| ループ間隔 | 5 s（旧 8 s：板追従性向上） |
| エントリー判定 | spread% × tick 数 の複合条件 |
| 安全装置 | DD ガード 3 USD / minQty 自動補正 |
| デプロイ | Docker Compose + Poetry / ShellCheck で静的解析 |
| 現フェーズ | 24 h 実弾ミニマム運用で Maker 比率を監視 |
| Next | Lot 拡張 → 動的スプレッド閾値の自動調整 |
2. 今回“新しく”手を入れたポイント（前回と非重複）
| # | 施策 | 目的・効果 | 備考 |
|---|---|---|---|
| 1 | PostOnly 強制フラグ〈FORCE_POST_ONLY=true〉 | すべての約定を Maker に固定し、リベートで手数料を相殺 | CLI ↔ env ブリッジでオンオフ自在 |
| 2 | スプレッド閾値の逆算 | Maker リベート込みで “最低勝てる幅” を理論値から設定 | 具体値は非公開 |
| 3 | tick 判定パラメータ化 (TICK_THR) | 板が詰まった 1 tick ノイズで発注しない | 本番ネットの板厚でチューニング |
| 4 | minQty 自動取得 | 取引所仕様更新に負けない起動ロバスト性 | REST 1 call、0.3 s で完了 |
| 5 | ShellCheck + set -eu | エントリポイントのシェル事故をゼロに | CI で毎プッシュ実行中 |
3. “Maker 固定” を実現するパラメータ設計フロー
- 手数料を先に差し引く
- 残る利幅 = 目標スプレッド
- tick 数で現実幅を検証
flowchart LR Fee["Taker 手数料<br>0.055 % ×2"] -->|逆算| Width["必要スプレッド％"] Width --> Tick["Tick 数に換算"] Tick --> Entry["エントリー閾値 (spread% & tick)"]
Maker リベート（-0.02 %×2）を踏まえないと、
「広がったつもりで実は負けていた」罠にハマります。
4. デプロイを安全にするシェル Tips
| チェック項 | やったこと | Why |
|---|---|---|
| 未定義変数エラー | set -eu 追加 | “typo 1 文字”で即クラッシュ→事故前に検知 |
| 動的フラグ挿入 | ${POST_FLAG:+"$POST_FLAG"} | 空文字なら丸ごと引数を省略 |
| CI 静的解析 | shellcheck entrypoint.sh | コンテナビルド前にヒューマンエラー排除 |
5. 今回の学び
- Maker リベートは“戦略”ではなく“前提条件”
→ 取れないなら MM 戦略を名乗るべきではない、と再認識。 - 閾値は「理論 → 実観測 → 再キャリブレート」のループで締まる
→ データ無しのチューニングは時間の浪費。 - シェルは小さくてもクリティカルパス
→set -euと ShellCheck だけで本番落ちが激減。
6. 次の一手
- Lot 拡張 → スリッページ計測
- 動的
s_entry（ボラティリティ依存）実装 - Maker/Taker 統計を Slack 集計ボットで自動可視化
7. おわりに
エッジを伏せつつ「何を考え、どこを変えたか」は公開できる──
公開することを通して、自分の思考と戦略を再確認できる──
Bot 開発は “情報戦” と “再現性” の両立が難しいですが、
測って・固めて・また測る の繰り返しが遠回りのようで一番速い。
本記事は技術共有を目的としたものであり、投資助言ではありません。
実売買はご自身の判断と責任で。