Datorama(マーケティングクラウド)がダウン?マーケターが知っておくべきこと

Marketing Cloud ダッシュボードが突然読み込みを停止した場合、最も迅速な対応は、Datorama 自体がダウンしていると決めつけることではありません。Salesforce は現在、Datorama をMarketing Cloud Intelligenceと呼んでおり、同社の公式 Trust サイトでは、Salesforce 全体のインシデントとは別に製品の可用性を報告しています。2026 年 9 月 16 日現在、Salesforce Trust では Marketing > Intelligence が利用可能と表示されています。これは、Salesforce サービス全体の問題、コネクタの障害、ソース プラットフォームの停止、権限の問題、データ取り込みの遅延など、マーケティング担当者のデスクから見るとすべて似たような問題に見える可能性があるため重要です。

次の架空の例を考えてみましょう。有料メディア担当のマヤは、役員会議の45分前に朝のキャンペーン進捗状況ダッシュボードを開きます。いくつかのKPIタイルが読み込み中のままで、昨日の支出が表示されず、レポートのエクスポートも1つ失敗しています。彼女の最初の直感は「Datoramaがダウンしている」というものでした。しかし、すぐにキャンペーンを一時停止したり予算を変更したりするのではなく、彼女はこの状況を可用性の問題として捉えます。このように区別することで、レポートの問題がマーケティング上の意思決定ミスに発展するのを防ぐことができるのです。

マーケティング分析ダッシュボードが表示されたノートパソコン。ダッシュボードには、読み込み中の指標、利用できないレポートデータ、およびサービスステータスチェックリストが表示されている。
指標が停止し、ステータスチェックパネルが表示されたマーケティング分析ダッシュボードは、障害発生時にマーケターが最初に答えるべき質問を示しています。つまり、分析サービスが利用できないのか、それとも問題はデータ、アクセス、または接続されたソースに限定されているのか、ということです。

まず、今日の「Datoramaダウン」の意味を知りましょう。

Datoramaは、Salesforce Marketing Cloud Intelligenceの旧名称です。Salesforceは、この2つの名称が同じ製品を指していることを確認しています。このプラットフォームは、複数のソースからのマーケティングデータを接続、統合、分析、視覚化するように設計されています。社内で「Datorama」という名称を使用しているチームがあっても問題ありませんが、公式のステータスページやサポートページでは、現在一般的にMarketing Cloud Intelligenceという名称が使用されています。

名称や製品範囲については、Salesforceの公式マーケティング分析ページおよびMarketing Cloud Intelligenceのヘルプドキュメントで確認できます。

また、重要な製品の違いもあります。Marketing Cloud Intelligenceは、Marketing Cloud EngagementにバンドルされているIntelligence Reportsとは必ずしも同じものではありません。Salesforceでは、これらはアカウントやテナントの要件が異なる別々のレポートサービスとして文書化されています。同僚が「Marketing Cloudのレポート機能がダウンしている」と言った場合は、結論を出す前に、どちらの製品を指しているのかを確認してください。

Salesforceの公式ステータスで現在発表されている内容

最も信頼できる公開チェックポイントはSalesforce Trustです。2026年9月16日現在、Salesforce Trustの可用性ページでは、マーケティング > インテリジェンスが利用可能と表示されています。Salesforceは、顧客が現在のインシデント、メンテナンス、影響を受けるインスタンス、およびサービス履歴を確認できる専用のステータスサイトも提供しています。

これは、すべての顧客が正常な動作を経験していることを証明するものではありません。Salesforceのステータスはあくまで一つの指標であり、テナント、ワークスペース、コネクタ、および上流データソースのテストに代わるものではありません。つまり、公式のインシデント報告やテナント固有のチェックによって裏付けられない限り、「Datoramaがダウンしています」という見出しや社内メッセージを使用する際は、マーケティング担当者は注意する必要があるということです。

Salesforceのサポートガイドラインでは、Marketing Cloud Intelligenceに関するサポートケースを開設する前に、Trustサイトを確認することを推奨しています。また、技術的な問題を報告する際には、ビジネスへの影響、スクリーンショット、再現手順、想定される動作、関連するワークスペース、ウィジェット、またはピボットテーブルの識別子を含めるよう顧客に求めています。

架空のシナリオを使用して、4つの異なる故障タイプを分類します。

さて、マヤの話に戻りましょう。彼女はKPIが空白でエクスポートが失敗したことに気づきます。これらの症状は確かに存在しますが、原因を特定するものではありません。問題を分類するのに役立つ方法は、4つのレイヤーをテストすることです。

考えられる問題マーケターが見るかもしれないもの確認すべき事項
プラットフォームの可用性ログイン失敗、ダッシュボードの広範囲にわたるエラー、複数のワークスペースが利用不可Salesforceの信頼度、ステータスインシデント、影響を受けるインスタンス
データ取り込みまたはコネクタの問題ダッシュボードは読み込まれるが、最新のデータが欠落しているか、古い。データストリームの状態、ソース認証情報、アップストリームプラットフォームの可用性、更新タイミング
ワークスペースまたはアクセスに関する問題一部のユーザーや資産は障害を起こすが、他のユーザーや資産は正常に動作する。ユーザーロール、権限、ワークスペーススコープ、最近の構成変更
レポートまたは視覚化の問題特定のウィジェット、ページ、エクスポート、または計算が失敗する影響を受けるアセットID、フィルター、日付範囲、データモデルの変更、ブラウザの動作

マヤのケースでは、TrustサイトでIntelligenceが利用可能と表示され、別のチームメンバーが同じワークスペースを開くことができ、有料メディアソースのうち1つだけが昨日のデータを欠落していると仮定します。この場合、証拠は製品全体の障害ではなく、より限定的な取り込み側またはソース側の問題であることを示唆しています。そうなると、対応策は完全に変わります。

キャンペーンを変更する前にマーケターがすべきこと

分析機能の障害発生時に最も大きな運用リスクとなるのは、ダッシュボードそのものではありません。不完全または古いデータに基づいて、取り返しのつかないキャンペーン決定を下してしまうことです。レポートの内容が不確かな場合は、影響を受ける指標を未検証としてラベル付けし、欠落しているデータをパフォーマンスゼロとして扱わないようにしてください。

例えば、マヤはダッシュボードから支出やコンバージョンが消えたという理由だけで、チャネル予算を削減すべきではありません。最後に正常に動作したタイムスタンプを比較し、ネイティブ広告プラットフォームやソースシステムを確認し、不一致が1つのソースに影響しているのか、複数のソースに影響しているのかを把握する必要があります。分析レイヤーに行が欠落しているからといって、基となるキャンペーンの配信が停止したという証拠にはなりません。

実用的な意思決定ルールとして、行動を可逆的なものと不可逆的なものに分けることが挙げられます。レポートの再実行、ネイティブプラットフォームの確認、緊急性の低い最適化の延期などは可逆的な行動です。一方、高額なキャンペーンの一時停止、多額の予算の振り替え、経営陣への最終的なROIの報告などは不可逆的な行動となる可能性があります。データの整合性が不確かな場合は、影響の大きい変更を行う前に検証を優先すべきです。

問題を誇張せずに伝える方法

障害発生が疑われる場合、社内での表現は重要です。「Datoramaが世界的にダウンしています」という表現は、「Marketing Cloud Intelligenceダッシュボードが更新されません」という表現よりもはるかに説得力があります。後者の表現は、チームが実際に把握している状況を正確に表しているからです。

マヤは関係者に対し、「現在、Marketing Cloud Intelligenceビューに最新の有料メディアデータが欠落しています。Salesforce TrustではIntelligenceが利用不可とは表示されていませんが、予算決定のためにダッシュボードを使用する前に、影響を受けているコネクタとソースデータを確認しています。最後に確認されたレポートポイントは昨日の締め切り時点です。」と伝えることができます。

このメッセージは、観測された影響と未確認の原因を区別する点で有用です。また、意思決定者にとって明確な境界線を示します。つまり、どの指標が影響を受けているのか、何がまだ信頼できるのか、そしてどの行動を待つべきなのかが明確になるのです。

Salesforce全体でインシデントが発生している場合

製品固有のインテリジェンスタイルが正常に見えても、Salesforce 全体のインシデントが重大な影響を及ぼす可能性があります。共有認証、コアサービス、サポートアクセス、API、または依存コンポーネントは、ユーザーが製品にアクセスしたり操作したりする方法に影響を与える可能性があります。適切な対応は、すべての Salesforce 製品が障害を起こしたと決めつけるのではなく、インシデントにリストされているサービスとインスタンスを自社のテナントと比較することです。

Salesforceは、公式のインシデントチェックガイドで、進行中のインシデントとメンテナンスを確認する方法を説明しています。また、サービスステータスガイドでは、「利用可能」、「パフォーマンス低下」、「サービス中断」、「メンテナンス」などのステータスの意味についても解説しています。

マヤにとって、これは、インシデントIDが存在する場合はそれを記録し、影響を受けたインスタンスまたはサービスをメモし、役員会議中はステータスページを開いたままにしておく必要があることを意味します。該当するインシデントがない場合は、包括的な修正をただ待つのではなく、より詳細な診断を継続する必要があります。

問題が解決するまで、報告経路を保護する。

Marketing Cloud Intelligenceは、Salesforceの外部から始まることが多いレポートチェーンの中に位置づけられています。広告プラットフォーム、Web分析、CRMシステム、コマースシステム、ファイルアップロード、API、データベースフィードなど、あらゆるものがデータ提供元となり得ます。Salesforceのドキュメントでは、Marketing Cloud Intelligenceは複数のマーケティングソースを接続し、統合するシステムであると説明されています。このアーキテクチャは強力ですが、同時に、上流で古いレポートが生成される可能性もあることを意味します。

システム障害発生時には、簡単な証拠ログを保存してください。具体的には、最初に障害が発生した時刻、最後に確認されたデータタイムスタンプ、影響を受けたワークスペースまたはレポート、影響を受けたソース、スクリーンショット、正確なエラーメッセージ、および最近の構成変更などを記録しておきましょう。サポートが必要になった場合、これらの詳細情報があれば、基本的な確認作業から始まる可能性を減らすことができます。

Salesforceの広範な問題が発生している最中にヘルプポータル自体が使いづらい場合は、証拠が失われないようにローカルで記録を続けてください。ケース作成が可能になったら、完全なタイムラインを提出してください。

ダッシュボードを再び安心して利用できるタイミングを知る方法

「ページが読み込まれる」だけでは不十分です。復旧には、可用性とデータ検証の両方が含まれるべきです。この仮想シナリオでは、Mayaは影響を受けたソースの更新が再開されるまで待機し、その後、同じ日付範囲の重要な指標の小さなセットをネイティブソースと比較します。また、最初の更新が完了したと仮定するのではなく、遅延したレコードが完全に到着したかどうかも確認します。

適切な復旧チェックには、次の3つの項目が含まれます。関連するSalesforceステータスが正常であること、影響を受けたデータストリームが想定されるタイムスタンプに追いついていること、そして複数の高価値指標が、チームが既に使用している通常の許容範囲内に収まっていること。これらのチェックのいずれかが失敗した場合は、レポートを「完全に復旧」ではなく「復旧中」としてマークしてください。

Salesforceでは、インスタンスのサービス履歴も提供されており、これにより、障害がデータやアクセスに関する問題が発生した期間と重なっていたかどうかをチームが把握するのに役立ちます。Salesforceのサービス履歴に関する手順を参照してください。

マーケターが覚えておくべきこと

「Datoramaはダウンしていますか?」という質問に対しては、根拠に基づいた回答が最善です。Datoramaは現在Marketing Cloud Intelligenceという名称になっており、障害発生を宣言する前に、Salesforce Trustの最新の公開ページを確認する必要があります。2026年9月16日現在、Salesforce TrustではIntelligenceが利用可能と表示されているため、問題が発生しているチームは、テナントアクセス、コネクタ、ソースプラットフォーム、データの鮮度、個々のレポートアセットについても調査する必要があります。

マヤの架空の朝から得られる教訓は単純だ。ダッシュボードの不具合は、プラットフォーム全体の障害の証拠ではなく、検証を促すサインとして捉えるべきだ。データが不確かな間はキャンペーンの意思決定を保護し、既知の情報のみを伝え、復旧を宣言する前に報告経路を検証する。このアプローチは、数分間推測するよりも時間はかかるが、後になって予算の誤りや不正確な経営報告を修正するよりははるかに速い。

コメントを残す

Collabora OnlineとONLYOFFICEの比較:RAMと編集遅延の測定

Collabora OnlineとONLYOFFICEの比較:RAMと編集遅延の測定

Collabora OnlineとONLYOFFICE Docsを同一サーバー上で、メモリ使用量、ドキュメントのオープン時間、共同編集の遅延について、再現可能なテストを用いて比較します。

ONLYOFFICE DocsとMicrosoft 365 Web:どちらが書式設定を保持できるのか?

ONLYOFFICE DocsとMicrosoft 365 Web:どちらが書式設定を保持できるのか?

ONLYOFFICE DocsとMicrosoft 365のWebアプリにおける文書、スプレッドシート、レイアウトの動作を比較し、簡単なテストでファイルに適した安全なエディターを選択してください。

ONLYOFFICEとExcelでスプレッドシートの数式が変わる理由

ONLYOFFICEとExcelでスプレッドシートの数式が変わる理由

数式の不一致の原因を構文、地域区切り文字、再計算、日付システム、またはサポートされていない関数に絞り込み、ワークブックを共有する前に検証してください。

ONLYOFFICEとLibreOfficeの比較:パフォーマンステストの結果

ONLYOFFICEとLibreOfficeの比較:パフォーマンステストの結果

最新リリースのデータから何が証明でき、何が証明できないかを確認し、同じファイルとコンピューター上で両方のオフィススイートを比較してください。

Calc VLOOKUP vs XLOOKUP: 適切な検索式を選択する

Calc VLOOKUP vs XLOOKUP: 適切な検索式を選択する

完全一致、左辺参照、欠損値処理、バージョンサポートなどを比較して、信頼性の高いCalcの数式を選択してください。

WriterとWordのページ番号の違い:スタイル、セクション、および再開

WriterとWordのページ番号の違い:スタイル、セクション、および再開

WriterのページスタイルとWordのセクションリンクが、ドキュメントを移動したときに表紙、ローマ数字、および番号の再開にどのように影響するかを学びましょう。

Pardus Software CenterかAPTか?適切なツールを選ぶ

Pardus Software CenterかAPTか?適切なツールを選ぶ

Pardus Software CenterとAPTコマンドを比較して、タスクに適した方法でパッケージの検索、インストール、削除、更新を行ってください。

Pardus 25.2 XFCE vs GNOME:公平なRAM比較

Pardus 25.2 XFCE vs GNOME:公平なRAM比較

Pardusが公表しているRAM要件が何を意味するのかを確認し、同じPC上で再現性のあるMemAvailable値を用いてXFCEとGNOMEを比較してください。

HamoniKR OSは企業向けデスクトップのニーズを満たすことができるか?

HamoniKR OSは企業向けデスクトップのニーズを満たすことができるか?

HamoniKR 8.0がビジネス向けデスクトッププランの中でどのような位置づけになるのか、韓国語に特化した機能がどのようなサポートを提供しているのか、そして本格的な展開前に確認すべき事項について見ていきましょう。

Gooroomセキュリティ:トラステッドブートとアイソレーションの実際の機能

Gooroomセキュリティ:トラステッドブートとアイソレーションの実際の機能

Gooroomの起動検証と実行時保護がどのように連携しているのか、「サンドボックス」とは何を意味するのか、そしてデバイス上でどの設定を確認すべきかを理解しましょう。