SAPでは、開発・テスト・本番といった複数のシステム間で整合性を保ちながら変更を反映させるために、独自の構成管理システムが用意されている。
この仕組みは「移送(Transport)」と呼ばれ、SAPシステムの導入や運用に関わるエンジニアやコンサルタントにとって、避けては通れない重要な業務プロセスである。
特に、SAPプロジェクトの実現化フェーズにおいては、システムのカスタマイズが日常的に行われるため、移送作業も頻繁に発生する。
本記事では、このSAPにおける移送の仕組みとその手順について、初心者にも分かりやすく丁寧に解説する。
SAPの移送とは
SAP独自の構成管理システム
SAPにおける「移送(Transport)」とは、開発環境で作成・変更されたオブジェクト(プログラムやカスタマイズ設定など)を、開発環境 → 検証環境 → 本番環境 へと、順に反映していくための仕組みである。

移送の仕組みによって、「誰が」「何を」「いつ」「どの環境で」変更したかを明確に管理でき、パラメータ設定やソースコードのバージョン管理、変更履歴のトレースが強固に担保される。
「移送」は複数環境にまたがる変更を整然と、一貫性を保って適用できるため、運用効率や安定性を確保する上で非常に重要なSAPの機能である。
移送の3要素
SAPにおける「移送」の仕組みは、システム全体で一貫性のある変更管理を実現するための非常に強力な機構である。その根幹を支えるのが、以下の3要素だ。
担当システム | 機能 |
---|---|
TR(Transport Request) | 移送の基本的な単位。移送ごとに「移送依頼番号」というユニークな番号が採番される。 |
CTS(Change and Transport System) | TRの作成、管理、履歴追跡を行う。移送ライフサイクル全体を管理する枠組み。 |
TMS(Transport Management System) | 移送のルート制御・適用を実行する。実際に移送をルーティングし、適用するコントローラー。 |
それぞれが役割を分担し、SAP全体として一貫性のある、追跡可能な移送管理を実現している。
TR(Transport Request):移送の単位
TR(トランスポートリクエスト):「移送依頼」は、SAPで開発・設定変更を行った際に、その変更内容をまとめて管理する「パッケージ」的存在である。TRはオブジェクト単位で変更を蓄積し、適切なタイミングで他のシステム(品質保証、本番など)に移送される。
- 移送依頼の主な構成要素
-
- 依頼ヘッダ:依頼作成者、依頼種別(ワークベンチ/カスタマイジング)、説明文など
- タスク:開発チームでの個別作業内容(複数ユーザーが同時に作業可)
- オブジェクトリスト:実際に変更されたテーブルやプログラムの情報
- 移送依頼の種類
-
TRの種類 用途 ワークベンチ依頼 ABAP開発、プログラム、テーブル定義など カスタマイジング依頼 IMG設定、アプリケーション設定など ローカル依頼 他システムへは移送されないローカル作業用 - 移送依頼を作成する流れ
-
- SAPシステム上で開発や設定などの作業を行う。→ TRが登録される
- 作業完了後、TRを「リリース」する
- リリースされたTRが、他の環境への移送対象となる
CTS(Change and Transport System):移送全体を管理する枠組み
「CTS(チェンジ・アンド・トランスポート・システム)」は、SAPにおける変更内容の登録・管理・移送を制御する全体のフレームワークである。開発から運用まで、変更プロセスのライフサイクルを一元的に管理するための仕組みとして位置づけられる。
- 主な役割
-
- TRの生成・管理
- オブジェクトのバージョンコントロール
- 移送ログ・エラーの追跡
- TRとユーザーのマッピング
- CTSログ/履歴による監査対応
- CTSの機能の特徴
-
- ABAPだけでなく、JavaベースのSAP NetWeaverやFioriアプリケーションの移送にも対応
- SAP Solution Managerと連携することで、変更管理プロセス全体を可視化・統制可能
TMS(Transport Management System):移送経路と実行制御
「TMS(トランスポート・マネジメント・システム)」は、TRが作成・リリースされた後、どのシステムへ、どの順序で、どのタイミングで移送されるかを制御する仕組みである。移送のルーティングと実行のオーケストレーターといえる。
- TMSの構成と機能
-
- Tドメインコントローラ(Domain Controller):TMS全体の中枢。移送設定を集中管理。
- トランスポートルート(Transport Routes):開発→QA→本番など、移送の流れを定義。
- インポートキュー(Import Queue):各環境における移送待ちリスト。
- STMS / STMS_IMPORT トランザクション:TMSのGUI操作画面。リクエストの確認・インポート処理を行う。
- CTSの特徴
-
- ABAPだけでなく、JavaベースのSAP NetWeaverやFioriアプリケーションの移送にも対応。
- SAP Solution Managerと連携することで、変更管理プロセス全体を可視化・統制可能。
移送のメリット
移送のメリットを整理すると次のようになる。
- 一貫性の確保: 全環境に渡る変更を同じTRで管理することで、不整合を防止できる。
- 追跡性向上: 変更内容や担当者、日時などがすべてTRに記録され、監査対応や障害解析も容易になる。
- 自動化と中央管理: TMSを通じ処理が自動化され、属人化を抑制、品質とスピードを両立できる。
- リスク低減: 本番環境への影響や不整合発生リスクを、テスト環境で前もって検証可能。
他のパッケージシステムとの違い、強み
SAPの移送は、パッケージ性能/レコード管理度で、他のパッケージシステムと比較して際立っている。
たとえば、Gitのようなソースコード管理(SCM) では、ブランチやマージ操作が中心で、環境へのデプロイメント(適用)は別ツールで行うケースが多い。
SAPの移送管理は、SCMとデプロイメントが密に統合されており、SAP固有のオブジェクト(IMGで設定したパラメータ、テーブルレコード、プログラムバージョン)も一元管理が可能となっている。
また、専用のUIやトランスポートコントロールがあるので、運用負荷が少なく、SAP標準の仕組みで完結する点が強みだ。
移送の手順
移送登録から適用までのステップ
SAPにおける移送の手順は、以下の3ステップで構成される。
- 開発環境で移送依頼を登録
- 開発環境で移送依頼をリリース
- 移送を適用する環境で、移送依頼をインポート
それぞれの操作を具体的に見ていこう。
移送依頼(TR)は、開発者やSAPコンサルタントがプログラム開発やカスタマイズ(パラメータ設定)を実行した際に登録する。
たとえば、カスタマイジングを行った際に[保存]ボタンを押下すると、次のような画面がポップアップする※のでTRを登録できる。

新規に移送依頼を登録するには、[依頼登録]ボタン(またはF8キー)を押下する。既に登録済みのTRを利用する場合は「自分の依頼」ボタンを押下し、自分が登録済みのTRを選択することも可能だ。
- 通常は、BC(ベーシス)コンサルタントによって構成されている。
開発が完了した後、TRを「リリース」することで本番への適用準備となる。
カスタマイジングのTRのリリースは、次のようにして行う。
- 開発環境でT-CODE: SE01またはSE10を起動し、移送依頼を一覧表示する。
- 「修正可能」グループから、リリース対象のTRを選択する。
TRは親子関係になっていることが多いため、下位の方から選択する。 - 上部のメニュー「依頼/タスク」から「リリース」を選択する。
- リリースされたTRは、「リリース済」グループに移動される。
TRはリリースすると、TMSによってルーティングされている検証環境や本番環境に、自動的に取り込まれる。
インポートを行うには、インポートを行う環境/クライアントにログオンし、T-CODE: STMSにて、対象のTRを選択、インポート操作を行う。
インポート操作を行った後は、ログを照会して正常にインポートされたことを確認する。エラーが発生している場合はエラーメッセージを解析し、適切に対処する。
移送依頼の取り消し
SAPにおける「移送依頼(TR)の取り消し(キャンセル)」とは、まだリリースしていない移送依頼を削除する操作を指す。これは、誤って作成した移送依頼や、不要になった移送移送を削除したい場合に有効である。
移送依頼を取り消す手順
TRを取り消すには、次のように操作する。
- T-Code: SE01またはSE10を起動し、移送依頼の一覧を表示する。
- 「修正可能」グループから、削除したいTRを選択する。
- 上部のメニューから「削除」を選択する。
取り消しが成功すると、TRが一覧から消えていることを確認できる。
リリース後やインポート後の取り消しはできない
取り消すことができるTRは、未リリース、すなわち「修正可能」な状態のものに限られる。
リリース済みのTRや、本番環境などでSTMSを通じてインポートされた内容は、SE10やSE01で取り消すことはできない。
これは、インポートされた時点でシステム側の設定やプログラムが変更されているため、物理的に元に戻すことができないからである。
インポート後に、誤りや問題が発覚した場合は、それを修正(上書き)または削除するための新たなTRを登録することで対処する。
移送関連のトランザクションコード
以下に代表的なSAPトランザクションコード(T-code)を紹介する。
T-code | 機能 |
---|---|
SE01 | TRの作成/表示/削除 |
SE09 | ワークベンチ依頼一覧表示(主にプログラム開発関連) |
SE10 | TRの作成/表示/削除。カスタマイジングTRに特化。 |
STMS | トランスポート管理システム起動 |
STMS_IMPORT | リリース済TRの適用実行 |
STMS_ADMIN | TMSの設定全般(ドメイン/システム分配パスなど) |
SE03 | TR分析/コンテンツ表示/トラブル解決用 |
SCC1N | 同じ環境(サーバ)内でのTR適用 |
移送依頼を登録するタイミングは、SAPコンサルタント・開発者が作業を行った場合である。したがって、SAPコンサルタント・開発者が使用するトランザクションは、主にSE01、SE10ということになる。
TRはSAPシステム上で開発作業を行えば自然と登録されるが、インポートをしない限り、別の環境に影響を与えることはない。このため、移送依頼を登録することについては、あまり神経質になる必要はない。
一方、移送依頼をインポートするSTMS系のトランザクションは、環境を直接変更するため操作は慎重さを要する。このため、移送依頼をインポートするプロセスには、ルールや手順を厳格化しておくのが通常である。インポートの「承認」プロセスを設けているプロジェクトも多い。
Fiori関連オブジェクトの移送
Fiori関連オブジェクトも移送の対象
SAP Fioriは、SAPの次世代UI/UXを実現するWebベースのアプリケーションであり、UI5アプリケーション、カタログ、グループ、タイル設定など、従来のABAPオブジェクトとは異なる構成要素を持つ。
Fiori関連のオブジェクトも、もちろんSAPの標準移送機能で本番環境へ移送することが可能である。
よくある移送のトラブルとその防止策
SAPの移送では高機能なシステムが提供されているものの、実際の運用現場では以下のようなトラブルが発生しやすい。特に本番環境への適用前には十分な注意が必要である。
1. 移送順序のミスによるエラー
たとえば、依存関係のあるカスタマイズが先に移送されていない場合、後続のカスタマイズを先に移送してしまい、エラーを起こすケースがある。
防止策:
環依存関係を考慮した順序で移送リクエストをリリース・インポートする。
なお、依存関係のある移送が事前に適用されていないことによってエラーが発生した場合は、先に原因となる移送を適用したうえで、再度エラーとなった移送を行えば、正常に処理される。
2. 開発と本番でテーブル設定の整合性が取れない
移送により設定項目が本番へ反映されたが、環境依存の差異により動作不良が起こる場合がある。
防止策:
環境固有の設定(例:URLやメール設定)を特定し、これらは別管理として、移送しないようにする。
3. 本番環境でのリリースミス
開発者が誤って未完成のTRをリリースし、本番に流れてしまうケースがある。
防止策:
本番リリース前に十分なレビューと、ステークホルダーの承認フローを設定する。
4. 移送依頼の上書き・重複による競合
大規模プロジェクトでは、同一オブジェクトに対して複数のチームによってTRが作成され、異なる内容が競合してしまうことがある。
防止策:
オブジェクトロックやチーム間のTR管理ルールを明確にする。
本番リリース前には十分なレビューと、ステークホルダーの承認フローを設定する。
また、定期的にチーム間でミーティングを行い、開発箇所の共有と連絡をとりあうのも効果的。
移送の上書きや重複によって、環境間で不整合が起きることがある。カスマイズにおける環境間の差異を調査する方法について解説した記事は以下。
5. インポート後の問題に気づかない
TR適用後に不具合が発生しても、気付かず運用が進んでしまうことがある。
防止策:
STMSログのチェックや、重要トランザクションへの影響をシナリオテストで確認する。
まとめ
本記事では、SAPの構成管理における中核プロセスである「移送」について、全体像から手順、関連トランザクション、よくあるトラブルとその対処法までを網羅的に解説した。SAP独自の構成管理システムである「移送」は、非常に常に強力かつ一貫性のある管理が可能であり、適切に運用することで品質を保った安定稼働を実現できる。
移送のメリットを最大限に活かすためには、日々の細やかな移送管理を実践することが重要である。この記事を通じ、SAP運用における移送作業の本質を理解し、トラブルのない移送運用と、システムの維持を目指してほしい。
コメント