Bot DeFi bot DEX 開発ログ

🛠️開発記録#464(2026/2/24)「歪みを探す前に地図を作ろう — マルチチェーンDeFi経路モデリングの実装記録」

DeFiアービトラージという言葉を聞くと、多くの人は「価格差を見つけること」が出発点だと思うかもしれません。私も最初はそうでした。しかし実際にボットを組み、マルチチェーンで探索を始めてすぐに気づいたのは、価格差よりも前に確認すべきことがあるという事実です。それは、「その経路は本当に存在するのか」という問いでした。

価格が歪んでいるように見えても、トークンの接続関係が閉じていなければ実行は不可能です。閉路があっても、サイズを流せばスリッページで崩壊します。さらに、静的に成立していても、それが時間的に持続しなければ実運用には耐えません。つまり、「歪み」は最終段階の話であり、その前に市場の構造を地図として可視化する必要があるのです。

本記事では、Ethereum、Arbitrum、Base、Polygon、Optimism、Avalancheをはじめとする複数チェーンを対象に、Layer0–3という設計レイヤーで経路を分離し、実行可能性と持続性を段階的に検証してきた実装記録をまとめます。価格差探索からグラフモデリングへ設計を転換した過程、サイズ依存性の可視化、そして24時間の時系列検証まで、実データとスクリプト構成を交えながら整理します。

歪みを探す前に、まずは地図を作る。その設計思想がどのように形になったのかを、技術的観点から記録します。

Ⅰ. なぜ価格差から入る設計は破綻するのか

DeFiアービトラージの入口として、最も直感的なのは「価格差を見つけること」です。
DEX A と DEX B で同じペアにズレがあれば、そこに利益があるように見えます。私も最初はそう考えていました。

しかし、実際にマルチチェーンで探索を始めてすぐに、ある壁にぶつかります。

価格差はあるのに、実行できない。

この現象は例外ではなく、むしろ通常状態でした。

1. 価格差は「閉じた経路」を保証しない

DeFiは価格の集合ではなく、トークン接続のグラフです。

  • ノード：トークン
  • エッジ：プール（DEX上のペア）
  • 重み：価格・手数料・流動性

価格差があっても、トークン接続が閉じていなければ資金は一周できません。
閉路（cycle）が存在しない限り、アービトラージは理論的に不可能です。

そこで私は、価格を見る前にまず「経路が存在するか」を確認する設計に切り替えました（Layer0–2）。

その結果、チェーンごとの構造差が明確に見えました。

  • Ethereum：cycles = 866
  • Arbitrum：cycles = 28

同じ“DeFiチェーン”でも、閉路密度はまったく違います。
価格差以前に、市場の接続構造そのものが違うのです。

価格差から入る設計では、この構造差が見えません。

2. 「存在する」と「使える」は別問題

経路が存在しても、それが使えるとは限りません。
次に立ちはだかるのが、サイズ依存性です。

Layer3で、サイズを変えながら実行可能率を測定しました。

sizeexecutable_rateavg_total_cost_bps
2k100%58.65bps
5k99.55%68.31bps
10k83.45%79.70bps
20k64.43%104.03bps

2kではほぼすべて成立していた経路が、20kでは3分の1以上消えます。
失敗理由の多くは high_impact_hop_*、つまりスリッページです。

価格差だけを見ていると、
「この差ならいける」と判断してしまいます。

しかし実際は、

  • fee（約17bps）
  • impact（サイズ依存で急増）
  • gas換算bps

これらを合算すると、構造的に越えられない壁が存在します。

価格差は“瞬間の値”ですが、
実行可能性は“流したときの結果”です。

ここを混同すると、設計は必ず破綻します。

3. チェーンごとに構造は違う

さらに探索を拡張すると、チェーンごとの差が浮き彫りになりました。

  • Fantom：候補なし
  • zkSync：低サイズのみ部分成立
  • Linea：500/1000成立、2000不成立
  • Optimism/Avalanche：cycles=2（母数不足）

これは価格の問題ではありません。
流動性密度と接続構造の問題です。

価格差探索だけをしていると、「なぜ取れないのか」が永遠に説明できません。
グラフを見て初めて、「そもそも薄い」「閉路が少ない」という構造的理由が見えます。

4. 時間というもう一つの壁

さらに厄介なのは、持続性です。

ある瞬間に成立していても、
15分後には崩れている可能性があります。

そこで、

  • 24時間
  • 15分間隔
  • persistence_rate > 40%

のような基準で時系列検証を導入しました。

価格差は一瞬でも現れます。
しかし、構造が持続するかどうかは別問題です。

5. なぜ価格差から入ると破綻するのか

価格差探索は、

  1. 経路存在を仮定している
  2. サイズ影響を無視している
  3. 持続性を考慮していない

という三重の前提に立っています。

しかし実際のDeFiは、

  • 経路が存在しない場合がある
  • サイズで崩壊する
  • 時間で消える

という三重の現実で動いています。

価格差は結果であり、出発点ではありません。

6. 設計を逆にする

だから私は順序を変えました。

  1. 経路を確定する（Layer0–2）
  2. 実行可能性を判定する（Layer3）
  3. 持続性を測る（時系列）
  4. その上で歪みを評価する

この順序にすると、
“取れない理由”が構造として説明できるようになります。

読者の方の中にも、
「価格差は見えるのに取れない」という経験をした方がいるかもしれません。

それはあなたの実装が悪いのではなく、
設計の順序が逆だった可能性があります。

歪みを探す前に、まず地図を作る。
この転換が、本稿の出発点です。

Ⅱ. 設計の転換：歪みではなく経路を先に確定する

価格差から入る設計が破綻する理由が見えてきたとき、次に必要だったのは「もっと精度の高い価格取得」ではありませんでした。
必要だったのは、順番をひっくり返すことでした。

歪みを探す前に、まず経路を確定する。

この転換が、設計全体を安定させました。

1. Layer0–2：市場をグラフとして扱う

まず行ったのは、Universe構築（Layer0–2）の実装です。

  • トークン集合を固定（チェーンごとにYAMLで定義）
  • DexScreener APIからプール情報を取得
  • token0 / token1 を有向エッジとしてグラフ化
  • 2〜3 hop の閉路（cycle）を列挙
  • 同一プール再利用禁止
  • min_distinct_dexes >= 2 制約

ここでは価格を一切見ていません。

問いはただ一つです。

このチェーン上に、理論上閉じる経路は存在するか？

この段階で、チェーンごとの構造差が一気に可視化されました。

例えば、

  • Ethereum：cycles = 866
  • Arbitrum：cycles = 28

同じ“DeFiチェーン”という括りでも、接続密度はまったく違います。

価格差を見ていたときは、
「なぜEthereumは取れないのに、Arbitrumも難しいのか」が曖昧でした。

しかし、グラフにすると明確です。

  • Ethereum：閉路は多い（密）
  • Arbitrum：閉路は少ない（疎）

ここで初めて、「市場構造」という言葉が意味を持ちました。

2. 経路を固定すると、世界の見え方が変わる

価格差探索では、

  • 差がある → 経路ある？ → 通る？

という順序になります。

経路先行設計では、

  • 経路ある → それが今、歪んでいるか？

になります。

この違いは大きい。

前者は「差があるのに取れない」というストレスを生みます。
後者は「この経路は今は歪んでいない」と冷静に判断できます。

精神的にも、設計的にも安定します。

3. Universeを固定する意味

Universe構築では、以下のような制約を設けています。

  • min_liquidity_usd = 500000
  • max_hops = 3
  • min_distinct_dexes = 2
  • token_query_limit = 0（全トークン探索）

これにより、

  • ノイズプールの除外
  • 単一DEX疑似閉路の排除
  • 過度な組み合わせ爆発の抑制

を実現しました。

重要なのは、「完璧な網羅」ではなく、
一貫したルールで閉路を抽出できることです。

設計が固定されれば、チェーンを増やしても崩れません。

4. チェーン拡張が可能になった理由

この経路先行設計のおかげで、

  • Stage B：Base / Polygon
  • Stage C：Optimism / Avalanche
  • Stage D：BNB / Fantom
  • Stage E：zkSync / Linea

と段階的に拡張できました。

価格差先行設計だったら、
チェーンが増えるたびに混乱していたはずです。

しかし今は、

  1. Universeを定義する
  2. 閉路を列挙する
  3. 母数を確認する

という同じプロセスを繰り返すだけです。

例えば、

  • Fantom：候補なし
  • zkSync：低サイズのみ部分成立
  • Linea：500/1000成立、2000不成立

という結果も、構造の問題として説明できます。

これは「取れない」ではなく、
「そもそも閉路が薄い」という構造的事実です。

5. 歪みは“最後に”見る

経路が確定すると、歪みは評価対象になります。

経路が曖昧なまま歪みを見ると、

  • 経路不足
  • サイズ不足
  • 流動性不足

と原因が混ざります。

しかし経路が固定されていれば、

  • これはimpactの問題
  • これはfee構造の問題
  • これは母数不足の問題

と分解できます。

Layer0–2は、
市場の地図を描く工程です。

歪みは、その地図の上で初めて意味を持ちます。

6. 設計が安定すると、感情が消える

価格差を追っていた頃は、

  • 「差があるのに取れない」
  • 「どこか間違っているのではないか」

という感情が常にありました。

経路を先に確定する設計にしてからは、

  • 「このチェーンは構造的に薄い」
  • 「このサイズはimpactで崩壊する」

と事実ベースで判断できます。

これは技術的進歩であると同時に、
精神的安定でもあります。

7. 設計の本質

この転換の本質はシンプルです。

市場を価格の集合としてではなく、
接続構造を持つネットワークとして扱う。

歪みは現象です。
経路は構造です。

構造が先、現象は後。

この順序を守ることが、
マルチチェーンDeFi探索の土台になります。

Ⅲ. Layer3：実行可能性をモデル化する

Ⅲ. Layer3：実行可能性をモデル化する

Layer0–2で「経路の存在」を確定できても、それだけではアービトラージは成立しません。
閉路はあくまで“通れる道がある”という事実にすぎず、その道をどれだけのサイズで通せるかは別問題です。

ここで必要になるのが、Layer3 ―― 実行可能性のモデル化です。

1. 「存在する」と「使える」は違う

Layer0–2で抽出した閉路は、理論上の経路です。

しかし、実際に資金を流すときには以下が効いてきます。

  • 手数料（fee）
  • 価格影響（impact）
  • ガスコスト（gas）

これらを考慮せずに価格差だけを見ると、

「差はあるのに、実行すると戻ってこない」

という現象が必ず起こります。

そこでLayer3では、各経路に対して

cost_bps = fee + impact + gas換算bps

という形でコストを分解し、サイズ別に実行可能性を判定するモデルを実装しました。

2. サイズを変えると、世界が変わる

Layer3の本質は、サイズ依存性を可視化することです。

実際にサイズスイープを行った結果は以下の通りです。

sizeexecutable_rateavg_total_cost_bps
2k100%58.65bps
5k99.55%68.31bps
10k83.45%79.70bps
20k64.43%104.03bps

2kではほぼすべての経路が成立していたにもかかわらず、
20kでは3分の1以上が実行不能になりました。

主な失敗理由は high_impact_hop_*。
つまり、スリッページが支配的です。

価格差は静的な値ですが、
impactはサイズとともに非線形に増加します。

この時点で明確になりました。

「取れる差」ではなく、「流せる差」を見なければならない。

3. コストの内訳を見る

Layer3ではコストを分解しています。

平均値（10k時点）はおおよそ：

  • avg_fee_bps ≈ 17bps
  • avg_impact_bps ≈ 57bps
  • avg_gas_bps ≈ 5bps
  • avg_total_cost_bps ≈ 80bps

ここで重要なのは、feeやgasよりもimpactが支配的という点です。

Ethereumであっても、
構造的な壁はガスではなくスリッページにありました。

これは直感と少し違います。

「L1だからガスが重い」というよりも、

「サイズを流すと流動性が吸収しきれない」

というのが実態でした。

4. クラスタ分類で見える構造差

Layer3では、経路を以下のように分類しています。

  • 2hop_stable
  • 3hop_stable
  • mixed
  • volatile_triangle

実行可能な経路の多くは volatile_triangle に集中しました。

これは示唆的です。

ステーブル三角は一見安定して見えますが、
実際にはプロの裁定ボットが張り付いている領域で、
歪みは瞬間的に消えます。

一方で、volatile三角は瞬間的に歪みやすい。

Layer3によって、

どのタイプの構造が「実行可能」なのか

が初めて見えてきました。

5. 近似モデルの限界

もちろん、Layer3は完全ではありません。

impactは簡略式（size/liquidity）で近似しています。

しかし実際のAMMは、

  • Uniswap v3：tick単位で流動性が偏在
  • Curve：stableswap曲線
  • ルーター：分割最適化

といった複雑な挙動を持ちます。

つまりLayer3は、

「最終確定」ではなく「スクリーニング」

のためのレイヤーです。

それでも十分価値があります。

なぜなら、明らかに成立しない経路を落とせるからです。

6. 実行可能性は時間にも依存する

Layer3は静的判定ですが、
実際の市場は動き続けます。

そのため、Layer3の判定を15分間隔で再実行し、
24時間の持続性を測る仕組みを導入しました。

ここで重要なのは、

  • avg_rate
  • min_rate
  • persistence_rate

です。

一瞬だけ成立する経路は、実運用では意味を持ちません。

Layer3は、
静的な「使えるか」を、動的な「持続するか」へ橋渡しするレイヤーです。

7. Layer3がもたらした変化

価格差探索の段階では、

  • 「差がある」
  • 「なぜ取れない？」

という曖昧な状態でした。

Layer3導入後は、

  • impactで崩壊している
  • fee構造で無理
  • サイズが大きすぎる

と明確に分解できます。

これは精度の向上であると同時に、
思考の安定化でもあります。

8. 歪みは最後に評価する

Layer3まで来て、ようやく

この経路はサイズXで成立する

と言えるようになります。

歪みを評価するのは、その後です。

順序を間違えると、

  • 取れない差を追い続ける
  • サイズに殺される
  • 構造を誤認する

ことになります。

Layer3は、

歪み評価の前提条件を整える工程です。

経路を確定し、サイズ依存性を理解し、
その上で初めて市場の非効率を測る。

これが、設計の転換によって見えてきた本質です。

Ⅳ. サイズ依存性の発見

Layer3を実装して最初に強く感じたのは、「価格差があるかどうか」よりも前に、サイズがすべてを決めるという事実でした。

それまでは、

  • この経路は成立している
  • コストはおおよそ◯bps
  • 差がこれ以上なら取れるはず

という“単一サイズ前提”の思考をしていました。

しかし、サイズを動かした瞬間、世界はまったく違う顔を見せました。

1. 2kでは成立、20kでは崩壊する

サイズスイープの結果は象徴的です。

sizeexecutable_rateavg_total_cost_bps
2k100%58.65bps
5k99.55%68.31bps
10k83.45%79.70bps
20k64.43%104.03bps

2kではすべての経路が成立していたにもかかわらず、
20kでは3分の1以上が実行不能になりました。

ここで重要なのは、

経路の「存在」は変わっていない

ということです。

閉路は同じ。
トークン接続も同じ。
DEX構造も同じ。

変わったのは、流したサイズだけです。

2. 崩壊の原因はimpactだった

失敗理由を見ると、支配的だったのは high_impact_hop_*。

これはつまり、

流動性はあるが、深くはない

という構造です。

feeはほぼ一定。
gasも大きくは変わらない。

しかしimpactはサイズとともに非線形に増加します。

価格差探索では見えなかったものが、
サイズを動かした瞬間に可視化されました。

3. チェーンごとに違う「サイズの壁」

このサイズ依存性は、チェーンごとにも違います。

例えば：

  • Linea：500 / 1000 は成立、2000は不成立
  • zkSync：低サイズのみ部分成立
  • Fantom：候補なし
  • Optimism / Avalanche：母数が小さいが、10kで崩れる

同じ設計・同じ閾値でも、
成立するサイズはチェーンごとに違いました。

これは単純に「TVLが多いかどうか」ではありません。

  • 流動性の集中度
  • DEX間の接続密度
  • プールの厚み
  • トークン偏り

が絡み合っています。

サイズ依存性は、チェーン構造の指紋のようなものです。

4. 価格差よりも重要な問い

ここで問いが変わります。

従来の問いは：

この差は取れるか？

サイズ依存性を発見した後の問いは：

いくらまでなら取れるか？

この違いは本質的です。

価格差は瞬間的に現れますが、
「どのサイズまで成立するか」は構造的な問題です。

そして構造は、簡単には変わりません。

5. 大きく流すほど有利、は幻想

直感的には、

  • サイズが大きい方が利益も大きい

と思いがちです。

しかし実際には、

  • サイズが大きいほどimpactが急増
  • 成立経路が急減
  • total_costが跳ね上がる

という現象が起きました。

20kではavg_total_costが100bpsを超えています。

これは、歪みがあったとしても吸収できない壁です。

サイズを上げれば利益が増えるという発想は、
AMM構造では通用しません。

6. 「実行サイズ」は設計変数である

この発見により、サイズは結果ではなく、設計パラメータになりました。

各チェーンごとに、

  • persistence_rateが維持される最大サイズ
  • その1段下を運用サイズ

というルールを導入しました。

つまり、

サイズは市場が決めるのではなく、構造が決める。

という考え方に変わりました。

7. サイズ依存性は、歪みよりも強い

価格差は一瞬で消えます。

しかし、

  • このチェーンは2kまでしか成立しない
  • このチェーンは10kまで持つ

という事実は、24時間観測しても大きくは変わりません。

サイズ依存性は、歪みよりも安定した構造情報です。

これを把握せずに歪みを追うのは、

深さを知らずに海に飛び込むようなもの

でした。

8. 設計が一段進んだ瞬間

Layer3でサイズを動かしたとき、

価格差探索の段階では見えなかった“市場の硬さ”が見えました。

  • 成立する経路の減衰率
  • impact支配の壁
  • チェーンごとのサイズ耐性

この瞬間、探索は

「差を探す作業」から
「構造を測る作業」へと変わりました。

サイズ依存性の発見は、
歪み探索から構造モデリングへの分岐点でした。

Ⅴ. チェーンごとの構造差

Layer0–3を実装し、サイズスイープと時系列観測を回し始めて最も面白かったのは、「どのチェーンが儲かりやすいか」ではなく、どのチェーンがどのような構造をしているかが見えてきたことでした。

価格差探索の段階では、チェーンごとの差は「ボラがある／ない」程度にしか見えません。しかし、経路存在と実行可能性を分離すると、まったく別の景色になります。

1. 経路母数の差は、構造密度の差

まず、Layer0–2で列挙した閉路（cycles）の数です。

  • Ethereum：cycles = 866
  • Arbitrum：cycles = 28

同じ「EVMチェーン」であっても、閉路密度は桁違いです。

これは単なるTVLの差ではありません。

  • プール数
  • トークン数
  • DEXの多様性
  • トークン間接続の組み合わせ

が積み重なった結果です。

Ethereumは高密度グラフ、
Arbitrumは疎グラフ。

価格差を見ているだけでは、この違いは分かりません。

2. 密であることは、有利とは限らない

一見すると、cyclesが多いEthereumの方が有利に思えます。

しかし、Layer3で実行可能性をかけると事情は変わります。

10kサイズ時点での実行可能率は：

  • Ethereum：85.22%
  • Arbitrum：28.57%

Ethereumは流動性が深く、実行可能率も高い。

しかし同時に、効率化が進みすぎているという現実があります。

  • ステーブル三角は即座に裁定される
  • 競合ボットが多数存在
  • 歪みは瞬間的

つまり、経路は多いが、歪みは持続しにくい。

一方でArbitrumは、

  • 経路母数は少ない
  • しかし未統合部分が残りやすい

密度と効率はトレードオフです。

3. 中規模チェーンの特徴

PolygonやBaseのような中規模チェーンでは、

  • 経路母数はEthereumより少ない
  • しかしArbitrumよりは密

という中間的な構造が見えます。

この層では、

  • 流動性は一定ある
  • しかし裁定競争はL1ほど激しくない

というバランスが存在します。

ここで重要なのは、「TVLの大きさ」ではなく、

トークン間接続の多様性 × DEX分散度

です。

4. 新興L2の構造的特徴

zkSyncやLineaでは、

  • 低サイズ（500 / 1000）では成立
  • 2000以上で崩壊

というパターンが見えました。

これは明らかに、

流動性は存在するが、厚みがない

という構造です。

経路はある。
しかしサイズを少し上げるだけでimpactが支配的になります。

これは未成熟市場の典型的特徴です。

5. 経路が「ない」チェーンもある

Fantomでは、候補なしという結果も出ました。

価格差探索では「取れない」と感じるだけですが、
グラフを見ると「そもそも閉路が薄い」と分かります。

これは敗北ではなく、構造的事実です。

  • DEX分散不足
  • トークン接続不足
  • 流動性断絶

価格ではなく、接続構造が問題です。

6. チェーンは三種類に分かれる

ここまで観測して、チェーンは大きく三分類できると感じました。

① 高密度・高効率型（Ethereum）

  • 経路多い
  • 流動性深い
  • 競争激しい

② 中密度・部分未統合型（Arbitrum / Base / Polygon）

  • 経路中程度
  • 流動性はある
  • 歪みが局所的に残る可能性

③ 低密度・薄型（zkSync / Linea / Fantom）

  • 経路少ない
  • サイズ耐性低い
  • 低サイズ限定市場

この分類は、価格ではなく構造から導かれたものです。

7. チェーンごとの差は「歪み」ではなく「構造」

価格差は、どのチェーンにも一瞬現れます。

しかし、

  • 経路母数
  • サイズ耐性
  • impact支配の閾値
  • 持続率

はチェーン固有です。

これらは時間が経っても大きくは変わりません。

つまり、

チェーンごとの差は、価格差ではなく構造差である。

8. 構造を理解すると戦略が変わる

価格差探索では、

  • どのチェーンが儲かるか？

という問いになります。

構造モデリングでは、

  • どのチェーンがどのサイズまで成立するか？
  • どのチェーンが持続性を持つか？

という問いに変わります。

戦略は、価格ではなく構造から決まります。

9. 「主戦場」はデータで選べる

24時間の持続性検証を経て、

  • persistence_rate
  • avg_rate
  • cycles_total

を集約すれば、主戦場は主観ではなくデータで選べます。

価格差を追う段階では“勘”が入り込みますが、
構造を見れば“選択”になります。

チェーンごとの構造差を理解したとき、
DeFiは「複数の市場」ではなく、複数のネットワーク構造の集合であることが分かりました。

歪みは、そのネットワークの上に現れる一時的な現象にすぎません。

まず見るべきは、地図そのものです。

Ⅵ. “存在する”と“使える”は別問題

ここまでで、私はようやく一つのことをはっきり理解しました。

経路が「存在する」ことと、
その経路が「使える」ことは、まったく別の問題である。

この2つを混同していたことが、初期の設計を不安定にしていました。

1. 経路は“構造”、実行は“力学”

Layer0–2で確定させたのは、あくまで構造です。

  • トークン接続が閉じている
  • 2〜3 hopの閉路が存在する
  • DEX分散条件を満たしている

これはグラフ理論の問題です。
価格もサイズも関係ありません。

一方で「使えるかどうか」は、

  • sizeを流したとき
  • feeが差し引かれ
  • impactで価格が動き
  • gasが差し引かれる

という力学の問題です。

構造と力学は別のレイヤーにあります。

2. “存在するのに使えない”は普通に起こる

例えばEthereumでは、

  • cycles = 866

という高密度構造が確認できました。

しかし10kサイズ時点での実行可能率は約83%。
20kでは64%まで低下します。

閉路は消えていません。
消えているのは「実行可能性」です。

失敗理由は主に high_impact_hop_*。

つまり、

経路はあるが、深さが足りない。

これは設計の問題ではなく、市場構造の事実です。

3. “使える”の定義を曖昧にしない

「使える」とは何か？

この定義が曖昧だと、設計も曖昧になります。

本プロジェクトでは、

  • cost_bps = fee + impact + gas
  • max_total_cost_bps を閾値に設定
  • サイズ別に executable_rate を算出

という形で明文化しました。

さらに、

  • 24時間観測
  • persistence_rate > 40%

という持続性条件を加えています。

つまり、

一瞬成立する経路は「使える」に含めない。

“存在する”は静的。
“使える”は動的。

この違いを明確にしました。

4. 小サイズで成立する市場の罠

zkSyncやLineaでは、

  • 500 / 1000 は成立
  • 2000以上で崩壊

というパターンが見えました。

ここで判断を誤ると、

「取れる市場だ」

と誤認してしまいます。

しかし実際には、

  • サイズ耐性が極端に低い
  • 流動性が薄い
  • impactが支配的

という構造です。

存在はしている。
しかし使えるとは言えない。

この境界を明確にするのがLayer3の役割です。

5. 持続性という第三の壁

さらに厄介なのは時間です。

ある瞬間に成立していても、

  • 15分後に崩壊
  • 次のサンプルで消滅

ということが普通に起こります。

そこで24時間の時系列観測を導入しました。

  • avg_rate
  • min_rate
  • persistence_rate

これらを見て初めて、

使える経路かどうか

が判断できます。

存在する経路のうち、
持続する経路はさらに少ない。

6. 混同すると起きること

存在と実行を混同すると、

  • 差はあるのに取れない
  • botが悪いのではと疑う
  • 閾値をいじり始める
  • ロジックが崩壊する

という流れになります。

これは実際に私が通った道です。

Layerを分離したことで、

  • 経路はある（構造OK）
  • サイズが大きすぎる（力学NG）
  • 持続しない（時間NG）

と冷静に分解できるようになりました。

7. プロがやっているのは“分離”

プロの設計も基本的には同じです。

  1. 経路を固定
  2. 実行シミュレーション
  3. リアルタイム評価
  4. 実行確定（オンチェーン見積）

このレイヤーを混ぜません。

存在を確定するレイヤーと、
使えるかどうかを判定するレイヤーは別です。

8. 設計が安定する瞬間

“存在する”と“使える”を分けたとき、
設計が急に安定しました。

  • 経路母数は揺れていないか？
  • impactが支配していないか？
  • persistenceは十分か？

チェックポイントが明確になりました。

これは価格差探索では得られなかった視点です。

9. 使えるものを区別する

存在は構造。
使えるかどうかは力学と時間。

この区別を持たない限り、
DeFi探索は常に不安定になります。

Layer分離は、技術的整理であると同時に、
思考整理でもあります。

歪みを追う前に、
その歪みが“使える土台”に乗っているかを確認する。

それが、今回得た最も大きな知見です。

Ⅶ. 24時間持続性検証の設計

Layer0–2で経路を確定し、Layer3でサイズ依存性まで把握できたとしても、まだ足りません。

なぜなら、DeFiは静止していないからです。

ある瞬間に成立している経路が、15分後にも成立している保証はありません。
そして実運用では、「一瞬だけ成立する経路」はほぼ意味を持ちません。

そこで導入したのが、24時間持続性検証です。

1. なぜ“持続性”が必要なのか

価格差探索の段階では、

  • 差があるか？
  • いま取れるか？

という瞬間的な問いしか立ちません。

しかし実際のボット運用では、

  • ノード遅延
  • APIラグ
  • ブロック間変動
  • ガス変動
  • 競合ボット

といった時間軸の要素が必ず介在します。

そのため、問いはこう変わります。

この経路は、一定時間安定して成立しているか？

これが持続性の設計思想です。

2. 検証設計の具体

持続性検証では、次のようなバッチ設計を採用しました。

  • duration-hours = 24
  • interval-seconds = 900（15分間隔）
  • 期待サンプル数 ≈ 96

各サンプルで、

  1. Universe再構築（Layer0–2）
  2. 実行可能性判定（Layer3）
  3. サイズ別成立率を記録

を繰り返します。

これにより、経路存在と実行可能性を時間軸付きで評価できます。

3. 評価指標

持続性を測るために、以下の指標を定義しました。

  • avg_rate：平均実行可能率
  • min_rate：最小実行可能率
  • persistence_rate：成立率が閾値を超えた割合

特に重要なのは persistence_rate です。

例えば、

  • avg_rate = 70%
  • persistence_rate = 20%

であれば、平均は高く見えても、
実際にはほとんどの時間で崩れている可能性があります。

逆に、

  • avg_rate = 60%
  • persistence_rate = 65%

であれば、安定的に成立していると言えます。

持続性は「平均」ではなく「継続」を見ます。

4. 失敗理由の一貫性も見る

持続性検証では、成立率だけでなく、失敗理由の分布も確認します。

主な理由は：

  • high_total_cost
  • high_impact_hop_*

もし失敗理由が常にimpactであれば、

サイズが構造的に重い

と判断できます。

一方、理由が毎回ばらつく場合は、

  • APIラグ
  • dexId揺れ
  • Universe再構築の揺らぎ

といった設計上の不安定性が疑われます。

持続性検証は、経路の安定性だけでなく、
設計そのものの安定性もチェックしています。

5. チェーンごとの持続パターン

24時間観測を行うと、チェーンごとに明確なパターンが見えてきます。

例えば、

  • 高密度チェーンは成立率が高いが、変動も激しい
  • 中密度チェーンは成立率は低めでも安定している
  • 低密度チェーンはそもそも母数が少ない

ここで重要なのは、

持続率 > 平均率 > 経路母数

という優先順位です。

経路が多くても持続しなければ意味がありません。

6. サイズ別持続性の設計

持続性はサイズにも依存します。

例えば、

  • 2kでは安定
  • 5kではやや不安定
  • 10kでは崩壊

という場合、

採用サイズは2kまたは5k

という判断になります。

さらに安全側に寄せるなら、

成立する最大サイズの1段下を運用サイズとする

というルールを設けています。

これは、実行レイヤーでの揺らぎに対するバッファです。

7. 持続性があるということ

持続性が高いということは、

  • 流動性構造が安定している
  • DEX接続が固定的である
  • 突発的な断絶が少ない

という構造的特徴を持つということです。

価格差は瞬間的に現れますが、
持続性は市場構造の安定度を反映します。

8. 24時間検証は「最終判定」ではない

重要なのは、24時間検証もまた中間段階であることです。

  • 経路存在（Layer0–2）
  • 実行可能性（Layer3）
  • 持続性（24h）
  • 最終実行確定（オンチェーン見積）

持続性は「実行確度を上げる」ためのフィルターです。

一瞬成立する経路を除外し、
安定して成立する構造を残す。

9. 時間軸を入れた瞬間、設計が完成する

価格差だけを見ていると、市場はノイズに見えます。

しかし、

  • 経路を固定し
  • サイズを固定し
  • 時間軸を入れる

と、ノイズは構造に変わります。

24時間持続性検証は、

静的モデルを動的モデルに昇華させる工程

でした。

歪みは一瞬です。
しかし構造は、時間の中で観測できます。

そして持続性こそが、
「使える経路」と「存在するだけの経路」を分ける最終フィルターになります。

Ⅷ. 精度の自己評価

ここまでで、

  • 経路存在（Layer0–2）
  • 実行可能性（Layer3）
  • 24時間持続性

まで設計を進めてきました。

では、この設計の精度はどの程度なのか？

ここを曖昧にしたまま次に進むと、どこかで必ず破綻します。
自分のモデルがどこまで信頼できて、どこから先は推論なのかを明確にしておく必要があります。

1. 一次情報と二次情報を分ける

まず大前提として、扱っている情報を2種類に分けています。

一次情報（比較的信頼できる）

  • DexScreener API のプール情報
    • token0 / token1
    • dexId
    • liquidity
  • それを保存したCSV / JSONログ
    • layer1_pools.csv
    • baseline_build_cmd.json

これらは「その時点でAPIが返した事実」です。

もちろんAPIの網羅性やラグの問題はありますが、
少なくとも加工前の事実データです。

二次情報（モデル依存）

  • cycles件数
  • executable_rate
  • cost_bps
  • impact_bps
  • persistence_rate

これらは、一次情報をもとにした推論結果です。

特にimpactは、

impact ≈ size / liquidity

という簡略式を用いています。

Uniswap v3 のtick分布や Curve のstableswap曲線を厳密に再現しているわけではありません。

ここは明確に「近似モデル」です。

2. 経路存在の精度

Layer0–2の精度は比較的高いと評価しています。

  • 同一チェーン内
  • min_liquidity_usd = 500000
  • max_hops = 3
  • min_distinct_dexes = 2

という明確な制約で閉路を列挙しています。

ただし前提は、

DexScreenerが見せている世界の中での正確性

です。

  • DEX命名揺れ
  • プール未取得
  • トークンUniverseの取りこぼし

があれば、存在する経路を見逃す可能性はあります。

したがって、

  • 「抽出した経路が存在する精度」＝高
  • 「すべての存在経路を網羅している精度」＝中

と自己評価しています。

3. 実行可能性（Layer3）の精度

Layer3はスクリーニングとしては有効ですが、
最終確定としてはまだ不十分です。

例えばサイズスイープでは、

  • 2k：100%成立
  • 10k：83.45%
  • 20k：64.43%

という減衰が確認できました。

この減衰の傾向は構造的に妥当です。
しかしimpactの近似が粗いため、

  • v3の局所流動性
  • ルーター分割最適化
  • 実際のswapルート

とは誤差が出ます。

Layer3は、

明らかに成立しない経路を落とす

ためのフィルターであり、

この経路は確実に10kで通る

と言い切るためのレイヤーではありません。

精度評価としては：

  • スクリーニング精度：中〜高
  • 実行確定精度：低〜中

です。

4. 持続性検証の精度

24時間持続性検証では、

  • duration-hours = 24
  • interval-seconds = 900（約96サンプル）

で測定しています。

ここでの精度を左右するのは、

  • サンプル数の十分性
  • Universe再構築の安定性
  • 経路IDの正規化

です。

まだOP / AVAXのように母数が2のチェーンもあり、
ここは「統計的に十分」とは言えません。

持続性は設計として正しい方向ですが、

サンプル不足のチェーンは精度が低い

という自己認識を持っています。

5. ガスモデルの限界

gasは固定USDで置いています。

これは比較には有効ですが、

  • ブロック混雑
  • priority fee変動
  • L1 / L2差

を反映していません。

ガス変動が支配的になる局面では、
Layer3の判定はズレます。

現時点では、ガスは近似的なコスト要素に留まっています。

6. どこまでが「探索として十分」か

現在の設計は、

  • 経路存在の可視化
  • サイズ依存性の把握
  • チェーン間比較
  • 持続性スクリーニング

という意味では十分機能しています。

しかし、

  • オンチェーンクォータによる実swap見積
  • eth_callベースのルーターシミュレーション
  • MEV影響評価

はまだ導入していません。

したがって、

探索精度は中〜高
実行確定精度はまだ低〜中

というのが正直な自己評価です。

7. 自己評価を明確にする意味

精度を曖昧にすると、

  • 過信する
  • 過度に悲観する
  • 閾値をいじり始める

という悪循環に入ります。

自分のモデルがどこまで信頼できるかを明確にすれば、

  • ここまでは地図
  • ここからは現地確認

と冷静に判断できます。

8. 今の位置づけ

いま到達しているのは、

「市場の地図を高解像度で描ける段階」

です。

まだ、

「その地図の上を実際に高速で走れる段階」

ではありません。

しかし、地図なしに走ることはできません。

精度の自己評価は、
次のフェーズに進むための土台です。

過信も過小評価もせず、
現在地を正確に把握することが、
このプロジェクトにおける最も重要な知見の一つです。

Ⅸ. 主戦場選定のロジック

マルチチェーンでLayer0–3と24時間持続性検証まで回すと、次に必ず出てくる問いがあります。

では、どのチェーンを主戦場にするのか？

価格差探索の段階では、この問いはほぼ直感になります。

  • ボラがありそう
  • 最近盛り上がっている
  • TVLが大きい
  • なんとなく効率が悪そう

しかし、経路存在・実行可能性・持続性を分離した今、主戦場は主観ではなくデータで決められるようになりました。

1. 主戦場は「価格」ではなく「構造」で決める

主戦場選定で最初に捨てたのは、「価格差が出やすそう」という基準です。

代わりに採用したのは、次の三指標です。

  1. persistence_rate
  2. avg_rate
  3. cycles_total

そして優先順位は明確にしました。

persistence_rate > avg_rate > cycles_total

理由はシンプルです。

  • 経路が多くても、持続しなければ意味がない。
  • 平均が高くても、瞬間的に崩れるなら運用不能。
  • 持続する経路が少数でもあれば、そこが候補。

母数よりも安定性を優先します。

2. persistence_rateを最優先にする理由

24時間観測で得られる persistence_rate は、

ある閾値以上で成立している時間の割合

です。

例えば、

  • avg_rate = 70%
  • persistence_rate = 25%

というチェーンは、一見良さそうに見えても、
実際には大半の時間で崩れています。

一方で、

  • avg_rate = 60%
  • persistence_rate = 60%

であれば、安定して成立していると判断できます。

主戦場とは、

一瞬勝てる場所ではなく、継続的に勝てる場所

です。

3. 経路母数は最後に見る

cycles_total は重要ですが、最優先ではありません。

例えば、

  • cycles_total = 800
  • persistence_rate = 15%

という高密度チェーンよりも、

  • cycles_total = 40
  • persistence_rate = 55%

の方が戦場としては魅力的です。

高密度市場は効率化が進み、
歪みは瞬間的に消えます。

中密度市場の方が、構造的な未統合が残りやすい。

母数は「可能性」、
持続率は「安定性」です。

4. サイズをどう決めるか

主戦場選定では、サイズも同時に決定します。

ルールは明確です。

  1. persistence_rate >= 閾値 を満たす最大サイズを特定
  2. その1段下を運用サイズとする

例えば、

  • 2k：安定
  • 5k：やや不安定
  • 10k：崩壊

なら、採用サイズは5k、
運用サイズは2kとします。

これはバッファ設計です。

主戦場は「チェーン×サイズ」の組み合わせで決まります。

5. 除外のロジックも明確にする

主戦場選定では、採用と同じくらい「除外」が重要です。

除外基準は例えば：

  • samples < 80（統計不足）
  • cycles_total_avg < 10（母数不足）
  • persistence_rate < 40%（不安定）

これに該当するチェーンは、

研究対象ではあっても、主戦場ではない。

切る基準を明確にすることで、
設計は安定します。

6. スコア化する

主観を排除するため、
ランキングスコアも導入しました。

例えば：

score =
  60 * persistence_rate
+ 30 * avg_rate
+ 10 * log1p(cycles_total_avg)

これにより、

  • 高持続
  • 中密度
  • 過度に効率化されていない

チェーンが自然に上位に来ます。

感覚ではなく数値で選ぶ。

これが主戦場選定の設計思想です。

7. 主戦場は固定ではない

主戦場は永遠ではありません。

  • 流動性が増える
  • DEXが増える
  • 競争が激化する

と、構造は変わります。

だからこそ、

  • Universe再構築
  • Layer3再判定
  • 24時間持続性再測定

を定期的に回せる設計にしました。

主戦場は、常に再評価されるべき対象です。

8. 主戦場とは何か

主戦場とは、

  • 経路が存在し
  • サイズが通り
  • 時間的に持続し
  • 構造的に安定している

チェーンです。

価格差が出やすい場所ではありません。

構造が安定している場所です。

9. 感覚から構造へ

価格差探索では、

なんとなくここが良さそう

という感覚に頼っていました。

Layer分離と持続性検証を経て、

このチェーンは persistence_rate が高い
このサイズまでなら成立する

と説明できるようになりました。

主戦場選定は、
感覚から構造への移行の象徴です。

歪みを追うのではなく、
歪みが“生き残れる場所”を選ぶ。

それが、この設計における主戦場選定ロジックです。

Ⅹ. いま何ができて、何ができていないか

ここまで設計を進めてきた今、一度立ち止まって整理しておきたいことがあります。

いま何ができていて、何がまだできていないのか。

ここを曖昧にすると、過信にも過小評価にも振れます。
自分の現在地を正確に把握することは、技術的にも心理的にも重要です。

1. いま「できていること」

① 経路の存在を構造として確定できる

Layer0–2により、

  • トークン接続をグラフ化
  • 2〜3 hop閉路を列挙
  • DEX分散条件を適用
  • チェーン横断で比較

が可能になりました。

これは単なる価格監視ではなく、
市場の構造を地図として描ける状態です。

価格差があっても経路がなければ不成立。
この当たり前の事実を、プログラムで検証できるようになりました。

② サイズ依存性を定量的に把握できる

Layer3で、

  • fee
  • impact
  • gas

を分解し、サイズ別に executable_rate を算出できています。

例えば、

  • 2kでは100%成立
  • 20kでは64%まで低下

という減衰を確認できました。

これは直感ではなく、数値で説明できる構造情報です。

③ チェーンごとの構造差を比較できる

  • Ethereumは高密度だが効率的
  • Arbitrumは中密度
  • zkSync / Lineaは低サイズ限定
  • Fantomは候補なし

という違いを、価格ではなく構造から説明できています。

これは大きな進歩です。

④ 持続性を時間軸で評価できる

24時間、15分間隔のバッチにより、

  • avg_rate
  • min_rate
  • persistence_rate

を測定し、

一瞬成立する市場と、持続する市場

を区別できるようになりました。

ここまで来て初めて、「使える可能性のある経路」を絞り込めています。

2. まだ「できていないこと」

① オンチェーン実行確定

現在のimpactは近似式です。

  • Uniswap v3 のtick構造
  • Curve stableswap曲線
  • 実ルーターの最適分割

は再現していません。

つまり、

この経路は確実に10kで通る

とはまだ言えません。

これは次フェーズ（Quoter / eth_callシミュレーション）です。

② MEV影響の考慮

現在のモデルには、

  • サンドイッチ
  • 競合ボット
  • ブロック内順序

は入っていません。

持続性が高くても、
実際にブロック内で奪われる可能性はあります。

これは別レイヤーの問題です。

③ 実運用検証

いまの段階は、

  • 地図を描いた
  • サイズを測った
  • 持続性を観測した

ところまでです。

実際に資金を流して、

  • スリッページがモデルと一致するか
  • ガスが想定通りか
  • 実行成功率がどうか

を検証していません。

ここはまだ未到達です。

④ 完全網羅性

Universeは固定トークン集合＋DexScreener依存です。

  • 取りこぼし
  • DEX未取得
  • token表記揺れ

の可能性は残っています。

「見えている世界の中での正確性」であり、
「市場全体の完全網羅」ではありません。

3. 現在地のまとめ

いまの位置はこうです。

  • 経路存在：高精度
  • 実行可能性（近似）：中精度
  • 持続性評価：中精度
  • 実行確定：未
  • 実運用：未

これは決して中途半端ではありません。

むしろ、

価格差探索から構造モデリングへ移行した段階

にいると言えます。

4. 過信もしない、悲観もしない

この段階でありがちな誤りは2つあります。

過信

「これで勝てる」

過小評価

「まだ何もできていない」

どちらも違います。

いまは、

地図が描けた段階

です。

地図なしで戦うより、
地図を持って戦う方が圧倒的に有利です。

しかし、地図だけで戦争は終わりません。

5. 次の一歩

次に進むべきは、

  • 上位経路をオンチェーンで再見積り
  • 実行サイズを確定
  • 実際に小額で検証

です。

ここから初めて、

“存在する”から“本当に使える”

へ移行します。

ここまでで得た最大の知見は、

歪みを追う前に、構造を確定せよ。

そして今は、

構造を確定できる段階に到達している。

これが、現在地です。

Ⅺ. まとめ：価格差ではなく構造を見よ

DeFiアービトラージに取り組み始めたとき、私は「価格差」を追っていました。
どこかにズレがあるはずだ、と。

しかし実装を進めるにつれて、何度も同じ壁にぶつかりました。

  • 差はあるのに通らない
  • 経路が閉じていない
  • サイズで崩壊する
  • 15分後には消えている

そこでようやく気づきました。

問題は価格ではなく、構造だった。

1. 価格は結果、構造が前提

価格差は“現象”です。

  • 流動性の偏り
  • トレードフローの偏り
  • DEX間の統合度

といった構造の上に、瞬間的に現れる結果にすぎません。

構造がなければ、差はあっても取れません。
構造が薄ければ、サイズで崩壊します。
構造が安定していなければ、持続しません。

価格差は最後に見るべきものであり、最初ではありません。

2. 地図を描くという発想

今回の設計転換は、単純なロジック改善ではありませんでした。

  • Layer0–2：経路存在を確定
  • Layer3：サイズ依存性を可視化
  • 24時間検証：持続性を測定
  • 主戦場選定：構造から判断

これは「価格監視」から「市場モデリング」への移行です。

市場を、価格の集合ではなく、
接続構造を持つネットワークとして扱う。

この発想がすべてを変えました。

3. 構造を見れば、迷いが減る

価格差探索では、

  • どこが良さそうか？
  • なぜ取れないのか？
  • 閾値が悪いのか？

と迷い続けます。

構造を見ると、

  • 経路は存在するか？
  • サイズはいくらまで通るか？
  • どのチェーンが持続するか？

と、問いが明確になります。

迷いが減るのは、構造が見えているからです。

4. いま到達した地点

現時点で、

  • 経路は確定できる
  • サイズ依存性は測定できる
  • 持続性は観測できる
  • チェーンごとの差は説明できる

ようになりました。

まだオンチェーン確定やMEV評価は残っています。
しかし、方向は明確です。

地図は描けています。

5. 最後に

DeFiで重要なのは、

「どこに差があるか」ではなく
「どこに構造があるか」

です。

歪みは瞬間的に現れ、消えます。
構造は時間をかけて観測できます。

価格差を追うのではなく、
構造を理解する。

この順序を守ることが、
ボット設計を安定させる最大の鍵でした。

歪みを探す前に、地図を作る。
それが、この開発を通して得た結論です。

-Bot, DeFi bot, DEX, 開発ログ