Bot 開発ログ

🛠️開発記録#244(2025/6/5)開発サイクルを回して得た“攻めと守り”の学び

1. はじめに ── テストネット調整から本番スモールテストへ

今回の開発フェーズでは、テストネット上で整えてきた運用基盤とロジックの安全性を一通り確認し、
その上で ミニマムサイズの本番稼働テスト（Mainnet Small Test） に踏み出す準備を進めた。

具体的には、以下のようなステップを意識して構築・検証を進めていった：

  • Makefile ベースでの 環境ごとの起動／停止の切り替え
  • .env.testnet / .env.production による 環境分離と本番APIキーの安全管理
  • テンプレート→JSON生成まで含めた entrypointの一貫処理
  • MMBOT_MODE の自動切り替えと Slack 通知のルート整備
  • テストネットで確認された全ループ処理（skip判定、safe_exit、ログ記録）の安定性の確認
  • そのうえで本番モードへの切り替え → LOT / LOSS を極小にして試験的運用

いきなり攻めに転じるのではなく、**“守りを固めてから一歩踏み出す”**という意図的なフェーズ切り替えだった。

この開発を通して改めて実感したのは、テストネット上で整えた「止まる仕組み」がそのまま実弾運用の安心感につながるということだった。
Bot開発においては、「どう勝つか」以前に 「どう負けずに済ませるか」 を徹底的に設計しておくことが
継続的な改善とトレードの自律性を支える。

次のセクションでは、この本番移行のために整えた インフラ周りの構成（Makefile・env・起動コマンド） についてまとめていく。

2. インフラ整備：Makefile × 多環境 env 切り替えの完成

本番テストへの移行に向けて、まず最初に取り掛かったのが起動・停止・切り替えの操作性を整えることだった。
現場でBotを扱う以上、「どの環境が、どの設定で、どう動いているのか？」を即座に切り替えられる状態は必須条件である。

Makefile 化の目的：操作を “1コマンド” で完結させる

それまでの運用では、docker compose コマンドに毎回 --env-file を指定し、DATA_DIR も export で手動指定する必要があった。
本番・テストネットを切り替えるたびに、環境変数や起動オプションの管理が煩雑になっていく。

これを解決するために、以下のような Makefileベースの簡略ターゲット群 を整備した：

# テストネット
make test-up        # 起動
make test-stop      # 停止
make test-clean     # コンテナとボリュームを削除

# 本番ネット
make prod-up        # 起動（MMBOT_MODE=mainnet または production）
make prod-stop
make prod-clean

# 共通
make logs           # ログのリアルタイム追跡

この構成により、「テストで動かしていたBotを本番に切り替える」という一連の作業は コマンド1つで即座に切り替え可能になった。

env_file の動的切り替えとBOT_ENV_FILEの導入

Composeファイル側も env_file: を静的指定から変数指定へ変更し、

env_file:
  - ${BOT_ENV_FILE:-../env/.env.testnet}

と記述することで、Makefile 側で BOT_ENV_FILE=../env/.env.production を渡せば
本番用の .env.production が読み込まれるようになっている。

この切り替えによって、本番とテストネットで完全に分離された API キー・パラメータ・Slack Webhook を用意しつつ、
コードや構成ファイルを一切書き換えずに環境を切り替えられる柔軟な構造が実現した。

成果：1日単位で testnet ⇄ mainnet を往復できる運用基盤

この仕組みによって、「昼間はtestnetでのロジック改善」「夕方に小ロットでmainnet確認」といった
日単位での環境切り替え→検証→修正のループがストレスなく回るようになった。

操作性が軽いことは、開発における“移行のハードル”を下げ、
そのぶん思考や実験にリソースを割けるようになる――今回その実感を強く得た。

次のセクションでは、このインフラの上に組み込んだ“守りの機構”＝safe_exit / watchdog / Slack 通知について紹介する。

3. 守りの要：safe_exit／watchdog／Slack 通知を鉄壁に

Botが“勝つ”ためには、まず“死なない”ことが前提である。
このセクションでは、Botがどんな状況でも 「安全に止まる」「止まったことを知れる」「その後に原因を分析できる」
という「守りの機構」についてまとめる。

safe_exit：シグナルを受けてポジションをクローズする

まず第一に整備したのが、**SIGINT / SIGTERM を受け取ったときの安全停止処理（safe_exit）**だ。
これは Docker 側の docker stop などから送られる終了シグナルが、
entrypoint 経由で Python 側の mmbot.cli に伝わり、注文キャンセル → ポジション決済 → Slack 通知 → 正常終了
という一連の流れを実行する仕組みである。

docker compose exec mmbot kill -SIGINT 1

この 1 行で safe_exit が呼ばれ、Bybit 側の UI でもポジションがゼロになり、Slack に通知が飛ぶことを確認した。

watchdog.sh：外部からの見張り役を追加

次に用意したのが watchdog.sh。これは

  • ログが一定時間更新されていない（例：10分）
  • Slack 通知が来ていない
  • DBファイルがローテーションしていない

といった**Botの“無言の異常”**を検知し、Slackに通知を送るシェルスクリプトである。

さらに、今回の実弾運用を想定して Slackが落ちている場合でもBotを止める最終ガード を組み込んだ：

if ! curl -fsSL --max-time 3 "$SLACK_WEBHOOK_URL" -d '{"text":"ping"}'; then
   docker compose -f compose/compose.yml stop mmbot
fi

これにより「Slackも落ちていてBotも止まらない」という最悪ケースを予防できる。

Slack通知：すべての判定と状態変化をリアルタイムで受け取る

  • 📌 NEW SESSION: mode=production
  • cycle n: pnl=+0.0043
  • :white_check_mark: 全ポジションを決済しました。安全停止します。

といったメッセージが 即座にSlackに届くことで、“今このBotは何をしているか”が常に把握できる。
通知の設計が整っていれば、Botの挙動を“画面を見なくてもわかる”状態にできる。

守りが整ったことで得られた安心感

この守りの構成によって、

  • 異常が起きたときの影響が最小限に留まる
  • 停止後にも状況がログとSlackに記録される
  • 後から分析と改善が可能なデータが必ず残る

という状態が実現できた。
この「壊れないことを前提にしない設計」は、実弾運用フェーズへ進むための重要な基盤となった。

次のセクションでは、この「守り」を裏で支えている ログとDBの構造、およびそれをどう分析可能な形に残すかについて紹介していく。

4. ログ＆DB 出力設計 ── 分析可能なデータの残しかた

Botを動かしているだけでは、勝ち負けの理由は分からない。
勝っても“なぜ勝てたか”、負けても“なぜ負けたか”が分析できなければ改善はできない。
そのため、ログとDBの設計には「あとから見返して定量評価ができる」という視点が重要になる。

ログの構造：人間が読めるテキストとSlack通知

ログは DATA_DIR/logs/MMBot.log に loguru 経由で出力される。
その内容は主に以下の3つに分かれる：

  • ループごとのイベントログ（スプレッド条件、skip判断、注文結果）
  • PnLログ（Cycleごとの収益、トータル収益）
  • エラー／警告ログ（通信エラー、ポジション未決済など）

ログは以下のように1ファイルで追跡できるため、
tail -F logs/MMBot.log で常時監視もできるし、あとから grep "cycle" でPnLだけ抽出することもできる。

12:30:00 | INFO | cycle 45 pnl=+0.0024 total=+0.1123
12:30:06 | INFO | skip – spread too narrow (0.00012, ticks=1.0)

Slackにも同様の情報が送られており、人間が目視で瞬時に判断できるリアルタイム通知が併用されている。

DBの構造：機械が解析するための日次記録

トレード記録は DATA_DIR/db/mmtrades_<mode>_<YYYYMMDD>.db という形式で
SQLiteファイルとして出力される。
このDBには、以下のような情報が記録されている：

  • 注文ID、サイド（Buy/Sell）
  • 実行価格とサイズ
  • タイムスタンプ（ミリ秒）
  • 成行かキャンセルかの判定
  • サイクル単位のPnL集計結果

この形式で保存しておくことで、時間帯ごとの成績傾向や
発注間隔と勝率の相関など、さまざまな角度から分析ができる。

分析スクリプトの接続

これらのログとDBは、後工程の analyze_pnl_vs_log.py によって読み込まれ、
以下のようなアウトプットを自動生成できるようになっている：

  • スプレッドとPnLの相関グラフ
  • サイクルごとの累積PnL推移
  • 時間帯別の勝率・ロス率
  • PnL急変ポイントの検出（しきい値設定可）

このスクリプトは既にテストネットでも正常に動作しており、
本番データを投入すれば即座にロジック改善のための定量的な示唆を得られる設計になっている。

すべては「あとから判断できる状態を残す」ために

Botの設計は、「動くこと」と「止まること」に加えて、
「あとで読み解けること」まで含めて完成だと私は考えている。

どれだけ優れたロジックでも、
「この判断が正しかったのか？」を検証できない限り、次の改善にはつながらない。

だからこそ、ログとDBの出力設計は単なる補助ではなく、開発の本質そのものなのだ。

次のセクションでは、この出力設計を支えた上での本番ミニロット稼働の結果と、そこから見えた現実について記録していく。

5. 本番ミニロット稼働レポート：skip ログから見えた“板の現実”

テストネットでの整備が一通り完了した後、いよいよ本番環境（mainnet）でのミニマムサイズ稼働に踏み切った。
LOT・MAX_NOTIONAL・LOSS はすべてテストネットよりも保守的な設定に抑え、
“勝ちにいく”というよりは**「安全に動作するか」「現場データが取得できるか」を目的とした実戦投入**だった。

結果：コンテナは稼働、だが注文は出ず

ログを追跡すると、Botはきちんとループ処理に入っていた。
📌 NEW SESSION: mode=production がSlackに通知され、毎サイクルのログも記録されていた。

だが、一定時間が経っても 注文（Buy/Sell）が一度も発生しなかった。
ログには以下のような出力が延々と繰り返されていた：

01:49:00 | INFO | skip – spread too narrow (0.00000, ticks=1.0)
01:49:06 | INFO | skip – spread too narrow (0.00000, ticks=1.0)

「スプレッドが開いていない」という現実

このログが意味するのはシンプルで、Bybit本番市場ではスプレッドが常に非常に狭いということだ。
特に BTCUSDT のような板が厚く流動性が高いペアでは、スプレッドは常に1tick（0.1 USDT）未満に抑えられている。
テストネットではスプレッドが2–3tick開いていたため条件を満たしていたが、
本番では**理論上はエントリ可能でも、実質的には“発注条件を満たせていない”**状況が続いていた。

ロジックは正常、だが“想定スプレッド”がズレていた

この出来事から学んだのは、ロジックそのものが間違っていたわけではない。
むしろ、「本番市場の板の挙動を正しく把握できていなかった」ことが原因だった。

エントリ条件（S_ENTRY）や spread_tolerance を市場の現実に即してチューニングしない限り、
“勝てるロジック”が“発動しないロジック”になってしまう。

得られた教訓

  • テストネットと本番市場では板の挙動がまるで違う
  • スプレッド1tickが常態である市場では、静的な閾値だけでは不十分
  • “動いているようで動いていない”Botは、一見安定して見えるが学習も収益も生まない

本番ミニテストは、たとえエントリが発生しなかったとしても、
「Botが安全に動くこと」「Slackやログ出力が正常なこと」「今後のロジックチューニングの方向性が見えたこと」の3点において十分な価値があった。

次のセクションでは、今回の実弾稼働から明らかになった課題に対して、
**どう守りを強化し、次に攻めるべきかのロジック戦略設計（3層構造）**についてまとめていく。

6. リスクマネジメント三層構造 ── Exit 粒度・動的 DD・流動性フィルタ

Bot開発において「勝てるロジックを詰める」というのは、
“勝ち筋”を見つけることではなく、“負け方”を制御することから始まる。
その前提のもと、今回の開発ではリスクマネジメントを3層構造で整理し、段階的に実装していく方針を取った。

第一層：Exit粒度の最適化（速やかに逃げる）

最初に着手すべきは、**「Exit条件を粗くしすぎない」**という視点だった。
単なる timeout や max_cycles だけに依存していると、

  • 板が薄くなってきているのにポジションを持ち続ける
  • スプレッドが潰れているのに注文を残す
  • 相場急変で片方が刺さらず損失が膨らむ

といったリスクを抱えやすい。

そこで考えたのは、OrderBook（OB）の変化をトリガーに即座に exit する仕組みだった。

if ob_imbalance > threshold or spread_pct < dynamic_min:
    await safe_exit(...)

つまり、**「相場が変わったと感じたらすぐ逃げる」**という粒度の細かいExit条件を整備することで、
“負け方のスピード”をコントロールできるようになる。

第二層：動的 DD（ドローダウン）ガード（負け幅を適切にスケールさせる）

次に考えたのは、**“最大損失（LOSS）を固定値にすることの危うさ”**だった。

  • ボラティリティが大きい相場ではすぐ損切りが発動してしまう
  • 逆にボラが低い相場ではLOSSが発動せず、ダラダラと不利な建玉を抱える

これを解決するため、過去N分のボラティリティや実現PnLから“許容DD”を自動でスケールさせる考え方に移行する。

dynamic_loss = base_loss * np.sqrt(recent_volatility)
if drawdown < -dynamic_loss:
    await safe_exit(...)

この実装によって、相場の“荒れ具合”に応じて柔軟にガードを働かせることができるようになる。
実弾テストフェーズでは、ロスを固定せずに動的調整することで “必要なリスクは取るが致命傷は防ぐ” というスタンスが取れる。

第三層：流動性フィルタ（そもそも危ない板に触らない）

最後に補完するのが、**“ポジションを持つ前段階のフィルタ”**である。

例えば、以下のような状況では本来エントリしない方が良い。

  • 板の厚さ（100k USD未満）
  • 出来高が極端に少ない時間帯（深夜〜早朝）
  • FR（Funding Rate）転換タイミング直後
if orderbook_depth < min_depth or time_in_maintenance_window():
    skip = True

これにより、「**“勝てる状況じゃないときに勝負を避ける”」**という判断がロジックに組み込まれ、
そもそも戦わなくて良い局面でBotを動かさないという守りの最終層ができあがる。

三層構造の強み：「止め方がわかると、攻め方が明確になる」

  • 粒度細かく逃げる（Exit）
  • 相場に合わせて負け幅を変える（DD）
  • 危ない場にそもそも出ない（流動性フィルタ）

この三層が揃って初めて、攻めのロジックを試せる「土俵」が整ったといえる。

この後はいよいよ、FR構造の活用やエントリロジックの動的最適化といった“攻め”の開発にフェーズを移していく。
次のセクションでは、その具体的な設計意図と狙いを整理していく。

7. 設計思想レベルで AI と対話するメリット＆限界

今回の開発において、私は ChatGPT を**単なるコード生成ツールとしてではなく、“設計レベルの壁打ち相手”**として使った。
具体的には以下のような内容を、日々の開発中に対話形式で洗練していった：

  • 構成ファイル（Makefile / compose.yml）の役割分離と切り替え設計
  • Botの「止まり方」の仕様定義（safe_exitの粒度、Slack通知の要件）
  • ログ／DBの出力構造と、その後の分析のための可視性
  • テストネットと本番の環境差分をどう安全に吸収するか
  • 「勝てるロジック」には何が足りていて、何がまだ不十分かという俯瞰

こうしたやり取りの中で、単なる正解をもらうのではなく、問いの精度そのものが上がっていく感覚があった。

AIを“設計レベル”で使うメリット

1. 俯瞰構造の可視化

自分の頭の中では漠然としていた「Botの全体像」を、
「構造で分けると何層になりますか？」
「このログはどこから生まれて、どこに使われますか？」
という問いにAIと答え続けることで、自然と整理されていった。

2. 抽象と具体を行き来できる

「Slack通知が来なかったとき、何が怖い？」というような抽象度の高い話から、
「それならcurlで死活確認して止めればいいですね」という具体的実装に落とし込む流れを、
1つの会話の中で往復できるのはAIの強みだった。

3. 記録としての機能

「考えたこと」「迷ったこと」「判断した理由」がそのままチャット履歴に残るため、
後から振り返って「なぜ今この設計になっているのか？」を思い出しやすい。

ただし万能ではない。限界もある。

1. 安全バイアスが強い

AIは基本的にリスクを嫌うように設計されている。
「もっと攻めたエントリ戦略を…」と相談しても、
まずは「DDガードを強化しましょう」と返ってくる。

→ 逆に言えば、“守りの見落とし”を拾うのには向いている。
→ 攻める判断はあくまで自分で責任を持って行う必要がある。

2. 完全なロジックは出てこない

ChatGPTは「コードを生成」することはできても、
自分のBot環境に完全適合した“即動くコード”を出してくれるわけではない。
だからこそ、「この提案の意図は何か？」を読み取って
自分の環境に合わせて翻訳する力が問われる。

3. 現場の肌感は提供してくれない

「板が薄い時間帯はどこ？」「スプレッドが1tick以内なのはなぜ？」といった、
“現場でしか分からない空気感”はAIからは出てこない。

→ これは実際にUIを開き、ログを追い、自分で観察し続けるしかない。

最適な使い方は「判断のための対話」

AIを設計レベルで使うときに最も効果的だったのは、
**「何を優先し、何を後回しにするか」**という判断軸を整理したいときだった。

  • 守りを強化するなら何から着手するか？
  • 実弾運用前に何を最低限整えておくべきか？
  • FR構造とスプレッド最適化、どちらを先に試すべきか？

そうした「迷い」に対して、“根拠を持った方向性”を提示してくれるパートナーとして、
ChatGPTは非常に相性の良いツールだった。

次のセクションでは、そうした“設計×対話”を通じて見えてきた、
「飽き」や「惰性」をトリガーにした自己リスクオンのタイミング設計について整理していく。

8. “飽き”をトリガーにルールを破る：自己リスクオンの仕組み化

Bot開発は、**「動くようにする」→「止まらないようにする」→「勝てるようにする」**という3段階を踏んで進化していく。
だが、皮肉なことにこの進化が進めば進むほど、「惰性でも動く」状態に入ってしまい、
“今はもう壊れない”という安心が、成長を止めるリスクに変わっていく。

私の中で明確な“ルール破りトリガー”

このフェーズに入ってから、私は次の3つを 中期的な内的バロメータとして設定している：

  1. 現状に飽きを感じる
  2. 惰性でこなせていると実感する
  3. 成果は出ているのに、快感よりも面倒臭さが勝る

Botが順調に動いていて、Slackにもログにも異常がなく、
PnLも微増している――
それでも**“つまらない”と感じたとき、それがリスクを取り直すべきサイン**だと思っている。

ルールを破るのは“自分で決めたルール”だけでいい

私がここで言う「ルールを破る」とは、
自分で定義した安全設計やチューニングポリシーに、意図的に穴を開けていくことだ。

たとえば：

  • エントリ閾値を1/10にして、あえてDDを増やしてみる
  • 深夜2時〜5時という“非推奨時間帯”に限定してBotを動かしてみる
  • MAX_NOTIONALを上げて一撃のP&Lを変えてみる

これは**“何かを試す”という意味でのリスクオン**であり、
「構造を壊す」のではなく、「構造の中で揺らぎを許す」ことで
ロジックに新しい刺激を与える行動である。

トリガーが明確なら、破り方も管理できる

“飽き”を自覚できるということは、
「そろそろ安全に慣れてきたな」という感覚を言語化できているということだ。

この状態であれば、ルール破りは無謀ではなく、管理された挑戦になる。

  • 破る前に「何をどう変えるか」を言語化し、メモする
  • 結果をログとして保存し、次回以降の判断材料にする
  • “思いつき”ではなく、“意識的な逸脱”として設計する

このようにしておけば、仮に失敗しても「なぜ失敗したか」が分かるし、
次の改善サイクルにスムーズに回すことができる。

開発とは「構造の構築」と「構造の破壊」を繰り返す行為

Bot開発も、それを支える設計も、突き詰めれば 構造を作る→壊す→また作るの連続だ。
問題は「どこをどう壊すか」を無意識ではなく、意識的にやれるかということ。

この感覚を持っている限り、
私は今後どんなフェーズに入っても、飽きすらも成長の材料にできると確信している。

次のセクションでは、今後の戦略的な攻め手である
**「FR構造の活用」と「動的エントリの最適化」**について、設計意図と試行計画をまとめていく。

9. 次の一手：FR 管理と動的エントリ最適化の実験計画

ここまでの開発で、「止まる」「守る」ための構造は整った。
ログ、DB、Slack通知、safe_exit、watchdog──
どれもテストネットと本番の両方で安定して稼働しており、
Botが“自律的に動き続けられる”という最低限の基盤が完成した。

次に進むべきは、いよいよ**“勝つための最適化”**だ。
その第一歩として、私は次の2つの戦略に取り組む計画を立てている：

① Funding Rate（FR）構造に合わせたポジション管理

Bybitのような先物市場では、ポジションを保有しているだけで資金の受け渡し（FR）が発生する。
このFRを無視したロジックでは、

  • 長時間ポジションを持ちすぎてFR支払いが膨らむ
  • 逆FR時にあえて保有してしまい、相場変動とは無関係に損失が発生する

といった“見えない損失”が積み重なっていく。

そこで検討しているアプローチ：

  • FRタイミング（毎8時間）前後 ±5分で ポジションを持たないように調整
  • FRが“受け取り”になるときだけ、ポジション保有をあえて継続して利益を増やす
  • get_funding_rate() を定期ポーリングし、FR予測値と現在ポジ状態での損益をスコア化
if upcoming_fr < -0.0005:
    should_exit = True  # 損FRなら回避

このようにFRをトリガーとしてポジションを動的に調整できれば、
**“取引していない時間すら収益化・損失回避できる”**Botに一歩近づく。

② 動的エントリの最適化（ボラ × 板厚 × FR を条件に）

もう一つの実験は、エントリの閾値（S_ENTRY）やタイミングを“動的”に変化させることだ。
現在は静的な数値（例：S_ENTRY=1e-5）で判定しているが、
相場の状況は常に変わる。ボラが高いときにチャンスが増え、
板が薄いときに踏み込みすぎればDDが増える。

実験案として考えているのは：

  • 直近1分間のスプレッド中央値・板厚・約定数から「エントリスコア」を計算
  • FRがプラスで、板厚が十分あり、ボラが出ているときだけ should_enter = True
  • 逆に、ボラが低く板も薄ければ強制skip
entry_score = vol_score * 0.5 + fr_score * 0.3 + ob_depth_score * 0.2
if entry_score > threshold:
    should_enter = True

このように、「**いまこの瞬間の市場は“エントリ価値がある”か？」**を数値化できれば、
無駄な注文を避けて手数料を減らしつつ、収益機会は最大化できる。

FR × エントリ × ポジション持続時間 ＝ 最適化の軸が交差する

FR管理と動的エントリは、単体では意味を持たない。
重要なのはこの2つが交差する点に、Botの“収益性”を左右する最適化余地が眠っているということだ。

  • FRが良くても板が薄ければ入らない
  • FRが悪くてもスプレッドと板厚が十分なら数秒だけ入って抜ける
  • エントリ条件と保有時間を同時に動かすことで、短期優位性を最大化する構造が見えてくる

今後はこの2軸をテーマに、テストネットで小さく試し、
実弾でもサイクル単位のPnL推移やDD率を見ながらロジックを段階的に進化させていく予定だ。

次のセクションでは、このような攻めの実験を可能にするために不可欠な
“守りを前提にした実験設計”と“攻めのためのログ設計”の考え方を、最後にまとめていく。

10. まとめ ── 守りを固めた先にある“攻め”のステージへ

今回の開発フェーズでは、Botを“勝てるロジック”に近づけるための土台づくりとして、以下のすべてを整備・確認してきた：

  • Makefile と環境変数設計による運用の一元化
  • safe_exit・watchdog・Slack通知による「止まれる設計」
  • ログとDBによる「後から分析できる設計」
  • テストネット／本番環境での最小構成実弾運用
  • リスクを3層で制御する守りのロジック設計
  • AIとの設計対話による抽象的思考の整理と行動の加速
  • “飽き”や“惰性”をトリガーにしたリスクオン戦略

これらはすべて、「動かすため」ではなく、“検証できるBot”を育てるために取り組んだ工程だった。

開発のゴールは「自分でロジックを育てていける状態」になること

Bot開発とは、一度設計して終わりではない。
常に変化し続ける市場に対して、Bot自身も変化し続けられるように設計することが最終ゴールだ。

そのためには、単に“強い戦略”を実装するのではなく、

  • なぜ動いたかが分かる
  • なぜ止まったかが分かる
  • なぜ勝ったかが分かる
  • なぜ負けたかが分かる

という **「振り返り可能性」**を備えた設計こそが必要になる。

守りが整った今、いよいよ“攻める自由”が手に入った

Botを守るための構造は、すでに整った。
それによって、ロジックを大胆に変えても壊れないという信頼が生まれた。
この状態こそが、今後“自由に攻める”ための最大の武器である。

  • 動的エントリをテストしても、ログで結果が可視化される
  • FR構造を組み込んでも、DDとsafe_exitが守ってくれる
  • ルールを破っても、それを記録して次の学びにできる

開発とは、構造と自由の間を行き来する営みだ。
そして今、私は**「守りの構造を手に入れたからこそ、自由に攻めに出られる」**というステージに立っている。

最後に：今後に向けての行動指針

  1. FR × エントリ × 保有時間の関係性を検証し、可視化する
  2. 1日単位でロット・戦略パラメータを変化させながら学習を継続する
  3. 構造が崩れたら即座に可視化できるよう、ログ設計を常に育て続ける
  4. “退屈さ”や“面倒くささ”をトリガーに、新しい試行を恐れない

Botが止まることを怖れなくなった今、
ようやく本当の意味で勝てるBotを育てる開発が始まったと、そう感じている。

-Bot, 開発ログ