ソラナの危機一髪：ネットワークが停止（ハルト）に至るまで4.5%のところまで迫った理由
2026年8月12日、ソラナは2024年2月の最後の完全障害以来となる、ネットワーク全体規模の停止に最も近い局面を迎えました——しかし今回は、原因は不具合のあるコードやボットによるスパムとは無関係でした。インターネットの基盤の奥深くにあるルーティング障害が引き金だったのです。
何が起きたのか
BGP（ボーダー・ゲートウェイ・プロトコル）のルーティング障害が、ソラナのバリデータのかなりの割合が利用するホスティング事業者TeraSwitchを襲いました。BGPは、ネットワーク間でデータがインターネット上をどう辿っていくかを決めるプロトコルであり、これが誤動作すると、サーバー自体は正常に稼働していても、インターネット上の地図からサーバー群が事実上消え去ってしまうことがあります。
障害により、約90のバリデータが同時にオフラインとなり、全ステークSOLの28.83%を占めた。
なぜこの数字が重要だったのか
Solanaのコンセンサスには重要な閾値がある。ステークSOLの33.34%が一度にオフラインになると、ネットワークはもはや取引を最終化できず、ブロック生成も完全に停止する。つまり、Solanaの過去の障害で見られたような、調整されたバリデータ再起動が必要になる。
8月12日、ネットワークはその閾値まで4.51パーセントポイントのところまで迫った。あと一歩だったが、Solanaは実際には停止しなかった。
ネットワークが稼働し続けた理由
Solanaのこれまでの主要インシデント――たとえば2022年9月の約8.5時間に及ぶフォーク選択（フォークチョイス）失敗、あるいは2024年2月にBerkeley Packet Filter（BPF）ローダーの再コンパイル・ループが原因で発生した5時間の停止――とは異なり、今回の出来事にはコンセンサスのバグやクライアントレベルの障害は一切関係していなかった。
およそ30〜33分の間：
ブロック生成は中断されることなく継続
取引は滞りなく処理され、通常どおり最終化された
ユーザーの資金が危険にさらされることは一度もなかった
投票を継続したステーク済みバリデータは699中597
これはSolanaの中核プロトコルの欠陥というより、純粋にネットワーク／インフラの問題だったため、影響を受けたルータが再収束すると自然に解消された。緊急パッチも、調整された再起動も、クライアントのアップグレードも不要だった。
真の教訓：インフラの集中
今回のインシデントによって、Solanaの信頼性をめぐる議論が組み替えられた。これまで何年もの間、ネットワークの障害はトランザクションのスパムや、バリデータクライアントのソフトウェアバグが原因だとされてきた。だが今回は脆弱性がインフラの集中――同じホスティング提供者と同じインターネットのルーティング経路に依存するバリデータが多すぎることによって生じたものだった。これにより、ブロックチェーンのコードとは無関係な単一障害点が作られてしまっていた。
これを受けて、Solana Foundationはインフラの多様性に関する規則を厳格化した。2026年5月1日時点で、Foundationの支援を受けるバリデータは次を満たさなければならない：
単一のASN（自律システム／ホスティングネットワーク）がネットワークのステークの25%を超えることはない
単一のデータセンター運営者がネットワークのステークの15%を超えることはない
これらの上限で、今後起こり得るすべての不安が防げるわけではないが、意図としては、ある提供者のルーティング障害が再びコンセンサスを脅かすことがないようにすることにある。
背景：長期にわたる安定の局面
タイミングが注目に値する。この出来事の前、Solanaは2024年2月の最後の完全な障害以来、約30か月連続でクラスター全体の稼働率100%を維持していた――提供開始以来で最長の信頼性の期間だ。8月12日の危機は、実際の停止の連鎖を壊したわけではないが、「稼働率」は単にクリーンなコードだけで決まるのではなく、その下にある物理的・ネットワーク的なインフラにも依存する、という注意喚起になった。
出典：Solana Foundationのステータスレポート。Spotted CryptoおよびBitcoin Foundationによる2026年8月のインシデント分析。
