本記事公開時点、Amazon Web Services(AWS)は再び暗号資産インフラに重大な障害を発生させています。本日8:00(英国時間)頃、米国東部(US-EAST-1、ノースバージニアデータセンター)で発生したAWSの問題により、Coinbaseをはじめ、Robinhood、Infura、Base、Solanaなど主要な暗号資産プラットフォームが多数ダウンしました。
AWSは、Amazon DynamoDBおよびEC2(多くの企業が依存する主要なデータベース・コンピューティングサービス)において「エラー率の上昇」が発生していることを認めました。今回のリアルタイム障害は、本記事の主張を直ちに裏付けています。つまり、暗号資産インフラが中央集権型クラウドプロバイダーに依存していることが、ストレス時に繰り返されるシステム上の脆弱性となる。
今回のタイミングは非常に示唆的です。19,300,000,000ドル規模の強制清算連鎖によって取引所インフラの障害が明るみに出てからわずか10日後、今回のAWS障害は問題が個別プラットフォームを超えて、基盤となるクラウドインフラ層に拡大していることを示しています。AWSが障害を起こせば、中央集権型取引所や「分散型」プラットフォーム(中央集権的な依存関係を持つもの)、その他多数のサービスに連鎖的な影響が一斉に及びます。
これは単発の事例ではなく、繰り返されるパターンです。以下の分析では、2025年4月、2021年12月、2017年3月にも同様のAWS障害が発生し、いずれも主要な暗号資産サービスを停止させています。次のインフラ障害は「発生するか」ではなく、「いつ・何が引き金になるか」が問われています。
図1:2025年10月 強制清算連鎖のタイムライン
インタラクティブなタイムラインチャートは、時間ごとに強制清算がどのように進行したかを劇的に示しています。最初の1時間で60億ドルが消失し、続く2時間目にはさらに激しい清算が加速しました。可視化のポイント:
図2:過去の強制清算イベント比較
棒グラフ比較は、2025年10月の規模が突出していることを示しています:
CEXは強制清算通知を1秒に1注文へスロットルしていますが、実際には毎秒数千件の処理が必要です。10月の連鎖時、これが情報の不透明化を招きました。ユーザーはリアルタイムの連鎖の深刻度を把握できず、サードパーティ監視ツールは毎分数百件の清算を示しているのに、公式フィードは遥かに少ない件数しか報告していませんでした。
APIレート制限によって、トレーダーは最初の重要な1時間にポジション変更ができませんでした。接続要求はタイムアウトし、注文送信は失敗、ストップロス注文も不発。ポジション照会は古いデータしか返しません。このインフラボトルネックが市場イベントを運用危機へと変質させました。
従来型取引所は通常負荷に加え安全マージンでインフラを供給しますが、通常負荷とストレス負荷は大きく異なります。平均日次取引量はピークストレス時の需要を予測するには不十分です。連鎖時には取引量が100倍以上に急増し、ポジション照会は1,000倍に増加。ユーザー全員が同時に口座を確認するためです。
図4.5:AWS障害による暗号資産サービスへの影響
自動スケーリング型クラウドインフラは一定の支援をしますが、即応は不可能です。データベースのリードレプリカ追加やAPIゲートウェイ新規インスタンス構築には数分を要します。その間にも、マージンシステムは過負荷状態の板から取得した価格データでポジション評価を継続します。
図3:オラクル操作フロー図
インタラクティブなフローチャートは、攻撃ベクトルを5段階で可視化します:
清算がさらなる売りを同一の流動性の低い市場に誘発し、価格はさらに下落。マージンシステムはこれら低価格を観測し、さらに多くのポジションを減価。フィードバックループが6,000万ドルの売り圧力を19,300,000,000ドルの強制清算へと増幅しました。
図4:強制清算連鎖フィードバックループ
循環型フィードバック図は、連鎖の自己強化構造を示しています:
価格下落 → 清算発動 → 強制売却 → さらなる価格下落 → [サイクル反復]
このメカニズムは、適切に設計されたオラクルシステムなら発生しません。Binanceが複数取引所の時間加重平均価格(TWAP)を採用していれば、一時的な価格操作は担保評価に影響しません。Chainlink等のマルチソースオラクルで集約価格を使っていれば、攻撃は失敗していたでしょう。
4日前のwBETH事件でも類似の脆弱性が露呈しました。Wrapped Binance ETH(wBETH)は本来ETHと1:1で交換可能ですが、連鎖時には流動性が枯渇し、wBETH/ETHスポット市場で20%割引となりました。マージンシステムはwBETH担保を減価し、実際にはETHで十分担保されていたポジションも清算対象となりました。
10月の連鎖時、Binanceは複数ペアでADLを発動しました。利益が出ていたロングポジションのトレーダーは自らのリスク管理不備ではなく、他のトレーダーのポジション破綻により強制決済されました。
ADLは中央集権型デリバティブ取引の根本的なアーキテクチャ選択を反映します。取引所は損失を出さないことを保証し、損失は以下のいずれかで吸収されます:
10月の連鎖後、BinanceはBTC、ETH、BNB USDⓈ-M契約でオープンインタレストが40億ドル未満ならADLを発生させない保証を発表しました。これにより、取引所はより大きな保険基金を維持するインセンティブを得ますが、資本の効率的活用とのトレードオフが生じます。
図5:主要ネットワーク障害 – ダウンタイム分析図5詳細:Solana障害(2月5時間、9月4.5時間)は、ストレス下でのネットワーク耐性の課題を繰り返し示しています。
Solanaのアーキテクチャはスループット重視で設計されています。理想条件下では3,000~5,000件/秒のトランザクションをサブ秒でファイナリティまで処理します。これはEthereumを大きく凌駕しますが、ストレスイベント時にはこの最適化が脆弱性にもなります。
2024年9月の障害は、スパムトランザクションがバリデータの投票メカニズムを圧倒したため発生。バリデータはブロックの合意形成のため投票を行います。通常時は投票トランザクションを優先し、合意形成を進行させますが、プロトコルは以前、投票トランザクションを通常トランザクション同様に手数料マーケットで扱っていました。
メンプールがスパムで埋まると、バリデータは投票トランザクションの伝播に苦戦。十分な投票が得られず、ブロック確定できず、チェーンが停止。保留中の取引はメンプールに留まり、新規取引も送信できません。
StatusGatorはSolanaのサービス障害を2024~2025年に複数記録していますが、Solana公式は障害として認定されていません。情報が非対称となり、ユーザーはローカルの接続問題とネットワーク全体の障害を区別できません。第三者監視サービスは一定の透明性を提供しますが、プラットフォームは包括的なステータスページの維持が望まれます。
図7:ネットワークストレス時の取引コスト
この折れ線グラフは、ストレスイベント時の各ネットワークでのガス手数料の急騰を明確に示しています:
Maximal Extractable Value(MEV)は、バリデータが取引順序の操作等で抽出可能な利益を指します。高ガス環境ではMEVが特に有利となり、裁定取引者がDEXでの大型取引のフロントラン競争を、清算ボットがアンダーコラテライズドポジションの優先清算競争を繰り広げ、ガス手数料の入札合戦に発展します。
混雑時に取引を確実に成立させたいユーザーは、MEVボットより高い手数料を支払う必要があります。これにより、取引手数料が取引額を上回る事態も発生します。100ドルのエアドロップ獲得に150ドルのガス代、清算回避のための担保追加に500ドルの手数料競争などです。
Ethereumのガスリミットはブロックごとの計算量上限です。混雑時はユーザーが限られた枠を手数料で競り合い、高額入札者が優先されます。設計通りに機能しますが、利用需要が高まるタイミングでネットワークコストも最大化され、ユーザーが最もアクセスを必要とする時に利用困難となります。
Layer2は計算をオフチェーン化し、EthereumのセキュリティをL1決済で継承することでこの問題の解決を目指しました。Optimism、Arbitrum等のロールアップは数千の取引をオフチェーン処理し、圧縮証明をEthereumへ提出。通常時の取引コスト低減に成功しています。
この障害で、計算のオフチェーン化だけではインフラ要件が消えないことが示されました。シーケンサーは取引受信・順序付け・実行・不正証明やZK証明生成など多層処理が必要です。極端なトラフィック下では、独立型ブロックチェーンと同様のスケーリング課題に直面します。
複数RPCプロバイダーの冗長性も不可欠です。主要プロバイダーが障害時は、ユーザーが自動的に他プロバイダーへ切り替えられるべきです。Optimism障害時、稼働中のプロバイダーも存在しましたが、ウォレットが障害プロバイダーにデフォルト設定されたユーザーはチェーン自体が正常でも取引できませんでした。
AWS障害は、暗号資産エコシステム全体のインフラ集中リスクを繰り返し示しています:
図5詳細:Polygon障害(11時間)は分析対象インシデントの中で最長であり、コンセンサス障害の深刻さを浮き彫りにしています。
バリデータ間で正しい状態認識が分岐し、コンセンサスが成立せずチェーンは新しいブロックを生成できません。旧バージョン稼働バリデータは新バージョンのブロックを拒否し、新バージョン側も旧バージョンブロックを拒否。これによりデッドロックが発生しました。
復旧にはバリデータの協調アップグレードが必要となりますが、障害時の協調は時間がかかります。各運営者への連絡・正規バージョンのデプロイ・再起動が必要で、数百の独立したバリデータが分散運用されるネットワークでは数時間~数日に及ぶこともあります。
ハードフォークはブロック高トリガーにより全バリデータ同時アップグレードを図りますが、事前の協調が不可欠です。漸次アップグレードは、Polygon障害のようなバージョン不一致リスクを高めます。

図6:ブロックチェーンのトリレンマ – 分散性 vs パフォーマンス この散布図は、各システムを2つの重要な軸でマッピングしています:
中央集権型取引所はアーキテクチャの単純化により低レイテンシーを実現。マッチングエンジンはマイクロ秒単位で注文処理し、状態は中央DBに集約。合意形成プロトコルによるオーバーヘッドなし。しかしこの単純さが単一障害点となり、ストレス時に連鎖的障害がシステム全体に波及します。
分散型プロトコルは状態をバリデータ間で分散し、単一障害点を排除。高スループットチェーンは障害時も資金損失はなく、停止のみ。しかし分散バリデータ間で合意形成には計算オーバーヘッドが発生。バリデータが非互換バージョン稼働や過負荷時には合意形成が一時停止します。
レプリカ追加は耐障害性を高めますが、調整コストも増加。Byzantine耐性システムでバリデータ追加ごとに通信オーバーヘッドが増し、高スループット設計は通信効率化でパフォーマンス向上を図る一方、特定攻撃パターンへの脆弱性が生じます。セキュリティ重視設計はバリデータ多様性と合意形成堅牢性を優先し、ベースレイヤーのスループットを制限しつつ耐障害性を最大化します。
Layer2は階層設計で両者の両立を目指します。L1決済でEthereumのセキュリティを継承しつつ、オフチェーン計算で高スループットを実現。ただしシーケンサーやRPCレイヤーに新たなボトルネックが生じ、アーキテクチャの複雑化が新たな障害モードを生み出します。
2025年10月のイベントは、取引所レベルでこの動態を示しました。通常時はBinanceのAPIレート制限やDB接続で十分ですが、連鎖時は全トレーダーが一斉にポジション調整を試み、これら制限がボトルネックになります。取引所保護を目的としたマージンシステムが最悪のタイミングで強制売却を生み、危機を増幅させました。
自動スケーリングは段階的負荷増への防御には不十分です。追加サーバー稼働まで数分要し、その間にマージンシステムは薄い板から取得した破損価格データでポジション評価を続行。新規キャパシティが稼働する頃には連鎖が拡大しています。
希少なストレスイベントに備えた過剰供給は、通常時にはコスト増となります。取引所運営者は典型的な負荷に最適化し、障害発生は経済合理性の範囲で容認。ダウンタイムのコストはユーザー側へ外部化され、清算・未処理取引・市場変動時の資金アクセス不能として影響します。

図8:インフラ障害モード分布(2024~2025年) 円グラフによる根本原因の内訳:
規制強化が変化を促す可能性もあります。99.9%の稼働率やダウンタイム上限が規制で義務化されれば、取引所は過剰供給が不可欠となります。しかし規制は通常、障害発生後に制定され予防的ではありません。Mt.Goxの2014年崩壊は日本の暗号資産取引所規制創設を促しました。2025年10月の連鎖も類似の規制対応を引き起こすでしょう。その対応が結果(ダウンタイム最大値、清算時最大スリッページ)を規定するのか、実装(特定オラクルプロバイダー、サーキットブレーカー閾値等)を規定するのかは不透明です。
根本的課題は、これらシステムがグローバル市場で常時稼働しながら、伝統的な営業時間向けに設計されたインフラへ依存していることです。ストレスが午前2時に発生すれば、運用チームは即時修正に奔走し、ユーザーは損失拡大に直面します。伝統市場はストレス時に取引停止しますが、暗号資産市場はそのまま崩壊します。特徴と捉えるか欠陥と捉えるかは議論が分かれます。
ブロックチェーンシステムは短期間で驚異的な技術発展を遂げました。数千ノードで分散合意形成するのは高度な工学的成果ですが、ストレス下での信頼性確保にはプロトタイプ設計から本格的なインフラへの転換が必須です。その実現にはコストが伴い、堅牢性を機能追加より優先する姿勢が求められます。
課題は、強気相場の成長期に堅牢性を優先することです。全員が利益を得ている時はダウンタイムも他人事。次のサイクルでシステムがストレステストされる頃には新たな弱点が顕在化します。2025年10月から業界が学び取るのか、同様のパターンを繰り返すのかは分かりません。歴史的には、次の重大な脆弱性も数十億ドル規模の障害で発見される可能性が高いでしょう。
本分析は公開市場データおよびプラットフォーム声明に基づきます。記載の見解は私個人のものであり、いかなる団体を代表するものではありません。





