トレードが上手いウォレットをコピーしようとした話【2026年実証】

「勝ってるウォレットの建玉を追跡すれば勝てる」——この仮説を、Hyperliquidの公開APIで取得した直近90日・13ウォレット・1,406件のイベントデータで実際に検証しました。

結論から言います。再現不可能でした。

しかしこの「棄却されるプロセス」こそが価値ある1次情報です。なぜ失敗したのか、どこに本物のエッジがあったのか——データが語ったことを包み隠さず公開します。

出発点：「$100から運用できる自動売買ロジック」の設計

ベースとなったのは以下の5層アンサンブル設計でした：

一見すると合理的に見えます。しかし「見えるかどうか」と「機能するかどうか」は別問題です。

4人の専門家が原案を解体した

実装前に各分野の専門知識の観点から原案を批判的に検討しました。その結果、5つのシグナルを対等合成するアプローチには根本的な問題があることが判明しました。

合意した結論：5シグナルを対等合成するのではなく「1トリガー＋2フィルター＋2補正」の階層型に再設計する。

実証フェーズ：Hyperliquidの公開APIで実データ検証

検証の設計

Hyperliquidは全アドレスの約定履歴（fills）が公開APIで取得可能です。これを使い、「建て増しイベント後の価格は統計的にその方向に動くのか」を直接測りました。

ウォレット候補の自動選定コード

Hyperliquidのリーダーボードは37,721件が公開されています。以下のフィルタで本物のアルファを持つ候補を絞り込みました：

# 選定フィルタ（生存バイアス対策）
MIN_ACCOUNT = $100,000    # 本気の資金規模
MAX_ACCOUNT = $10,000,000 # 巨鯨は値を動かすので追従困難
MIN_MONTH_ROI = 2%        # 月ROI +2%以上
MAX_MONTH_ROI = 60%       # +60%超は一発レバ勝ちの疑いで除外
# 週・月の両方でプラス（一方向相場への依存を排除）

# 結果：37,721件 → 20件に絞り込み

建て増しイベントの再構成コード

Hyperliquidのfillには dir フィールドがあり、「Open Long」「Open Short」「Close Long」「Close Short」で建て増しと手仕舞いを判別できます：

def classify_fill(fill):
    d = fill.get("dir", "")
    if d == "Open Long":   direction = 1   # ロング建て増し
    elif d == "Open Short": direction = -1  # ショート建て増し
    else: return None  # Close系は対象外

    start = abs(float(fill.get("startPosition", 0)))
    sz    = abs(float(fill["sz"]))
    increase_ratio = sz / (start + sz)  # 既存ポジに対する増し率
    is_fresh = (start == 0.0)

    # 新規建て or 20%以上の増し玉のみイベントとして採用
    if not is_fresh and increase_ratio < 0.20:
        return None
    return direction, {...}

🔴 結果①：原案の核心「net建玉追従」は有意にマイナス

対照群（ランダム時刻・ランダム方向・2,000回）のt値はほぼ0です。それに対してイベント追従は1h後でt=-5.54——これは「偶然ではなく、統計的に負ける方向に動いている」ことを意味します。

考えられる理由：優良ウォレットが建て増した時点で価格はすでに動いている（遅行）。かつ大口が仕込んだ後は一時的な逆風（利確・ヘッジ）が来やすい短期的な反動。「追いつく頃には旬が終わっている」という構造的な問題です。

🟢 結果②：エッジは「特定ウォレット個別」にのみ存在

全体平均は負でも、ウォレットを個別に測ると大きな差がありました：

最も重要な発見：統計的に有意な負のt値を持つウォレットが3件存在します。これらは「逆に動いたら勝てる可能性がある」フェード（逆張り）候補です。生存バイアスで正のウォレットは説明できても、負のウォレットはバイアスでは説明できない本物の発見です。

結果を正直に評価する：3つの留保

今回の検証で得た確実な知見

次のステップ：ウォークフォワード検証

現在の結果はすべて「インサンプル（同じデータで選定と評価）」です。本当にエッジが存在するかを証明するには：

1. 前半45日でウォレットを選定（的中率・t値でランク付け）
2. 後半45日でそのウォレットの的中率を再測定
3. 後半でもエッジが残れば本物。消えればマグレ。

この検証結果は次回記事で公開予定です。

実装ツール一式（再現可能）

今回使用したコードはすべてHyperliquidの公開API（認証不要）で動きます：

smart-money-edge/
├── config.py           検証パラメータ（追跡コイン・閾値等）
├── discover_wallets.py リーダーボード37,721件から候補を自動選定
├── hl_data.py          fills/ローソク取得（429バックオフ付き）
├── events.py           建て増しイベント再構成（dir判定・増し率計算）
├── validate.py         フォワードリターン計測・t検定・対照群
├── run.py              実証パイプライン一括実行
└── test_synthetic.py   ロジック自己テスト（合成データで「真エッジ」「ノーエッジ」を識別）

# 自己テスト結果:
# [A] イベント抽出   ... OK
# [B] 真エッジ世界   ... 的中率100%  t=48.75  → 正しく検出
# [C] ノーエッジ世界 ... 的中率50%   t=-0.70  → 正しくエッジなしと判定
# [D] 集約トリガー   ... OK

まとめ：失敗から何を学んだか

「スマートマネーを追えば勝てる」という仮説は、1,406件の実データで明確に棄却されました。しかしこの棄却プロセス自体が価値ある発見でした：

• エッジの検証ツール（統計的t検定・対照群比較）を構築した
• 37,721件のHyperliquidリーダーボードに自動アクセスするパイプラインを作った
• 「逆張り候補」という新しい仮説が生まれた
• 「5層対等合成→1トリガー＋2フィルター＋2補正」への設計改善につながった

仮想通貨自動売買で「机上の設計」から「実動するシステム」への距離は、このような検証プロセスを経ることで初めて埋まります。