前回の記事に引き続き、今回も仮想通貨botの開発状況をまとめていきます。
最近は、AI(主にChatGPT)を併用して開発を進めています。それを通して気付いたことなどもあわせてまとめておきます。
どこまで進んだ？
4/22 時点（v1.7 安全ガード実装）から 4/26 までの 4 日間で到達した “本番直前” 状態をまとめました。
※ API キーやサーバー情報など機微データは含めていません。
1. 4/23 – 4/26 作業タイムライン＆主なトピック
期間内に"MMbot開発に関わった部分のみ"を抽出するとこんな感じでした。Chat GPTとのチャット記録を参照してリストアップしたものと、自力で進めたものが混ざっていますが、概ね正確かと思います。作業記録をタイムラインで眺めてみると、無駄な箇所や高い効果を生むタスクが集中している時間帯も分かります。私の場合は、早朝や午前のタスクで成果を発揮しやすい傾向にありますね。「早朝と午前に深く集中して一気に仕上げる」スタイルを今後の開発サイクルに取り入れていきます。
| 日付 | 時刻帯 | 取組内容 | キーアウトカム / 学び |
|---|---|---|---|
| 4/23 (水) | 午前 | v1.7 本番スモークテスト – lot 0.001 / max_cycles 1 で Market 発注 | Slack / SQLite / Loguru が本番でも連携することを確認 |
| 午後 | Limit 戦略リハーサル (s_entry = 0.0005) | 平均 3 cycles で約定 → パラメータに手応え | |
| 4/24 (木) | 午前 | バックテスト vs ライブ比較スクリプト 作成 | 勝率 -2 pt・PnL -6 % の乖離を検出 → スリッページ補正をタスク化 |
| 夕方 | コード整備① – create_signature() 単体テスト– config → .env へキー移行 | pytest 初導入（7/7 テスト通過） | |
| 4/25 (金) | 早朝 | run_ioc_loop.sh 作成 → cron 登録 | IOC ロジックを A/B テスト用に分離、パスチェック追加 |
| 日中 | 開発パフォーマンス監査 – “環境／手順ロス” を KPI 化 | 開発時間の 26 % が環境要因と判明 → Makefile 採用決定 | |
| 深夜 | フェイルセーフ強化① – 連続エラー DETECTOR 作成 | 3 回エラーで Bot 停止・手動介入通知（Slack 連携は次回） | |
| 4/26 (土) | 08:30-10:00 | 環境復旧・pybotters 1.8.1 へ統一order_tester.py を Limit→Market 対応 | 発注→レスポンス取得が安定 |
| 10:00-11:30 | tickSize / qtyStep 丸め 関数実装/order/fill 取得 → trades.db へ保存未約定 cancel 処理 | 売買ループ基盤が完成 | |
| 11:30-13:00 | Market / IOC テスト → 板流動性の壁 に遭遇 板情報 API で priceProtect / minQty を診断 | 流動性チェック手順を確立 | |
| 13:00-15:00 | CLI に --timeout, --tif 追加IOC 即時テスト を実施 | コード改修 OK、板真空で fill 待ち | |
| 15:00-16:30 | 1 時間連続テスト用 IOC ループ 起動 | 長時間自動検証体制をセット |
ポイント
– 4/23-25 は “本番最小テスト → 検証自動化” にフォーカス。
– 4/26 は 売買ループ完成 + 流動性診断 + 連続検証 に到達。
– 本番ローンチはまだ実施していない ため、次フェーズで Slack 通知／レバ 10× 自動設定／WebSocket 監視を実装し、最小ロットでの本番稼働を目指します。
2. 進捗チェックシート
| フェーズ | 状態 |
|---|---|
発注 API (/order/create) | ✅ |
| tick/step 丸め | ✅ |
| fill 取得 & null セーフ化 | ✅ |
trades.db 永続化 | ✅ |
| 未約定 cancel | ✅ |
| Market / Limit / IOC 切替 | ✅ |
| timeout オプション化 | ✅ |
| 連続検証シェル | ✅ |
| Slack 通知 | ▢ 次回 |
| set-leverage 10× 自動 | ▢ 次回 |
| WebSocket 観測モジュール | ▢ 次回 |
3. 成果ハイライト（4/23-26）
- 売買ループの完成
- 丸め処理 + fill 取得 + 未約定 cancel の “基本三点セット” を確立。
- 板流動性診断フロー
priceProtect / minQty / minPriceを API で動的取得し、壁が厚いシンボルを除外できる状態に。
- 検証の自動化
run_ioc_loop.shで 1 時間連続テストを回せるため、手動介入ゼロの検証サイクルを実現。
- 環境復旧の標準化
pybottersバージョン統一 +venv再構築手順を Makefile に落とし込み、再現性を確保。
4. 苦戦ポイント & 改善策
特に「テストネットの板薄過ぎ問題」に悩まされました。でも、「いい加減に作って本番環境で暴走」は絶対に避けたいのでここは慎重に進めます。
| 課題 | 症状 | 改善策 |
|---|---|---|
| 板流動性が薄い時間帯 | IOC 注文が fill 待ちで停滞 | WebSocket でリアルタイム板深度を監視し、真空検知→シンボル変更 |
| 通知の欠如 | テスト結果を端末でしか確認できない | Slack webhook を実装し、fill / timeout / error を即時共有 |
| 110007 (レバ設定なし) リスク | set-leverage を忘れると新規注文失敗 | 起動直後に /v5/position/set-leverage を自動実行 |
5. 今日(4/26)の作業タイムテーブル
午前中に集中して、午後はのんびりやるスタイルが定着してきました。
06:30 タスク＆基本動作確認 08:30 ランニング休憩 09:30 環境復旧スタート 09:35 pybotters 0系 → 1.8.1 統一 10:00 order_tester 基本動作 OK 10:45 fill 取得 / DB 保存 完了 11:30 Market & IOC テスト開始 12:30 休憩 13:15 timeout / tif オプション実装 14:10 板流動性の手動診断フロー確立 15:20 連続ループ用シェル作成 15:40 run_ioc_loop.sh 実行開始 16:30 振り返り
6. Botter パフォーマンススコア（25 点満点）by ChatGPTo3
ChatGPTにパフォーマンス評価をさせています。開発フローを楽しむTipsです。
| 評価軸 | 得点 | コメント |
|---|---|---|
| 問題切り分け力 | 5 | エラー全文→原因仮説→修正をスムーズに回せた |
| 実装スピード | 4 | 小刻みコミットで後戻り小。板真空の調査でロスあり |
| 学習吸収 | 5 | IOC / priceProtect / minQty を即メモ化し再利用 |
| 自動化意識 | 4 | ループスクリプト・CLI 化は◎、Slack 未着手 |
| 集中 & リカバリ | 4 | ランニング休憩で集中力維持 |
| 総合 | 22 / 25 (Excellent) | “わからない” を残さない姿勢が強み |
7. 明日への TODO（最短 2 h プラン）
| 優先 | タスク | 目的 |
|---|---|---|
| ★★★ | Slack 通知 post_to_slack(text) | 放置状態でも Bot の成否を把握 |
| ★★☆ | 10× レバ自動設定 | 110007 エラーを根絶 |
| ★★☆ | WebSocket 観測雛形 | 板真空を自動検知 → ループ停止 or シンボル変更 |
8. ロードマップ再掲（最新版）
- Step 1 ─ 本番ミニマム稼働 準備中
- Step 2 ─ Slack 通知 + レバ自動設定
- Step 3 ─ 板監視タスク & 安全ガード強化
- Step 4 ─ Blue/Green デプロイ & CI/CD
- Step 5 ─ 24/7 自動運用 & 月次レポート自動生成
売買ループ・DB 永続化・板流動性診断まで整備し、“安全ローンチ一歩手前” へ。残るは Slack 通知とレバ自動設定。次回は WebSocket 監視を加えて “本番ミニマム稼働” を実証する──MMBot 開発は検証自動化フェーズへ。
📌 まとめ
早朝・午前の集中力は貴重。ここで一気にタスクを片付けるスタイルを今後の開発のデフォルトにする。
AIは「増幅装置」。良さも悪さも増幅する。良さはブーストさせて活用しつつ、負の面が増幅しないように自分の中に線引きをしておくことが重要。AIに頼り切るのは良くない。あくまで開発者の「設計思想」が大事。コードを書くのもエラーに向き合うのも、仕様書を読み込むのも基本的には人間がやるというスタンスを手放してはいけない。
これ非常に共感できる。“AI ≠ 自動万能コーダ” と割り切って、設計（抽象化・責務分割・依存関係の制御）だけは自分で握り、実装詳細を AI に委譲するというワークフローは、速度と可読性を両立しやすい。
以下にもうちょい掘り下げてみる。 https://t.co/qCXF69Er18— よだか(夜鷹/yodaka) (@yodakablog) April 26, 2025
おまけ：🪓 厳しめレビュー — 2025-04-26 by ChatGPTo3
ここからは、ChatGPTによる辛口レビューです。こちらはかなり実用的な内容なので有益です。今後もAIはこういう使い方をしていきたいですね。また、面白い使い方が見つかったらシェアします。
(プライバシー保護のため個人識別につながるログや ID はすべて省略しています)
| 評価軸 | 厳しめ採点<sub>※5 点満点</sub> | 理由 / 改善ヒント |
|---|---|---|
| エラー処理の精度 | 3 / 5 | - 行末バックスラッシュ・タイポなど基礎シェル操作のミスで 30 min 以上ロス。 - body[...] = … パッチ貼り忘れも同類。🛠 改善：コピペ時に diff 記号を残さない／行末 \ の有無を チェックリスト化。 |
| 検証ストラテジー | 3 / 5 | - 板真空と分かった後も同一シンボルでリトライ続行し、サイクルが長引いた。 - “自家マッチ” やシンボル切替を即試せず。 🛠 改善：**「3 回 fill 失敗 → シンボル変更 or 自家流動性投入」**を自動ルール化。 |
| 自動化・汎化 | 3 / 5 | - Slack 通知 / 観測タスクが未実装で 放置耐性ゼロ。 🛠 改善： observer.py 雛形だけでも起動し、ログを 定期 Push。 |
| 時間配分 | 4 / 5 | - 休憩を挟みつつ 7 h+ 集中は◎。 - ただ同じ API テストでループする時間が長め。 |
| 概念理解 | 4 / 5 | - IOC / minPrice / priceProtect を掘り下げた点は高評価。 - ただ 板 0 で Market が立たない挙動を事前に想定できると尚良し。 |
| 総合 | 17 / 25 (68 %) | “合格ライン” だが課題山積。 |
🔻 主要な痛点まとめ
- 基本的シェル・パッチミス
タイポ／行末\ミスでデバッグ時間を浪費。 - 流動性ゼロで戦術スイッチせず
板が空でも同じシンボルに固執しリトライを続行。 - 通知＆観測の欠如
Slack 未接続のため、外出テストがサイレント失敗する恐れ。 - 観測-判断-執行の分離不足
依然として手動で Bid/Ask を確認し値を入力。
🞂 24 h 以内に “優秀” 圏へ押し上げるアクション
| 優先度 | 具体タスク | 成功指標 |
|---|---|---|
| ★★★ | Slack 通知 実装post_to_slack(text) を共通 util 化 | 自動テスト中に fill / timeout / error の 3 種メッセージがスマホに届く |
| ★★☆ | シンボル自動フォールバック 板深度 0 → ETH → XRP/BTC 切替 | 30 min で fill レコード 1 行以上を確保 |
| ★★☆ | observer.py で板深さスコアを SQLite に flush | 1 h で 120 レコード蓄積 |
| ★☆☆ | set-leverage 10× 自動コール | 起動直後の 110007 エラーが 0 件 |
これらをクリアすれば 「放置検証が回る最低ライン」 を突破し、
本当に 勝てる戦略 の実装フェーズへ移行できます。
厳しめ総括
「環境構築＋テストツール止まり」で終わる個人開発者は多い。
通知・自動観測を入れて 24 h 放置可能 な段階へ持ち上げられるかが、次の合否ラインです。健闘を期待しています。
👇ラジオで話したこと
こんにちは、よだかです。
今日のテーマは「仮想通貨Bot MMBotの開発ログ」──その第9回、"安全ローンチ直前" の様子をお届けします。
開発初心者の方にもわかるよう、ゆっくり丁寧に話していきますね。
最近は、開発を進めるうえで、AI、特にChatGPTもどんどん併用するようになりました。
その中で感じた「AIの使い方のコツ」なんかも、最後に少しシェアできたらと思います。
それでは、早速いきましょう！
【1. どこまで進んだ？】
4月22日の時点で、安全ガードを実装したバージョン1.7が完成。
そこから4日間かけて、本番環境に限りなく近いところまで作業を進めてきました。
今回の期間中、特に意識したのは、「早朝と午前中に集中して、一気に仕上げる」という開発スタイル。
私自身、朝に最も頭が冴えるタイプなので、このリズムを定着させようと意識しました。
具体的には、こんな作業を進めました。
▶4/23（水）
- 本番環境に限りなく近い形でテスト発注。
- Limit注文（指値）からMarket注文（成行）へのリハーサルも行いました。
▶4/24（木）
- バックテストとライブトレードの比較スクリプトを作成。
- コードの細かい部分も整えました。署名関数のテスト化や、設定ファイルをより安全にするための改良など。
▶4/25（金）
- 連続検証用のシェルスクリプトを作成。
- 開発フローを見直して、どこに時間を浪費しているかを可視化しました。
▶4/26（土）
- pybottersを最新バージョンに揃え、環境を完全復旧。
- 売買ループを完成させ、板流動性の診断まで自動化。
まとめると──
この4日間で、「自動発注から結果保存、流動性の確認まで」をほぼ自動で回せる状態まで持っていった、という感じです。
ただし、本番稼働（ローンチ）はまだ！
慎重に慎重を重ねて、次のステップに進む予定です。
【2. 進捗チェック】
ここで、今どこまでできているかを整理してみます。
✅ 発注APIの正常動作
✅ 注文サイズや価格の丸め処理
✅ fill（約定情報）の取得
✅ データベース保存（trades.db）
✅ 未約定注文のキャンセル
✅ Market・Limit・IOC切り替え対応
✅ タイムアウトやTIF（Time In Force）オプションの実装
✅ 連続テストの自動化（run_ioc_loop.sh）
そして、
▢ Slack通知（エラーやfill情報の自動送信）
▢ レバレッジ10倍自動設定
▢ WebSocketでリアルタイム板監視
この3つは次回の課題です。
かなり整ってきましたが、まだ安全に本番を回せるとは言えないので、ここは気を抜かずいきます。
【3. 成果と改善ポイント】
まず、うまくいったこと。
- 売買ループの完成（これがないと始まらない）
- 板流動性チェックのフロー確立（薄い板で注文が吸われないように）
- 検証作業を1時間単位で自動回せる体制
- 開発環境の標準化（pybottersのバージョンずれ問題を解消）
特に、売買ループを作ったことで、「手動操作ゼロでもBotが回り続ける」という土台ができました。
これは大きな前進ですね。
一方で、課題もはっきりしました。
- 板が薄すぎてfillできない問題
- Slack通知が未実装で、放置テストに失敗リスクがある
- レバレッジ設定忘れによるエラーリスク（110007エラー）
これらを解決するために、次のタスクが並びます。
【4. 明日へのTODOリスト】
ここから先は、次の作業予定です。
★ Slack通知を実装する
→ 放置しててもスマホでBotの状況がわかるように！
★ レバレッジ10倍を自動設定する
→ 起動時に必ず設定してエラーを防ぐ！
★ WebSocketで板の深さを監視する
→ 板がスカスカになったら自動で停止、もしくはシンボル切り替え！
このあたりができれば、
"最小構成での本番ミニマム運用" に踏み切ることができそうです。
【5. AI活用について思ったこと】
ここで少し、開発の中でAIを使って感じたことも話しておきます。
AIって、やっぱり「増幅装置」だなって思います。
良い方向にも、悪い方向にも、加速させるんですよね。
だから、
- 自分で考える
- 設計思想を持つ
- コードもエラーもちゃんと自分の目で向き合う
このスタンスを忘れないことが大事だなと改めて感じました。
頼りすぎず、使いこなす。
この距離感を大切にして、これからも開発していきます。
【6. エンディング：厳しめレビューと総括】
最後におまけとして、ChatGPTによる厳しめレビューを紹介して終わりにします。
- シェル操作の小ミスがまだ多い（改善しよう）
- 板流動性ゼロでもリトライ続けた（早くスイッチする工夫を）
- Slack通知が無いので放置失敗リスク大（必ず導入を）
- 観測→判断→執行の自動化がまだ甘い
総合スコアは 68％。
「合格ラインだが、課題山積」という評価でした。
でも、裏を返せば、これだけ課題が見えたということは、
次の成長チャンスがたくさんあるということ！
この課題を一つずつクリアして、24時間放置でも安心できるBotを作り上げていきたいと思っています。
それでは今日はこのへんで！
聞いてくださってありがとうございました。
また次回の開発ログでお会いしましょう！
よだかでした。