SAPのテストと検証に適したツールセットの選び方

2026年のSAPプログラムの大半では、ツールの構成は、テスト管理とトレーサビリティにSAP Cloud ALM、自動化にTricentisの製品、性能テストに別のツールという形になります。Cloud ALMは、SAP Enterprise Supportまたはクラウドサブスクリプションをお持ちのお客様には、ライセンス料がかかりません。さらにEnterprise Supportには、エントリーレベルのTricentis自動化ライセンスが含まれるようになりました。デリバリーがすでにJiraで動いているなら、Xrayが合います。Solution Managerは、すでに構成されている環境でだけ意味があります。メインストリームメンテナンスが2027年に終了するためです。このガイドは、S/4HANAプログラムのツールを選ぶテストリード、プログラムマネージャー、QA責任者に向けたものです。何かを購入する前に、サポート契約ですでに何が使えるのかを確認してください。

すべてが完璧に動くツールのデモに、何十回も付き合ってきました。ところが実際のプロジェクトでは、スクリプトが壊れ続けたり、ベンダーが見せたとおりに連携が動かなかったりします。だから私は、機能チェックリストでSAPのテストツールを選びません。リリースの頻度、導入形態、監査への備えで選びます。

SAPのテストはリスク管理の手段であり、本稼働前に済ませるチェック項目ではありません。Realizeフェーズで始まり、システムが変わり続ける限り続きます。重要な層は5つあり、どれも別の層の代わりにはなりません。

1. 単体テスト：開発者が、個々のプログラムと機能が期待どおりに動作することを確認します。
2. 結合テスト：受注が出荷と請求に進み、各受け渡しが正しく転記されることを確認します。
3. リグレッションテスト：統合されたシステムでは、小さな変更が無関係な領域を壊します。
4. ユーザー受入テスト：財務と業務の担当者が、システムが実際のシナリオを処理できることを確認します。
5. 性能テスト：ピーク時のボリュームでもシステムが応答性を保つこと。機能テストのスクリプトでは、これは決してわかりません。

1. 05性能ピーク時のボリュームでも応答性を保つこと。専用のテストサイクルで確認する
2. 04ユーザー受入財務と業務の担当者が、実際のシナリオを確認する
3. 03リグレッション小さな変更が無関係な領域を壊すため、再テストする
4. 02結合フローの各受け渡しが正しく転記される
5. 01単体プログラムと機能が期待どおりに動作する

自動化が効果を発揮するのは、頻繁なリグレッションサイクル、大量のデータやインターフェースの確認、そしてトランスポートごとの予測可能なフローです。判断の代わりにはなりません。スクリプトは、画面がユーザーを混乱させることや、ワークフローが実務上意味をなさないことには気づきません。

事業が守るべきものをテストしてください。月次決算、収益に直結するプロセス、多数の拠点に展開するものすべてが最優先です。何にも結びついていない全面的なカバレッジは、保護にはなりません。5つ目の層については、私のSAP性能テストのガイドで詳しく扱っています。

SAP Cloud ALM

SAPのライフサイクル管理プラットフォームで、要件、テスト計画、テスト実行、不具合を、SAP Activateのフェーズと変更に結びつけます。Enterprise Support、Product Support for Large Enterprises、またはEnterprise Supportを含むクラウドサブスクリプションをお持ちのお客様は、クラウドエディションで、ライセンス料なしで1つのテナントを利用できます。RISEとGROWの契約も対象です。

SAPは、これにAIも加えました。Jouleベースのアシスタントが、ドキュメントから要件のドラフトを作成し、テストケースを生成できます。またSAPは、ECCからS/4HANAへの移行向けに、リスクベースのテスト範囲を提案するテスト管理アシスタントを打ち出しています。出力は、テストアーキテクトがレビューするための初稿として扱ってください。

新規のS/4HANAプログラムでは、Cloud ALMがテスト文書とトレーサビリティの標準的な基盤です。

Tricentis

Tricentis Toscaは、モデルベースの自動化を採用しています。スクリプトを書く代わりに、再利用可能なテストコンポーネントを視覚的に組み立てるので、機能担当のチームに向いています。SAP GUI、Fiori、SAP以外のアプリケーションを1つのテストフローでカバーでき、これが、業務プロセス全体をテストする際の最大の強みです。

SAPとTricentisは、緊密なパートナーシップを結んでいます。SAPは、SAP Enterprise Continuous Testing by Tricentis、SAP Load Testing by Tricentis、SAP Change Impact Analysis by Tricentisといった、Toscaベースの製品を再販しています。予算の面でより大きなニュースは、SAPの使用権にあります。Enterprise Supportのお客様には、Cloud ALMと統合されたTricentis Test Automation for SAPの期間ライセンスが付与され、現時点では2027年12月31日までです。指名ユーザー5人、月500回のテスト実行、実行エージェント5つが上限なので、プログラム規模のツールではなく、出発点として扱ってください。

苦手な場面：動的な要素の多いWebフロントエンドでは保守の手間が増え、大規模なテストデータ管理には通常、追加のツールが必要で、大きなモジュールライブラリには最初からガバナンスが必要です。

Xray for Jira

XrayはSAP向けに作られたものではありませんが、デリバリーがJiraで動いているなら、自然な拡張に感じられます。テストケースがユーザーストーリーや変更要求の隣に置かれるので、カバレッジがスプリント計画の一部になります。ビヘイビア駆動のテスト向けにCucumberとGherkinをサポートし、CIパイプラインにも組み込めます。

苦手な場面：バッチジョブや深い連携チェーンのような、SAPのトランザクションを重く扱うテスト、非常に大きなテストリポジトリ、複雑なカスタムレポートです。これらにはアドオンやAPIを使った作業が必要になります。

SAP Solution Manager

Solution Managerは、要件、テスト計画、実行、トランスポートを1か所でつなぎ、Change Request Management（ChaRM）と統合されています。Business Process Change Analyzerは、変更が実際に影響するプロセスにテスト範囲を絞り込みます。規制の厳しい環境では、この監査証跡は今も価値があります。

弱点は、古びたユーザーエクスペリエンス、重いセットアップ、SAPのユーザーインターフェースしかカバーしない自動化（CBTA）、そして今ではほとんどのチームが持たないスキルセットです。メインストリームメンテナンスは2027年末に終了し、一部の機能については2030年まで延長メンテナンスが続きます。すでに変更管理で使っているのでなければ、テスト管理のために導入しないでください。

ほかのツールは、特定のニッチに合います。Worksoft Certifyは、製薬のようなバリデーションが求められる環境に強みがあります。Katalonは、軽量でWebに面したSAPプロジェクトで役立つことがあります。どちらも、SAPの中核のテストプログラムに私が通常勧めるものではありません。

この表は、適合性を決める機能の観点から、4つのツールを比較したものです。

機能	SAP Cloud ALM	Tricentis	Xray for Jira	SAP Solution Manager
主な役割	テスト管理とトレーサビリティ	SAPと非SAPをまたぐ自動化	Jira内のテスト管理	ChaRMと結びついたテスト管理
要件のトレーサビリティ	ネイティブ。Activateのフェーズに連携	完全。独自のテスト管理を経由	Jiraのリンクを経由。規律が必要	ネイティブ。ChaRMとの組み合わせで最強
自動化	統合されたTricentisまたはパートナーのツールを経由	中核の強み。モデルベース	外部のフレームワークを経由	CBTA。SAPのインターフェースのみ
SAP以外のアプリケーション	限定的	対応。同じフロー内で	対応。フレームワークを経由	非対応
監査証跡	強い	強い	標準状態では限定的	強い。トランスポートも含む
ライセンス	Enterprise Supportがあればライセンス料なし	Enterprise Supportでエントリーライセンス。フル製品は別価格	Jiraへのユーザー単位のアドオン	オンプレミスのメンテナンスに含まれる
見通し	SAPの戦略的プラットフォーム	SAPとのパートナーシップが深化	Jiraの戦略次第	メインストリームメンテナンスは2027年に終了

私は、テストを文書化と自動化に分けて考えます。2つは別の問題を解決するものであり、両方を1つのプラットフォームに押し込もうとするチームは、たいてい苦労します。

文書化とトレーサビリティには、新規プログラムならCloud ALMを使います。すでにSolution Managerで変更管理を運用しているなら、システム環境が移行するまでそれを延ばし、その後で移行します。自動化には、リリース頻度が高く、SAP中心のシステム環境なら、Tricentisが私の通常のおすすめです。モデルが安定すれば、実行は安定し、スクリプトによる自動化に比べて保守も減ります。Jira上でFioriアプリとAPIを作るアジャイルなチームには、Xrayで十分なことが多くあります。

選ぶ前に、テストを実際に実行する人たちと、次の質問を順に確認してください。

要素	重要な理由	尋ねるべき質問
SAPのカバレッジ	テストは、SAP GUI、Fiori、実際に使うインターフェースを操作できなければならない	どのSAPのUI技術とAPIを、標準でサポートしているか？
変更の影響	トランスポート後に何を再テストすべきかがわかれば、過剰なテストとリスクの見落としを避けられる	変更を、影響を受けるテストに結びつけられるか？
CI/CD連携	自動実行には、パイプラインからのトリガーが必要	ビルドとトランスポートのツールと連携できるか？
ガバナンス	大規模なプログラムには、再利用でき、バージョン管理されたコンポーネントが必要	テストを、モジュール化、バージョン管理し、ウェーブをまたいで再利用できるか？
業務部門の使いやすさ	機能コンサルタントとキーユーザーがテストをレビューする必要がある	開発者以外が、テストケースを作成し、読めるか？
利用権	サポート契約で、必要の一部がすでにカバーされているかもしれない	Cloud ALMとTricentisの利用権で、すでに何が使えるか？
総コスト	セットアップ、エージェント、保守が、ライセンス料を上回る	モデルの保守を含めて、2年目にいくらかかるか？

グローバル製造企業：Tosca。この企業は、大幅にカスタマイズした倉庫システムとともにSAP ECCを運用していました。四半期ごとのリリースは、長い手作業のリグレッションサイクルと、本番環境への不具合の流出のせいで遅れ続けていました。チームは入荷物流でToscaを試行し、4週間かけて再利用可能なステップのライブラリを構築しました。自動実行はトランスポートの承認に結びつけられ、その後、出荷物流と生産計画にも広げられました。大量トランザクションのリグレッションカバレッジは35%から85%超に上がり、本稼働後の不具合は2四半期以内に40%減少しました。これほどカスタマイズされた環境を自動化することに、展開中は反発があったのを覚えています。本番環境のインシデントが減り、同じモデルが複数の工場で再利用されるのをチームが目にすると、反発は止みました。

小売企業：Xray。この企業は、新しいFioriアプリとクラウド連携と並行してS/4HANAに移行し、IT部門のデリバリーをすべてJiraで運用していました。Xrayはテストをユーザーストーリーに結びつけ、プロダクトオーナーがツールを切り替えずに進捗を追えるようにし、Fioriのスクワッドに向けてGherkin形式の受け入れ基準をサポートしました。テストの証跡は、スプリントレビューに間に合う形で用意されていました。トランザクションやバッチを重く扱うテストには対応できなかったでしょうが、アジャイルなFiori、API、ユーザー中心の作業には、複雑さを加えることなく十分でした。

金融機関：Solution Manager。財務、トレジャリー、規制報告にまたがる、大幅にカスタマイズされたシステム環境が、完全なトレーサビリティを求める監査の圧力にさらされていました。テストはスプレッドシートの中にあり、トランスポートとのつながりはありませんでした。テスト計画をChaRMの変更ドキュメントに結びつけ、すべての実行にタイムスタンプを付け、Business Process Change Analyzerで再テストの範囲を絞り込んだことで、議論の流れが変わりました。転機は、監査人がExcelファイルを求めなくなり、システム上でテスト履歴を直接検証するようになったときに訪れました。

Solution ManagerからCloud ALMへの移行。テスト文書の移行は、それ自体が1つのプロジェクトです。システム環境がもともと移行する時期に、たとえばRISE導入の一環として行い、単独では行わないでください。

ツールだけでは品質は生まれません。品質を生むのはこれらの実践であり、どのツールでも通用します。

実践	適用方法
早く始める	要件を書いている段階からテストリードを巻き込み、成果をテスト可能にする
トランザクションではなくプロセスをテストする	モジュールをまたぎ、例外を含むフローを作る
テストデータを管理する	専用のリセット可能なテストクライアントを使い、本番データはすべてマスキングする
リグレッションを日常化する	カットオーバーの前だけでなく、トランスポートごとに自動実行をトリガーする
リスクで優先順位を付ける	重要で変更の多いプロセスを先に。100%ではなく、賢いカバレッジを目指す
業務部門を巻き込む	実行が始まる前に、キーユーザーがテストケースを検証する
テストを変更承認に結びつける	検証済みのテストがなければ、トランスポートは動かさない
監査に備える	誰が、いつ、何をテストしたかを、エクスポートできる形で記録する

3つの数字を追ってください。本番環境への不具合の流出、書き直されずに再利用されたテストケースの割合、リグレッション全体にかかる時間です。これらが、どこに労力を注ぐべきかを教えてくれます。テスト結果をGo/No-Goの判断に結びつける方法は、私のSAPクオリティゲートの記事で紹介しています。

Cloud ALMが標準になります。新規のRISEとGROWのプログラムでは、これをテストの基盤にするべきです。Solution Managerを使う既存のオンプレミス環境には時間がありますが、多くはありません。2028年より前に移行を計画してください。ハイブリッドの環境では、しばらく両方が動きます。重なる期間に備えてください。

AIがテストのドラフトを作ります。Cloud ALMのJouleベースのアシスタントが、ドキュメントからテストケースと要件を生成します。削減効果が出るのは、バリエーションの大半がデータであるリグレッションスクリプトのような、量をこなす作業です。エッジケース、複雑な連携ロジック、性能テストの設計には、今もシニアのテストアーキテクトが必要です。

クリーンコアは、テストの対象を動かします。パブリッククラウドでは、コアにリグレッションを起こすカスタムコードはありません。プライベートクラウドとオンプレミスでは、コア内のカスタムABAPが、リグレッションを見つける場所として最もコストがかかります。修正し、次のSAPリリースに対して再検証することになります。SAP BTP上のサイドバイサイド拡張は、別々にバージョン管理され、専用のリグレッションカバレッジが必要です。

AIのステップには、新しいテストパターンが必要です。決定論的なリグレッションスクリプトでは、非決定論的なAIの振る舞いはテストできません。Jouleやエージェントが動かすステップには、別のテストの区分が必要になると考えてください。

自動化に最適なSAPテストツールはどれですか？

SAP中心のシステム環境では、私が最もよくお勧めするのはTricentis Toscaです。モデルベースのアプローチでテストを作りやすく保守しやすくなり、SAPと非SAPのアプリケーションを1つのフローでカバーできます。チームがJiraで仕事をし、主にアジャイルでFioriアプリを作っているなら、テストフレームワークと組み合わせたXrayのほうが合うかもしれません。決め手は、デモではなく、状況です。

TricentisはSAP Enterprise Supportに含まれますか？

一部は含まれます。SAPは、SAP Cloud ALMと統合されたTricentis Test Automation for SAPの期間ライセンスを、現時点では2027年12月31日まで付与しています。対象は、Enterprise Support（クラウドエディションまたはオンプレミス）またはProduct Support for Large Enterprisesをお持ちのお客様です。指名ユーザー5人、月500回のテスト実行、実行エージェント5つまでに制限されています。より大規模なプログラムでは、通常、Tricentisのフル製品が必要で、SAPはそれも再販しています。

SAP Solution Managerでテスト自動化はできますか？

一部だけです。Component-Based Test Automation（CBTA）はSAPのユーザーインターフェースをカバーしますが、SAP以外のアプリケーションはカバーせず、画面が変わるたびに相当な保守が必要です。Solution Managerは、主にテスト管理とドキュメントのプラットフォームです。ほとんどのチームは、Tricentisなどの自動化ツールと組み合わせて使っています。メインストリームメンテナンスが2027年に終了するため、新規のプログラムは、代わりにCloud ALMで始めるべきです。

2026年のテストには、SAP Cloud ALMとSolution Managerのどちらを使うべきですか？

新規のプログラム、とりわけRISEとGROWでは、Cloud ALMです。テストをSAP Activateのフェーズと変更に結びつけられ、Enterprise Supportがあればライセンス料もかかりません。既存のオンプレミス環境ですでにSolution Managerがうまく動いているなら、システム環境が移行するまでそのまま使い続けてよいですが、移行は2028年より前に計画してください。

テスト管理ツールと自動化ツールの両方が必要ですか？

ほとんどの大企業のプログラムでは、必要です。テスト管理（Cloud ALMまたはSolution Manager）は、要件からテスト、変更までのトレーサビリティをもたらし、監査人はそれを必要とします。自動化（Tricentisなど）は、リグレッションサイクルを効率よく実行します。1つのツールで両方をうまくこなせることは、まれです。より単純な環境では、Cloud ALMと付属のTricentisの利用権から始め、リリースの量がそれに見合うようになったら、フルの自動化製品を加えてください。

クリーンコアで、SAPのテストはどう変わりますか？

テストの重心は、コア内部のカスタムコードから、その周囲の拡張へと移ります。パブリッククラウドでは、リグレッションの対象となるコアのカスタムコードはありません。プライベートクラウドとオンプレミスでは、残っているコアの修正を、SAPのリリースのたびに再テストする必要があります。SAP BTPの拡張には独自のリリースサイクルがあり、専用のリグレッションスイートが必要です。AIのステップには、非決定論的な出力を許容するテストパターンが必要です。