CI/CDとトランスポート管理：パターンと原則

JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

May 14, 2026 · 21 min read

本記事の位置づけ#

参考資料#

1) CI/CDとトランスポートのランドスケープ#

SAP BTPのDevOpsツールチェーンは、コードのビルドとテスト（CI/CD）、および検証済みアーティファクトを環境間でプロモーションする（トランスポート管理）という2つの領域に分かれています。これらのツールは代替手段ではなく、連携して動作します。

これらは代替ではありません。CI/CDはビルド品質を扱い、Transport Managementはリリースガバナンスを扱います。Transport ManagementをスキップしてCI/CDから本番環境に直接デプロイすると、承認ゲートとトランスポート監査証跡が失われます。

2) S/4HANA への接続方法#

SAP BTP CI/CD およびトランスポート管理は、以下の3つの主要な統合パスを通じて SAP S/4HANA に接続します。

[Developer Workstation]
        │  git push
        ▼
[SAP CI/CD Service / Project Piper]
        │  1) Build MTA (.mtar)  2) Run unit + integration tests
        │     against S/4HANA sandbox (OData sandbox / BTP API Hub)
        ▼
[SAP Cloud Transport Management — DEV Node]
        │  Approved → forward to QA node
        ▼
[SAP Cloud Transport Management — QA Node]
        │  Integration tests against S/4HANA QA system
        │  Approved → forward to PROD node
        ▼
[SAP Cloud Transport Management — PROD Node]
        │  Release to CF space / ABAP PROD / CPI PROD
        ▼
[SAP S/4HANA (on-premise or Cloud)]  ←── calls or receives data

3つの接続パターン：

• CAP/Cloud Foundry サイドバイサイド: CI/CD が CAP アプリケーションをビルドし、S/4HANA サンドボックスに対して統合テストを実行し、MTA アーカイブを生成して、ランドスケーププロモーションのために TMS にアップロードします。S/4HANA は下流の依存関係であり、トランスポートルートのノードではありません。

• CPI (Cloud Integration) iFlow: CPIコンテンツパッケージはTMS CPIノードを介して転送されます。パイプラインはiFlowをQA S/4HANAシステムに対してテストし、TMSは承認されたパッケージをPROD CPIテナントにプロモートします。

• ABAP サイドバイサイド（Steampunk）：gCTS は ABAP オブジェクトの信頼できる情報源として Git を使用します。パイプラインはソフトウェアコンポーネントをクローンし、ABAP ユニットテストと ATC チェックを実行した後、TMS が Steampunk ランドスケープを通じてプロモートするトランスポートリクエストを作成します。

重要なポイント: SAP Cloud Transport Management（ help.sap.com →）は、コアABAPワークロード向けのS/4HANAトランスポートシステム（STMS）を置き換えるものではありません。S/4HANAと併置されるBTPホストコンポーネントに対して、ランドスケープガバナンスを拡張するものです。

3) 成熟度マップ#

4) 要件チェックリスト#

これらのチェックリストをプロジェクトのブループリントに組み込んでください。前提条件が欠けていると、プロジェクト後半で修正に多大なコストがかかる段階になって、パイプラインやトランスポートの障害が発生します。

SAP CI/CD サービス#

Project Piper (Jenkins)#

SAP Cloud Transport Management#

ABAPとgCTS（BTP ABAP環境またはSteampunk）#

5) 意思決定基準#

最初に問うべき3つの質問#

Q1. 現在のリリースプロセスにおいて、測定可能な非効率性や問題点はありますか？

チームがCF CLIを使って手動でデプロイしたり、CPIパッケージを手作業でアップロードしたり、自動テストなしでSTMSトランスポートを実行している場合、非効率性はすでに存在しています——ただ定量化されていないだけです。考えてみてください：毎週何時間が手動リリース作業に費やされ、何件の本番インシデントが未テストのトランスポートに起因しているでしょうか？明確な答えがなければ、CI/CDやTMSの取り組みは予算承認を得るのに苦労するでしょう。

Q2. デプロイメント認証情報の所有者は誰ですか。また、システム環境には正式な承認ゲートが必要ですか。

規制業界（金融、医療、公共事業）では、パイプラインから本番環境への直接デプロイが変更管理ポリシーに違反する可能性があります。本番環境へのプロモーション前に文書化された承認が必要かどうかを、ITガバナンスの観点から早期に判断してください。必要な場合、SAP Cloud Transport Managementはオプションではなく、承認管理のポイントとなります。ランドスケープに規制対象の本番環境がない場合、直接的なCFデプロイパイプラインで十分な場合があります。

Q3. CI/CDツールチェーンおよびTMSサブスクリプションに対して予算権限を持つ内部スポンサーはいますか？

SAP CI/CD サービス（ help.sap.com →）および SAP Cloud Transport Management は、いずれも BTP のサブスクリプションとエンタイトルメントが必要です。Project Piper には Jenkins インフラストラクチャが必要です。これらは継続的なコストであり、誰かが負担しなければなりません。この問題を先送りにしたプロジェクトは、エンゲージメント後半に BTP サービスのサブスクリプション請求書が届くと、しばしば停滞します。

プロジェクトコンテキストによるドメイン選択#

ライセンスとコスト#

6) よくある障害#

障害1：本番環境への直接デプロイのショートカット

パイプラインはビルドから本番CFスペースへ直接デプロイします。TMSや承認ゲートはありません。規制対象環境では、これは変更管理ポリシーに違反します。修正方法：すべての本番デプロイをSAP Cloud Transport Management経由でルーティングします。最小限のTMSランドスケープ（1つのルート、並列QAノードなし）でも、追跡可能な承認記録が得られます。

障害 2: パイプライン設定前にトランスポートノードが未定義

CI/CDパイプラインはtmsUploadステップを含めて構築されていますが、SAP Cloud Transport Managementにノードが設定されていません。ノード名が存在しないため、アップロードが失敗します。修正方法：アーキテクチャスプリントの段階でトランスポートランドスケープ（ノードとルート）をモデル化します。パイプライン構築後の後続作業として行うのではありません。

障害 3: 環境固有のパラメータが mta.yaml に組み込まれている

接続資格情報やサービスインスタンス名が、ある環境のMTA記述子にハードコードされています。TMSが同じ.mtarを別の環境にプロモートすると、ハードコードされた値がデプロイメントを破損させます。修正方法：環境固有のオーバーライドをすべてMTA拡張記述子（.mtaext）に外部化し、tmsUploadステップのnodeExtDescriptorMappingを介してTMSノードにマッピングします（ project-piper.io →）。

障害 4: CI/CDとリリース管理の混同

Teamsは、CI/CDパイプラインに直接PRODデプロイアクセスを付与することで、ビルド品質とリリースガバナンスの両方の責任を割り当てています。これにより、変更管理に必要な承認ゲートと監査証跡が失われます。CI/CDツールはアーティファクトを所有し、SAP Cloud Transport Managementはそのアーティファクトがいつどこに配置されるかを管理します。

障害 5: ABAP の自動テストステージがない

ABAP トランスポートが、ABAP 単体テストや ATC チェックを実行せずにトリガーされています。その結果、QA や PROD に未検出のリグレッションが到達しています。対策：トランスポートを作成する前に、ソフトウェアコンポーネントをクローンして ATC チェックを実行するパイプラインステージを追加します（ help.sap.com →）。最小限のチェックバリアント（構文エラー、セキュリティ上の問題）でも、最も一般的なリグレッションクラスを排除できます。

障害 6: 開発者ワークステーション全体での認証情報の乱立

TMS、CF組織、CPIテナント、ABAP環境のサービスキーは、個々のマシン上のプレーンテキストファイルに保存されています。開発者が退職したりキーが期限切れになると、パイプラインが失敗し、誰も認証情報がどこに保存されていたかを把握できません。
対策: すべてのパイプライン認証情報を、Jenkins Vault統合、SAP CI/CDサービスの認証情報ストア、またはBTPサービスバインディングに保存し、ローカルファイルやGitには決して保存しないでください。

障害 7: 納期短縮のための確認ステージの削除

スケジュールのプレッシャーの中で、チームはリリースを迅速化するために手動承認ステージ（ project-piper.io →）を削除しました。次の実行では、レビューなしで壊れたコミットが本番環境にデプロイされます。修正方法：削除されたConfirmステージを、自動化されたスモークテストとTMS承認ルールに置き換えてください。単にゲートを削除するのではありません。

FAQ#

Q: SAP CI/CDサービスは、オンプレミスのJenkinsインストールを完全に置き換えることができますか？

標準的なSAPスタック（CAP、SAPUI5、Cloud SDK、Kyma、CPI）を使用するチームにとっては、その通りです。SAP CI/CDサービスは、Jenkinsを運用することなく、必要なすべてのパイプラインステージを提供します。高度にカスタマイズされたパイプライン（非標準のビルドツールやPiperステップでカバーされないツールチェーン統合）を持つチームは、Jenkins上のProject Piperの方が柔軟性が高いと感じるでしょう。マネージドサービスは、カスタマイズ性と運用の簡素さをトレードオフにしています。

Q: SAP Cloud Transport Management はオンプレミスのABAPトランスポートで動作しますか？

部分的に。TMS は、オンプレミスの S/4HANA に接続し、標準の ABAP トランスポートをトリガーする CTS+ ノードを含めることができ、BTP コンテンツとオンプレミスの ABAP にわたる統一されたランドスケープビューを提供します。TMS は STMS を置き換えるものではなく、トランスポートがリリースされたときに調整を行います。実際の ABAP トランスポートは STMS 内で引き続き実行されます。

Q: TMS トランスポートがランドスケープの途中で失敗した場合はどうなりますか？

失敗したインポートは、そのノードのインポートキューに残ります。既にインポート済みの上流ノードにあるコンテンツは自動的にはロールバックされません。根本原因（通常はターゲット環境でのデプロイエラー）を調査し、修正してからインポートを再試行してください。サイレントTMS障害は最も有害です。インポートキューの監視とアラートは必須です。

Q: gCTSはいつ従来のABAPトランスポート（STMS）の代わりに使用すべきですか？

gCTSは、開発がBTP ABAP環境（Steampunk）またはgCTSが有効化されたS/4HANA 1909以降で行われ、チームがGitベースのワークフロー（フィーチャーブランチ、プルリクエスト）を希望する場合に適しています。従来のSTMSは、gCTSがまだ有効化されていないオンプレミスシステムではデフォルトのままです。gCTSは、意味のあるABAP CI/CDパイプラインの前提条件です。

Q: 監査目的で輸送依頼を文書化するにはどうすればよいですか？

tmsUpload ステップは、デフォルトで Git コミット ID をトランスポート要求の説明として使用し（ project-piper.io →）、各トランスポートをそのソースコミットにリンクします。規制対象環境では、customDescription パラメータを使用して変更チケット ID を明示的に含めてください（例："JIRA-4321: Add payment service endpoint"）。TMS はこれをトランスポート履歴に保存し、監査者に対してチケットからコミット、デプロイメントに至るトレーサブルなチェーンを提供します。

Q: Project Piper は無料で使用できますか？

Project Piperはオープンソース（Apache 2.0）であり、無料で利用できます。コストはインフラストラクチャに発生します。Jenkinsインスタンスを実行する必要があり、SAPはコミュニティサポートのみを提供します。組織がSLAに基づくサポートを必要とする場合、SAP CI/CDサービスはBTPサービスサブスクリプションのコストでJenkinsの運用負担を解消します。

Q: BTPプロジェクトからCI/CD自動化をスコープ外とするべきタイミングはいつですか？

以下の場合、スコープを外す（Descope）こと：(1) プロジェクトがコード変更のない単発の移行である場合、(2) デプロイメントの頻度が月1回未満で、変更量がごくわずかである場合、(3) プロジェクトがカスタムコードを伴わず、設定（ロール割り当て、エンタイトルメント管理）のみを提供する場合。カスタムアプリケーションロジック（CAPサービス、SAPUI5アプリ、CPI iFlows、ABAP拡張）を提供するプロジェクトは、最初の数回のリリースサイクル内でCI/CDへの投資を回収できます。

概要#

SAP BTPのCI/CDおよびトランスポートツールチェーンは、2層構造のシステムです。CI/CDツール（SAP CI/CDサービスまたはProject Piper（ project-piper.io →））がビルドとテストのライフサイクルを担当し、SAP Cloud Transport Managementがリリースガバナンスのライフサイクルを担当します。これらの責務を混在させたり、トランスポート層を完全にスキップしたりすることは、要件段階で最もよく見られるアーキテクチャ上の誤りです。

Cloud Foundryベースのプロジェクトでは、MTAアーカイブをビルドし、TMS DEVノードにアップロードし、承認してランドスケープ全体にプロモートするというパターンが確立されています。BTP ABAP Environment上のABAPプロジェクトでは、gCTSによりGitベースのワークフローと自動テストが可能になりますが、事前のソフトウェアコンポーネント設定と単体テストが必要です。ハイブリッドランドスケープでは、TMSのマルチノードアーキテクチャが、1つのプロモーションワークフローですべてのコンテンツタイプを処理します。

パイプラインの前に、トランスポートランドスケープの設計から始めてください。ノード名とルート構造によって、リリースステージの設定方法が決まります。

次に読むべきもの#