SAPのエラーメッセージから原因のプログラムを探す方法｜SE91・使用先一覧・デバッグの実務手順

SAPでエラーが出たとき、文面を検索しても原因が分からないことがあります。たとえば「入力を確認してください」と表示されても、どの項目を、どの条件と照合した結果なのかまでは見えません。

そんなときの入口は、メッセージクラスと番号です。長文説明を確認し、SE91の使用先一覧で候補を絞り、必要ならデバッガで実際の通り道を確かめます。本記事では「プログラム名を知らない状態から、どこまで調べれば原因の説明につながるか」を整理します。

対象は主にSAP GUIを利用するECCやSAP S/4HANAのオンプレミス／Private Editionで、必要な表示・デバッグ権限がある環境です。Public EditionやSAP BTP ABAP環境に、SE91やSAP GUIの操作をそのまま当てはめる記事ではありません。画面名や利用できる機能はリリース・権限で異なります。

まず「メッセージ」と「発生した操作」をセットで残す

SAP GUIのステータスバーに表示されたメッセージなら、ダブルクリックなどで詳細を開きます。長文説明があれば先に読み、原因・システム応答・対処の説明を確認してください。既知の入力条件なら、ソースを調べる前に解決する場合があります。

SAPのEWM向け公式ガイドでも、長文説明、メッセージクラスと番号、SE91の使用先一覧という順に調べる方法が紹介されています。画面の日本語文面だけでなく、識別情報を残すのが出発点です。SAP Help：Error messages

控える項目	調査での使い道
メッセージクラス＋番号	同じ文面や同じ番号の別メッセージとの取り違えを防ぐ
発生した操作・タイミング	入力直後なのか、保存時なのか、実行後なのかを切り分ける
システム・クライアント・発生時刻	再現した環境とログの対象を合わせる
表示言語・入力条件・期待した結果	文面の差と処理条件の差を区別する

番号だけでは足りません。また、メッセージの種類を示すEやWは、メッセージクラスとは別の情報です。伝票番号などの実データを記録する場合は、社内で承認された場所だけに残し、外部検索や公開記事には持ち出さないでください。

SE91の使用先一覧で、まず候補を見つける

SE91を開き、確認したメッセージクラスを入力して表示します。対象番号の行を選択し、使用先一覧（Where-used list）を実行します。ここでは表示だけを使い、メッセージ本文やソースの変更は行いません。

一覧からソースを開いたら、MESSAGEの行だけでなく、その手前のIFやCASE、呼び出している処理も見ます。候補が複数ある場合は、発生操作に関係するプログラム・クラス・処理名から絞ります。ただし、名前がそれらしいというだけでは、今回実行された場所とは確定できません。

この段階の成果は「原因判明」ではなく、「同じメッセージを扱う候補の場所が分かった」です。標準プログラム名が見つかっても、それだけでSAP標準の不具合とは判断できません。

使用先がゼロでも、調べ方が間違っているとは限らない

メッセージクラスや番号が実行時に渡される処理、メッセージを蓄積して後で表示するフレームワークでは、静的な使用先一覧だけで追い切れない場合があります。

SAPのCRM Web UI向け資料にも、メッセージサービスへIDと番号を渡す呼び出しが、SE91の使用先一覧に現れない例が示されています。「一覧が空だから、このメッセージを出す処理は存在しない」とは言えません。SAP Help：CRM Web UI Customization

調査結果	次の進め方
候補が少ない	前後の条件と呼び出し元を読み、必要なら候補の行で実行確認
候補が多い	発生操作との関係を整理してから、実行時に通る候補を確認
使用先が見つからない	実行時のメッセージ処理やアプリ側ログを確認
画面上のエラーにクラス・番号がない	ABAPメッセージと決めつけず、画面・通信・バックエンドの切り分けへ

デバッガでは「今回、本当に通った場所」を確かめる

デバッグは、権限と実施許可のある開発・検証環境を優先します。再現操作を行うと保存や外部送信も実行され得るので、検証用データと処理の影響を確認してから進めてください。

使用先で候補の行まで分かっているなら、まずその行のブレークポイントを使います。SAP GUIの同じユーザーセッションを調べるセッションブレークポイントと、HTTP・RFCなどの呼び出しを調べる外部ブレークポイントは、用途が違います。

候補が分からないときは、デバッガ内の「メッセージで停止する」ブレークポイントを利用できるか確認します。対象のクラス・番号を指定できる場合は絞り込みます。SAPの現行ABAP Platform資料では、メッセージやABAP命令に対するデバッガブレークポイントが説明されています。SAP Help：Breakpoints and Breakpoint Statements（2025 FPS01）

MESSAGE命令全体で停止させる方法は、無関係なメッセージにも止まりやすくなります。停止したら、まず今回のクラス・番号に対応する命令かを確認します。命令実行前には、過去のメッセージ情報が残っている可能性もあるため、sy-msgidなどのシステム項目だけで決めず、停止した命令のオペランドも確認してください。

停止しない場合、すぐに権限不足と断定するのも早計です。別のユーザー・セッション・バックエンドで動いているのか、メッセージを直接表示せず戻り値へ格納する経路なのか、再現条件が一致しているのかを切り分けます。

MESSAGEの行で止まったら、直前の条件と値を読む

以下は考え方を説明するための架空の疑似コードです。SAP標準のソースではなく、そのままABAPとして実行するコードでもありません。実際の案件・プログラム・テーブルとは関係ありません。

IF 入力数量 > 許容数量
    「入力数量が許容範囲を超えています」を通知
ENDIF

通知の行が分かっただけなら、「数量の比較で止まった」までです。次は比較の左右を見ます。入力数量は画面値なのか、単位換算後なのか。許容数量は固定値なのか、別処理の計算結果なのか。この違いによって、追うべき場所が変わります。

この例で許容数量が想定外だったとしても、すぐ設定ミスと結論づけません。許容数量に値を入れている箇所を探し、その取得条件や引数を確認します。「値が違う」という観測と、「設定が原因」という仮説は分けて残します。

同じ検証環境で正常になる条件と比較できれば、どの入力や取得結果が変わったかを整理します。ただし、比較のために本番データを書き換えたり、デバッガで変数を変えてチェックを通過させたりしてはいけません。

共通の表示処理に止まったら、コールスタックをたどる

止まった場所が「受け取ったメッセージを表示するだけ」の共通処理なら、そこが業務上の判定場所とは限りません。コールスタックを見て、誰がこの処理を呼び、どんな引数を渡したかを確認します。

SAPのABAP Debugger資料では、コールスタックからプログラム・処理ブロック・行を確認し、選択した呼び出し階層の変数やソースを参照できることが説明されています。SAP Help：ABAP Debugger

ただし、エラー情報をいったん蓄積し、後の処理でまとめて表示している場合、現在のスタックに元の判定処理が残っていないこともあります。その場合は表示処理を上へたどるだけでなく、メッセージを戻り値や内部テーブルへ追加した箇所を次の停止候補にします。

Fioriやバックグラウンド処理では、同じ入口にこだわらない

Fioriの画面に出たエラーが、必ずSAP GUIのセッションで止まるわけではありません。画面側の問題、通信エラー、バックエンドの業務エラーを区別してから、対象システムやログを確認します。具体的な入口はFioriのエラーをGatewayログから調べる記事で整理しています。

バックグラウンドや更新処理も、画面操作と同じ条件では調査できない場合があります。処理方式に合う手順を担当者と確認してください。この記事の手順を使うためだけに、実行方式や権限を変更することは勧めません。

調査結果は、次の人が同じ場所を確認できる形にする

記録する内容	書き方の例（すべて架空）
確認できた事実	数量の比較条件が成立し、対象メッセージの通知処理に入った
確認した値と条件	入力側と許容側の値が一致しない。どの単位で比較したかも記録
発生箇所と呼び出し経路	内部の調査記録にプログラム・処理・停止行を記載
未確定の仮説	許容側の取得条件が想定と違う可能性。取得元は追加確認が必要

実際の識別子や業務データを含む記録は、社内の承認された範囲で扱います。外部への問い合わせでは、送付先・必要範囲・匿名化方針を確認してください。調査が終わったら、作成したブレークポイントも整理します。

ソースの場所が見つかった後、値の流れや処理の役割を読む手順はABAPソースコードの実務的な読み方につながります。今回はその一歩手前にある、「どのソースを読めばよいのか」を探す方法です。

メッセージクラスと番号で候補を探し、実際の経路を確かめ、条件と値を追う。この順番で進めると、エラーの文面だけを眺める状態から、何を追加確認すべきか説明できる状態へ進めます。

技術資料確認日：2026年11月13日。公式資料に基づく一般的な調査手順であり、個別環境での再現テストは行っていません。SAP GUI・ABAP Platformのリリース、権限、アプリケーション構成によって操作や停止方法は異なります。