「負けたことも、ちゃんと書く」というのがこのブログのスタンスです。
4月8日〜9日にかけて、運用中のFX Bot(GMOコイン USD/JPY セッションブレイク戦略)が2日間で -2,256円 の確定損失を出しました。
今回はその原因と、実施した対策を記録します。
何が起きたか
4月8〜9日の相場は、セッションブレイクbotが苦手とする「ブレイク後すぐ反転する」動きが続きました。エントリーしては損切り、またエントリーしては損切り──という展開です。
確定損失の内訳はこうです。
- 1回あたりの損切り幅:24pips固定(当時の設定)
- 損切り回数:複数回
- 合計:-2,256円
金額だけ見れば「まあそんなもんか」と思えるかもしれません。しかし問題は損失額より、「なぜこんなに損切りが連発したのか」という構造的な原因にありました。
原因①:SL(損切り幅)が大きすぎた
当時のSLは 24pips固定 でした。
私はこれを「安全マージン」として設定していたのですが、バックテストを改めて実施したところ、まったく逆の結論が出ました。
24pips1本でも、GMOコインFXの取引単位で計算すると1回あたり数百円の損失になります。それが複数回重なれば、すぐに数千円規模になる。
「損切り幅は広いほど安全」という思い込みが、被害を拡大させていました。
原因②:もっと根本的な設計ミス
SLの問題だけなら「設定を直せば終わり」です。しかし今回の調査で、もっと深刻な問題が見つかりました。
当時の構成を説明します。
このbotシステムは、レジームbot(相場の状態を判定するプログラム)とFX bot(実際にトレードするプログラム)の2本立てで動いています。
レジームbotは「今はトレンド相場か?レンジ相場か?」を判定して、それに応じてFX botを systemctlコマンドで起動・停止 する仕組みでした。
4月9日、ここで事故が起きました。
「FX botがポジションを保有している最中に、レジームbotが『レンジ相場』と判定してFX botをstopした」
Linuxのsystemctl stopは即座にプロセスを終了します。ポジションが残っているかどうかは関係ありません。
結果として、ポジションは証券口座に存在したまま、それを管理すべきbotだけが消えた状態になりました。いわゆる「孤児ポジション」です。
孤児になったポジションはトレイリングストップが機能しません。事前に入れていたサーバーサイドのSL注文だけが頼りになります。その固定SLが24pipsだったので、相場が不利方向に動いたとき、機械的に損切りされ続けました。
実施した対策
対策①:レジームbotの外部制御を撤廃
レジームbotが他のbotをsystemctlで操作する設計を 完全に廃止 しました。
代わりに、レジームbotは判定結果をファイル(current_regime.json)に書き出すだけにしました。各botはこのファイルを自分で読んで、「今はtrendだから動く」「rangeだから待機する」と自律的に判断します。外から強制停止されることはありません。
変更前:レジームbot → systemctl stop/start → FX bot
変更後:レジームbot → current_regime.json書き出し → FX botが内部で読んで判断
この設計変更により、「ポジション保有中に強制停止される」という事故は構造的に起きなくなりました。
対策②:SLを24pips → 14pipsに縮小
バックテストを高精度に作り直した結果、SL=14pipsが最もパフォーマンスが良いという結論が出たため、設定を変更しました。
「損切り幅を狭めるとすぐ刈られるのでは?」と思う方もいると思います。私もそう思っていました。ただ、実際にhigh/lowベースの厳格なバックテストで確認すると、14pipsがベストでした。
対策③:安全弁として+50pips強制全決済を追加
「どんな異常事態でも、+50pipsの含み益が出た瞬間に全決済する」という安全弁を追加しました。
これは利益確定というよりも、「何かおかしいことが起きたときの非常ブレーキ」として機能します。
損失を振り返って
-2,256円は、正直、痛かったです。
ただ、この事故がなければ「レジームbotの外部制御」という根本的な設計ミスに気づくのがもっと遅れていたと思います。より大きなポジションで同じ事故が起きてからでは、被害額が桁違いになっていたかもしれません。
早い段階で、少ない資金で、設計の欠陥を発見できたという点では、授業料としての価値はあったと思っています。もちろん、次は同じ失敗はしません。
まとめ
| 項目 | 変更前 | 変更後 |
|---|---|---|
| SL幅 | 24pips固定 | 14pips |
| レジーム制御 | systemctl stop/start | current_regime.jsonを読んで内部判断 |
| 安全弁 | なし | +50pips強制全決済 |
今回の教訓をひとことで言うと、「外から強制停止するアーキテクチャは危険」です。
プロセスを外部から止めるということは、そのプログラムが「何の途中だったか」を無視するということです。人間なら「今ちょっと待って」と言えますが、プログラムはそうはいきません。
設計を変えてから約1週間、同じ事故は起きていません。引き続き記録していきます。


コメント