以前、人が集まる3D空間は「使われるほど重くなる」という構造の話を書きました（メタバースは死んでいない。「無料で場を貸す」モデルが終わっただけだ）。普通のWebサービスとは逆で、同じ部屋に人が集まるほどコストが膨らんでいく。だから「広く無料で貸す」モデルは苦しくなる、という話でした。
あのときは、業界の出来事を外から眺めて書きました。今日は同じテーマを、もう少し近いところから書きます。というのも、その「重くなる」という構造に、私たち自身が実際にぶつかったからです。2026年6月のはじめ、私たちが運用するメタバース rezona のサーバーが、応答できなくなって自動で作り直される、という事態を起こしました。きれいな成功談ではありません。けれど、自分たちで起こした障害だからこそ、原因の手前まで掘り下げて学べたことがあります。それを書き残しておきたいと思います。
なぜ、人が増えるほど重くなるのか
まず、前回の話を少しだけ具体的にしておきます。
人が同じ空間に集まってリアルタイムに動く3Dワールドでは、一人ひとりが「いま自分はここにいて、こちらを向いて、こう動いている」という情報を、その場にいる全員に向けて伝え続けます。受け取る側も、全員ぶんの動きを絶えず受け取り続けます。音声も同じで、誰かの声を、その場の誰にも届けなければなりません。
ここで効いてくるのが、人数の増え方と負荷の増え方が一致しないことです。部屋に2人いれば、伝え合う線は1本で済みます。3人なら3本、4人なら6本。人が一人増えるたびに、つなぐべき線はそれ以上の勢いで増えていきます。みんながみんなに伝え合う、いわば総当たりに近い形になるからです。10人を超え、20人を超えてくると、この差はじわじわと、しかし確実に効いてきます。人数は足し算なのに、負荷は掛け算に近い増え方をする。これが、3D空間が「集まるほど重くなる」ことの正体です。
詰まりが詰まりを呼ぶ ――「輻輳崩壊」
2026年6月のはじめに起きたのは、この重さが臨界を越えたときに何が起きるか、という出来事でした。
きっかけは、サーバー側の処理が少しずつ詰まりはじめたことです。混んだお店のレジに、行列ができはじめる様子を想像してください。問題は、ここから先でした。
レジが詰まって応答が遅れると、待っているお客さん――この場合はそれぞれの利用者の端末（クライアント）――が「返事がないな、届かなかったのかもしれない」と判断して、同じ要求をもう一度送り直します。これ自体は、通信が不安定なときに備えた、ごく普通の仕組みです。けれど、すでに詰まっている行列に、同じ注文がもう一枚、また一枚と追加されていくとどうなるか。行列はますます伸び、応答はさらに遅れ、遅れるからまた送り直される。この「送り直し（リトライ）が、かえって詰まりを深くする」悪循環が回りはじめました。
専門的には、これを「輻輳崩壊」と呼びます。輻輳とは、ものが一か所に殺到して詰まる状態のこと。崩壊というのは、その詰まりが自分で自分を悪化させて、止まらなくなることです。最後にはサーバーが応答そのものを返せなくなり、自動の仕組みによってまるごと作り直される、というところまで行き着きました。
正直に書いておくと、当時のサーバーが控えめな構成――つまり、それほど強くないCPUとメモリの、小さな一台――だったことも効いていました。余力が小さいほど、行列はあっという間に限界に達します。
ログに「失敗」と残らない障害
この出来事でいちばん学びになったのは、原因をどうやって突き止めたか、でした。
困ったことに、こういう詰まりは、ログに「エラーが起きました」とはっきり残ってくれるとは限りません。一つひとつの処理は、最終的には（遅れながらも）こなされていたりするからです。記録だけを後から眺めても、「特に失敗はしていないのに、なぜか全体が応答しなくなった」という、もやのかかった状態に見えます。
手がかりは、ふたつの時間の食い違いにありました。
私たちは、サーバーの「入口」にあたる場所――受付係のようなもの（プロキシと呼びます）――が計った応答時間と、その奥でアプリ自身が計った処理時間の、両方を記録していました。本来この二つはおおむね一致するはずです。ところが障害のあいだ、入口が計った時間だけが大きく膨らんでいました。奥の処理そのものはそれほど時間がかかっていないのに、入口での待ち時間だけが伸びていた。これは、詰まりが処理の中身ではなく、その手前の「行列」で起きていたことを意味します。レジ係の手際が悪いのではなく、店の前の行列が伸びていた、という指紋です。
もうひとつの物証は、瞬間的にサーバーの台数がゼロに落ちる「谷」が記録に残っていたことでした。先ほどの「応答できなくて作り直される」瞬間です。ログに失敗の文字はなくても、この谷だけは隠せませんでした。
ここで言いたいのは、ひとつだけです。これらは、観測していなければ気づけませんでした。二つの時間を別々に計り、台数の推移を見ていたからこそ、もやの中から指紋を拾えた。記録がなければ、「なんとなく重かった」で終わっていたはずです。
そしてこれは、後から思いつきで足せるものではありません。障害は、予告してから起きてはくれません。起きたその瞬間に、入口と奥の時間が両方そろって記録されていなければ、食い違いそのものが存在しなかったことになります。私たちが今回、原因の手前まで辿れたのは、平時から地味に観測の仕組みを敷いておいたからにすぎません。派手な手柄ではなく、ただ準備が間に合っていた、というだけのことです。逆に言えば、準備していなければ、同じ障害でも「原因不明」で終わっていました。観測とは、問題が起きてから慌てて見るものではなく、起きる前から黙って計り続けておくものなのだと、今回あらためて思い知りました。
手当てと、これからの地図
原因の見当がついたら、次は手当てです。
まず効くと考えたのは、悪循環の入口にあたる「送り直しの増幅」を抑えることでした。利用者の端末側に、いくつかの手当てを入れました。同じ要求を立て続けに何度も投げないよう、重なった要求はひとつに束ねる。返事が遅くても、むやみに送り直さない。そして、その画面が実際には見られていないとき――たとえば別のタブに切り替えられているとき――は、通信そのものを控える。どれも派手な変更ではありませんが、行列に余計な注文を積み増さないための、地味で確実な手当てです。
それと並行して、もっと先を見据えた「地図」も引きました。人が増えても音声を支えられるようにするための、設計の道筋です。
ひとつは、部屋ごとにサーバーを分ける案。みんなが一台に殺到するのではなく、行き先を分散させる考え方です。もうひとつは、近くにいる人の声だけを受け取る案。広い会場でも、実際に会話するのは隣の数人です。全員ぶんを律儀に配り続けるのをやめれば、負荷はぐっと下がります。さらに、何百人も集まる巨大なライブのような場面に向けて、観客を複数のまとまりに切り分ける案――シャーディングと呼びます――も描いています。一枚の大きな紙を、複数の小さな紙に分けて受け持つようなイメージです。
これらはまだ地図の段階で、すべてを引き終えたわけではありません。それでも、どこから重くなり、どこを分ければ支えられるのかが見えていることは、行き当たりばったりに対処するのとはまるで違います。
うまくいっている面も、正直に
ここまで失敗の話を続けてきたので、釣り合いを取るために、うまくいっている面も正直に書いておきます。
少し前に開いたあるルームツアーでは、私たちの想定の約2.4倍――20数名の人が同時に同じ空間に集まりました。総当たりに近い負荷が効いてくる、まさに「集まるほど重くなる」人数帯です。けれど、このときは大きな問題もなく捌けました。参加した方々の体感の満足度も、低くはありませんでした。
このとき何が支えになったのかを、後から振り返ってみました。ひとつは、その場の人数や演出が、総当たりの負荷が爆発するほどの臨界には、まだ届いていなかったこと。もうひとつは、想定の倍を超える人が来るかもしれないという前提で、あらかじめ余裕を見ていたことです。逆に言えば、もう少し人が増えていたら、あるいは余裕を削っていたら、ルームツアーでも同じ壁にぶつかっていた可能性は十分にあります。うまくいったのは運がよかったからではなく、かといって万全だったからでもなく、その中間――「いまの設計が支えられる範囲に、たまたま収まっていた」という、ぎりぎりの成功でした。
だからこそ、この成功を過信するつもりはありません。つまり、私たちの場が常に壊れているわけではありません。設計と観測でちゃんと支えられる範囲は、確かにあります。そしてその範囲は、今回のような障害から学ぶたびに、少しずつ広がっています。限界はあります。けれど限界の位置が分かっていて、その先へ伸ばす地図を持っていることこそが、運用するということなのだと思います。
自分の土地で転ぶということ
最後に、前回の話につなげて締めたいと思います。
「使われるほど重くなる場所」は、いつか必ず重さの壁にぶつかります。これは避けようがありません。問題は、その壁にぶつかったとき、何ができるかです。
今回、私たちは確かに障害を起こしました。けれど、それを自分ごととして観測し、二つの時間の食い違いという指紋まで掘り下げ、増幅を抑える手当てを自分の手で入れ、その先の地図まで引くことができました。これは、自社で運用している場所だからこそできたことです。
もし他人の土地の上に場を借りているだけだったら、ここまではできません。サーバーの入口と奥で別々に時間を計ることも、台数の谷を物証として読むことも、送り直しの仕組みに手を入れることも、自分の都合では選べない。重さの壁にぶつかったとき、ただ「重いですね」とこぼすしかなくなります。
前回、私たちは「簡単には消えない、自分でコントロールできる場をつくりたい」と書きました。今回ぶつかった障害は、その判断のもうひとつの意味を教えてくれました。コントロールできるというのは、うまくいくときに自由が利く、というだけの話ではない。転んだときに、なぜ転んだのかを自分で確かめて、自分で立ち上がれる、ということでもあるのです。
Boundary LAB は「境界を越える体験を設計する」会社です。自社ホスティングのメタバース rezona を運営しています。空間づくりのご相談は X（@shuuuuuuvuu）の DM へ。私たちについては Boundary LAB について もどうぞ。