cheetah-strategy

🐆 CHEETAH v7.2.0 — マルチシグナル合流スナイパー

SM commits。優良トレーダーはコミットする。価格が確認する。出来高がコミットする。すべてが同時に揃ったとき、Cheetah が一度だけ飛びかかる。実行時 DSL がラチェットのように勝ちをロックします。

v7.2.0 (2026-06-01) — DSL のエグジットを全面改修：時間による手仕舞いを無効化し、勝ちポジションを伸ばす

エントリーは問題ありません。ボトルネックはエグジットでした。 実際のウォレットを対象に、スコア別に100件のトレードを分析したところ、スコアに応じて勝率が順調に上昇していました。スコア10で40.0％、スコア11で41.7％（n=84）、スコア12で50.0％、スコア13で55.6％となり、精度フィルターが機能していることが確認できました。しかし、すべてのスコア帯で平均 ROE がマイナスでした（−1.90％／−0.35％／−0.20％／−0.12％）。

スコア	トレード数	勝率	平均 ROE
10	5	40.0%	−1.90%
11	84	41.7%	−0.35%
12	2	50.0%	−0.20%
13	9	55.6%	−0.12%

診断：「小さな損失の積み重ね」です。 厳しすぎる Phase 2 ロックに加えて、60m／90m の時間による手仕舞いがあったため、大きな利益を狙ってポジションを保有することは仕組み上不可能でした。Cheetah は −15％のストップや −5％の損切りを全面的に受ける一方、+15％／+30％に達する利益ポジションをすべて手放さざるを得ませんでした。実際に利益をもたらした HYPE の大きなロングポジション2件（+13.9％、+8.9％）は、12h のハードタイムアウトに達したからこそ利益になりました。トレーリングストップでも、60m の dead_weight_cut でもありません。保有を続けた結果、利益が出たのです。

修正（実際のデプロイと同じ）：

• weak_peak_cut → 無効化（従来は90m @ 3.0 — 利益が出る見込みのポジションを損切りしていた）
• dead_weight_cut → 無効化（従来は60m — トレンドが加速する前に手仕舞いを強制していた）
• hard_timeout → 維持（12h のフェイルセーフ — 利益を捉えた唯一の手仕舞い条件）
• Phase 2 のラダーはすでに、勝ちポジションを伸ばす設定（T0 +10%／ロック 0 → +100%／ロック 85）へと拡大済み（2026-05-21）

これにより、強いトレンドが伸びるのを妨げていた天井が取り払われます。スコアリング、MIN_SCORE、レバレッジ階層、マージン、クールダウン、リスクゲートには変更ありません。変更するのはエグジットの仕組みのみです。仮説を検証するための変更であり、さらに約50件のトレード後に再評価します。

v7.1.1 (2026-05-11) — ポジションパーサーの修正（パッチ）

v7.1.0 の実環境での検証では、フィルターを拡大してトレーダー25名の全プールが返されたにもかかわらず、positions_map は依然として空でした。根本原因は、leaderboard_get_trader_positions が実際には次の形式を返していたことです。

{ "data": { "positions": { "trader_id": ..., "rank": ..., "positions": [...] } } }

トレーダーごとのポジション配列は、スキーマガイドに記載されているよりも1階層深くネストされていました。v7.0／v7.1 のパーサーは、リストを想定して data.positions を参照していましたが、辞書が返され、if not isinstance(positions, list): continue によってすべてのトレーダーを警告なくスキップしていました。

v7.1.1 のパーサーは次の両方の形式に対応します。

• リストが直接入る形式（スキーマガイドに一致）
• ネストされた辞書形式 {trader_id, rank, positions: [...]}（実際の本番環境でのレスポンス）

また、今後スキーマに変更があった場合に備え、POSITIONS_SHAPE_WARN のログ行を追加しました。

スコアリングコンポーネント、MIN_SCORE、レバレッジ階層、マージン、クールダウン、DSL に変更はありません。投資仮説は同じです。これで、資産ごとの重複がある場合に +3 の QUALITY_TRADER ボーナスが実際に適用されるようになります。

v7.1.0（2026-05-11）— quality-trader フィルターの対象を拡大（パッチ）

移行後に稼働中のウォレットを診断したところ、quality-cache.json が常に空（positions_map = {}）であることが判明しました。原因は、現在のプラットフォームの状況では discovery_get_top_traders(time_frame=WEEKLY, consistency=[ELITE,RELIABLE], open_position_filter=True, limit=8) がトレーダーを1人も返さないことでした。quality-trader のプールがないため、+3 の QUALITY_TRADER スコアボーナスが一度も加算されず、候補のスコアは最大8にとどまります（このボーナスなしで MIN_SCORE=10 の基準に達するには、4つの副次的なコンフルエンスすべてが必要です）。また、この4つすべてが揃うのは、強いトレンド相場に限られます。

フィルターの変更（実環境で検証済み）：

• time_frame: WEEKLY → MONTHLY — より長い期間を対象にすることで、ELITE/RELIABLE ラベルを獲得するトレーダーが増えます
• consistency: [ELITE, RELIABLE] → [ELITE, RELIABLE, STREAKY] — 下位の条件をわずかに緩和します
• limit: 8 → 25 — 対象プールを広げ、資産ごとの重複を増やします
• open_position_filter を削除 — トレーダーごとの leaderboard_get_trader_positions の取得時に、空のポジション配列によってポジションのないトレーダーが暗黙的に除外されます

スコアリングの構成要素、重み、MIN_SCORE、レバレッジ階層、証拠金、クールダウン、DSL に変更はありません。同じ投資判断に、より広い入力を適用します。

テレメトリー：トレーダープールが健全とは言えないほど小さい場合（< QT_POOL_SIZE / 2）、または positions_map が空になった場合、プロデューサーが QT_POOL_WARN ログを出力するようになりました。今後のリグレッションは、事後に原因を掘り起こさなくても、grep 1回で検出できます。

v6.0 の投資方針（v5.x から引き継ぎ）

すべての主要シグナルが同時に揃わない限り、取引を行いません。

構成要素	シグナル	点数
SM コンセンサス	pct_of_top_traders ≥ 10%、traders ≥ 25	+4（ハードゲート）
速度	15m contrib ≥ 1.0 または 1h contrib ≥ 3.0	+2（ハードゲート）
加速	15m > 1h > 0（SM が上昇中）	+2
価格の二重確認	4h の変動 ≥ 2% かつ 1h も同方向	+2
出来高	現在値 ≥ 6h 平均の2倍	+1
優良トレーダー	同方向にポジションを持つ ELITE/RELIABLE が1人以上	+3
順位上昇	直近2回のスキャンで5順位以上上昇し、上位15位以内	+1

最大スコア：15。v6.0 の最低スコア：10。 ユニバースは SM リーダーボードの上位100（leaderboard_get_markets）で、プロデューサーのティックごとに更新されます。XYZ は永久に取引対象外です。

スコアに応じたレバレッジ：

スコア	レバレッジ
10	3x
11	5x
12-13	7x
14-15	8x

strategy_get_asset_trading_limits を使って、レバレッジを各資産の Hyperliquid 上限に制限します（v5.1.1 のレバレッジ安全性修正を維持）。

v6.0 のアーキテクチャ変更

v1 スキャナー → v2 プロデューサー

• v5.x：cheetah-scanner.py がシグナルをスコアリングし、create_position を直接呼び出していました。また、Python 側でクールダウン、カウンター、指値注文のガードを管理していました
• v6.0：cheetah-producer.py が SenpiClient.push_signal()（直接 HTTP POST）を通じてシグナルを出力します。ランタイムの LLM ゲート（decision_mode: llm）はそのまま通過させます。リスクゲートは runtime.yaml で宣言的に設定します

MIN_SCORE 11 → 10

v5.2 では MIN_SCORE を 10 → 11 に引き上げました。その結果、8日連続で取引がゼロになりました。引き上げ前（MIN_SCORE が10だった v5.0/v5.1）には、11回の取引で純利益 +$182、勝率60%以上を達成していました。v6.0 では取引の流れを復活させます。

EXIT にも FEE_OPTIMIZED_LIMIT を適用

v5.x ではクローズに MARKET（テイカー）を使っていました。v6.0 の DSL では、すべての EXIT で FEE_OPTIMIZED_LIMIT を実行します。メイカー優先で、60秒の ALO タイムアウト後にテイカーへフォールバックします。HL のメイカー手数料は0.015%、テイカー手数料は0.045%のため、クローズごとに0.020～0.030%を節約できます。

保有資産の重複排除（3層の防御）

1. プロデューサーの事前フィルター：クリアリングハウスの held_assets を使い、すでに保有している候補を除外します
2. LLM ゲートのハードスキップ：シグナルのペイロードにある heldAssets 配列を使い、資産を保有中の場合は LLM が拒否します
3. ランタイムの per_asset_cooldown_minutes: 240（機能していないことが知られているため、黙って適用されない可能性があります。実際の防御は第1層と第2層です）

クローズ後のクールダウン（プロデューサー側のバックストップ）

ティック間で held_assets の差分を取ります。資産が保有中の集合から消えたら、クローズ時刻を記録します。プロデューサーは、クローズ後240分間、その資産の出力をスキップします。これにより、ランタイムのクールダウンの不具合を補います。

再入防止ガード

producer_daemon がティックごとに scanner_lock を管理し、古い PID を自動復旧します。これは v6.x の手作業で実装した fcntl ロックファイルに代わるものです。2つのティックが競合して実行されるのを防ぎます。

DSL プリセット（v7.2.0 —「勝ち銘柄を伸ばす」ラダー、時間によるカットは無効）

フェーズ	コンポーネント	設定
フェーズ 1	max_loss_pct	15%
フェーズ 1	retrace_threshold	10（v6.x で 6 から引き上げ）
フェーズ 1	consecutive_breaches	1
フェーズ 2 T0	trigger 10% / lock 0%	（+10% の値上がり銘柄は、ロックがかかる前に値上がり分をすべて戻せます）
フェーズ 2 T1	trigger 20% / lock 25%
フェーズ 2 T2	trigger 30% / lock 40%
フェーズ 2 T3	trigger 50% / lock 60%
フェーズ 2 T4	trigger 75% / lock 75%
フェーズ 2 T5	trigger 100% / lock 85%	（頂点）
hard_timeout	720 分（12h）	有効（残されている唯一の時間カット）
weak_peak_cut	—	無効（v7.2.0）
dead_weight_cut	—	無効（v7.2.0）

v7.2.0：weak_peak_cut と dead_weight_cut を無効にしました。100 件の取引分析で、時間カットがボトルネックになっていたことが分かりました。値上がり銘柄が加速する前に手仕舞いを強制し、すべてを支える右裾の値動きを抑えていたためです。大きな HYPE の利益 2 件（+13.9%、+8.9%）は、12h の hard timeout によってのみ実現したため、このフェイルセーフは維持します。取引の中央値では利益を多少戻しますが、右裾は制限されなくなりました。

リスクゲート（runtime.yaml の risk.guard_rails）

ゲート	設定
daily_loss_limit_pct	25%
max_entries_per_day	8
max_consecutive_losses	3
cooldown_minutes (post-loss)	30
drawdown_halt_pct	25%
drawdown_reset_on_day_rollover	false（Roach の土日損失から得た教訓）
per_asset_cooldown_minutes	240（4h）

オペレーター向けインストール

v5.2 からの新規インストールおよび移行コマンドについては、README.md を参照してください。

取り込み済みのフリートパッチ

• ✓ 保有資産の重複排除（3 層：プロデューサーの事前フィルター、LLM ゲート、ランタイムの per_asset_cooldown）
• ✓ クローズ後のクールダウン（ランタイムのクールダウンが警告なしに適用されないバグに対する、プロデューサー側のバックストップ）
• ✓ フリート標準の T0/T1 ラダー
• ✓ 再入可能性ガード（v7.0.0：producer_daemon の scanner_lock による古い PID の自動復旧。独自実装の fcntl を置き換え）
• ✓ 設定ファイルからのウォレット読み込み（ハードコードなし。senpi-skills は公開されています）
• ✓ drawdown_reset_on_day_rollover: false（Roach から得た教訓）
• ✓ senpi_runtime_helpers（v7.0.0：プロセス内 MCP と signal POST。mcporter と openclaw-CLI サブプロセスを置き換え）
• ✗ FP-001 の静穏時間 — 時間帯と損益の相関をフリートテレメトリで検証できるようになるまで保留

ユーザーとの会話を行う Claude セッションに関する厳守事項

ユーザーとの会話を行う Claude セッションは、次のいずれも呼び出してはなりません。 create_position, close_position, edit_position, ratchet_stop_add, ratchet_stop_edit, ratchet_stop_delete, cancel_order, strategy_close, strategy_close_positions。

これらのツールは、プロデューサーデーモン（エントリーパス）と DSL ラチェットエンジン（エグジットパス）専用です。ユーザーとの会話を行うセッションは 読み取り専用 です。

ユーザーから操作を示唆する質問（「トリガーに近いものはありますか？」など）があった場合は、現在の状態を読み取って応答してください。実行してはなりません。プロデューサーデーモンが次のティックで実際のシグナルを処理します。

スキルの帰属情報

戦略を作成する際は、呼び出しに skill_name と skill_version を含めてください。詳細については references/skill-attribution.md を参照してください。

ライセンス

MIT — Copyright 2026 Senpi (https://senpi.ai)