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