SalesforceとAWS間の依存関係を理解する：何が何に依存しているのか

Salesforce を起動すると、機能が遅い、利用できない、またはエラーが表示されるといった問題が発生します。同時に、AWS の問題に関する報告も目にします。「Salesforce は AWS 上で動作しているのだから、原因は AWS に違いない」と結論づけたくなるかもしれません。確かに方向性としては正しい場合もありますが、実際の依存関係はもっと複雑です。Salesforce は、特にHyperforceを通じて AWS を幅広く利用していますが、Salesforce 環境やサービスの中には、他のインフラストラクチャを使用しているものもあります。そのため、AWS の障害は、すべての Salesforce 顧客やすべての Salesforce 製品を停止させることなく、一部の Salesforce ワークロードに影響を与える可能性があります。

実務上の問題は、SalesforceがAWSを使用しているかどうかだけではありません。実際には使用しています。重要なのは、Salesforceサービスのどの部分がどこでホストされているか、どのAWSリージョンまたはサービスに依存しているか、そして問題がSalesforce、AWS、独自の統合、あるいはそれらの間のネットワークパスのいずれにあるのかを特定することです。このガイドでは、最も簡単なチェックからより詳細なアーキテクチャまで、その依存関係について説明し、ご自身の状況を検証する方法を示します。

まず、SalesforceがHyperforceで何を意味しているのかを理解しましょう。

Hyperforceは、Salesforceアプリケーションを地域クラウド環境で提供するための、Salesforceのパブリッククラウドインフラストラクチャアーキテクチャです。SalesforceはHyperforceをCustomer 360の基盤となるインフラストラクチャと位置付けており、パブリッククラウドプロバイダーを利用して、地域ごとの可用性、データ所在地の明確化、セキュリティ制御、および拡張性を向上させています。

Salesforceによると、2026年9月現在、Hyperforceは複数の国でAmazon Web Services上で利用可能であり、Google Cloud Platformにも展開中とのことです。この違いは重要です。「SalesforceはAWSを使用している」のは事実ですが、「すべてのSalesforce組織がAWS上でのみ稼働している」わけではありません。Salesforceは、Salesforceが管理する自社インフラストラクチャも一部運用しており、個々のサービスはコア組織とは別のインフラストラクチャ上で稼働させることができます。

Salesforceの現在のインフラストラクチャの場所に関するガイダンスは、Salesforceヘルプの「Salesforceインスタンスはどこにありますか？」で確認できます。Salesforceは、SalesforceのHyperforceに関する一般的な情報とFAQで、より広範なHyperforceモデルについても説明しています。

SalesforceとAWSの依存関係はどの程度強いのか？

両者の依存関係は大きいものの、多層構造になっている。AWSは長年にわたりSalesforceにとって主要な戦略的クラウドプロバイダーであり、AWSは両社をグローバルな戦略的パートナーシップと位置付けている。SalesforceはHyperforceの展開にAWSのインフラストラクチャを利用しており、Amazon ConnectやAmazon BedrockといったAWSサービスとSalesforce製品を統合している。

顧客にとって、関係性を3つの層に分けて考えることは役立ちます。

この階層型モデルがトラブルシューティングの鍵となります。「Salesforceは稼働中です」というステータスページが表示されていても、AWSでホストされている統合が正常であるとは限りません。逆に、AWSの広範なイベントが発生しているからといって、特定のSalesforceインスタンスが影響を受けているとは限りません。

AWSの障害が必ずしもSalesforceのダウンを意味するわけではない理由

Salesforceによると、Hyperforceインスタンスは、該当リージョン内の3つのアベイラビリティゾーンにまたがるアクティブ/アクティブモデルを使用しているとのことです。アベイラビリティゾーン（AZ）とは、AWSリージョン内の隔離された場所のことです。アクティブ/アクティブ設計では、アプリケーションのキャパシティは複数のゾーンに分散され、1つのゾーンをコールドスタンバイとしてアイドル状態にしておくことはありません。Salesforceによれば、トラフィックは3つのゾーンすべてのアクティブなアプリケーションサーバーに分散され、データベースのレプリケーションによってゾーン間の一貫性が維持されます。

このアーキテクチャは、単一のアベイラビリティゾーンへの依存度を低減することを目的としています。あるアベイラビリティゾーンで局所的な問題が発生した場合でも、他のゾーンを通じてサービスを継続できるように設計されています。しかし、マルチアベイラビリティゾーンアーキテクチャは、あらゆる障害モードを排除するわけではありません。リージョン全体のサービス障害、コントロールプレーンの問題、ネットワーク障害、ソフトウェア障害、依存関係の障害、またはアプリケーションレベルのインシデントは、依然として可用性に影響を与える可能性があります。

つまり、正しい考え方はこうです。AWS上のSalesforceはAWSリージョン内で高い回復力を持つように設計されていますが、大規模なAWS障害発生時にはインフラストラクチャへの依存関係が重要になる場合があります。

Salesforceの一部のサービスは、コア組織とは独立して障害を起こす可能性があります。

多くのインシデント調査がここで失敗します。Salesforceは、特定のサービスが顧客組織と統合しながらも、別のインフラストラクチャ上で実行できることを明示的に述べています。たとえば、Sales Engagement、Einstein Activity Capture、Salesforce Inbox、およびEinstein Conversation Insightsに関するSalesforceのドキュメントには、これらのサービスは組織のSalesforce Coreインフラストラクチャとは別のAWSインフラストラクチャ上でホストされていると記載されています。

つまり、ユーザーは次のような状況を目にする可能性があるということです。

• SalesforceへのログインとコアCRMレコードは正常に動作します。
• 特定の生産性、またはアインシュタイン関連のサービスが低下します。
• この問題は、Salesforceの中核組織ではなく、別のインフラストラクチャに関連しています。

Salesforceは、Sales Engagement、Einstein Activity Capture、Salesforce Inbox、およびEinstein Conversation InsightsのHyperforce移行ガイダンスの中で、この分離について説明しています。

トラブルシューティングは、最も簡単なチェック項目から始めましょう。

1. AWSが責任を負っていると決めつける前に、Salesforceの信頼性を確認してください。

まずはSalesforceの公式ステータスと信頼性情報を確認してください。「Salesforceがダウンしています」といった一般的な報告に頼るのではなく、ご自身のSalesforceインスタンスのステータスを正確に把握することが重要です。Salesforceでは、「Salesforce組織のインスタンス情報の表示」で、組織のインスタンスを特定する方法を説明しています。

Salesforce の設定で、クイック検索ボックスを使用して「会社情報」を探し、次に「インスタンス」フィールドを探します。Salesforce によると、AP0 のような 2 文字のインスタンスプレフィックスは Salesforce が管理するファーストパーティ インフラストラクチャを示し、GBR10 のような 3 文字のプレフィックスは Hyperforce インフラストラクチャを示します。

2. Hyperforce組織がAWS上にあるかどうかを確認します。

Hyperforceインスタンスは、必ずしもAWSと常に同じであるとは限りません。Salesforceは、HyperforceはAWSで利用可能であり、Google Cloud Platformにも展開していくと述べています。特定のHyperforceインスタンスがAWS上にあるかGCP上にあるかを確認する必要がある顧客は、Salesforceカスタマーサポートに問い合わせるよう、Salesforceのドキュメントで推奨しています。

これは、インシデントの相関関係を把握する上でますます重要になっています。「Hyperforce」という単語だけを根拠に「AWS」と結びつけるべきではありません。

3. 関連する場合にのみ、特定のAWSリージョンを確認してください。

組織または影響を受けるSalesforceサービスがAWS上で稼働していることを確認済みであれば、リージョンを特定してください。Salesforceの現在のロケーションに関するドキュメントには、Hyperforceリージョンとそのパブリッククラウドプロバイダーが記載されています。たとえば、Salesforceは、シドニー、ムンバイ、東京、シンガポール、ロンドン、フランクフルト、カナダ中央、および複数の米国リージョンなど、AWSを基盤とするHyperforceリージョンをリストアップしています。

次に、Salesforceのインシデントを、そのリージョンとサービスに関連する公式のAWS Health情報と比較してください。あるAWSリージョンで発生した問題を、無関係なSalesforceリージョンの問題の証拠として扱うことは避けてください。

4. Salesforceのホスティングを独自のAWS統合から分離する

Salesforce自体に問題がない場合は、統合パスを確認してください。顧客側の一般的な依存関係には、APIゲートウェイ、Lambda関数、Amazon Connect、データベース、キュー、プライベートエンドポイント、VPN、DNS、および企業ネットワーク制御が含まれます。これらのコンポーネントのいずれかに障害が発生すると、Salesforceワークフロー内でエラーが発生するため、ユーザーには「Salesforceの問題」として認識される可能性があります。

有効なテスト方法として、AWSサービスを呼び出さずに同じSalesforce操作を成功させることができるかどうかを自問してみることが挙げられます。もし成功できるのであれば、コア組織は正常であるものの、統合パスで問題が発生している可能性があります。

AWS Direct Connectについてはどうでしょうか？

一部の組織は、AWS へのプライベートネットワーク接続であるAWS Direct Connect を使用して、AWS 上の Hyperforce のネットワーク要件をサポートしています。Salesforce は、プライベート接続、コンプライアンス、またはデータ所在地の要件を持つ組織向けに、特定の Hyperforce メールトラフィックを AWS Direct Connect 経由でルーティングするユースケースを文書化しています。

これにより、依存関係のレイヤーがさらに増えます。プライベート接続が関係する場合、インシデントはSalesforce自体ではなく、ユーザーとSalesforceの間で発生する可能性があります。関連するSalesforceのドキュメントは、「Hyperforce向けAWS Direct Connectを介したメールのルーティング」です。

SalesforceがマルチクラウドのHyperforceモデルへと移行する理由

Salesforceは、Hyperforceが複数のパブリッククラウドプロバイダー間で動作するように設計されていると説明しています。これにより、すべてのSalesforceワークロードの基盤として単一のハイパースケーラーを恒久的に使用しなければならないというアーキテクチャ上の前提が軽減されます。Salesforceの2026年のドキュメントによると、HyperforceはAWSで利用可能であり、Google Cloud PlatformのサポートはSalesforceのロードマップ公開に基づき、一部のリージョンで導入される予定です。

お客様にとって、これはAWSの障害発生時に既存のSalesforce組織がAWSからGoogle Cloudに自動的にフェイルオーバーすることを意味するものではありません。マルチクラウドサポートは、主にSalesforceがプラットフォームをデプロイおよび運用できる場所に関するものです。Salesforceがお客様が使用するサービスについて明示的にドキュメント化しない限り、プロバイダー間のフェイルオーバーが想定されるべきではありません。

SalesforceとAWSのパートナーシップはホスティングにとどまらない

この関係は、インフラストラクチャのホスティングだけにとどまりません。AWSとSalesforceは、データ、AI、コンタクトセンター機能、統合、調達など、より広範な戦略的パートナーシップを構築しています。AWSの公式パートナーシップページでは、生成型AIやデータ管理機能など​​、Salesforce製品とAWSテクノロジーを組み合わせた統合事例が紹介されています。この関係の詳細は、AWSとSalesforceの公式パートナーシップページでご確認いただけます。

これはアーキテクチャレビューにおいて重要です。なぜなら、依存関係に関する2つの異なる問題が存在するからです。

• Salesforce自体はどこで動作しているのか？それはホスティング環境に依存する問題です。
• Salesforceとの接続にどのAWSサービスを選択しましたか？それは、お客様が制御できる統合依存関係です。

これら2つの依存関係は、それぞれ異なる所有者、監視経路、復旧手順、およびサポートチームを持っています。

実用的なインシデントチェックリスト

ユーザーからSalesforceが利用できない、または部分的に不具合が発生しているとの報告があった場合は、以下のチェック項目を順番に確認してください。

1. 影響を受けるSalesforceの機能を正確に確認してください。「Salesforce」というだけでは不十分です。
2. Salesforceインスタンスを見つけて、その公式Salesforceトラストステータスを確認してください。
3. 組織がSalesforce管理のインフラストラクチャ上にあるか、Hyperforce上にあるかを判断します。
4. Hyperforceを使用している場合は、該当するデプロイメントがAWSを使用しているかどうかを確認してください。
5. 関連性があると確信できた場合にのみ、AWSリージョンを指定してください。
6. 障害が発生している機能が、コア組織とは独立してホストされている別のSalesforceサービスであるかどうかを確認してください。
7. 実際に障害の原因となっている依存関係が、自社のAWS統合、プライベートネットワーク、DNS、API、またはコンタクトセンターサービスであるかどうかをテストしてください。
8. タイムスタンプとリクエストIDを記録しておけば、SalesforceサポートまたはAWSサポートが障害の原因を特定できます。

結論を検証する方法

複数のレイヤーで証拠が一致すれば、診断の確度が増していることがわかります。Salesforce Trustがお客様のインスタンスで発生したインシデントを報告し、影響を受けた機能が症状と一致する場合、Salesforce側に問題がある可能性が高いです。Salesforce自体は正常であるにもかかわらず、同じ時間帯にAWS統合テストが失敗した場合は、お客様側のAWS依存関係に問題がある可能性が高いです。SalesforceのコアCRM機能が正常に動作している一方で、Salesforceアドオンが1つだけ影響を受けている場合は、そのサービスの個別のインフラストラクチャと状態を調査してください。

「AWSで障害が発生した」とか「Salesforceがダウンした」といった情報だけで判断してはいけません。信頼できる回答を得るには、インスタンス、製品、リージョン、そして統合パスを照合する必要があります。

結論

SalesforceはAWSに大きく依存しており、特にHyperforceの多くのデプロイメントやサポートサービスがAWSインフラストラクチャ上で稼働しているため、その依存度は高い。しかし、この依存は普遍的でも一面的でもない。Salesforceは自社インフラストラクチャも運用しており、Hyperforceを複数のパブリッククラウドプロバイダーに展開し、顧客のコア組織とは別に個々のサービスをホストすることも可能だ。

運用チームにとって最適なアプローチは、SalesforceとAWSを単一のスタックとしてではなく、依存関係グラフとして扱うことです。コア組織がどこで稼働しているかを特定し、個別にホストされているSalesforceサービスをマッピングし、顧客が管理するすべてのAWS統合を文書化し、各レイヤーを個別に監視します。そうすることで、「Salesforceに問題が発生した」という状況から、実際に注意が必要な特定のコンポーネントまで、はるかに迅速にたどり着くことができます。