Uniswap V3 の liquidity フィールドはお金でもスワップ深度でもない。Claude に誤読しやすいフィールドを丁寧に解説させよう。
DeFi をいじる人なら誰でも、いずれは Uniswap V3 のプール画面を眺めることになる。そしてあのびっしり並んだ数字の中には、ほぼ全員が初見で誤読するフィールドが少なくとも一つある —— しかもその誤読は、1 億ドルのプールに「32 京円分の流動性」が乗っていると勘違いするほど致命的だ。
この記事では、smarts MCP と Claude を組み合わせて、5 分で一つのプールを最初から最後まで読み切る。実データはメインネットの USDC/WETH 0.05% プール。
smarts MCP を繋いだあと、Claude に get_uniswap_v3_pool を slug univ3-usdc-weth-eth で呼ばせると、こう返ってくる：
protocol: Uniswap V3
pair: USDC/WETH
fee: 0.05%
price:
1 WETH in USDC: 2310.3381
1 USDC in WETH: 0.00043283
tick: 198868
liquidity: 3243712254364037809
liquidity_note: Uniswap V3 sqrt-formula virtual liquidity
at the current tick. Not a USD amount and
not the depth available to swap.
tvl_usd: 100,645,897.62
tokens:
token0: USDC (decimals 6)
token1: WETH (decimals 18)
block_number: 24959248
データそのものはシンプル。ポイントは各フィールドに罠があるところ。順に分解していく。
USDC/WETH プールでは USDC が「主通貨」で WETH が「価格付けされる資産」だ —— と思いがち。違う。Uniswap V3 はコントラクト内で token0 と token1 をアドレスの 16 進値の大小で並べる。USDC のアドレス 0xa0b8... は WETH の 0xc02a... より小さい。だから token0 = USDC、token1 = WETH。
この順序があらゆる内部計算を支配する：価格の方向、tick の方向、流動性の単位。別のプール、たとえば WETH/DAI に切り替えたら、token0 と token1 の役割はひっくり返るかもしれず、「ETH が上がってる？下がってる？」という直感は全部組み直す必要が出る。
Claude にプールを読ませる利点の一つは、両方向の価格をラベル付きで返してくれること。「このティックはどっちがどっちを買っている方向か」を脳内計算する苦行が消える。
Uniswap V3 によくある fee は 0.01% / 0.05% / 0.30% / 1.00% の四段階。
USDC/WETH が 0.30% ではなく 0.05% を採用しているのは、「ボラティリティは限定的、フローは巨大」という前提だから。マーケットメイカーは厚い手数料ではなく回転で稼いでいる。
これを知っていれば、新しいプールが 1% fee なのを見た瞬間に推測がつく：新規トークンか、誰も気にしていないペアのどちらかだ。
V3 プールの状態に「直近約定価格」という独立フィールドは存在しない。現在価格は slot0.sqrtPriceX96 がそのまま決め、tick はその対数表現。つまり：誰も取引しない限り、価格はそこに居続ける。CEX の「最終約定」とはまったく別のモデル。
（履歴価格を見たいなら V3 内蔵の oracle を使う —— プール状態には observation のアキュムレータが入っていて、そこから TWAP を逆算できる。これは別の仕組み。）
今回読んだ 1 WETH = 2310.34 USDC はプールの「現在の建値」。次のスワップがその価格から始まり、曲線に沿って新しい tick まで価格を押す。
tick: 198868。最初に見たら誰でも戸惑う数字。なんとなく価格っぽいけど、ドルではない。
V3 は価格を対数で離散化する：raw_price = 1.0001^tick。ここでの raw_price は token1 の wei 数 / token0 の wei 数（表示価格ではない）。「1 ETH は USDC でいくらか」に変換するには、さらに 10^(decimals_token0 - decimals_token1) を掛けて補正する。198868 を補正すると 1 ETH ≈ 2310 USDC にぴったり対応する。
なぜここまで回りくどいか。価格を対数化したからこそ、マーケットメイカーは特定の価格レンジだけに流動性を配置できる。たとえば「2200〜2400 の間だけ作る」みたいに。離散 tick はそのレンジを指すラベル。これが V3 が V2 と違う核心：集中流動性。
実務では tick を計算する必要はない。覚えておくべきは：tick が大きいから価格が高いとは限らない（どちらが token0 かに依存する）し、tick 1 つの差は価格 0.01% の差。
最大の罠：liquidity: 3243712254364037809。
19 桁、wei オーダーに見える。でもこれはお金じゃない。
Uniswap V3 の数式における「仮想流動性」L —— sqrt-price レンジ内のマーケットメイク曲線の傾きを表す内部パラメータ。単位は USD でもなければ、プールが実際に持っている資金との比較もできない。
ツールのレスポンスにも liquidity_note で警告が入っている：
Uniswap V3 sqrt-formula virtual liquidity at the current tick. Not a USD amount and not the depth available to swap.
なぜ「スワップ深度でもない」と強調するのか。もう一つよくある誤解は、liquidity を「いまこのプールでスリッページなしに換金できる金額」と読んでしまうこと。これも違う。V3 のスワップ深度は段階的に計算される：現在の tick レンジ内ではこの L を使って sqrt-price 公式を回し、取引量が tick の境界を越えた瞬間に次のレンジへ移って、そのレンジ独自の L に切り替えて続ける。境界を越えるたびに L が入れ替わる。取引量が消化されるまでこれを繰り返す。だから「いくら換えてもスリッページが出ないか」は経路上の各レンジに L がいくら載っているかに依存する —— slot0 のこの数字一つだけ見ても何もわからない。
一文で覚えておけば十分：liquidity フィールドの数字は USD と比較しない、プール間の「深さ」比較にも使わない。それは誤導。
tvl_usd: 100,645,897.62。こちらがプールに実在する資金。
この数字の出どころは？コントラクトが実際に保有している USDC 量と WETH 量に、それぞれ DefiLlama から取得した現在のドル価格を掛け、合計したもの。
liquidity と並べると違いが明確になる：
| フィールド | 値 | 意味 |
|---|---|---|
| liquidity | 3.24 × 10¹⁸ | V3 数式の内部パラメータ、無次元 |
| tvl_usd | $100,645,897 | プールが実際に保有する資金 |
どちらも口語では「流動性」と訳されるが、別物。ストーリーを語るときは TVL、計算するときは liquidity、絶対に混同しない。
最後の細部：block_number: 24959248。
オンチェーンデータは常にブロック番号付きのスナップショット。Claude が引いてきた全フィールドは同じブロックで同期的に読まれている。これが意味するのは二つ：
監視やアービトラージのロジックにはこの整合性が決定的 —— 1 回の取得で世界の整合スナップショットが手に入り、フィールド間の時差を気にしなくていい。
ここまで分かれば道具箱は一気に広がる：
以前ならこれら全てに web3.py をインストールし、スクリプトを書き、ABI を保守し、RPC を借りる必要があった。今は Claude + MCP との対話レベル。聞けば Claude が読む。
V3 の数学モデルは入り口がやや高い。sqrtPriceX96、tick、L、集中流動性 —— これらの概念で多くの人が引き返してきた。だが実務で必要な 90% は「このプールは今どんな状態か、お金はあるか、価格はいくらか」。公式は要らない。
Claude を V3 の翻訳家にしよう。仮想流動性や tick エンコーディングを「1 ETH = 2310 USDC、プールには 1 億ドル入っている」という人間の言葉に変えてくれる。判断はそこからあなたの仕事。