SAP 開発物の品質保証：Lint・静的解析・CI/CD の標準的な考え方

TL;DR

• 横断万能原則が先: SAP の品質保証は領域別ツール表から入るのではなく、Pull Request Review + Quality Gate の二重防御 を 1 枚で定義してから領域別の標準を埋める順序だと考えています。
• 3 領域の整理: 本記事は ABAP / Fiori / UI5 / CAP の 3 領域 (Fiori / UI5 を 1 領域とみなす) を横断対象とし、Linter / Unit Test / E2E / Pipeline の標準ツールを揃えて並べました。
• ATC と abaplint の二段構え: ATC はリリース時の品質ゲート、abaplint は日次 PR の早期フィードバックという役割分担が現実解です。
• Project Piper は SRE 化前提: Project Piper は強力ですが Jenkins 運用コストが負債化するため、CoE の SRE 化が前提条件 です。
• 品質ゲート閾値は初期値から固定: Coverage 70 % / 重大警告 0 件などの 初期閾値を最初から固定し、運用しながら緩めるのではなく厳しくしていく方が破綻しにくいです。

要点サマリ

観点	内容
何の話	SAP 開発物 (ABAP / Fiori / UI5 / CAP) の品質保証手法を横断整理した標準的な考え方
結論	横断万能原則 (PR Review + Quality Gate) を先に定義し、領域別ツール (ATC / abaplint / UI5 Linter / Cloud CI/CD) を当てはめる
影響範囲	ABAP 開発者 / Fiori / UI5 開発者 / CAP 開発者 / SAP CoE / SI エンジニア
私の評価	Sapphire 2026 後の Custom Agent 増加で品質基準の明文化は必須。先に書いた組織が事故を減らせる

背景・経緯

SAP の開発スタイルは Clean Core と Side-by-Side Extensibility の浸透で大きく変わりました。S/4HANA コアは標準のまま保ち、拡張は ABAP Cloud や BTP の CAP などコア外側に逃がす設計原則が主流になり、1 つのプロジェクトでも ABAP / Fiori / UI5 / CAP の複数領域 を並行開発するのが当たり前になっています。

複数領域を並行で動かすと、品質保証の現場では「ABAP は ATC、UI5 は ESLint、CAP は Jest をバラバラに回す」状態が起こりがちで、ツール選定の前に 横断する標準の考え方 が欲しいニーズが明確にあります。

2026 年 5 月の Sapphire 2026 以降は Joule Studio や Custom Agent で生成系の開発物が増える局面に入りました。自動生成物が増えるほど、静的解析と CI/CD の品質ゲートを通すワークフローの価値は相対的に上がると考えており、本記事は過去 5 記事の人材論で軽く触れた「技術スキルセット」軸を実装レベルに掘り下げる位置付けです。

本題の詳細

5.0 用語の定義

品質保証の議論は用語のブレが事故を生みやすい領域です。本記事で使う 12 用語を先に定義します。

5.1 品質保証の横断万能原則

3 領域に共通する万能原則は、Pull Request 単位の人的レビュー と CI Pipeline 上の自動 Quality Gate の二重防御です。SAP 公式の ABAP Code Review ガイドも、Git ベースのレビューと自動チェックを組み合わせる前提に立っています。

Change-based code reviews increase code quality by finding defects earlier and preventing them from polluting the main code line

(変更ベースのコードレビューは欠陥を早期に発見し、メイン系への汚染を防ぐことでコード品質を高めます)

実装イメージはソース変更を起点に Lint / 静的解析、単体テスト、ビルド、結合テスト、Quality Gate、Deploy、Transport の順に並ぶパイプラインで、SAP の DevOps Reference Architecture が示す Continuous Integration / Development / Delivery / Operations の 4 フェーズとも整合します。

flowchart LR
A[Code Push] --> B[Lint / Static Analysis]
B --> C[Unit Test]
C --> D[Build]
D --> E[Integration Test]
E --> F{Quality Gate}
F -->|Pass| G[Deploy to Test]
F -->|Fail| H[PR Blocked]
G --> I[Transport / Promote]
H --> A

ポイントは Quality Gate を二重に置く ことです。1 段目は PR レビュー時にマージ可否を、2 段目は Transport / Promote 時に本番昇格可否を判定します。BTP Reference Architecture も “Compliance checks in the CI pipeline ensure that only qualified changes are propagated to production.” (CI のコンプライアンスチェックで、適格な変更のみが本番に伝搬される) と述べており、最終 Gate は CI 内部に置く設計を推奨しています。

5.2 領域 1: ABAP の品質保証

ABAP の品質保証は ATC / abaplint / ABAP Unit / Pair Review の 4 点セットで構成するのが現実解です。

ATC (ABAP Test Cockpit) は SAP 標準のチェックフレームワークで、Code Inspector のチェック集合を内包し、CTS の CTS_REQUEST_CHECK BAdI を通じて リリース時の必須関門 として機能します。S/4HANA on-premise や BTP ABAP Environment の両方で利用可能で、Clean Core ルールセットをそのまま運用できる利点があります。一方 ABAP システムが必要 な制約があり、PR 時の早期フィードバックには重く感じる場面があります。

abaplint はその弱点を補う OSS の静的解析ツールです。README に “Linter for ABAP, code must be serialized using abapGit” とあり、abapGit でシリアライズされたファイルに対し SAP システム非依存 で動作します。GitHub Actions として即座に組み込め、TypeScript 実装で MIT ライセンスです。

コミュニティ abaplint (GitHub) - Standalone static analysis for ABAP

ABAP Unit は CDS の Test Double と組み合わせれば外部依存を切り離した検証ができ、これら自動チェックの上に Pair Review (公式表現 “asynchronous pair programming”) を載せて、設計意図・命名・業務理解のレイヤーを人間が押さえます。

実運用では どこで何をブロックするか の役割分担が肝になります。下表のような線引きが実務的です。

工程	主役ツール	失敗時の挙動
PR 時 (毎コミット)	abaplint	PR を Draft に戻す。マージ不可
マージ直後	ABAP Unit (CI 上)	ビルドを Fail。次工程へ進めない
開発系 → 検証系の Transport 直前	ATC	リリース不可。修正を要求
検証系 → 本番系の Transport 直前	ATC + 人的 Approval	リリース不可。承認者を明示

5.3 領域 2: Fiori / UI5 の品質保証

Fiori / UI5 の品質保証は UI5 Linter + ESLint + OPA5 + Karma / QUnit の 4 点で整理できます。

UI5 Linter は SAP が Apache-2.0 で公開する UI5 専用の静的解析ツールで、README に “A static code analysis tool for UI5” と明記されています。最大の特徴は deprecated API 検出 で、“all APIs and features that were deprecated with or before UI5 1.136” を機械的に洗い出します。UI5 2.x 移行時に削除済み API への参照が残っていると実行時に壊れますが、これを CI 上で事前に止められる価値が大きいです。

ESLint は JavaScript / TypeScript の汎用 Linter として一般コーディング規約 (命名 / 未使用変数 / Promise の扱い等) を担当します。UI5 Linter = UI5 固有の deprecated 検出、ESLint = 言語レベルの一般品質 という分業です。検証側は OPA5 (One Page Acceptance Tests) と QUnit がほぼ標準で、QUnit が単体、OPA5 が UI E2E、Karma がランナーという役割です。

CI 組み込みは、UI5 Linter が ui5lint() 関数や UI5LinterEngine クラスを公開し、Node.js API・終了コード・JSON / Markdown / HTML 出力をパイプラインに食わせられる構造です。GitHub Actions なら npm run lint 相当のステップ 1 つで Quality Gate になります。

特に強調したいのは Fiori / UI5 では deprecated API 検出が最重要観点 だという点です。UI5 はメジャーバージョン更新で破壊的変更が定期的に発生し、deprecated 警告を放置すると次の更新で動かなくなります。UI5 Linter を CI で必ず通せば見えにくい技術的負債を可視化できます。

5.4 領域 3: CAP の品質保証

CAP (Cloud Application Programming Model) は BTP クラウドネイティブ の開発モデルで、Node.js または Java のランタイム上で OData / REST API を CDS から生成します。品質保証は Web 開発のベストプラクティスに近く、SAP Continuous Integration and Delivery Service + Cloud Transport Management + Jest / Mocha + SonarQube が標準スタックです。

SAP Continuous Integration and Delivery Service は BTP 上の SaaS 型 CI/CD で、ABAP Environment / CAP / UI5 など事前定義済みシナリオを持ちます。Project Piper の基盤を活用しつつ Jenkins を自前運用しなくてよいのが利点です (Help ポータル本文取得は失敗したため、シナリオ詳細は BTP Reference Architecture の記述で補完しています。要検証)。

Cloud Transport Management (Cloud TMS) は CI/CD から生成された MTA アーカイブを開発 → テスト → 本番と段階的に運ぶ仕組みで、Project Piper の tmsUpload ステップから CI 直結で呼び出せます。

add transparency to the audit trail of changes

(変更の監査証跡に透明性を加える)

CAP の単体テストは Jest / Mocha が主流で、@sap/cds のインメモリ DB (cds.test) と組み合わせれば HANA 接続なしで回せます。SonarQube を加えるとカバレッジ / 重複検出 / セキュリティスキャンも Quality Gate に組み込めます。

開発体験面では SAP Business Application Studio (BAS) が CAP / UI5 / ABAP Cloud の統合 IDE として位置付けられ、Reference Architecture も “Teams use SAP Business Application Studio” と明記しています。BAS のターミナルで Linter / Unit Test を回しつつ CI で再実行する二段構えにすると、開発者体験と品質ゲートを両立しやすくなります。

なお CAP は Node.js / TypeScript ベースのため、ESLint が事実上の標準 Linter として広く用いられます。後段の図 2 でも CAP レイヤーに ESLint を配置しています。

5.5 横断比較とツール対応マトリクス

3 領域を 6 観点で並べて視覚化すると、領域ごとに「足りない部品」が一目で分かります。

表 1: SAP 3 領域 × 6 観点のツール対応マトリクス

観点	ABAP	Fiori / UI5	CAP
Linter	ATC + abaplint	UI5 Linter + ESLint	ESLint + SonarQube
Unit Test	ABAP Unit	QUnit	Jest / Mocha
E2E Test	eCATT / 手動	OPA5 + Karma	Jest + supertest
Pipeline 基盤	gCTS + SAP CI/CD Service	SAP CI/CD Service	SAP CI/CD Service
Quality Gate	ATC リリース関門	CI 上の lint exit code	SonarQube quality gate
Transport 連携	CTS / gCTS	Cloud TMS (Piper tmsUpload)	Cloud TMS (Piper tmsUpload)

もうひとつ視覚化が効くのは ツール群が CI Pipeline のどの段階に並ぶか の対応図です。3 領域それぞれの並びを並べると、ツールの重複と空白がはっきりします。

flowchart TB
subgraph ABAP
  A1[abaplint] --> A2[ABAP Unit] --> A3[ATC Gate] --> A4[CTS Transport]
end
subgraph FioriUI5["Fiori / UI5"]
  B1[UI5 Linter + ESLint] --> B2[QUnit] --> B3[OPA5] --> B4[Cloud TMS]
end
subgraph CAP
  C1[ESLint + SonarQube] --> C2[Jest / Mocha] --> C3[SonarQube Gate] --> C4[Cloud TMS]
end

このマトリクスを 1 枚作っておくと「ABAP しかやってこなかったチームに UI5 と CAP を増やすとき何を足すべきか」の会話が一気に進みます。抜けがある箱 (例: ABAP の E2E が手動だけ) は将来の自動化候補としてバックログに積めます。

比較・代替手法

CI/CD 基盤の選び方は大きく SAP 標準スタック / Project Piper (Jenkins) スタック / 完全 OSS スタック の 3 アプローチで、5 軸で並べると下表のとおりです。

表 2: CI/CD 基盤 3 アプローチ × 5 軸の比較

観点	SAP 標準 (CI/CD Service + Cloud TMS)	Project Piper (Jenkins ベース)	完全 OSS (GitHub Actions + abaplint / ESLint / Jest)
構築コスト	○ 低 (BTP で提供)	△ 中 (Jenkins 構築)	○ 低 (GitHub 標準)
学習コスト	△ 中 (BTP 概念)	× 高 (Jenkins + Piper)	○ 低 (Web 標準)
拡張性	△ 中 (定型シナリオ中心)	○ 高 (Stage 自由設計)	○ 高 (Workflow 自由設計)
SAP ECC / オンプレ連携	× 弱 (BTP 前提)	○ 強 (gCTS / RFC 経由)	× 弱 (連携は自作)
運用標準化	○ 高 (SAP 公式定型)	△ 中 (CoE で標準化要)	× 低 (各チーム自由)

実務の選定基準は、BTP 中心の Greenfield なら SAP 標準スタック、オンプレ ABAP 混在なら Project Piper、社内に Web 系 DevOps 文化があれば GitHub Actions ベースの OSS スタック、というのが私の感覚です。組み合わせる場合は「CAP は SAP CI/CD Service、ABAP は gCTS + Project Piper」のように 領域ごとに別基盤 を選ぶのも現実的です。

私の考察

ここまで整理して、私が現場で意識している判断軸を 3 つ書き残します。いずれもツール選定の前に決めておくと事故が減る観点です。

第 1 に 横断万能原則を 1 枚で定義してから領域別の標準を埋める ことです。最初に Pull Request Review + 自動 Quality Gate の二重防御 を絵にして合意し、その絵の中に ATC / abaplint / UI5 Linter / Jest / SonarQube を埋め込む順序にすると、ツール議論で迷子になりません。逆順 (ツールから入る) だと領域ごとに別の哲学が混入し、CoE の標準化負荷が膨らみます。

第 2 に ATC と abaplint は二段構えで併用する ことです。ATC は SAP 公式ルールセットを含む リリース時の防壁、abaplint は abapGit ベースで PR 単位に高速に回る 日次の早期フィードバック という役割分担です。どちらか一方に絞ると、システム依存の重さ (ATC) かルールセット不足 (abaplint 単独) のどちらかで困る局面が必ず来ると考えています。

第 3 に Project Piper の採用は CoE の SRE 化が前提 という点です。Jenkins 自体の運用 (バージョン管理 / プラグイン管理 / シークレット管理 / セキュリティ更新) は軽くなく、専任メンバーかそれに準ずるロールを置けないなら、SAP CI/CD Service のような SaaS 型を素直に選んだ方が長期で安く済むと感じます。

最後に Project Piper の採用判断をカードで残しておきます。

参考リンク

• SAP/styleguides ABAP Code Review
• Continuous Integration and Delivery (CI/CD) - SAP Help
• DevOps with SAP BTP (Reference Architecture)
• Project Piper - Integrate SAP Cloud Transport Management Into Your CI/CD Pipeline
• abaplint (GitHub)
• Running abaplint from SCI / ATC / ADT
• UI5/linter (GitHub)
• Introducing UI5 linter