【ITニュース解説】DeepSeek's API Was Partly Down for 4h52m. It's Refunding a Week of Spend as Credit

DeepSeekというAIモデルを提供する企業が、そのサービスの一部に障害が発生したことを発表し、利用者に補償を提供した事例は、システム開発の現場で起こりうる問題と、それに対する企業の対応、そして開発者側がどのように備えるべきかを示す良い教訓となる。この事件は、2023年10月15日の世界標準時（UTC）の午前0時11分から午前5時4分にかけて、約4時間52分間にわたり発生した。この時間帯にDeepSeekのAIモデルとやり取りするアプリケーションは、一部のサービスが利用できない、または不安定な状態に陥っていたのである。具体的には、チャットサービス、そしてDeepSeek V4 Pro APIサービスとDeepSeek V4.1 Flash APIサービスが影響を受けた。この障害は、DeepSeekのステータスページで「DeepSeek ウェブ/API 部分中断」と記載され、その詳細な時間軸が公開された。まず問題の原因調査が始まり、約1時間後には原因が特定され、修正作業が実施された。その後、修正が適用され、状況を監視するフェーズを経て、最終的にはサービスが復旧したことが報告されている。

DeepSeekは、この障害に対して顧客に補償を提供した。その内容は、障害が発生する前の7日間（10月8日から10月14日）にアカウントが消費した金額を、全額「ボーナス残高」として返還するというものであった。これは非常に手厚い補償策と言える。返還されたクレジットは自動的に付与され、利用者が新しくチャージした通常の残高よりも優先して消費される仕組みだ。つまり、障害の発生によって金銭的な負担が増えることを防ぐための措置である。しかし、この補償がカバーするのは、過去の利用金額に対するクレジットであり、障害によって利用者のアプリケーションがサービスを提供できなかったことによる機会損失や、ユーザーからの問い合わせ対応にかかったコストなどは含まれない。例えば、障害発生日にサービスをローンチしようとしていた場合でも、過去7日間の利用額が少なければ、受け取れるクレジットも少なくなる。また、このクレジットに有効期限があるかどうかは、個別にDeepSeekのプラットフォームで確認する必要がある。

DeepSeekは障害の原因について具体的な説明はしていないが、補償に関する通知の中で、サービス安定性に関する徹底的な見直しを開始し、「単一の依存関係（single point of dependency）」を排除すると述べている。これは、一つのコンポーネントが停止すると、それによって複数のサービス全体が停止してしまうような構造が問題であったことを示唆している。実際に、今回の障害ではチャットサービスと二つのAPIモデルが同時に影響を受けていたため、これら三つのサービスが共通の何かに依存していたと考えられる。DeepSeekは過去にも何度かサービスの問題を経験しており、特に新しいモデルであるV4.1 Flashのリリース以降、需要の増加に伴う障害が指摘されることもあるが、これはあくまで推測の域を出ない。しかし、どのクラウドサービスやAPIプロバイダーも完璧ではないため、一時的な障害は避けられない現実である。

このような事態に備え、システム設計において重要なのは、「単一のプロバイダーに全てのAIモデルの呼び出しを依存させない」という教訓である。もしDeepSeekのような主要なサービスが停止した場合でも、アプリケーションが完全に機能停止するのを避けるために、「フォールバック」、つまり代替手段を用意することが不可欠だ。DeepSeekのAPIはOpenAIの形式と互換性があるため、別のOpenAI互換のAPIプロバイダーを代替として用意することは比較的容易である。

具体的な実装例として、OpenAIのNode.js向けSDKを使ったフォールバックの仕組みが示されている。これは、まずDeepSeekのAPIを「主要なサービス」として呼び出し、もしDeepSeek側でエラーが発生した場合に、自動的に「代替のサービス」に切り替えて処理を続行するという方法だ。この際、重要な設定がいくつかある。例えば、「タイムアウト」と「最大リトライ回数」を短く設定することで、主要なサービスが応答しない場合に、何分も待つことなく素早く代替サービスに切り替えることができる。また、どのようなエラーが発生した場合に代替サービスに切り替えるべきかについても考慮が必要だ。ネットワーク接続の失敗やタイムアウト、あるいはサーバーエラーを示す「5xx」系のステータスコードや、リクエスト過多を示す「429」のようなエラーコードは、サービス側の一時的な問題を示しているため、フォールバックの対象とすべきである。しかし、不正なリクエストや認証エラーを示す「400」や「401」のようなエラーは、開発者側のコードのバグや設定ミスが原因である可能性が高いため、これらを代替サービスに送っても解決にはならず、問題を見つけにくくするだけなので、フォールバックの対象から外すべきだ。

代替サービスとしては、コストよりも安定性を重視して選定することが推奨される。また、異なるモデルを使用する場合、応答内容が変わる可能性もあるため、代替モデルでも期待通りの結果が得られるか、事前にテストしておくことが重要である。そして、どちらのプロバイダーがリクエストを処理したかをログに残すことで、サービスの運用状況を把握できるようにしておくべきである。

今回の出来事を受けて、DeepSeekのAPI利用者として取るべき行動はいくつかある。まず、DeepSeekのプラットフォームで自分のアカウントの残高を確認し、付与されたクレジットの金額と有効期限をチェックすることだ。クレジットは優先的に消費されるため、これまでの課金アラートなどの設定を見直す必要があるかもしれない。次に、10月15日の障害発生時間帯（UTC 00:11～05:04）の自社システムのログを確認し、どれくらいのリクエストが失敗したかを把握すること。これは、実際の障害によるビジネスへの影響を把握するために不可欠な情報であり、クレジットでは補償されない部分である。そして、最も重要なのは、前述のようなフォールバックの仕組みを自社システムに導入し、テストすることである。主要なAPIが使えなくなった時に備える設計は、システムの信頼性を高める上で非常に重要だ。

今回のDeepSeekのAPI障害とそれに対する対応は、システムエンジニアを目指す者にとって、サービスの依存関係、障害からの回復力、そしてリスク管理という、システム設計の基本を改めて考える機会を提供する。どんなに信頼性の高いサービスでも、予期せぬ障害は発生する可能性があり、その時にいかにビジネスへの影響を最小限に抑えるかが、開発者の腕の見せ所となる。