Spike OS 深層インタビュー：Web3アプリに超能力を与える、裏方の英雄が描くビジョンと決意
TechFlow厳選深潮セレクト
Spike OS 深層インタビュー：Web3アプリに超能力を与える、裏方の英雄が描くビジョンと決意
Spike OSは、Wab3アプリ向けにプラグ可能な、マルチチェーン対応の「L3」を提供します。
Web3業界の深掘り報道に専念し潮流を洞察
暗号市場は上下に揺れ動く中、「境界を越える」ことこそが依然として議論すべきトピックだ。今日のWeb3アプリケーションたちは、資本市場では一時的に注目を集めることが多いが、現実世界でより多くの外部ユーザーを惹きつけるには至っていない。どれだけの力不足があるか、それと同じだけ解決策も的外れである。
アプリケーションが境界を越えるための真の処方箋はどこにあるのか。大多数は標準的な答えを待ち望んでいるが、一方で、自らの探求の中で答えを創り出そうとする人々もいる。
このほど、TechFlowはSpike OSに独占インタビューを行った。Spike OSとは、Web3アプリケーションにデータの相互運用性とコンポーザビリティを提供するインフラプロジェクトであり、データ共有を通じて、外部ユーザーを惹きつける新たなアプリケーションの組み合わせを可能にするものだ。同社創業者のJeff氏は、現在のWeb3アプリケーションが直面している課題について深く考察し、Spike OSの設計理念、製品アーキテクチャ、今後の展開計画などについて詳しく語ってくれた。
インフラ層の投資機会に関心がある方、あるいは現在Web3アプリケーションを開発している方にとって、今回のインタビューはきっと何かしらの示唆やインスピレーションを与えてくれるだろう。
Section 1：製品設計理念——アプリたちを青い海へ運ぶ舟
TechFlow：Spike OSの構築を始めたきっかけは何ですか？つまり、このアイデアが生まれた契機はなんでしょうか？
Jeff：私たちの出発点は、Web3はより広範なユーザー層にサービスを提供すべきだということです。いわゆる「Massive Adoption（大規模採用）」は、金融分野に限定されるべきではなく、金融従業者専用のツールでもあるべきではありません。
しかし、以前V神が指摘したように、「現時点でのブロックチェーンは金融アプリケーションではうまく機能しているが、非金融アプリケーションも将来有望な方向性だ」というわけです。
現状を見渡すと、成熟した非金融アプリケーションは少なく、業界全体としては真のMass Adoptionからまだ遠い状態です。しかし前回のサイクルでは、NFTやGameFiの登場により、Bored Ape、StepN、Axie Infinityなどのプロジェクトが大量の新規トラフィックを呼び込みました。これらのプロダクトにもそれぞれ問題はありましたが、そこに見られるのは、非金融アプリケーションがなければ市場の成長は見込めず、期待通りに急速に発展することはできないということです。
非金融アプリケーション、たとえばGameFiを例に挙げると、いわゆるAAA級ゲームには特に優れたプロダクトがなく、完全にブロックチェーン上に構築されたゲームも大きな受容層を持っていません。そのため、私たちは新しいWeb3実行環境が必要だと考えています。すべての資産がオンチェーン化され、ユーザー体験に相互運用性を持たせること。アプリ自体も高い拡張性とコンポーザビリティを持つだけでなく、同時に楽しく遊べるものであること。
このような環境があってこそ、より多くの非金融アプリケーションと大規模なユーザーが参入できるようになります。そして現時点では、こうした環境を提供するインフラ層が欠如しており、それが私たちが構築しようとしているものです。
TechFlow：ゲームや非金融アプリケーションに言及されました。Spike OSの主なターゲットはWeb3のゲーム開発者なのでしょうか？他の非金融アプリケーションはどのようにして貴社の製品から恩恵を受けられますか？
Jeff：まず、私たちが提供するのは汎用的で技術基盤寄りのソリューションです。このソリューション自体は、「ゲームとは何か」「アプリとは何か」といった概念を理解しません。
現在の業界では、ゲームとアプリの境界線はますます曖昧になっています。たとえばSandboxは確かにゲームのような画面を持っていますが、その可能性はそれだけにとどまりません。AMAを開催したり、共同オフィスワークをしたり、パフォーマンスやライブコンサートなどを開催できることを考えれば、狭義の「ゲーム」の定義を超えていることがわかります。
したがって、Spike OSも対象を「ゲーム」や「他のアプリ」に限定せず、本質的にはデータの可用性、アプリモジュールのコンポーザビリティ、ユーザーのデータ相互運用性において、未来志向の環境を実現することを目指しています。
もちろん、ゲーム開発者がSpike OSと協力すれば、一般ユーザーの受け入れが早期に進む可能性があります。
TechFlow：現在のWeb3アプリケーションが直面しているデータ可用性、モジュールのコンポーザビリティ、相互運用性の問題は、概念的に抽象的です。具体的な例で説明していただけますか？
Jeff: 具体的な例を挙げると、モジュールのコンポーザビリティと相互運用性を理解しやすくなります。たとえば、Sandboxやいくつかのオープンワールドでは、開発者が作ったゲームが内包されています。
たとえば私がテキサスホールデムのアプリを作り、ゲーム内のカジノに配置するとします。テーブル（NFT）を購入し、そのテーブルで他のプレイヤーを招待してテキサスホールデムをプレイ（ビジネスモジュール）できます。参加者は体験し、ルールに基づいて報酬を分配されます。しかし、あなたがそのテーブルを買った後、そこでブラックジャックや麻雀（別のモジュール）を遊びたいと思っても、既存のアプリやゲームを再開発することはできません。元の開発者がそのような機能を提供するつもりがなかった場合、それは不可能です。
開発者が追加モジュールを提供したいとしても、それを公開するには多大な作業が必要になるでしょう。
したがって、現在のアプリケーションはそもそもモジュール化や組み合わせ可能な特徴を持っていません。これはユーザーにとっても開発者にとっても良いことではなく、双方の利益が損なわれています。より良い状況とは、アプリをモジュール化して開放し、組み合わせ可能にすることです。そうすれば、誰かが作ったシーンに対して、他人が簡単に二次的なイノベーションを加えることができる。これは過去のWeb3やWeb2アプリケーションには欠けていた要素です。
次に、データの相互運用性について。現在、どのアプリケーションを作っても、そのデータは基本的に開発者の私有物です。ユーザーのデータはあなたのサーバーに保存されており、そのサーバーはAWSや阿里雲かもしれません。アプリデータ、ソーシャル関係、メッセージ投稿内容など、すべてが独自のデータベースにあります。
他のアプリケーションがあなたのデータを呼び出すことはできません。APIを積極的に公開しない限り不可能です。
ここでWeb3における新しいシナリオを想像してみましょう。ユーザーの資産は引き続きユーザー自身が所有します。しかし、すべてのアプリケーションのデータはオープンネットワーク上に存在し、アプリ間で自由に呼び出し可能になります。たとえば、あるシューティングゲームAがあり、私のランクがゴールドだとします。新しいゲームが、ゲームAでゴールドランクに到達したユーザーに対し、特別な隠しアイテムやバッジを配布することができます。
アプリ間のデータが自由に呼び出せるようになれば、相互運用性は飛躍的に高まります。もしWeChatがAlipayの信用スコアを取得でき、Xiaohongshu（Little Red Book）がDouyinのフォロワー属性を参照できるなら、このようなデータ共有は業界全体のイノベーションを大きく促進するでしょう。
TechFlow：上述の問題は確かに存在します。すでに市場に解決策はありますか？なければ、Spike OSが先駆者となる根拠と強みは何でしょうか？
Jeff：非常に良い質問です。まず、イーサリアムやEVMの誕生が、すでにコンポーザビリティとデータの相互運用性の問題を解決しているかどうかを見てみましょう。
いわゆる「金融レゴ」のように、Aプロトコルをスマートコントラクトで作り、それを活用して別のアプリBを構築できます。だからこそDeFi Summerが生まれ、今日のCurveやAaveといった成功事例があるのです。
つまり、すべての金融アプリケーションはすでにモジュール化されたコンポーザビリティとデータの相互運用性を活用しています。標準的で単純な金融シナリオにおいて、EVMは革新を果たし、その有効性は証明済みです。しかし、非金融アプリケーションではそうではありません。
非金融アプリケーション、または汎用アプリケーションには、膨大な量の汎用計算が含まれます。ソーシャルシナリオでは音声ストリーム、テキスト、マルチメディアがあります。ゲームにはモデルやエフェクトアニメーションがあり、ユーザーのデータベースにはさらに多次元のデータ特性があります…
このような汎用計算に対して、現在のところ効果的なソリューションはありません。言い換えると、我々はその問題を解決するために、より汎用的な計算を行うEVMのようなものを構築したのです。
今日の開発者はJava、C、Pythonなど異なる言語を使いますが、Spike OSの仮想マシン内では統一されたマシン語形式になり、異なる開発者がこのアーキテクチャを使って自分のモジュールを簡単に作成できます。また、モジュール同士は互いに認識・連携可能です。
私たちのチームは以前、「Oasis」というメタバースプロジェクトを手がけており、2019年に初のOasisエンジンをリリースしました。これは当時、開発者がメタバース向けUGCを作成するためのものでした。
また、Oasis OriginはBNB Chain主催のハッカソンにも参加し、優勝しています。
こうした背景を継承し、今日までエンジン自体をオープンソース化し、データ構造を新たに標準化しながら、徐々に新しいSpike OS製品を構築してきました。
この目標のために、過去3〜4年間で新メンバーを増やし、オープンソースエンジンや低レベル言語に精通した多くの人材を採用し、今日の製品を共に実現してきました。したがって、Spike OSの開発は、過去3〜4年の経験と一致しています。ただし、これを私たちが最も良くできるか、他社ができないかというと、必ずしもそうとは限りません。
今日のブロックチェーンエコシステムでは、ソリューション同士が互いに学び合い、各社が独自の強みを持ち、最終的にはある側面で協力・学習しあうことができます。そのため、Spike OSは最初からオープンソースにしており、その意味もここにあります。私たちの基盤の上に、さらに優れた人がイノベーションを起こしてほしい。イーサリアムが登場した当初、スマートコントラクトは完璧ではなくても、そのオープンソース性とガバナンス構造によって正の外部性が生まれ、より多くのエコシステム開発者が協力しました。
以上が、Spike OSを立ち上げた初衷であり、自信の源泉でもあります。
TechFlow：Web2では、OS（オペレーティングシステム）クラスの製品は構築が難しいことで知られています。Web3でOSクラスの製品を作る上で、最大の困難は何だと思いますか？
Jeff：私たちは実はAndroidシステムの理念を多く参考にしています。Android自体がオープンソースであり、付属の開発環境Android Studioもオープンソースです。そのため、Androidアプリを開発する際、公式エディタを使う必要はなく、そのアーキテクチャを基に改良・アップグレードが可能です。
したがって、最初の困難は、Spike OS自体の技術基盤に問題があるかどうか、つまりバグやエラーなどです。しかし、この種の困難は比較的解決しやすいです。
もう一つの困難は、合意形成とエコシステムの構築です。私たちのソリューションが業界の共通認識となり得るか、より多くのアプリが参加してくれるか、十分な数のアプリが私たちのソリューションを利用するか。これらが次の焦点です。同時に、多くのアプリが参加することで複雑さが増し、システム全体への負荷が大きくなります。こうした複雑性に直面したとき、問題やバグが発生するか、弱点が露呈するかといったリスクもあります。
エコシステムの問題をどう解決するかについては、後ほど戦略に関する話の中で触れます。
Section 2: 製品技術アーキテクチャ——単なる「L3」ではない
TechFlow：Spike OS以前に、Spike Engineもリリースされていますね。これらは異なる製品ですか？どのような関係ですか？
Jeff：Spike OSにはSpike Engineが含まれており、ちょうどAndroid OSにAndroid Studioが含まれているようなものです。
Spike OSについて、以下の3点で定義できます：
第一に、モジュール化され、組み合わせ可能なソリューションである。これは前述のインタビューでも触れました。Spike Engineはこのソリューションの中で、よりモジュール化・コンポーザブルな開発環境を担います。
第二に、オープンで分散型の計算資源システムであり、すべてのデータがオープンネットワーク上に存在する。必要な計算資源は、ネットワークに参加するノードによって提供されます。
第三に、オープンで相互運用可能なユーザー実行環境でもある。現在私たちがAndroid/iOSスマホを使うように、ユーザーにとってはデータ相互運用可能な実行環境として感じ取られます。
TechFlow：Engineは開発環境として、視覚的・触覚的に理解できますが、「OS」という概念は一体どのような形態で存在するのでしょうか？ブロックチェーンなのか、L1やL2の上にさらに重ねる構造ですか？
Jeff：我々はSpike OSを、プラグアンドプレイ可能でマルチチェーン対応の「L3」と考えています。詳細には、アプリケーションが汎用計算を実行するための実行環境です。L1やL2は「帳簿環境」であり、トークンやトランザクション記録などはあくまでオンチェーンの帳簿環境に戻ります。一方、汎用計算はSpike OS内で行われます。
したがって、ETH/Polygon/BSCなどEVM互換チェーンであれば、すべてプラグアンドプレイ可能です。今後AptosやCosmosなどのチェーンに対しても同様の機能を実装していく予定です。
また、ユーザーにとってのOSの存在感はそれほど直感的ではありません。ユーザーが感じるのは、たとえばAアプリに送ったメッセージがBアプリで受信できたり、アプリ間でデータを呼び出せたりすることです。より身近な比喩としては、Spike OSがユーザーに提供するのは、腾讯会议（Tencent Meeting）内で飞书（Feishu）のドキュメントを直接共有できたり、小红书（Xiaohongshu）内で今日投稿された抖音（Douyin）の動画をそのまま見られることです。
ただし、ユーザーのウォレットアドレスや資産は、元のチェーンに帰属します。たとえばD-AppがETH上にある場合、アドレス間の送金や資産のやり取りなどのロジックは、引き続きETHのルールに基づきます。
ユーザーが自分のデータが端末やアプリを越えて利用できることに気づけば、それは大きなイノベーションだと認識するでしょう。しかし、その裏で誰がそれを実現しているかを知っているかといえば、ほとんどのユーザーは気にしないと思います。
TechFlow：Spike OS内部の構造をさらに深く見てみると、ホワイトペーパーにはエンジン、ノード、コントラクト、チェーンなどの要素も含まれています。理解が難しいため、具体例でこれらの要素がどのように協働するか教えていただけますか？
Jeff：もちろんです。まず、あなたが開発者であると仮定し、Spike OSを使用する流れを整理しましょう：
ゲーム開発——Spike Engine：例えば、ステージクリア型ゲームをゼロから開発したい場合、Spike Engineを開き、ジャンプ、移動、スコア、ステージクリアなど、さまざまなモジュールを設定し、コードでその動作を記述します。
モジュール接続——Spike Contract：このゲームには、ユーザーモジュール、資産モジュール、スコアモジュール、ステージモジュールなどが含まれます。モジュール同士は本来「互いを知らない」ですが、キャラクターのインターフェースをステージの復活ポイントに接続したり、スコア結果を次のステージへの条件としたい場合は、Spike Contractを使って接続できます。
計算リソースの需要——Spike Node：従来のゲーム開発では、完成後にサーバー、データベース、レンダリング、チャット機能があれば音声サービスなども購入する必要があります…
Spike OSでは、これは「計算リソース」の購入に相当します。ゲームを完成させたら、publishボタンを押すだけで、Spike Engine内でワンストップでリリースできます。プロトコルアドレス（例：「Spike/ステージクリアゲーム」）が表示され、そのリンクを他人に送れます。スマホゲームならそこからAPPをダウンロードでき、Web版ならブラウザで直接プレイできます。
こうしたサービスを支える汎用計算リソースは、すべて私たちのNodeが提供しており、ゲームのレンダリング、通信、実行、ダウンロード、CDN高速化などを含みます…
TechFlow：上記の計算リソースとノードについて、ハードウェアや時間にどのような要件がありますか？ビットコインシステムでは、フルノードになるにはかなりのコストがかかります。
Jeff：はい、私たちのノードはビットコインや初期のイーサリアムノードに比べてはるかに軽量化されています。イーサリアムはスーパーコンピュータのようなもので、理論的には各ノードがネットワーク全体を検証し、唯一の計算結果を保持する必要があります。
Spike OSのノードはP2P方式で分散されており、たとえば上海でアプリを作成・リリースした場合、近くにいるユーザーがその計算環境を担い、レンダリングや高速化の問題を解決してくれます。
そして、このような作業はネットワーク全体の検証を必要としないため、ノードの負担ははるかに小さくなります。
TechFlow：上記は主に製品設計のアーキテクチャ紹介でしたが、Spike OSの具体的なフロントエンド表示を実際に見せていただけますか？製品の現在の開発段階や実際の表示について非常に興味があります。
Jeff：以下のデモで非常に生き生きとした表示ができます：
-
「Spike/キャンディーパーソン」というリンクを渡せば、そのURLにアクセスしてすぐにゲームをプレイできます；
-
このゲームの開発方法が知りたければ、「Spike/キャンディーパーソン/dev」と入力するだけで、すぐに開発者モードに入れます；
-
すると、「キャラクター—ステージ—アクション—スコア」などのモジュールディレクトリが表示されます；
-
このゲームの「果樹園」ステージを「宇宙」ステージに変えたい場合、自分で作った宇宙ステージをクリックしてアップロードできます；
-
アップロード後、コントラクトコードで宇宙ステージとゲーム本体を連携させ、Gas料金を支払えば、新しいステージを持つキャンディーパーソンゲームの完成です。本質的には軽量なWeb開発インターフェイスです。
TechFlow：この表示は主に開発者向けです。一般ユーザーとして、Spike OSに参加する方法はありますか？ノードとして参加できますか？
Jeff：はい、許可不要のネットワークを目指しており、ユーザーにより多くの参加方法を提供したいと考えています。これはXunlei（迅雷）などのP2Pダウンロードネットワークに似ており、各デバイス自体がノードとなります。ダウンロード中に、他のタスクにアップロードの計算リソースを提供しています。利用者が増えれば増えるほど、シードが増えてノード間の速度も上がります。
技術的に見ても、Spike OSは許可不要のネットワークであり、誰のパソコンやスマホでも参加可能です。たとえば私たち二人がゲームをしているとき、お互いに通信の高速化やレンダリング能力など、一定の計算リソースを提供し合っています。
ただし、ノードとして参加するには初期段階ではある程度の要件があります。オンライン時間、計算結果の速度と正確性など、各ノードに対して評価スコアをつけます。しかし将来的にはより開放的になります。ユーザー数や開発者数が増えれば、ノードも増え、開放性も高まり、最終的には誰でも参加できるネットワークになります。
TechFlow：これらのノードが参加する動機は何ですか？経済的なインセンティブはありますか？
Jeff：主な動機はトークン報酬です。開発者は従来、サーバーを借りる必要があり、毎月数万から数十万、数百万円のコストがかかっていました。現在は代わりにトークンを支払い、Spikeネットワーク内のノードに計算リソースを提供してもらい、アプリの実行に必要なリソースを支えています。
トークンを支払うことで、ノードは貢献した計算リソースの割合に応じてトークン報酬を得ます。エコシステムが大きくなるにつれ、このトークンはガバナンストークンとしても価値が高まっていくため、新たな参加者は報酬を得るためにさらに積極的にノードを提供または参加しようとするでしょう。
また、Spike OSのノードになるには「ステーキング」が必要です。ノードは計算が有効であることを保証しなければならず、個人のせいでネットワーク全体や特定アプリの速度を遅らせてはいけません。そのためステーキングがあり、評価スコアの変化に応じて、ステーキング額や報酬額も変動します。
Section 3：製品導入戦略——対立ではなく協力
TechFlow：ビジネス戦略やプロモーションについて考えたことがありますか？Spike OSは全体的にBtoB色が強く、非常にハードコアですが、どうやってより多くのプロジェクトに認知され、市場に知られるようにするつもりですか？
Jeff：良い質問です。私たちも最近考えていることです。今の答えを出して、市場で議論したいと思っています。成熟したソリューションは、BD（ビジネス開拓）を行い、BtoBでより多くの人に使ってもらうことで目的を達成する必要があります。そのため、Polygon、Avalanche、Near、Aptos、SuiなどのすべてのL1やL2が、数百人のチームを組織して新規プロジェクトを勧誘し、自らのチェーンでアプリを開発してもらおうとしています。
しかし逆に、イーサリアムの初期にはBDがなく、大手プロジェクトや企業をわざわざ勧誘することもありませんでした。なぜ違いが出るのでしょう？個人的には、新しいソリューションが業界内の特定ケースで「これしか使えない」と気づかせ、効率・効果・体験が既存案を大きく上回れば、それは異なるイノベーション曲線上の競争になるというのが鍵だと思います。
顕著な例がICOです。最終的には失敗に終わりましたが、その後誰もがスマートコントラクトとEVMの有用性を認識しました。当時はイーサリアムの構造を通じてのみ、このようなイノベーションが可能だったのです。同様に、Spikeのソリューションでしかできないケースを見つけ、ユーザー体験が非常に良く、開発効率が高く、コストも低い事例を提示したいと考えています。
もし業界が認識するイノベーションが、基盤技術の変化から来ているとわかれば、自ら多くの開発者がエコシステムに参入するようになります。私たちが個別にプロジェクトを探して提携やBDを行うよりも、むしろ本来の目的から逸脱してしまうでしょう。
TechFlow：上記の考え方のもと、具体的にどのような行動を取る予定ですか？たとえば、自らケーススタディを作成したり、開発者向けインセンティブプログラムを提供したりする予定はありますか？
Jeff: はい、3段階に分けます。
第一段階：自ら成熟した、実際にブロックチェーン上で動作するアプリケーションをいくつか作成します。以前手がけたOasisも、実際にはSpikeの方式で開発されています。前述のキャンディーパーソン風ゲームのデモも、公式サイトで公開しています。今後はそのようなゲームを他のチェーンにも展開し、組み合わせ可能なゲームや非金融アプリケーションがどのように見えるかを広く知ってもらいます。
まず私たち自身がSpike OSをしっかり使いこなし、技術的優位性を示す必要があります。
第二段階：主要なパブリックチェーンやL2と協力し、投資やGrantの形で、これらのチェーン上の開発者がSpike OSを使って開発できるように支援します。また、これがETH Denverに参加する理由の一つでもあります。
現地での反応を見る限り、パブリックチェーンの共通ニーズはMass Adoptionであり、新規ユーザーの獲得に注目しています。そのため、新しい開発環境があれば、より多くの娯楽アプリが参入し、外部ユーザーを呼び込めるなら、彼らはオープンで歓迎する姿勢です。また、私たち自身は完全なチェーンを持っていないため、競合ではなく協力関係にあります。
第三段階：Spike OSの優位性が広く認識された後、独自の開発者エコシステムを構築します。Hackathonや投資・インキュベーションを通じて、Spike OSを目的に選んでくる開発者たち
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
