SAP Basisとは？システム管理者の業務内容と現場運用の実践ガイド

SAP Basisは、SAP ERPやSAP S/4HANAを安定して稼働させるための技術領域です。アプリケーションの業務設定そのものではなく、ユーザー、権限、バックグラウンドジョブ、システム監視、移送、接続、障害対応など、システム全体を支える運用を担当します。この記事では、実際の運用現場で使う画面と確認手順を中心に、SAP Basisの実務を整理します。

01SAP Basisの役割

SAP Basisの担当者は、システムを「使える状態」に保つだけでなく、問題の兆候を早期に発見し、業務影響を抑えながら変更を管理します。担当範囲は、SAP GUIから実行するトランザクション、アプリケーションサーバー、データベース、OS、ジョブ基盤、外部連携まで広がります。

代表的な業務は、次のように分類できます。

• ユーザーとロールの登録、変更、ロック解除
• システムログ、ダンプ、ロック、プロセスの確認
• バックグラウンドジョブの登録、監視、再実行
• 移送依頼の順序確認と本番反映の管理
• RFCや外部システム接続の疎通確認
• 稼働状況、性能、ディスク使用量、印刷やスプールの確認
• 障害発生時の一次切り分け、記録、エスカレーション

業務担当者が処理を実行できない場合でも、原因が権限、ユーザーロック、ジョブ停止、ロック残留、ダンプ、接続障害のどこにあるかで対応は変わります。問い合わせを受けたら、発生時刻、ユーザー、トランザクション、対象伝票、エラーメッセージ、再現条件を最初に記録すると、調査が安定します。

02日次監視の進め方

日次監視は、異常を見つけた画面だけを確認する作業ではありません。前日の処理結果と当日の業務予定を照合し、業務に影響する兆候を優先順位付けします。

始業時の確認

最初に、システムへログオンできること、主要なアプリケーションサーバーが稼働していること、予定されたジョブが完了していることを確認します。ジョブの終了時刻だけでなく、処理件数や生成されたファイルの有無も業務担当者と合意しておくと、形式上は成功した不完全処理を見逃しにくくなります。

次に、SM21でシステムログを確認します。大量のエラー、データベース接続、更新処理、RFC、メモリやファイルシステムに関する記録が連続していないかを見ます。ログは単発の警告より、同じ時間帯に繰り返す事象と業務処理の時間帯を結び付けて判断します。詳しい確認手順は、SAPシステムログ（SM21）の確認方法にまとめています。

業務時間中の確認

業務時間中は、応答時間の悪化、更新待ち、ロック競合、短時間に増加するエラーを優先します。SM50では各アプリケーションサーバーのワークプロセス、SM66ではシステム全体の処理状況を確認できます。長時間実行中の処理は、対象ユーザーと処理内容を確認したうえで、業務担当者の承認なしに終了させない運用が安全です。

SM12ではロックエントリを確認します。ロックが残っているときは、対象オブジェクト、所有ユーザー、作成時刻、関連セッションを記録します。ユーザーのブラウザやSAP GUIが切断された直後でも、ロックが業務データを保護している場合があります。削除する前に、該当ユーザーが処理を継続していないことを確認します。

終業時の確認

終業時は、当日予定されたジョブの完了、失敗、キャンセルを確認し、未処理のエラーを翌日の担当者へ引き継ぎます。監視記録には、発生時刻、影響範囲、調査結果、実施した処置、次のアクション、担当者を残します。画面のスクリーンショットだけでなく、ジョブ名やログ番号など再調査できる情報を保存します。

03ユーザーと権限の管理

ユーザー管理の中心はSU01です。新規ユーザー、退職者、異動者、利用停止、パスワード初期化、ユーザー種別、有効期間を、申請と承認記録に基づいて処理します。ロールを直接付与する場合は、付与理由、期間、承認者、対象システムを記録します。

ユーザー作成では、次の項目を確認します。

• ユーザーIDと氏名が申請内容と一致している
• ユーザー種別が用途に合っている
• 有効開始日と終了日が適切である
• 必要なロールだけが割り当てられている
• 初期パスワードの通知経路が管理されている
• 本番環境への緊急権限に期限が設定されている

パスワードの失敗回数超過では、まず本人確認を行い、ロック解除の前に認証情報が漏れていないかを確認します。複数ユーザーが同時にロックされた場合は、個別解除を繰り返すのではなく、認証基盤、ジョブ、RFC、端末設定など共通原因を調べます。ユーザー管理の操作順序と確認項目は、SAPユーザー管理（SU01）の実務手順も参照できます。

権限エラーは、単純にロールを追加して解決するとは限りません。対象トランザクション、会社コード、プラント、販売組織、活動、期間など、権限値のどの部分が不足しているかを確認します。SU53の結果や、必要に応じて権限トレースを利用し、申請された業務範囲と実際の不足項目を一致させます。

04バックグラウンドジョブの運用

バックグラウンドジョブは、帳票、インターフェース、集計、データ連携、定期メンテナンスを自動化します。SM36で登録し、SM37で実行状況とログを確認します。ジョブ名、実行ユーザー、開始条件、周期、対象バリアント、スプール、前提ジョブを一覧で管理すると、担当者が変わっても運用を継続できます。

ジョブを登録するときは、次の項目を明確にします。

1. 業務上の目的と処理対象
2. 実行頻度と開始時刻
3. 実行ユーザーと必要権限
4. バリアントに保存された選択条件
5. 前提ジョブと後続ジョブ
6. 失敗時の通知先と再実行方法
7. 実行時間の上限とデータ量の見込み

SM37で「Released」「Scheduled」「Active」「Finished」「Canceled」の状態を確認します。キャンセルされたジョブでは、ジョブログ、ステップ、実行ユーザー、開始時刻、終了時刻、ダンプの有無を順に確認します。ジョブログだけで原因が判断できない場合は、同じ時間帯のSM21、ST22、SM50またはSM66を突き合わせます。

ジョブを再実行する前に、途中まで登録されたデータ、重複送信、ファイル出力、後続処理への影響を確認します。再実行が安全であることを業務担当者と確認し、元の実行結果と再実行結果を分けて記録します。日常的な監視の詳しい流れは、SAPバックグラウンドジョブ監視（SM37）の手順で確認できます。

05ダンプと処理異常の切り分け

ABAPプログラムの実行時エラーはST22で確認します。発生日時、ユーザー、トランザクション、プログラム、エラーの種類、呼び出し元、選択条件を記録します。同じダンプが複数回発生している場合は、発生件数と業務影響を整理し、単発の入力エラーとシステム全体の問題を分けます。

調査は、次の順序で進めると効率的です。

1. 業務担当者から再現手順と対象データを確認する
2. ST22でダンプの発生時刻と実行ユーザーを確認する
3. SM21で同時刻のシステムイベントを確認する
4. SM50またはSM66で処理の滞留や異常終了を確認する
5. 直前に行われた移送、設定変更、マスタ変更を確認する
6. 再現テストの条件と本番での暫定対応を分けて記録する

メモリ不足、データベースエラー、権限不足、変換不整合、プログラム不具合では、担当するチームが異なります。Basis担当者は、技術的な事実を収集し、ABAP開発、機能担当、データベース担当、インフラ担当へ渡せる形に整理します。ダンプの読み方と一次切り分けは、ABAPダンプ分析（ST22）の実践手順で補足しています。

06移送と変更の管理

移送管理では、変更の内容、依頼番号、所有者、対象システム、インポート順序、承認状態、結果を追跡します。開発、品質保証、本番の各環境で、同じ変更がどの状態にあるかを一覧化すると、依存関係の見落としを防げます。

本番移送の前には、対象機能のテスト完了、関連依頼の確認、インポート順序、バックアップや戻し方、業務停止の有無、担当者の待機状況を確認します。移送後は、インポートログだけでなく、対象トランザクション、バッチジョブ、RFC、帳票、権限を業務シナリオで確認します。

STMSでエラーが発生した場合は、インポートログの警告とエラーを分け、オブジェクトのロック、依存する依頼、構文や生成、権限、ファイルシステムを確認します。再インポートはログの内容と変更管理上の承認を確認してから実施します。

07RFCと外部連携の確認

外部システムとの連携では、SM59で接続先、接続方式、宛先、ログオン情報、ネットワーク疎通、認証、リモート関数の実行結果を確認します。接続テストが成功しても、業務処理が成功するとは限りません。送信データ、受信データ、キュー、相手側ログ、タイムスタンプを合わせて確認します。

連携障害では、発生時刻を基準にSAP側と相手側のログを並べます。認証失敗、名前解決、ポート、証明書、タイムアウト、権限、データ形式、重複送信を分けて調査します。再送信の前に、相手側で受信済みになっていないかを確認し、二重登録を防ぎます。

08性能と容量の管理

性能問題は、遅い画面だけを見て判断せず、時間帯、ユーザー数、処理量、アプリケーションサーバー、データベース、外部接続を関連付けて確認します。SM50とSM66でワークプロセスの状態を確認し、長時間処理、待機、更新処理、RFC待ちを区別します。

容量管理では、データベース、ログ、インターフェースファイル、スプール、トレース、OSファイルシステムを定期的に確認します。空き容量が少ない場合は、単にファイルを削除せず、保持期間、バックアップ、監査要件、再生成可能性を確認してから整理します。

性能調査の記録には、測定時刻、対象ユーザー、トランザクション、処理件数、応答時間、サーバー、関連ジョブ、変更履歴を含めます。改善前後で同じ条件を測定すると、対策の効果を説明できます。

09障害対応の標準手順

障害対応では、復旧を急ぎながらも、証拠を失わないことが重要です。最初に影響範囲と開始時刻を確定し、次に直近の変更、システムログ、ダンプ、ジョブ、ロック、ワークプロセス、外部接続を確認します。

受付と初動

問い合わせを受けたら、次の情報を収集します。

• 影響を受けるユーザー、拠点、会社コード、プラント
• 発生時刻と最初に確認された画面
• 実行したトランザクションと入力条件
• 表示されたメッセージ番号と全文
• 全員に発生するか、特定ユーザーだけか
• 直前に移送、設定変更、ジョブ変更があったか
• 業務上の締切と許容できる暫定対応

その後、影響の大きい処理を保護します。重複登録、誤送信、データ更新の不整合が起きる可能性がある場合は、業務責任者と処理停止や再実行の判断を行います。システム再起動は最後の手段として、影響、依存サービス、バックアップ、担当者、承認を確認してから実施します。

復旧後の確認

復旧後は、ログオン、主要トランザクション、更新処理、ジョブ、RFC、帳票、スプール、監視アラートを確認します。技術的に起動していても、更新キューや連携が停止していれば業務復旧とはいえません。業務担当者による代表シナリオの確認を完了条件に含めます。

障害記録には、原因、影響、時系列、実施した操作、判断者、復旧時刻、未解決事項、再発防止策を残します。再発防止策は、監視追加、ジョブ設計変更、権限見直し、容量計画、運用手順改訂、教育など、実施可能な単位に分けます。

10管理者が整備する運用台帳

安定した運用には、画面操作の知識だけでなく、システム固有の情報を更新し続ける仕組みが必要です。最低限、次の台帳を整備します。

• システム、クライアント、インスタンス、サーバーの一覧
• 管理者、業務責任者、緊急連絡先
• ユーザー、ロール、特権ID、期限付き権限の管理方法
• 定期ジョブ、実行時刻、担当者、失敗時の対応
• RFC接続、外部連携、証明書、接続先の情報
• 移送経路、承認者、停止時間、戻し方
• バックアップ、復旧テスト、保持期間
• 監視項目、しきい値、通知先、対応手順
• 障害履歴と既知の問題

トランザクションコードは、一覧を暗記するよりも、業務目的と確認結果を結び付けて管理するほうが実務的です。用途別の整理には、SAPトランザクションコード一覧を参照し、社内で許可された操作と承認経路を追記します。

11まとめ

SAP Basisの業務は、ユーザー登録だけ、ジョブ監視だけ、あるいは障害時の再起動だけではありません。日常監視、権限管理、ジョブ、ログ、ダンプ、移送、RFC、性能、容量、障害記録を一つの運用サイクルとして扱います。

重要なのは、異常を見つけること、影響を判断すること、安全に変更すること、復旧後に業務処理まで確認することです。担当者ごとの経験に依存せず、確認項目、判断基準、承認、記録、引き継ぎを標準化すると、SAPシステムの安定性と障害対応の再現性を高められます。