開発者はBaseやRobinhoodのような企業チェーンに参加（入居）するべきですか？

撰文：Jonah

編訳：Luffy，Foresight News

開発者はRobinhoodのパブリックチェーン、またはStripe傘下のTempoのパブリックチェーン上で開発を行うべきでしょうか？ この2つのプロジェクトには、同じ核心となる共通点があります。運営側が、基盤となるパブリックチェーンのプラットフォームを同時に掌握し、さらにチェーン上の流量最大のアプリも握っているのです。

Amazon、Microsoft、そしてCoinbase傘下のBaseチェーンの過去の事例から見ると、この「プラットフォーム＋自社のヘッド部アプリ」一体モデルは、利益相反を生みやすく、入居する開発者に悪影響を及ぼします。開発者は流量の恩恵と引き換えに、プラットフォームの運営による統制リスクを引き受ける一方で、プラットフォームの利益志向は揺れ動くため、その方向性に直面することになります。本稿では、そこにある利益の矛盾、開発者への実際のインパクト、そしてそれに対応するリスク回避策を分解します。

魅力的な売り文句：流量の分配支援

開発者が最初に企業系パブリックチェーンを選ぶ動機は何だったのでしょうか？ 一部のパブリックチェーンは、入居に対して高額の補助金を直接提供します。より多くの場合、パブリックチェーンのコアのセールスポイントは「流量支援」です。CoinbaseのBaseを例にすると、外向きの主要な訴求ロジックはこうです。Baseエコシステムに入居すれば、プラットフォームがCoinbaseウォレットまたはアプリを通じて、開発者のプロジェクトを導いて露出させる。RobinhoodのパブリックチェーンやStripe傘下のTempoも、このロジックを踏襲しています。

理論上は双方にとってのウィンウィンです。ゼロから顧客獲得を始めるのは極めて難しいため、開発者はプラットフォームが元々持っている流量を頼りに素早く冷スタートできます。一方で、パブリックチェーンはプロジェクトの取引から手数料を得られ、さらにプラットフォームがプロジェクトを導線として流入させるなら、追加でプロモーションの取り分まで徴収できるため、開発者の研究開発成果を直接現金化するのと同じ構図になります。

しかし実際には、さまざまな問題が次々と起きます。根本原因は、プラットフォームが生来的に第三者の開発者ではなく、自社のネイティブ製品を優先して支援するからです。Coinbaseは自社の取引所やウォレットにリソースを寄せます。Robinhoodは自社の証券会社やウォレットを優先します。Stripeは自社開発の決済体系を全面的に推します。以下、五つの主要リスクを順に解きほぐします。

リスク1：プラットフォームが前に出て開発者と直接競争する

基盤となるプラットフォームと、チェーン上のアプリを同時に運営する企業が、第三者の開発者を押しのけることは、これまでに大量の資料で裏付けられている「常態」です。『The Wall Street Journal（ウォール・ストリート・ジャーナル）』は、Amazonの経営陣が第三者の販売者の事業データを取り出してヒット商品を選別し、自社の直営競合商品を投入することを明らかにしたことがあります。販売者はAmazonプラットフォームで市場ニーズの検証を行う一方、Amazonは独占データの優位性を武器に、同じ土俵で競争するのです。

もう一つの典型例はMicrosoftとNetscape（ネットスケープ）ブラウザです。NetscapeはWindowsのユーザーに完全に依存していました。するとMicrosoftは、IEブラウザをOSにプリインストールし、競合相手を完全に打ち砕きました。Base、Robinhoodのパブリックチェーン、Tempoといった企業チェーンと、その上に入居する第三者プロジェクトとの間にも、同じ利益相反が存在します。

リスク2：付随するウォレットは単一のパブリックチェーンに紐づかない

ウォレットには、開発者が提供する「そのチェーンのプロジェクト」だけを推す動機がありません。ウォレット製品の競争力は、ユーザーに対して業界全体の暗号資産サービスを開放することにあります。もし単一のパブリックチェーンしか対応しなければ、製品の競争力は大幅に弱まります。ユーザーは多チェーンウォレットへそのまま乗り換えます。したがって、CoinbaseウォレットはSolanaに対応しなければならず、RobinhoodやTempoの付随ウォレットも将来的に同様の互換性への圧力を受けることになります。

つまり、ウォレットは必ず他のパブリックチェーンの資産とアプリを表示することになります。さらにウォレットの最適な製品戦略は、レーン（分野）のトップアプリをそのまま直接組み込むことです。たとえばPhantomウォレットにHyperliquidの無期限先物取引が埋め込まれているように、そのアプリがウォレットの属するパブリックチェーンにデプロイされていなくても成立します。

このロジックは、企業チェーンが売りにしている流量優位をそのまま相殺します。ウォレットは自らの発展ニーズのために、全網から優良アプリを選別して一括で露出させます。自チェーン以外のプロジェクトでも流量を分けてもらえるため、その企業チェーンに入居する際の希少な価値は大幅に目減りします。

リスク3：プラットフォームの競合が開発者の製品を排斥する

その企業と競合関係にある業界プレイヤーは、自らのエコシステム内のプロジェクトを推進する動機がまったくありません。なぜ競合エコシステムを支援するのでしょうか？ USDCは以前、同種の困難に直面したことがあります。背後でCoinbaseに紐づいているため、多くの第三者プラットフォームはこのステーブルコインを上場したがりません。同様に、Robinhoodチェーンにしかデプロイされていないプロジェクトでも、Coinbaseウォレットが自発的に取り込み・推進することはありません。その逆もまた同じです。

リスク4：プラットフォームがユーザーを握り、開発者の利益を分け合う

暗号資産業界には共通の法則があります。終端ユーザーを掌握している側の収益は、プラットフォームに接続するプロトコルよりも通常ははるかに大きくなり、プロトコルの利益を押しつぶし続けて、利益が限界費用に近づくまでになります。私は『価値捕捉のロジック』やAIエージェントの記事でも、この商業モデルについて述べてきました。たとえ開発者が企業チェーンに入居し、プラットフォームが流量支援の約束を実行してくれても、単一プラットフォームへの配信チャネルに完全に依存している時点で、リスクは非常に高いです。プラットフォームはユーザー側の裁量を握り、交渉力が極めて強く、開発者の収益機会を継続的に圧縮してしまうからです。

より確実なルートは、自前で配信チャネルを構築し、第三者プラットフォームは単なる流量の加速器として扱うことです。HyperliquidやPolymarketが典型例です。彼らは直接、独立したユーザー到達チャネルを構築し、そのうえで開発者向けのインセンティブコード（開発者インセンティブコード）によって、自身のプロトコルを各種プラットフォームに展開しています。

リスク5：約束された流量支援が完全に空振りする

プラットフォームが約束する流量露出は、まったく実現されない可能性があります。多くの開発者が「Coinbaseウォレットは長期的にソーシャル機能を優先し、ほぼBaseチェーン内のプロジェクトに露出のためのリソースを与えていない」と不満を吐露しています。Base側は改善すると公式見解を示したとしても、この件自体が証明しているのです。企業の上層部の戦略調整は、そのまま流量支援政策の良し悪しを決めてしまうのだと。

開発者はどう対応すべきでしょうか？

比較してみると、純粋に中立なパブリックチェーンの優位性が際立ちます。イーサリアムやSolanaには、この種のプラットフォームリスクがそもそも存在せず、完全に中立な基盤です。イーサリアムにデプロイする開発者であれば、イーサリアム公式が同種のアプリを投入して自分と競争することを心配する必要がありません。この中立性こそが、長らく過小評価されてきた中核的な強みです。

では、開発者は企業チェーンに入居すべきなのでしょうか？

利益相反によるリスクを緩和する方法として、いくつかの選択肢があります。

プラットフォームが高額の入居補助金を提供する（この方式は公鏈基金会で多く見られ、企業チェーンでは採用が比較的少ない）、開発者は補助金の収益が潜在リスクを上回るかを自ら見極める。

プラットフォームが強硬な書面による約束を提示し、前に出て競争しないこと、流量支援を実行することを保証する（ただし商業史が示す通り、この種の協約の拘束力は非常に弱く、簡単に無効化されやすい）。

自前でリスクを分散する：多チェーンにデプロイ＋自建の流量チャネル。複数のエコシステム選択権を持つだけでなく、自身の利益空間も守ることができる。

この観点から言えば、企業チェーンはプロジェクトの冷スタート期に適しています。プラットフォームの流量を借りて冷スタートを行うことは可能ですが、核心の目標は、長期的にプラットフォームに依存することではなく、自分のユーザーを定着させることです。

現時点では企業系パブリックチェーンのビジネスモデルはまだ初期段階にあります。今後、プラットフォームが既存の矛盾を緩和する方案を打ち出す可能性があり、その一方でまったく新しいリスクも生まれてくるでしょう。