Salesforce Workbenchのエラー：ダウンタイム中のAPIツールのトラブルシューティング

2026年9月16日検証済み。Salesforceインシデント発生時、Workbenchエラーは誤読されやすい。ログイン失敗の原因としては、セッションの期限切れ、環境の誤り、Workbenchルートの破損、Salesforce APIの停止などが挙げられる。一方、リクエストがエラーを返す場合、開発者が迅速に作業を進めようとすると、503 Service Unavailableエラーと異なる方向性を示す可能性がある。401 Invalid Session

トラブルシューティングの目的は、特定の要求を無理やり通すことではありません。どの層で問題が発生しているかを特定し、システムが不安定な間もデータを保護し、状況に応じて待機、ツールの切り替え、適切なサポート窓口への連絡といった対応を取るのに十分な証拠があるかどうかを判断することです。

簡単な診断：このエラーは最も可能性の高い原因は何でしょうか？

表示されているもの	最も可能性の高いレイヤー	次に最適な行動
ワークベンチページが読み込まれません	ワークベンチサイト、ブラウザ、DNS、またはネットワークパス	Salesforceの信頼ステータスを開き、許可された別のネットワークからサイトをテストしてください。
Workbenchはロードされるが、ログインに401エラーが発生する。	セッション、OAuth、ユーザー名、パスワード、またはログインフロー	新たに認証済みログインを開始し、選択した環境を確認してください。
APIリクエストが403エラーを返します	権限、接続アプリポリシー、またはAPI制限	ユーザー数、接続アプリ数、リクエスト数の制限を確認してください。ただし、これらをシステム停止の証拠として扱わないでください。
いくつかのAPI呼び出しで500、502、または503エラーが返される	Salesforceプラットフォーム、エッジルーティング、メンテナンス、または過負荷	エラー発生時刻を、Trust上のインスタンスおよび製品ステータスと比較してください。
クエリまたはオブジェクトが 1 つだけ失敗します	リクエスト構文、オブジェクトアクセス、レコード共有、またはデータの問題	リクエストを無害で既知の安全な読み取りに縮小し、レスポンスボディを検査する。

この表はあくまで出発点であり、診断ではありません。同じHTTPコードでも、エンドポイント、認証方法、組織のポリシーによって原因が異なる場合があります。

まず、Workbenchのサポート範囲を理解する

Workbenchは、REST、SOAP、Bulk、Streaming、Metadata、Apex関連ツールなど、複数のAPIを介してSalesforce組織と連携するためのブラウザベースのスイートです。ただし、Workbenchのサイトには、これはSalesforceの公式製品ではなく、Workbench自体に対するSalesforceのサポートは提供されていないと明記されています。また、Workbenchの「概要」ページでは、本番データでこのアプリケーションを使用しないよう警告しています。

この警告によって、システム停止時の対応方法が変わります。Salesforce サポートは Salesforce サービス、インスタンス、または API の問題を調査できますが、Workbench インターフェイスのすべての動作をトラブルシューティングできるとは限りません。逆に、Workbench のみで報告された問題は、Salesforce プラットフォームではなく、Workbench またはブラウザのパスに起因する可能性があります。

トラブルシューティングに関する情報は、可能な限り読み取り専用にしてください。パスワード、OAuthシークレット、セッションID、アクセストークン、顧客レコード、または編集されていないリクエストヘッダーを、スクリーンショット、チャットメッセージ、または公開されている問題報告に貼り付けないでください。

Workbenchのログイン画面の例。標準、詳細、OAuth、環境、APIバージョン、ユーザー名、パスワード、セッションID、サーバーURLの各フィールドが表示されます。 — まず、Workbenchのログインパスと選択した環境を確認してください。表示されているインターフェースはあくまでもイメージ図であり、実際のログイン画面や記事画像への認証情報入力画面ではありません。

ステップ1：ワークベンチの設定を変更する前に、Salesforceの信頼ステータスを確認します。

Salesforceの信頼ステータスを別のタブで開きます。Salesforceのヘルプドキュメントでは、製品の障害やサービス低下が発生した場合にこのページを参照するように顧客に案内しており、信頼サイトでは製品に関する情報だけでなく、特定の事例に関する情報も確認できます。

2つのビューを確認してください

製品全体を把握するには、使用しているSalesforceサービスに影響を与えるインシデント、サービス低下、障害、またはメンテナンスイベントを探してください。
インスタンスビュー：インスタンスまたはマイドメインを検索し、一致する結果を開きます。

「利用可能」とマークされたインスタンスは、すべてのAPI操作が正常に動作することを保証するものではありません。これは、Salesforceのステータス定義に従って、インスタンスとそのサービスが利用可能であることを意味します。「パフォーマンス低下」は、アクセスに遅延が生じたり、機能が部分的にしか動作しない可能性があることを示します。 「サービス中断」は、インスタンスが利用できない状態であることを示します。 「メンテナンス」は、アクセスに影響を与える場合と与えない場合があるメンテナンスイベントを示します。

mycompany を含む検索インスタンスまたはドメインフィールドと、利用可能なインスタンスの結果を含む Salesforce の信頼ステータスページの例を示す。 — ステップ 1 — 広範な信頼ステータス情報を、影響を受けた組織のインスタンスと比較します。表示されている画面は、文書化された検索ワークフローを示すための例示であり、実際のインシデントを示すものではありません。

ステップ2：再試行する前に環境と組織を確認する

WorkbenchはさまざまなSalesforce環境に接続できます。APIがダウンしていると結論付ける前に、失敗したリクエストが本番環境、サンドボックス環境、またはその他の承認済み環境のいずれを対象としているかを確認してください。ある環境でテストが成功したとしても、実際に問題が発生している環境がクリアになるわけではありません。

影響を受ける組織の「マイドメイン」またはインスタンス識別子を使用してください。Salesforce のドキュメントによると、「マイドメイン」プレフィックスは信頼ステータスで使用でき、管理者は「設定」の「会社情報」でインスタンスを確認できます。インスタンス、環境、API バージョン、おおよその障害発生時刻、エンドポイントをメモしておいてください。この簡単な記録により、本番環境のエラーと正常なサンドボックス環境の状態を比較するというよくあるミスを防ぐことができます。

Workbenchのログインページ自体にサポートされていないログイン方法が表示されたり、ログイン画面に戻ってしまう場合は、信頼ステータスとSalesforceへの直接ログインによって別の問題が示されるまで、それを別の認証またはWorkbenchの問題として扱ってください。障害が疑われる場合は、認証情報を繰り返し送信しないでください。過剰な再試行はロックアウトを引き起こしたり、調査を複雑にしたりする可能性があります。

ステップ3：推測するのではなく、APIレスポンスを分類する

SalesforceのREST APIドキュメントによると、レスポンスヘッダーにはHTTPステータスコードが含まれ、本文には通常メッセージと、該当する場合はエラーに関連付けられたフィールドまたはオブジェクトが含まれます。これらの証拠を両方とも保存してください。

コード	Salesforceの文書化されたヒント	休憩時間中にそれをどう解釈するか
400	リクエストを理解できませんでした。多くの場合、JSONまたはXMLの本文が無効であることが原因です。	通常は、障害として扱う前にリクエストを修正します。
401	セッションIDまたはOAuthトークンの有効期限が切れているか、無効です。	承認された手順で再認証を行ってください。401エラーのみでは、プラットフォームの障害を示す証拠にはなりません。
403	リクエストは拒否されました。多くの場合、権限の問題かAPIの制限が原因です。	可用性に関するインシデントにエスカレーションする前に、アクセス権限と制限を確認してください。
500	Lightning Platform内でエラーが発生しました。	応答を記録した後のみ再試行してください。繰り返し発生する失敗は、信頼ステータスと比較してください。
502	Salesforce Edgeはインスタンスとの通信に成功しませんでした。	ルーティングまたはプラットフォーム側の問題が発生する可能性があります。特に複数のリクエストにまたがる場合はその可能性が高くなります。
503	サーバーが利用できません。メンテナンス中か、負荷過多の可能性があります。	インシデントやメンテナンスイベントが発生していないか確認し、破壊的な再試行を回避してください。

ワークベンチ API リクエスト画面の例。安全な GET リクエストと、401 無効なセッション、502 Salesforce Edge、503 サービス利用不可、および 500 内部サーバーエラーに対するレスポンス行を示しています。 — ステップ3 — 認証情報やリクエストを変更する前に、HTTPコードとレスポンスの意味を記録してください。この例には、トークン、顧客データ、実際のインシデント識別子は含まれていません。

ステップ4：安全な比較テストを実行する

状態と環境が分かったら、許可されている最小限の読み取り専用テストを使用してください。優れた比較テストには、次の3つの特性があります。対象となる組織をターゲットにしていること、データを変更しないこと、そしてリクエスト形式の間違いが起こりにくいほどシンプルであること。

最初の応答を記録した後、同じ無害な要求をもう一度繰り返してください。
リクエストが401エラーを返した場合、古いセッションを再利用するのではなく、新しい認証フローを開始します。
400、403、または404が返された場合は、エンドポイント、APIバージョン、オブジェクト名、権限、およびリクエストボディを確認してください。
500、502、または503が繰り返し返される場合は、その時間とインスタンスを信頼ステータスと比較してください。
ブラウザのUIは正常に動作するのにWorkbenchが動作しない場合は、承認済みの内部クライアントまたは統合診断ツールを使用して、同じ認証済みAPIパスをテストしてください。

書き込み、削除、一括更新、メタデータ展開、または移行リクエストをヘルスチェックとして使用しないでください。インシデント発生中に書き込みを行うと、結果が不完全になったり、作業が重複したり、復旧が完了したという誤った印象を与えたりする可能性があります。

トラブルシューティングのアプローチを変更すべきタイミングはいつですか？

信頼ステータスにインシデントが表示された場合は、アプローチを変更してください。

リクエストの形式が不正であるという独立した証拠がない限り、クエリの再設計は中止してください。インシデント番号、影響を受けるサービス、インスタンス、開始時刻、および最新の更新情報を保存してください。Salesforce の復旧メッセージに従い、キューに登録された作業が重複して再試行されないようにしてください。

信頼ステータスが利用可能だがワークベンチ単体では失敗する場合にアプローチを変更する

Workbench、ブラウザ、ネットワーク、認証、またはローカルポリシーに焦点を当ててください。プライベートブラウザウィンドウ、サポートされている別のブラウザ、および許可されたネットワークで比較してみてください。Workbench サイトでは、Workbench 固有のサポートについてはオープンソースコミュニティのリソースを参照するように案内していますが、Salesforce 製品およびアカウントのサポートについては Salesforce ヘルプを参照してください。

エラーが常に401または403の場合は、アプローチを変更する。

IDと認証の分析に進みます。ユーザー、接続済みアプリのポリシー、OAuthスコープ、セッションの有効期間、APIアクセス、プロファイルまたは権限セット、および組織の制限を確認してください。ブラウザを繰り返し更新しても、権限の欠落や無効なトークンは修復されません。

エンドポイントの1つが失敗しても単純な読み取りは機能する場合、アプローチを変更する。

エンドポイント、オブジェクト、フィールド、レコード共有、APIバージョン、リクエストボディ、レスポンスボディを調査してください。限定的な障害だけでは、Salesforce全体がダウンしていると断定することはできません。問題が構文、アクセス、データ、または依存サービスにあるかどうかを特定できるまで、リクエストを絞り込んでください。

Workbench の「概要」ページの例。Workbench は Salesforce の公式製品ではなく、Salesforce によるサポート対象外であり、本番データで使用すべきではなく、オープンソースのコミュニティによってサポートされていることを示す通知が表示されます。 — ステップ4 — Workbenchのサポートおよび安全上の制限事項を遵守してください。プラットフォームに関する問題については、承認済みのSalesforceサポートをご利用ください。Workbench固有の動作については、オープンソースのコミュニティリソースをご参照ください。

サポートに送るべき証拠は何ですか？

Salesforceの問題が解決しない場合は、Success Planで利用できるチャネル向けのSalesforce公式サポートガイダンスを参照してください。以下を含めてください。

組織識別子、インスタンス、および環境
UTCタイムスタンプとあなたの現地タイムゾーン
ワークベンチページまたはAPI操作が関係しています
HTTPコード、エラーコード、および編集済みのレスポンスボディ
Salesforce UI、他のユーザー、または他の承認済みクライアントでも同様に失敗する
信頼ステータスのインシデント番号、または一致するイベントが見つからなかったことを示すメモ

ログを送信する前に、認証情報、セッションID、アクセストークン、顧客名、レコードID、および機密性の高いペイロードを削除してください。問題がWorkbenchのみに関するものである場合は、Workbenchヘルプページに記載されているサポートルートをご利用ください。SalesforceはWorkbench自体の製品サポートは提供していません。

復旧を確認する方法

緑色のステータス表示は励みになりますが、それで終わりではありません。段階的に復旧状況を確認してください。

インシデントページに解決済みと表示されるか、インスタンスの状態が「利用可能」に戻ることを確認してください。
古いセッションを再利用せずに、承認済みのSalesforceまたはWorkbenchのフローを通じてログインしてください。
先ほど失敗した、同じ無害な読み取り専用リクエストを実行します。
HTTPコード、応答時間、および応答本文を、記録されたエラーと比較してください。
統合、キューに入れられたジョブ、および下流通知を確認し、遅延または重複した作業がないか確認してください。

あなたが望む結果は、単に「ページが開かれた」ということではありません。本来の承認済み操作が成功し、期待通りの応答が得られ、未確認の副作用が発生しないことが求められます。

自己チェックチェックリスト

範囲：製品レベルの信頼ページと影響を受けるインスタンスの両方を確認しましたか？
環境：本番環境とサンドボックス環境、および正しいマイドメインまたはインスタンスであることを確認しましたか？
証拠：正確なHTTPコード、エラーコード、時刻、および編集済みの応答を保存しましたか？
安全性：インシデント発生時に、書き込み、削除、一括処理、デプロイ、移行のリクエストを回避しましたか？
判断事項： Workbench固有の動作とSalesforce APIの障害を区別できましたか？
復旧：元の操作を再テストし、遅延した下流工程を検査しましたか？

結論

Salesforce Workbench のダウンタイム中に発生したエラーについては、まず信頼ステータスと影響を受けるインスタンスを確認し、認証情報の変更やリクエストの書き換えを行う前に HTTP レスポンスを分類してください。単純な読み取り専用テストで 500、502、または 503 エラーが繰り返し発生し、信頼インシデントが一致する場合は、Salesforce 側での説明が考えられます。401、403、400 エラー、または Workbench のみで発生するエラーの場合は、認証、権限、リクエスト、ブラウザ、または Workbench のトラブルシューティングが必要になります。Workbench は Salesforce がサポートする製品ではないため、本番データを Workbench に使用せず、境界を明確に文書化し、状況が変わった場合は最新の公式ステータスとサポートガイダンスを参照してください。