ロシアのIT大手Yandexが、2026年10月8日から11日にかけて相次いだドローン攻撃により、3カ所のデータセンターに被害を受けた。サソヴォとウラジーミルの施設は全面停止し、カルーガでも一部の設備が使用不能になった。これと同時期に、Yandexのネットワークから発信されるボット通信も急減した。ただし、Cloudflareの公開データでは、11日後半に通信量が部分的に回復している。今回の通信量の減少を「ロシアの偽情報活動が壊滅した」と解釈する根拠はない。公式発表から明らかになったのは、被害を受けたクラウドサービスの復旧に必要な計算資源の不足と、企業の文書業務にまで及ぶ深刻な影響だ。
3拠点への相次ぐ攻撃で、Yandex Cloudが緊急運用体制に
Yandexが10月9日に発表した声明によると、最初の被害が発生したのは7日から8日にかけての夜だった。リャザン州サソヴォにあるデータセンターが攻撃を受け、施設は深刻な損傷を負い、完全に稼働を停止したという。
続く9日朝には、カルーガのデータセンターも攻撃を受け、インフラの一部が停止した。いずれの施設でも従業員に負傷者はいなかったものの、当時、設備をいつ復旧できるかは見通せない状況だった。
11日には、ウラジーミルの施設も被害を受けた。
公式Telegramチャンネル「Yandex Cloud Alerts」は、ドローン攻撃によって同地のデータセンターの設備が損傷し、全面停止したと発表した。こちらも人的被害は報告されていない。
一方、Yandexは残された設備や計算資源によるサービス提供が不安定な状態にあると説明し、クラウドプラットフォームを緊急運用体制に移行した。利用者には、別の環境でサービスを復旧するための災害復旧計画を実行するよう勧めている。
ただし、複数のデータセンターが停止したからといって、Yandexのすべてのサービスが使えなくなったわけではない。
11日の復旧状況に関する告知では、クラウドの管理画面とAPIは利用可能で、一部の計算資源も使用できると説明された。
データベースについては、別の環境への切り替えが進められていたものの、読み取り専用の状態にとどまるものや、依然として利用できないものも残っていた。
つまり、障害の影響はサービスによって異なり、同じサービスでも実行できる操作には違いがあった。
データセンターの被害がどの業務に影響するかは、停止した施設の数だけでは判断できない。利用者がデータや処理をどこに配置していたか、また代替設備で何を動かせるかによって、復旧の難しさも変わってくる。
急減した「ボット通信」は、偽情報の発信を意味するのか
今回、Cloudflare Radarで急激な減少が確認されたのは、Yandexが運用するAS13238というネットワークから発信されたHTTPリクエストのうち、自動通信と推定されたものだ。
AS（自律システム）とは、共通の管理方針に基づいて運用されるネットワークの単位を指す。
したがって、このデータが示しているのはロシア全体のインターネット通信量でもなければ、特定のSNSに投稿されたメッセージの件数でもない。
Cloudflareのボット分類に関する説明によると、ボットスコアが1〜29の通信は自動化されている可能性が高く、30以上は人間による操作の可能性が高いものとして分類される。
ただし、この仕組みが判定しているのは通信が自動生成された可能性であり、その内容が政治的な宣伝なのか、誰が資金を提供して運用しているのかを調べるものではない。
また、Cloudflare Radarが使用するのは、Cloudflareのネットワークを通過した通信のデータだ。インターネット上のすべての通信を網羅した統計ではない点にも注意が必要だ。
さらに、AS13238はYandexの検索エンジンが行う正規のウェブ巡回にも利用されている。
Yandexの公式ボット識別ガイドでは、同社のボットが使用するネットワークとしてAS13238を挙げ、ウェブページを収集するYandexBotの役割も説明している。
検索エンジンが検索結果を更新するには、ボットが外部のウェブサイトを継続的に巡回し、情報を収集しなければならない。
こうした正規の巡回処理が停止した場合も、Cloudflareのグラフ上ではボット通信の減少として現れる。
もちろん、今回減少した通信のうち、どれだけが検索エンジンによる巡回だったのかは、このデータだけでは分からない。
重要なのは、正規の用途にも使われているネットワークからの自動通信を、一括して偽情報の発信活動とみなす根拠がないという点だ。
一方で、この観測結果によって情報工作の存在そのものが否定されるわけでもない。
通信の内容や運用主体を特定するには、通信量の推移とは別の証拠が必要になる。
ほぼゼロまで急減した通信量、11日後半には一部回復
Cloudflare RadarのData Explorerでは、AS13238から発信されたボット通信について、一定期間の推移を確認できる。
同じ観測期間内の最大値を100として比較すると、AS13238のボット通信量は10月11日3時に約0.29まで急減したものの、同日22時には約11.03まで回復していた。
以下は、2026年10月1日0時から11日23時までのデータから、11日の主な時間帯を抜き出したものだ。
時刻はすべて協定世界時（UTC）であり、モスクワの現地時刻ではない。
| 10月11日の時刻（UTC） | 公開された正規化値 | 期間内の最大値を100とした通信量 |
|---|---|---|
| 3時 | 0.002942 | 約0.29 |
| 15時 | 0.192477 | 約19.25 |
| 22時 | 0.11028 | 約11.03 |
Data Explorerの応答には、「MIN0_MAX」という正規化方式が使われている。
Cloudflareの定義によると、この方式では対象期間内の最大値を1として、それぞれの値を相対的な比率で表す。
上表では公開値を100倍し、小数第2位までに丸めている。
基準となるのは、指定期間における1時間当たりの最大通信量だ。ロシア国内のボット総数や、人間の通信を含めた全通信量に占めるボットの割合を示しているわけではない。
また、このデータから実際のHTTPリクエスト件数を知ることもできない。
11日3時の通信量が極めて低い水準まで落ち込んだことは確かだ。
しかし、15時には期間内の最大値の約19.25%まで回復し、22時も約11.03%を維持していた。途中で再び減少しているものの、通信量がゼロに近い状態のまま固定されていたわけではない。
一時的な急減を、長期間にわたる完全停止と捉えてしまうと、こうした変化を見落とすことになる。
また、データセンターへの攻撃が発生した時期と、通信量が急減した時期は重なっているが、このグラフだけで各施設の停止が通信量にどの程度影響したのかを特定することはできない。
回復した通信についても、元の設備が復旧した結果なのか、それとも別の設備へ処理を移した結果なのかは分からない。
ボット通信が回復することと、被害を受けたデータセンターの処理能力が回復することは、別の問題だ。
データセンターを分散しても、復旧先の余力がなければ対応できない
Yandex Cloudの可用性ゾーンに関する説明では、仮想マシンやディスクなどのクラウド資源が、特定の可用性ゾーンに関連付けられる仕組みを説明している。
可用性ゾーンとは、クラウドサービスを提供する設備を障害の影響範囲ごとに分けた単位だ。
異なるゾーンを利用することで、一方の設備やソフトウェアに障害が発生しても、ほかのゾーンへの影響を抑えられる。
アプリケーションを複数のゾーンに分散配置すれば、一部の設備が故障してもサービスを継続できる可能性が高まる。
ただし、別の拠点が存在するだけでは、停止した施設の処理をすべて引き継げるとは限らない。
移行先にも十分な計算資源が必要であり、アプリケーションが使用するデータにアクセスできることも欠かせない。
仮想マシンを新しく起動できても、必要なディスクやバックアップデータを利用できなければ、元の業務は再開できない。
Yandexのゾーン障害時の仮想マシン群の運用に関する文書では、こうした余力の確保について具体例を示している。
9台の仮想マシンが必要なアプリケーションを2つのゾーンで運用する場合、それぞれのゾーンに9台ずつ、合計18台を用意するというものだ。
この構成であれば、一方のゾーンが完全に停止しても、もう一方に残る9台で必要な処理能力を維持できる。
一方、合計9台の仮想マシンを2つのゾーンに分散しただけでは、一方が停止した際に必要な9台を確保できない。
もちろん、これはYandexが示した設計例であり、今回の障害発生時に同社が実際にどれだけの予備資源を持っていたかを示すものではない。
それでも、設備を複数の場所に分散することと、障害時に必要な処理能力を確保することが別の課題であると分かる。
通常の機器故障であれば、複数のゾーンに分散することで影響を抑えられる可能性がある。しかし、複数のデータセンターが相次いで物理的な被害を受ければ、利用できる計算資源そのものが減少してしまう。
今回の公式発表にも、復旧先の資源不足をうかがわせる内容がある。
Yandexは10日、計算資源とディスクの利用枠を完全に手動で管理すると説明した。さらに11日には、新たな計算資源の利用枠の発行を停止したと告知している。
利用者に対し、別のクラウド基盤での復旧を勧めたことからも、同じプラットフォーム内で必要な資源を追加するだけでは対応しきれない状況だったことがうかがえる。
データセンターは、サーバーだけでなく、電源設備やネットワーク、ストレージなどを含む大規模な物理施設だ。
ソフトウェア上で処理の移行先を指定できたとしても、その場所に必要な設備とデータがそろっていなければ、実際の業務を再開することはできない。
クラウド障害が電子申告や運送書類の業務にも波及
データセンターの被害は、クラウドを利用する企業の業務にも影響を及ぼしている。
ロシアの業務サービス企業Astralは、10月11日8時時点の告知で、電子申告、電子文書交換、電子運送書類に関するサービスで障害が発生していると説明した。
同社によると、ウラジーミルにあるYandexのデータセンターが新たなドローン攻撃で損傷したことにより、複数のサービスが影響を受けたという。
文書の送信や電子署名の際にエラーが発生する利用者には、時間を置いて再試行するよう案内している。
さらにAstralは、技術的な障害によって期限内に文書を提出できなかったことを説明するための、監督官庁向け書類も用意した。
これは、クラウドサービスの停止が、単にウェブサイトを開けなくなるという問題にとどまらず、企業の申告業務や運送関連の手続きにまで影響した例だ。
ただし、この発表が示しているのはAstralのサービスに生じた障害であり、ロシア全土の物流が停止したという意味ではない。
また、サービスが復旧したかどうかを判断する際も、通信量の回復だけでは不十分だ。
管理画面にアクセスできること、保存されたデータを読み取れること、データを更新できること、文書の作成や署名、送信を完了できることは、それぞれ異なる。
例えば、保存済みの文書を閲覧できるようになっても、新しい運送書類の作成や電子署名、送信ができなければ、業務への支障は続く。
今回のYandexの被害が浮き彫りにしたのは、複数のデータセンターを持つクラウド事業者であっても、物理的な攻撃が相次いだ場合には、サービスの継続が難しくなり得るという現実だ。
データが失われずに残っていたとしても、それを処理するための計算資源を別の環境に確保できなければ、業務は再開できない。
Cloudflareの通信データは、障害がネットワーク上に及ぼした影響を知る手掛かりにはなる。しかし、それだけで被害の全容や復旧状況、まして偽情報活動への影響まで判断することはできない。
重要なのは、通信が回復したかどうかだけでなく、利用者がデータの読み書きを再開し、必要な業務を最後まで完了できる状態に戻ったかどうかだ。
複数拠点に被害が及んだ今回の事例は、クラウドの耐障害性を考えるうえで、設備の分散に加えて、復旧先の処理能力とデータへのアクセスを確保しておくことの重要性を示している。
