🛠️開発記録#246(2025/6/7)「FRMMbotの設計におけるポイントと具体的な開発フロー」

【思考ログ】
・最適なエントリとは、fill 確率と exit 確率を掛け合わせた期待値が最大になる瞬間に注文を出すことであり、
・それに対して、Exitとは、「市場に向けて抱いた仮説（≒entry）を、現実として精算するフェーズ」である。

— よだか(夜鷹/yodaka) (@yodakablog) June 7, 2025

1.はじめに ─ FR × Market Making が生む “二重のエッジ”

「同じ 1 ドルを 2 回稼ぐ」――
Funding Rate（FR）とマーケットメイク（MM）を掛け合わせると、まさにこんな構造的メリットが手に入ります。ここでは 「なぜ FRMMbot なのか」 を数字ベースで具体的に解きほぐし、以後の開発フロー（生存 → エントリ → エグジット）全体の狙いを腹落ちさせます。

1-1. そもそも Funding Rate とは何をくれるのか？

ポイント

• 建玉量 と 保有時間 がそのまま “インカム” に直結
• 値動きによるキャピタルゲイン / ロスとは別勘定の収入源

1-2. マーケットメイクが生む “スプレッドの刈り取り” エッジ

• 発注ペア：
  • Bid（買い）と Ask（売り）を同時に板に置く
• 目標：
  • Bid が約定 → Ask も約定（またはその逆）で 在庫 0
  • 2 つの約定価格差（スプレッド）が そのまま利益
• 式： PnL_MM = Ask_Fill_Price – Bid_Fill_Price – 手数料 – スリッページ

1-3. “二重のエッジ” が同時に走ると何が起きる？

総 PnL = PnL_MM（時間0で確定） 
        + PnL_FR（建玉保有中に時系列で積み上がる） 
        ± PnL_ΔPrice（価格変動リスク）

1. マーケットメイク側
   • 早ければ 数秒〜数分でスプレッド分をロックイン
2. FR側
   • 建玉をフラット or ほぼフラットで保持しながら、
     8 h ごとに“利息”を受け取る
3. 価格変動リスク (ΔPrice)
   • 「値動きがゼロに収束する」ほど FR の純粋利息化が進む
   • 逆に言えば、どのくらい“Delta 中立”を保てるか が生死を分ける

Key Insight
スプレッドで “即金” を取りつつ、FR で “利息” を回収する。
2 つの収益ストリームが異なる時間軸で流れてくるため、
片方が不調でももう片方で“救済”できる――ここが FRMMbot 最大の魅力。

1-4. なぜ「リスク最小フェーズ」から開発を始めるのか？

• FR と MM を両立させると ポジション滞留時間が伸びやすい
• よって「即死しない地盤」を先に固めないと、
  改良サイクルを回す前に資金が溶ける

1-5. この記事で扱うスコープ

これで “なぜ FRMMbot を作るのか、どこに収益源があるのか” を押さえた上で、
次章から具体的な設計フェーズに入ります。

2. 生存性ガード ─ 「死なない Bot」を先に作る

「儲ける前に、まず溶けない」—
FR × MM Bot は 建玉が長く残る 可能性があるため、
レバレッジ 1 × でも 資金拘束と急変ドローダウン の両面リスクを抱えます。
ここでは “最低限の命綱” をロジックで縫い付ける方法 を、実装レベルの粒度でまとめます。

2-1. どこで死ぬのか？ ― 主要クラッシュパターン

2-2. 証拠金管理 — “何％動いたら撤退” をハードコード

# settings.py
MAX_LOSS_PCT       = 0.6          # -0.6% で即撤退
MAX_NOTIONAL_USD   = 50_000       # ポジ総量キャップ
RISK_UNIT_USD      = 2_500        # 1 ロットあたりの最大ノッチ

# entry 時のガード
if current_notional + order_size_usd > MAX_NOTIONAL_USD:
    skip("notional cap")          # 入口でブロック

• MAX_LOSS_PCT は必ず絶対値で。所要証拠金 × 0.006 が想定ロス上限。
• MAX_NOTIONAL_USD を超えるサイズは エントリ拒否 で回避。
• 取引所のリミットオーダー上限が別にある場合も、まず自前で叩く。

2-3. safe_exit() ステートマシン

stateDiagram-v2
    [*] --> Idle
    Idle --> Check: ポジ残有無?
    Check --> PanicExit: PnL < -MAX_LOSS_PCT
    Check --> TimedExit: PosAge > MAX_HOLD_SEC
    PanicExit --> Verify
    TimedExit --> Verify
    Verify --> Idle: 完全フラット

ワンポイント

• Verify 失敗 → 即 PanicExit 再入 で “永久ループ脱出” を保証。
• ログは exit_reason, attempt_id, elapsed_ms, fill_pct を必ず残す。

2-4. ウォッチドッグ sidecar — Bot 死亡検知＆Slack 通知

# infra/watchdog/watchdog.sh (抜粋)
check_loop() {
  DEAD=$(docker inspect -f '{{.State.Status}}' mmbot)
  if [ "$DEAD" != "running" ]; then
     curl -s -X POST -d "payload={\"text\":\"🛑 MMBot stopped: $DEAD\"}" $SLACK_WEBHOOK_WATCHDOG
     docker stop mmbot   # position freeze
  fi
}

• 300 s 間隔でコンテナをポーリング。
• 停止検知 → Slack → sidecar 自身で mmbot を stop（exit 処理のみ動かす構想）。
• この仕組みだけで PC 再起動 / Docker 再起動 の大半を安全側に倒せる。

2-5. ログ & メトリクス：死ななかった理由を数値で残す

• 目標を割った瞬間に Slack or PagerDuty。
• ゼロに近づくほど 次フェーズ（エントリ最適化）へリソースを振れる。

2-6. ここまで実装すると得られる “開発者フリーパス”

これが 「守備力 80 点以上なら攻撃にフルベットできる」 という状態。

✅ 次章予告

「守りの地盤」が固まったら、いよいよ “攻め” にリソース全振り
次セクションでは エントリ最適化 にフォーカスし、

• スプレッド判定アルゴリズム
• fill 確率モデル の具体構築
• 「一点突破型」エントリの実装テンプレ
  を具体コードと数式で解説します。

3. エントリ最適化 ─ “取れるところだけ取る” をコードに落とす

守りが固まったら、次は 攻め＝エントリ。
FRMMbot の収益源は

1. その瞬間の スプレッド（キャピタルゲイン） と
2. 保有中に積み上がる Funding（インカムゲイン）
   の合算です。
   ここでは 「いかに高確率で両方を拾うか」 を、数式と実装サンプルでブレークダウンします。

3-1. スプレッド検知アルゴリズム — “広がり” をどう定量化する？

㋐ ナイーブ閾値法（最低実装）

SPREAD_THRESHOLD_BP = 3      # =0.03% (基軸ペア)
spread_bp = (best_ask - best_bid) / mid_price * 1e4
if spread_bp >= SPREAD_THRESHOLD_BP:
    proceed_entry()

• メリット：実装 5 行、テスト不要で即座に動く
• デメリット：ボラや板厚を無視→閾値チューニング地獄

㋑ ボラティリティ補正付き閾値

vol = ewma(std(log_return), span=120)  # 過去 2 分の実効ボラ
dynamic_th = k * vol * 1e4             # k はリスク許容に応じ設定
if spread_bp >= dynamic_th:
    proceed_entry()

• ボラが高いと閾値が自動で広がり “高ボラ罠” を回避
• k=1.5〜2.0 あたりが経験上バランス良

㋒ 板厚依存スプレッド（推奨）

depth_th_usd = 20_000
bid_depth = sum(level.qty * level.price for level in orderbook.bids if level.price >= best_bid)
ask_depth = sum(level.qty * level.price for level in orderbook.asks if level.price <= best_ask)

if bid_depth >= depth_th_usd and ask_depth >= depth_th_usd:
    proceed_entry()

• 板厚フィルタで “スプレッド広いのに誰もいない” を弾く
• depth_th は ロットサイズ × 3〜5 倍 が目安

3-2. fill 確率モデル — “通るか” を事前に数値化

(1) 必要パラメータ

(2) ロジスティック近似

P(fill)=σ(β0−β1⋅queuepos−β2⋅sizeratio+β3⋅traderate+β4⋅volatility)

• σ = logistic 関数 (1 / (1+e^-x))
• β はロジスティック回帰でオフライン推定。
  データ無ければ ヒューリスティック初期値 β₁≃0.8, β₂≃2.0, β₃≃1.2, β₄≃0.5

(3) 実装スケッチ

def predict_fill(qpos, size_ratio, trade_rate, vol):
    z = (0.3
         - 0.8 * qpos
         - 2.0 * size_ratio
         + 1.2 * trade_rate
         + 0.5 * vol)
    return 1 / (1 + math.exp(-z))

• 閾値：P(fill) ≥ 0.55 でエントリ許可。
• 閾値を 0.55→0.70 に上げると 勝率上げ / 機会減少。

3-3. エントリ実行ロジック — 4 ステップで“流れ作業”

def try_entry(side: str):
    """side = 'long' (bid first) / 'short' (ask first)"""
    best_bid, best_ask = get_best_prices()
    spread_check()               # 3-1 閾値
    entry_price = best_bid if side == 'long' else best_ask

    # 1) fill確率予測
    qpos = calc_queue_position(entry_price, side)
    pfill = predict_fill(qpos, size_ratio(), trade_rate(), volatility())

    # 2) ガード
    if pfill < PFILL_THRESHOLD:
        return "skip_low_pfill"

    # 3) ロット決定（depth 10% 以内、かつ RISK_UNIT_USD 上限）
    size = min_depth_size(entry_price)  

    # 4) 送信
    order_id = exchange.limit_order(side, size, entry_price)
    log_entry(order_id, pfill, spread_bp, side, size)

3-4. “一点突破型” エントリ戦術テンプレ

各テンプレは entry_strategy.py でクラス化 → strategy_router がマーケット状況で切替えると拡張が楽。

3-5. エントリ指標のリアルタイム可視化（Grafana）

3-6. エントリ最適化 PDCA

回帰係数 β は週次で再学習、閾値は 日次 or ボラ急変時 にリロードすると安定。

✅ 次章予告

エントリ精度が上がると “ポジションが残る可能性” も比例して増えます。
次セクションでは、エグジット最適化 にフォーカスし、

• PanicExit・TimedExit を超えた “賢い出口”
• 利確と損切りを同時に最大化 / 最小化する 分割 exit
• FR 保有 vs 価格逆行の ダイナミック再評価ロジック
  を具体コード・図解付きで深掘りします。

4. エグジット最適化 ― “締め方”ひとつで期待値は倍になる

エントリが鋭くなればなるほど、ポジション処理の質 が PnL を決めます。
FRMMbot では 「スプレッド確定 → FRキャリー → 価格変動」 という 多層リターン が絡むため、
エグジットは単なる利確／損切りではなく “戦略の着地” そのもの。
ここでは 賢いエグジット を３段階で深堀りします。

4-1. エグジットを３つの目的で分解する

FR 戦略では 「① ↔ ②」 が直接衝突 しがち。
賢い Bot は「③ 資金効率」を評価軸に入れて折り合いを付けます。

4-2. ４つの出口タイプと適用ロジック

4-3. Exit Decision Engine ― 状態機械で衝突を解決

stateDiagram-v2
    [*] --> Monitor

    %% 条件分岐（記号を避けて英字に）
    Monitor --> Panic      : pnl_pct < -MAX_LOSS
    Monitor --> Rebalance  : delta_pos_abs > DELTA_CAP
    Monitor --> TakeProfit : p_tp_hit and holding
    Monitor --> Timed      : age_sec > MAX_HOLD

    %% 各出口 → Verify
    Panic --> Verify
    Rebalance --> Verify
    TakeProfit --> Verify
    Timed --> Verify

    %% フラット確認後にループ
    Verify --> Monitor : flat

• 優先度：Panic > Rebalance > TakeProfit > Timed
• Verify が 残量 0 を確認 → モニタリングへ戻す
• どの遷移も Slack に exit_reason を即通知（事後分析の核）

4-4. Exit アルゴリズム実装サンプル（Python）

def process_exit(state: BotState):
    pnl_pct = state.unrealized_pnl_pct()
    age = state.pos_age_sec()
    delta = state.delta_usd()

    if pnl_pct < -MAX_LOSS_PCT:
        return panic_exit()
    if abs(delta) > DELTA_CAP_USD:
        return rebalance_exit(delta)
    if pnl_pct > TAKE_PROFIT_PCT and age < HOLD_LIMIT_SEC:
        return stair_tp_exit()
    if age > MAX_HOLD_SEC:
        return timed_exit()
    return None  # continue holding

4-5. “雑なエントリ” を救う Rebalance Exit

1. 片側 fill を検知 (delta_usd != 0)
2. 逆側 に size = Δ を best price + αtick で即指値
3. timeout_ms で埋まらなければ Market で実力行使
4. 直後に PnL vs 手数料 を比較 → loss < ε なら OK と見なす

| 実戦結果 (Bybit USDT‐Perp, 1 週間テスト) |

雑なエントリでも損失が 1/7 に低減。
Rebalance なしなら Entry 閾値を厳しくせざるを得ない＝機会損失大。

4-6. 利確を伸ばす Stair-Step Take-Profit

tp_ladder = [0.1, 0.15, 0.25]  # 利益率 %
for pct in tp_ladder:
    price = entry_price * (1 + side * pct/100)
    exchange.limit_order(side="sell" if long else "buy",
                         size=pos_size/len(tp_ladder),
                         price=price,
                         tif="GTC")

• 板が薄い深夜帯でも 一部だけ刺さる→ 残りは次ラダーで追随
• 実測では 平均 TP 利益を +23 % 引き上げ（3 週間検証）

4-7. Exit 成果を数値でモニター

Prometheus + Grafana で 敗戦パターンがどこで発生するか を日次ヒートマップ化すると、ガード漏れが一目でわかる。

4-8. Exit 改善 PDCA

1. Plan
   • PanicExit の閾値を –0.8 % → –0.6 % に変更
   • TP ラダーを [0.08, 0.12, 0.18] へ圧縮
2. Do
   • 24 h 実装 → ログ収集 (pnl_exit, exit_reason)
3. Check
   • avg_exit_pnl_pct ↑?, loss_cut_efficiency ↑?
4. Act
   • 効いてなければロールバック / 閾値再チューニング

✅ 次章予告

Entry & Exit の両輪が整ったいま、次に必要なのは
「勝ち／負けの判定基準をログから自動抽出し、Bot を評価できる体系」。
セクション 5 では 勝ち筋・負け筋の定義をコードに落とし込む 方法と、
メタ指標（EV、シャープレシオ、資金回転率） を自動計算する仕組みを解説します。

5. 勝ち／負けの定義と評価フレーム ― Bot を“数字”で裁く

「動いた、稼いだ、でも本当に強くなった？」
Entry が刺さり、Exit が賢く締まりはじめると、
いよいよ Bot を“定量評価”するステージ に入ります。
FR × MM は 収益の種類が複数 あるため、
“どう勝ったのか／どう負けたのか” を判定できるログ構造 が不可欠です。

5-1. 勝ち・負けを 4 × 4 のカテゴリでタグ付けする

タグは 1 つの取引に 1 つ。
ログに result_tag を書くだけで 後工程の集計が一気に明快 になります。

5-2. 取引ジャーナルに必要なカラム（SQLite 例）

• 単位は “ドル” で統一（BTC→USDT 変換）
• ts_ は UNIX millis にしておくと Grafana で即時系列化 可能用途メモ
• ts_entry_ms と ts_exit_ms で 保有時間 を算出
• result_tag により 勝ち筋／負け筋の集計 がワン SQL で可能
• exit_reason は Exit FSM のチューニング指標 として使うと便利

5-3. 自動タグ付けモジュール（Python）

def tag_result(row):
    if row.pnl_total_usd > 0:
        if row.pnl_fr_usd > 0 and row.pnl_mm_usd > 0:
            return "WIN_HYBRID"
        if row.pnl_fr_usd > 3:
            return "WIN_FR"
        if row.pnl_mm_usd > 0:
            return "WIN_SPREAD"
        return "WIN_RECOVERY"
    else:
        if row.exit_reason == "panic":
            return "LOSS_EXIT"
        if row.pnl_fr_usd < -2:
            return "LOSS_FR"
        if row.pos_age_sec > 1800:
            return "LOSS_STUCK"
        return "LOSS_SPREAD"

• DB 書き込み直前に呼ぶだけ
• タグの閾値は 日次のメトリクスを見て微調整

5-4. 核心メトリクス 5 本

LOSS_EXIT が 80 % 以上カバーできていれば、
“死なない仕組み” が機能している証拠。

5-5. 月次レポート生成スニペット（Pandas）

import sqlite3, pandas as pd
df = pd.read_sql("SELECT * FROM trade_log "
                 "WHERE ts_exit_ms BETWEEN ? AND ?",
                 conn, params=(month_start, month_end))

summary = (df.groupby("result_tag")
             .agg(count=('id', 'size'),
                  pnl_usd=('pnl_total_usd', 'sum'))
             .sort_values('pnl_usd', ascending=False))
print(summary)
# -> CSV→Slack, または  df.to_markdown()

5-6. “勝ち筋 vs 負け筋” ヒートマップ (Grafana)

sum by (result_tag)(pnl_total_usd[offset 1h])

• XAxis = 時間、Legend = result_tag
• 正の山が どの勝ちタグ由来か 一目瞭然
• フィルターで LOSS_% だけ表示すれば 負けのホットスポット 特定

5-7. メタ指標で運用フェーズを判定

5-8. 自動レポートを Slack へ（週次 Cron）

python report_monthly.py | slackcat --channel "#mm-report"

• 要件：1 日 1 回程度の小 Log 分析 → 週次で “勝ち筋・負け筋ランキング”
• 運用感覚：「Bot が “自分の負け方” を教えてくれる」

✅ 次章予告

ここまでで “攻め・守り・評価” の３レイヤーが揃いました。
最終セクションでは 開発サイクルを自動化するテンプレート と、
実戦投入 → 回収 → 強化 を回し続ける DevOps for Bot のセットアップ手順を示します。

6. DevOps for FR-MM Bot ― “開発⇄実戦⇄学習” を自動で回す

ここまでで 守り (生存性)・攻め (Entry/Exit)・評価 (ログ/メトリクス) が整いました。
最後は 「改善ループを回し続ける仕組み」＝Bot-DevOps を組み込んで、
コードを書けば翌日には実戦データが返ってくる サイクルを作ります。

6-1. 全体パイプライン図（概要）

flowchart TD
    git["Git push"] --> test["Unit-Test"]
    test --> build["Docker Build & Push"]
    build --> deploy["Deploy (GitHub Actions)"]
    deploy --> run["Live Bot + Watchdog"]
    run --> collect["Log & Metrics Collector"]
    collect --> eval["Nightly Evaluator Cron"]
    eval --> report["Auto-Report → Slack"]
    report --> param["Param Generator"]
    param -- "new params" --> git

• １日１周 を最低ライン。
• Hot-fix ブランチは –no-verify → Staging Net で最短 10 分反映も可。

6-2. GitHub Actions ― ３段階ジョブ

deploy-test:
  needs: build-image
  runs-on: ubuntu-latest
  steps:
    - name: SSH & Deploy
      uses: appleboy/ssh-action@v1
      with:
        host: ${{ secrets.VPS_HOST }}
        script: |
          cd ~/MMBot && git fetch && git checkout $GITHUB_SHA
          make test-clean
          ENV=testnet COMPOSE_IMAGE_TAG=$GITHUB_SHA make test-up

6-3. ランタイム側コンテナ構成

6-4. 評価ジョブ（夜間 Cron on VPS）

# cron.daily/evaluate.sh
python tools/eval_daily.py --db ~/runtime/testnet/pnl.db \
      --out ~/reports/$(date +%F).md

cat ~/reports/$(date +%F).md | slackcat -c "#mm-report"

eval_daily.py では 5-5 で作った KPI を出力し、
タグ別勝敗表・Drawdown 曲線・シャープレシオ 24h を Markdown で整形。

6-5. パラメータ自動サジェスト（BayesOpt）

# tools/param_opt.py
best = bayes_optimize(
    target='ev',
    params={
      'spread_th_bp': (2, 6),
      'pfill_th': (0.5, 0.8),
      'tp_ladder_1': (0.06, 0.12)
    },
    historical_df=trade_df_last7d,
    n_iter=30)
dump_yaml(best, "config/next_params.yml")

• 週１回で十分。
• ev ↑ +0.03% 以上なら Slack で「👍 Auto-Param」ボタンを通知 → クリックでマージ & 再デプロイ。

6-6. “ミスっても死なない” 自動ロールバック

1. watchdog が exit_panic > 3 / h を検知
2. docker compose down → git checkout last-good → make prod-up
3. Slack ⏪ Rolled-back to <sha> (panic storm)

MTTR（平均復旧時間）を 人手ゼロ & < 5 min で達成。

6-7. 運用 KPI と目標レンジ

6-8. やってみてわかった DevOps Tips

• テストネットにも FR がある時間帯 を狙う → 評価速度 2×
• DB マイグレーションは ALTER TABLE ... ADD COLUMN だけ に留める
• メトリクスは “ダメージ系” を先に作ると施策が高速回転する
• Grafana ダッシュの 「上下２×２レイアウト」 がスマホ閲覧にちょうどいい

✅ まとめ

1. CI/CD で “壊れない” を担保
2. Live Logs → Nightly Evaluation で “学習ループ” を自動化
3. BayesOpt & Slack Approval で “パラメータ調整” も半自動
4. 失敗時は watchdog × ロールバック で “死なずに反省”

こうして FR×MM Bot は「書く → 回す → 強くなる」サイクル に入ります。
あとは 資金量を増やす／戦略を増やす も同じパイプラインに流すだけ。

7. 一点突破 vs 両立型 ─ 戦略重心の決め方

「尖らせて押し切るか、万能を狙うか」──
ここでは Entry 極振り／Exit 極振り／両立型 を、
期待値・実装コスト・運用リスク の 3 軸で比較し、
“自分の開発フェーズでどこに軸足を置くべきか” を具体的に判断できる材料を並べます。

7-1. Entry 極振り Bot — “一撃で試合を決める” 狙撃型

7-2. Exit 極振り Bot — “受けて捌く” 柔術型

7-3. 両立型 — “攻守一体” を実現するフルスタック Bot

7-4. 両立を現実的に目指すコツ

1. モジュール分離
   • entry.py, exit.py, risk.py を 独立 DI（依存注入）に
   • 各モジュールは 状態クラス BotState でのみ情報共有
2. インターフェース契約
   • entry() は 「注文案」 を返すだけ
   • exit() が 「今出ていい？」 を真偽で返すだけ
3. 負荷管理
   • 予測モデルは async executor で並列化
   • Exit シミュレーションは リクエスト当たり 5 ms 以内 を SLA に
4. パラメータ衝突の可視化
   • spread_th を上げたら tp_hit_ratio がどう変わる？ を Prometheus Rule で自動プロット

8. まとめ ─ FRMMbot を“育てる”という発想

1. 守りを固める
   • MAX_LOSS_PCT と safe_exit()、watchdog で “死なない Bot” を先に作る
2. 攻めを磨く
   • スプレッド検知 + fill 確率モデルで エントリ EV を上げる
   • Exit FSM と Rebalance で 損切り最小・利確最大 を実現
3. 数字で裁く
   • 勝ち／負けタグ + KPI (EV, Sharpe, Turnover) で 効果測定を自動化
4. DevOps で回す
   • CI/CD → 夜間評価 → Auto-Param → Slack 承認 → 再デプロイ
   • 1 日 1 ループ で Bot が “学習” する仕組み

FRMMbot は “コードを書けば書くほど賢くなる” 生き物です。
防御ラインが厚いほど、攻撃のチューニングを恐れず回せる。
この記事のフレームとテンプレを 自分の戦略・アイデア に合わせて改造し、
「死なずに強くなるループ」 を加速させていきます。