6月18日にClaudeのサービス障害が発生しました。
日本時間の午後4時ごろから、XをはじめとしてSNSで声が上がり障害発生のステータスが表示され、一時的に話題になりました。
- URL：https://japan.cnet.com/article/35249117/
- 参照：CNET Japan 「Claude」で障害発生（復旧）より
ところで、昨今「ClaudeのAI」重要は飛躍的に高まり、「Claude Fable」に至っては、米政府の輸出管理指示によって、すでにアクセス制限となりました。これは利用するユーザーの判断に関わらず、利用できない事態が容易に起こると言うことです。
先ほどの18日に起きたサービス障害は、結果から見れば約1時間で済みました。しかしClaude Fableはどうでしょう？依然見通しが立ちません。（6月21日現在)
これはサービスを受ける側からすると、突然利用できなくなり、再度利用することもできないと言うことです。1時間であれば、まだ軽微なものかもしれませんが、「以降利用できない」のであれば話は変わってきます。
この社会現象には覚えがあります。
一強という視点で、私が感じたのは「AWS」です。
今回は、一強依存による継続的サービスへの不安をAWSを例に考えます。また、マルチAI時代へのシフトを考え、一つの解を記載します。
AWS障害に見る、一強サービス利用の不安
2025年10月に発生した、AWSの大規模障害を覚えているでしょうか？ サーバーは生きているにも関わらず、一つの障害から、深い依存関係にあるサービスが利用できなくなりました。
当然一般的なサービスにも障害が波及し、SNS、銀行アプリ、ネットワークサービスにも当然サービス障害が発生し、世界的な混乱に陥ったのです。この障害は約15時間かけて復旧に至りました。
- URL：https://aws.amazon.com/jp/message/101925/
- 参照：米国東部（バージニア北部、US-EAST-1）リージョンにおける Amazon DynamoDB サービス中断の概要より
この間、私たちにできることは多くありません。AWSに関係なくできる業務を回したり、関係各所に連絡し、どのようにその後の対応をするかを考え、相談するという先回りの対応です。
ただ、問題の本質はAWSが障害を起こしたことではないのです。AWSの可用性を信じて選択してきたことで、起こり得た問題から目を逸らしていたということです。
壊れる前提で動いていたNetflixなどの企業は、この問題をうまく回避しています。これは日常的なカオスエンジニアリングのなせる技です。
AI時代に取り組む、Design for Failure
一過性のエラーでも、長期的なエラーであっても、サービス提供は続けなければなりません。つまり設計としてDesign for Failure（システムに障害は発生する）の前提で動いていく必要があります。
これは、システムだけではなく、インフラ、サービス、あらゆる依存関係にあるものが対象です。
さて、AIに話を戻しましょう。今回、Claudeの障害ではAPIは大丈夫やそうではないなど、様々な会話が飛び交っていました。サービスとして活用していたり、開発利用をしていたり、組み込んで利用していたりと、多くの利用者に影響が出たのは間違いありません。
そして、約1時間の障害がニュースとして取り上げられるほど、生活に入り込んでいるのです。先述のAWSが、AzureやGCPにシェアを取られるのでは？と当時言われていたにも関わらず、あれだけの障害を起こしたことで、予期せず影響範囲が露見したといえるでしょう。
この点ではClaudeも同じです。
CodexやCursor、IBM Bobといった製品が並ぶ中で、一強時代になりつつあります。誰もがClaudeなら、という思想になってしまっています。しかしそれで本当に問題ないのでしょうか？
これはベンダーロックインに陥っていませんか？ プランの変更による事実上の価格高騰、規約変更など、一つの製品への依存はこれからも大きな課題となってくるでしょう。
直近の「Claude Fable」でも、利用し始めてすぐ利用制限では、サービスの安定提供に差し障ります。私たちは、インフラのようなものから、サービスを買う時代になったことで、サービスもいつ問題を起こすかわからない、という姿勢でいなければならないのです。
対策としてCodexやIBM Bob、Cursorの併用。さらに先のマルチLLMとは？
現時点では、Claudeが抜きん出ていることが社会的評価からは窺うことができます。あくまで私見ではありますが、Qiitaのトレンドの状況などを見ても、Claudeが選択肢として上位にくるといえるでしょう。
「Design for Failure」という視点では、一つに固執しないことが最も大事です。Claude以外の選択肢を持つこと、あるいはローカルLLMなどの選択肢もあるでしょう。ただし、インフラ設備の関係からもそれらの選択肢はまだ取りづらいこともあります。
多くの選択肢がある中で、CodexやCursorはCode関連に強く、OpenAIのCodexは先駆けとしてChatGPTなどで名を挙げてきました。では、マルチAIという点では、このClaudeとその他のAI製品を利用すれば良いでしょう。
では、さらに一歩進んで考えるべきリスクは、Codexも利用できなくなった時です。
マルチAIというのは、取りえる簡単な対策ではありますが、ここで問題になるのは、双方が利用できないときにどうするのか？ということです。つまり、そういったことも視野に入れて動いている製品がリスクヘッジには欠かせません。
そのため、マルチLLMという思考に至ります。開発元が違うLLMを一つの環境で利用することができる、という思想です。これは、マルチモデル・オーケストレーションという考え方になります。
現在、Claudeを利用しているが、その他のAIツールを探さねばならない。できるだけリスクヘッジも考える必要がある、というときにはマルチモデル・オーケストレーションが必要です。この機能によって、多くのLLMから必要なものを選択的に利用することができます。
また、IBM Bobは、マルチLLMの特性上Claudeを利用することができますが、今回のClaudeの障害発生時にはClaudeを回避して、通常利用ができていました。
つまり、これからは一強依存しないように、マルチAIという選択も取れますし、マルチモデル・オーケストレーションという選択もできるということです。
常に障害は起こりうる。ClaudeやAWSの教訓を活かす
AIは水道や電気と同じ「社会インフラ」になりつつあります。今回のClaude障害を教訓に、「一強」に依存しない分散型の活用を考えることが、これからの時代を生き抜くことに繋がります。
Claude
Gemini
Codex
IBM Bob
Cursor
...
改めて、多くのAI製品がある中で、これからもマルチAIに進むことが必要になるでしょう。そして、障害対応も見越し、コスト、トークン消費、料金体系などで考えると、どれかを組み合わせる必要があります。
Claude * [.....] Gemini * [.....]
Codex * [.....] IBM Bob * [.....] Cursor * [.....]
その中で、さらに一歩進んで、マルチモデル・オーケストレーションを組み合わせるのもポイントになります。そういった意味では、
[.....] * IBM Bob
という選択肢を持つことは、継続性があり効果の高いAI利用につながるでしょう。
ちなみに、私は、Codexと、Claude、IBM Bobを利用しています。
ここまで読んでいただきありがとうございます。