SAPクリーンコア戦略：その意味と、実践の方法

クリーンコアが、S/4HANAのアップグレードを6週間で終わらせるか、6か月かけるかを決めます。システムがSAP標準オブジェクトへのモディフィケーションだらけなら、リリースのたびにリグレッションテストのプロジェクトになります。カスタムロジックが公開済みのインターフェースの背後にあれば、アップグレードは日常的なメンテナンスになります。

S/4HANAプログラムが始まる前にクリーンコアの原則を適用して、アップグレードの期間を40%短縮した企業を見てきました。ある消費財メーカーは、レガシーの価格設定ロジックを、コアの外に作ったモジュール型のFioriアプリに置き換え、アップグレードでそのロジックが壊れなくなりました。

2025年4月にこの記事を最初に書いてから、多くのことが変わりました。SAPは現在、クリーンコアを5つの指針となる原則で説明し、2025年8月以降は、すべての拡張を4つのレベルのいずれかに分類しています。ECCの期限も、より明確になりました。この版は、その変更を反映しています。

クリーンコアとは、S/4HANAシステムを、事業が許す範囲でSAP標準にできるだけ近い状態に保ち、追加するものはすべて、アップグレードに耐える形で作ることです。

カスタマイズは引き続き可能です。ただし、SAPが公開し、安定を約束しているインターフェースを使う必要があります。そのための方法は、SAPが2つ用意しています。

• オンスタック、ABAP Cloudを使う。 拡張はS/4HANAの内部で動きますが、使うのは公開済みのAPIと拡張ポイントだけです。
• サイドバイサイド、SAP BTP上。 拡張は別のアプリケーションとして動き、APIやイベントを通じてS/4HANAとやり取りします。

SAP自身のガイダンスは、ユースケースごとに選び、まずBTPを検討するというものです。私の経験では、コードがどこで動くかよりも、その要件にそもそもコードが必要かどうかのほうが重要です。

汚れたコアは、ECCを運用したことのある人なら見覚えがあるはずです。修正された標準プログラム、直接書き込まれるZテーブル、SAPの内部を読みに行くインターフェース、誰も文書化していない暗黙のエンハンスメント。作られた当時は、どれも間違いではありませんでした。ただ、1〜2年ごとにアップグレードされるシステムのために作られていなかっただけです。

SAPは、クリーンコアを5つの指針となる原則で整理しています。この記事の以前の版は、別の見出しを挙げていました。以下がSAPの使っているもので、それぞれについて私が最初に見る点を添えています。

原則	SAPの意味するところ	私が最初に確認すること
プロセス	SAP標準のプロセスに、できる限り近づける	「昔からこうしてきたから」という理由だけで存在するプロセスのバリエーションはどれか
拡張性	公開済みのAPIを通じてコアから切り離された拡張。どの選択肢を使うかはガバナンスで管理する	カスタムコードがどれだけあり、どれだけ使われ、どのレベルにあるか
データ	クリーンでコンプライアンスに沿ったデータと、確立されたガバナンスモデル	重複や不完全なマスタデータ、誰も説明できないカスタム項目
連携	サポートされた技術の上に構築された、標準化された安全な接続	テーブルを直接読むポイントツーポイントのインターフェース
運用	他の4つを維持するガバナンス、人、プロセス、ツール	誰が拡張を承認するのか、次のモディフィケーションを何が止めるのか

多くのチームは、最も測りやすいという理由で、拡張性から始めて拡張性で終わります。私の経験では、遅れをより多く生むのは、プロセスとデータです。カスタムコードは、たいてい症状にすぎません。その背後にあるプロセスが原因です。

2025年8月、SAPは従来の3層の拡張性モデルを、クリーンコアのレベルの概念に置き換えました。各拡張は、どのように作られているか、コアからどれだけ切り離されているか、どれだけ簡単にアップグレードできるかによって評価されます。

レベル	SAPによる説明	アップグレードにとっての意味
A	SAP Buildで拡張する。公開済みの安定したインターフェースのみを使い、ABAP Cloudでオンスタック、またはBTPでサイドバイサイド	リスクは最も低い。SAPが、これらのインターフェースを安定性の契約で支えている
B	SAPのクラシックなAPIと技術も使う	一般にアップグレードに対して安定しているが、クラウド開発モデルの外にある
C	SAPの内部オブジェクトにアクセスする	部分的に準拠。アップグレードのたびに確認が必要。SAPは内部オブジェクトの変更履歴（チェンジログ）を計画している
D	非推奨：モディフィケーション、SAPテーブルへの書き込み、暗黙のエンハンスメント、明示的に非推奨とされたオブジェクト	最初に取り除くべき技術的負債

これは、かつての「クリーンか、そうでないか」という議論より役に立ちます。オブジェクトごとに目標を設定できるからです。すべてをレベルAにする必要はありません。アップグレードの前にレベルDのオブジェクトをBかCに移すだけでも、リスクは確実に下がります。

レベルAレベルBレベルCレベルD

使うものレベルA公開済みの安定したインターフェースのみレベルBSAPのクラシックなAPIもレベルCSAPの内部オブジェクトレベルDモディフィケーション、SAPテーブルへの書き込み、暗黙のエンハンスメント

アップグレードのリスクレベルA最も低い。安定性の契約で支えられているレベルB一般にアップグレードに対して安定しているレベルCアップグレードのたびに確認が必要レベルD最も高い

何を判断するかレベルA新規のものすべてのデフォルトレベルB理由を記録したうえで受け入れるレベルC理由をつけて受け入れ、アップグレードのたびに再確認するレベルD最初に取り除く。またはBかCへ移す

出典: SAPのクリーンコアのレベルの概念、SAP News、2025年八月

来月、御社のシステムの評価を頼まれたとしたら、私が踏む順序は次のとおりです。

1. 何が使われているかを把握する。 メンテナンス契約に含まれるSAP Readiness Checkを実行し、カスタムコードの利用データを集めます。あるプログラムでは、smartShiftによる分析で、18,000あったカスタムオブジェクトが3,200になりました。残りの大半は、単に使われていなかっただけです。
2. 残ったものをレベルAからDに分類する。 ABAP test cockpitは、コードレベルのチェックのためのSAPのツールです。RISEでは、RISE with SAP Methodologyダッシュボードが、クリーンコアの採用状況を報告します。
3. オブジェクトごとに判断する。 廃止する、公開済みのインターフェースに移す、BTPで作り直す、あるいは理由を文書化したうえで残す。毎日動いているコードから始めます。ひとつの地域チームが年に2回使うレポートは、後回しで構いません。
4. 業務部門を同席させる。 一緒に仕事をした財務リードは、45分のウォークスルーを受けて初めて、新しいFioriアプリを理解しました。そのセッションが、UATでの2週間分のやり取りを省いてくれました。
5. 「うちのプロセスは違う」に異議を唱える。 ある営業チームのワークショップでは、「独自」とされたプロセスの80%が、レガシー由来の無駄な事務作業だと判明しました。回避策がなくなると、標準のSAPのほうが顧客体験を良くしました。
6. データの作業を早く始める。 ある小売のクライアントは、整理すべきカスタム項目が15,000を超えていました。私の経験では、データ移行は導入工数の30〜40%を占め、ほとんどの計画が最も過小に見積もる部分です。その理由は、SAPのデータ移行が失敗する理由で書いています。
7. 本稼働の前にガバナンスを整える。 デザインオーソリティが、新しい拡張をすべてレビューするべきです。かつての基本の問いは、「これをBTPに置けないのはなぜか」でした。今なら、「これをレベルAにできないのはなぜか。できないなら、どのレベルを受け入れるのか、その理由は何か」と問います。

ツールと同じくらい、スキルも重要です。ABAP CloudやBTPを使ったことのないABAPチームは、学んでいる間、プログラムを遅らせます。私が仕事をしたあるメーカーは、S/4HANAプロジェクトが始まる前に、3か月の社内BTPプログラムを実施しました。それは、構築中の予想外の事態が減るという形で報われました。

このテーマで私が交わすほぼすべての会話で、3つの質問が出てきます。

RISE with SAPでは、クリーンコアは必須ですか？ 一律のルールとしては、そうではありません。S/4HANA Cloud Public Editionでは、公開済みのインターフェースを通じてしか拡張できないため、システムがそれを強制します。Private Editionとオンプレミスでは、コアを変更することが今でも可能です。そこでのクリーンコアは、ガバナンス上の選択であり、SAPはRISEのMethodologyダッシュボードを通じて追跡しています。SIが契約上の義務だと言うなら、その条項を見せてもらってください。

ECCには、あとどれくらいの猶予がありますか？ エンハンスメントパッケージ6〜8のSAP ERP 6.0では、メインストリームメンテナンスは2027年12月31日に終了します。オプションの延長メンテナンスは、追加費用で2030年12月31日まで続き、SAPは顧客に2027年第3四半期までの発注を求めています。それより前のエンハンスメントパッケージは、メインストリームメンテナンスが2025年末で終わりました。2030年以降は、SAP ERP, private edition, transition optionが2031年から2033年までをカバーします。対象となるのは、2030年末までにSAP HANA上のSAP ERP, private editionに移行済みの大規模なシステムに限られ、SAPのmax success planを契約している場合に限ります。2033年は、例外的なルートであって、計画の基準日として扱わないでください。ルートの選択肢は、私のECCからS/4HANAへの移行ガイドで解説しています。

クリーンコアは、AIにとって重要ですか？ SAPは、Jouleを含むAI機能を、標準のプロセスとデータモデルの上に構築しています。Joule for developersは、公開済みのAPIに対してABAP Cloudのコードを生成します。私の考えはシンプルです。プロセスとデータが標準に近いほど、それらの機能が役に立つようになるまでに必要な調整は少なくなります。大幅にモディフィケーションされたプロセスは、AI機能の導入が最も難しい領域です。

クリーンコアを飛ばしたチームも、作業を避けられるわけではありません。先送りにしているだけで、その作業は、止まったアップグレード、リグレッションテストの長丁場、誰も理解できないカスタムコードとなって戻ってきます。

S/4HANAまたはRISEの契約にこれから署名するなら、スコープに合意する前に、現在のカスタムコードをレベルAからDに分類したものをSIに求めてください。それが出せないなら、その見積もりについて何かがわかります。移行の選択肢は、私のECCからS/4HANAへの移行アセスメントで試せます。あるいは、通話を予約していただければ、一緒に状況を見ることができます。

SAPクリーンコアとは何ですか？

クリーンコアとは、S/4HANAをSAP標準に近い状態に保ち、SAPが公開し、安定を維持すると約束したインターフェースだけを通じて拡張を構築することです。拡張は、ABAP Cloudを使ったオンスタック、またはSAP BTP上のサイドバイサイドのいずれかで動きます。目的は、アップグレードでカスタムロジックが壊れないようにすることです。

SAPクリーンコアの5つの側面とは何ですか？

SAPは、これをクリーンコアの5つの指針となる原則と呼んでいます。プロセス、拡張性、データ、連携、運用です。プロセスは標準に近い状態を保ちます。拡張は公開済みのAPIを使います。データは、ガバナンスモデルのもとでクリーンに保たれます。連携は、標準化された、サポートされる技術を使います。運用は、他の4つを維持するためのガバナンス、人、ツールを指します。

SAPクリーンコアのレベルA、B、C、Dとは何ですか？

2025年8月以降、SAPは拡張を4つのレベルに分類しています。レベルAは、公開されている安定したインターフェースだけを使います。レベルBは、SAPのクラシックなAPIも使います。レベルCは、SAPの内部オブジェクトにアクセスし、アップグレードのたびに確認が必要です。レベルDは、モディフィケーション、SAPテーブルへの書き込み、暗黙のエンハンスメントなどの非推奨の手法を指し、最もリスクが高くなります。

RISE with SAPでは、クリーンコアは必須ですか？

一律のルールとしては、そうではありません。S/4HANA Cloud Public Editionは、公開済みのインターフェースを通じた拡張しか認めないため、クリーンコアを技術的に強制します。Private Editionでは、コアを変更することが今でも可能なので、クリーンコアはガバナンス上の判断になります。SAPは、RISE with SAP Methodologyダッシュボードを通じて、クリーンコアの採用状況を報告します。

SAP ECCのサポートはいつ終了しますか？

エンハンスメントパッケージ6〜8のSAP ERP 6.0では、メインストリームメンテナンスは2027年12月31日に終了します。追加費用で、オプションの延長メンテナンスを2030年12月31日まで利用できます。それより前のエンハンスメントパッケージは、メインストリームメンテナンスが2025年末で終わりました。SAP ERP, private edition, transition optionが2033年まで延びるのは、2030年末までにSAP HANA上のSAP ERP, private editionへ移行済みの、対象となる大規模なシステムに限られます。

自社のSAPシステムのクリーンコアへの準備状況は、どう評価すればよいですか？

SAP Readiness Checkと、カスタムコードの利用データから始めます。今も使われているものを、コードレベルのチェックにABAP test cockpitを使って、レベルAからDに分類します。そのうえで、オブジェクトごとに、廃止する、公開済みのインターフェースに移す、SAP BTPで作り直す、あるいは理由を文書化して残すかを判断します。プロセスとデータも同時に見直してください。そのコードがなぜ存在するのかを、たいていはそれらが説明してくれるからです。

クリーンコア戦略で、SAP BTPはどんな役割を果たしますか？

SAP BTPは、サイドバイサイドの拡張が動く場所です。BTP上のアプリケーションは、APIとイベントを通じてS/4HANAに接続するため、コアには手が加わりません。SAPは、BTPを優先するアプローチを推奨しています。ロジックがデータやトランザクションの近くになければならない場合には、オンスタックのABAP Cloud拡張を使います。