ペトル・マリュコフは連続起業家であり、分散型リアルタイム通信ネットワークdTelecomのCEO兼共同創業者である。
表面的には、2025年のWeb3は活況を呈しているように見えた。しかし内実は、煙幕と鏡の世界であることが多かった。ローンチは至る所で行われていたが、持続可能なプロダクトはほとんど存在しなかったのだ。CoinGeckoの推計によると、その年GeckoTerminalで1160万のトークンが失敗しており、これは過去4年間の合計を大幅に上回る数字である。さらに、Web3プロジェクトの99%はキャッシュ収益をまったく生み出していない。つまり、見出しは派手だったが、継続的な利用と安定した収益は依然として稀だったのである。
長年にわたり、市場は希望と、数字を維持するためのトークン報酬、そしてチームがストーリーを売り込むことを可能にした容易な資金調達によって成り立っていた。だが資本の回収は「いつか先」に期待されていた。ところがそれが10年経っても実現しなかったため、要件の変更を余儀なくされた。今、我々はより伝統的なビジネス基準へと向かっている。私が知るVC、パートナー、大手バイヤーは、従来の「Web3的な見栄え」に加えて、収益、継続率、運用体制に注目している。
では、2026年のWeb3企業はどのような状況に置かれているのか。それは岐路に立たされているということだ。ローンチモードに留まり続けるか、継続的な利用と信頼を構築するために動くか。後者を実現する方法を以下に示す。
ローンチだけでなく、継続利用を見据えて構築する
初期のトラクション（牽引力）は成功のように見えることがあるが、多くの人が見落としがちな別の問題を覆い隠していることが多い。ユーザーは一度試すだけで、二度と戻ってこないのだ。そしてマーケティングの勢いが落ち、それに伴ってアクティビティも低下すると、チームは初期ユーザーがなぜ定着しなかったのかを検証するのではなく、次のリリースに注力しがちになる。本来、ユーザーの定着こそが企業にとっての最優先目標であるべきなのに。
まさにここで従来のモデルは破綻する。例えば、プロダクトの主要なセールスポイントが「オンチェーンである」ことだとすると、実際に何を提供するかではなく、手法に重点が置かれてしまう。ほとんどのユーザーはプロダクトがどのように構築されているかなど気にしないし、多くの場合、知る必要もない。本当に重要なのは、それが確実に動作し、安全だと感じられ、摩擦を減らしてくれるかどうかなのだ。
今日のリーダーが注力すべきは、関心を喚起することから継続的な行動を構築することへの移行である。サインアップ後の最初のインタラクションはシンプルで予測可能であるべきであり、何か問題が起きた際のリカバリープロセスも分かりやすくなければならない。同じ論理はシステム運用にも当てはまる。モニタリング、ログ記録、インシデント報告──これらすべてが理解しやすく設計されているべきである。
コンプライアンスをプロダクトアーキテクチャに組み込む
多くのWeb3企業は今でもコンプライアンスを「後から足すもの」として扱っている。大手クライアントが要求してから、あるいは新市場に参入してから対応すればいいと考えているのだ。このアプローチは普及を妨げる。なぜなら、伝統的な企業は「Web3」を買うわけではないからだ。彼らが求めているのは、信頼性、品質、そして既存のリスク管理基準に適合するワークフローである。ここでの重要な要件は、機能すること、そしてそれを証明できることだ。
だからこそ、コンプライアンスはプロダクトアーキテクチャの不可欠な部分でなければならない。誰が何をできるか、ユーザーが行動する前に何を証明しなければならないか、何がブロックされ、何が記録され、誰が後でレビューできるかを定義するのがコンプライアンスである。また、データ処理、権限、決済、サポート手順、チームのインシデント対応も規定する。これらの仕組みが最初から欠けていると、チームはプレッシャーの中でコアフローを再構築せざるを得なくなる。
実際には、普及は目に見えるコントロールと予測可能な運用に依存する。モニタリング、ログ記録、監査証跡、強制的な制限、明確な責任者、そしてストレス下でも機能するエスカレーションパスなどだ。大手バイヤーは、システムがオンチェーンかオフチェーンかに関係なく、利用を拡大する前にこれらの要素を期待する。
Web3は、その強みをエンタープライズが利用できる形で活用すれば、ここで力を発揮できる。一部の設計では、デフォルトでより強力な透明性と検証可能性を提供している。また、ゼロ知識証明（データの内容を開示せずにその正当性を証明する暗号技術）のようなツールは、コンプライアンスチェックを可能にしながらプライバシーを確保できる。これらの利点は重要だ。運用リスクを軽減し、監査を容易にしながら、ユーザー体験は馴染みのあるものに保つことができるからである。
スケールする前にレディネステストを実施する
レディネステストは、「さあスケールしよう」が「火消しに追われる」状態に陥るのを防ぐ最後の関門である。私はキャリアを通じてこれらの教訓を学んできたが、すべてのプロジェクトでチェックリストとして活用している。
ビジネス上の課題から始める
プレゼンテーションの最初の5分間がトークンや「オンチェーン」についてであれば、そのチームはおそらくクライアントを失うだろう。私の経験では、プロダクトが解決する課題、軽減するリスク、クライアントが測定できる成果から話を始める方が理にかなっている。暗号資産用語なしでプロダクトの価値を説明できないなら、顧客を探し続けることになる可能性が高い。
ユーザーにとって馴染みのある形を保つ
ほとんどの企業はすでにアクセスとコントロールに関する習慣的なルーティンを持っており、あなたのプロセスのためにそれを変えることはない。クライアントがメールログイン、ロール、承認、シンプルなリカバリーを期待するなら、それを提供すべきだ。Web3は舞台裏に置き、ワークフローを改善する場合にのみ表に出すようにする。
サービスとして運用する
サポートはチャットでの約束であってはならないし、「調査します」はインシデント対応計画ではない。企業には責任者、対応時間、問題発生時の明確なエスカレーションパスが必要だ。そうすれば、インシデントが発生した際に、チームは平易な言葉で問題を説明し、自分たちの対応で何が変わったかを示すことができる。
結論として、Web3が勝利するのは、市場に信じることを求めるのをやめ、信頼する理由を提供し始めたときだけである。2025年、我々はローンチしても失敗することがいかに容易かを目の当たりにした。次の勝者は表面的には平凡に見えるかもしれないが、本物のサービスのように構築されているだろう。使いやすく、壊れにくく、監査に対応でき、継続的なインセンティブなしに収益を上げられるサービスとして。
