SAP Clean Core（クリーンコア）とは：意味、レベルA〜D、ガバナンス

SAPのクリーンコアとは、S/4HANAシステムを、ビジネスが許す限りSAP標準に近い状態に保つことです。追加するものはすべて、SAPがリリースし安定性を約束したインターフェースを通じて構築するため、アップグレードで壊れることはありません。

端的に言えば、クリーンコアはSAPをどう拡張し、どう統制するかについての規律です。カスタムロジックはABAP Cloudでオンスタックに、またはSAP BTPでサイドバイサイドに置き、SAPはすべての拡張をレベルA（最もクリーン）からレベルD（除去すべきモディフィケーション）まで格付けします。見返りはアップグレードの迅速化です。私はこの方法でアップグレード期間を40%短縮した企業を見てきました。

SAP標準オブジェクトへのモディフィケーションだらけのシステムでは、リリースのたびに回帰テストのプロジェクトになります。カスタムロジックがリリース済みインターフェースの背後にあれば、アップグレードは定常的な保守作業になります。

クリーンコアの原則を適用して、アップグレード期間を40%短縮した企業を私は見てきました。カスタマイズを最小限に抑え、残したものをきちんと統制することで実現したのです。

2024年、ある欧州の消費財企業は、レガシーの価格設定ロジックを、SAP BTP上でコアの外に構築したモジュール型のFioriアプリに置き換えました。これにより、そのロジックの回帰テストが完全になくなりました。

クリーンコアのERPでも、カスタマイズは可能です。ただし、SAPがリリースし安定性を約束したインターフェースを使う必要があります。SAPはそのための方法を2つ用意しています。

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

SAPは自らのアプローチを「BTPファースト」と表現し、ユースケースごとに選ぶとしています。私の経験では、コードをどこで動かすかよりも、その要件にそもそもコードが必要かどうかのほうが重要です。

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

このテーマは、私のYouTubeチャンネルの動画（英語）でも解説しています。

SAPはクリーンコアを、指針となる5つの原則で整理しています。SAPがそれぞれをどう位置づけているか、そして私がまず何を見るかは次のとおりです。

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

多くのチームは拡張性から始め、拡張性で終わります。最も測定しやすいからです。私の経験では、遅延の原因になるのはむしろプロセスとデータです。カスタムコードはたいてい症状であり、原因はその背後にあるプロセスです。

2025年8月、SAPは従来の3階層の拡張性モデルを、クリーンコアレベルのコンセプトに置き換えました。各拡張は、どう構築されているか、コアからどれだけ切り離されているか、アップグレードをどれだけ安全に乗り切れるかで評価されます。階層（ティア）について書かれた古いSAPの資料を読んでいるなら、それに取って代わったのがこの仕組みです。

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

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

アップグレードリスクレベルA最も低い。安定性の契約で保証レベルB概ねアップグレード後も安定レベルCアップグレードごとに確認が必要レベルD最も高い

決めることレベルA新規開発の基本レベルB理由を記録したうえで許容レベルC理由を付けて許容し、アップグレードごとに再確認レベルD最初に除去するか、BまたはCへ移す

出典: SAPクリーンコアレベルのコンセプト、SAP News、2025年8月

レベルAは、安定性の契約を伴う公開リリース済みインターフェースだけを使い、SAP Build、ABAP Cloud、BTPで構築します。レベルBはSAPの従来型APIも使います。レベルCはSAP内部オブジェクトに触れるもので、SAPはアップグレード計画を支援するため、これらの変更履歴を提供する予定です。

レベルDは、モディフィケーション、SAPテーブルへの書き込み、暗黙的エンハンスメント、その他SAPが推奨しない手法です。これは従来の「クリーンかそうでないか」という議論より役に立ちます。オブジェクトごとに目標を設定できるからです。アップグレードの前にレベルDのオブジェクトをBやCに移すだけでも、リスクは実際に下がります。

ABAP Cloudは、SAPのクラウド対応ABAP開発モデルです。開発者は「ABAP for Cloud Development」という言語バージョンを使い、リリース済みオブジェクト、公開API、拡張ポイントの上でしか開発できません。SAP BTP ABAP環境から始まり、現在はすべてのS/4HANAエディションで利用できます（SAP ABAP Cloud FAQ）。

S/4HANA Cloudには3つの拡張ルートがあります。キーユーザー拡張性は、SAPのコードに触れずに、項目、ロジック、UIの簡単な変更をカバーします。ABAP Cloudによる開発者拡張性は密結合のロジックを扱い、SAP BTPでのサイドバイサイド拡張は、切り離しておくべきものすべてを扱います。

どれだけ選択肢があるかは、エディションで決まります。

	S/4HANA Cloud Public Edition	S/4HANA Cloud Private Editionとオンプレミス
ABAP開発	ABAP Cloudのみ。リリース2208以降、新規顧客には必須	2022年以降ABAP Cloudを推奨。従来型ABAPも引き続き使用可能
SAPコードの変更	不可	可能だが、レベルDになる
キーユーザー拡張とBTPのサイドバイサイド拡張	利用可能	利用可能
クリーンコアを強制するもの	システム	自社のガバナンス

Private Editionのお客様に対する私のルールは、新しく作るものについてはPublic Editionであるかのように扱うことです。従来型ABAPは許されていますが、今日追加する従来型オブジェクトはどれも、次のアップグレードで誰かが正当性を説明しなければならない判断になります。

クリーンコアの判断は、ビジネスとITで構成するデザインオーソリティが担うべきです。ITだけに任せれば、技術的に可能なものは何でも承認されます。ビジネスだけに任せれば、昔のプロセスを取り戻そうとします。

私なら次のように設計します。

1. メンバーを指名する。 主要領域ごとのビジネスプロセスオーナーに、ソリューションアーキテクトとリード開発者を加えます。要件が本物かどうかはビジネスオーナーが判断し、どう構築するかはITが判断します。
2. 構築を始める前に優先順位を合意する。 まず標準プロセス、次にキーユーザー拡張性、その次にABAP CloudまたはBTPでのレベルAです。レベルBやCには書面での理由が、レベルDには撤退計画が必要です。
3. すべての拡張依頼にオーナーとビジネス上の理由を付けさせる。 オーナーがいなければ構築しません。判断と、許容したレベルは、1つの台帳に記録します。
4. 移送の前に技術的なゲートを置く。 ABAPテストコックピットのクリーンコアチェックを定期的に実行し、新しいレベルDのコードが本番環境に届く前に止めます。
5. アップグレードの前には毎回台帳を見直す。 もう誰も使っていないものは廃止し、より上のレベルに移せるようになったものは移します。

その場で投げかける問いは、かつては「なぜこれをBTPに置けないのか」でした。今なら私は「なぜこれをレベルAにできないのか」と問います。できないなら、次の問いは、どのレベルをなぜ許容するのかです。

私が最もよく目にするクリーンコアの失敗は、SAPをOracleのように動かそうとすることです。他のシステムのロジックをカスタムコードで作り直すのではなく、SAPの標準プロセスを採用してください。まだ両者で迷っているなら、SAP vs Oracleで比較しています。

クリーンコアは、技術の問題である前にチェンジマネジメントの問題です。すべてのカスタムオブジェクトは、誰かが求めたから存在します。それを取り除くには、その人に標準プロセスで十分だと納得してもらう必要があります。

その対話は、新しいプロセスについてのスライドではなく、実際に動いているところをビジネスが目にすると、うまく進みます。プロセスが独自だという主張を検証した場合もうまく進みます。実際には独自でないことが多いからです（後述のステップ4と5を参照）。

ツールと同じくらいスキルも重要です。ABAP CloudやBTPの経験がないABAPチームは、学びながら進むことになり、プログラムを遅らせます。私が支援したある製造業の企業は、S/4HANAプロジェクトの開始前に3か月間の社内BTPプログラムを実施し、構築中の想定外が減るという形で成果を得ました。

クリーンコアへの準拠とは、5つの原則にわたって、システムのどれだけがSAPの基準を満たしているかを指します。数字がなければ管理できません。SAPはその数字を得る場所を3つ用意しています。

1. ABAPテストコックピット。 コードレベルのチェックを行うSAPのツールです。どのカスタムオブジェクトが、未リリースのオブジェクト、モディフィケーション、テーブルへの直接アクセスを使っているかがわかります。
2. SAP Readiness Check。 保守契約に含まれており、決断する前に、S/4HANAへの移行が何に影響するかを示します。
3. RISE with SAP Methodologyダッシュボード（クリーンコアダッシュボードとも呼ばれます）。 SAP Cloud ALM上で動きます。システムビューでは、S/4HANAのバージョンを確認し、データ収集ツールが有効であることを確かめ、アップグレードに先立って拡張をレビューします。オペレーションビューでは運用KPIを追跡します。

毎月デザインオーソリティに示すべき数字はシンプルです。各レベルにカスタムオブジェクトがいくつあり、レベルDは減っているか。未解決の例外はいくつあり、そのそれぞれにオーナーがいるか。

来月、御社のシステムを評価してほしいと頼まれたら、私は次の順序で進めます。

1. 何が使われているかを把握する。 SAP Readiness Checkを実行し、カスタムコードの使用状況データを収集します。あるプログラムでは、smartShiftによる分析で、18,000個のカスタムオブジェクトが3,200個まで絞り込まれました。残りの大半は単に使われていなかったからです。
2. 残ったものをレベルA〜Dに分類する。 コードにはABAPテストコックピットを使います。RISEを利用しているなら、その先はクリーンコアダッシュボードで追跡できます。
3. オブジェクトごとに判断する。 廃止するか、リリース済みインターフェースに移すか、BTPで作り直すか、理由を文書化したうえで残すかです。毎日動くコードから始めてください。1つの地域チームが年に2回使うだけのレポートは後回しで構いません。
4. ビジネスを同じ場に呼ぶ。 私が一緒に仕事をしたある財務責任者は、45分のウォークスルーを経て初めて、新しいFioriアプリを理解しました。そのセッションのおかげで、UATでの2週間分のやり取りが不要になりました。
5. 「うちのプロセスは違う」を疑う。 2023年に欧州の産業系企業の営業チームと行ったワークショップでは、「独自」とされていたプロセスの80%が、冗長なレガシーの事務作業だとわかりました。回避策がなくなると、標準のSAPで顧客体験が向上しました。
6. データ作業を早く始める。 2024年に私が支援したGCCの小売業のお客様には、整理すべきカスタム項目が15,000以上ありました。私の経験では、データ移行は導入工数の30〜40%を占めます。それが予算のどこに表れるかは、SAP導入コストガイドで示しています。
7. 本稼働の前にガバナンスを定める。 前述のデザインオーソリティを立ち上げ、新しい拡張を通す唯一のルートにします。

この話をすると、ほぼ毎回3つの質問が出ます。

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

一律のルールではありません。Public Editionではシステムが強制しますが、Private Editionとオンプレミスでは今でもコアを変更できます。

その場合のクリーンコアはガバナンス上の選択であり、SAPはRISE methodologyダッシュボードでそれを追跡します。SIから契約上の義務だと言われたら、その条項を見せるよう求めてください。

ECCはあとどれくらい使えますか？

エンハンスメントパッケージ6〜8のSAP ERP 6.0については、メインストリームメンテナンスが2027年12月31日に終了します。オプションの延長保守は、追加費用で2030年12月31日まで続きます。

その後は、SAP ERP, private edition, transition optionが2031年から2033年をカバーします。対象は、2030年末までにSAP HANA上のSAP ERP, private editionへ移行済みの大規模システムに限られます。

2033年は計画上の期日ではなく、例外的なルートとして扱ってください。ルートの選び方は、私のECCからS/4HANAへの移行ガイドで解説しています。

クリーンコアはAIに関係しますか？

はい。SAP標準を保つことでAIやJouleは機能しやすくなり、大きく修正されたプロセスほど導入が難しくなります。

SAPは、Jouleを含むAI機能を、自社の標準プロセスとデータモデルの上に構築しています。Joule for developersは、リリース済みAPIに沿ってABAP Cloudのコードを生成します。クラウド、AI、クリーンコアがどう組み合わさるかは、ERPモダナイゼーションで解説しています。

クリーンコアを省くチームは、作業を避けているわけではありません。先送りしているだけで、それはブロックされたアップグレード、延々と続く回帰テスト、誰も理解していないカスタムコードとして戻ってきます。

S/4HANAやRISEの契約に署名する前に、現在のカスタムコードをレベルA〜Dに分類するようSIに依頼してください。それを出せないなら、その見積もりについて何かがわかるはずです。ご相談の予約をいただければ、御社の状況を一緒に見ていきます。

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ではABAP Cloudとリリース済みインターフェースしか使えないため、技術的にクリーンコアが強制されます。Private Editionでは今でもコアを変更できるため、クリーンコアはガバナンス上の判断であり、SAPはRISE with SAP Methodologyダッシュボードでそれを追跡します。

ABAP Cloudとは何ですか？

ABAP Cloudは、SAPのクラウド対応ABAP開発モデルです。リリース済みオブジェクト、公開API、拡張ポイントしか使えないため、カスタムコードがアップグレード後も安定します。S/4HANA Cloud Public Editionではリリース2208以降の新規顧客に必須であり、Private Editionとオンプレミスでは2022年から推奨されています。

クリーンコアはどう測定しますか？

コードレベルのチェックにはABAPテストコックピットを使い、カスタムオブジェクトをレベルA〜Dに分類します。RISEのお客様は、SAP Cloud ALMのRISE with SAP Methodologyダッシュボード（クリーンコアダッシュボードとも呼ばれます）で取り組みの状況を追跡できます。私は、各レベルのオブジェクト数、レベルDの推移、オーナーの付いた未解決の例外の数を追跡しています。

SAPクリーンコアのガバナンスは誰が担うべきですか？

クリーンコアに関するすべての判断は、ビジネスとITで構成するデザインオーソリティが担うべきです。要件が本物かどうかはビジネスプロセスオーナーが判断し、どう構築し、どのレベルにするかはITが判断します。例外はすべてオーナーとともに記録し、アップグレードの前に毎回見直します。

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

エンハンスメントパッケージ6〜8のSAP ERP 6.0については、メインストリームメンテナンスが2027年12月31日に終了し、オプションの延長保守は追加費用で2030年12月31日まで受けられます。SAP ERP, private edition, transition optionは2033年まで続きますが、対象は2030年末までにSAP HANA上のSAP ERP, private editionへ移行した、要件を満たす大規模システムに限られます。