Slippage Tolerance

なぜスリッページ許容度を緩く設定しすぎると、直接MEVサンドイッチ攻撃の攻撃面になるのですか？両者は具体的にどう繋がっていますか？

サンドイッチ攻撃の動作原理は、本質的に「設定したスリッページ許容度と実際の約定価格の間の乖離」を利用するもので、スリッページ許容度が緩いほど、この利用可能な乖離が大きくなり、両者の繋がりは非常に直接的です。

サンドイッチ攻撃の具体的な手順：攻撃者のボットはオンチェーンの保留中トランザクションプール（mempool）を継続的に監視し、規模が十分大きくスリッページ許容度が十分緩い取引（例：あなたのAgentが1ETHであるトークンをスワップしようとしており、スリッページ許容度が3%に設定されている）を見つけると、攻撃者は3つのことを行います。まずあなたの取引の前に先回りして自分で同じトークンを買い（価格を押し上げる）、あなたの取引をすでに押し上げられた価格で約定させます（しかし約定価格が設定した3%の許容範囲内である限り、取引は依然として成功実行され失敗しません）。次に攻撃者はあなたの取引直後に、先ほど買ったトークンを即座に売却します（あなたの買い注文がさらに価格を押し上げた後、より高い価格で売却して利益を得る）。この全プロセスで、あなたの取引は確かに成功実行されます（価格変動が設定した許容範囲内に収まっているため）が、実際に受け取るトークン量は正常な市場価格で受け取るべき量より少なくなり、この差額が攻撃者の利益源です。

なぜスリッページ許容度が攻撃者の狙う重要なパラメータなのか：攻撃者がこの攻撃を成功させるための前提は「あなたの取引が価格を押し上げられたことで失敗しない」ことです——スリッページ許容度が非常に厳しく設定されている場合（例：0.1%）、攻撃者がわずかに価格を押し上げただけであなたの取引は直接リバートして失敗し、攻撃者の操作行為はむしろ無駄になります（自分の先回り取引がブロックスペースを占有したのにあなたから利益を得られない可能性さえあります）。スリッページ許容度が緩く設定されている場合（例：3〜5%）、攻撃者には価格をこの上限近くまで押し上げる大きな操作余地があり、あなたの取引は依然として成功実行され、攻撃者は安定して利益を得ます。これはスリッページ許容度の緩さ・厳しさが「攻撃者があなたにサンドイッチ攻撃を仕掛ける価値があるかどうか」を直接決定することを意味します——許容度が緩いほど潜在的な利益余地が大きくなり、あなたの取引は攻撃者にとってより魅力的な標的になります。

私のAgentが市場状況に基づいてスリッページ許容度を動的に計算する必要がある場合、具体的にどんなデータを参照すべきで、この計算ロジックをどう設計すべきですか？

スリッページ許容度を動的に計算する核心ロジックは、「現在の市場状況でこの取引が直面する合理的な価格変動範囲はおおよそどれくらいか」から許容度を逆算することであり、固定パーセンテージを適用することではありません。具体的には3つのデータ次元を参照できます。

次元1：取引ペアのリアルタイム流動性の深さ。流動性が深い取引ペアほど（例：主流トークンとステーブルコインのペアで通常流動性プールの規模が大きい）、同じ金額の取引が価格に与える衝撃は小さく、比較的厳しいスリッページ許容度を設定できます。流動性が浅い取引ペアほど（新規上場や取引量の少ないトークンなど）、同じ金額の取引が価格に与える衝撃は大きく、比較的緩い許容度を設定する必要があります。そうしないと取引は容易に失敗します。具体的には、取引を送信する前に、この取引ペアの現在の流動性プール規模をリアルタイムで照会し、「この取引額が流動性プールに占める割合」を計算します。この割合が高いほど、理論上必要なスリッページ許容度も高くなるべきです。

次元2：最近の価格変動度（ボラティリティ）。このトークンの最近（過去1時間または過去24時間など）の価格変動幅を照会できます。最近の変動が激しい場合、「取引送信からオンチェーン反映までの間に価格が自然に変動する可能性」が高いことを意味し、正常な変動による取引失敗を避けるためスリッページ許容度もそれに応じて引き上げるべきです。最近の価格が安定していれば、比較的厳しい許容度を使うことでMEV攻撃に利用されるリスクを下げられます。

次元3：流動性プールに対する取引額の比率（次元1と呼応するがより精密）。取引額が大きいほど価格への影響（price impact）自体が大きくなり、必要なスリッページ許容度も高くなるべきですが、ここには重要な区別があります。「取引自体が引き起こす価格衝撃」と「スリッページ許容度」は異なる概念です。前者はあなたの取引が価格に必ず与える影響（事前に精密に計算可能）であり、後者は「取引確認前に市場が再び変化した」場合のために追加で確保するバッファ空間です。スリッページ許容度の計算は、「取引自体の価格衝撃」に加えて、ボラティリティに基づいて計算された追加バッファ値を加えるべきで、両者を混同すべきではありません。

具体的な実装の推奨：これらのデータをゼロから自分で計算するより、多くの分散型取引所のインターフェースやAPIは通常すでに「現在の市場状況に基づく推奨スリッページ設定値」という機能を提供しています。Agentはこの推奨値を優先的に照会し基準として採用し、自分のリスク選好に応じて微調整する（推奨値に小さな安全マージンを加えるなど）方が、計算ロジックを完全にゼロから再発明するよりよいでしょう。

Agentの取引が失敗した場合（スリッページが許容度を超えたため）、前述のリトライ戦略記事で議論した3種類の失敗タイプのうち、この失敗はどれに属し、どう対処すべきですか？

厳密に言えば、この失敗は前述のリトライ戦略記事で議論した一時的・構造的・循環的のいずれか単一のタイプにきれいに当てはまるわけではなく、どう対処すべきか決定するにはより緻密な判断ロジックが必要です。理由は「スリッページが許容度を超える」根本的な原因が、一時的な市場変動である場合もあれば、持続的な市場状況の変化である場合もあり、両者は異なる対策を必要とするためです。

判断方法：現在の市場状況を再照会し、価格が安定しているか確認する。取引がスリッページで失敗した後、すぐに元のパラメータでリトライするのではなく、まず現在の市場価格と流動性状況を再照会し、元の取引を送信した時点の市場状況と比較します。再照会の結果、価格が元々予想された水準に近づいて戻っている場合（先ほどの変動が短期的・一時的だったことを示す）、この状況は前述の指数バックオフリトライロジックに適しており、元のまたはそれに近いスリッページ設定で再試行します。再照会の結果、価格が持続的で明確な方向性のある動き（大口取引が流動性プールの価格を永続的に変えた、一時的な変動ではなく新しい価格水準になったなど）を示している場合、この状況では元のパラメータでリトライすべきではなく、「新しい市場状況」に対応するスリッページ許容度を再計算するか、この取引が新価格でも実行する価値があるか再評価すべきです（裁定タイプの取引で価格が大幅に変動していれば、元の裁定余地はすでに消失している可能性があり、リトライはむしろ損失を招きかねません）。

この判断ロジックは前述の「構造的失敗は単純なリトライではなく戦略変更が必要」という原則と呼応します：スリッページ失敗が市場状況の実質的な変化によるものであれば、単純なリトライ（より緩いスリッページ設定に変えても）は問題を解決しているのではなく、「とにかく約定させる」ことを盲目的に目指しているだけであり、すでに不利な価格でも取引を実行してしまい不必要な損失を招く可能性があります。より良い対処法は、数回連続でスリッページ失敗が発生し再照会の結果市場状況が確かに継続的に変化していることが分かった場合、前述のリトライ戦略記事で触れた縮退経路をトリガーすべきです（「市場状況が変化したためこの取引の必要性を再評価する必要がある」とマークし、スリッページ許容度を無制限に緩めて無理やり約定させるのではなく）。

追加のコスト考慮：スリッページで失敗した取引は、成功実行しなくても通常一定のGas代を消費します（取引が送信されオンチェーンで実行されリバートする瞬間まで、このプロセスは依然として計算資源を消費するため）。これはスリッページ失敗のリトライにも前述の「単一タスクの総コスト上限」設計を適用すべきことを意味し、スリッページ失敗によるリトライを繰り返して大量のGas代を蓄積消費しながら、実質的な操作を一切成功実行できないという事態を避けるべきです。

マルチAgentシステムで、Sub-agent Aが市場タイミングの判断を担当し、Sub-agent Bが実際の取引実行を担当する場合、スリッページ許容度は誰が決定すべきですか？

この問いは前述のHandoff項目で議論した「実行型Agentは引き継ぎパッケージの結論に完全に依存して最終決定を下すべきではない」という原則を適用できます。答えは、スリッページ許容度の初期提案はSub-agent Aが提供できますが、最終的な実際の数値は実行を担当するSub-agent Bが実行の瞬間に再検証し確定すべきで、Aが与えた数字をそのまま丸ごとコピーすべきではありません。

なぜSub-agent Aだけで決定できないのか：Sub-agent Aが市場タイミングを判断する際、それはその瞬間に照会した市場データに基づいていますが、Aが判断を完了し、タスクをHandoffでBに渡し、Bが実際に取引を送信するまでの間には（短くても）タイムラグが生じる可能性があります——市場状況はこのタイムラグの間にすでに変化している可能性があり、Bが再検証せずAの引き継ぎパッケージに書かれたスリッページ許容度をそのまま使うと、「すでに古くなった市場スナップショット」に基づいて計算された許容度で取引を実行してしまう可能性があり、これはまさに前述のHandoff項目で触れた「引き継ぎパッケージ内の情報は受け取り側がそれを使用する時点ですでに最新の状態ではない可能性がある」というリスクと呼応します。

具体的な分業の推奨：Sub-agent A（タイミング判断）が提供する引き継ぎパッケージには、「取引実行を推奨する」という結論に加え、判断を行った瞬間の市場スナップショットデータ（その時照会した流動性の深さ・変動度）も添付すべきで、Bが「これらのデータが現在の実行時点からどれくらい時間が経過しており、まだ適用可能か」を判断する根拠を持てるようにします。Sub-agent B（取引実行）は実際に取引を送信する前に、Q2で触れた動的計算ロジックを使い、自身の実行時点で再照会したリアルタイム市場データに基づいて独立してスリッページ許容度を計算すべきで、Aが与えた数字を直接引き継ぐべきではありません。Bが再計算した推奨値がAの元の推奨値と大きく異なる場合（市場状況がこの期間中に大きく変化したことを示す）、これ自体が立ち止まって確認する価値のあるシグナルです——前述の「新しい条件下でこの取引を実行すべきか再評価する」というロジックをトリガーでき、再計算されたスリッページ許容度で無理やり取引を送信するのではありません。

この設計が呼応する核心原則：スリッページ許容度は、他のあらゆる「即時性に敏感な」パラメータと同様、Handoffの過程で受動的に伝達されそのまま使われる静的な数値として扱われるべきではなく、実際の実行に最も近い時点で実行担当Agentが再検証すべきです。これは複数のAgentに分散されたタスクで「即時性」への要求が高い場合、特に注意が必要な設計上の詳細です。