Fioriで保存ボタンを押したら、「エラーが発生しました」。画面にそれ以上の説明がなく、どこから調べればよいのか迷うことがあります。
そんなときは、いきなりABAPのソースを探すより、どの操作が、どの通信になり、どこで失敗したかをつなぐと、次の確認先を絞りやすくなります。
この記事では、ブラウザーの開発者ツールからSAP Gatewayのエラーログ、必要に応じてバックエンドのログへ進む流れを、架空の例で整理します。画面だけを確認できる人と、管理・開発権限を持つ人の役割も分けて考えます。
この記事で扱う構成と、最初に知っておきたい違い
主な対象は、SAPUI5の画面からSAP GatewayのODataサービスを呼び出すFioriアプリです。ECCを含むSAP Business Suiteの対応構成、SAP S/4HANAのオンプレミス／Private Editionを中心に説明します。
Fioriは一つの通信方式の名前ではありません。SAP GUI for HTML、Web Dynpro、BTP上のアプリなどでは、調査する経路が変わります。まず対象アプリの技術と接続先を確認してください。
| 構成・環境 | ログを探す場所 |
|---|---|
| Gatewayハブ構成 | Gateway側のABAPシステムと、業務処理を行うバックエンドが分離。前者の /IWFND/ERROR_LOG、後者の /IWBEP/ERROR_LOG を区別する。 |
| Gateway組み込み構成 | Gatewayと業務処理が同じABAPシステム内にある。論理的な役割は分かれていても、別サーバーへ移動するとは限らない。 |
| S/4HANA Cloud Public Edition | 提供されるOData Error Logなどのアプリと、管理者・サポートの手順を使う。SAP GUIのTコードを自由に実行できる前提にしない。 |
「ECCだからハブ」「S/4HANAだから必ず組み込み」と製品名だけで決めないことが大切です。システム構成、クライアント、Gatewayの配置、ODataの版、運用担当者を確認します。Private Editionでも契約や役割分担により、確認できる範囲は異なります。
OData V4でもGatewayのエラーログを使う構成があります。ただし、応答の構造や管理手順をV2と同じだと思い込まないようにします。
SAP公式：Managing an SAP Gateway Service
エラーを閉じる前に、発生時刻と操作を残す
最初に残したいのは、長い説明よりも「どの実行を調べるか」が分かる情報です。ログは大量にあるため、時刻と操作が曖昧なままだと別のエラーを追ってしまいます。
- 日時：日付・時刻・タイムゾーン。例：2026年11月10日 14:32:10 JST。
- 環境：本番／検証、対象システム・クライアント。分からない場合は不明と書く。
- アプリ：アプリ名、分かればアプリID。どのタイルから開いたか。
- 操作：検索、明細を開く、保存など。直前まで何ができていたか。
- 表示内容：エラー文、詳細ボタンにあるメッセージや識別子。
- 影響範囲：特定のデータだけか、自分だけか、複数ユーザー・複数アプリか。確認できた事実と未確認を分ける。
ユーザーIDや伝票番号は、社内の許可された問い合わせ先には役立ちます。一方、公開記事や外部の掲示板にそのまま貼る必要はありません。必要な情報を、適切な相手にだけ共有します。
保存を連打して再現させないでください。画面ではエラーでも、バックエンドの更新が終わっている可能性があります。再試行の前に処理結果を確認し、再現テストは承認された検証環境とデータを優先します。
全体像は「画面 → 通信 → ログ」でつなぐ
矢印は、必ず全ログを順番に見るという意味ではありません。ST22は、バックエンドだけでなくGateway側で起きた短期ダンプにも使います。通信が発生していなければ画面側、接続先に届かなければ通信経路、ODataのエラー応答があれば対応するサービスとログ、というように分岐します。
ブラウザーでは、ConsoleとNetworkの役割を分ける
デスクトップ版ブラウザーの開発者ツールを開き、ConsoleとNetworkを確認します。キー操作や表示名はブラウザーによって異なります。組織の端末利用ルールに従ってください。
Consoleは、JavaScriptの例外やリソース読み込みの問題など、画面側の手がかりを探す場所です。ただし、赤い表示があるだけで今回の原因とは限りません。エラーが出た操作・時刻との対応を見ます。
Networkは、ブラウザーとサーバーの通信を見る場所です。承認された再現操作の前から記録し、画面遷移で消える場合はPreserve logなどの保持機能を使います。再現が許可されない場合は、すでに残っている情報から調べます。
- 対象操作の直後に出た通信を探す。Fetch/XHRやサービス名で絞り、見つからなければ他の種類も確認する。
- リクエストのURL・HTTPメソッド・時刻を確認する。URLはクエリ部分に業務データを含む場合がある。
- Statusだけでなく、Responseのエラー本文を読む。認証画面のHTMLが返っていないかも確認する。
- エラーメッセージ、コード、transaction ID、timestampなど、存在する項目を記録する。
応答の項目名は一定ではありません。V2の応答でinnererror.transactionidが見える場合もあれば、V4では@SAP__common.TransactionIdなどの形を取る例もあります。画面に出ている識別子の名前と値を、そのまま区別して記録します。Request IDとtransaction IDを同じものとして置き換えないでください。
SAP公式：Logging and Tracing
SAP公式：Batch Request：V4のエラー応答例
HTTPステータスは、原因の答えではなく手がかり
| 見えた結果 | 次に確かめること |
|---|---|
| 通信自体が見つからない | 記録を開始したタイミング・フィルターを確認。操作が画面内で止まった可能性も調べる。 |
| 400 | 要求内容や業務チェックなどを、応答のコード・本文から確認。必ず入力ミスとは限らない。 |
| 401／403 | 認証・アクセス拒否を確認。403はCSRF検証の失敗でも起こり得るため、業務権限不足と即断しない。 |
| 404 | URL、サービスやリソースの存在、接続先を確認。 |
| 500／502／503／504 | 応答本文と返したコンポーネントを確認。アプリ、Gateway、プロキシ等のどこで失敗したかを切り分ける。 |
| 2xxなのに画面はエラー | $batchの内部応答、アプリが解釈する業務メッセージ、画面側の例外を確認。 |
たとえば403を見て、いきなりロールを追加するのは早すぎます。SAPのCSRF保護でも403が返ることがあります。まず応答本文と関連ログを確認し、必要なら権限担当者へつなぎます。
SAP公式：Protecting CSRF Tokens
$batchは「外側が成功」でも、中の処理が失敗している
ここはFioriの調査で覚えておきたいポイントです。ODataの$batchは、複数の要求をまとめて送る仕組みです。Networkの一覧に見えるステータスは、まとめた通信の外側の結果であることがあります。
外側が202などの成功扱いでも、内部の保存処理が400などで失敗している場合があります。Responseを開き、個別リクエストや変更セットに対応するステータスとエラーメッセージを確認します。
OData V4でも、バッチ送信自体の成功と、中の個別要求の成功は分けて扱います。「Networkが赤くないからバックエンドは正常」とは判断しないようにします。
SAP公式：Step 6: Create and Edit：バッチと個別要求の失敗
SAP公式：SAP Gateway Client：外側と内部のHTTPステータス
Gatewayログでは、同じリクエストを探す
SAP GUIを利用でき、必要な表示権限を持つ担当者は、対象のGatewayシステムで/IWFND/ERROR_LOGを確認します。SAP GUIのコマンド欄から起動する場合は、名前空間付きTコードとして/n/IWFND/ERROR_LOGと入力します。
発生日時の前後、実行ユーザー、サービス名などで候補を絞り、応答にtransaction IDがあれば照合します。「近い時間に赤い行があった」だけで同じエラーだと決めないことが大切です。
日時はタイムゾーン付きで記録し、応答のtimestampは原文を残します。ログ画面の表示時刻・タイムゾーンを確認して対応させてください。すべての画面がUTC、または日本時間だと決めつけないようにします。
- エラー本文・コードが、ブラウザーの応答と対応するか。
- 対象サービス、システムエイリアスや接続先などが、調べているアプリと合うか。
- Error Contextなどの詳細に、原因やバックエンド側の確認先があるか。
- 権限と機能が利用できる場合、Backend Monitorなどから関連するバックエンドログへ移れるか。
バックエンド側のGatewayエラーログは/IWBEP/ERROR_LOGです。ハブ構成ではログイン先が別になり、組み込み構成では同じABAPシステム内で確認することがあります。構成を確認せず、手元のSAP GUI接続先だけを探し続けないようにします。
ログを開く権限と、詳細・ペイロードを表示する権限は同じとは限りません。たとえばGatewayの詳細表示には、設定によってS_ADMI_FCDのPADMが関係します。権限が足りない場合は、必要な時刻・操作・識別子を添えて担当者に依頼します。
SAP公式：Gateway Tracing tools：ログレベルと詳細表示権限
SAP公式：Error Log：照合項目と詳細機能（旧版資料。画面・機能の細部は利用環境で確認）
ST22とSLG1は、手がかりがあるときに使う
ST22はABAPの短期ダンプを確認する場所です。Gatewayのエラー詳細がランタイムエラーを示す場合などに、Gatewayやバックエンドなど、ランタイムエラーが発生したABAPシステムで、日時・ユーザーなどを照合します。
ただし、入力チェックで処理を拒否しただけなら、短期ダンプが発生しないこともあります。ST22に何もないから正常、とは言えません。
SLG1はアプリケーションログの確認先です。対象処理がログを記録している場合に、適切なオブジェクト、サブオブジェクト、外部ID、日時などで調べます。すべてのFioriエラーが一つの共通条件で見つかるわけではありません。
SAP公式には、Gateway runtimeの追加ログを、オブジェクト/IWBEP/、サブオブジェクトRUNTIM、外部IDにtransaction IDを指定して調べる例があります。これはGateway runtime向けの例で、個々の業務アプリのSLG1条件とは分けて考えます。
SAP公式：Which Tools Can Be Used for Troubleshooting?
SAP公式：Display SAP Gateway Logs
ログが見つからないときは、システム・クライアント・時刻・ユーザーの取り違えに加え、保存期間、ログレベル、権限、通信がその層まで届いたかを確認します。たとえばSecure設定では、記録されるエラーや詳細情報が制限されます。
調査のためでも、全体のログレベルを安易に上げたり、Gateway ClientのReplayで更新要求を再実行したりしないでください。業務データの露出、性能への影響、二重登録などを考え、担当者の承認と運用手順に従います。
架空の例で、画面から原因候補まで追ってみる
以下は説明用に作った架空のアプリ・サービス・メッセージです。SAP標準アプリの仕様や、実際の案件で起きた経験談ではありません。
架空アプリ「備品申請」で保存したところ、画面に「エラーが発生しました」と出たとします。検証環境で、保存操作と同時刻の通信を確認しました。
| 確認場所 | この架空例で見つかったこと |
|---|---|
| 画面 | 14:32:10 JSTに保存。表示は汎用的なエラー文だけ。 |
| Networkの一覧 | POST …/Z_DEMO_REQUEST_SRV/$batch。外側のHTTPステータスは202。 |
| Response内部 | 保存処理の応答は400。メッセージは「申請理由を入力してください」。 |
| Gatewayログ | 同じtransaction ID・時刻・サービスの記録に、申請理由の必須チェックによる拒否がある。 |
この例では、202だけを見ていたら「通信は成功しているのに、なぜ？」で止まってしまいます。内部の400とメッセージを読めば、まず申請理由の入力値や送信内容を確認するところまで絞れます。
画面では入力済みなのに送信内容が空なら、画面側の値の扱いが候補です。送信内容に値があっても拒否されるなら、サービス側の受け取り方やチェック条件を確認します。ここで初めて、担当する実装の調査につなげられます。
この架空例で短期ダンプが発生していなければ、ST22を探し続ける必要はありません。「画面がエラー」から「どの要求の、どのチェックを確認するか」まで具体化することが、最初の調査の成果です。
Public Editionでは、提供アプリと担当者につなぐ
SAP S/4HANA Cloud Public Editionにも、技術的なメッセージ監視のためのOData Error Logアプリがあります。「Public Editionではログを見られない」という理解も正確ではありません。
SAP公式のMessage Monitoringには、関連ビジネスカタログSAP_CA_BC_COM_TECH_ERR_PCが記載されています。実際の利用可否は、テナントのリリース、設定、割り当てられたロールを確認してください。
一方、この記事のSAP GUIトランザクションをそのまま自由に実行できるとは限りません。業務ユーザーは発生時刻・アプリ・操作・エラー詳細をそろえ、管理者が提供アプリやSAPサポートの経路で調べる、という役割分担に読み替えます。
SAP公式：Message Monitoring
問い合わせメモは、事実と未確認を分けて渡す
すべてのログを自分で読めなくても、調査に使える形で渡すことはできます。次のような項目があると、受け取った人が同じ実行を探しやすくなります。
- 対象：環境、アプリ名・ID、実行ユーザー、対象データ。社内で必要な範囲に限定。
- 発生：タイムゾーン付き日時、直前の操作、期待結果と実際の結果。
- 通信：HTTPメソッド、サービス／パス、外側のステータス、$batch内部のステータス。
- 識別子：エラーコード、transaction IDなど、項目名と値の組み合わせ。
- 確認済み：どのログで何が一致したか。単に「ログあり」で終わらせない。
- 未確認：再現可否、他ユーザーへの影響、バックエンドの更新結果など。
- 次の依頼：接続経路、権限、サービス処理、業務チェックなど、確認してほしい箇所。
HARファイルやスクリーンショットは、そのまま外部へ共有しないでください。Cookie、Authorizationヘッダー、トークン、URL内の値、個人情報、業務データが含まれる場合があります。必要な範囲だけを取り出し、組織の承認された共有先・方法を使います。
Fioriのエラー調査は、Tコードをたくさん知っているだけでは進みません。発生時刻と操作をそろえ、通信の結果を読み、同じリクエストのログへつなぐ。その順番を持つと、画面の先にある処理を少しずつ追えるようになります。
バックエンドの処理まで絞れたら、ABAPソースコードを読む順番も参考にしてください。環境間の反映差が疑われる場合は、STMSで移送履歴を確認する方法へ進めます。
本記事はSAP公式資料をもとにした学習用の整理です。Gateway Clientとトラブルシューティングのツール一覧は、2025 FPS01（Feb 2026）表示の本文を確認しています。一部の詳細は旧版資料も参照しています。確認日：2026年11月11日（日本時間）。画面名、ログの保持・記録内容、権限、利用できる機能はリリースと構成によって異なります。実環境での操作検証や障害再現は行っていません。
コメント