MEV と AMM｜サンドイッチと JIT 流動性の読み方

「自社トークンを Uniswap に上場させた後、ユーザーから『MEV で損した』とクレームが来た」——これは事業者が想定しておくべきリスクだ。本記事は事業者目線で、MEV（Maximal Extractable Value）と AMM の関係、自社プロダクトでの防御設計を整理する。

本記事のスコープ: MEV は一括りに「悪」と語られがちだが、実際には種類によって性格が異なる。裁定（Arbitrage）や清算（Liquidation）は市場の価格効率化や Lending プロトコルの健全性維持に寄与する側面があり、これら自体を否定するものではない。本記事ではサンドイッチ攻撃や JIT 流動性など、一般取引者・一般 LP が直接的な被害を受けやすい類型に絞って、事業者の防御策を解説する。

目次

1. なぜ事業者がこれを理解する必要があるのか
2. MEV とは — 「取引順序操作で抜かれる利ざや」
3. サンドイッチ攻撃の仕組み
4. JIT（Just-In-Time）流動性とは
5. MEV のサプライチェーン — 利益はどこで分配されるのか
6. ユーザーと事業者の防御策
7. CowSwap・1inch Fusion・MEV-Boost の使い分け
8. 自社プロダクトの防御設計
9. まとめ

1. なぜ事業者がこれを理解する必要があるのか

3つの場面で関係する:

• 自社トークンを上場させた場合: 一般ユーザーが MEV 被害を受けるリスク → 事業者の責任認識
• 自社で DEX/AMM を組む場合: MEV 対策を組み込む設計判断
• 自社で MEV bot を運営する場合: 戦略 A としての事業選択肢（Flash Loan 記事参照）

2. MEV とは — 「取引順序操作で抜かれる利ざや」

定義

MEV（Maximal Extractable Value） は「ブロック内の取引順序を操作することで抜き出せる価値」を指す。元々は「Miner Extractable Value」(マイナーが抜く)だったが、Ethereum がPoS化したため Maximal に変わった。

MEV の主要分類

このうち「サンドイッチ攻撃」が一般ユーザーに最も直接的な被害を与える。

3. サンドイッチ攻撃の仕組み

ステップ

ここでは「ユーザーが ETH を USDC にスワップする（ETH を売る）」ケースで説明する。

1. 一般ユーザーが大きめの取引（例: ETH 10 枚＝約 $30,000 を USDC にスワップ）を mempool（取引待機列。ブロックに取り込まれる前の、誰でも中身が見える順番待ちスペース）に投入。スリッページ許容値を 1% に設定していたとする
2. MEV bot が mempool でその取引を検知（取引内容・スリッページ許容値はブロック確定前に丸見え）
3. MEV bot が より高い gas（手数料）で同じ方向の取引を先回りで入れる（フロントラン）→ プール内の ETH を先に売り込み、ETH 価格を押し下げる
4. 一般ユーザーの取引が、すでに悪化した価格で約定。許容したスリッページの範囲内ぎりぎりまで価格が滑る
5. MEV bot が 反対方向の取引（押し下げた価格で ETH を買い戻す）で利確（バックラン）。買い戻しコストと売却額の差が bot の利益

一般ユーザーへの被害

数値例で考える。ETH 10 枚（約 $30,000）のスワップで、bot がスリッページ許容値 1% の枠を使って 0.3〜0.6% 程度の追加スリッページを発生させたとする。この場合の被害は概ね $90〜$180（取引額の 0.3〜0.6%）。bot 側は、この差額からフロントラン／バックラン 2 本分の gas コストとプール手数料を差し引いた分を利益として得る。

数値の前提について: サンドイッチの抜き取り額は「取引額そのもの」ではなく「ユーザーが許容したスリッページ枠の一部」で決まる。bot はユーザーのスリッページ許容値を超えると取引が revert（巻き戻し）してしまうため、許容値を上限とした範囲でしか抜けない。したがって被害額は 取引サイズ × プールの薄さ × 許容スリッページ で大きく変わり、流動性が厚いメジャーペアでは取引額の 0.1% 未満、薄い新規トークンでは数 % に達することもある。「ETH 1 枚あたり一律 $15」のような固定額では起きない点に注意。

被害額は流動性が厚いペアの 1 取引あたり数十ドル程度から、薄いプールでは数百ドル以上まで幅があり、日次・週次で累積すると無視できない規模になる。Ethereum 全体で抜かれている MEV はサンドイッチ・裁定・清算を合わせて年間で数億ドル規模と推定されている（出典: Flashbots Transparency / MEV-Explore、EigenPhi を参照。推定方法・期間・対象とする MEV 種別によって規模感は大きく変動する）。

4. JIT（Just-In-Time）流動性とは

仕組み

Uniswap v3 の集中流動性を悪用した MEV 戦略。

1. MEV bot が mempool で大口取引を検知
2. 同一ブロック内で、ターゲット価格帯だけに集中流動性を瞬間投下
3. ターゲット取引が約定（手数料を MEV bot が独占）
4. 同一ブロック内で流動性を引き上げ

これにより MEV bot は ターゲット取引の手数料の大部分を奪い、既存 LP の取り分を平均で約 85% 希薄化させる（出典: Demystifying Just-in-Time (JIT) Liquidity Attacks on Uniswap V3, Imperial College London）。なお JIT は大口取引者にとっては流動性が瞬間的に厚くなることで価格インパクトが下がり、約定がむしろ有利になる側面もある。明確な被害者はスワップ実行者ではなく 既存 LP である点に注意。

一般 LP への被害

通常なら一般 LP が受け取れるはずの手数料の大部分を、MEV bot が瞬間流動性で持っていく。v3 のメインネットで定期的に観察される現象。

5. MEV のサプライチェーン — 利益はどこで分配されるのか

「MEV bot が抜く」と書くと一人の攻撃者が利益を独占しているように見えるが、実際の MEV は 分業された供給網（サプライチェーン） を通って流れ、各層が手数料を取り合う構造になっている。Ethereum の PoS 化以降に普及した PBS（Proposer-Builder Separation。「ブロックを提案する役」と「ブロックの中身を組み立てる役」を分離する設計思想） によって、この供給網は概ね次の 5 層に整理できる。事業者として「自社ユーザーから抜かれた価値が、最終的に誰の懐に入るのか」を理解しておくと、防御策の効きどころが見えてくる。

各層の役割と利益の流れ

bundle・supply chain という言葉の補足

• bundle（バンドル）: Searcher が「この順番でまとめて実行してほしい」と指定する取引の束。サンドイッチなら「フロントラン → ユーザー取引 → バックラン」を 1 つの bundle にして、途中で他人の取引が割り込まないことを保証してもらう
• supply chain（サプライチェーン）: 上の 1→5 の流れ全体を指す。MEV の利益は Searcher が独占するのではなく、入札競争を通じて Builder・Proposer へと「上流」に吸い上げられていく。激しい競争下では、抜いた MEV の大部分が最終的にバリデータ（＝チェーンの担い手）への支払いに回るのが実態

事業者にとっての意味

• 抜かれた価値の行き先: 自社ユーザーがサンドイッチで失った数十〜数百ドルは、Searcher の利益だけでなく、Builder の手数料やバリデータへの入札を通じて供給網全体に分配される。つまり「特定の悪者 1 人を排除すれば終わり」という問題ではなく、構造的に発生する
• 防御の効きどころ: 後述する CowSwap や Flashbots Protect は、この供給網の 入口（2. Searcher 層が mempool を覗くポイント） を塞ぐアプローチ。取引を公開 mempool に流さない、あるいはオークションで MEV を競争させてユーザーに還元させることで、サプライチェーンに「原資」を渡さない・抜き取り分をユーザーに戻す設計になっている
• 自社で DEX を組む側の視点: 第 8 章の TWAP Oracle・取引額制限・JIT 検知は、Searcher が利益機会を「見つけにくく・実行しにくく」する施策であり、供給網の最上流（原資の発生）を細らせる位置づけになる

6. ユーザーと事業者の防御策

ユーザー側の防御策

• スリッページ許容値を絞る: 0.5% 以下に設定
• アグリゲータ経由で取引: 1inch、CowSwap 等を使う
• プライベート mempool 経由: Flashbots Protect 等を使い、取引を公開 mempool に晒さない（MEV-Boost はバリデータ側の仕組みでユーザーが直接使うものではない点に注意。詳細は 7 章）
• 取引額を小さく分散: 大口を分割

事業者側の防御策（自社サービスでユーザーを守る）

• デフォルトでアグリゲータ経由: 自社 dApp が DEX 直接ではなく 1inch/CowSwap 経由で取引
• MEV 対策の UX 提示: ユーザーに「Flashbots Protect 経由で送信」のオプションを提供
• 取引額の分割提案: 大口の場合、自動で分割を提案

7. CowSwap・1inch Fusion・MEV-Boost の使い分け

そもそも Flashbots と MEV-Boost とは

使い分けの前に、よく混同される 2 つの名前を整理しておく。

• Flashbots: MEV を「隠れた抜き取り」から「透明で測定可能なもの」に変えることを目指す 研究組織であり、関連インフラ群の総称。MEV の規模を可視化するダッシュボード（MEV-Explore）、ユーザー向けにサンドイッチを回避させる送信サービス（Flashbots Protect）、そして後述する MEV-Boost などを開発・運用している。MEV を「なくす」のではなく、特定マイナー／業者による独占を防ぎ、競争を通じて民主化・透明化することがミッション。組織やプロダクトの「ブランド」だと捉えるとよい
• MEV-Boost: Flashbots が開発した、前章の PBS（提案役と組立役の分離）をバリデータのソフトウェアの外側（ミドルウェア）で実現する具体的な仕組み。これを入れると、バリデータは自分でブロックを組まず、複数の Builder が出した「このブロックを載せてくれたら X ETH 払う」という入札を Relay 経由で受け取り、最も高く払う Builder からブロックを買ってチェーンに載せる。バリデータにとっては MEV を Builder 間の競争にかけて、その上澄み（入札額）を受け取れるツール

つまり Flashbots は組織・インフラ群の名前、MEV-Boost はその中の 1 プロダクト（バリデータ側のミドルウェア） という関係にある。前章のサプライチェーンで言えば、MEV-Boost は 3〜5 層（Builder → Relay → Proposer）の接続を担う土管であり、Flashbots Protect は 1〜2 層（ユーザー → Searcher）の入口を塞ぐ盾、という役割の違いがある。

CowSwap（CoW Protocol）

何か: 「バッチオークション（一定時間内の注文をまとめて 1 つの価格で清算する仕組み）」と「ソルバー競争」を組み合わせた DEX。ユーザーは自分で執行先を選ぶのではなく、「この条件で売りたい／買いたい」という注文（intent）に署名するだけでよい。

どう MEV から守るか:

1. 一定時間内に集まった複数注文を 1 つのバッチに束ねる
2. その中で売り買いの向きがちょうど噛み合う注文同士を、外部の DEX を経由せず直接マッチングする（これが Coincidence of Wants ＝ 売り買いの欲求（wants）の一致。例: A が ETH を売りたい・B が ETH を買いたいなら両者を相殺）
3. バッチ内で相殺しきれなかった残り分だけを、ソルバー（solver）と呼ばれる執行業者たちが競争し、ユーザーに最も大きな余剰（surplus＝より有利な約定価格）を返せる解を出した者が落札してオンチェーンで執行する

注文を公開 mempool に晒さず、バッチ内では全注文が同一の清算価格で約定するため、取引順序を操作するサンドイッチが原理的に成立しにくい。

誰を・何から守るか: 一般スワップユーザーを、サンドイッチ・フロントランから守る。事業者の使いどころ: 自社 dApp のスワップ機能を、ユーザーが MEV 対策を意識しなくても済むよう CowSwap 経由にする（出典: CoW Protocol Docs）。

1inch Fusion

何か: ユーザーが署名した「意図（intent）」を、リゾルバー（resolver） と呼ばれる承認済みの執行業者（プロのマーケットメイカー）が競争して埋める、Dutch オークション（ダッチオークション） 方式の DEX。ユーザーは取引を自分で送信せず、オフチェーンで署名した注文を出すだけでよい。

どう MEV から守るか:

1. ユーザーは「この条件以下なら満たして良い」という指値に近い注文に署名して出す
2. その注文の提示レートは高い側から時間とともに下がっていく（これが Dutch オークション）。リゾルバーは「自分が利益を出せる」と判断した時点で注文を引き受ける。複数のリゾルバーが先を競うため、結果的にユーザーに有利なレートで早く埋まりやすい
3. リゾルバーは引き受けた注文を自分の取引と束ねて（bundle）ブロックに入れるため、ユーザーの取引が単独で公開 mempool に晒されず、サンドイッチの的になりにくい

ガスレス: 取引コスト（ガス代）はリゾルバー側が負担するため、ユーザーは原則ガス代不要で（ネイティブトークンを持っていなくても）スワップできる。

誰を・何から守るか: 一般スワップユーザーを、フロントラン・サンドイッチから守りつつ、ガス負担も肩代わりする。事業者の使いどころ: ガスを持たない新規ユーザーにも優しいスワップ UX を組みたいときに採用しやすい（出典: 1inch Help Center）。

MEV-Boost（レイヤーが違う点に注意）

ここが最も混同されやすい。CowSwap と 1inch Fusion は「ユーザーを守るツール」だが、MEV-Boost はそうではない。 前章で解説したとおり、MEV-Boost は バリデータ側のブロック調達ミドルウェアであり、バリデータが複数の Builder の入札を受け取って「最も高く払う Builder からブロックを買う」ための仕組みである。一般ユーザーが「MEV-Boost に取引を送る」ことはできないし、ユーザーをサンドイッチから守る道具でもない。

ユーザーが MEV を避けたい場合に使う Flashbots 製のツールは MEV-Boost ではなく、Flashbots Protect（取引を公開 mempool ではなく Flashbots の private な経路に送り、サンドイッチに晒さないユーザー向け送信サービス）の方になる。つまり同じ「使い分け」の文脈で並べるなら、ユーザー保護の選択肢は CowSwap / 1inch Fusion / Flashbots Protect の 3 つであり、MEV-Boost はそこには入らない（出典: Flashbots Docs）。

使い分け

8. 自社プロダクトの防御設計

自社で DEX/AMM を組む場合

• TWAP Oracle の採用: 瞬間価格ではなく時間加重平均を使う
• 取引額制限: 1ブロックでの最大取引額を制限
• Flashbots Protect 接続: ユーザー注文をプライベート mempool 経由に
• JIT 流動性検知: 同一ブロック内 deposit + withdraw を拒否

自社トークン上場時

• 流動性プールの厚みを確保: スリッページが小さくなるよう、初期流動性を厚く
• ユーザー向けガイダンス: 「アグリゲータ経由を推奨」と公式に案内
• Flashbots Protect の案内: ウォレットの RPC を Flashbots Protect に切り替える手順を、ユーザー向けに分かりやすく案内する（取引を公開 mempool に晒さずサンドイッチを回避できる）

9. まとめ

事業者目線で MEV と AMM を理解する要点は5つ。

1. MEV = 取引順序操作で抜かれる利ざや。サンドイッチ攻撃が最も直接的
2. JIT 流動性は v3 集中流動性を悪用した MEV 戦略
3. MEV はサプライチェーン（Searcher → Builder → Relay → Proposer）で分配される構造であり、抜かれた価値は最終的にバリデータまで吸い上げられる
4. CowSwap・1inch Fusion・Flashbots Protect が防御の主要選択肢。Flashbots（組織・インフラ群）と MEV-Boost（バリデータ側ミドルウェア）は層が異なる
5. 自社プロダクトで MEV 防御を UX に組み込むことが事業者の責任

詳しくは Uniswap v2 定数積モデル と Flash Loan の実装と用途 を参照。

関連記事

MEV 防御設計を進める上で、隣接するテーマを並べて読むと意思決定がスムーズになります。

• 価格インパクトとスリッページ — MEV の影響を加味した大口取引コストの計算と最適化。本記事 6章と相互補完
• Flash Loan を使った裁定の実装例 — 本記事 1章で言及した「自社で MEV bot を運営する」戦略 A の実装と収益試算
• Uniswap v3 集中流動性 — 本記事 4章「JIT 流動性」が悪用する集中流動性の仕組みを、運営側目線で深掘り
• Uniswap v4 Hooks アーキテクチャ — Hooks で「ダイナミック手数料」を実装すると MEV 攻撃を抑制できる。設計手段を選ぶ参考
• Health Factor と清算ボット — 本記事 2章で「市場効率化に寄与する」と整理した清算 MEV を、事業として運営する側の視点

本記事は XTELA JAPAN 株式会社が作成しました。 MEV 対策のご相談は無料技術相談からお問い合わせください。