MuleSoftで「障害かな？」と思ったら：最初の30分で行う切り分けとサポートケースの書き方

公開日 : 2026.09.02

― Anypoint Platform 運用者向けの初動ガイド

この記事の位置づけ：「障害かもしれない」と気づいてから最初の30分で、①影響範囲の整理、②プラットフォーム起因かアプリ起因かの一次切り分け、③サポートケースを出すか・自分たちで対処するかの判断、まで進めるための初動ガイドです。目的は「30分で直す」ことではなく、30分後に「次に何をするか」が決まっている状態をつくることです。正解を一律に示すのではなく、確認の観点を提供します。

スコープ：本記事は「最初の30分の初動」に絞ります。個別製品の詳細なトラブルシューティング、根本原因分析、恒久対策の設計、パフォーマンスチューニングは対象外です。

対象読者・前提
想定シナリオ
最初の30分の流れ
サポートケースの書き方
初動チェックリスト（この記事のまとめ）
よくある誤解・アンチパターン
関連リンク（公式・主要のみ）

対象読者・前提

Anypoint Platform を運用する管理者・IT 担当の方
CloudHub 1.0 / CloudHub 2.0 / Runtime Fabric のいずれかでアプリケーションを稼働中
Anypoint Platform へのログイン権限と、サポートケースを起票できる権限（またはその担当者への連絡経路）がある

想定シナリオ

月曜 9:05、業務部門から「基幹システムとの連携が動いていないようだ」と連絡が入りました。画面にエラーの詳細はなく、「金曜までは動いていた」とのこと。監視アラートは飛んでいません。ここから30分で何をするか。

先にお読みください（緊急時のショートカット）：主要業務が停止していて許容可能な回避策がない場合や、データ破損・セキュリティの懸念がある場合は、この30分の手順を最後まで待つ必要はありません。調査と並行して、サポートケースの起票（重要度レベル1・2）と電話連絡を開始してください。情報がすべて揃っていなくても起票はでき、不足分は同じケースに追記すれば十分です（起票先と電話窓口は後半の「起票の場所」、書き方は「サポートケースの書き方」を参照）。復旧のために再起動を急ぐ場合も、「再起動は、証拠を確保してから」だけは先に目を通してください。

最初の30分の流れ

0–5分：影響範囲を3つの質問で整理する

何が：どの API／アプリ／業務が影響を受けているか（すべてか、特定のものだけか）。事象は「エラーが出る」のか「遅い」のか「応答しない」のかも区別する
いつから：最後に正常だったのはいつか（時刻＋タイムゾーン）。「たぶん金曜の夜から」でも仮置きでよいので記録する。現在も継続しているかも確認する。可能なら、現象が発生している時刻をできるだけ正確に把握しておく（テストリクエストを送って再現できる場合は、その時刻・リクエスト先の URL・パラメータもあわせて記録しておくと、調査が速くなります）
どこまで：影響ユーザーは全員か一部か。業務は「止まっている」のか「遅い」のか

この3つのメモが、後のケース起票の核になります。関係者への一次報告（「調査中。影響は◯◯、続報は◯時」）もこの時点で出せます。

5–10分：プラットフォーム状況を確認する

MuleSoft のステータスページを確認：https://status.salesforce.com/products/mulesoft で障害情報・メンテナンス情報を確認します
ステータス通知は事前に登録できます：障害・メンテナンス情報はメール等で受け取れます。登録手順は「Trust通知の登録」— https://help.salesforce.com/s/articleView?id=xcloud.subscribe_to_trust_notifications.htm&language=ja&type=5 を参照してください。平時に登録しておくと、発生時の確認が速くなります
あわせて、依存している外部サービス（接続先の SaaS・社内システム・ネットワーク）の状態も確認します

10–20分：プラットフォーム起因かアプリ起因かを一次切り分けする

まず全体像の観点：

複数の無関係なアプリで同時に発生 → プラットフォーム／共通基盤起因の可能性
特定のアプリ・特定の処理だけ失敗 → アプリ／データ／接続先起因の可能性
特定の接続先だけ失敗 → 相手システム・ネットワーク・証明書まわりの可能性

次に、事象の種類ごとの最初の一手（Runtime Manager／Anypoint Monitoring で確認）：

「エラーが出る」場合：Runtime Manager から対象アプリケーションのログを確認し、エラーメッセージの全文とスタックトレース全体を確保する。どのアプリ・どの処理で起きているかを特定し、直近にアプリ・ランタイム・コネクタのバージョンアップがなかったかを確認する。Anypoint Monitoring では Failures 系のメトリクス（エラー数・失敗リクエスト数）を見る（補足：Failures は Mule フロー内で発生した例外と、アウトバウンド接続時に発生した例外を集計する指標です。HTTP 4xx／5xx の応答をすべて数えるものではありません）
「遅い」場合：全体的に遅いのか、特定の処理だけ遅いのかを確認する。Anypoint Monitoring の Performance（レスポンスタイム系）と Infrastructure（JVM CPU %・Heap 使用量）を確認し、通常時との差をメモする
「応答しない」場合：Runtime Manager でアプリの稼働状態と、直近の再起動・デプロイの有無を確認する。そのうえで、リクエストがそもそも届いているか（受信トラフィック）、JVM CPU %・Heap 使用量、接続先への到達性、処理の滞留（キュー・未処理件数）を順に確認する。無応答のまま再起動すると原因情報が失われやすいため、後述の「再起動は、証拠を確保してから」を必ず参照する

20–25分：直近の変更を確認する

「金曜まで動いていた」なら、金曜から今日までに何が変わったかを列挙します。

自分たち側：デプロイ、設定・プロパティ変更、証明書の更新・期限、権限変更
プラットフォーム側：メンテナンス・パッチ適用の予定（月次のリリース・メンテナンス情報記事を参照）
相手側：接続先システムの変更・メンテナンス・IP レンジ変更

25–30分：対処方針を決める

まず、サポートの対象範囲を確認します。製品の不具合やプラットフォーム側の問題はサポートケースの対象です。開発・実装に関する相談（Developer Support）は、含まれるトピックと含まれないトピックが公式に定義されています（「MuleSoft 開発者サポートリクエストトピック」— https://help.salesforce.com/s/articleView?id=000394496&language=ja&type=1 ）。

対象の例：アプリケーションエラーのレビューと解決への一般的なガイダンス、カスタム DataWeave のトラブルシュート。ビルドエラーの支援、CloudHub 接続性のトラブルシュート、フローレベルの性能ボトルネック調査、重大インシデント後のレビューなども対象ですが、一部は Signature ティア限定の範囲があります（上記の公式ページに「(Signature のみ)」と明記されています）
対象外の例：コードや設定ファイルの作成・修正（SQL を含む）、Java／Bash／Python コードのレビュー、フロントエンドのデバッグ、サードパーティ製品の設定・デバッグ、性能チューニングの実施やキャパシティプランニング、アプリケーションの設定・デプロイ・スケーリング設定の変更。これらは公式ドキュメントや Professional Services の領域です
なお、アプリの実装どおりにエラー応答が返っているケースでは、調査の支援は依頼できますが、修正は利用者側での対応になります

再起動は、証拠を確保してから。再起動すると、再起動前のログや診断情報の一部が取得できなくなります。保全の要点はデプロイ先により異なります（保全そのものは5分では終わらないこともありますが、再起動より先に実施する価値があります）。

CloudHub 1.0 の場合：全ワーカーで Mule Logs（mule_ee.log）・アプリケーションログ・Diagnostics（スレッドダンプ。対応ランタイムでは DIAF 形式。30～60秒間隔で複数回）をダウンロードしてから対処する。収集する情報の詳細：What Information to Collect Raising for a CloudHub Case — https://help.mulesoft.com/s/article/What-Information-to-Collect-Raising-for-a-CloudHub-Case
CloudHub 2.0 の場合：レプリカのローカルストレージは揮発性で、再起動するとローカルのファイル・一時データは失われます（セキュリティパッチ適用などでレプリカが自動再起動されることもあります）。Runtime Manager の Logs 画面から各レプリカのログを早めにダウンロードして確保する（ログの保持はデプロイ設定ごとに最大 100MB または 30日の、いずれか早く達したほうまで）。なおアプリケーションを更新すると新しいデプロイ設定が作成され、Logs 画面が空に見えることがあります（過去のログは設定を切り替えて参照します）。ロールバックや再デプロイを行う前にログを確保しておくと確実です。詳細：What Information to Collect for a CloudHub 2.0 Case — https://help.mulesoft.com/s/article/What-Information-to-Collect-for-a-CloudHub-2-0-Case
Runtime Fabric の場合：レプリカ（Kubernetes Pod）前提のため、ログの残り方は環境のログ転送設定に依存します。転送先でのログ確保とあわせて、公式ナレッジの収集手順に従う。詳細：What Information to Collect for an RTF Case — https://help.mulesoft.com/s/article/What-Logs-to-Collect-for-an-RTF-Case
OutOfMemory 系のエラーやアプリが応答しない場合は、可能な限り再起動前にサポートへ連絡してください。サポート側で稼働中のワーカー／レプリカから追加情報の収集が必要になることが多いためです。業務継続上許容できる場合は手動再起動を保留し、該当する重要度で起票します。復旧を最優先する場合は、取得できる範囲のログと、実施した操作の時刻・対象・結果を記録したうえで、自組織で承認されたインシデント対応手順に従って再起動してください

そのうえで方針を決めます：

プラットフォーム起因が疑われる／切り分けできない／業務影響が大きい → サポートケース起票へ（次章）
アプリ起因が濃厚で、直近変更のロールバック等で対処できそう → 自分たちで対処。ただし実施した変更は記録する

サポートケースの書き方

初動30分で確認した画面やデータは、多くの場合、サポートが提供を依頼する情報と重なります（画面のスクリーンショット、データの CSV エクスポート、Monitoring のグラフ等）。つまり初動のメモと収集物は、そのままケースの添付材料になります。二度手間にはなりません。

起票の場所

ケースは Salesforce Help ポータルから、Salesforce（Trailblazer）アカウントで起票します。Anypoint Platform の「?」メニュー → Support Center からもアクセスできます。画面つきの起票手順はサクセスナビの「Premier および Signature Success Plan におけるサポートケースの作成と管理方法について」— https://successjp.salesforce.com/article/NAI-000839 を参照してください
MuleSoft の日本語サポートの対応時間は平日 9:00～18:00（Titanium／Premier Success Plan の場合）で、営業時間外の問い合わせは英語での対応となります（対応時間・体制の詳細は契約プランにより異なります。公式記載：「Salesforce カスタマーサポートへの問い合わせ」— https://help.salesforce.com/s/articleView?id=005224387&language=ja&type=1 ）
夜間・休日に対応が必要な場合：日本の営業時間外は、海外のサポート窓口（英語）による対応となります。緊急の場合は、海外窓口に電話するか、Salesforce ヘルプサイトで画面左下の言語を「English」に設定してケースを起票します。チャットは24時間365日利用でき、営業時間外は同時翻訳機能（日本語）を介して海外のエンジニアが対応します。ただし、夜間・休日にチャットからケースに移行した場合、日本のエンジニアによる対応は翌営業時間からとなる点にご注意ください（詳細：「日本営業時間外のチャットサポートにおける考慮事項」— https://help.salesforce.com/s/articleView?id=005225103&type=1&language=ja ）
すでに起票済みのケースで夜間・休日の対応が必要になった場合は、日本の営業時間内にケースコメントでその旨をお知らせください。グローバルサポートへの引き継ぎが可能です（時間外は英語での対応となります）
緊急度の高いケース（重要度レベル1・2 相当）は、起票に加えて電話での連絡が推奨されています（窓口・手順は上記の公式ページを参照）

ケースに書く情報

まず必須（どのケースでも最初に必要）

組織情報：Organization ID と Business Group 名
環境：環境名（Production／Sandbox 等）、デプロイ先（CloudHub 1.0／2.0／Runtime Fabric）、リージョン
対象：アプリケーション名（API の場合は API 名・バージョンも）。デプロイ先が CloudHub の場合、アプリケーション名が正確だとサポート側で詳細情報を直接確認できる場合があります
ランタイム：Mule Runtime のバージョン
発生日時：開始時刻～現在（タイムゾーン付き。例：2026-08-17 09:05 JST～継続中）。「最後に正常だった時刻」もあると切り分けが速い
事象：種別（エラー／遅い／無応答）と、現在も継続しているか
エラー内容：エラーメッセージの全文とスタックトレース全体をテキストで
ログ：該当時間帯（前後を含む）のアプリケーションログ・Mule Logs
業務影響：どの業務にどう影響しているか、影響規模、回避策の有無（重要度レベル1・2 で起票する場合は具体的に。あわせて夜間・休日の連絡可否と連絡先も記載。）
実施済みの切り分け：この記事の 0–30分でやったこと＋その結果

あると解決が速い

再現手順（再現しない場合は発生条件・頻度）
画面キャプチャ、関連データのエクスポート（CSV 等）、Anypoint Monitoring のグラフ（Monitoring の情報はスクリーンショットで提供します。取得できるタイミングで撮っておくと確実です）
わかる範囲で、問題が起きているフロー名・処理箇所（開発チームに確認できれば）
回答希望日とその理由（期日を保証するものではありませんが、優先度の判断材料になります）
（CloudHub 1.0／CloudHub 2.0 の場合）サポートがワーカーやレプリカにアクセスして詳細ログを取得することの可否（取得はアプリの実行にわずかに影響し得ます）

添付前の確認（機密情報）：ログ・スタックトレース・CSV・画面キャプチャには、認証情報（パスワード・トークン・API キー）や個人情報・顧客データが含まれることがあります。ケースに載せる情報は必要最小限にし、社内ルールに従ってマスキングしてから添付してください。

また、製品カテゴリごとに「What Information to Collect for ◯◯ cases」という公開ナレッジが用意されています。該当製品のナレッジを起票前に確認すると、最初の往復を減らせます。例：

What Information to Collect for Anypoint MQ cases — https://help.mulesoft.com/s/article/What-Information-to-Collect-for-Anypoint-MQ-cases
What information to collect for Anypoint Connector related issues — https://help.mulesoft.com/s/article/What-information-to-collect-for-Anypoint-Connector-related-issues
What Information to Collect Raising for a CloudHub Case — https://help.mulesoft.com/s/article/What-Information-to-Collect-Raising-for-a-CloudHub-Case
What Information to Collect for a CloudHub 2.0 Case — https://help.mulesoft.com/s/article/What-Information-to-Collect-for-a-CloudHub-2-0-Case
What Information to Collect for an RTF Case — https://help.mulesoft.com/s/article/What-Logs-to-Collect-for-an-RTF-Case

記入例

件名：受注連携アプリで接続タイムアウトが継続発生

アプリケーション名：order-sync-app（Runtime 4.9／CloudHub 1.0・Tokyo／Production）

発生日時：2026-08-17 09:05 JST 頃～継続中（最後の正常確認：08-14 23:00 JST）

事象：基幹 API への送信が 60 秒でタイムアウト（エラー全文・ログ・スタックトレース添付済み）

再現性：あり（手順を本文に記載）

業務影響：受注データの基幹反映が停止し回避策なし（約◯件／日が滞留）。受注の受付自体は継続できており、業務全体は止まっていない → 重要度レベル2で起票（受付も停止し回避策がなければレベル1）

実施済み：ステータスページ確認（該当情報なし）、直近の変更なし、再起動前にログ・Diagnostics 確保済み

連絡体制：平日 9:00～18:00 は担当◯◯（メール・電話）、時間外は当番窓口△△が対応可能

Severity（重要度）の選び方

重要度は「業務影響の大きさ × 回避策の有無」で選びます。技術的に珍しいかどうかではありません。目安：

業務が停止し、許容可能な回避策がない → レベル1
主要業務に影響しており、回避策がない → レベル2
主要業務に影響しているが回避策がある。または主要業務以外に影響し回避策がない → レベル3
主要業務以外への影響で回避策がある。または業務への影響がない → レベル4

重要度レベル1・2 で起票するときは、お客様側の対応体制もあわせてご検討ください。サポートの調査は、状況確認への回答、追加情報の提供、事象の再現といったお客様との連携を前提に進みます（Success Plan 約款「エラー再現」の項）。重要度が高いケースでは、このやり取りが日本の営業時間内に収まらないこともあり（営業時間外は英語での対応となります）、応答が止まると調査も止まります。対応できる時間帯と連絡先をあらかじめ決め、ケースに明記しておくとスムーズです（夜間・休日の対応が難しい場合も、その旨を書いていただければ前提として調整できます）。

正確な定義と目標一次応答時間は、契約プラン（Standard／Premier／Signature 等）の約款・公式情報を参照してください。なお「一次応答」は、内容と重要度を確認した旨の応答までの目標であり、回答・解決までの時間を約束するものではありません。

公式の定義：お問い合わせの重要度についての説明 — https://help.salesforce.com/s/articleView?id=000249281&type=1&language=ja
英語版ナレッジ：Severity Level descriptions for Salesforce Support Cases — https://help.salesforce.com/s/articleView?id=000382814&language=en_US&type=1
約款（Success Plan 別紙・日本語 PDF）：SUCCESS PLAN STANDARD、PREMIER、PREMIER+、SIGNATURE — https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/product-specific-terms/salesforce-standard-premier-signature-success-jp.pdf

なお、本番停止で回避策がないなら、レベル1をためらう必要はありません。重要度は「現在の」業務影響で選び、状況が変わったら（回避策が見つかった・影響が拡大した）同じケースの中で重要度の変更を相談します。

書き方のコツ

1ケース1論点：複数の問題は分けて起票する（混ぜると対応が分散して遅くなる）
時系列で書く：発生 → 確認したこと → 試したこと → 現在の状態
事実と推測を分ける：「◯◯というエラーが出た」（事実）と「◯◯が原因ではないか」（推測）を区別して書く
続報は同じケースに：新しいケースを立てず、同一ケースに追記する
関係者にも更新通知を：起票者以外もケース更新のメール通知を受け取れる「ケースコラボレーター」機能があります（最大20名。追加方法：「Salesforce ヘルプのケースコラボレーション」— https://help.salesforce.com/s/articleView?id=000386788&language=ja&type=1 ）

初動チェックリスト（この記事のまとめ）

影響範囲（何が・いつから・どこまで）と事象の種別をメモした
関係者に一次報告（影響範囲・調査中である旨・次の連絡時刻）を出した
status.salesforce.com（MuleSoft）を確認した
依存している外部サービス（接続先の SaaS・社内システム・ネットワーク）の状態を確認した
複数アプリか特定アプリかを確認した
該当時間帯のログ・スタックトレースを確認・確保した
直近の変更（自分たち／プラットフォーム／相手側）を列挙した
サポート対象範囲（Included／Excluded）を確認した
再起動の前に、デプロイ先に応じた証拠（ログ・診断情報）を確保した
ケースに書く情報が「まず必須」分そろっている
該当製品の「What Information to Collect」ナレッジを確認した
重要度を業務影響と回避策の有無で選び、対応できる連絡体制をケースに書いた

よくある誤解・アンチパターン

「動きません」だけで起票する → 環境・時刻・ログの確認往復が増え、解決が遅くなる
証拠を取らずに再起動する → 再起動前の情報が失われ、原因究明が難しくなる。再発時に振り出しに戻る
エラー名だけ書いてスタックトレースを省略する → 原因特定に必要な情報が足りず、往復が増える
サポート対象範囲を確認せずに起票する → 開発支援などティアにより対象外のトピックは、期待した回答が得られない
複数の問題を1つのケースに書く → 対応が分散して全部遅くなる
時刻にタイムゾーンがない → グローバルのサポート体制では時間帯の特定に往復が発生する
高い重要度で起票したまま連絡がつかなくなる → 状況確認への回答待ちで調査が止まる。対応できる時間帯を先に共有しておく