開発記録#203(2025/4/29)MMBot 開発ログ 11 ── “テストネット最終チェックで fill を掴むまで”

前回の記事に引き続き、今回も仮想通貨botの開発状況をまとめていきます。

前回（#202）では Makefile + .env で「テスト⇆本番を 1 行切替え」する方法をまとめました。
今日の記事はその続き。 「実際に最小ロットで発注 → 約定を DB に保存」 できるところまでの全プロセスを、初心者の方にも追えるレベルで整理します。

0. やったこと・得たこと

1. 今日のタイムライン(こまめに休憩しながらコツコツと)

2. なぜ /execution/list に切り替えた？

ワンポイント

# execution/list 呼び出し例
r = await client.request(
    "GET", "/v5/execution/list",
    params={"category":"linear",
            "symbol": symbol,
            "orderId": order_id}
)
fills = (await r.json())["result"]["list"]

3. trades.db をその場で確認するコマンド

sqlite3 -header -column trades.db "
SELECT id        AS execId,
       symbol,
       side,
       price,
       qty,
       datetime(ts/1000,'unixepoch') AS filled_at
FROM trades
ORDER BY ts DESC
LIMIT 5;
"

出力例（個人 ID はマスキング）

execId                                 symbol   side  price     qty   filled_at
------------------------------------   -------  ----  --------  ----  -------------------
7760…962f51                            BTCUSDT  Buy   93681.3   0.029 2025-04-29 01:55:56
0e07…707b2                             BTCUSDT  Buy   93614.8   0.001 2025-04-29 01:55:56

4. ハマりポイント & 対処メモ

5. 明日への To-Do（本番ミニマム稼働準備）

1. 本番資金を入金（余裕資金のみにする）
2. .env.prod に BYBIT_KEY_MAIN / SECRET_MAIN をセット
3. Lot = 最小 0.001 BTC、timeout 15 s、フォールバック上限 3 に調整
4. make mainnet-loop 起動 → Slack で 1 fill を確認
5. trades.db をバックアップしつつ 24 h 放置テスト

6. まとめ ― 今日の学び 3 カ条

1. 「レスポンスは必ず json.dumps で人間の目で見る」
   — KeyError は 10 秒で潰せる。
2. テストネットでも板が薄いと Market が立たない
   — priceProtect の壁は Bid/Ask + α でクロスする or シンボルを変える。
3. 小さなコマンドは Makefile のターゲットに昇格させるとミスが 1/10
   — make testnet-fill など “よく打つもの” ほど自動化。

Yodaka

🛠️ 今回は「**fill が DB に落ちる**」ところまで到達！次はいよいよ **本番ミニマム稼働** に突入します。

（※ 本記事に記載の API キー・Webhook URL はダミーまたは伏せ字です。実際の秘密情報は .envファイルで安全に管理してください。）

おまけ：なぜ「テストネットで fill を掴む」ことにこだわるのか？

fill = 約定（やくじょう）
取引所が「あなたの注文を確かにマッチさせ、ポジションが建った」ことを示す唯一の証拠データ。

こだわった理由＝「ゼロ→イチの安心感」

• 未約定でも API は retCode=0 を返す
  → “注文 OK ＝約定 OK” ではない。
• fill を 1 行 DB に書き込む ＝
  Bot・取引所・DB・通知 … 全レイヤーがつながった証拠。
• ここさえ通れば ロットを 10 倍にしても、戦略ロジックを差し替えても
  “通信経路” は基本そのまま使い回せる。

つまり
「fill を掴む」 = “紙パックにストローを刺して最初の一口を飲む” 行為
ジュース（= 相場データ）は確かにパイプを流れて自分のアプリに入ってくる。
だから次は安心して大きなストロー（本番ロット）に替えられるわけです。

これからテストネットを触る初心者さんへ

1. Market 最小ロット → Limit‐IOC クロス の順で必ず試す
   • 板が薄くても最短で約定しやすい
2. 取れた fill を DB or CSV に “実物” として保存
3. 人間の目で SELECT して確認
   （GUI ではなく sqlite3 や cat csv 推奨――構造が分かる）
4. 成功通知のメッセージ を Slack / Discord で受け取る
   → 失敗 と 成功 の両方のパターンをログ化しておく

この 4 ステップをクリアすれば、もう 「動く Bot の血液循環」 が完成です。
あとは心臓（戦略アルゴ）を入れ替えたり、筋肉（ロット）を鍛えたりするだけ。

だから私は、多少ハマってでも “fill 1 行” にこだわりました。

よくある反論 & それでも「fill 取得」を推す理由

結論

• テストネットで fill を確認するのは “勝てる／負ける” の前段階。
• 取引所との I/O が正しい ことを物理的に証明する 最小不可欠ステップ。
• 数百円・数十分で終わる保険と思えば、無視する理由はほぼ無い。

ファクトチェックwithGPTo3

以下、記事中で挙げた “主な事実” について公開ドキュメント・公式 FAQ で確認できる一次情報を示します。 リンク先＝ソース ID を文末に付けてあるので、必要に応じて開いてみてください。（URL は出さず、クリックで飛べる仕様です）

検証方法メモ

• ①②⑤︰Bybit v5 Official REST API reference
• ③︰Bybit Discord #testnet チャンネル固定メッセージ
• ④︰Fee Schedule ページ下部 “Testnet” セクション
• ⑥︰Unix /proc ドキュメント