Incident Tech

はじめに

第二回ではAlibaba Cloudのネットワーク障害とデータセンター火災を取り上げました。第三回となる今回は、中国のAIサービスで起きた3つの障害を取り上げます。

2025年以降、DeepSeekやQwen（アリババ）などのAIサービスが急速に普及しています。AIの推論リクエストは通常のWebリクエストと比べて1件あたりの計算コストが桁違いに大きく、攻撃にも需要急増にも従来のWebサービスより脆弱という構造があります。3つの事例はそれぞれ異なる形の障害ですが、この「AIサービス特有のコスト構造」が根底にあります。

事例3　DeepSeek 大規模DDoS攻撃（2025年1月25〜30日）

詳細

2025年1月20日にDeepSeek-R1が公開されると、低コストながらOpenAI o1に匹敵する推論性能が話題となり、米国のナスダック市場でNVIDIAが一日で約60兆円規模の時価総額を失うほどの衝撃を与えました。この注目度に乗じるように、同月25日から3波にわたる組織的なDDoS攻撃が始まります。

サイバーセキュリティ企業NSFOCUSの解析によれば、攻撃はDeepSeekのAPIエンドポイント（api.deepseek.com）に集中し、NTPリフレクション攻撃とMemcachedリフレクション攻撃を組み合わせた手口で、1波あたり平均35分にわたって継続しました。1月28日にDeepSeekがAPIの解決先IPアドレスを切り替えると攻撃側は即座に追跡して新たな波を投入し、攻撃量は前日比100倍超に急増しました。

同時期、外部のセキュリティ研究者によってClickHouseデータベースが誤って外部公開状態になっていたことも判明し、ユーザーのチャット履歴などが閲覧可能な状態にあったことが明らかになっています。

対応のポイント

DeepSeekは1月27日に「大規模な悪意ある攻撃」を受けていると公表し、新規ユーザー登録を中国本土の電話番号のみに絞り込み、APIサービスを一時停止しました。特筆すべきは攻撃側の洗練度です。IPアドレスの切り替えに即座に追従するという機動性から、セキュリティ企業各社は「事前に計画された専門チームによる攻撃」と評価しており、単なる愉快犯とは異なる性格の事案でした。

原因

直接的な原因は外部からの組織的なDDoS攻撃ですが、背景にはAI推論の計算コスト構造があります。AIの推論リクエストは1件あたりの計算負荷が通常のWebリクエストより桁違いに大きく、攻撃者の偽リクエストが正規ユーザーの利用機会を容易に圧迫する構造があります。

学び

AIサービス特有のDDoS耐性設計を先手で組む　帯域ベースの防御だけでは対処できない。推論1リクエストあたりのコストを踏まえたレートリミット（トークン単位・ユーザー単位）を事前に設計する必要がある。

ステータスページと障害情報の発信手段を本体サービスから独立させる　本体サービスがダウンしても、別ドメインのステータスサイトや公式SNSで障害情報を発信できる体制を維持する。これがユーザーの不安拡散を防ぐ最初の砦になる。

急速な成長前にデータベースの外部公開状態を棚卸しする　ClickHouseの誤公開は「成長の速度が、セキュリティ監査の速度を追い越した」典型例。スケールアップ前にセキュリティレビューを設計サイクルの必須工程として組み込む。

事例4　アリババ Qwen 旧正月キャンペーンクラッシュ（2026年2月6日）

詳細

2026年2月6日（中国の旧正月直前）、アリババはAIチャットボット「Qwen（クウェン）」の普及促進を目的に、総額30億人民元（約430億円）のキャンペーンを開始しました。目玉は「Qwen経由でタピオカミルクティーの無料クーポン（25元相当）をもらえる」というもので、全国30万店舗以上が対象でした。

しかし開始からわずか9時間で1,000万件を超える注文が殺到し、Qwenのバックエンドはダウン。Qwenが「私は言語モデルであり手足を持ちません。別のデリバリーアプリで注文してください」と返答するという状況になりました。同日、アリババの香港株が2.88%下落するという市場への影響も出ています。アリババは翌日「緊急でサーバーリソースを追加している」と公表し、クーポンの有効期限を2月28日まで延長して対処しました。

対応のポイント

エンジニアチームは障害発生後40分以内に追加のGPUインスタンスを投入し、部分的なサービスを復旧させています。しかしキャンペーンに参加できなかったというユーザー体験の損失はその時点ですでに発生しており、クーポン延長という補償策はSNS上の批判を完全には吸収できませんでした。アリババ内部では事前にピーク時のリスクが認識されていたとされていますが、Tencent・Baidu・ByteDanceとの競争でキャンペーン開始のタイムラインが前倒しになり、十分な負荷テストの時間を確保できなかったことが明らかになっています。

原因

従来のECシステム（「独身の日セール」では1日8,000〜9,000万件を処理可能）とAIエージェントのリクエストとでは、1件あたりの計算コスト構造に根本的な違いがあり、AI特有の需要予測モデルが整備されていませんでした。また競合のWeChatがQRコードシェアをブロックしたことで流入経路が特定のAPIエンドポイントに集中したことも、複合的な要因として挙げられています。

学び

「キャンペーンが成功した場合」をインフラ設計の前提に置く　マーケティング施策と技術チームは同じタイムラインで動く必要がある。キャンペーン規模の試算（参加人数・注文数）をインフラキャパシティと突き合わせることを、リリース承認の必須条件にする。

AIの推論コストはECの注文コストで換算できない　ECの注文処理とAIエージェントのリクエストは1件あたりの計算コストが2〜3桁異なることがある。既存の負荷試験ツールや閾値設定をAI推論の文脈に合わせて再設計する。

エラーメッセージを工夫しても、復旧見込みと補償方針の明示は別途必要　Qwenの返答がSNSで話題になったが、ユーザーが本当に求めたのは「いつ使えるか」という情報だった。障害時のユーザーへの説明は、復旧見込みと補償方針の明確化を優先する。

事例5　DeepSeek サービス開始以来最大の障害（2026年3月29〜30日）

詳細

2026年3月29日夜の21:35頃、DeepSeekのチャットサービスで大規模な障害が始まりました。約2時間後の23:23に一度復旧したとマークされましたが、1時間も経たないうちに再び障害が発生。翌3月30日午前10時33分にようやく完全解決が宣言されるまで、合計8時間以上（独立監視サービスStatusGatorによれば8時間13分）のダウンタイムが記録されました。

R1モデルの公開から14ヶ月以上にわたって99%前後の稼働率を維持してきただけに、このインシデントは「サービス開始以来最大の障害」として注目を集めました。障害中、内部のモデル識別子がDeepSeek-V3から変更されている様子が観測されたことから、次世代モデル（V4）のバックエンドでのテスト展開が引き金ではないかとの憶測も広がりました。なお、StatusGatorの監視履歴によれば、3月5日に40分間、3月10日に75分間の障害がすでに記録されており、今回の8時間超の障害はその延長線上にある「兆候が蓄積した末の破綻」とも解釈できます。

対応のポイント

DeepSeekはステータスページで「Major Outage（重大障害）」と公表し複数回の状況更新を発行しましたが、根本原因の説明は一切行いませんでした。「障害は解決しました」という通知のみで、なぜ起きたのかという説明がなかったことは業界からの批判を集めています。財新（中国の経済専門メディア）の報道によれば、この時期の中国国内のAI日次トークン呼び出し数は140兆を超えており、急増する需要とインフラ拡張スピードのギャップが背景にあったと見られています。

原因

DeepSeekは公式に原因を開示しておらず、確定的な分析は存在しません。開発者コミュニティでは、次世代モデルに向けたシステムアップデート、バックエンドアーキテクチャの変更、あるいは需要急増によるキャパシティ超過の3つの仮説が有力とされています。

学び

原因不明のまま「解決」を宣言することのリスクを理解する　ユーザーや開発者は「なぜ起きたか」「再発しないか」を知りたがっている。事後の障害報告書（ポストモーテム）の公開は、AIサービスが業務用途にまで浸透した今、誠実さだけでなく競争力の要素になっている。

段階的な障害悪化を早期に捉える仕組みを作る　3月5日・10日・29日という一連のパターンは、蓄積するシステム負荷が段階的に表面化したことを示唆している。P99レイテンシやエラー率のトレンドを継続的に監視し、大規模障害を予兆する段階でエスカレーションする仕組みが重要。

「AIサービスはインフラである」という認識でSLAを設計する　3億5,500万ユーザーの日常的な業務・学習フローに組み込まれているにもかかわらず、SLAや補償ポリシーを公表していない。利用者の業務依存が高まるにつれ、提供側の責任水準も自然と上がる。このギャップを放置すると、障害時の批判は「一時的な不満」を超えて「信頼の喪失」へと変わる。

3つの事例に共通すること

今回の3事例はすべてAIサービスの障害です。共通するのは、AI推論リクエストの「1件あたりのコストが通常のWebリクエストと桁違いに大きい」という構造が、あらゆる問題を増幅させている点です。DDoS攻撃への脆弱性も、需要急増によるクラッシュも、根は同じです。

従来のECやWebサービス向けに整備してきたキャパシティ設計・負荷試験・レートリミットの考え方を、AIサービスの文脈で見直す必要があります。また、DeepSeekの事例が示すように、急成長期のAIサービスは「問題の兆候を蓄積しながら、閾値を超えた瞬間に大きく崩れる」パターンを持ちやすく、利用者がインフラとして依存し始めた段階で提供側に求められる責任水準も上がります。

参考情報

• NSFocus「DeepSeek DDoS攻撃分析」（2025年1月）：https://securityboulevard.com/2025/01/the-undercurrent-behind-the-rise-of-deepseek-ddos-attacks-in-the-global-ai-technology-game/
• Yicai「Qwen旧正月キャンペーン障害」（2026年2月）：https://www.yicaiglobal.com/news/alibabas-website-crashes-as-chinese-tech-giant-starts-usd4324-million-lunar-new-year-push-for-qwen-ai-app
• Caixin「DeepSeek障害：需要急増の中10時間のダウン」（2026年3月）：https://www.caixinglobal.com/2026-03-30/deepseek-goes-out-for-10-hours-amid-chinas-ai-demand-surge-102428989.html