a16zインタビューの要約：なぜオープンネットワークは常に勝つのか？

最近、a16zでシンプルなテーマのインタビューを見ました：なぜオープンネットワークが勝つのか（Why open networks win）。このインタビューでは、現実的な命題について議論されています：グローバルなネットワークを構築するなら、最終的に解決すべきはパフォーマンスではなく信頼の問題です。

クリスチャン・カタリーニがこのインタビューの中心人物です。彼はLibraのコアメンバーであり、Lightsparkの創設者でもあります。録音の中で彼は非常に鋭くも的確な言葉を述べています：もしあなたが金融システムを改革したいなら、誰もあなたのコーポレートチェーン（企業チェーン）を信用しない。コーポレートチェーンは、ネットワークの支配権、アップグレード権、利益分配権が特定の企業や連合の手に集中していることを示しており、そのため外部からは内部の利益に奉仕していると見なされがちです。

多くの人はLibraの失敗を規制のせいにしますが、クリスチャンは異なる「真実」を示しています。彼は、規制の影響は確かに大きいが、それだけが問題ではないと指摘します。より重要なのは、市場が「中立的な通貨ネットワーク」を企業が作れると信じていないことです。たとえ協会を設立してガバナンスを行い、CEOが独立して運営していても、外部の人々は同じ推論をします：リーダーが去った瞬間、ネットワークは血を流すだろうと。 この推論は本質的にFacebookに対するものではなく、「企業チェーン」という組織形態に対するものです。

そのため、彼はますますビットコインに惹かれるようになっています。彼は、ビットコインは「最も技術的に進んだ」解決策ではないと考えています。ビットコインの開発は非常に苦痛で、まるで宇宙で車を作るようなものだと。しかし、企業が再現しにくい要素がある。それは、中立性が歴史によって証明されているということです。創始者が姿を消し、許可不要の参加が可能で、ルールの一方的な書き換えが難しく、ガバナンスも一点に集中しにくい。だからこそ、「グローバルな価値移転」のような高い信頼性を求められる用途に適しているのです。この論理は、「コードの良し悪し」から「誰を信頼できるか」へと議論をシフトさせます。

この議論の中で、クリスチャンはより商業的な判断も示しています。企業チェーンの最大のパラドックスは、「第二位の企業」をネットワークに誘い込むことは決してできないということです。例えば、あなたが最大の決済会社であった場合、なぜ第二位の決済会社はあなたに命を預ける必要があるのでしょうか？また、あなたがステーブルコインの発行者であれば、なぜパートナーはあなたが下流に拡大して利益プールを飲み込むことを信じるのでしょうか？この問題はWeb2の世界ではよく見られるものです。ネットワークが利益を抽出できる状態になると、コントローラーは利益最大化のインセンティブを持つのです。

したがって、クリスチャンはこう判断します。短期的には新たな閉鎖型ネットワークや「企業チェーンの支配」段階が出現するかもしれません。しかし、長期的には資金は必ずオープンネットワーク上を流れると。

この議論は、以前私が書いたエッセイ**「Web3起業探討：暗号プロジェクトは本当にオープンソースにすべきか？」**を思い出させます。その中で、私は二つの力の引き合いについて焦点を当てました。オープンソースは信頼を築くことができる一方で、コピーのリスクも伴います。オープンソースはWeb3の基盤ですが、すべてのチームが完全にオープンにするコストを負担できるわけではありません。また、UniswapとSushiSwapの例を用いて、コピーは珍しくなく、競争優位性はコードだけに由来しないことも示しました。

今回のa16zの議論は、より深い補足を提供しています。それは、「オープンソース」の意味を中立性の声明のような性質に再定義している点です。しかし実際には、たとえチームがコードを公開しても、それだけで自動的に中立性を獲得できるわけではありません。市場が中立性を判断するときに重視するのは、GitHubのコードではなく、コントロールの所在です。

では、「中立性」とは何か、どうすれば中立でいられるのか？Portal Labsはこれを大まかに三つの実用的な次元に分けています。

1. ルールの中立性

ルールの中立性は、重要なルールが一方的に書き換えられるかどうかに関わります。契約の手数料、清算、凍結、権限、アップグレードなどの条項が少数の人間によって変更可能であれば、そのシステムは公共インフラとみなされにくくなります。ルールの中立性は、「完全にアップグレード不能」である必要はありません。重要なのは、アップグレードの権利に境界線があり、その境界が外部から制約されうることです。この次元は、「いつでもルールを変えられるか？」という問いに答えます。

2. アクセスの中立性

アクセスの中立性は、エコシステムの入り口が誰にとっても開かれているかどうかに焦点を当てます。統合に許可が必要か、インターフェースはいつでも撤回可能か、ノードや検証者は承認を必要とするか、重要なリソースは自社だけに限定されているか、これらがネットワークが公共の道路か私的なキャンパスかを決める要素です。アクセスの中立性は、閾値がないことを意味しません。閾値を恣意的に引き上げることができないことが重要です。この次元は、「他者は自由に参加できるか？」という問いに答えます。

3. 利益の中立性

利益の中立性は、価値の分配がコントロールによって歪められるかどうかに関わります。権限を使って取引を自社の製品に誘導できるか、重要なタイミングで利益分配を変更できるか、特定のパートナーに特別待遇を与えられるか、エコシステムの利益を会社のキャッシュフローに集中させられるか。これらの答えが頻繁に「はい」になると、市場はあなたをネットワークではなくプラットフォームとみなします。この次元は、「ネットワークをATMに変えるのか？」という問いに答えます。

実際には、これら三つの基準は最終的に同じWeb3起業の判断に帰着します：「あなたは“分散型製品”を作っているのか、それとも“分散型ネットワーク”を構築しようとしているのか？」。製品の目的は効率とコントロールです。一方、ネットワークの目的は信頼性と参加のしやすさです。両者は共存可能ですが、優先順位は異なります。Web3起業家が本当にやるべきことは、まず自分のポジショニングを明確にし、その後に中立性とオープンソース戦略を決めることです。

この点について、Portal Labsは自己診断のためのシンプルな質問セットを提案しています。

Q1：あなたのシステムは、誰でも許可不要で統合・展開できるものですか？

もし「いいえ」なら、あなたは製品に近いです。この判断は、多くの「疑似ネットワーク」を排除できます。

Q2：あなたの主要なルールには、緊急の片側スイッチ（凍結、ロールバック、強制アップグレードなど）がありますか？

もし「はい」なら、その権限がどのように制約されているかを説明する必要があります。この質問はルールの中立性に直結します。

Q3：あなたのエコシステムの入り口は、あなたが提供する唯一のインターフェースや唯一の順序に依存していますか？

もし「はい」なら、あなたはプラットフォームをやっていることになります。この質問はアクセスの中立性に直結します。

Q4：あなたは競合他社があなたのシステム上で利益を得ることを許可し、そのルールによる抑圧を受けていませんか？

もし「いいえ」なら、あなたは公共ネットワークにはなれません。この質問は利益の中立性に直結します。

これらの質問に答えが出たら、オープンソースはより合理的なエンジニアリングの決定となります。もちろん、オープンソースには階層があり、二者択一ではありません。

第一層は検証可能なオープンソースです。チームは主要な契約やセキュリティに関わるコードを公開し、外部による監査や再現性を確保します。この層は透明性と信頼性を高めますが、ビジネスの完全なコントロールを放棄する必要はありません。多くのツール型製品はこのレベルで十分です。この層は「他人に自分が悪いことをしていないと信じてもらいたい」という意味合いです。

第二層は代替可能なオープンソースです。チームは自分たちのキー運用をロックせず、第三者がフォークして運用できる状態を許容します。この層は競争圧力を生み出しつつ、検閲耐性や持続性も高めます。これは「私は独占的な運用権に依存していない」という意味です。

第三層は撤退可能なオープンソースです。チームは段階的にアップグレードやガバナンスの権限を委譲し、自分たちの重要性を薄めていきます。ビットコインはこの極端な例ですが、現実には中間的な状態も存在します。イーサリアムは調整や監査を必要としますが、そのガバナンスは長期的に進化する公開プロセスに近く、企業の規約のようなものではありません。オープンネットワークはガバナンスを持ちますが、それは特定の企業のものではありません。

表面的には、オープンネットワークの議論は「オープンソースにすべきかどうか」の議論に見えますが、実際には中立性の議論です。一度コントロールが集中すると、二番手は参加しなくなり、エコシステムは公共の基盤にならず、最終的には単なる製品の域にとどまります。

したがって、Web3の起業家にとって、オープンソースは製品の一形態の選択です。どの程度オープンにするか、どの権限を手放すか、どれだけ制御不能な状態を受け入れるかを決めることで、最終的にプラットフォーム型の製品になるのか、オープンなネットワークになるのかが決まるのです。

これを理解すれば、オープンソースの問題はむしろシンプルになります。あなたは「オープンソースにするかどうか」を決めているのではなく、「ネットワークになるかどうか」を決めているのです。