公開2026.07.13更新2026.10.03 ERP

SAP S/4HANAとは？ECCとの違い・導入形態・移行方式と2027年問題への備えを解説

SAP S/4HANAとは、SAPが2015年に投入した基幹システム「SAP ERP 6.0（ECC）」の後継にあたる次世代ERPです。名称はSimple・第4世代・インメモリDB「SAP HANA」を組み合わせた造語で、HANA上でのみ動く点がECCと異なります。この記事では、ECCとの機能・データ構造の違い、パブリック・プライベート・オンプレミスの3形態、Brownfieldなど3方式の進め方に加え、移行前に現行ECC上で回す必須チェックの手順までを、SAP公式ドキュメントの記載にもとづいて整理しました。どの形態・方式で、いつ移行を計画すべきかの判断軸まで示します。

まとめ：S/4HANAの全体像とECCから移行する企業が押さえる要点

S/4HANAは、ECC（SAP ERP 6.0）の後継として2015年に登場したERPです。従来は任意のデータベースを選べましたが、S/4HANAはSAP HANA上でのみ動き、会計・販売・在庫といった基幹データをメモリ上で即時に処理します。得意先と仕入先はビジネスパートナーへ一本化され、画面もWebベースのFioriへ刷新されました。オンプレミス版は2年周期でリリースされ、各リリースに7年の標準保守が付きます。最新のS/4HANA 2025は2032年末までが標準保守の期間です。

導入形態はパブリッククラウド・プライベートクラウド・オンプレミスの3通りです。標準機能へ寄せるパブリック版はGROW with SAP、作り込みを残せるプライベート版はRISE with SAPという枠組みに対応します。ECCからの移行は単純な入れ替えではなく、Brownfield・Greenfield・Bluefieldの3方式から自社のアドオン量に応じて選ぶ形です。そのアドオン量は勘で語らず、Simplification Item-CheckとABAP Test Cockpitを現行ECC上で回して本数で出せます。ECC 6.0の標準保守は2027年末で切れ、延長保守を選んでも2030年末が終点です。移行に1〜2年かかる規模を逆算すると、決定を先送りできる余地は狭まっています。

SAP S/4HANAという製品の定義とHANAを基盤に据えた仕組み

まず「S/4HANAが何者か」を名称と基盤技術から押さえます。ここを曖昧にすると、単なるバージョンアップと取り違えます。

名称が示すSimple・第4世代・HANA基盤という三つの由来

S/4HANAの正式名称は「SAP Business Suite 4 (generation) for SAP HANA」です。頭のSはSimple、4はビジネススイートとして第4世代であること、HANAは基盤となるデータベースを表します。ECC（SAP ERP 6.0）の後継として2015年に提供が始まった、SAPが主力に据える基幹システムそのものです。製品仕様や機能の一次情報はSAP Help PortalのSAP S/4HANA製品ドキュメントにリリース単位でまとまっています。ERPという枠組み自体は、ERPとは何か、基幹システムやCRMとの違いを解説した記事もあわせて確認してください。

SAP HANA専用のインメモリDBが生む即時処理と分析の中身

ECCではデータベースをOracleやDB2などから選べましたが、S/4HANAは基盤がSAP HANAに固定されます。HANAはデータを列方向に持つカラム型のインメモリデータベースで、集計や検索をディスクではなくメモリ上で処理する仕組みです。この構造により、ECCでは夜間バッチで回していたMRP（資材所要量計画）を日中にリアルタイムで実行できます。MRPの前段にあたる需要計画や供給計画をERPの外で立てる仕組みは、SAP IBPの機能構成と生産管理との分担を解説した記事で整理しています。会計伝票も、複数の集計テーブルに分散させず「Universal Journal（ACDOCA）」という単一の明細テーブルへ一元化し、月次締めを待たずに残高を参照できる設計へ変わりました。

Fiori画面とビジネスパートナー統合がもたらす操作性の変化

操作画面も刷新されています。従来のSAP GUIに加え、WebベースのSAP Fioriが標準の入り口になりました。Fioriはブラウザで動くため、専用クライアントを入れずにタブレットやスマートフォンからも操作できます。マスタ設計も変わり、ECCでは別々に管理していた得意先と仕入先が「ビジネスパートナー」という単一のオブジェクトへ統合されました。同じ取引先が販売と購買の両方に登場する場面で、二重登録や不整合を抑えられます。

二年周期のリリースと七年の標準保守が決めるS/4HANAの寿命

移行先の寿命を誤解したまま計画を立てる例が少なくありません。SAPは2022年9月のSAP News Centerでのリリース・保守戦略の発表で、オンプレミス版を2年周期のリリースへ切り替え、各リリースに7年の標準保守を付けると公表しました。この計算でいくと、2025年10月に提供が始まったS/4HANA 2025の標準保守は2032年末までです。さらに2040年まで常に少なくとも1つのリリースを保守下に置くと明言しており、移行後すぐ次の期限へ追われる構図にはなりません。リリースごとに載る新機能の性格は、SAPが組み込むAIアシスタントを解説したSAP Jouleの機能と料金を整理した記事でつかめます。

ECCと比べたSAP S/4HANAの機能とデータ構造の主な違い

差分を知らないまま計画すると、アドオンの改修範囲を見誤ります。

データベースとデータモデルの違いがECC移行作業に及ぼす影響

最大の差は、データベースの選択肢がSAP HANA一択に絞られた点です。ECC時代に別のDB前提で組んだアドオンやSQLは、HANA上での再検証が避けられません。加えて会計まわりのデータモデルがACDOCAへ一元化されたため、旧来の総勘定元帳（BSEG等）に直接アクセスしていたプログラムは、参照先の見直しが要ります。差分の全体像は次の比較で押さえられます。

比較軸	SAP ECC 6.0	SAP S/4HANA
データベース	任意のDBを選択可	SAP HANA専用
会計データ	集計テーブルへ分散	ACDOCAへ一元化
取引先マスタ	得意先と仕入先を分離	ビジネスパートナー統合
主な操作画面	SAP GUI	SAP Fiori
MRPの処理	夜間バッチが中心	日中リアルタイム
リリース周期	拡張パッケージで追加	2年ごとの定期リリース
標準保守の期限	2027年末（延長は2030年末）	2025版は2032年末まで

この表のうち移行工数に直結するのは上の2行です。DBとデータモデルの変更が、既存アドオンの改修量をほぼ決めます。自社のアドオンがどこまでこの差分に触れているかの棚卸しが、見積りの起点になります（2026年9月時点のSAP公表内容にもとづく整理）。

ECCから引き継げる部分と、作り直しが必要になる部分の線引き

標準機能の範囲で完結していた業務は、大きな作り替えなしに引き継ぎやすい領域です。一方、ECC固有のトランザクションコードに依存した独自プログラムや、集計テーブルへ直接読み書きするアドオンは、作り直しの対象になりやすい部分です。SAPは非互換の箇所を洗い出す「Simplification Item」の一覧をSimplification Item Catalogとして公開しており、これで改修対象を事前に特定できます。SAP公式の「Conversion Guide for SAP S/4HANA 2025」（文書バージョン2.0・2026年2月25日）でも、このカタログは変換プロジェクトの必須資材という位置づけです。同ガイドは前提条件も明示しており、変換対象はUnicode化済みかつAS ABAP単独のシステムに限られます。ABAPとJavaを同居させたデュアルスタック構成は変換できません。

パブリック・プライベート・オンプレという三つの導入形態と選び方

S/4HANAは動かす場所によって性格が異なる製品です。形態を取り違えると、想定した作り込みができない、運用負荷が下がらないといった食い違いが起きます。クラウド型ERP全般の分類と費用構造は、クラウドERPとオンプレミスの違いと種類を整理した記事が下敷きになります。

標準機能へ寄せるパブリッククラウド版とGROW with SAP

パブリッククラウド版は、SAPが用意した標準機能に業務を合わせて使う形態です。SAP自身がインフラとアップデートを管理し、原則としてアドオンによる深い作り込みはしません。新規導入や中堅企業向けには「GROW with SAP」という提供プログラムがあります。四半期ごとに新機能が自動で入る代わりに、独自要件は標準の拡張の枠内へ収める割り切りが前提です。営業、EC、問い合わせ対応などの顧客接点はS/4HANAの外側でSAP CXの製品群が受け持ち、在庫や価格、受注の状況を連携して参照する構成はSAP CXの製品構成とS/4HANA連携を解説した記事で確認できます。なお、子会社や小規模な拠点向けには、S/4HANAとは別系統の中小企業向けERPもあり、SAP Business Oneの機能・ライセンスとS/4HANAとの違いを解説した記事で線引きを整理しています。コアを標準に保ちつつ拡張を外側で組み合わせる考え方は、コンポーザブルERPとはで整理しています。

作り込みを残せるプライベートクラウド版とRISE with SAP

プライベートクラウド版は、自社専用の環境でS/4HANAを動かし、一定のアドオンやカスタマイズを残せる形態です。ECCで積み上げた作り込みを生かしたい企業に向きます。SAPはこの形態を含むクラウド移行を「RISE with SAP」という契約枠組みで提供し、インフラ・保守・移行支援を一括で束ねる仕組みです。契約に含まれる範囲とSAP・自社・パートナーの責任分界は、RISE with SAPの契約範囲・GROWとの違いと責任分界を解説した記事で整理しています。ERP製品全体の選定軸から比較したい場合は、Salesforce・SAP・Dynamicsの選定軸と導入の進め方を整理した記事が参考になります。

自社資産でインフラ運用を続けるオンプレミス版が向く企業の条件

オンプレミス版は、自社またはデータセンターのサーバー上でS/4HANAを運用する従来型の形態です。インフラとバージョンアップを自社で握れるため、外部に預けられないデータを扱う業種や、クラウドの共有更新サイクルに乗せにくい企業に向きます。最新のオンプレ版はS/4HANA 2025で、標準保守は2032年末までです。ただし運用・保守の責任を負うのは自社です。要員を確保できないままオンプレを選ぶと、次の保守切れで同じ問題を繰り返します。基幹システムをオンプレとクラウドのどちらで持つかは、オンプレミス型とクラウド型の導入形態の違いを比較した記事で選定ポイントごとに整理しています。

ECCからS/4HANAへ移す三つの移行方式と現実的な進め方の全体像

現行をそのまま引き継ぐか、この機に作り直すかで、期間もコストも変わります。移し替えという行為そのものの分類は、マイグレーションとリプレイス・モダナイゼーションの違いを解説した記事で整理できます。

現行を引き継ぐBrownfieldと作り直すGreenfieldの違い

移行方式は大きく2つの軸に分かれます。現行の設定・データ・アドオンを引き継いでS/4HANAへ変換するBrownfield（現行踏襲）と、業務プロセスをゼロから設計し直すGreenfield（新規構築）です。安定稼働していて変更を抑えたいならBrownfieldが工期を圧縮しやすく、長年の改修でアドオンが肥大化した環境なら、この機に不要な作り込みを削ぐGreenfieldが効きます。Brownfieldの実作業はSoftware Update Manager（SUM）が担い、HANA以外のDBで動く現行機は、SUMのデータベース移行オプション（DMO）でHANA移行と変換を同じ工程で処理します。判断の分かれ目は、現行の作り込みをどこまで資産と見なせるかです。

必要な部分だけ移すBluefieldとFit to Standardの考え方

2方式の中間として、移す範囲を選べるBluefield（選択的移行）があります。生かす部分だけを持ち込み、不要なデータやアドオンは切り捨てる進め方で、Brownfieldの安全性とGreenfieldの身軽さの折衷を狙います。いずれの方式でも根底にあるのが、独自要件をアドオンで作り込まず標準機能へ業務を寄せる「Fit to Standard」の発想です。進め方はFit to Standardとは何かを解説した記事で確認できます。標準で賄える業務は標準に寄せ、競争力に直結する部分だけを独自実装に絞る。この線引きが、移行後の保守性と総コストを左右します。

現行ECC上で移行前に回す必須チェックの工程とツールの使い分け

移行方式の議論が机上で止まるのは、改修対象の量が数字になっていないからです。SAPは現行ECC上で走らせる検査ツールを用意し、一部は必須工程に位置づけています。

Maintenance PlannerとSI-Checkを必須工程として回す順序

Conversion Guideは準備工程を順番に定義しています。最初がMaintenance Plannerで、コンポーネント・アドオン・ビジネスファンクションの互換性を判定し、SUMが読み込むスタックファイルを生成します。旧Maintenance Optimizerは使えません。次がSimplification Item-Check（SI-Check）です。SAPノート2399707がチェックレポート本体を、2502552がTCI（トランスポートベースの修正命令）経由でチェッククラスを配信します。SAP Readiness Checkと混同されがちですが、Readiness Checkは任意の自己サービス、SI-Checkは必須という違いがあります。

* 1. Maintenance Planner でスタックファイル（stack.xml）を生成する
*    互換性判定の対象: コンポーネント、アドオン、ビジネスファンクション
* 2. SAPノート 2187425 の手順で TCI を有効化する
*    NW 700 SP36 ／ 701 SP20 ／ 702 SP20 ／ 731 SP19 ／ 740 SP16 ／ 750 SP05 以降は有効化済み
* 3. SAPノート 2399707 と 2502552 を適用し SI-Check を導入する
* 4. トランザクション SA38 で次のレポートを起動する
REPORT /SDF/RC_START_CHECK.
*    Simplification Item Check Options で移行先バージョン（2025 など）を指定する
* 5. 結果一覧に出た SAPノートを1件ずつ確認し、対応要否と工数を割り付ける

この5工程は本番機ではなく、コピーした検証機で先に回します。結果一覧はSAPノート番号の羅列で返るため、1件ずつ読んで該当を判定してください。ここで出た件数が、移行方式の議論に持ち込める最初の実測値です。

ATCの検査バリアントでアドオンの改修量を数える手順と結果の読み方

アドオンの改修量は、ABAP Test Cockpit（ATC）で数えます。SAP公式の「Custom Code Migration Guide for SAP S/4HANA 2025」によれば、中央チェックシステムを1台立てれば、SAP_BASIS 7.00以降のABAPシステムをリモートで検査できます。検査の土台になるSimplification Databaseの取り込みに使うのは、トランザクションSYCMです。2025向けの検査バリアントはS4HANA_READINESS_2025とS4HANA_READINESS_2025_NO_FLEの2種類です。前者は品目コード40桁と拡張金額項目を有効にした設定、後者は18桁で拡張項目を無効にした設定で、どちらを選ぶかで検出件数が変わります。

結果はATCの指摘一覧として返り、各指摘は対応方法を書いたSAPノートに紐づきます。Eclipse用のABAP Development Toolsで実行すると、指摘の一部はQuick Fixによる半自動的な修正が可能です。Custom Code Migrationアプリのスコーピング機能を使えば、使われていないプログラムを対象から外せます。ABAPという言語の特性と2027年問題への備えは、ABAPとは何かを実装目線で解説した記事で背景まで追えます。「アドオンが多い」を「ATCの指摘が何件で、うちQuick Fix対応が何件」という数字に置き換える。ここまで来て、初めてBrownfieldとGreenfieldの比較が成立します。

S/4HANA移行で自社が最初に決めるべき論点と着手時期の判断

ここからは「どこから決めるべきか」を条件付きで言い切ります。順番を誤ると、後工程で手戻りが生じます。

現行アドオンの棚卸しが移行方式と費用を左右する最初の判断の軸

最初に決めるべきは、移行方式でも導入形態でもなく、現行アドオンの棚卸しです。アドオンが少なく標準機能中心で回っている企業は、Brownfieldでもパブリッククラウドでも選択肢が広く、費用も抑えやすくなります。逆にECC固有の作り込みが数百本の規模なら、全部持ち込んだ移行費用は膨張し、次の保守切れで同じ問題を再生産します。まず「捨てられるアドオンはどれか」を洗い出す。棚卸しを省いた結果どこで破綻するかは、ERP導入の失敗事例を判例と開示資料から分解した記事に実例が並んでいます。

パブリッククラウド版を見送るべき場面と標準化の割り切りの判断

導入形態は、標準機能へどこまで寄せられるかで決まります。業務を標準に合わせられる企業はパブリッククラウド版が費用と運用の両面で有利ですが、SAPでしか回らない独自プロセスが業務の中核に残るなら、パブリック版は向きません。この場合は無理に標準へ寄せず、プライベートクラウド版で作り込みを残す判断が現実的です。逆に、独自プロセスが過去の惰性で残っているだけなら、この移行を機に手放すほうが長期の保守コストは下がります。

延長保守の二ポイント上乗せから見積もる延命の費用と現実的な期限

延命を検討するなら、その値札を先に把握します。SAPの保守戦略ページ（SAP S/4HANA and SAP Business Suite 7）は、Business Suite 7のコアアプリケーションの標準保守を2027年末まで、任意の延長保守を2030年末までと定めています。対象は最新3世代の拡張パッケージに限られ、延長保守を選んだ場合の保守料は、算定基礎に2ポイントぶんを上乗せする計算です。延長保守を選ばない企業と2030年末を過ぎた企業には、カスタマー固有保守が適用されます。3年の延命に上乗せ費用を払い、その間も新機能は止まる。延命が合理的になるのは、3年以内に別のERPへ乗り換える計画が具体的に決まっている場合に限られます。

ECC保守が切れる2027年末から逆算する現実的な着手時期の判断

着手時期は、ECC 6.0の標準保守が2027年末で切れる事実から逆算します。延長保守に入れば2030年末まで公式サポートは続きますが、移行そのものには要件定義から本番稼働まで1〜2年規模の期間がかかります。延長保守に入る企業でも2028年前後には着手しておく計画が妥当です。保守終了の全体像と、移行・延命・乗り換えを含む選択肢の判断基準は、SAPの2027年問題を整理した記事で確認できる内容です。外部ベンダーへ委ねるなら、現行情報の開示範囲と移行要件の書き方で見積り精度が変わるため、システム刷新のRFPの書き方を解説した記事を先に読んでおくと発注時の手戻りを減らせます。棚卸しや方式選定を外部と組んで進めるなら、SAPコンサルティング/導入支援サービスのように要件整理から移行方式の決定まで伴走できる体制を早めに確保すると、SAP技術者の逼迫による着手遅れを避けられます。

よくある質問

SAP S/4HANAについて、移行検討の現場で挙がりやすい疑問に答えます。

S/4HANAとECCの一番大きな違いは何ですか？

基盤データベースがSAP HANAに固定された点です。会計データもACDOCAという単一テーブルへ一元化されました。日中のリアルタイム処理が可能になった一方、旧DBやテーブルに直接依存したアドオンは再検証が要ります。画面のFiori化と、得意先・仕入先のビジネスパートナー統合も実務上の差です。

S/4HANAはいつまでサポートされますか？

SAPは、少なくとも1つのS/4HANAリリースを2040年末まで保守下に置く方針を示しています。オンプレミス版のリリースは2年ごとに更新され、各リリースに7年間の標準保守が付きます。2025年10月に提供が始まったS/4HANA 2025は、標準保守が2032年末までです。ECCの2027年末とは違い、移行後すぐ次の保守切れへ怯える必要はありません。

パブリッククラウド版とプライベートクラウド版はどう違いますか？

パブリッククラウド版は標準機能へ業務を合わせて使う形態で、GROW with SAPとして提供され、深い作り込みは想定しません。プライベートクラウド版は自社専用環境で一定のカスタマイズを残せる形態で、RISE with SAPの枠組みで提供されます。ECCの作り込みを生かしたい企業はプライベート版、運用を軽くしたい企業はパブリック版が向きます。

ECCからの移行にはどれくらいの期間がかかりますか？

要件定義から本番稼働まで、一般に1〜2年規模を見込みます。期間は現行アドオンの量と移行方式で変わり、現行踏襲のBrownfieldは工期を圧縮しやすく、新規構築のGreenfieldは初期負荷が高い代わりに移行後の保守性を高めやすい傾向があります。精度を上げるには、SI-CheckとATCを検証機で先に回し、指摘件数を数えてから工数へ換算してください。

S/4HANAへ移行せず他社ERPへ乗り換える選択肢はありますか？

現行の作り込みが浅く業務を標準機能へ寄せられる企業なら、他社ERPやクラウドERPへの乗り換えも合理的な選択肢です。SAP固有のアドオンに縛られない分、運用負荷を抑えやすくなります。一方でSAP前提の独自プロセスが中核に多く残る場合は、乗り換えのほうが再構築の負担は大きくなります。延長保守の期限である2030年末までに移行先を稼働させられるかが、現実的な足切り線です。