クリーンコア戦略：S/4HANAにおける意味とBTPが実現する方法

JinJin48

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

May 7, 2026 · 20 min read

はじめに#

10人のSAPコンサルタントに「Clean Core」の意味を尋ねると、おそらく10通りの異なる答えが返ってくるでしょう。ある者はそれを制約——カスタムABAPを書くのをやめるよう求める命令——と表現します。また別の者は、SAPがBTPサービスを販売するためのマーケティング上のラッパーと見なします。どちらの見解も正確ではありません。

Clean Coreは、明確な定義、5つの次元から成る構造化フレームワーク、そしてそれを実現する具体的なツールを備えたアーキテクチャ原則です（ SAPヘルプポータル — BTPガイダンスフレームワーク）。SAPコンサルタントやエンタープライズアーキテクトにとって、これを理解することはもはや選択肢ではありません。すべてのS/4HANA導入判断、すべての統合設計、そして顧客とのあらゆる拡張性に関する対話において、戦略的基盤となるものです。

この記事では、クリーンコアが実際に何を意味するのか、なぜ存在するのか、その5つの側面が日々の意思決定にどのように反映されるのか、そしてSAP BTPがコンプライアンスを単なる理想ではなく達成可能なものにする上で果たす役割について解説します。

1) 対象読者#

2) レガシーの問題：ECCがいかにしてアップグレードのロックを生み出したか#

クリーンコアが重要である理由を理解するには、それが解決する問題を理解することが役立ちます。

SAP ECC（ERP Central Component）は、オンプレミスソフトウェアが大幅にカスタマイズされることが想定されていた時代に設計されました。長年にわたる運用の結果、ほとんどの大規模なECC導入環境では、以下のものが蓄積されました。

• Z または Y で始まる数千のカスタムプログラムが、SAP のリポジトリに直接存在
• SAP の修正コンセプト（CMOD、SMOD、またはオブジェクトの直接変更）を介した SAP 提供オブジェクトへの直接変更。SAP アップグレードのたびに調整が必要
• SAP 標準から大幅に逸脱したカスタムビジネスプロセス。SAP 自身の革新が及ばないプロセスバリアントに固定化
• RFC および BAPI を介したポイントツーポイント統合。バージョン管理や API ガバナンスなし

その結果、業界が「アップグレードロック」と呼ぶ現象が生じました。SAPが新しいECCサポートパッケージや新しいEHP（エンハンスメントパッケージ）を提供するたびに、カスタマイズが多岐にわたる顧客は、アップグレードにかかるコストが法外なものとなりました。テストだけでも数か月を要することがありました。カスタムコードは、SAPの新しいコードベースと手動で整合させる必要がありました。リグレッション（後退）のリスクは高かったのです。

SAPinsider によると、このパターンにより、多くの組織が SAP 自身が公表したサポート期限を過ぎても 5 年から 10 年にわたって ECC バージョンに留まり続けました（ SAPinsider,「クリーンコアとは」）。現在、SAP による ECC のメインストリーム保守期間が狭まる中、修正負債を理由に S/4HANA 移行を先延ばしにしてきた組織は、無期限に延期できない戦略的緊急性に直面しています。

Clean Coreは、S/4HANAのお客様がECCの過ちを繰り返さないためのSAPのアーキテクチャ上の答えです。この原則は、S/4HANA Cloud（パブリックエディション）の構築方法に組み込まれており、パブリッククラウドではSAPコードの直接変更は技術的に不可能です。プライベートクラウドおよびオンプレミス環境では、Clean Coreは技術的な強制ではなく、戦略的な規律として位置づけられています。

3) クリーンコアの意味：公式定義と5つの側面#

SAPの公式定義は、 SAP BTP Guidance Frameworkに文書化されている通り、クリーンコアS/4HANA環境を次のように定義しています：

「最新、未変更、一貫性、効率的、そしてカスタム拡張がSAPソースコードから分離されていること。」

その定義のすべての単語に意味があります。「最新（Up-to-date）」とは、システムが最新のSAPリリースで動作していることを意味します。「未変更（Unmodified）」とは、SAPが提供するコードが直接変更されていないことを意味します。「疎結合（Decoupled）」とは、カスタム拡張機能がSAPの内部実装の詳細に依存しないことを意味します。

SAPは、クリーンコアのコンプライアンスを5つの側面にわたって整理しています（ SAP BTP Guidance Framework）。

拡張性#

カスタムコードは、SAPが承認した安定した拡張ポイントのみを使用しなければなりません。SAPオブジェクトの変更や内部APIの呼び出しは禁止です。オンスタック拡張では、ABAP Cloud開発モデル（リリース済みのC1/C2 APIのみ、ABAP Test Cockpitで強制）を使用します。サイドバイサイド拡張はBTP上で動作し、リリース済みのODataまたはREST APIを通じてS/4HANAと通信します。

プロセス#

ビジネスプロセスは、可能な限りSAP標準プロセスに準拠する必要があります。組織は、逸脱を明示的に特定し、管理すべきであり、将来のプロジェクトチームから見えなくなるカスタムコードにプロセスのバリエーションを黙って埋め込むべきではありません。

データ#

データ品質、データガバナンス、移行精度は中核的な責務です。データ面におけるクリーンコアとは、マスタデータとトランザクションデータが正確でアクセス可能であり、レガシーカスタムコードのみが理解するカスタムテーブルに埋もれていない、ガバナンスされたデータアーキテクチャを維持することを意味します。

統合#

統合には、SAPが公開しているAPI（ODataサービス、ビジネスイベント、SAP Integration Suiteの事前構築済みパッケージ）を使用する必要があります。直接的なRFC/BAPI接続は、SAPがアップグレード間での保存を保証しない内部SAPファンクションモジュールの実装に依存するため、段階的に置き換えるべきです。

操作#

システム管理、トランスポート管理、アプリケーションライフサイクル管理（ALM）、およびモニタリングは、SAP標準のツールとプラクティスに従うべきです。S/4HANAシステムを非標準的な方法で運用することは、カスタムABAPが開発において技術的負債を生み出すのと同様に、運用においても目に見えない技術的負債を確実に生み出します。

4) 3つの拡張モデル — 適切なレーンを選ぶ#

クリーンコアはカスタマイズを禁止するものではありません。承認されたパターンを通じてカスタマイズを行うことを意味します。SAPは3つの階層を定義しています（ SAP S/4HANA Cloud 拡張性ドキュメント）：

キーユーザー拡張性（設定 — コード不要）#

ビジネスユーザーや機能コンサルタントは、コードを記述することなく、設定ツールを通じてS/4HANAを拡張できます。これには、カスタム項目、カスタム業務オブジェクト、Business Rules Framework plus（BRF+）によるカスタムロジック、およびSAP Fiori UIアダプテーションツールによるUI適応が含まれます。これらの拡張は、設計上アップグレードセーフです。SAPは、それらがリリースをまたいでも維持されることを保証しています。

この層はしばしば十分に活用されていません。多くのプロジェクトでは、キーユーザーツールで適切に対処できる要件に対して、ABAPソリューションに頼ってしまっています。

開発者拡張性 — ABAP Cloud（オンスタック）#

ビジネス要件が設定だけでは満たせない場合、ABAP Cloud開発モデルにより、開発者はコアシステム内に留まりながらアップグレードセーフなカスタムABAPを作成できます。

重要な制約：SAPがリリースしたAPI（リリース状態C1（顧客向け）またはC2（パートナー向け）とマークされたもの）のみを呼び出すことができます。SAPのABAPテストコックピット（ATC）は開発中にこれを強制し、リリースされていないAPIの呼び出しをコンプライアンス違反としてフラグ付けします。ATCチェックに合格したコードは、SAPのアップグレード後も正しくコンパイルされ、動作することが保証されます。SAPはリリースされたAPIに対して互換性の責任を負います。

SAPinsider が文書化しているように、このオンスタックモデルは「ABAP Cloud 開発モデルを使用して SAP システム上で直接カスタム ABAP コード開発を行う」ものです（ SAPinsider、Clean Core の定義）。

サイドバイサイド拡張性（BTP）#

最も柔軟な拡張モデルでは、すべてのカスタムロジックをS/4HANAシステムの外部に完全に配置します。アプリケーションはSAP BTP上に構築され、SAP Build Apps、SAP Build Process Automation、またはCloud FoundryやKyma上のカスタムアプリを使用し、公開されたAPIを通じてS/4HANAに接続します。

SAPinsiderが指摘するように、BTPは「SAPによって、中核システム外でアプリケーションを構築、統合、拡張するための基盤として位置づけられています」（ SAPinsider、Layer Seven Securityの記事）。サイドバイサイド拡張はSAPの内部コードとの結合がゼロであり、S/4HANAのリリースサイクルとは独立して進化できます。その代償として、オンスタック開発と比較して統合のオーバーヘッドが大きくなります。

5) BTPをクリーンコア実現プラットフォームとして#

5つのClean Coreの各ディメンションには、対応するSAP BTPサービスがあります。このマッピングを理解することは、Clean Core準拠のランドスケープを設計するアーキテクトにとって不可欠です。

拡張性の次元 → SAP Build Suite#

SAP Build Appsは、S/4HANA Fioriの設定に触れることなく、UIアプリケーションやモバイルアプリを構築するためのローコード/ノーコード環境を提供します。SAP Build Process Automationは、ワークフロー拡張とロボティックプロセス自動化をカバーします。SAP Build Work Zoneは、標準のSAP FioriアプリとカスタムBTPアプリを単一の管理された起動パッドに集約します（ SAPinsider、Layer Seven Securityの記事）。

ABAP開発者にとって、SAP BTP ABAP環境（Steampunkとも呼ばれる）は、BTP上で管理されたABAPランタイムを提供し、ATCチェックを含む完全なABAP Cloud開発モデルを使用して、S/4HANA自体で実行することなくABAPベースのサイドバイサイド拡張を開発できます。

統合ディメンション → SAP Integration Suite#

SAP Integration Suiteは、直接的なRFC/BAPI接続を、ガバナンスが効きバージョン管理された統合に置き換えるための中央ハブです。このスイートは、一般的なSAP間およびSAPとサードパーティ間のシナリオ向けに事前構築された統合パッケージを提供し、Clean Core準拠の統合を構築するために必要な時間を短縮します。Integration Suite内のAPI管理は、ライフサイクル管理、レート制限、およびS/4HANA ODataサービスを外部に公開するためのデベロッパーポータルを追加します。

イベント駆動型のシナリオにおいて、SAP Advanced Event Meshは管理されたメッセージングレイヤーを提供します。データ変更をポーリングするカスタムABAPプログラムの代わりに、Clean Core準拠の設計ではS/4HANAビジネスイベントをEvent Meshに公開し、コンシューマーアプリケーションが非同期に反応できるようにします。これにより、プロデューサーとコンシューマー間の結合はゼロになります。

実践的な例として、SAPinsiderの請求書ワークフローに関するホワイトペーパー（ SAPinsider, 2026年2月）では、財務チームがSAP BTPと「標準化されたワークフローとインテリジェント自動化により、コンプライアンスと拡張性を確保」しながら請求書処理を自動化し、これまでアップグレードのたびに手動メンテナンスが必要だったカスタムABAPを置き換える方法が示されています。

データディメンション → SAP Datasphere および SAP Analytics Cloud#

SAP Datasphereは、SAPおよび非SAPのデータを、脆弱なカスタムレポート基盤に抽出することなく、統合、モデル化、アクセスできるガバナンスされたデータファブリック層を提供します。SAP Analytics Cloudは、このガバナンスされたデータを分析および計画に活用します。

データの次元は、特に戦略的に重要性を増しています。2026年5月時点で、SAPはDremioの買収を発表し、エージェンティックAIのユースケースに向けてSAPデータと非SAPデータをさらに統合することを目指しています（ SAP News, 2026年5月）。SAPのAIアシスタントであるJouleや、将来のエージェンティックAI機能は、クリーンでガバナンスの効いたデータに依存しています。断片的でカスタムコード化されたデータアーキテクチャを持つ組織は、AI導入において障壁に直面することになります。

運用とプロセスの次元 → SAP Cloud ALM および SAP Signavio#

SAP Cloud ALMは、S/4HANA Cloudの導入を含むSAPクラウドソリューション向けに、一元化されたアプリケーションライフサイクル管理を提供します。プロジェクト管理、実装アクティビティ、トランスポート管理、およびモニタリングを、単一のガバナンスツールでカバーします。

SAP Signavio Process Intelligenceは、S/4HANAから実際のプロセス実行データを分析し、SAP標準プロセスからの逸脱を特定します。これにより、組織は現在のプロセスとSAPベストプラクティスとのギャップを定量化できます。これは、どのプロセス逸脱がカスタム拡張を正当化し、どの逸脱を単に除去すべきかを判断する前に不可欠なインプットとなります。

6) クリーンコアの実践：RISE with SAP#

RISE with SAPは、S/4HANA Cloud Private Edition向けのSAPのマネージドクラウドサブスクリプションモデルです。これはクリーンコア準拠への最も体系化された道筋であり、この課題に直接対応するいくつかのツールが含まれています（ SAPヘルプポータル — BTPガイダンスフレームワーク）。

• SAP Business Transformation Center: 現在のランドスケープの評価、移行計画、およびクリーンコア準拠の進捗状況を追跡するためのサービスポートフォリオ
• SAP Signavio エンタイトルメント: RISE サブスクリプションに初年度含まれるプロセス分析
• カスタムコード移行アプリ: 未使用のカスタムコードを特定し、移行前に非ABAP Cloud準拠の呼び出しをフラグ付けするためのSAP標準ツールセットの一部
• BTP クレジット: RISE with SAPにはBTPクレジットが含まれており、顧客がオンスタックでサイドバイサイド拡張を構築するのではなく、BTPに移行するよう促進する

RISE with SAPは技術的に修正を妨げるものではありません（Public Cloudは妨げます）が、エンゲージメントモデルはクリーンコアへの強いインセンティブを生み出します。SAPがアップグレードを管理し、大幅に修正されたシステムはSAPの運用チームにとって摩擦を生み出します。実際には、RISE契約にはクリーンコアへの準拠が暗黙のうちに期待されています。

7) クリーンコアへの道：実践的なスタートロードマップ#

既存のECCカスタマイズ資産を持つ組織にとって、Clean Coreは単にスイッチを切り替えるようなものではなく、移行の旅路です。実践的な開始アプローチには4つのステップが含まれます（ SAP S/4HANA Cloud 拡張性ドキュメント）：

カスタムコード資産の評価#

SAP Custom Code Migration アプリを既存のECC環境に対して実行します。出力結果により、カスタムオブジェクトのボリューム、アクティブに使用されているオブジェクト、およびABAP Cloudに準拠していないAPI呼び出しが特定されます。この評価により、通常、本番環境で実行されていないカスタムコードのかなりの部分が明らかになります。これは移行前の意味のある早期クリーンアップの機会となります。

カスタムシナリオを拡張モデルにマッピングする#

各主要なカスタムシナリオについて、適切な拡張ティア（キーユーザ設定、オンスタックABAP Cloud、またはBTP上のサイドバイサイド）を判断します。この判断は、開発者のオンスタックABAPへの習熟度ではなく、機能要件に基づいて行う必要があります。

統合をSAP APIに合わせる#

既存のRFC/BAPI統合を棚卸し、それぞれを利用可能なODataまたはREST APIの代替にマッピングします。SAPのAPI Business Hubには、リリース済みのすべてのS/4HANA APIが文書化されています。ギャップが存在する場合、Integration Suiteのプリビルドパッケージは、以前はカスタムRFCラッパーを必要としていた一般的なシナリオをカバーすることがよくあります。

プロセス逸脱のガバナンス#

SAP Signavioを使用して、現在のプロセスにおけるSAP標準からの逸脱を文書化します。各逸脱について、明示的な決定を行います。逸脱を受け入れ、サポート対象の拡張を構築するか、SAP標準プロセスを採用して逸脱を排除します。文書化自体は、決定内容に関わらず、クリーンコア準拠の成果となります。

概要#

クリーンコアとは、SAP S/4HANAをアップグレードの俊敏性を維持し、継続的なイノベーションを可能にする方法で運用するためのアーキテクチャ原則です。その5つの側面（拡張性、プロセス、データ、統合、運用）にはそれぞれ、原則を実践に移す具体的なBTPベースのツールが存在します。

この原則が存在する理由は、ECCの変更モデルにより組織が技術的負債を蓄積し、最終的にアップグレードが法外に高額になる可能性があったためです。S/4HANA Cloud Public Editionでは、設計上Clean Coreが強制されており、コードの直接変更は技術的に不可能です（ SAP S/4HANA Cloud Extensibility ドキュメント）。プライベートクラウドおよびオンプレミス環境では、この規律を意図的に選択し、維持する必要があります。

コンサルタントが顧客にアドバイスする際、Clean Coreは制約ではなく保守性への投資として捉えるのが最適です。コア外に構築されたカスタム拡張機能はすべて、次のSAPリリースでも修正なしで存続します。SAPが四半期ごとに機能面やAIのイノベーションを提供する環境において、その存続性は複合的な価値を生み出します。

FAQ#

Q: クリーンコアとは、S/4HANAを全くカスタマイズできないという意味ですか？ A: いいえ。クリーンコアは、カスタマイズの方法を定義するものであり、カスタマイズの可否を定義するものではありません。キーユーザー設定、オンスタックABAP Cloud、BTPサイドバイサイドの3つの拡張ティアはすべて、承認されたカスタマイズパスです。制約は、方法（SAP提供オブジェクトの変更禁止、未リリースAPIの呼び出し禁止）に対するものであり、カスタムロジックの存在に対するものではありません。

Q: Clean CoreはSAP S/4HANAのお客様にとって必須ですか？ A: S/4HANA Cloud Public Edition（SaaS）では、Clean Coreは技術的に強制されており、変更は不可能です。S/4HANA Cloud Private Edition（RISE with SAP）では、強く推奨されています。オンプレミスのS/4HANAでは、戦略的な選択となります。ただし、これを無視するお客様は、ECCのアップグレードロック問題を再現するリスクがあります。

Q: ABAP Cloudとは何ですか？また、従来のABAPとどのように異なりますか？
A: 従来のABAPでは、開発者はSAP内部の実装コードを含む任意のファンクションモジュールやクラスメソッドを呼び出すことができました。ABAP Cloudでは、開発者はSAPがリリースしたAPIのみを使用するよう制限されます。ABAP Test Cockpit（ATC）は、開発中にこの制限を強制します。ABAP Cloudで記述されたコードはアップグレードに対して安全です。一方、リリースされていないAPIを呼び出すコードは、SAPが内部実装をリファクタリングした際に破損する可能性があります。

Q: Clean CoreにおけるBTPの役割は、BTPのライセンスコストにどのような影響を与えますか？
A: BTPのライセンスは、主にRISE with SAPのクレジットまたはスタンドアロンのBTP契約を通じて付与されます。拡張機能をBTPに移行すると、S/4HANA上のABAP開発からBTPサービスの消費へとコストモデルが変化します。ビジネスケースは、通常、アップグレードコストの削減とイノベーションのスピードに基づいており、即時のコスト削減を目的とするものではありません。BTPの価格詳細は公開されているSAPのドキュメントには記載されておらず、SAPのアカウント担当者と協議する必要があります。

Q: S/4HANA移行時に既存のECCカスタムコードはどうなりますか？ A: SAPは、移行前に既存のカスタムコードを評価するためのCustom Code Migrationアプリを提供しています。組織は通常、カスタムオブジェクトを次のように分類します：ABAP Cloudに保持して適応するもの、BTPサイドバイサイドに移行するもの、または廃止するもの（使用されなくなったため削除）。移行は、S/4HANAのSAP標準機能でカバーされるようになった要件のために構築されたカスタムコードを排除する機会でもあります。

参考資料#

1. SAPinsider — 「クリーンコアとは何か、なぜ重要なのか」 — 2026年5月7日アクセス
2. SAPinsider — クリーンコアの定義（Neptune Software） — 2026年5月7日アクセス
3. SAPinsider — 「Layer Seven Security、クリーンコア戦略の拡大に伴いSAPサイバーセキュリティ拡張機能をBTPに提供」 — 2026年5月7日アクセス
4. SAPinsider — 「SAP S/4HANA Cloud向けクリーンコア請求書ワークフロー」 — 2026年5月7日アクセス
5. SAP News — 「SAP、Dremioを買収しSAPデータと非SAPデータを統合、エージェンティックAIを強化」 — 2026年5月7日アクセス
6. SAP Help Portal — BTPガイダンスフレームワーク：クリーンコアとは — 2026年5月7日アクセス
7. SAP Help Portal — SAP S/4HANA Cloud 拡張性ドキュメント — 2026年5月7日アクセス

次に読むべきもの#

このサイトでは、BTPのナレッジを以下の構成で整理しています。