SAP移送リクエスト・STMS入門｜開発→検証→本番への安全な変更管理

はじめに：なぜ変更管理が品質を決めるのか

SAPプロジェクトで「テスト環境では動いていたのに本番で動かない」「本番に上げたら他の機能が壊れた」――こうした事故の多くは、コードの問題ではなく「移送（変更の運搬）の手順ミス」が原因です。SAPは複数システム（DEV→QAS→PRD）にまたがって動くシステムであり、変更は「正しい順序で」「必要な単位で」「必要な依存関係を含めて」運ばないと、必ずどこかで壊れます。

なぜそれが致命的か（why so）。本番事故の原因が移送ミスだと、コードを直しても解決せず、影響範囲の調査と切り戻しに膨大な時間がかかるからです。さらに「いつ・誰が・何を・なぜ移送したか」が記録されていないと、監査要件も満たせません。

ではどうすべきか（so what）。変更を「移送リクエスト」という単位に閉じ込め、STMSで順序と承認を制御し、依存関係を可視化しながら運ぶのが答えです。SAPはこの目的のために移送リクエスト（Transport Request）とSTMS（Transport Management System）という仕組みを提供しています。本記事では基本概念・標準カバー範囲・S/4HANA Cloud時代の変更管理までを整理します。

移送リクエストとは何か

移送リクエスト（TR：Transport Request）は、SAPシステム上の変更をひとまとめにして他のシステムへ運ぶための「箱」です。プログラム・カスタマイズ設定・データディクショナリ定義など、SAP上のオブジェクトを変更すると、変更内容は必ずTRに記録されます。

TRには2つの種類があります。

TRの中には複数のタスク（Task）があり、各タスクが個別の開発者に紐づきます。複数の開発者が同じTRに対して並行して作業し、それぞれのタスクをリリースしていく構造です。

ランドスケープと移送の流れ

SAPは通常、3層システムランドスケープ（DEV/QAS/PRD）で運用されます。

flowchart LR
  DEV[DEV
開発] --> QAS[QAS
品質保証/UAT]
  QAS --> PRD[PRD
本番]
  DEV -.SBX.-> SBX[SBX
サンドボックス]

DEVで開発→QASでテスト→PRDで本番運用、という基本的な流れに加え、複雑なプロジェクトでは「DEV→QAS→PRE-PRD→PRD」の4層、「機能別に複数のDEVを並列運用しMERGEを設ける」など、ランドスケープが拡張されます。

なぜ複数システムが必要か。本番環境で直接開発・テストすると、誤った変更が即座に業務を止めるからです。SAPの移送モデルは「本番には常に検証済みの変更だけが届く」ことを保証する仕組みであり、これを軽視するとどんなに優れたコードを書いても運用は崩壊します。

STMS：移送を制御する管理ツール

STMS（Transport Management System、Tコード「STMS」）は、ランドスケープ全体の移送経路を定義し、移送リクエストの実行・モニタリング・承認を管理するBasisツールです。

主要機能

• 移送ルート定義：DEV→QAS→PRD のような物理的な移送経路を設定
• インポート待ち行列（Import Queue）：各システムに到着したTRをインポート順に並べる
• 移送承認：本番インポート前に承認を必須化する設定
• 移送ログ：すべてのインポート結果（成功・警告・エラー）を記録
• 並列インポート：大量TRを並列に処理して時間短縮

TRの状態遷移

flowchart LR
  A[作成
SE09] --> B[開発中]
  B --> C[タスク
リリース]
  C --> D[TR
リリース]
  D --> E[QAS
インポート]
  E --> F[PRD
インポート]

TRはリリースされると編集できなくなります。修正したい場合は新しいTRを作って追加変更を運ぶ形になります。

移送のベストプラクティス

1. TRは小さく切る

1つのTRに膨大な変更を詰め込むと、何か問題があったときに切り戻し単位が大きくなりすぎ、影響範囲の特定が困難になります。「1機能 = 1 TR」を徹底するのが運用品質を決める最大の鉄則です。

2. WorkbenchとCustomizingを混ぜない

WorkbenchとCustomizingを1つのTRに混在させると、依存関係の管理が複雑になります。原則として2種類のTRを別に作り、移送順序を明示します。

3. 移送順序を必ず守る

TRには依存関係があります。たとえば「Z構造体を作るTR」と「その構造体を使うプログラムのTR」は、必ず構造体のTRが先にインポートされなければなりません。STMSのインポート待ち行列で順序を確認し、必要なら手動で並べ替えます。

4. インポートエラーへの対処

インポートエラーには「警告（Return Code 4）」と「致命エラー（Return Code 8以上）」があります。RC=4は許容範囲のことが多いですが、RC=8以上は依存オブジェクトの欠落・構文エラーなどで本番影響が大きいため、原因を特定してから次のTRを進めます。

5. 切り戻し計画を必ず立てる

本番インポート前に「失敗したらどう戻すか」を必ず決めておきます。SAPの移送は基本的に「上書きインポート」なので、戻す場合は1つ前のバージョンを再インポートする必要があります。これを実現するには、変更前のオブジェクトを別TRで保管しておくか、オブジェクト履歴（Version Management）を活用します。

ChaRMとSolution Manager

大規模プロジェクトでは、移送だけでなく「変更要求→承認→開発→テスト→移送→クローズ」までのライフサイクル全体を管理する必要があります。これを担うのがSAP Solution ManagerのChaRM（Change Request Management）です。

ChaRMはSTMSの上位レイヤとして動き、変更要求（CR）を起点にTRの作成・関連付け・承認・本番リリースまでを統制します。Tコードの操作と承認ワークフローを統合できるため、内部統制やSOX対応で重宝されます。

なぜ大規模プロジェクトでChaRMが必要か。STMS単体では「承認の証跡」「変更要求との紐付け」を持てず、監査時に「このTRはなぜ作られたのか」を遡れないからです。ChaRMを使うと変更管理の完全なトレーサビリティが確保できます。

S/4HANA Cloud時代の変更管理

S/4HANA Cloudでは、移送の概念そのものが大きく変わります。

Public Edition

Public EditionではABAP開発が制限され、変更管理はFioriアプリ「Manage Software Collections」で行います。Workbench/Customizing TRという概念は薄れ、ソフトウェアコレクションという新しい単位で変更を運びます。

詳しくはS/4HANA Cloud Public vs Privateも参照してください。

Private Edition

Private EditionではほぼオンプレミスS/4HANAと同じ移送モデルを使えますが、SAP推奨のClean Core戦略に従い、コアへの直接変更を最小化することが求められます。Clean Core戦略の詳細はClean Core戦略も参照してください。

なぜCloud時代でも移送概念が残るか。「変更を段階的に運び、段階ごとに検証する」という業務システム運用の本質は、クラウド時代でも変わらないからです。技術的な実装は変わっても、ランドスケープの考え方は引き続き重要です。

現場で頻出するアドオン事例

事例1：TRリリースの事前チェックジョブ

TRリリース前に、コード品質チェック（ATC：ABAP Test Cockpit）を自動実行し、警告がある場合はリリースをブロックするアドオン。品質ゲートを開発フェーズで設けることで本番事故を減らせます。

事例2：移送ログのダッシュボード可視化

STMSのインポートログを毎日集計し、システム別・期間別の成功/失敗率を可視化するFioriダッシュボード。問題のあるTRや時間帯を特定するのに役立ちます。

事例3：本番インポート前の自動通知

本番インポートの直前に関係者へ自動メール／Teams通知を送るアドオン。インポート中の業務影響を最小化するため、関係者にリアルタイムで通知する仕組みです。

事例4：移送依存関係の自動分析

巨大プロジェクトで複数TRの依存関係を自動分析し、安全なインポート順序を提案するアドオン。手動で順序を組むとミスが生じるため、ロジックで担保します。

事例5：CI/CDパイプラインとの連携

GitやJenkinsとabapGitを組み合わせ、コード変更→自動テスト→自動TR作成→自動移送のパイプラインを構築するアドオン。BTPやABAP Cloud環境では一般的な構成です。

よくある疑問（FAQ）

Q. TRの中身を後から確認するには？ A. SE09／SE10で確認できます。リリース済みTRもオブジェクトリスト・タスク内容・タイムスタンプを参照できます。

Q. 移送を取り消す（切り戻す）にはどうしますか？ A. 標準では「逆向き移送」はサポートされません。1つ前のバージョンを再インポートするか、変更前のオブジェクトを別TRで運ぶ必要があります。

Q. クライアント依存とクライアント非依存はどう違いますか？ A. クライアント依存はクライアント固有のデータ（カスタマイズ設定、組織構造など）、クライアント非依存は全クライアントで共有されるオブジェクト（プログラム、DDIC定義など）です。

Q. STMSの設定は誰が行いますか？ A. Basis担当者が初期構築し、ランドスケープ変更時のみ更新します。日常運用では開発者・PMがインポート操作を行うことが多いです。

Q. abapGitを使えばTRは不要になりますか？ A. abapGitはコードのバージョン管理を提供しますが、SAP内のオブジェクト依存関係や本番への適用順序はTR/STMSで管理する必要があります。両者は補完関係です。

まとめ

• 移送リクエスト（TR）はSAP上の変更をひとまとめに運ぶ単位で、Workbench／Customizingの2種類
• ランドスケープはDEV→QAS→PRDの3層が基本、本番には検証済みの変更だけが届く設計
• STMSはランドスケープ全体の移送経路と承認を管理するBasisツール
• TRは小さく切る、Workbench/Customizingを混ぜない、依存順序を守るが運用三大原則
• ChaRMはSolution Manager上で変更管理ライフサイクル全体を統制する上位レイヤ
• S/4HANA CloudではSoftware Collections等の新概念に置き換わるが、ランドスケープ思想は不変
• アドオンは品質ゲート・可視化・自動通知・CI/CD連携など運用品質の底上げに使う

移送管理は「地味だが本番事故の8割を防ぐ」極めて重要な領域です。コードを書くスキル以上に、変更を安全に運ぶ運用力が、SAPプロジェクトの成功を左右します。最初に小さなプロジェクトで丁寧な移送運用を経験しておくと、大規模案件でも怖くありません。

移送管理の位置付けを含めて、S/4HANAの全体像を先につかんでおくとランドスケープ設計の議論が入りやすくなります。約2時間の動画で主要機能と特徴を一通り押さえられます。