Salesforceは最近のAWS障害の影響を受けているのか？クラウドのせいにする前に確認すべきこと

Salesforceの動作が遅くなったり、ログインに失敗したり、連携機能が突然停止したりしたのと同時にAWSの障害に関するニュースが流れた場合、すぐに両者を関連付けたくなるでしょう。場合によってはそれが正しい診断となることもありますが、常にそうとは限りません。

2026年9月16日現在、最新のAWS障害に起因するSalesforceの大規模な障害を示す公式な証拠はありません。AWSは、中東（バーレーン）リージョンで大規模かつ長期にわたるサービス障害が発生しており、中東（UAE）リージョンの一部でも深刻な障害が発生していると報告し続けています。SalesforceはUAEを含む複数の国でAWS上でHyperforceワークロードを実行しているため、AWSの地域的な問題は一部のSalesforce顧客に影響を与える可能性があります。しかし、AWSが原因であると結論付ける前に、Salesforceの状況を特定の組織、インスタンス、リージョン、およびサービスレベルで確認する必要があります。

この記事では、何が確定していて何が確定していないのか、Salesforce環境が影響を受けているかどうかを確認する方法、そして公開されているステータスページを待つのをやめて、自分のネットワーク、ブラウザ、統合、またはテナントを調査すべきタイミングについて説明します。

運用アナリストが、2台のモニターで地域クラウドインフラストラクチャの状態ダッシュボードとCRMサービスの健全性ダッシュボードを比較している。 — 運用アナリストは、クラウドプロバイダーの健全性とアプリケーションレベルの状態を比較します。地域的なクラウド障害が発生したからといって、すべてのSalesforce組織が影響を受けるとは限りません。

最近発生したAWSの障害とは何ですか？

AWSの公衆衛生に関する歴史の中で、現在もなお大きな影響が見られる最新のAWS障害は、中東地域に集中している。AWSによると、物理的な損傷により、中東（バーレーン）リージョン（me-south-1）は利用できなくなっており、中東（UAE）リージョン（me-central-1）も深刻な影響を受けているという。

AWSは、影響を受けた施設が2026年3月の地域紛争中に物理的な損傷を受けたと報告しました。4月30日、AWSはバーレーンリージョンが引き続き利用できず、UAEリージョンも顧客アプリケーションを確実にサポートできないと発表しました。AWSは、影響を受けた顧客に対し、ワークロードを他のリージョンで復旧し、アクセスできないリソースは可能な限りリモートバックアップから復元するよう助言しました。

AWS Health ダッシュボードでは、現在および過去のイベントステータスを直接確認できます。AWS の説明によると、公開されているサービスヘルスビューには広範なサービスイベントが表示されますが、サインインしているお客様は、個別の AWS Health ビューでアカウント固有の問題を確認できます。

AWSが原因でSalesforceがダウンしているのですか？

2026年9月16日時点で入手可能な公開情報に基づくと、広くはそうではない。

Salesforceの公式ウェブサイトであるTrust Statusサイトは、Salesforce関連のインシデントを確認する主要な場所です。レビュー時点では、Salesforceは、現在広範囲に発生しているSalesforceの可用性問題の原因をAWS中東の障害に起因するものとするプラットフォーム全体のインシデントを公表していませんでした。

その違いは重要です。クラウドプロバイダーが特定のリージョンで深刻な障害を起こしても、そのプロバイダーを利用しているすべてのソフトウェア企業がグローバルにダウンするとは限りません。最新のSaaSプラットフォームは、多くの場合、複数のリージョン、アベイラビリティゾーン、ルーティングレイヤー、インフラストラクチャ環境にまたがって動作します。したがって、重要なのは「AWSで障害が発生しているか？」という問いだけでなく、「私のSalesforce組織、あるいはSalesforceが依存するサービスは、影響を受けるインフラストラクチャパスで動作しているか？」という問いなのです。

AWSはなぜSalesforceにとって重要なのでしょうか？

SalesforceのHyperforceアーキテクチャは、パブリッククラウドインフラストラクチャ上で多くのSalesforceワークロードを実行します。Salesforceの最新ドキュメントによると、Hyperforceはオーストラリア、ブラジル、カナダ、フランス、ドイツ、インド、インドネシア、イスラエル、イタリア、日本、シンガポール、南アフリカ、韓国、スウェーデン、スイス、アラブ首長国連邦、英国、米国など、複数の国のAWSで利用可能です。

Salesforceは、一部のHyperforceインスタンスが特定のAWSリージョンにマッピングされていることを文書で説明しています。例えば、インスタンスの場所に関するドキュメントには、Hyperforceが使用されている複数の地域に対応するAWSリージョンが記載されています。さらに同社は、顧客がSalesforceインスタンスを特定し、Salesforce Trustを使用してその場所とステータスを確認できると述べています。

Salesforceの公式インスタンスロケーションガイドおよびSalesforceのHyperforceデータレジデンシーに関するドキュメントを参照してください。

あなたはどのような結果を目指すべきでしょうか？

目標は単に赤または緑のステータスアイコンを見つけることではない。有用な診断は、次の3つの質問に答える必要がある。

範囲：この問題は全員に影響しているのか、特定のSalesforceインスタンス、特定の製品、特定の統合機能に影響しているのか、それとも組織のみに影響しているのか？
原因： Salesforceの公式インシデント、AWSの地域イベント、または問題がブラウザ、ネットワーク、認証設定、または統合に起因することを示す証拠はありますか？
次のアクション：ユーザーは待機すべきか、フェイルオーバーすべきか、後で再試行すべきか、ワークフローを変更すべきか、Salesforceサポートに問い合わせるべきか、内部依存関係を調査すべきか？

もしこれらの3つの質問にまだ答えられないのであれば、それは診断ではなく、状態観察に過ぎません。

自分のSalesforce組織が影響を受けているかどうかを確認するにはどうすればよいですか？

1. Salesforceインスタンスを特定します

Salesforceでは、設定の「会社情報」にある「インスタンス」フィールドを確認するか、Salesforce Trustでドメインを検索することをお勧めします。インスタンスの識別情報は、リージョンやインフラストラクチャグループによってサービスの状態が異なる場合があるため重要です。

Salesforceの公式手順は、「Salesforce組織のインスタンス情報の表示」に記載されています。

この段階での良好な結果とは、影響を受けている本番組織が実際に使用しているインスタンス名を把握していることです。同僚の組織、別のリージョンのサンドボックス、または一般的なSalesforceステータスの見出しから診断を行わないでください。

2. Salesforce Trustでそのインスタンスを検索する

Salesforce Trustにアクセスし、インスタンスまたはドメインを検索してください。現在発生しているインシデント、最近のインシデント履歴、および予定されているメンテナンスを確認してください。

Salesforceがインスタンスで発生している障害をリストアップし、その症状がユーザーが確認しているものと一致する場合、それはソーシャルメディアへの投稿や一般的なクラウド障害の見出しよりもはるかに強力な証拠となります。

Salesforce Trustでインスタンスが正常と表示されていても、そこで止まってはいけません。ステータスページは顧客からの最初の報告よりも遅れて反映される場合があり、問題が特定の機能、依存関係、またはごく一部のテナントのみに影響する可能性もあります。

3. AWSの公式イベントのタイミングと比較する

Salesforce組織がAWSを基盤とするHyperforce上で動作している場合は、Salesforceのインシデント発生期間と、該当するAWSリージョンのイベント発生期間を比較してください。意味のある相関関係を判断するには、両方のイベントが同じ月に発生しているだけでは不十分です。

例えば、Salesforce環境がヨーロッパのAWSリージョンでホストされている場合、バーレーンに限定された障害だけでは、障害の原因を説明できません。ワークロードや依存するサービスがUAEリージョンにある場合は、関連性がより高くなり、より詳細な検証が必要になります。

4. 何がまだ有効なのかをテストする

質の高いトラブルシューティングでは、同じページを繰り返し更新するのではなく、問題を絞り込むことができます。代表的なパスをいくつかテストしてみましょう。

ユーザーはログインできますか？
彼らは記録を公開できるのか？
アップデートを保存できますか？
APIリクエストは成功しますか？
アウトバウンドまたはインバウンドの統合が失敗していますか？
この問題は、ブラウザやネットワークを問わず発生しますか？
問題は特定の地域またはオフィスに限られていますか？

パターンが重要です。ログインが完全に失敗するケースは、単一の統合遅延とは異なる障害領域を示唆します。SalesforceのUIは正常でも、AWSホスト型システムへのミドルウェアフローが失敗した場合、実際の影響はSalesforce自体ではなく、Salesforceの下流にある可能性があります。

Salesforceは、統合がまだ機能していない状態でも、正常な状態と言えるのだろうか？

はい。これはクラウド障害発生時に最も重要な区別の1つです。

Salesforce組織は、AWS上でホストされているコンポーネントが通信している場合でも、完全に利用可能な状態を維持できる可能性があります。例としては、ミドルウェア、カスタムAPI、データパイプライン、ファイルサービス、IDコンポーネント、分析ジョブ、AWS上で実行されている外部アプリケーションなどが挙げられます。

そのような状況では、組織内の業務プロセスが失敗している場合でも、Salesforce TrustはSalesforceプラットフォームが正常であると正しく表示する可能性があります。

Salesforceのコア動作と外部依存関係の動作を切り離してテストすることは有効です。ユーザーがレコードの作成や編集はできるものの、外部サービスへの呼び出しがタイムアウトする場合は、外部依存関係とそのリージョンを調査してください。多くのユーザーやネットワークで基本的なSalesforceナビゲーションさえも失敗する場合は、Salesforceインスタンスの健全性がより重要になります。

9月上旬に報告されたSalesforceの問題はどうなったのでしょうか？

Salesforceは2026年9月初旬にいくつかのインシデントを公表したが、公開されているインシデント記録からは、それらが現在のAWS中東の障害によって引き起こされたとは断定できない。

例えば、Salesforceは9月5日に「AWS US」プラットフォームグループに影響を及ぼしたサービス障害を記録しており、これは約90分間続き、その後解決されました。また、Salesforceは9月6日から発生したRevenue Cloudの問題を報告し、調査の結果、最近のリリースが原因であると示しました。Salesforceはさらに、ChromeとEdge 153でUIが断続的にフリーズする問題について情報通知を公開し、これはSalesforceのインフラストラクチャの問題ではなく、サードパーティのブラウザの問題であると説明しました。

この教訓は重要です。複数の障害が、全く異なる理由で、ほぼ同時期に発生する可能性があるということです。ベンダーが実際に関連付けていない限り、Salesforceに関するあらゆる問題を「AWS障害」という括りで片付けるのは避けましょう。

AWSが実際に関与している可能性を示唆する兆候は何ですか？

複数の兆候が一致すると、証拠はより強固になる。

シグナル	それはあなたに何を伝えているのか
SalesforceインスタンスはAWSのHyperforce上に構築されています。	AWSへの依存関係は存在するが、それだけでは影響を証明するものではない。
インスタンスまたは依存サービスは、影響を受けるAWSリージョンにマッピングされます。	地域的な停電は技術的に関連性がある。
Salesforce Trust は、同時にインスタンスのインシデントを報告します	Salesforce側からは、影響があったことを示す直接的な証拠が得られている。
AWS Health は、同じリージョンと時間帯で劣化を報告しています。	インフラ関連の事象は、その症状と一致している。
複数の場所のユーザーが同じ障害を目撃する	純粋に地域的なオフィスやインターネットサービスプロバイダの問題である可能性は低くなります。
Salesforceコアは正常な状態を維持したまま、外部統合が1つだけ失敗した。	実際の障害箇所は、Salesforce本体ではなく、依存関係にある可能性がある。

ステータスページが表示されるのを待つのをやめるべきタイミングはいつですか？

公開されている情報と実際に目にする情報が一致しなくなった場合は、トラブルシューティングの方法を変更してください。

Salesforce Trustが緑色であるにもかかわらず、多数のユーザーが複数のネットワークから同じインスタンスにアクセスできない場合は、タイムスタンプ、リクエストID、エラーメッセージ、および影響を受けたユーザー名を記録し、Salesforceサポートケースを開設してください。影響を受けているのが1つのオフィスのみの場合は、グローバルなSaaS障害としてエスカレーションする前に、別のネットワークまたはモバイル接続と比較してください。

SalesforceのUIは正常に動作するのに統合が失敗する場合は、外部エンドポイント、DNS解決、証明書、キュー、APIエラーコード、およびその依存関係をホストしているクラウドリージョンを確認してください。Salesforceが運用していないコンポーネントに関するインシデントがSalesforceから投稿されるのを待たないでください。

問題がご自身が所有する AWS リソースに関係する場合は、公開ダッシュボードのみに頼るのではなく、サインインした AWS ヘルスダッシュボードを使用してください。AWS のドキュメントには、アカウント固有のヘルス情報は公開サービスビューとは異なる場合があることが明記されています。AWSヘルスダッシュボードのドキュメントを参照してください。

問題が実際に解決したかどうかは、どうすれば判断できますか？

ステータスページが緑色に戻ることは便利ですが、運用復旧はご自身のワークフローで確認する必要があります。

事件の終結を宣言する前に、以下の点を確認してください。

ユーザーは通常通りログインできます。
レコードの読み書きが成功しました。
APIのエラー発生率はベースラインに戻りました。
キューに登録された統合処理は、蓄積され続けるのではなく、むしろ減少している。
スケジュールされたジョブが再び実行されています。
手動フェイルオーバーまたは緊急構成はアクティブ状態を維持しません。
ビジネス上重要な取引は、最初から最後まで完了できる。

優れた成果とは、単に「ベンダーが解決済みと言っている」ということではありません。「ベンダーが解決済みと言っているだけでなく、私たちにとって重要なワークフローが異常なエラー率なく再び機能するようになった」という成果です。

現状における現実的な解決策は何でしょうか？

2026年9月16日現在、入手可能な公式情報では、最近のAWS障害によりSalesforce全体がダウンしていると断言することはできません。AWSで現在発生している最も深刻な障害は、バーレーンとアラブ首長国連邦の一部地域を中心とした地域限定的なものです。Salesforceは、アラブ首長国連邦を含む多くのHyperforce環境でAWSを使用しているため、SalesforceがホストするワークロードやSalesforceに接続するワークロードの中には、AWSに依存しているものがあります。そのため、地域ごとの検証は重要ですが、Salesforce全体の障害が必ずしも発生するとは限りません。

もし貴社が現在問題を抱えている場合、最も確実な解決策は次のとおりです。

Salesforceインスタンスを特定します。
Salesforce Trustでそのインスタンスを確認してください。
組織または障害が発生している依存関係がAWS上にあるかどうか、またどのリージョンにあるかを特定します。
正確な発生時間帯を比較する。
Salesforceコアを外部統合とは別にテストする。
公式発表で症状が説明できない場合は、証拠を添えて訴えてください。

このアプローチでは、広範な仮定に頼るのではなく、自社の環境に合わせた妥当な回答を得ることができます。ただし、公開されているステータスページではテナント固有の障害を即座にすべて把握することはできないため、本番環境でのインシデントの最終的な確認には、ベンダーのサポートと自社のテレメトリデータが必要になる場合があります。