Salesforceの障害2025：主要な障害に関する回顧

2025年のSalesforce障害記録から得られる最も重要な結論は、その年を象徴するような単一の「グローバルSalesforce障害」は存在しなかったということである。実際には、顧客は複数の異なる障害パターンを経験した。2月には広範囲にわたるサービス中断、6月には複数のクラウドにわたる認証エラー、ベンダーの意図しないアップデートが原因となったHerokuプラットフォームの重大なインシデント、インディアナポリスのデータセンターのネットワーク障害、そしてその後は特定のインスタンスや機能に限定されたインシデントなどである。この区別が重要なのは、適切な対応は障害が発生した箇所によって異なるためである。

ユーザーがサインインできない場合、ブラウザを更新しても問題は解決しません。公開ステータスページの表示が遅れている場合、一般的な障害監視も不完全な情報となる可能性があります。Salesforce自体は利用可能でも、統合キューが停止している場合、CRM自体は正常に見えても、ビジネスプロセスは依然として失敗している可能性があります。2025年の事例から得られる実践的な教訓は、テナント固有のステータス通知、独立した監視、テスト済みの手動手順、および下流システムの復旧チェックを組み合わせることです。

2025年にSalesforceに起こった主な変革は何だったのでしょうか？

以下の事例は、さまざまな障害モードを示しているため、事後検証に役立ちます。ただし、2025年に発生するすべてのSalesforceステータスイベントがここに網羅されているわけではありません。

2月とSalesforce Trustのインシデントについては、日付、範囲、復旧状況の更新情報はSalesforceのインシデント記録に基づいています。具体的には、2月7日のサービス障害、6月10日のクロスクラウド認証インシデント、6月18日のインディアナポリスでのインシデント、11月1日のインスタンスインシデント、12月31日のWhatsAppインシデントです。

6月10日の事件は、2つの異なる障害層を明らかにした。

6月10日は特に重要です。なぜなら、「Salesforceの障害」という言葉は複数の事象を指す可能性があるからです。Salesforceの信頼記録には、複数のクラウドに影響を与えた多要素認証の失敗が記載されています。その後、Herokuが発表した是正措置報告書には、UTC午前6時に発生したプラットフォームサービスの障害が、ベンダーによる本番環境への意図しないシステムアップデートによって引き起こされたと記載されています。

Herokuは、自社のステータスサイトにも影響があったことを認めた。Herokuの是正措置アップデートによると、ステータスページの設計上の不備とAPIの遅延によりタイムアウトが発生し、ページにアクティブなインシデントが表示されない場合があるという。Herokuは、ベンダーによる無人オペレーティングシステムアップグレードの永久停止、イメージ監査、追加の監視、ステータスコンテンツのキャッシュ、独立したコミュニケーション計画、より強力なインシデント対応手順などの対策で対応したと述べている。

これは管理者にとって重要な区別です。ステータスページはサービスそのものではありませんが、顧客はそれを使って待機するか、フェイルオーバーするか、サポートケースを開くか、あるいは自社のユーザーと連絡を取るかを判断します。ステータスチャネルが影響を受けるプラットフォームとインフラストラクチャを過度に共有している場合、最も必要とされる瞬間に信頼できる情報を提供できない可能性があります。

2025年の記録は、Salesforceの顧客に何を教えてくれたのか？

1. 認証には独自の継続性計画が必要である

アプリケーションデータが正常であっても、ログイン、多要素認証、または接続されたIDパスが失敗すると、チームは作業できなくなる可能性があります。これは、Salesforce、Heroku、Commerce、Marketing Cloudを併用している企業にとって特に重要です。どのユーザーがどのシステムにアクセスする必要があるかを文書化し、ベンダーからの最新情報を受け取れる緊急連絡先を特定し、ログインが成功しなくても継続できる作業を定義してください。

小規模な営業チームの場合、それは短期間の手動コールリストと共有インシデントログを意味するかもしれません。コンタクトセンターや医療機関の場合は、正式なダウンタイム手順、承認済みの読み取り専用エクスポート、およびテスト済みのエスカレーションツリーが必要になるかもしれません。フォールバックの規模は、ロックアウトされた場合のビジネス上の影響に見合ったものでなければなりません。

2. 一般的なステータスページだけでは不十分です

Salesforceの公式ドキュメントによると、トラストステータスは可用性とパフォーマンス情報を提供する一方、新しいマイ・トラストセンターのビューはテナントとサポート対象製品を中心に設計されています。運用上のポイントはシンプルです。インシデントが発生する前に、インスタンスまたはテナントの識別子を把握しておくことが重要です。

Salesforceでは、My Trust Centerのメッセージと通知を購読するための手順も提供しています。通知は、組織を最初に作成した管理者だけでなく、対応が必要なユーザーにも設定してください。ベンダーのステータスサイトが遅い場合や利用できない場合でも社内で連絡が取れるように、社内ステータスページや承認済みメッセージンググループなど、独立したチャネルを確保しておきましょう。

3. 復旧とは、ログイン画面が表示されること以上の意味を持つ。

Salesforceがサービス復旧を報告しても、インシデントが業務に影響を与えている可能性があります。遅延したAPIリクエストが2回再試行されたり、キューに入れられたメッセージが遅れて届いたり、デプロイの失敗によってレコードの同期がずれたりする可能性があります。復旧後は、認証、API呼び出し、スケジュールされたジョブ、統合キュー、メールまたはメッセージ配信、レコード作成、レポートの鮮度など、最も重要なワークフローを確認してください。

例えば、中規模のサポートチームがあり、エージェントがSalesforceのケースを使用し、別のコマースシステムが連携を通じて更新情報を送信しているとします。Salesforceが午前10時に利用可能になったとしても、連携キューに障害発生期間中の失敗メッセージが残っている場合、ブラウザが読み込まれたというだけでインシデントをクローズすべきではありません。正しいテスト方法は、新規および以前に失敗したケース更新情報が重複することなくワークフロー全体を通過するかどうかを確認することです。

貴組織にはどのような事業継続対策が適していますか？

2026年以降、この回顧録をどのように活用するか

まず、1ページにまとめた依存関係マップを作成します。Salesforceインスタンスまたはテナント、IDプロバイダー、接続されているクラウド、重要な統合、ステータスサブスクリプション、および障害発生時に使用される手動プロセスを書き出します。次に、重要なワークフローごとに客観的な復旧チェックを定義します。「Salesforceが復旧した」では曖昧すぎます。「新規ケース、送信メッセージ、および注文更新が重複なく処理されている」であればテスト可能です。

最後に、可用性に影響を与える可能性のある変更点（ベンダーのアップデート、オペレーティングシステムの変更、リリース、構成の変更、インスタンスの移行など）を確認してください。6月のHerokuのインシデントは、無人変更には強力な制御が必要であり、ステータスの伝達にも独自の回復力が必要であることを示しています。6月18日のインシデントは、クラウドサービスにおいても物理的な容量とデータセンターへの依存が依然として重要であることを示しています。12月の機能低下は、チームがプラットフォームのトップレベルの可用性だけでなく、実際に使用する機能も監視する必要があることを示しています。

したがって、最適な対応策は状況によって異なります。小規模な組織では、通知と明確な手動チェックリストが必要になる場合があります。販売やサポートを一時停止できない企業では、独立した監視、キュー認識型復旧、および訓練されたダウンタイムプロセスが必要です。規制の厳しい組織では、テスト済みの復旧、証拠、およびガバナンスが必要です。2025年のSalesforceの障害記録は、一貫した結論を裏付けています。回復力は、単一の緑色のステータスインジケーターではなく、顧客の依存関係チェーンを中心に構築されるということです。

情報源と範囲

本稿では、執筆時点で入手可能なSalesforce Trustのインシデント記録およびSalesforceまたはHerokuのドキュメントに基づいて分析を行っています。インシデントページは解決後に更新される場合があり、Salesforceの製品カバレッジはTrust StatusとMy Trust Centerで異なります。Salesforceが詳細な根本原因分析を公開していない場合、本稿ではそれを推測していません。