バンドル（まとめ売り）を回避する確実な単一フィルターは存在しない。複数のデータを重ね合わせ、多角的に判定する設計が不可欠だ。
なぜバンドルはボット運用の最大のリスクになるのか
Pump Fun のようなミームコインプラットフォームでは、発射直後のトークンに大量の購入が集中する。このとき、複数のウォレットが協調して買いを入れ、価格を吊り上げたあと一斉に売り抜ける行為を「バンドル」と呼ぶ。非対称戦略（asymetric strategy）のボットは、本来オーガニックな買いの勢いに乗ることを前提としている。バンドルはその前提を根本から壊す。
ボットがバンドルに巻き込まれると、高値掴みした直後に供給が雪崩れ込み、大きな損失を被る。とくにミームコインは流動性が薄く、一瞬で価格が崩壊する。バンドルを見抜けない限り、どれだけエントリータイミングを磨いても勝率は上がらない。
バンドル検知に失敗しやすい典型的なフィルターと限界
バンドルを避けようと、多くのボット運用者は初期購入の SOL 総額や保有者分布に注目する。しかし、単一の指標に頼ると必ずすり抜けが発生する。以下に代表的な失敗パターンを示す。
初期購入の SOL 総額だけを見るフィルター
「最初のブロックで買われた合計 SOL が一定額以上ならバンドル」というルールは、最も素朴なアプローチだ。だが、大口の個人投資家（クジラ）が本気で買うケースと区別がつかない。クジラの単独購入をバンドルと誤判定すれば、伸びるトークンを取り逃がす。
供給分布や保有者集中度に頼るフィルター
上位保有者のトークン占有率が高いトークンを弾く方法も、単体では機能しにくい。バンドル実行者の多くは、供給を複数の小さなウォレットに分散させて保有者数を水増しする。表面上の保有者数は健全に見えるが、実態は一人がコントロールしているケースが大半だ。
買いサイズのパターン分析
購入トランザクションのサイズが不自然に均一だったり、特定のパターンを描くことを検知する手法も試みられている。しかし、バンドル業者は乱数を使って買いサイズをばらつかせるなど、対策を重ねている。静的なパターン検知ではすぐに無力化される。
多角的なバンドル検知フィルターの設計
実用的なフィルターは、複数の観測データを組み合わせてスコア化する。ここでは、現場で有効性が確認されている指標と組み合わせ方を示す。
オンチェーン分析で使える主な指標
- 初回購入ブロックでの合計 SOL 投入額
- 投入された SOL の資金源（入金元）の集中度
- 購入に使われたウォレットの生成タイミングと年齢
- その後の売り圧力の立ち上がり速度
- 購入と売却の時間差（平均保有時間）
資金源の集中度が最も強力な手がかりになる
バンドル実行のために用意される多数のウォレットは、多くの場合、少数の「資金供給元ウォレット」から SOL を受け取っている。オンチェーンで初回購入直前の入金経路を辿ると、数百の購入ウォレットが同一の送金元に依存している構造が浮かび上がる。この「資金源クラスタリング」は、バンドル検知における最も強固なシグナルだ。
ウォレット年齢と生成パターンの組み込み
バンドルに使われるウォレットは、トークン発射直前に大量生成されることが多い。ウォレットの初回トランザクション時刻が、発射タイミングの数十秒前から数分前に密集している場合、高い確率で仕込みと判断できる。「ウォレット年齢が極端に若い集団の同時出現」は、他の指標と組み合わせることで検知精度を大幅に高める。
売り圧力の立ち上がりをリアルタイム評価する
バンドルは買い集めのフェーズが終わると、ほぼ同時に大量の売りが放出される。この「売りの急峻さ」をリアルタイムに監視し、異常値を検出した時点で即座にポジションを閉じる仕組みも有効だ。完全に防げなくとも、被害を最小化する最後の砦（とりで）になる。具体的には、時価総額の増加に対して売り注文数が非線形に跳ね上がるポイントを閾値（しきいち）として設定する。
フィルター実装時の注意点とチューニング
誤検知による機会損失を許容範囲に収める
フィルターを厳しくしすぎると、実際にはバンドルでない本物のムーブメントまで弾いてしまう。バックテストで「バンドルと誤判定したトークンのうち、実際にその後価格が持続した割合」を必ず計測する必要がある。機会損失率が許容できる範囲（例: 5% 以下）に収まるよう、閾値を調整する。
データの取得とパフォーマンス
資金源クラスタリングやウォレット年齢の分析には、発射直後の短期間に大量のオンチェーンデータを取得する必要がある。Solana の RPC（遠隔手続き呼び出し）ノードには高い処理能力が求められる。専用の RPC プロバイダー（Helius、QuickNode など）を使い、getSignaturesForAddress や getTransaction を効率的にバッチ処理する設計が欠かせない。レート制限に注意し、必要なら複数エンドポイントを並列で使う。
フィルターの継続的なアップデート
バンドル業者の手法は常に進化している。数週間単位で有効性が低下することを前提に、自動再学習やパラメータの定期更新の仕組みを組み込む。発見した新たなバンドルパターンを記録し、フィルターロジックに反映させるサイクルを回し続けることが、長期運用の鍵だ。
よくある質問
バンドルと単なる大口購入の見分け方は？
決定的な差は「資金源の分散度」と「購入ウォレットの年齢」に現れる。大口の個人投資家は既存の単一ウォレットから購入し、そのウォレットには長い取引履歴がある。一方、バンドルは複数の新規ウォレットに資金が事前分配されており、資金源が共通しているケースが大半だ。
フィルターが厳しすぎて良いトークンを弾いてしまう場合の調整方法は？
スコアリング方式を採用し、複数指標の合計点で判定する設計に切り替える。単一の閾値で即排除するのではなく、「資金源集中度スコア」「ウォレット年齢スコア」などを重み付け加算し、最終的な判定スコアで柔軟に線引きできるようにする。バックテストを繰り返し、機会損失率とバンドル被害率のバランスを取る閾値を探す。
Pump Fun 以外の DEX でも同じフィルターは有効か？
基本的な考え方は Raydium や Orca など他の Solana DEX でも応用可能だ。ただし、各プラットフォームで取引の流れやスマートコントラクトの構造が異なるため、资金源の追跡方法はそれに合わせて実装を変える必要がある。Pump Fun のボンディングカーブ特有の挙動を前提とした閾値は、他の環境では機能しない。
バンドル検知に機械学習は使えるか？
適切な特徴量設計ができれば強力な武器になる。とくに「資金源グラフの構造的特徴」「購入タイミングの時間分布」などは数値化してモデルに投入しやすい。ただし、リアルタイム推論の遅延がトレードの足を引っ張らないよう、軽量なモデル（決定木ベースなど）を使うか、推論パイプラインを最適化する必要がある。
フィルターのパラメータを最適化する頻度は？
最低でも2週間に1回は過去データで有効性を再検証する。バンドル業者のパターン変更を検知したら、その時点で即座に調整する。全自動化するなら、直近の取引データを毎日取り込み、異常検知モデルでパラメータを自動更新する仕組みが理想だ。
この記事のポイント
- バンドル回避には資金源クラスタリングやウォレット年齢など複数指標の組み合わせが必須
- 単一の閾値フィルターはクジラの買いと区別できず、誤検知を生む
- 売り圧力の急峻さをリアルタイム監視し、被害を最小化する仕組みも有効
- フィルターは定期的なバックテストとパラメータ更新が前提
- RPC ノードの性能とレート制限を考慮したデータ取得設計が重要
「エミリーズ・クリプト・インサイダー」のリサーチ担当として、暗号資産の現場で日々生まれる疑問や悩みを丹念に追いかける。
Reddit や海外フォーラムに寄せられる声を読み解き、「初心者がつまずきやすいポイント」「経験者でも見落としがちな落とし穴
」を一つずつ記事として整理している。
専門的な話を誰もが理解できる言葉に置き換えることに全力を注ぐ。情報の正確さと読みやすさの両立を信条としている。