急変動検知レーダー Move Radar の設計 — 「勝てる」を約束せず、負け方まで公開する検証システム
Bitget 先物の急変動を、寝ている間・仕事中に見逃していませんか。5分足の異常度スコアで入口を検知し、Discord に通知する仕組みを、ZERO Lab 内部で開発検証中です。名前は Move Radar（急変動検知レーダー）。まだ販売準備中で、Live 資金では動かしていません。本記事では、この検知システムがどのような設計判断で作られているかを、現在の実測データを添えて説明します。
本記事は Move Radar の販売告知ではありません。<br>現在は Bitget Demo (sandbox) 環境での検証段階で、勝てるシステムであることは主張しません。数値はすべて buy.zero-aibot.com/ja/lab/status/ の公開ダッシュボードで随時確認できます（本記事執筆時点のスナップショットです）。
◯ なぜ「検知」だけで、「売買推奨」をしないのか
暗号資産の bot 界隈には「シグナル配信」「勝てる bot 販売」「月利保証」といった訴求が溢れています。Move Radar はそれらと明確に別の立場を取ります。
- 検知して事実ログを配信するところまでを担当する
- 売買判断・売買推奨・利益保証はしない
- 検知が当たったか外したかを、隠さず後追いで公開する
理由はシンプルで、責任分界点を線で引きたいからです。「入口を通知する」ところまでは実装で確度を上げられますが、「その後にエントリーして利益を取れるか」は相場・執行環境・板・スリッページ・保有時間の判断に依存します。ここまでを一つのプロダクトで保証することはできません。
Move Radar は「気づき」を出すシステムです。判断は使う人が行う。これを最初から設計原則にしています。
◯ 現状の検証スコープは BTC と ETH に絞っています
works_data の商品説明には「Bitget USDT-M 流動性上位」と将来スコープを書いていますが、実装レベルで検証しているのは現在 BTCUSDT / ETHUSDT の 2 銘柄のみです。
コード上の定義もこの通りです。
# tradingview_collection_worklist.py
AXIS_SYMBOLS = ("BTCUSDT", "ETHUSDT")TradingView から流れてくるアラートは、この 2 銘柄について複数の時間軸・条件で計 12 チャンネルを監視しており、公開ダッシュボードの「TradingView Coverage 12 / 12」がその状態を表しています。fresh 数（有効期間内のアラート数）と合わせて、runtime 側から 5 分ごとに送信されるヘルスチェックで健全性を見ています。
「なぜ 2 銘柄に絞ったか」は単純で、多銘柄を同時に走らせる前に、少数銘柄で条件と負け方のパターンを掴みたいからです。銘柄を増やすと、勝てているのか勝てていないのかが薄まって見えるようになります。Move Radar は「見えなくする」ことを避けたいので、まず BTC / ETH に絞って、負け方まで分類できる密度を保っています。
◯ Score / Line / Blockers の 3 要素設計
Move Radar が発注するかどうかの判断は、3 つの数字で成り立っています。
| 要素 | 意味 | |---|---| | Score | 自前検知の総合点（各種フラグ・出来高・RSI 位置・トレンド方向を集計） | | Line | Bitget Demo に発注する下限スコア（現在 40） | | Gap | Line と Score の差。プラスなら「発注ラインに届いていない」 | | Blockers | なぜ今発注していないかの全理由 |
現在のダッシュボードの候補状態はこうなっています（本記事執筆時点）。
| Symbol | Score | Line | Gap | Ready | Blockers | |---|---|---|---|---|---| | ETHUSDT | 46.18 | 40 | -6.18 | not ready | required_flag_missing | | BTCUSDT | 24.28 | 40 | +15.72 | not ready | score_below_min, required_flag_missing |
ETHUSDT はスコア自体は Line を超えているのに、required_flag_missing（必須フラグが立っていない）で発注していません。これは「スコアだけで発注しない」ための設計で、後述の rsi_rebound_zone のような文脈条件を追加で満たす必要があります。
BTCUSDT はスコア自体が Line 未満で、フラグも未達。まず「発注しない」判断です。
Blockers の全列挙にこだわっている理由は、「発注しなかった」という事実の記録にこそ、後で条件を見直すための材料が残るからです。「なんで発注しなかったっけ」を後から追いかけられない検知システムは、条件変更の根拠を失います。
◯ 検証 Lane を並列運用する理由
Move Radar は 1 つのルールだけで走っているわけではなく、複数の Lane（=判定ルール一式）を並列で回して比較しています。現在公開している Lane 別の実測成績を並べます。
| Lane | Scope | Closed | W / L | Net (USDT) | PF | WR | |---|---|---|---|---|---|---| | btc_eth_entry_cutline_demo_probe | currentRule | 19 | 7 / 12 | -1.7748 | 0.376 | 36.8% | | btc_eth_practical_forward_demo_probe | currentRule | 5 | 3 / 2 | +0.1547 | 2.576 | 60.0% |
このデータの読み方を隠さず書きます。
- entry_cutline lane：19 件決着で 負け越し中（Net -1.7748 USDT、PF 0.376、WR 36.8%）。条件を厳しくしたつもりでも、Demo 環境の実測ではまだプラスに転じていません
- practical_forward lane：5 件しか決着していないのに WR 60% / PF 2.576。「勝ってる」ように見えますが、サンプルサイズが小さすぎて統計的に何も言えません。もう 30〜50 件は必要です
「Live 資金を投入する前に、Demo で条件別に PF が安定するかを見る」ことが Lane を並列運用する目的です。現時点で Move Radar は Live 化されておらず、この理由もここにあります。
◯ 保護注文（TP 1.6% / SL 1.0% / timeout 120min）
エントリーが決まったときの保護注文設計です。
tpPct: 1.6 # 利確 +1.6%
slPct: 1.0 # 損切り -1.0%
timeoutMinutes: 120 # 2時間で強制決済TP と SL の比率を 1.6 : 1.0 にしているのは、期待値が正になる下限（勝率 38.5%）を超えられる設計を狙っているためです。ただし、これは机上の計算で、実測 WR が 38.5% を超えている保証はまだありません（entry_cutline lane は 36.8%）。
さらに、保護注文が本当に生きているかを毎 run で確認しています。ダッシュボード側の open probe 記録では、こういう形で残っています。
openProbeEvidence=ETHUSDT
entryOrder=1461193406591467521
tpOrder=1461193409292681216
slOrder=1461193409926021120
protectionLive=2/2protectionLive=2/2 は「TP と SL の両方が取引所側に live で残っている」ことを意味します。片方が消えていたら（protectionLive=1/2）、それ自体をエラーとして検知します。「エントリーは通ったのに、SL が実は無かった」という事故を防ぐための構造です。
◯ 条件変更は、Replay の根拠を残してから
Move Radar は「条件を頻繁に変えない」ことを方針にしていますが、変えるときは必ず 30 日 Replay の根拠を条件変更履歴に残します。直近の実例を貼ります。
2026-07-15 の cooldown 変更
| 項目 | 旧 | 新 | |---|---|---| | cooldownMinutes | 30 | 10 |
理由（履歴に残っている原文の抜粋）：
Move out of passive waiting while preserving the tested quality filters. Replay on zero_unified_events.jsonl showed the current rsi_rebound_zone + green route stayed positive over 30d. Cooldown 30m produced 87 settled / PF 1.4046 / avgNet 0.0984%, while cooldown 10m produced 106 settled / PF 1.4823 / avgNet 0.1165%. Broader variants such as trend_green, no_flag_green, rsi_no_extra, volume_green, and long_wick_green were not promoted because their 30d PF was below 1.0 in the same check.
日本語で要約するとこうなります。
- 30 日 Replay で、cooldown 30 分 = 87 件決着 / PF 1.4046 / avgNet 0.0984%
- 同じ Replay で、cooldown 10 分 = 106 件決着 / PF 1.4823 / avgNet 0.1165%
- 10 分の方が件数もパフォーマンスも上だったので採用
- 一緒に検討した trend_green / no_flag_green / rsi_no_extra / volume_green / long_wick_green の派生ルールは、30d PF が 1.0 未満だったので不採用
「PF 1.48 > 1.40 だから 10 分にした」というだけの記述に見えますが、これを条件変更履歴に残すこと、そして「不採用にした派生ルール」まで明記していることが Move Radar のスタイルです。採用された条件だけを残すと、なぜその条件になったかが後で見えなくなるためです。
◯ 負け方の内訳を、隠さず公開する
Move Radar の検証で一番大切なのは「勝つ」ではなく「負け方を分類する」ことです。過去 30 日の Demo 実測を、負け方別に並べます。
| 分類 | 件数 | Net (USDT) | |---|---|---| | positive_close（利益で決済） | 10 | +1.3209 | | timeout_small_loss（保有時間切れの微損） | 11 | -1.2794 | | stop_loss_hit（SL 到達） | 4 | -2.1636 | | 合計 | 25 | -2.1221 |
負け方から見えていること：
- 総合は -2.12 USDT の負け越し（Demo 環境なので実損はゼロ）
- 件数比では positive : timeout : SL = 10 : 11 : 4 で、timeout が最多
- 一方、金額比では SL 到達の 4 件が -2.16 USDT で最も痛い
- positive の +1.32 USDT を、SL の -2.16 USDT が食い潰している構図
このデータが示唆するのは「SL 到達を減らす条件を追加できれば、負け越しから抜けられる可能性がある」ですが、これはあくまで仮説で、実際に SL 到達フラグを避ける Filter を追加した Lane を別途走らせて、Replay で PF が改善するかを見てから条件変更します。
「勝てるロジックがある」ではなく、「なぜ負けているかが分類できる」を可視化するのが Move Radar の設計目的です。分類できていれば、次の条件変更の方向性を決められます。分類できないと、条件を変えても何が改善したのか分かりません。
◯ TradingView + Bitget Demo + 自前検知ロジックの三段構え
Move Radar のデータフローはこうなっています。
TradingView（複数の時間軸アラート・12 チャンネル）
│
▼
自前スコアリングエンジン（rsi_rebound_zone / green / long_wick / trend 等のフラグ集計）
│
▼
Score >= Line か + requiredFlags 満たすか + cooldown 経過か + maxSignalAgeMinutes 内か
│
▼
Bitget Demo API（sandbox）に成行 + TP 1.6% + SL 1.0% + timeout 120m で発注
│
▼
runtime ledger（ローカル状態）+ 公開ダッシュボード（60秒キャッシュで自動更新）- TradingView は「シグナルの入口」を検知する外部センサー
- 自前検知ロジックは「シグナルの重ね合わせ」で確度を出す
- Bitget Demo は Live 資金なしで実注文まで通す
「Live 資金ゼロ」を貫く理由は、条件を変えるたびに実損を出したくないから、そして「Demo 環境で PF 1.4 以上が 30 日安定してから Live 化する」というゲート条件を設定しているからです。この Move Radar は現状、そのゲートを越えていません。
◯ ダッシュボードは 60 秒キャッシュ + heartbeat LIVE 表示
/ja/lab/status/ のダッシュボードは、runtime 側から heartbeat メトリクスが送信され、60 秒キャッシュで自動更新されます。本記事執筆時点で表示されている状態はこうです。
Heartbeat: LIVE (0 分前)
Runner: runs 8229 / exit code 0
TradingView Coverage: 12 / 12 fresh: 12
Mode: demo (sandbox)
Lane: btc_eth_entry_cutline_demo_proberuns 8229 は runner が起動してからのループ実行回数で、exit code 0 は最後の run が正常終了したことを意味します。この 2 つが両方生きていれば、少なくとも「システムが動いている」ことは保証されます。逆に、heartbeat が「STALE」に変わったら、この LP に届く前に社内で気付ける設計になっています。
透明性のトレードオフとして、「絶対金額（total equity の実額）は非公開」にしています。前週比 % のみ表示、これは相場観察者に不要な情報レバレッジを与えない設計判断です。
◯ 販売準備中の意味
Move Radar は現在 販売準備中で価格未設定 です。works_data では status: dev / price: 販売準備中 としています。
販売しない理由：
- Demo での Net がまだプラスに転じていない
- Lane 別 PF が Live 化ゲート（30 日 PF > 1.4）を超えていない
- 「動くもの」は既にあるが、「勝てるもの」ではまだない
- Live 化前に「勝てるを約束しない」姿勢を保つ
販売準備で進めていること：
- Lane 別 Replay の自動化（条件変更を Replay 根拠なしに走らせない仕組み）
- Discord 通知フォーマットの整備（事実だけ流す、シグナルは流さない）
- Live 化前ゲート（30d PF / 30d WR / 30d avgNet のしきい値）の明文化
- ダッシュボードの透明性維持（負け方分類 / 条件変更履歴 / Blockers 全列挙）
「認知育成」というのは、売る前に「どういうスタンスで作っているか」を先に共有しておくことです。ZERO Lab は「勝てる bot を売る」立場を取っていないので、Move Radar もその線に沿った販売設計にします。
◯ 「同じ座組で自分の bot を検証したい」方へ
Move Radar 本体は販売準備中ですが、同じ検証座組は依頼として受注可能 です。以下のパーツを個別に組めます。
| メニュー | 内容 | 見積目安 | |---|---|---| | TradingView Webhook 受信構築 | アラートを Python で受信し JSON 整理・ログ保存・エラー記録まで | ¥3〜8万 | | Paper trade ログ基盤 | エントリー条件・スキップ理由・仮想約定・PF・期待値・最大DD まで保存 | ¥5〜15万 | | Discord / Telegram 通知 | bot 稼働・エラー・注文失敗・残高変化・日次レポートを通知 | ¥3〜10万 | | 検証ダッシュボード | PF / 勝率 / 期待値 / 最大DD を Web で可視化 | ¥10〜30万 |
「Move Radar と同じ透明性で自分の検証システムを組みたい」というご相談は、17 項目フォームから即日見積で返信します。
◯ ダッシュボードと商品ページ
- 実測ダッシュボード: https://buy.zero-aibot.com/ja/lab/status/
- Move Radar 商品ページ: https://buy.zero-aibot.com/ja/works/zero-move-radar/
- 相談フォーム: https://buy.zero-aibot.com/ja/request/
投資助言・売買シグナル・利益保証は行いません。Move Radar は Bitget Demo 環境の検証記録を公開している開発段階のシステムです。数値は本記事執筆時点のスナップショットで、ダッシュボードで最新値が確認できます。