> For the complete documentation index, see [llms.txt](https://pancakeswap.gitbook.io/pancakeswap/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://pancakeswap.gitbook.io/pancakeswap/japanese/qu-yin/pancakeswap-infinity/hooks/shared-inventory-hook/rwa-capital-inefficiency-and-how-shared-inventory-solves-for-it.md).
# RWAの資本非効率性とShared Inventoryによる解決
2026-09-04
PancakeSwapのケーススタディ実験(第1部:セットアップ)
本記事は、2部構成のケーススタディの第1部です。この第1部では、RWA資産の発行体が直面している資本効率の実際の問題を整理し、PancakeSwapのShared Inventory Hook(SIH)がそれをどのように解決することを目指しているかをご紹介します。あわせて、オンチェーンデータでSIHを検証するライブのケーススタディ実験についてもご案内します。
今後数週間のうちに、第2部「結果編」を公開します。
***
### 🧩 資本効率の問題とは?
RWA業界が好む数字が1つあります。それは**どれだけトークン化されたか**です。ほぼすべてのレポートの見出しを飾っており、新しいアセットクラスの登場、数十億ドル規模の発行、数百パーセントの成長などが並びます。
しかし、もう1つの数字は埋もれがちです。こちらのほうが重要なシグナルかもしれません。**そのうち実際に取引できるのはどれだけか?**
この2つの数字の差こそが核心です。代表的なトラッカーである[rwa.xyz](http://rwa.xyz)では、オンチェーンで\_表現されている\_価値の総量が、ある時点で実際に\_取引可能な\_量を大きく上回っています。データを見ると、ロック済み・参照用・配布済みの価値は、取引可能な板に存在する価値の**10倍以上**に達しています。
*出典:app.rwa.xyz/stocks*
RWAの発行体にとって、これが落とし穴です。株式、ETF、国債をトークン化することは簡単な部分であり、それを狭いスプレッドで安定して取引できるようにすることが課題です。資本効率が成否を分けるのもここです。最終的な目標は、トレーダーがトークン化資産を\_実際に取引\_できるようにし、しかも簡単かつ低コストにすることです。取引高や手数料が生まれるのは結局そこだからです。
そして、これが単なる流動性の問題ではなく、特に\_資本効率\_の問題である理由は次のとおりです。
#### 見積もるプールごとに、専用のUSDTが必要になる
従来の集中流動性(CLAMM)プールで1つのRWAペアを取引可能にするには、買い手が売り込めるように、発行体が専用のクォート資産(USDT)を用意しておく必要があります。10ペアを上場すれば、CLAMMモデルでは**10個の別々のUSDTスタック**への資金供給が必要になります。ペアごとに1スタックで、互いに助け合うことはできません。このようにクォート資本は専用のサイロに細切れにされてしまいます。
私たち自身の板で測定しました。**PancakeSwapで稼働中のトークン化株式プール7つ**(いずれも従来型のV3 CLAMMプール)を対象に、専用USDTを集計しました。
スナップショット:**2026年9月2日**
ペア
プール内の専用USDT
プールTVL
CRCLB / USDT
$352,836
$654,170
SPYB / USDT
$170,644
$355,677
SNDKB / USDT
$123,262
$227,068
GMEB / USDT
$64,323
$135,665
MUB / USDT
$19,146
$35,733
DRAMB / USDT
$11,041
$22,032
SOXLB / USDT
$4,082
$8,276
合計
$745,334
$1,438,621
つまり、**約$745kのUSDTが専用に割り当てられている**ことになります。
しかも、これは板が存在する銘柄だけの数字です。
SNXXB、KORUB、SOXSB、DJTBにはCLAMMのUSDT板がそもそもなく、トークン化はされていても取引が困難です。
***
### 🎯 発行体は何を最適化すべきか?
仕組みを取り払って考えると、RWAの発行体は本質的に次の3つを解決する必要があります。
1. **資産が真に効率よく取引できること**:主力トークンだけでなく、すべての資産で狭いスプレッドの見積もりを実現すること。
2. **そのために拘束される資本を最小限にすること**:クォート資産は高価であり、10個のUSDTスタックを専用に用意するのはあまり効率的ではありません。
3. **トレーディングデスクを運営しないこと**:日々の流動性インフラを運用しなくても、資産を発行できること。
そこで問題になるのは、流動性を別の形で構成できないかということです。PancakeSwapのShared Inventory Hookは、まさにこの課題を解決するために設計されています。
***
### 🥞 Shared Inventory Hook(SIH)
**SIHは、RWA発行体がペアごとの専用スタックではなく、1つの共有USDTプールで多数のペアを支えられるようにするPancakeSwap Infinityのフックです。**
SIHは流動性をジャストインタイムで提供することで、次のことを可能にします。
* ペアの見積もりがより厚くなる
* 特に大口取引で、プライスインパクトが小さくなる
* 少ない資本でより多くのペアを見積もれるため、RWA発行体の資本が解放される
これらの主張を実際の数字で見てみましょう。
同じ**2026年9月2日**のスナップショット時点で、SIHは1つのフックに\*\*$635,028**のインベントリを保有しており、**$180,467**の共有USDTから**11ペア**を見積もり、稼働率は**87.7%**です。これにより、SIHは**17,299件のトランザクションで$3.56M\*\*を処理しました。
つまり、**約$700kの共有USDT残高1つで約11ペアを見積もっているのに対し、約$745kを使っても見積もれるのは7ペアのみ**です。
役割は同じで、資本の重複をやめるように設計されただけです。
発行体が重視する点に置き換えると、次のようになります。
* 従来はN個の専用USDT残高が必要 → ✅ SIHなら共有プール1つ
* 発行はされているが取引できない → ✅ 取引可能\
ライブ価格の周辺にジャストインタイムでシェアードインベントリを注入することで、V3のUSDT板がないトークンでも、ミントされるだけでなく見積もりが可能になります。
* デスクの運営 → ✅ 許可制のオペレーター\
発行体はインベントリを提供し、見積もりはフックとそのオペレーターが担当します。
***
### 🔬 Shared Inventoryシミュレーターを試す
インタラクティブな比較ツールで、SIHの挙動を直感的に確かめることができます **→**
これは、SIHと従来のCLAMM板との**高レベルで正規化された比較**です。資本効率の仕組みを明確に切り分けるため、現実世界の多くの要因を両側で一定にしています。理解を助けるためのモデルであり、損益計算ではありません。
3つのタブがあります。
* **シミュレータータブ** - インベントリ、バンド幅、フローを調整して、さまざまな条件下でSIHが同等のCLAMMプールと比べてどのように機能する\_はずか\_を試せます。
* **比較タブ** - 同じプール上でSIHを**PancakeSwap V3 CLAMM**の板と直接比較し、共有USDTプールと専用USDTの違いを、投入資本とカバレッジの両面から並べて確認できます。
* **ライブデータタブ** - 本調査を支えるオンチェーンクエリから取得した、SIHの\_現在の実際の\_パフォーマンスを測定できます。
このシミュレーターは、Shared Inventory Hookの動作を理解していただくためのものです。まず試してみて、その後、今後数週間で公開する実際の結果と照らし合わせてみてください。
***
### 🧪 実験について
**今後数週間**にわたってSIHをライブで稼働させ、オンチェーンのソースを用いて、上記の資本効率に関する主張を検証します。毎週、SIHのパフォーマンスとアーキテクチャに関する新しい情報をお届けします。
\*\*調査対象のライブRWAペア:\*\*CRCLB、MUB、GMEB、SNDKB、SPYB、SOXLB、SOXSB、DRAMB、SNXXB、KORUB、DJTB
*注:SNXXB、KORUB、SOXSB、DJTBには、従来型のCLAMM板がそもそもありません。*
**結果は今後数週間にわたり、PancakeSwapの**[**Twitter**](https://x.com/PancakeSwap)**で公開します。**
公開する結果には次の内容が含まれます。
* **パフォーマンスデータの全体像** - 今後数週間のSIHの全データを1つにまとめたもの。
* **資本配分に関する問い** - SIHがRWA発行体の資本を実際にどれだけ節約したか。
* **達成/未達** - SIHが期待を上回った点と、改善が必要な点。
* **結論** - RWAの資本効率においてSIHが実際にどれほど有効かについての、根拠に基づく結論。
*データに関する注記:ここに示した数値は、ライブのオンチェーンクエリと公開されているペアデータから取得しており、出典は本文中に記載しています。一部の比較では集計期間が異なるため、その旨を明記しています。本調査は同条件での比較を目指して設計されていますが、この導入編では問いを提示することしかできませんでした。*
***
### 自社の資産でSIHを有効にしませんか?
RWA発行体の方で、見積もるプールごとに別々のUSDTスタックへ資金を供給することにうんざりしているなら、これはまさにそのための仕組みです。
現在、RWA発行体のオンボーディングを行っています。こちらのGoogleフォームにご記入いただければ、SIHでの資産の見積もり開始までをご案内します -
ご覧いただきありがとうございました。最新情報は[X](https://x.com/PancakeSwap)でご確認いただけます。[Telegram](https://t.me/PancakeSwap)や[Discord](https://discord.gg/pancakeswap)にもぜひご参加ください。
Let’s build,\
The Chefs 🥞
***
*免責事項:本コンテンツは一般的な情報提供および教育目的のみを目的としており、金融、法務、その他の専門的助言と解釈されるべきではありません。デジタル資産の価格は変動が大きくなる場合があります。投資の価値は下がることも上がることもあります。*
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://pancakeswap.gitbook.io/pancakeswap/japanese/qu-yin/pancakeswap-infinity/hooks/shared-inventory-hook/rwa-capital-inefficiency-and-how-shared-inventory-solves-for-it.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
