SAP が他の ERP と違う3つの理由 — HANA・Universal Journal・MANDT

Posted at 2026-08-05

はじめに

筆者は Java と Spring で業務システムを書いてきた人間で、SAP は長らく「名前は知っているが中身は知らない」対象でした。SIer にいれば「SAP 連携」という要件は降ってきますし、転職市場では SAP 技術者の需要が高い、という話も聞きます。実際に現在進行形でSAPの設計に携わっていて、知らないことばかりでした。それでも中身の話になると、出てくるのは製品名と略号ばかりで、技術的に何がどう違うのかが見えてきませんでした。

そこで一次情報を当たり、実際に動かせるものは動かして、Web 開発の語彙に翻訳する作業をしました。この記事その記録で、何回かSAPについての記事を掲載します。

前提知識

RDB の基礎（テーブル、インデックス、集計）があれば読めます。SAP の知識は不要です。

本記事の記述は SAP 公式（support.sap.com / news.sap.com / sap.com / learning.sap.com）を筆者が直接確認して書いています。日本語訳は筆者によるものです。

背景：なぜ SAP は「わからない」のか

SAP について調べ始めて最初に困るのが、技術の話にたどり着けないことでした。

検索して出てくるのは導入事例、コンサルの売り込み、資格の話、そして「2027年問題」。製品名は S/4HANA、ECC、BTP、RISE、GROW と次々出てくるのに、それぞれが何なのかを技術的に説明した日本語の情報は多くありません。

理由の一つは、SAP の一次情報が機械的に読みにくいことです。help.sap.com も community.sap.com も www.sap.com も、通常のフェッチツールからは取得できません（robots.txt や 403）。

今回の調査では、代わりに2つの入口を使いました。SAP 公式の GitHub 組織（SAP-docs）に Markdown ソースが公開されていること、そして learning.sap.com が制限を受けないこと。この2つを一次ソースにしています。

もう一つは、「ERP」という言葉が技術を隠してしまうことです。ERP は業務パッケージの分類名であって、アーキテクチャの名前ではありません。SAP が他と何が違うのかは、業務の話ではなくデータモデルとプラットフォームの話をしないと出てきません。

この記事ではその部分だけを扱います。

1. まず時計を見る：2027 / 2030 / 2040

先ほど「2027年問題ばかり出てくる」と書いた直後で恐縮ですが、この数字は移行の是非ではなく技術的な意思決定の締切として効いてきます。ここだけ正確に押さえて先へ進みます。

SAP の公式メンテナンス戦略ページによれば、次のとおりです。

対象	期間
SAP Business Suite 7（ECC を含む）のメインストリーム保守	2027-12-31 まで
延長保守	2028-01-01 〜 2030-12-31
延長保守の追加料金	保守基準額の +2パーセントポイント
2031年以降	標準サポートではなく顧客固有保守へ

この方針が公表されたのは 2020-02-04 です。

一方、移行先の S/4HANA についてはこう明記されています。

2040年まで、常に少なくとも1つの S/4HANA リリースが保守下にある

つまり「2027年に一斉に何かが止まる」わけではありません。実際には、2027年末に ECC のメインストリーム保守が切れ、2030年末に延長保守も終わります。そして移行先の S/4HANA には、2040年までのコミットがあります。

リリースサイクル

S/4HANA のリリース戦略は 2022-09-15 に改定されました。

S/4HANA 2023 以降は2年周期のリリース
1リリースあたり7年のメインストリーム保守（従来の5年から延長）

クラウド版（Public Edition）は別のリズムです。

年2回（2月・8月）のメジャーリリース
採番は 2408.2 のように「西暦下2桁＋リリース月＋機能提供番号」
3システムランドスケープでは、通知の6週間後にテスト系、その3週間後に開発系と本番系がアップグレード
アップグレードは SAP が自動適用

年2回のアップグレードが自動で降ってくる、というのはオンプレの ERP しか知らないと驚く点です。これが後の回で扱う「Clean Core（コアを汚さない拡張）」という原則の背景になります。勝手にアップグレードされるので、標準を書き換えていると壊れるわけです。

RISE と GROW

製品名で混乱しやすい2つも整理しておきます。

名称	中核製品	対象
RISE with SAP	SAP Cloud ERP Private Edition（旧称 S/4HANA Cloud Private Edition）	既存の SAP ERP 顧客。ECC / オンプレ S/4HANA からの移行
GROW with SAP	SAP Cloud ERP Public Edition（旧称 S/4HANA Cloud Public Edition）	新規・グリーンフィールド専用。「稼働まで最短4週間」

RISE はグリーンフィールド（新規構築）／ブラウンフィールド（システムコンバージョン）／2層 ERP のいずれも許容します。GROW はグリーンフィールド専用です。

なお ECC の資産を延命するために使われてきた Compatibility Packs は、利用権が 2025-12-31 から 2026-05-31 へ最終延長されました（2025年12月の発表）。

2. HANA が変えたこと：集計テーブルを捨てる

ここからが技術の話です。

SAP HANA は列指向を既定とするインメモリ DB で（行ストアも併用できます）、データを DRAM 上に保持し、CPU アクセスに最適な形で配置します。分析クエリが表の一部の列しか要求しないことに最適化した設計で、トランザクション処理と分析処理の双方を同一基盤で扱います。なお永続化はディスク上のデータボリュームとログボリュームに対して行われるので、メモリ上のデータが揮発しても復旧できます。

ここまでは「速いDB」の話です。決定的なのは、その帰結として書かれている次の一文でした。

SAP HANA は合計値、インデックス、マテリアライズドビュー、集計を必要としない。これによりデータベースフットプリントが削減される。すべては主記憶上でオンデマンドに計算される。

これが、SAP が他の ERP と違う理由の中核だと筆者は考えています。

なぜこれが効くのか

従来の ERP は「集計テーブル」を大量に持っていました。月次の売上合計、部門別の原価集計、勘定科目別の残高。これらをあらかじめ計算してテーブルに書き込んでおく設計です。

理由は単純で、ディスクベースの RDB では明細から都度集計すると遅すぎるからです。しかしこの設計には代償があります。

明細を1件登録するたびに、関連する集計テーブルを全部更新する必要がある
集計テーブルと明細の整合性が崩れるリスクが常にある
集計の切り口を増やしたければ、テーブルを増やすしかない
更新のロック競合が起きやすく、並行性が下がる

インメモリで都度計算できるなら、これらは全部不要になります。インメモリ性能が本当に効くのは、個々のクエリが速くなることより「集計テーブルを持たなくてよくなる」ことのほうです。効いているのは速度そのものではなく、速度が買ってくれるデータモデル設計の自由度です。

Web 開発の文脈で言えば、CQRS のリードモデルを永続化せず、書き込みモデル上のビューとして都度組み立てる判断に近いです。実際 S/4HANA では CDS View 群（Virtual Data Model）が読み取り側のモデルを担っており、モデルが無いのではなく実体化されていないという形になっています。成立するかどうかがインフラ性能に依存する点も、リードモデルを非正規化して持つかどうかの判断と同じ構造です。

3. Universal Journal — 財務を1つのテーブルに畳む

この「集計テーブルを捨てる」を、SAP が財務会計で実行したのが Universal Journal（ACDOCA テーブル）です。公式の説明はこうです。

各転記は universal journal テーブル（ACDOCA）に明細を生成し、異なる財務コンポーネントで入力された全データを1つの構造にまとめる。

データモデルは大幅に単純化された。不要なテーブルとそのデータを失うことで、フットプリントを劇的に縮小した。

従来は、財務会計（FI）と管理会計（CO）と資産管理が別々のテーブル群を持ち、それぞれに集計テーブルを抱えていました。結果として同じ取引が複数の場所に書かれ、突き合わせが必要になります。月次で「FI と CO が合わない」という照合作業が発生する、という話は SAP に限らず会計システムの定番です。

Universal Journal はそれを1つのテーブルに畳みました。照合が不要になるのは、同じ行を見ているからです。

注記: ACDOCA が具体的にどのテーブル群を置き換えたか（BSEG のインデックステーブル、GLT0 など）は、SAP の Simplification List / Simplification Item に個別項目として整理されている領域です。ただし筆者が一次ソースで各項目を確認できていないため、本記事では「単一テーブル化された」という事実までに留めます。

ただし「集計が消えた」わけではない

念のため補足します。これは「あらゆる集計を持たなくてよい」という意味ではありません。実際、S/4HANA の在庫管理では明細テーブル MATDOC に対して MATDOC_EXTRACT という圧縮済みの集約テーブルが併存します。都度計算のコストは明細件数に比例するため、大量データでは事前集約がやはり必要になるからです。

「集計テーブルを設計の前提にしなくてよくなった」であって「集計が消えた」ではない、というのが実態です。

4. 「クライアント」— SaaS より先にあった行レベルのマルチテナンシー

SAP を触ると必ず出てくるのが クライアント（Mandant） という概念です。ログイン画面で3桁の数字を入力する、あれです。

公式の定義はこうです。

クライアントは「法的・組織的に独立した単位」
全業務データが他のクライアントから保護される
3桁の数値で識別される
同一のデータベースを共有しつつ、WHERE 句の MANDT 項目でデータを分離する
カスタマイジング／アプリケーションデータ／ユーザーマスタがクライアント依存

最後の2つが技術的に重要です。マルチテナンシーを、DB のスキーマ分離でもインスタンス分離でもなく、クライアント依存テーブルの先頭に付いた MANDT という列で実現しているわけです（プログラムなどクライアント非依存のオブジェクトにはこの列がありません。後述します）。

なお、ここでいうクライアントは SaaS の「テナント＝契約顧客」とは用途が違います。実務では同一システム内で本番・検証・研修用のデータ空間を分けるのに使われ、複数の法人を表現するのは次章の会社コードの役割です。仕組みは行レベルのマルチテナンシー、使われ方は環境とデータ空間の分離、と分けて捉えると混乱しません。

Web 開発でマルチテナント SaaS を作るとき、テナント分離の方式は概ね次の3つから選びます。

方式	分離の粒度
データベース分離	テナントごとに DB インスタンス
スキーマ分離	同一 DB 内でスキーマを分ける
行レベル分離	同一テーブルにテナント ID 列を持つ

SAP は3番目です。しかもアプリケーション層で徹底されているため、開発者が MANDT を意識してクエリを書くことは基本的にありません。**ABAP SQL（旧称 Open SQL）**が、クライアント依存テーブルへのアクセスに MANDT の条件を自動で付与します。

これがどれだけ徹底されているかというと、開発オブジェクトそのものもこの世界観の中にあります。カスタマイジング（設定値）はクライアント依存で、プログラムコードはクライアント非依存です。同じシステムの中で、設定は本番／検証で分けられ、コードは共有されます。

「全テーブルにテナント列を持つ設計」自体は、Salesforce の OrgId など SaaS では珍しくありません。SAP が独特なのは、それを業務パッケージの標準として最初から組み込み、設定値と開発オブジェクトの管理まで同じ軸に載せきっている点です。しかも R/3（1992年）から30年以上、この構造で動き続けています。ここは素直にすごいと思いました。

5. 組織構造 — クライアントの下に何があるか

クライアントの下の階層も押さえておきます。SAP の設定を読むときに必須の語彙です。

クライアント（Client / Mandant）          ← 最上位。法的・組織的に独立した単位
  ├─ 会社コード（Company Code）          ← 独立した法的会計主体。4桁英数。FI の最小必須単位
  ├─ 事業領域（Business Area）           ← 会社コードを横断する内部報告単位
  └─ 管理領域（Controlling Area）        ← 原価と収益を管理・配賦する自己完結した組織
       ├─ 会社コードを 1:n で割り当てる
       ├─ 利益センタ（Profit Center）
       └─ セグメント（Segment）          ← 利益センタから導出

事業領域はクライアントレベルの組織単位で、複数の会社コードを横断します。利益センタは管理領域に属する管理会計上のオブジェクトで、会社コードの下にぶら下がるわけではありません。ここは最初に間違えやすいところです。

公式の定義を引くと、

会社コードは「企業グループ内で独立した勘定を持つ、独立した法的会計主体」であり、財務会計における最小の必須構造（4桁の英数キー）
管理領域は「原価と収益を管理・配賦できる、自己完結した組織構造」

グローバル企業なら、1つのクライアントの下に国ごとの会社コードが並び、それらを横断する管理領域が置かれる構成になります。

注記: 本記事で一次ソースを確認できたのは、FI（財務会計）と CO（管理会計）の組織単位の定義です。MM（資材管理）／SD（販売管理）／PP（生産計画）といった他モジュールの組織単位は本記事では扱いません。

まとめ

SAP が他の ERP と違う技術的な理由を、この記事では3つ挙げました。

HANA を前提に、集計テーブル・インデックス・マテリアライズドビューを構造的に不要にした。「すべては主記憶上でオンデマンドに計算される」という設計判断が、データモデルの自由度を変えた
その帰結として、財務データを Universal Journal（ACDOCA）という単一テーブルに畳んだ。照合作業が不要なのは、同じ行を見ているから
マルチテナンシーを MANDT という行レベルの分離で実装し、R/3（1992年）から30年以上運用している。アプリケーション層で徹底されているため、開発者は意識しない
加えて、クライアントの下の会社コード／管理領域という語彙を押さえておくと、SAP の設定画面が読めるようになります

そして時計の話。ECC のメインストリーム保守は 2027-12-31、延長保守は 2030-12-31 まで。S/4HANA は 2040年までのコミット。 Public Edition は年2回のアップグレードが自動で降ってきます。

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up