Clean Core は理想論ではない：SAP BTP へ切り出す拡張と S/4HANA に残す責務をどう分けるか
Clean Core という言葉は SAP の文脈で頻繁に出てきますが、実務ではしばしばスローガンのまま消費されます。
「とにかくコアを汚さない」「拡張は全部 SAP BTP に出す」といった説明は一見わかりやすいものの、そのまま設計に持ち込むとまず破綻します。なぜなら、実際の現場で問われるのは思想ではなく、どの責務を S/4HANA に残し、どの責務を BTP へ切り出すべきか という具体的な線引きだからです。
この記事では、Clean Core を理想論で終わらせず、SAP BTP 時代の拡張設計としてどこまで現実的に運用できるのかを整理します。
先に結論
先に結論を言うと、Clean Core は「すべてを外へ出す」ことではありません。
判断の軸は次のように整理できます。
- 業務オブジェクトの整合性やトランザクション責任に強く結びつくもの は S/4HANA 側に残す
- 周辺体験、外部連携、独立デプロイしたい処理 は SAP BTP 側へ切り出す
- 重要なのは製品の好みではなく、変更頻度・責任境界・監査性・アップグレード耐性 で線を引くこと
つまり Clean Core の本質は、コアを空にすることではなく、コアに残すべき責務を絞り込み、変化しやすい拡張を外で受ける設計原則 にあります。
なぜ Clean Core が理想論で終わりやすいのか
Clean Core が現場で空回りする理由は単純です。多くの議論が「中に書くな」「外でやれ」という禁止事項で止まり、何を中に残してよいのか を語らないからです。
しかし実際には、S/4HANA の内部に残した方が安全な責務は確実にあります。たとえば次のようなものです。
- 業務トランザクションと強く一体化した整合性制御
- 標準業務オブジェクトに密着した検証ロジック
- 更新順序やコミット境界を厳密に守る必要がある処理
- 監査上、ERP コアで責任を持たせるべき判定
これらまで全部 BTP に逃がすと、見た目は Clean でも、実際には責任分界が崩れます。
S/4HANA に残すべき責務
まず押さえるべきなのは、S/4HANA は単なるデータ保管庫ではないという点です。そこには業務オブジェクト、整合性、トランザクション責任、標準プロセスの意味づけが乗っています。
そのため、次のような処理はコアに残す方が自然です。
1. 標準業務オブジェクトに密着した判定
販売、購買、会計、在庫といった標準オブジェクトに直接ぶら下がる判定は、コア側で扱う方が安全です。理由は、業務意味とデータ整合性を分離しすぎると、後から障害時の責任が曖昧になるからです。
2. トランザクション境界の内側で完結すべき処理
同一更新の中で必ず成立していなければ困る検証や派生更新は、外部 API 越しに逃がすべきではありません。ネットワーク越しの side-by-side 拡張にすると、再試行、順序、部分失敗の設計コストが一気に上がります。
3. アップグレード対応済みの拡張ポイントで実現できるもの
ABAP Cloud や標準拡張ポイントで吸収できるなら、無理に外へ出さない方が良い場面もあります。Clean Core は「ABAP を捨てる」話ではなく、安全な拡張モデルへ寄せる 話です。
SAP BTP に切り出すべき責務
一方で、BTP 側に出した方が圧倒的に合理的な領域もあります。
1. 外部システム連携を含む周辺プロセス
SaaS、社内 API、データ基盤、イベント配信などを跨ぐ処理は、S/4HANA の中に閉じ込めるより BTP 側で受ける方が見通しが良くなります。Integration Suite や Event Mesh を含め、接続・監視・再送・認可の設計を外にまとめやすいからです。
2. UI/UX を頻繁に変える周辺アプリ
現場入力補助、承認体験、ダッシュボード、検索 UI のように変化が速い領域は、BTP で独立デプロイできる形にしておく方が運用しやすいです。ERP コアの変更サイクルと分離できるメリットが大きいです。
3. AI、推論、非同期処理、イベント駆動
AI Core、外部 LLM、ワークフロー、イベント駆動処理のような変化しやすい実行基盤は、BTP 側に置く方が現実的です。特に AI は権限、監査、実行可否の制御が重要であり、ERP コアの中に直接押し込むより、BTP 上で文脈制御する方が壊れにくいです。
現実的な判断基準
実務では「中か外か」を技術好みで決めると事故ります。最低でも次の軸で評価した方が良いです。
| 判断軸 | S/4HANA に残す寄り | SAP BTP に切り出す寄り |
|---|---|---|
| 業務責任 | 標準業務オブジェクトと不可分 | 周辺プロセス・補助機能 |
| トランザクション | 同期・同一整合性が必要 | 非同期・疎結合で許容 |
| 変更頻度 | 安定的で頻繁に変えない | 要件変化が速い |
| 外部連携 | 少ない | 多い |
| 監査/認可 | ERP コアで責任を持つべき | 境界で制御したい |
| デプロイ | コア更新と一体でもよい | 独立リリースしたい |
この表に沿って見ると、Clean Core は宗教論争ではなく、責務設計の話だと分かります。
よくある失敗パターン
失敗 1: 何でも BTP に出して責任境界を壊す
一見スマートに見えますが、実際には「誰が最終責任を持つのか」がぼやけます。特に更新順序や整合性が重要な処理は、外に出した瞬間に難易度が跳ね上がります。
失敗 2: 逆に怖くて何も外へ出せない
これもよくあります。結果として UI も連携もレポート補助も全部コアへ押し込み、アップグレード耐性を失います。Clean Core はゼロか百かではありません。
失敗 3: CAP と ABAP Cloud の使い分けを決めずに始める
BTP に出すと決めた後も、CAP で受けるのか、ABAP Cloud で受けるのか、Integration Suite をどう絡めるのかを設計しないと、結局また境界が曖昧になります。
壊れにくい進め方
現実には、次の順序で整理すると破綻しにくいです。
- S/4HANA に残すべき業務責任 を先に定義する
- 外に出したい理由 を「変更頻度」「連携」「独立デプロイ」で説明できるようにする
- BTP 側の実装方式 を CAP / ABAP Cloud / Integration Suite / Event Mesh で分ける
- 認可、監査、障害時責任 を業務側と運用側で合意する
- アップグレード時に何を守りたいのか を最初に明文化する
この順番なら、Clean Core を標語ではなく設計判断として扱えます。
まとめ
Clean Core は理想論ではありません。ただし、「全部外へ出す」という雑な理解のままでは実装で失敗します。
重要なのは、
- S/4HANA に残す責務
- SAP BTP に切り出す責務
- その境界を決める判断軸
を先に言語化することです。
Clean Core の価値は、コアを空にすることではなく、変化に強い境界を意図的に設計すること にあります。SAP BTP を使う意味も、まさにそこにあります。