2026年7月23日、「SAPクリーンコアを実現するシステム構成と考え方 ～日本企業の「細やかな業務要件」をどう標準化・外出しするか～」というセミナーが開催されました。本記事ではその講演内容のポイントをご紹介します。

登壇者

この記事で分かること

SAP × クリーンコアの実現方法は、標準機能の維持と細やかな業務要件の外出しを両立させる設計にある

まず、SAPに手を加えずに標準機能で運用するクリーンコアと、業務プロセス側をSAP標準に合わせるFit to Standardの考え方を整理します。日本企業に特有の細やかな業務要件をSAP本体に取り込むのではなく、周辺のサラウンドソフトウェアへ切り出すアーキテクチャーこそが、両者を両立させる実現方法であることを解説します。

クリーンコアは、ERPパッケージにアドオンやモディフィケーションを加えず、標準機能のまま運用するという「システム側の視点」に立った考え方です。これに対してFit to Standardは、企業の業務プロセス自体をSAPに搭載されている標準機能へ適応させていくという「業務側の視点」に立った考え方となります。両者は視点が異なるだけで、表裏一体の関係にあります。業務プロセスを標準機能に合わせていくことで、独自のカスタマイズ開発が不要となり、結果としてSAPシステムの中核が標準機能のまま維持される、という構造につながります。

一方で、日本企業の業務現場には、ミリ単位の帳票レイアウト調整や複雑な明細行の出力、拠点ごとの運用差異など、SAP標準機能だけでは吸収しきれない「細やかな業務要件」が数多く存在します。ここでSAP本体にアドオンを積み上げてしまうと、クリーンコアもFit to Standardも両立が難しくなります。そこで採用されるのが、細やかな業務要件をSAP周辺の「サラウンドソフトウェア」へ切り出し、SAP本体は標準のまま維持するというアーキテクチャーです。差別化領域はAPI連携を通じて外部プラットフォームや専用パッケージで拡張し、業務ルールの変更はプログラム修正ではなく外部ツールやビジネスルールエンジン（BRE）の設定変更で吸収する、という役割分担が基本設計となります。

従来のアドオン開発の限界と、2027年問題・40%超カスタマイズからの脱却という背景

次に、なぜ今クリーンコアとFit to Standardが求められているのか、その背景を整理します。従来のアドオン開発が抱える限界、SAP ERP 6.0の標準サポート終了に伴う移行の壁、そして日本企業に多い40%を超えるカスタマイズという実態が、標準機能への回帰を必要としている構造を明らかにします。

背景の一つ目は、従来のアドオン開発の限界です。自社の業務プロセスに合わせてSAPをカスタマイズし続けてきた結果、独自の作り込みが蓄積されてシステムが複雑化し、アップデートのたびに多大な検証工数と改修コストが発生する、という負のスパイラルに陥っています。標準機能の恩恵を受けにくくなる一方で、保守と改修だけで運用リソースが消費されていく構造は、日本企業の多くに共通する課題です。
背景の二つ目は、いわゆる「2027年問題」と移行の壁です。SAP ERP 6.0の標準サポートが2027年末に終了し、S/4HANAへの移行が必須となります。ただし移行先では設計思想や標準機能が大きく異なるため、過去のアドオンをそのまま持ち込むことが難しく、移行プロジェクトが停滞しやすい構造があります。
背景の三つ目は、40%を超えるカスタマイズという日本企業の実態です。日本企業では40%を超えるカスタマイズが前提となっているケースが多く、この状態のままではS/4HANA移行そのものが重い負債となります。「システム側の標準化」と「業務側の適応」を同時に進め、身軽なERP環境をつくることが、移行の成否を分ける前提となっています。

ASTERIA Warpによるデータ連携処理の一元化とSVFシリーズによる帳票基盤の共通化
── 周辺ソフトへの切り出しアプローチ

続いて、クリーンコアを実現する具体的な構成として、AI＆ノーコード開発のデータ連携ツール「ASTERIA Warp」によるデータ連携処理の一元化と、「SVFシリーズ」による帳票デジタル基盤の共通基盤化を紹介します。差別化領域を外部プラットフォームに、帳票のような共通要件を専用基盤に切り出す設計により、SAPを標準のまま維持しながら業務要件を吸収する方法を整理します。

まず、データ連携の観点です。SAPと周辺システム（DWH、受発注、クラウドストレージ等）を個別のインターフェースで接続していくと、システムが増えるほど連携が複雑化し、メンテナンスが困難になります。ASTERIA Warpは、SAPと周辺システムの間にハブとして介在することで、インターフェースを一元化し、SAP本体に直接手を入れずに周辺システムと連携できる構成を実現します。SAPをクリーンコアのまま維持しながら、業務側のデータ活用要件を柔軟に取り込むことができる設計です。

連携処理の作り方も、SAP周辺の運用を軽くするうえで重要な要素です。ASTERIA Warpのフローデザイナーでは、アイコンをワークスペースにドラッグ＆ドロップで並べていくノーコード開発により、データ連携を定義できます。加えて、AIフロー作成機能では、「売上実績を集計したい」といった自然言語での指示に対して、データの所在（データベース、CSV、Excelなど）や集計条件をAIが対話で確認しながらフローの雛形を自動生成します。大まかな流れをAIで生成し、微修正はノーコードで行うという組み合わせにより、開発・メンテナンスの工数を抑えやすくなります。運用中の不明点やエラーメッセージへの対応は、AIチャットボットがマニュアルを参照して回答する仕組みが用意されています。

適用事例としては、SAPから出力される受注伝票PDFをクラウドストレージの各フォルダへ保存する作業を自動化して業務工数削減につなげた事例や、SAPと新たな業務システムの連携をJavaによるスクラッチ開発と比べて開発工数1/6以下で実現した事例、親会社からの独立に伴う大規模移行で200本以上のインターフェースをわずか4カ月で構築した事例などが挙げられます。

次に、帳票の観点です。日本企業の帳票要件には、ミリ単位の緻密なデザイン調整や動的なグラフ配置、複雑な明細出力といった「表現と要件の壁」、物流や製造現場での大量・高速印刷、拠点印刷、ラベル印刷といった「パフォーマンスの壁」、さらに出力後の保管や取引先とのやり取りが分断されることによる「業務サイクルの分断」があります。これらを一つひとつSAP本体で吸収しようとすれば、アドオンが積み上がり、クリーンコアから遠ざかっていきます。

SVFシリーズは、帳票の生成・保管・流通（取引）を一つの基盤に統合し、帳票を起点に業務の自動化・最適化を進める「デジタル帳票基盤」として位置づけられます。基幹システムやクラウドアプリと連携した多彩な帳票設計と大量・高速出力、SVFで帳票を生成し、SVF Archiverで電子ファイルの保管・仕分け・検索を行い、SVF TransactでWeb配信や受領、Peppolに準拠したデジタルインボイスの送受信に対応します。また、タイムスタンプについてはTrusteeと組み合わせることで利用できます。これらを連携させることで、帳票の生成から保管、取引先とのやり取りまでを一連の業務として構成できます。SAP標準の帳票ツールと組み合わせつつ、対外向け帳票、大量・高速印刷、拠点印刷、ラベル印刷が必要な領域でSVFの導入価値が最大化されるという役割分担で運用します。

さらに、ホスト・独自業務システム・ERPといった上位システムを問わず、共通のインターフェースで帳票出力を一元管理することで、周辺システムの帳票もまとめて共通基盤化することができます。SAPだけでなく、企業全体のミドルウェアとして帳票運用を統合するという発想です。ダイキン工業株式会社の事例では、化学事業部の「グローバル統一基盤プロジェクト」の一環として、SAPを起点にSVFを組み合わせ、帳票の作成から保存、Web配信までを一気通貫で構築し、業務効率化・ヒューマンエラー防止・ガバナンス強化につなげています。

差別化領域はASTERIA Warpを介した外部プラットフォーム連携で、帳票のような全社共通要件はSVFシリーズによる帳票デジタル基盤で吸収する、という役割分担により、SAP本体をクリーンコアのまま維持しつつ、日本企業に特有の細やかな業務要件をアーキテクチャー全体で受け止めることが可能になります。

実現方法を運用まで持続させるために ── 周辺システムを止めない可用性設計という最後のピース

最後に、クリーンコアで構成したSAPと、切り出した周辺システムを長期にわたって運用で守るための視点として、周辺システムの可用性設計に触れます。ASTERIA WarpとSVFに代表される周辺システムが止まった時点で、標準化した基幹業務そのものが停止するという構造を確認し、実現方法を運用まで持続させるための最後のピースとして、HAクラスターによる止めない仕組みを位置づけます。

SAP × クリーンコアの実現方法は、SAP本体の標準機能を維持しつつ、日本企業に特有の細やかな業務要件を周辺のサラウンドソフトウェアへ切り出す設計にあります。ASTERIA Warpによる疎結合な連携でインターフェースを一元化し、SVFシリーズによる帳票デジタル基盤で全社共通の帳票要件を吸収する、という役割分担が、その中核を担う構成です。

この構成を運用で守るための最後のピースが、周辺システムの可用性設計です。基幹系システムの安定稼働のためには、SAPだけでなく、ASTERIA WarpやSVFに代表される周辺システムも止まらずに動き続けることが求められます。HAクラスター製品「LifeKeeper」は、同じ役割を担う2台のサーバー（1台は稼働系、もう1台は待機系）を用意し、稼働系のサーバーやアプリケーションに障害が起きた場合、自動的に待機系のサーバーへ切り替えて運用を継続します。これにより、ASTERIA WarpやSVFなどの周辺システムの停止時間を最小限に抑えられます。ハードウェアの障害だけでなく、その上で動くアプリケーション層の障害までを対象に含める設計であり、切り出した周辺システムを止めない選択肢として位置づけられます。

よくある質問

Q1. クリーンコアとFit to Standardは、どちらから着手すべきですか？両者の関係をどう理解すればよいでしょうか？

A1. クリーンコアはシステム側の視点、Fit to Standardは業務側の視点であり、両者は表裏一体の関係にあります。どちらか一方だけを進める設計にはなりにくく、業務プロセスをSAP標準に合わせていくFit to Standardの取り組みが進むことで、独自カスタマイズが不要となり、結果としてSAP本体を標準機能のまま維持するクリーンコアが成立する、という構造で理解するのが自然です。業務側と情報システム側が同じアーキテクチャー方針を共有した状態で、両輪として着手する設計が前提となります。

Q2. 日本企業に多い40%を超えるカスタマイズを、SAP標準機能とサラウンドソフトウェアにどう振り分ければよいですか？

A2. 財務・人事などの基礎業務については、業務側をSAP標準に合わせていく方針で強力に統制するのが基本です。差別化領域は、SAP本体にアドオンとして取り込むのではなく、API連携を通じた外部プラットフォームや専用パッケージへ切り出します。業務ルールの変更が頻繁に発生する領域は、プログラム修正ではなく、外部ツールやビジネスルールエンジン（BRE）の設定変更で吸収できるようにアーキテクチャーを設計します。SAP本体の中核はクリーンコアのまま維持し、周辺のサラウンドソフトウェアで細やかな要件を受け止める、という役割分担で振り分ける考え方です。

Q3. ASTERIA Warpによるデータ連携処理を一元化する構成は、既存のPoint-to-Point接続とどう違うのでしょうか？

A3. Point-to-Point接続は、システム間の接続をインターフェース数に応じて個別開発で対応していく方式です。周辺システムが増えるほど接続経路が増え、メンテナンスが複雑化しやすい構造となります。ASTERIA Warpによるデータ連携処理を一元化する構成は、SAPと周辺システムの間にハブとして介在し、インターフェースを一元化する構成です。周辺システムを入れ替えた際もASTERIA Warp側の設定変更で対応できるため、SAP本体を標準のまま維持しつつ、周辺システムの入れ替えや追加に柔軟に対応しやすくなります。

Q4. SAP標準の帳票機能とSVFシリーズは、どう使い分けるのが適切ですか？

A4. 日本企業に特有の帳票要件には、ミリ単位の緻密なデザイン調整、動的なレイアウト、複雑な明細出力といった「表現と要件の壁」、物流・製造現場での大量・高速印刷、拠点印刷、ラベル印刷といった「パフォーマンスの壁」、さらに出力後の保管や取引先配信の分断による「業務サイクルの分断」があります。SAP標準の帳票ツールでカバーしきれる領域は標準に寄せつつ、対外向け帳票、大量・高速印刷、拠点印刷、ラベル印刷が必要な領域はSVFシリーズに切り出す、という使い分けで導入価値を最大化するのが基本です。あわせて、SVF Archiverによる電子保存やWeb配信までを含めた帳票デジタル基盤として運用することで、業務サイクル全体を一つの基盤に統合しやすくなります。

Q5. クリーンコアで構成したSAPと周辺システムを、長期運用で安定稼働させるために必要な観点は何ですか？

A5. SAP本体をクリーンコアで構成しても、切り出したASTERIA WarpやSVFなどの周辺システムが止まれば、標準化した基幹業務そのものが停止します。長期運用の観点では、SAP本体の可用性だけでなく、周辺システムに対しても可用性設計を行うことが重要です。HAクラスター製品「LifeKeeper」は、同じ役割を担う2台のサーバー（1台は稼働系、もう1台は待機系）を用意し、稼働系のサーバーやアプリケーションに障害が起きた場合、自動的に待機系のサーバーへ切り替えて運用を継続します。これにより、ASTERIA WarpやSVFなどの周辺システムの停止時間を最小限に抑えられます。クリーンコアで得た身軽なアーキテクチャーを、運用フェーズでも持続させるための最後のピースとして、周辺システムの可用性設計を位置づけることが求められます。