Request

Requestとは？

Requestは、オープンソースの暗号資産支払い請求および照合プロトコルであり、企業やユーザーが署名付きの請求書形式の支払いリクエストを作成し、そのリクエストデータを分散型インフラストラクチャに保存し、その後のオンチェーン支払いをそのリクエストと照合しながらも、決済資金の管理権限を決済プロセッサーに渡さずに済むようにする。
このプロトコルが扱う中心的な課題は、多くのウォレットや決済ゲートウェイがすでに行っているような、抽象的な意味での「トークンを動かすこと」ではなく、支払いを巡る検証可能な会計オブジェクトを作ることにある。すなわち、「誰が要求したのか」「いくら支払うべきか」「どの通貨または計算単位が使われたか」「どこで決済が行われたか」「支払いが自動的に検知・照合可能か」といった情報を構造化して扱う点に特徴がある。

したがって、このプロトコルの実務的な“参入障壁”は、ベースレイヤーのコンセンサスではなくワークフロー統合にある。Requestは、署名付き支払いリクエスト、IPFSストレージ、オンチェーンでのCIDアンカリング、支払いリファレンスイベント、Webhook、APIツール群、マルチチェーン支払いルーティングといった要素を組み合わせ、Request Networkのドキュメンテーションおよびプロトコル概要で説明されているような財務バックオフィス向けのプリミティブを形成している。docs.request.network

Requestは、覇権的なLayer 1やロールアップ、大規模なDeFiマネーマーケットではない。暗号資産のインボイス発行、支払い検知、照合に特化したニッチな決済およびデベロッパーツールのアプリケーションレイヤーである。

2026年5月末時点で、市場データプロバイダーはREQを「小～中型時価総額トークン」の範囲に位置付けており、「システム上重要な暗号資産」とはみなしていない。CoinMarketCapではRequestはおおよそ384位付近に位置し、CoinGeckoやDeFiLlamaは、循環供給量の算定方法やタイミングの違いにより大きく異なる時価総額を報告している。この種のプロトコルにとってTVLは限定的な指標であり、DeFiLlamaの Request Network page では、典型的なレンディング／AMM型TVLではなく、トレジャリーおよびトークン市場データが示されている。これは、Requestがユーザー預かり資産のプールではなく、支払いインフラとして機能していることと整合的である。
より重要なスケール指標は、支払いボリュームおよび処理されるビジネス活動である。財団のウェブサイトによれば、処理ボリュームは累計20億ドル超であり、幅広いステーブルコインをカバーしていると主張されている。一方、コミュニティ主導のRequest Activity Dashboardは日次の支払い件数と支払いボリュームを追跡しているものの、一般消費者向けウォレットや取引所と比較可能なDAU/MAUベースのユーザーコホートは明確には提供していない。(coinmarketcap.com)

Requestの創業者と設立時期は？

Requestは2017年に、以前のフィンテックプロジェクトMONEYTISに関わっていたChristophe LassuytとEtienne Taturによって設立された。Y Combinatorは、Request Networkを2017年冬バッチの企業としてリストしており、パリ拠点で、LassuytをFounder/CFO、TaturをFounder/CTOとしている。
ローンチの文脈は重要である。REQは2017年のICOサイクルの中で登場しており、その時期には多くのプロジェクトが、単なるトークン送金にとどまらず、会計、コマース、ビジネスオートメーションへとEthereumの適用範囲を拡張しようとしていた。歴史的なICOデータベースによれば、トークンセールは2017年10月に行われ、初期トークン供給量は約10億REQとされているが、その後のバーンやトークン会計の変更により、現在の供給量はそれより少ない。
こうした「ビンテージ」は、利点と負担の両方をもたらす。Requestは複数のマーケットサイクルを生き延び、稼働するソフトウェアを維持してきた一方で、2017年世代のユーティリティトークンプロジェクトに共通する「初期の物語が短期的な採用を上回っていた」という評判面の重荷も抱えている。(ycombinator.com)

プロジェクトのストーリーは時間とともにより絞り込まれてきた。

当初のフレーミングは、インボイス、監査証跡、貿易法コンプライアンス、グローバルな支払いリクエストを対象とする広範な分散型決済ネットワークだったが、現在のプロダクト面の重心は、よりオペレーショナルで、イデオロギー色の薄いものになっている。具体的には、APIベースの暗号資産決済、オンチェーンインボイス、支払い検知、クロスチェーンルーティング、一括支払い、定期支払い、および照合に焦点を当てている。

その進化は財団の2025年のアップデートにも表れている。Requestは、API V2、部分支払い、Webhookの強化、暗号資産から法定通貨へのワークフロー、一括支払い、クロスチェーン支払い機能などをリリースしており、「新たな汎用ブロックチェーン」になろうとするのではなく、これらの機能の充実に注力した。
制度的な観点から見ると、このピボットは「ブロックチェーン上のPayPal」から、複数チェーンにまたがる構造化された支払い記録を必要とする財務チーム、決済サービスプロバイダー、暗号資産ネイティブ企業向けのミドルウェアへと軸足を移したものと言える。request.network

Request Networkはどのように機能するのか？

Requestは独自のProof of Work、Proof of Stake、DAG、バリデーターセット、シーケンサー、ロールアップコンセンサスメカニズムを持たない。
オフチェーン／オンチェーンのハイブリッドなプロトコルであり、リクエストの主要な内容はIPFSに保存され、そのIPFSコンテンツ識別子（CID）がオンチェーンにアンカーされ、決済は対応するチェーン上のスマートコントラクトを通じて処理される。

ドキュメンテーションによれば、リクエストはGnosis Chain上にCIDを保存することで作成され、一方で支払いは20以上の対応EVM互換チェーンおよびNEAR上で実行可能である。その後、派生した支払いリファレンスに紐づいたオンチェーンの支払いイベントをインデックスすることで、リクエスト残高が計算される。
技術的に言えば、Requestはアプリケーションレイヤーのプロトコルかつ開発者向けAPIであり、Gnosis、Ethereum、Base、Arbitrum、Optimism、Polygonその他の外部ネットワークから「リブネス」と「ファイナリティ」を継承する形で動作しており、自前のベースレイヤーのセキュリティ予算は持たない。docs.request.network

このプロトコル独自の仕組みは、「支払いリファレンス」である。推奨されるリファレンスベースのモデルでは、リクエストデータから導出された一意の識別子が、ブロックチェーン上の支払いを基礎となるインボイスや支払いリクエストへと紐付ける。プロキシコントラクトは受取人への資金転送を行うとともに、支払い金額とリファレンスを含むイベントを発行し、サブグラフが後の照合作業のためにそれらのイベントをインデックスする。

このシステムは、スケーリングのネイティブプリミティブとしてシャーディングやZKロールアップを用いておらず、その検証モデルは、暗号学的なロールアップ証明の検証というより、「イベントインデックスされた決済＋署名付きリクエストメタデータ」に近い。
Request Nodesは、IPFS、スマートコントラクト、The Graphを跨ぐゲートウェイとして機能する。財団は開発者の利便性のためにノードを運用しているが、本番環境のビルダーについては自前のノード運用を推奨している。これは重要な点であり、たとえ基盤となるリクエストデータやコントラクトがオープンソースであっても、財団がホストするゲートウェイやAPIへの依存は中央集権化の要因となり得るからである。

プライベートリクエストには非対称鍵暗号とAES暗号が追加される。リクエスト内容はAESキーで暗号化され、そのAESキー自体が各ステークホルダーの公開鍵で暗号化されたうえでIPFSに保存される。docs.request.network

REQトークンのトークノミクスは？

REQはおおよそ10億ユニットでローンチされたERC-20トークンであり、その供給プロファイルは、インフレ型のエミッション資産というより、控えめなバーンメカニズムを備えた「ほぼ固定供給」に近いと理解するのが妥当である。
2026年5月末時点で、EtherscanはERC-20トークンコントラクトとして 0x8f8221afbb33998d8584a2b05749ba73c37a938a を掲載しており、最大総供給量は約9.99416億REQとなっている。一方、CoinMarketCapは循環供給量を約7.967億REQとし、CoinGeckoは異なる循環供給量を示している。これは、「循環」供給量の定義が、リザーブ、ブリッジ、非アクティブ残高の扱いによって変わり得ることを示している。

コミュニティダッシュボードによれば、約58.3万REQがバーンされており、元の供給量から見れば小さな割合である。そのため、デフレ効果は存在するものの、それ単体で投資ストーリーの中心になるほど大きな規模ではない。(etherscan.io)

REQの価値蓄積は間接的であり、慎重に解釈すべきである。

ドキュメンテーションでは、リクエスト保存時にREQをロック、ブリッジ、バーンし得るトークンコントラクトおよびバーンメカニズムコントラクトが示されている。またAPIドキュメントでは、API経由で処理される支払いに対して5ベーシスポイント（0.05%）のプロトコル手数料が設定されており、主要なUSDおよびEUR建てステーブルコインについては、おおよそ25ドルまたは25ユーロ程度を上限としていると説明されている。

しかし、これらは一般的なPoSステーキング利回りと同義ではない。Requestは、EthereumがETHバリデーターによるステーキングでセキュリティを確保しているのとは異なり、REQステーキングを通じてプロトコルを直接的に保護しているわけではない。
一部のサードパーティによる説明では、REQのユーティリティを、スパム防止、ガバナンス、ステーキング、割引、独立性といった観点から語るものもあるが、現在の公式技術ドキュメンテーションでは、大規模な流動ステーキング市場、バリデーター報酬スケジュール、REQ保有者向けの恒常的なエミッションプログラムといったものは提示されていない。

最も防御可能なトークノミクスの読み方としては、REQは、供給上限を持ち、利用に応じたバーン要素を備えた「レガシーなユーティリティ／ガバナンス型トークン」であり、短期的なプロトコル利用による価値は、自動的にパッシブなトークン保有者へと還元されるというより、プロダクトレイヤーおよび財団が運営するAPIサービスにより直接的に帰属する可能性が高い、といった位置付けになる。docs.request.network

誰がRequestを利用しているのか？

投機的なREQトレーディングと、実際のRequest Networkユーティリティとの違いは大きい。取引所におけるトークンの出来高は、市場流動性や投資家のローテーションを反映しているに過ぎず、プロトコルの実利用は、作成されたリクエスト数、検知された支払い、支払いボリューム、API採用状況、財務ワークフローへの統合度合いなどで測定する方が適切である。

Request自身の2025年5月のエコシステムアップデートでは、レポート指標の重心を「トランザクション数」から「支払い件数」へと明確に移した。これは、インボイス作成、承認、却下などのアクションが、実際の決済活動を伴わなくてもトランザクション指標を水増しし得るためである。

コミュニティダッシュボードでも、対応チェーン全体の支払いボリュームと支払い件数が報告されているが、これらは日々変動する指標であり、安定したアクティブユーザー数としてそのまま解釈すべきではない。
セクター的に見ると、RequestはDeFi流動性、ゲーム、NFT投機といった領域ではなく、暗号資産決済、ステーブルコイン決済、インボイス、給与支払い、会計、トレジャリーオペレーションの交差点に位置している。request.network

最も説得力のある採用証拠は、匿名ウォレットのカウントではなく、特定できる財務・暗号オペレーション系プロダクトとの統合にある。Requestの 2025年のエコシステムアップデートでは、Animal Social Club、intrXn、0 Finance、Allora、Request Finance などがアクティブなビルダーとして挙げられ、より前のアップデートでは Huma Finance、BSOS、Joba Network その他のエコシステム参加者にも言及されていた。

2025年10月、Kryptos は Kryptos Enterprise 内のインボイス機能を支えるために Request Network API を統合したと発表した。Request はインボイス作成、オンチェーン決済、イベント Webhook、照合機能を提供しており、この発表では Kryptos 自身の導入状況として、20万超の登録ユーザー、初期フェーズにおける 50 超の Web3 企業のオンボーディング、そして数千に及ぶウォレット、CEX、DeFi、チェーンとの統合が示されていた。これらの数字は REQ 保有者による直接利用というより、パートナープラットフォームのスケールとして読むべきだが、根拠のないパートナーシップ噂話よりは、はるかに実質的な内容である。request.network

Request にとってのリスクと課題は何か？

Request の規制リスクは、取引所やレンディングプロトコル、プライバシーミキサーほど直接的ではないものの、ゼロではない。公開検索や検索結果からたどれる SEC の訴状テキストを見るかぎり、2023年に SEC が Coinbase や Binance を提訴した主要訴訟の中で、REQ が名指しのトークンとして挙げられている形跡はなく、2026年5月末時点で Request Network を特定して提起された SEC 訴訟が広く報じられている状況もない。

しかし、それは規制上の「安全地帯」を意味しない。REQ は 2017 年の ICO 期に販売され、現在も二次市場で取引されており、米国の規制当局は、プロトコル開発資金の調達手段として配布されたトークンを歴史的に厳しく精査してきた。

また、このプロトコルの決済ビジネスは、特に Request が暗号資産から法定通貨への決済、ウォレットスクリーニング、法人向け請求書発行をサポートする場面で、AML（マネロン対策）、制裁スクリーニング、KYC、ステーブルコイン規制、送金業規制、税務報告といった論点にも接している。中央集権化リスクも理論上ではなく実務上の問題として存在する。ファウンデーションが運営する API、ダッシュボード、安全な支払いページ、Request Node、決済検知インフラは、たとえコントラクトや SDK、データモデルがオープンソースのままであっても、運用面での依存関係を生みうる。sec.gov

競争環境も厳しい。というのも、Request が解こうとしているユーザー側の課題は、複数の方向からアプローチできるからである。伝統的な決済プロセッサーはステーブルコイン決済を追加しつつあり、中央集権型の暗号資産決済プロセッサーはコンプライアンス、チャージバックポリシー、法定通貨オフランプ、マーチャントダッシュボードを提供できる。ウォレットや取引所は支払いリンクを直接組み込めるし、エンタープライズ向け暗号会計プロバイダーは独自スタックの中にインボイス照合機能を構築することができる。Web3 内部でも、Safe のようなソリューションや Coinbase Commerce 類似プロダクト、マルチシグ財務ツール、給与支払いプラットフォーム、ステーブルコイン決済プロバイダー、オンチェーン会計ダッシュボード、クロスチェーン・ルーティング API などが、それぞれ Request のワークフローの一部を取り込むことが可能だ。

経済的な脅威としては、もし支払いルーティングと照合が「コモディティ化された API 機能」になってしまうと、Request の 5 ベーシスポイントの手数料と REQ 焼却の連動が、価格競争で切り下げられうる点が挙げられる。防御力があるかどうかは、開発者が Request のインボイスオブジェクト、支払い参照標準、照合ツール群を「長期的な統合レイヤー」と見なすのか、「いつでも置き換え可能な利便性ラッパー」と見なすのかにかかっている。docs.request.network

Request の将来見通しは？

Request の短期的なロードマップは、コンセンサスレイヤーの再発明というより、プロダクトの深さに焦点を当てているように見える。2025年および 2026年初頭の信頼できるドキュメントでは、API V2 への移行、クロスチェーンステーブルコイン決済、一括支払い、部分支払い、暗号資産から法定通貨へのワークフロー、定期支払い、手数料カスタマイズ、ウォレットやネットワーク切替の改善、より幅広い決済トラッキング、そして API を通じた 25 以上のチェーン対応が示されている。クロスチェーン決済は特に重要であり、これは実務上の大きな痛点に対処するからである。たとえば支払側は Optimism 上の USDT を保有している一方で、請求書は Base 上の USDC を要求しているかもしれないが、財務チームはブリッジやスワップ、ガストークン、照合作業を手作業で管理したくない。

Request のドキュメントによれば、クロスチェーン決済は USDC (USDC)、USDT (USDT)、DAI (DAI) を対象に、Ethereum (ETH)、Arbitrum One (ARB)、Base、OP Mainnet (OP) 間でサポートしており、ルートは取引手数料と処理速度に基づいてランク付けされる。公開されているクロスチェーン製品ページでは、Request が LI.FI のルーティングを利用しつつ、決済検知と Webhook ロジックを単一化したままにしていると記載されている。request.network

構造的なハードルは「採用の密度」である。Request は Ethereum、Visa、Stripe、あるいはあらゆるステーブルコイン・プロセッサーに「広義で」勝つ必要はない。必要なのは、十分な数のビジネスアプリケーション、会計プロダクト、PSP、クリプトネイティブな財務チームが、そのリクエスト＆リコンシリエーションレイヤーを標準として採用することだ。弱気シナリオとしては、ステーブルコイン決済がウォレットや銀行、取引所 API に直接埋め込まれていき、Request がトークン価値捕捉の乏しい小さなデベロッパーツールにとどまってしまう可能性がある。

強気シナリオは、単なる価格上昇物語よりも控えめだ。もしステーブルコイン決済が拡大し続け、財務チームが監査可能で、非カストディアルで、マルチチェーンな決済記録を求めるのであれば、署名付きリクエスト、支払い参照、Webhook、一括フロー、定期支払い、クロスチェーンルーティングを組み合わせた Request の仕組みは、なお有効なインフラとして残りうる。

したがって、このプロジェクトの将来は、投機的な REQ 需要よりも、Request が長年の運営実績を、持続的なインテグレーション、透明性のある利用指標、そして実際の決済と明確に経済的連動を持つトークンモデルへとどこまで転換できるかに、より大きく依存している。