SAP Clean Core戦略とは？コアを守りながら拡張する新しい開発思想

はじめに

S/4HANAへの移行やクラウド化の話題で、近年もっとも頻繁に登場するキーワードの一つが Clean Core（クリーンコア） です。「カスタマイズを減らせ」「標準に寄せろ」という話は以前からありましたが、Clean Coreはそれをさらに進めて、ERPのコアを「クリーン」に保ちつつ、必要な拡張は正しい方法で行うという包括的な戦略です。

本記事では以下の4つを軸に解説します。

1. Clean Coreとは何か — 5つの柱と基本思想
2. 拡張性レベル（A〜D） — どこまでがClean Coreで、何がNGか
3. RAP・BTPとの関係 — Clean Core準拠の開発基盤
4. よくある誤解 — 「カスタマイズ禁止」ではない理由

なぜClean Coreを学ぶ必要があるのか（why so）：S/4HANA Cloud Public Editionでは四半期ごとの自動アップデートが行われます。Clean Coreに準拠していないカスタムコードは、このアップデートで動かなくなるリスクがあります。On-Premise環境でも、将来のクラウド移行やSAP Business AIの活用を見据えると、Clean Coreの理解は避けて通れません。SAPは「Clean Coreはオプションではなく標準」と明言しており、すべてのS/4HANA顧客に影響する戦略です。

Clean Coreとは何か

一言で言うと

Clean Coreとは、ERPシステムのコア（標準機能）をできるだけ変更せず、ビジネス固有の差別化が必要な部分はSAPが定めた拡張方法で対応するという指導原則のセットです。

従来のSAP開発では、標準のABAPコードを直接修正（Modification）したり、標準テーブルにカスタム項目を追加したりすることが日常的に行われていました。これらのカスタマイズが積み重なると、アップグレードのたびに大量のテスト・修正が必要になり、「技術的負債」としてシステムの進化を妨げる原因になります。

Clean Coreはこの問題を根本的に解決するため、「コアは触らない、拡張は正しい場所で」というアプローチを取ります。

Clean Coreの5つの柱

SAPはClean Coreを5つの柱（Dimension）で定義しています。

flowchart LR
  subgraph "Clean Coreの5つの柱"
    A["Processes\n業務プロセス"]
    B["Extensibility\n拡張性"]
    C["Data\nデータ"]
    D["Integration\n統合"]
    E["Operations\n運用"]
  end
  F["Clean Core\n（中心思想）"] --> A
  F --> B
  F --> C
  F --> D
  F --> E

読者への示唆（so what）：Clean Coreは「コードをきれいにする」だけの話ではありません。プロセス・データ・統合・運用まで含めた5つの柱すべてを整えて初めて「Clean Core」と言えるのです。コードだけクリーンにしても、データガバナンスが不在なら意味がありません。

拡張性レベル（A〜D）

「何がClean Coreで、何がNGか」の判断基準

SAPは2025年に、拡張性を4段階のレベル（A〜D） で分類するモデルを導入しました。これにより、「自分のカスタムコードがClean Core準拠かどうか」を客観的に判断できるようになっています。

flowchart LR
  subgraph "Clean Core準拠"
    A["Level A\nReleased API\n安定性契約あり"]
    B["Level B\nClassic API\n概ね安定"]
  end
  subgraph "Clean Core非準拠"
    C["Level C\nInternal Objects\n変更リスクあり"]
    D["Level D\nNot Recommended\n非推奨"]
  end
  A -->|"推奨度"| B
  B -.->|"境界線"| C
  C -->|"リスク増大"| D

なぜレベル分けが重要か（why so）：従来は「カスタムコード＝全部NG」か「カスタムコード＝仕方ない」の二択になりがちでした。A〜Dレベルの導入により、「ここまではOK、ここからは段階的にリスクが上がる」というグラデーションで判断できるようになりました。既存コードの棚卸しにも、新規開発のガイドラインにも使えます。

S/4HANA Cloud版ごとの制約

読者への示唆（so what）：Public Editionを使う場合はLevel A以外の選択肢がないため、Clean Core準拠は必須です。Private Edition / On-Premiseでも、将来のCloud移行を見据えるなら、今からLevel A/Bで開発しておくことが実務上の保険になります。

拡張の2つのアプローチ

Clean Coreでの拡張には、大きくOn-Stack拡張とSide-by-Side拡張の2つがあります。

On-Stack拡張（S/4HANA内部）

S/4HANAシステムの中で直接行う拡張です。さらに2つのタイプに分かれます。

Developer Extensibilityで使うRAP（RESTful ABAP Programming Model）は、ODataシリーズのODataサービスの作り方｜SEGW方式とCDS View＋RAP方式を比較するで詳しく解説しています。BTP側でNode.js/JavaベースのCAP（Cloud Application Programming Model）と使い分ける視点はHANA Cloud CDS vs ABAP CAPを参照してください。なお、従来型のBAdI拡張も「公開されたBAdIを使う限り」Clean Core準拠として残ります。モジュール別の具体例はPPモジュールのBAdI実装ガイドやCOモジュールのBAdI実装ガイドで整理しています。

なぜ拡張アプローチの選択が重要か（why so）：On-Stack拡張の中でもKey User ExtensibilityとDeveloper Extensibilityでは、必要なスキル・対応範囲・保守の責任範囲が大きく異なります。Key User Extensibilityは業務ユーザーが主導でき、迅速に対応できる反面、複雑なロジックには対応できません。Developer Extensibilityはより柔軟ですが、ABAP Cloud開発スキルが必要です。適切な方式を選ばないと、開発コストの肥大化や保守困難な拡張が生まれる原因になります。要件の複雑さと社内のスキルセットを踏まえて判断しましょう。

Side-by-Side拡張（SAP BTP上）

S/4HANAのコアとは**別のプラットフォーム（SAP BTP）**上で構築する拡張です。

flowchart LR
  subgraph "S/4HANA（コア）"
    CORE["標準機能\n変更しない"]
    API["OData API\n（Released API）"]
    CORE --> API
  end
  subgraph "SAP BTP（拡張）"
    EXT1["カスタムアプリ\n（SAP Build / CAP）"]
    EXT2["プロセス自動化\n（Build Process\nAutomation）"]
    EXT3["統合フロー\n（Integration Suite）"]
  end
  API -->|"API経由で\n連携"| EXT1
  API -->|"API経由で\n連携"| EXT2
  API -->|"API経由で\n連携"| EXT3

なぜSide-by-Side拡張があるのか（why so）：On-Stack拡張はS/4HANAのアップデートサイクルに縛られます。Side-by-Side拡張はBTP上で独立してデプロイ・更新できるため、コアのアップデートと拡張のリリースサイクルを分離できます。たとえば「S/4HANAは四半期更新、カスタムアプリは毎週更新」という運用が可能になります。

Side-by-Side拡張で中核となるCAP（Cloud Application Programming Model）の全体像・アーキテクチャ・ABAP RAPとの違いについてはSAP CAP入門で詳しく扱っています。On-Stack側のRAPと、Side-by-Side側のCAPをどう使い分けるかの判断軸を整理する際にあわせて参照してください。

ODataを使ったAPI連携の基礎についてはODataとは何か？SAPの外部連携を支えるAPIプロトコルの基礎で解説しています。

RAP・BTPとClean Coreの関係

RAPはClean Core開発の「心臓部」

RAP（RESTful ABAP Programming Model）は、Clean Coreに準拠したABAP開発の事実上の標準です。

RAPの詳細（managed/unmanagedシナリオ、Behavior Definition）についてはODataサービスの作り方で、CDS Viewの基礎についてはCDS Viewとは何か？で解説しています。

BTPはClean Core拡張の「実行基盤」

SAP BTP（Business Technology Platform）は、Side-by-Side拡張を構築・実行するためのクラウドプラットフォームです。

なぜRAPとBTPの両方を理解する必要があるか（why so）：Clean Core準拠の開発では、拡張要件に応じてOn-Stack（RAP）とSide-by-Side（BTP）を使い分ける必要があります。RAPはS/4HANAのデータモデルに密結合した拡張に向いており、BTPはコアから独立したアプリやプロセス自動化に向いています。両者の特性を理解せずに選択すると、パフォーマンス問題やアーキテクチャの複雑化を招きます。たとえば、コアデータに頻繁にアクセスする拡張をBTPに置くとAPI呼び出しのオーバーヘッドが発生し、逆にコアと無関係なUIアプリをOn-Stackで作るとアップデート時の影響範囲が不必要に広がります。

カスタムコードの棚卸し：ATCの活用

既存のカスタムコードがClean Coreにどの程度準拠しているかを評価するために、ATC（ABAP Test Cockpit） が使われます。

ATCはカスタムコードを自動分析し、以下を報告します。

読者への示唆（so what）：Clean Coreへの移行は「一気に全部やる」ものではなく、ATCで現状を可視化し、リスクの高い部分（Level D）から段階的に対処するのが現実的なアプローチです。パフォーマンス分析に使うSE30/SATについてはABAPパフォーマンスチューニング入門で解説しています。

よくある誤解

誤解①：「Clean Core＝カスタマイズ全面禁止」

事実：禁止ではありません。Clean Coreは「正しい場所で正しい方法の拡張」を推奨しています。ビジネス差別化に必要な拡張は、Key User Extensibility、Developer Extensibility（RAP）、Side-by-Side拡張（BTP）のいずれかで行います。

誤解②：「標準のまま使えば自動的にClean Core」

事実：標準機能だけを使っていても、データガバナンスが不在だったり、統合が非標準的な方法で行われていたりすれば、Clean Coreとは言えません。5つの柱すべてを整える必要があります。

誤解③：「BTPに移せばクリーン」

事実：BTPへの移行は技術的な配置の変更であり、設計がクリーンかどうかは別問題です。BTP上でも、設計が悪ければ保守性の低い拡張になります。

誤解④：「Clean Coreは守りの戦略」

事実：守りではなく、イノベーション加速のための攻めの戦略です。コアがクリーンであれば、アップグレードが容易になり、SAP Business AIなどの最新機能をいち早く活用できます。SAPは「Clean Core採用企業は10年間で最大75%多くのビジネス価値を実現できる」と主張しています。

誤解⑤：「グリーンフィールド導入にしか適用できない」

事実：ブラウンフィールド（既存システム移行）でも適用可能です。ATCでカスタムコードを棚卸しし、段階的にClean Core化を進めるアプローチが一般的です。SAP Activate方法論についてはSAP Activateとは？で解説しています。

導入事例

Clean Core戦略の導入事例を紹介します。S/4HANA Cloudの導入事例全般についてはS/4HANA Cloud導入事例まとめも参照してください。

まとめ

• **Clean Coreは「コアを変更せず、正しい方法で拡張する」**という包括的な戦略であり、5つの柱（プロセス・拡張性・データ・統合・運用）で構成される
• 拡張性はLevel A〜Dの4段階で評価され、Level A（Released API）が最もClean Core準拠。Public EditionではLevel A以外の選択肢がない
• 拡張にはOn-Stack拡張（Key User / Developer Extensibility）とSide-by-Side拡張（BTP）の2つのアプローチがある
• RAPがClean Core準拠のABAP開発の事実上の標準であり、BTPがSide-by-Side拡張の実行基盤
• 「カスタマイズ禁止」ではなく、正しい場所で正しい方法の拡張を推奨する攻めの戦略
• 既存コードの棚卸しにはATC（ABAP Test Cockpit）を活用し、Level Dから段階的にClean Core化を進めるのが現実的

Clean Core戦略を実践するには、S/4HANAとECCで何が変わったのかを操作画面レベルで把握しておくことが前提になります。実際のS/4HANA画面で新旧の違いを確認できるUdemy講座が役立ちます。