パケット解析の結果、Clubhouseでは遅延を取り除くためにSD-WANという仮想的にエッジクラウドを一つのネットワークとして扱い、高速でデータ処理をする仕組みを導入していると推定されている。
しかも1つ目の違い「1回あたりのデータ送信量が小さいこと」によって、配送されるパケット（仮想的なデータの箱）の数が通常よりも多くなってしまうため、ハブとなるサーバも通常よりも強力なコンピュータを必要としていると想定される。
この設計は、資金調達が十億円程度で大型調達と言われる日本のスタートアップでは選択することが出来ない戦略である。資金に乏しい企業が選択した場合、あっという間にサーバコストでバーンアウト（資金難に陥ること）するからである。
それだけでなく、資金が潤沢な企業でもユニットエコノミクス（Clubhouseで言えば、ルームあたりの粗利収益性）を悪化させるため、選択が難しい。
こうした遅延の解消は諸刃の剣であるため、あらゆるリアルタイム双方向通信のサービスは遅延とコストの関係に折り合いを付けながらネットワーク設計をしているが、おそらくClubhouseは遅延を減らすことに判断を全振りしていると思われる。
スピーカーとオーディエンスのネットワークを別系統に
ではこの資金を悪化させる仕組みを解決するために、何をしているのか？ これが3つ目の「スピーカーとオーディエンスのネットワークを別系統にしている」という違いである。
遅延を減らすための様々な努力によって、Clubhouseのネットワークは、送信されるデータが増えれば増えるほど、配送先が増えれば増えるほど、コストが指数関数的に肥大化していく構造になっている。
では、この富豪的なネットワーク構造を何の発信もしていないオーディエンスに提供すべきなのか？ 答えは否である。
前述のネットワークは遅延を減少させるために構築しており、遅延の発生が問題になるのはスピーカーだけである。つまり、発信をしていない人にこのネットワークを提供するのは意味がない。
実はこの3つ目の仕組みがClubhouseの大きな強みである。
Clubhouseでは巧みなUXの実現によって、オーディエンスがスピーカーになりにくい構造を作り出している。これは全員参加の会議ツールを由来としているZOOMでは取れない戦略である。下記の図にはClubhouseとZOOMの根本的なネットワーク構造の違いを図示する。
ClubhouseとZOOMの根本的なネットワーク構造の違いの図
Clubhouseでは図中の破線（─ ─ ─）で示した見えない壁、境界線をオーディエンスが超えてくるとコストが上がるため、超えにくくする構造を作っている。たとえば、スピーカーが招待しないとマイクがONにできないなどにしている。一方で、そういったUX設計を露骨におこなうと、オーディエンスが疎外感を感じてしまい盛り上がらない。
このため、ささやくようなしっとりした声質や誰でもルームに入れるオープンさなどで、一体感、親近感を醸成するUX設計をすることで、この見えない境界線を気が付かないようにしていると考えられる。
