1. はじめに
前回の記事で、私は「クリーンコアとはSAP標準のデータモデルを壊さないこと」だと書きました。
そして、In-App拡張やSide-by-Side拡張といった手段を使っても、標準を崩すような設計をしてしまえば“クリーン”とは言えない、という話をしました。
更にもう一つ重要なポイントがあります。
それは、人間が理解できるデータ構造ではなく、AIが正しく理解できるデータモデルを維持することこそが、クリーンコアの本質だという点です。
AIや機械学習を活かした「Intelligent ERP」の世界では、システム内部のデータ構造が標準化され、一貫性を保っていることが何より重要です。
もし各社が勝手にフィールドの意味を変えたり、独自のマスタ構造を作ったりすれば、AIはそのデータを“標準の意味”として認識できず、誤った判断を下してしまいます。
だからこそ、クリーンコアとは「SAPが定義した標準構造を壊さず、AIにも理解できる形で保つ」ということになります。
人間中心のERPから、AI中心のERPへ進化する今、その重要性はますます高まっていると感じています。
では、今回の記事では、そんなクリーンコアの考え方がSAP公式としてどのように進化したのかについて触れていきます。
実は近年、SAPはクリーンコアに対してこれまで以上に明確な基準を設けました。
これがいわゆる 「クリーンコア拡張性モデル（Clean Core extensibility model）」です。
この拡張性モデルでは、
どの拡張がクリーンで、どの拡張がリスクを孕んでいるのかをA～Dのレベルで分類できるようになっています。
つまり、「クリーンに保つべき」という抽象的な概念から、“どこまでなら大丈夫か”を判断できる時代に入ったわけです。
2.SAPが示した新しいクリーンコアとは
これまで「クリーンコア」といえば、
• 標準を改修しない
• BTPで拡張する
• コアに触らない
といった、どちらかというと“思想”や“姿勢”のように語られることが多いものでした。
しかし最近、SAPはこのクリーンコアに対してより実務的な判断軸を提供し始めています。
それが「クリーンコア拡張性モデル（Clean Core extensibility model）」と呼ばれる考え方です。
この拡張性モデルでは、拡張内容や設計アプローチをA〜Dの4段階で分類します。
A：リリース済みインターフェイスで連携（BTP・ABAP Cloud含む）。最もアップグレードに強い。
B：クラシックAPI活用（長年の実績・文書化あり。ただし正式な安定契約はなし）。Aより柔軟だが、わずかにリスク増。
C：内部オブジェクト参照（非公開・非保証）。柔軟だがアップグレードリスク顕著。
D：非推奨の拡張（標準コード改変、暗黙拡張、直接書込み等）。最優先で是正すべき領域。
レベルAとBは“アップデートに強い拡張”です。
特にレベルAの状態は、SAPが長期的に保証し、AIも標準前提でデータを解釈することができます。
逆に、レベルCとDは時間が経つほど保守が難しくなり、
S/4HANAのアップグレード時に障害ポイントとなる可能性が高い設計です。
3.クリーンコアの拡張性モデルによって、提案・設計・レビューがどう変わるのか
ここまではSAP公式が提示しているクリーンコアの新しいモデルについて説明をしてきました。
ここからは、SAPコンサル、設計者に求められる役割がこのように変わるのではないかという私自身の考えを述べていきます。
※あくまでSAP歴5年目のまだ若手としての、現場での肌感ベースの展望です。
3-1.「できる/できない」ではなく、「どのクリーンコアレベル」で実現できるかの提案へ
これまでの提案では、
「標準で対応できるか」
「アドオンが必要か」
の2択で語られがちでした。
しかし、拡張性モデルが導入された今は、
「その要件では、レベルAで実現できるか。もしくはBになってしまうのか」
という「拡張の健全性」まで提案段階で説明できることが価値になります。
| 従来の提案 | クリーンコアを考慮した提案 |
|---|---|
| この要件は標準ではできません。アドオンが必要です。 | この要件はレベルBの拡張で実現可能です。APIベースで構築すれば、アップデート影響を最小化できます。 |
| カスタマイズすれば対応可能です。 | 現在の設計はレベルC相当です。内部オブジェクト参照があるため、将来的なリスクを伴います。Bレベルへ移行するために設計を見直しましょう |
| 現行プログラムを移植しましょう | 既存のロジックはレベルD相当です。クリーンコア移行の観点では再設計が推奨です。 |
3-2.コンサルは「業務知識 × 標準知識 ×拡張設計 × データ理解」が必要になる
従来のSAPコンサルの評価軸はこうでした
①「モジュール知識がある」
②「標準シナリオを理解している」
③「カスタマイズができる」
これからはこう変わっていくと考えています。
①「標準シナリオを理解している」
②「標準のデータモデルがどう繋がっているかを理解している」
③「拡張する場合、レベルA、Bに収める設計ができる」
つまり、「標準に詳しい」だけでは不十分で、“標準を壊さずどう拡張するか”まで説明できるコンサルが価値を持つ時代になります。
3-3.クリーンコアの先にあるメリットを説明できる
クリーンコアというと「やってはいけないことが増える」「制約が多い」と思われがちです。
しかし、コンサルや設計者がそのメリットを理解し、お客様やチームメンバーに「なぜクリーンに保つ必要があるのか」を説明できることが、これからの重要なスキルになります。
実際にはAIやJouleエージェント、AIシナリオといった新技術を“活かすための前提”です。
クリーンコアを維持することで、AIが標準データを正しく理解し、Jouleエージェントが本来の力を発揮できます。
4.まとめ
ERPは導入して終わりではありません。
SAPは、運用しながら継続的にアップデートされていくことを前提としたシステムです。
だからこそ、クリーンコアは「本番稼働後に気づいたときに考えるもの」ではなく、要件定義の段階――むしろもっと前の構想段階から意識しておく必要があります。
拡張の設計判断を誤ると、その瞬間は業務要件を満たせたとしても、数年後のアップグレードや追加開発のたびに 技術的負債が雪だるま式に膨らんでしまいます。
提案時にエンドユーザへ「AIが使えますよ」「高度な分析ができますよ」と説明することは簡単です。
しかし、それを綺麗事で終わらせず、実際に“使える状態”として成立させるためには、クリーンコアの前提が欠かせません。
今後の記事では、更に具体的な導入論や設計方法に焦点を当てて記事を書きたいと思います。