顧客課金がまわすAIインフラの新しい歯車
AIの需要は止まらないのに、インフラ費は前払いと補助に頼りがち。これを反転させるのがRezolve Ai傘下SQD NetworkのRevenue Poolsだ。
顧客の利用料がそのままネットワーク容量の原資になり、使われるほど強くなる“需要直結”の経済設計を掲げる。
単なる価格モデルの変更ではない。エージェントコマース時代に合わせ、データ・決済・知能を束ねる実需ドリブンのスケーリング手法だ。
補助金やトークン放出に依存しない持続性が要で、企業ITの現実に寄せたアップデートと言える。
“SQD’s Revenue Pool model is designed to fund SQD’s infrastructure capacity directly by customer payments as customer usage grows…” Yahoo Finance
Revenue Poolsは何を変えるのか
これまでのWeb3/AIインフラは、補助やトークン報酬でノード供給をブーストし、需要はあとから付いてくる形が多かった。
Revenue Poolsは順番を逆にする。まず企業顧客の支払いがあり、その売上を元に容量を確保・増強する。
この仕組みは、利用が伸びるほどキャパシティ投資が自動的に回るのが特徴だ。
“使われているから強くなる”という、公共インフラに近い需要連動型のダイナミクスをAI/データ基盤に持ち込む。
“With the Revenue Pool, SQD Token holders can temporarily lock their SQD tokens… When customers pay, a piece of that payment may be shared with the participants, who are compensated in stablecoins… ‘In short, customers pay for the service and those who help support it may share in the income it generates.’” PYMNTS
仕組みと関係者：誰が何を得る？
エンタープライズ顧客
大口顧客はサブスクや従量で高性能データアクセスを購入する。
需要に応じて追加キャパが確保され、ミッションクリティカルなワークロードを止めない。
- 利点：SLA志向の安定供給、スケール時の容量確保、コストの透明性。
- 懸念：需要急増時のリードタイム、料金メカニズムの理解負荷。
SQD Network（インフラ提供）
顧客売上を原資にネットワーク容量をロック・増強。
スパイク時も“支払い＝投資”の回路で機動的にスケールできる。
- 利点：需要連動の安定収益、無理なトークン放出依存からの脱却。
- 懸念：大口顧客への集中リスク、契約・回収の運用負荷。
トークン保有者（オプショナル参加）
一定期間SQDをロックして容量裏付けに参加でき、顧客支払いの一部をステーブルコインで受け取る可能性がある。
価格変動とは切り離し、現金フロー（の分配）に紐づくのが設計の肝だ。
“participation does not make Subsquid or Rezolve your guarantor or counterparty… ‘Revenue Pools’ … are funded by enterprise customer payments rather than emissions.” SQD Blog (FAQ)
補助金・トークン報酬型との違い
従来は発行体が“先に”報酬や補助を配り供給を作る。需要が追いつかないと、費用は宙に浮く。
Revenue Poolsは顧客収益→インフラ投資を直結し、使われない容量への過剰投資を抑える。
- 補助・エミッション型の課題：希薄化、価格シグナルの歪み、補助停止時の逆回転。
- Revenue Poolsの強み：利用ベースの健全性、原資の可視化、会計・SLA志向の運用に適合。
“…moving away from subsidy-driven growth and toward customer-funded, usage-based economics.” CoinCodex
使い方ガイド：企業が導入するとき
- 要件定義とSLA設計：必要なチェーン/データ種類、スループット、レイテンシ、可用性を整理。2〜3段階の負荷曲線を想定し、閾値で自動増強するポリシーを設ける。
- 契約と課金モデル：基本サブスク＋従量を組み合わせ、ピーク時の上限・救済手当を定義。監査対応のメータリングとログ保全を前提にする。
- ポータル選定とロック期間：業務の季節変動に合わせ、適切なロック期間/解除条件を検討。急な解約や負荷変動のフェイルセーフを決める。
- 監視とレポーティング：遅延・失敗率・スループットを継続監視。財務には売上/コストの対応関係を月次で可視化し、投資判断に回す。
- 会計・法務・リスク：ステーブル支払いの経理処理、カストディ、税務を整理。ITと法務が共同でポリシー化し、監査証跡を標準化する。
どこに効くのか：ユースケースの輪郭
オンチェーン・データを前提にする金融/決済/分析は需要が読みにくい。
Revenue Poolsは、成長に合わせて自然と容量が厚くなるため、止められない業務に相性がいい。
実際、SQDは大手通信やDeFiの基盤データで実績を積んでいる。
多チェーン横断の履歴・イベントをリアルタイムに出す用途では、課金＝容量の増強が手戻りを減らす。
“SQD provides high-performance blockchain data services to major global organizations, including Deutsche Telekom and top DeFi protocols such as Morpho and PancakeSwap…” Rezolve Press Release
経済設計の要点とリスク管理
要点は、収益原資が顧客支払いであること、支払いが容量投資に還流すること、そしてロック参加者にはステーブル建ての分配可能性があること。
この“会計に乗る設計”は、エンプラ導入の心理的障壁を下げる。
リスクは、需要の集中と季節変動、ロック流動性の制約、そして規制/会計実務の差異だ。
内部統制上は、契約とメータリングの整合、支払い/分配の照合作業が肝になる。
“Rezolve Ai does not sponsor, endorse or promote trading in SQD tokens.” Rezolve Press Release
導入チェックリスト（実務メモ）
- 技術：対象チェーン、レイテンシ要求、可用性、データ保持期間、障害時の迂回設計。
- 財務：サブスク/従量の費目、為替とステーブル処理、コスト連動KPI、SLA違約条項の積上げ。
- 法務・監査：データ利用規約、プライバシー、暗号資産の会計方針、監査証跡とログ保全。
- 運用：需要予測モデル、キャパ閾値、月次/四半期レポート、BCP/DRテストの定期化。
まとめ：AIコマースの“地ならし”としてのRevenue Pools
Revenue Poolsは、需要が動くほど強くなるAI/データ基盤を、企業会計に馴染む形で実装する試みだ。
補助やトークン放出の熱気ではなく、顧客の支払いという現実の重さでインフラを前に押し出す。
エージェントが価値を作り、支払いが走り、データが回る。
その循環を顧客課金でスケールさせる設計は、AIコマースの基礎体力を底上げするはずだ。次は、貴社のSLAと財務のレンズで、このモデルを現場に落とし込む番である。
コメント