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

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

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

インシデント履歴、調査、解決状況、復旧タイムラインを表示する汎用的なエンタープライズサービスステータスダッシュボード — 一般的なサービス状況ダッシュボードは、チームが障害発生のタイムラインを再構築する際に確認する段階を示すものであり、概念的な図解であって、実際のSalesforceのスクリーンショットではありません。

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

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

日付	混乱	記録が示すもの	なぜそれが重要なのか
2月7日	サービスの中断	公式の事故記録によると、障害は協定世界時（UTC）11時21分に終了し、約2時間20分間続いた。	広範囲にわたるサービス障害は、根本原因が公表されていない場合でも、Salesforceの通常の業務に影響を与える可能性があります。
6月10日	クロスクラウド認証の失敗	Salesforceは、Heroku、Commerce、Marketing Cloud、およびSalesforceサービスの認証サービスに影響が出ていると報告した。	ログインやIDの依存関係は、すべての製品に同じ技術的障害が発生していなくても、製品間で障害を引き起こす可能性があります。
6月10日	Herokuプラットフォームの破壊的変革	Herokuは後に、このインシデントの原因はベンダーが本番環境のインフラストラクチャに意図せずシステムアップデートを適用したことにあると発表した。Herokuのステータスサイトも影響を受けた。	通信チャネル自体がインシデントの一部となる可能性があるため、独立した通知経路が不可欠となる。
6月18日	インディアナポリスのデータセンターでネットワーク障害が発生	セールスフォースは、インディアナポリスのデータセンターにおける冷却システムの故障により、スタック1とスタック6に影響が出たと発表した。	物理インフラに関する事象は、世界規模の停電ほど広範囲には及ばないものの、関係する事例にとっては深刻な事態となる可能性がある。
11月1日	インスタンスレベルのコアサービスの中断	公式のインシデント記録では、IND76が影響を受けたインスタンスとして特定され、この事象は解決済みとして記録されています。	インスタンスごとのチェックは、「Salesforceがダウンしているか？」といった大まかなレポートだけに頼るよりも有用です。
12月31日	WhatsAppメッセージングのパフォーマンス低下	Salesforceは、複数のインスタンスでWhatsAppのメッセージング機能にパフォーマンス上の影響が出たと報告し、その後、協定世界時（UTC）16時56分に復旧したことを確認した。	ある機能が損なわれていても、CRMのその他の部分は引き続き使用可能である場合がある。

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時に利用可能になったとしても、連携キューに障害発生期間中の失敗メッセージが残っている場合、ブラウザが読み込まれたというだけでインシデントをクローズすべきではありません。正しいテスト方法は、新規および以前に失敗したケース更新情報が重複することなくワークフロー全体を通過するかどうかを確認することです。

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

事業状況	実用的な最低限	追加するタイミング
少人数のチームなので、短時間の中断は許容範囲内です。	関連するトラスト通知を購読し、インスタンス識別子を記録し、簡単な手作業チェックリストを維持してください。	顧客履歴やコンプライアンス記録が重要な場合は、エクスポートおよび復旧テストを追加してください。
収益、コンタクトセンター、サービス業務は、終日Salesforceに依存している。	独立した監視システム、ダウンタイム手順、統合再試行制御、およびインシデント担当者の指定を実施してください。	実際の障害発生前に、営業時間中にフェイルオーバーまたは代替の受信チャネルのテストを実施してください。
SalesforceはHerokuや複数のクラウドと連携している	各製品のステータスソースを監視し、認証の依存関係を個別に文書化する。	ログイン、API、キュー、顧客との通信を同時にテストする合同復旧演習を実施する。
規制対象データまたは高価値データ	承認済みのバックアップおよびデータ保持設計、アクセス制御、監査証跡、および復旧手順書を使用してください。	運用マニュアルを、セキュリティ部門、法務部門、コンプライアンス部門、および事業責任者にレビューしてもらってください。

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

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

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

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

情報源と範囲

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