Cloud ALM: アーキテクチャと用途

JinJin48

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

May 12, 2026 · 23 min read

本記事の位置づけ#

参考資料#

1) Cloud ALMのランドスケープ#

SAP Cloud ALMは、SAP BTP上で動作するすぐに使えるSaaSアプリケーションであり、SAPランドスケープの中央管理プラットフォームとして機能します。100以上のソリューションと約6,000のアクティブ顧客をサポートしています（ SAP Cloud ALM — メイン製品ページ）。

これらの4つの柱は、SAP運用ライフサイクルにおいて明確な役割を果たします。これらは互いに代替するものではありません。

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

  Customer landscape
  ┌────────────────────────────────────────────────────┐
  │  S/4HANA Cloud Public Ed.  S/4HANA Cloud Private  │
  │  S/4HANA On-Premise        SAP BTP Extensions     │
  │  SuccessFactors / Ariba / non-SAP SaaS             │
  └──────────────┬─────────────────────────────────────┘
                 │  Push via REST API (data providers)
                 │  No Cloud Connector required (cloud systems)
                 │  SAP Cloud ALM REST API + service key (on-premise)
                 ▼
  ┌──────────────────────────────────────────────────────────────┐
  │              SAP Cloud ALM (SaaS on SAP BTP)                 │
  │                                                              │
  │  ┌─────────────┐  ┌────────────────────┐  ┌─────────────┐   │
  │  │ Landscape   │  │  Implementation    │  │ Operations  │   │
  │  │ Management  │→ │  (Processes, Tasks,│  │ (Health,    │   │
  │  │ (auto-import│  │   Reqs, Tests,     │  │  RUM, BPMon,│   │
  │  │  from Cloud │  │   Change/Deploy)   │  │  Job Mon,   │   │
  │  │  Directory) │  └────────────────────┘  │  Int. Mon.) │   │
  │  └─────────────┘                           └─────────────┘   │
  │                                                              │
  │  Dedicated BTP Global Account + Subaccount (auto-created)   │
  │  Contains: Cloud ALM app, Cloud Integration Automation, CTM  │
  └──────────────────────────────────────────────────────────────┘
                 │
                 │  Bidirectional REST APIs (SAP Business Accelerator Hub)
                 ▼
       Jira / Azure DevOps / ServiceNow (external tools)

Cloud ALMテナントがプロビジョニングされると、専用のBTPグローバルアカウントとサブアカウントが自動的に作成されます。これはBTP上の顧客開発アカウントとは別のものです（ SAP Cloud ALMヘルプポータル）。管理対象システムは、SAP提供のデータプロバイダーを使用して監視データをプッシュします。オンプレミスシステムは、Cloud ALM BTPサブアカウントで生成されたサービスキーを介して認証します。このAPIベースのパターンでは、SAP Cloud Connectorは不要です。JiraやAzure DevOpsなどの外部プロジェクトツールは、SAP Business Accelerator Hubで公開されている双方向REST APIを介して接続します。

重要ポイント: Cloud ALMは、SAP Activateプロジェクトの実行とランドスケープ運用監視のための単一の記録システムです。既存のツールの上に構築されるレポートレイヤーではなく、完全に採用するお客様にとっては、ツール（Solution Manager、スタンドアロンのテスト管理、手動変更追跡）を置き換えるものです。

3) 成熟度マップ#

運用モニタリングは、アクティブなデプロイメント全体で毎日63億のIDOCを追跡しており、プラットフォームの本番規模を反映しています（ SAP Cloud ALM for Operations）。

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

（ SAP Cloud ALMのセットアップと管理および SAP Cloud ALMへの移行は、以下のすべての前提条件に関する正式な情報源です。）

テナントおよび契約の前提条件#

実装管理#

テスト管理#

運用監視の設定#

5) 意思決定基準#

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

Q1. 現在のALMまたは運用プロセスにおいて、測定可能な課題はありますか？

もし顧客が具体的な問題を特定できない場合（信頼性の低い輸送追跡、不完全なテストカバレッジ、ビジネスプロセスの逸脱に対する可視性の欠如、または断片的な監視ツール）、Cloud ALMの導入はオーバーヘッドとして扱われます。進める前に、痛点を明確かつ測定可能にしてください。

Q2. 管理対象システムのデータレジデンシーと統合セキュリティに関する意思決定は誰が行いますか？

Cloud ALMは、管理対象の全システムから運用データを収集します。テナントのデータ保存リージョンと、各管理対象システムのデータプロバイダーが送信するデータは、お客様の情報セキュリティポリシーに準拠している必要があります。プロビジョニングを行う前に、セキュリティおよびデータガバナンスのステークホルダーから承認を得てください（ SAP Cloud ALM for Operations）。

Q3. 予算権限と組織的な権限を持ち、導入を推進するスポンサーは特定されていますか？

Cloud ALMは、導入プロジェクトの管理方法と運用チームの作業方法を再構築します。SAP Activateに準拠したプロセスモデルを適用し、データの一貫性を義務付けるスポンサーがいなければ、導入は断片的な利用に留まり、置き換えられる従来のツールよりも低い価値しか提供できません。

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

ライセンスとコスト#

6) よくある障害#

障害 1: Cloud ALM の本番稼働を移行プロジェクトとして扱うこと

チームはCloud ALMを、Solution Managerデータの技術的な移行（プロセスの抽出、テストケースのインポート、ChaRMワークフローの複製）として捉えています。Selective Data Transfer (SDT)ツール（SAP Note 3358439が必要）はビジネスプロセスとテストケースを移行しますが、ChaRMデータは移行されず、ITSM機能はCloud ALMには存在せず、レポート履歴はアクティベーション後に新規に開始されます（ Transition to SAP Cloud ALM）。並行したプロセス再設計のワークストリームなしに移行予算を割り当てたチームは、プロジェクト中盤で両方のツールを同時に運用していることに気づきます。

障害 2: 実装プロジェクトで Cloud ALM の開始が遅すぎる

プロジェクトチームは、Cloud ALMが標準状態ですぐに使用できると想定し、Exploreフェーズのキックオフ時にアクティベートします。しかし、まずPrepareフェーズの作業（ロール定義、ステータスとタグのガバナンス、並行ツールの統合戦略、テストデータ戦略、チームトレーニング）が必要です。これらの前提条件がExploreフェーズに持ち込まれると、最初のスプリントはプロセススコープ策定ではなくツールセットアップに費やされ、ワークショップの内容はCloud ALM外で記録されることになり、完全には埋まらないドキュメントギャップが生じます。

障害 3: ChaRM の機能ギャップを無視する

Solution ManagerのChange Request Managementは、順序付け、クリティカルオブジェクトチェック、自動レトロフィット機能を提供していましたが、Cloud ALMのFeature-based Change & Deployment Managementには直接的な同等機能はありません。ChaRMのユースケースをギャップ分析せずにCloud ALMでカバーできると想定したチームは、Realizeフェーズでトランスポート管理の問題に直面します。この問題への対応策としては、Cloud ALMのより標準化されたトランスポートアプローチを受け入れるか、ISVソリューションを導入してギャップを補うか、または高度な変更管理を明示的に対象外とし、その代替手段を文書化するかのいずれかが必要です。

障害 4: 並行ツール実行時の統合境界の未定義

JiraやAzure DevOpsをCloud ALMと併用する場合、各システムのスコープを明確にする必要があります。つまり、どのシステムがどのデータの記録システムとなるのか、同期の方向性、競合解決方法を定義します。この統合を都合に合わせて設定する技術的な手順として扱うプロジェクトでは、重複レコードやステータスの競合により、Cloud ALMを導入した目的であるトレーサビリティデータが破損することを認識しておく必要があります。

障害5: 運用監視範囲に関するスコープ前提の失敗

運用チームは、プロビジョニング後にCloud ALMがすべてのシステムを自動的に監視すると想定しています。しかし、管理対象システムごとにランドスケープ管理への明示的な登録と、個別のデータプロバイダーのインストールが必要です。非SAPアプリケーションにはカスタムインストルメンテーションが必要です。運用中に主要システムが監視されていないことに気付いたチームは、本番環境のプレッシャーの中でデータプロバイダーのセットアップを後付けで行う必要があり、異常検知に必要なベースライン構築期間が圧迫されます。

障害 6: モニタリングデータに対するデータガバナンスの例外処理の欠落

規制産業の組織は、Cloud ALMデータプロバイダーが収集する運用データ（ユーザーパフォーマンスデータ（Real User Monitoring）、ビジネストランザクションデータ（Business Process Monitoring）、統合メッセージコンテンツ（Integration & Exception Monitoring））が、データレジデンシーおよびプライバシー規制に準拠していることを確認する必要があります。データガバナンスの承認を本番稼働後の活動として扱うチームは、本番環境の監視アクティベーションが遅延するという問題に直面します。

障害 7: 長期プロジェクトにおける隔週の機能変更の無視

S/4HANAの移行は通常12～24か月にわたります。Cloud ALMでは、2週間ごとに新機能のリリースと既存ワークフローの変更が行われ、さらに毎日バックグラウンドでのデプロイメントが追加されます。リリースノートを追跡する担当者がいないチームは、各フェーズゲートで、前回トレーニングを受けてからツールが変更されていることに気づきます。特にテスト管理やデプロイメントのワークフローでこの問題が顕著です。

FAQ#

Q: Cloud ALM は、オンプレミスのみのランドスケープにおいて Solution Manager を置き換えるものですか？

Cloud ALMは、クラウドネイティブ環境とハイブリッド環境の両方をカバーします。オンプレミスのABAPシステムは、Cloud ALMのBTPサブアカウントで生成されたサービスキーを使用してCloud ALM REST API経由で接続します。SAP Cloud Connectorは不要です。ただし、オンプレミス環境のみで高度な監視要件がある組織は、補完的にSAP Focused Runを評価すべきです。SAPの見解として、Cloud ALMは戦略的プラットフォームですが、Focused RunはCloud ALMの現在の範囲を超えるオンプレミス主体のシナリオにおいて引き続き推奨されます（ Transition to SAP Cloud ALM）。

Q: ライセンスモデルはどのようになっており、費用はかかりますか？

SAP Cloud ALMは、SAP Enterprise Support、Product Support for Large Enterprises、またはEnterprise Support cloud editionを含むクラウドサブスクリプション契約を保有するお客様に対し、追加のライセンス費用は発生しません。Tricentis Test Automation for SAP（TTA）も、このエンタイトルメント内で追加費用なしで利用可能です。プロビジョニングはSAP for Meを通じてセルフサービスで行います。フェアユースに基づくストレージ制限（HANAストレージ8 GB、月間送信API転送8 GB）が適用されるため、お客様はランドスケープ規模に応じてこれらの制限をSAPアカウントチームと確認する必要があります。SAP Focused Runが必要な場合は、別途ライセンスが必要です。

Q: テスト自動化をCloud ALMプロジェクトのスコープから除外すべきタイミングはいつですか？

Descope Tricentis TTAは、以下の場合に該当します。(1) プロジェクトのタイムライン上、最初の回帰テストサイクル前にTTAテナントのプロビジョニングと初期テストケース作成に必要な4～6週間の準備期間を確保できない場合。(2) テスト範囲が、TTAが大規模なカスタムスクリプトなしではサポートしない非標準のUIコンポーネントやバッチ処理によって占められている場合。(3) 顧客が別のツールで確立された自動テストスイートを有しており、そのツールに関する組織的な専門知識が豊富な場合。これらのケースでは、Cloud ALMでの手動テスト管理は完全に機能し、トレーサビリティを維持します（ SAP Cloud ALM for Implementation）。

Q: 要件仕様書において、Cloud ALMの要件はどのように文書化すべきでしょうか？

Cloud ALMの導入を「ツールおよびインフラストラクチャ要件」の下でプラットフォーム要件として扱い、以下を含めること：(1) 有効化される具体的な機能、(2) 該当するサポート契約、(3) データ保存地域の選択根拠、(4) 外部ツールとの統合ポイント、(5) ガバナンス構造（ロール、ステータス分類）、(6) 対象となる場合のSolution Manager廃止スケジュール。この枠組みにより、ITガバナンスがCloud ALMをインフラストラクチャ上の決定として承認することが確実になる。

Q: Solution Manager からの移行時に ITSM プロセスはどうなりますか？

Solution ManagerのITSM機能はCloud ALMに相当するものがない — これは確認された機能ギャップです。SolMan ITSMを利用している組織は、それらのプロセスを専用のITSMプラットフォーム（ServiceNow、Jira Service Management、または類似のもの）に別のワークストリームとして移行する必要があります。Cloud ALMは、インシデント連携のために外部ITSMツールと統合するREST APIを提供しますが、それ自体がITSMワークフロー機能を提供するわけではありません。

Q: Cloud ALMはクリーンコアとRISE with SAPをどのようにサポートしますか？

RISE with SAPのお客様にとって、Cloud ALMは必須のALMプラットフォームであり、RISE with SAP Methodologyロードマップ（品質ゲートを含む）と、プロセス、拡張性、データ、統合、運用の5つの側面をカバーするクリーンコア成功計画を有効化します。SAP JouleはCloud ALM内のRISE Methodologyダッシュボードに統合され、クリーンコア基準に関するガイダンスを提供します（ SAP Cloud ALMとクリーンコア導入）。プロセス管理を通じて適用されるFit-to-Standardアプローチは、SAPベストプラクティスコンテンツをベースラインとして使用します。

Q: Cloud ALMテナントはどのくらい前にリクエストすべきですか？

Prepare フェーズの開始時にテナントをリクエストし、プロジェクトで使用できる状態になってからリクエストしないでください。プロビジョニング自体は迅速で、通常は SAP for Me 経由で 30 分以内に完了します。しかし、前提条件の確認（サポート契約の権利確認、管理 S ユーザーの特定、データセンターリージョンの選択、IT セキュリティ承認の取得）には、大規模組織では数日から数週間かかる場合があります。プロビジョニングを直前の管理手続きとして扱うことは、Cloud ALM 導入におけるプロジェクト開始の遅延の中で、最も回避可能な単一の原因です。

概要#

SAP Cloud ALMは、SAPのクラウドおよびハイブリッド環境管理における戦略的ALMプラットフォームであり、SAP BTP上でSaaSアプリケーションとして提供され、Enterprise Supportのお客様には追加ライセンス費用は発生しません（ SAP Cloud ALM — メイン製品ページ）。その3つの機能柱である「実装」「運用」「サービス」は、それぞれ成熟度が異なります。実装とコア運用の監視は本番利用可能ですが、変更・デプロイ管理はSolution ManagerのChaRMと比較して依然としてギャップがあります。Solution Managerからの移行はデータ移行ではなく、ITSMギャップ、ChaRMギャップ、および過去のレポートデータが引き継がれないことを考慮したプロセス再設計です。Explore開始前のPrepareフェーズでガバナンス、ロール定義、統合戦略を確立するプロジェクトは、Cloud ALMを実装途中で設定するツールとして扱うプロジェクトよりも一貫して優れた成果を上げます。Solution Managerのメインストリーム保守は2027年12月31日に終了します。移行ロードマップがない組織は、今すぐSAP Readiness Checkを開始すべきです。

次に読むべきもの#