Private Cloud経験者が知るべき構造的差異・制約・設定の真実
2026年6月
SAP S/4HANA Cloud Public Edition（以下、Public Edition / PE）は「SAPの最新クラウドERP」として紹介されますが、S/4HANA Private Cloud（オンプレミスまたは専有クラウド）を長年構築してきた技術者・コンサルタントにとって、最初に直面する壁は「同じSAPなのに、なぜこんなに違うのか」という困惑です。
本稿はその困惑を解消するために書かれています。概要説明は最小限にとどめ、「テーブル構造・カスタマイズ可否・データモデルの差異・トランザクションの制約・技術的な設定の違い」というPrivate Cloud経験者が即座に実務判断に使える情報に集中して解説します。
結論を先に言えば、Public Editionは「SAP標準プロセスをFit-to-Standardで使うことを前提に設計されたSaaS」であり、Private Cloudで当然のように行ってきたABAPカスタマイズ・テーブル直接参照・Customizing自由設定の大半が封印されています。この制約の境界線を正確に把握することが、Public Edition導入成否の分岐点です。
Private Cloudでは「一つのSAPシステム（ABAP Application Server）を一社が専有」します。DBスキーマも一社専用であり、ABAP開発・テーブル変更・Customizing変更は自由度が高い状態です。
Public Editionは「一つのSAPシステムを複数企業（テナント）が共有するマルチテナントSaaS」です。SAP社がシステムインフラ・ABAPコア・アップグレードを一元管理しており、テナントごとのコード変更やDB直接操作は原則不可能です。
コードライン（Code Line）：Public Editionでは全テナントが同一のABAPコード（標準コード）を共有します。SAPが年4回（四半期ごと）の強制アップグレードを実施します。
テナント分離：テナントごとにクライアント（Client）が分離されています。Private Cloudと同じ「クライアント」の概念ですが、DB物理層は共有インフラです。
カスタマイズの範囲：「Configuration（IMG設定）」のうちSAPが許可した設定項目のみが変更可能です。許可されていないIMG項目はそもそも表示されません。
Private Cloudでは開発（DEV）・品質保証（QAS）・本番（PRD）の3システム以外に、サンドボックス・トレーニングシステム等を自由に追加できます。Public Editionでは以下の構成が標準として提供されます。
Starter System（スターターシステム）：導入プロジェクト初期のFit-to-Standardワークショップ用。SAP標準プロセスの確認に使用。Configurationは永続しません。
Quality System（品質保証システム）：テスト・ユーザー受入試験（UAT）用。
Production System（本番システム）：本稼働システム。
開発システム（DEV）が存在しないことがPrivate Cloud経験者には最大の驚きです。ABAPカスタム開発の場となる「開発システム」がなく、代わりにBTP上のABAP Environment（ABAPクラウド）が拡張開発の場となります。Transport Requestによるコード昇格（DEV→QAS→PRD）という従来のABAPトランスポート体制は存在しません。
Private Cloudの技術者が最初に知るべき最重要事実：Public EditionではSAPコア（Standard Code）へのABAPカスタマイズ（ユーザー出口・BAdI実装・Enhancement Spot・Function Moduleの変更・標準テーブルへの直接書き込み）は一切不可能です。
ユーザー出口（User Exit）：Private Cloudでは多用されるUSER_EXIT_*・EXIT_*形式のExit。Public Editionでは提供されていません。
クラシックBAdI：Private Cloudで使用してきた「クラシックBAdI（SE18のインターフェース実装）」は使用不可。一部の機能はKey User Extensibilityで代替可能ですが、全対応ではありません。
ABAP Dictionary変更（SE11）：標準テーブルへのフィールド追加・新規テーブル作成は不可。カスタムテーブル（ZテーブルをSE11で作成する従来方式）も不可。
SE80（ABAPワークベンチ）：SE80は存在しますが、標準オブジェクトへの変更保存はエラーになります。閲覧のみ可能。
Public Editionの拡張は二つの公式チャネルに限定されます。
ABAPコーディングなしに、ビジネスユーザー（キーユーザー）がFiori UI上で設定できる拡張。
カスタムフィールド（Custom Fields and Logic）：標準オブジェクト（販売伝票・購買発注・取引先等）への追加フィールド定義。Fioriアプリ「Custom Fields and Logic（F3484）」で定義します。追加したフィールドはSAPが管理するExtension Tableに格納されます（標準テーブルは変更しない）。
カスタムロジック（Business Logic）：「Custom Fields and Logic」アプリで「ビジネスロジック（BAdI）」の実装をFiori上のABAPエディタで記述できます。ただし使用できるABAPはABAPクラウド準拠（Released APIのみ）に制限されます。
カスタムCDSビュー（Custom CDS Views）：既存CDS ViewにカスタムフィールドをExtensionとして追加できます。レポート・分析への活用が目的です。
ページレイアウト変更（Page Layout）：Fioriアプリの画面レイアウト（フィールドの表示/非表示・必須化・グループ化）をノーコードで変更できます。
BTP上のABAP Environment・CAP・Build Appsを使用したSide-by-Side拡張。Public Editionのコアには触れず、BTP側でカスタムアプリを開発してPublic Edition APIを呼び出す方式です。
Released OData API（SAP API Business Hub）：Public EditionはSAP標準OData APIを通じてのみ外部システムからのデータ操作を受け付けます。Released APIに含まれない操作（特定の業務ロジック・特定テーブルへの直接アクセス等）はAPI経由でも実行できません。
RAP（Restful ABAP Programming Model）：BTP ABAP Environmentで開発したRAPベースのカスタムアプリがPublic EditionのAPIを呼び出す構成。
S/4HANAのUniversal Journal（テーブルACDOCA）はPublic EditionとPrivate Cloudで共通の中核データモデルです。FI・CO・ML（Material Ledger）のすべての仕訳データがACDOCAの単一テーブルに格納されるアーキテクチャはPublic Editionでも同一です。
ただしACDOCAのテーブル構造に関して以下の差異があります。
カスタム拡張フィールド：Private Cloudでは「ACDOCA-ZZFIELD」のようなZフィールドをSE11でACDOCAに直接追加できます。Public Editionでは直接追加は不可で、Extension Table（ACDOCA_E等の拡張テーブル）にKey User拡張フィールドが格納されます。レポート・CDS Viewではこの拡張テーブルをJOINして参照します。
テーブル参照の方法：Public Editionでは標準テーブルへのSELECT文による直接参照（ABAP Open SQL）を独自ABAPから実行することはできません。データアクセスはCDS View・Released APIを通じた参照が原則です。
Private CloudではZテーブル（SE11で定義する任意のカスタムデータテーブル）を自由に作成できます。Public Editionではこの方法は存在せず、カスタムデータの格納には以下の代替手段を使用します。
Key User Custom Objects（Custom Business Objects：CBO）：Fioriアプリ「Custom Business Objects」でカスタムデータオブジェクト（テーブルに相当）をノーコードで定義します。フィールド・キー構造・関係性（標準オブジェクトとのリンク）を定義でき、自動生成されたFiori画面でデータ管理ができます。ただしZテーブルほどの自由度（JOINの柔軟性・インデックス定義・バルクデータ処理性能）はありません。
HANA Cloud（BTP）でのカスタムデータ管理：大規模カスタムデータはBTP上のHANA CloudにCAPアプリを経由して格納し、Public Editionとの連携はAPIで行う方法が実践的です。
Private Cloudで日常的に参照していた重要テーブルについて、Public Editionでの参照方法の変化を整理します。
MARA/MARC/MARD（品目マスタ）：直接SELECTは不可。CDS View「I_Material」「I_MaterialPlant」「I_MaterialStock」等の公開CDS Viewを通じて参照します。Released OData API「API_MATERIAL_DOCUMENT_SRV」「API_PRODUCT_SRV」等でのアクセスが標準。
KNA1/KNB1（得意先マスタ）：CDS View「I_Customer」「I_CustomerCompanyCode」を通じて参照。OData API「API_BUSINESS_PARTNER」が標準連携API。
LFA1/LFB1（仕入先マスタ）：ビジネスパートナー（BP）統合モデルに一本化。CDS View「I_Supplier」「I_SupplierCompanyCode」を使用。
VBAK/VBAP（受注ヘッダ/明細）：CDS View「I_SalesOrder」「I_SalesOrderItem」を使用。OData API「API_SALES_ORDER_SRV」でCRUD操作。
EKKO/EKPO（購買発注ヘッダ/明細）：CDS View「I_PurchaseOrder」「I_PurchaseOrderItem」を使用。OData API「API_PURCHASEORDER_PROCESS_SRV」。
BSEG（FI明細テーブル）：S/4HANAではBSEGは互換ビューとして残存。Public Editionでも参照可能ですが、パフォーマンス上はACDOCAをCDS View経由で参照することが推奨されます。
T001/T001L（会社コード/保管場所）：これらの設定テーブルはCustomizing設定として参照可能。ただしZABAPからのSELECTは不可。
Private CloudではSPRO（IMG：Implementation Guide）から全Customizing設定に自由にアクセスできます。Public EditionではSPROは存在しますが、表示されるCustomizing項目がSAPによって厳選された「許可済み設定（Allowed Customizing）」のみに制限されています。
許可されていないIMG項目はそもそもSPROのツリーに表示されません。「あの設定項目がない」という体験がPrivate Cloud経験者に頻繁に生じます。
設定可能：会社コード定義・会計年度バリアント・転記期間バリアント・勘定科目コード表（勘定科目の追加・変更）・支払条件・Dunning（督促）設定・税コード定義（限定的）・銀行マスタ基本設定。
設定不可/制限あり：会計仕訳タイプ（Document Type）の新規作成（標準タイプのみ使用・カスタムタイプ追加は不可）・カスタム転記キー（Posting Key）の追加・Financial Closing Cockpit（FCC）の詳細カスタマイズ・カスタム割り当てルール（Account Determination）の高度な変更。
設定可能：販売組織・流通チャネル・製品階層の基本定義・受注タイプ（Order Type）は標準タイプの設定変更（一部）・出荷タイプの基本設定・請求タイプの基本設定・価格手続き（Pricing Procedure）のカスタム追加・条件タイプの追加（一定範囲内）。
設定不可/制限あり：新規受注タイプ（Sales Document Type）の自由な追加（SAP標準タイプ以外は原則不可）・カスタム出荷スプリットルール・出力管理（Output Management）のアクション設定は新方式（BRF+/Form Template）に移行・Availability Check設定の詳細変更。
設定可能：購買組織・購買グループ・資材タイプ（Material Type）の一部設定変更・移動タイプ（Movement Type）の基本設定・仕入先評価基準（一部）・評価クラス（Valuation Class）の追加（限定的）・MRPタイプの基本設定。
設定不可/制限あり：カスタム移動タイプ（Zxxx形式の新規Movement Type）の追加は不可・ユーザー定義の在庫タイプ追加・MRP計算のカスタムアルゴリズム・購買情報レコード自動更新ルールの詳細変更。
設定可能：プラント定義・作業スケジューリングのパラメータ・MRPパラメータ（再発注点・ロットサイズ）・ワークセンタカテゴリの基本設定・生産バージョンの設定。
設定不可/制限あり：カスタム生産指図タイプの自由な追加・Shop Floor Controlのカスタムステータス追加・カスタムMRP計算ルーティンの組み込みは不可。
設定可能：原価センタ階層・利益センタ階層・内部指図タイプ（一部標準）・原価要素（Primary/Secondary Cost Elements）・活動タイプ定義・WBSエレメント設定（PS）。
設定不可/制限あり：カスタム原価計算バリアント（Costing Variant）の詳細カスタマイズ・カスタム勘定決定（Account Determination）の変更・CO-PA特性の自由な追加（一定の上限と承認プロセスが必要）。
Public EditionのCustomizing設定の主要インターフェースは「Manage Your Solution（F2700）」Fioriアプリです。Private CloudのSPROに対応しますが、表示される設定項目はPublic Edition用に絞り込まれています。
設定変更の手順：「Manage Your Solution」→「Configure Your Solution」→業務領域を選択→Activity（設定項目）を選択→設定画面を開いて変更。
変更の反映：Public EditionのCustomizing変更は「Change Request（変更依頼）」を通じて本番システムに反映します。Private Cloudのトランスポートに相当しますが、SAPが変更の整合性を自動チェックした上で反映されます。
バックグラウンド設定（Background Job Scheduling）：バックグラウンドジョブ（SM36相当）は「Manage Scheduled Jobs（F2373）」Fioriアプリで管理します。SM36での直接ジョブ定義は不可。SAP標準のジョブテンプレートに基づいてスケジュールを設定します。
Public Editionでは業務処理の主要インターフェースはFioriに移行しています。SAP GUIは完全に廃止されたわけではありませんが、利用できるトランザクションコードが大幅に制限されています。
SE16N/SE16（テーブルブラウザ）：公開された範囲のテーブル・CDS Viewの参照のみ。更新は不可。Zテーブルは存在しないため対象は標準テーブル・CDS View。
AL11（ファイルシステム参照）：BTPのインフラ上ではファイルシステムへのアクセスは制限されます。ファイル連携はSFTP/API経由が原則。
SU01（ユーザー管理）：ユーザー作成・権限ロールの割り当ては可能。ただし認証はIAS（Identity Authentication Service）との連携が標準で、SU01だけでは完結しない場合があります。
SM30（テーブルメンテナンス）：許可されたCustomizingテーブルのみ変更可能。Zテーブルは存在しないためその用途では使用不可。
SE11（ABAP Dictionary）：標準テーブルの参照は可能。変更・新規作成は不可。
SE80（ABAPワークベンチ）・SE38（ABAPエディタ）：標準プログラムの閲覧のみ。変更・カスタムプログラム作成は不可。
SPRO（全体IMG）：Public Edition用に絞り込まれたIMGのみ表示。
SM36/SM37（バックグラウンドジョブ管理）：直接のジョブ定義は不可。Fiori「Manage Scheduled Jobs」を使用。
ST05（SQLトレース）・ST12（ABAP Trace）：パフォーマンス分析ツール。Public Editionでは標準ユーザーへのアクセスは制限されており、SAP支援チームが使用する管理者ツールの位置付け。
CMOD（拡張管理）・SE19（BAdI Builder）：カスタム実装のためのBAdI管理。Public Editionでは使用不可（Key User Extensibilityに置き換え）。
Private CloudのFiori LaunchpadではタイルのグループやカタログをSAP_UI_BC_MC（Fiori Launchpad Content Manager）等で自由にカスタマイズできます。Public Editionでは「Manage Launchpad Settings（Fiori）」でのカスタマイズが可能ですが、タイルのソースとなるビジネスカタログ（Business Catalog）の定義はSAP標準のみであり、カスタムビジネスカタログの追加は制限されています。カスタムFioriアプリのタイル追加はBTP上の「SAP Build Work Zone」経由で行います。
Private CloudではPFCG（プロファイルジェネレーター）でシングルロール・複合ロール・プロファイルを細かく定義します。Public Editionでは権限管理は「ビジネスロール（Business Role）」を中心とした方式に変化します。
ビジネスロール：SAP標準の業務役割（例：「Accounts Payable Accountant」「Warehouse Operator」）として定義されています。各ビジネスロールはビジネスカタログ（Business Catalog：Fioriアプリのセット）とアクセス制限（Restriction Type：組織値のフィルタ）の組み合わせで構成されます。
ビジネスロールのカスタマイズ：SAP標準ビジネスロールをコピーしてカスタムビジネスロールを作成できます。ビジネスカタログの追加・削除・Restriction Typeの値（会社コード・プラント・販売組織等）の設定が可能。
PFCG廃止ではない：PFCG自体は存在しますが、Public EditionではPFCGで直接ロールを作成してユーザーに割り当てる従来方式は推奨されません。ビジネスロール管理はFioriアプリ「Maintain Business Roles（F2700系）」が標準です。
Public Editionでは認証基盤として「SAP Identity Authentication Service（IAS）」との統合が前提です。Private Cloudではローカル認証（SU01のパスワード管理）が主流でしたが、Public Editionでは全ユーザーのID・認証をIASで管理し、SSOを実現します。
Active Directory（Azure AD / Entra ID）連携：企業のIdPとIASをSAML Federationで連携し、企業のADアカウントでPublic Editionにシングルサインオンします。
ローカルユーザー（SU01）の制限：テクニカルユーザー（バックグラウンドジョブ用・API連携用）は引き続きSU01で管理しますが、一般業務ユーザーのSU01ローカル管理は非推奨です。
Private CloudではNACHTEN（メッセージ）と呼ばれる出力管理フレームワーク（NAST・条件テーブルベース）で伝票印刷・EDI・メール送信を管理していました。Public Editionではこの方式は「レガシー出力管理」として位置付けられ、新方式への移行が必要です。
Business Rules Framework +（BRF+）：出力チャネル（印刷・EDI・メール・電子署名等）の決定ルールをBRF+で定義します。Private Cloudの条件テーブル（NAST）に相当しますが、UIがFiori化されより柔軟な条件定義が可能。
Form Templates（Adobe Forms / SAP Forms）：印刷帳票はAdobe Document Services（ADS）上のAdobe Formsで定義します。Private CloudのSAPscriptやSmartFormsは非推奨。既存SAPscript/SmartFormsからAdobe Formsへの移行が必要です。
「Maintain Output Channels」：Fioriアプリ「Maintain Output Channels（F2679）」で出力チャネルの設定を管理します。
出力管理の変更はプロジェクト工数として過小評価されがちです。既存の帳票（請求書・注文書・出荷指示書等）がSAPscript/SmartFormsで作成されている場合、Adobe Formsへの全面移行設計が必要であり、大規模な帳票カスタマイズを行っていた企業ほど影響が大きくなります。
Private CloudではIDoc（Intermediate Document）が「レガシーシステム・他SAP・EDI」との標準連携手段として広く使用されてきました。Public Editionでも技術的にはIDocを使用できますが、新規設計では「OData API / REST API経由の統合（SAP Integration Suite）」が推奨されます。
IDocから新方式への移行推奨：既存のIDoc連携をOData API + BTP Integration Suite（iFlow）に移行することを計画します。IDOCのサポートが終了するわけではありませんが、新機能・拡張はAPI方式に集中するためです。
RFC（Remote Function Call）：外部システムからのRFC呼び出しは原則不可。RFC代替としてReleased OData API・BAPIラッパーAPI（一部）を使用します。
Public Editionと外部システムのすべての連携は「BTP Integration Suite（Cloud Integration）のiFlow」を経由することがSAP推奨アーキテクチャです。直接DB接続・直接RFC接続は封鎖されているため、APIベース統合がデフォルトです。
Private Cloudで多用されていた「カスタムABAPプログラムによるバッチファイル連携（FTP→ABAP処理→DB書き込み）」パターンは、Public Editionでは「SFTPサーバー→iFlow（ファイル取得・変換）→OData API（Public Editionへのデータ投入）」パターンに置き換わります。
Private Cloudでは印刷はSAPspoolシステムとSAP Print Server（CUPS等）で管理します。Public Editionでは「Cloud Print Manager（Fiori）」または外部クラウド印刷サービス（SAP Document Management Service・Open Text等）との連携が必要です。社内プリンターへの直接印刷設定はPublic Editionでは追加設定が必要です。
Public Editionの最大の運用特性は「年4回の強制アップグレード（Quarterly Release）」です。SAPが自動的に全テナントのシステムを新バージョンに更新します。これはPrivate Cloudの「数年に一度の計画的なバージョンアップ」とは根本的に異なる運用要件です。
プレビューシステム（Preview System）：本番アップグレードの約3週間前に、同じ変更が品質保証システムに先行適用されます（Preview Period）。この期間に変更の影響確認・リグレッションテストを実施します。
変更内容の通知：SAPは「What's New Viewer」（help.sap.com）で各四半期リリースの変更内容（新機能・廃止機能・Customizing変更）を事前公開します。運用チームはこの通知を定期的に確認してアップグレードへの対応を計画する体制が必要です。
テスト自動化の必須性：四半期ごとにリグレッションテストを実施するには、手動テストだけでは工数が不足します。SAP Cloud ALM（Test Suites機能）または外部テスト自動化ツール（Tricentis tosca・Worksoft等）によるテスト自動化が実質的に必須です。
四半期リリースでは新機能追加と同時に「廃止予告（Deprecated）機能」が通知されます。廃止機能には「廃止予告期間（通常2年程度）」が設けられますが、廃止日以降は機能が無効化されます。
Private Cloud経験者が特に注意すべき廃止機能の例として、SAPscript/SmartForms・クラシックBAdI・NACHTENベースの出力管理等があります。これらは既にDeprecatedステータスとなっており、Public Edition導入時には新方式への移行設計が必須です。
SAP Cloud ALM（Application Lifecycle Management）はPublic Editionの実装・運用管理ツールです。Private Cloudで使用するSAP Solution Manager（SolMan）とは別製品で、BTPサービスとして提供されます。
実装管理（Implementation）：プロジェクト・フェーズ・タスク・フィットギャップ分析・テストケース管理をCloud ALMで実施します。
変更管理（Change Management）：Customizing変更の品質保証システムから本番への反映をCloud ALMの「Change and Transport Management」で管理します。
運用管理（Operations）：システムモニタリング・ジョブモニタリング・アラート管理をCloud ALMで実施します。Private CloudのSolMan Monitoring相当。
テスト管理（Test Suites）：リグレッションテスト・UATのテストケース管理・実行・結果記録をCloud ALMで管理します。
SolManからCloud ALMへの変化は管理ツールの移行だけでなく、プロセスと考え方の変化を伴います。SolManのカスタム設定・カスタムMonitoring設定はCloud ALMに持ち越せません。
①ABAPカスタマイズ棚卸：現行システムの全ABAPカスタマイズ（ユーザー出口・BAdI・ABAP Report・Zテーブル）を一覧化し、Public Editionでの代替手段（Key User拡張・BTP拡張・廃止・業務変更）を判定します。
②帳票棚卸：全SAPscript/SmartFormsをリストアップし、Adobe Forms移行スコープと工数を見積もります。帳票数が多い企業では最大工数項目になります。
③IDoc・RFC棚卸：全IF（インターフェース）一覧を作成し、OData API + iFlowへの移行設計を策定します。
④出力管理のNAST依存確認：NACHRICHTENSTEUERUNG（条件テーブルベース）の出力設定がどれだけあるかを確認し、BRF+方式への移行計画を立てます。
⑤Customizingギャップ分析：現行のCustomizing設定のうちPublic Editionで設定不可の項目を特定し、業務プロセス変更または代替策を検討します。
⑥ユーザー数・ライセンス：Public Editionはユーザー数ベースのライセンス（Named User）です。Private Cloudと異なりConcurrent Userではないためアクティブユーザー数の正確な見積もりが必要。
⑦テスト戦略：四半期アップグレード対応のテスト自動化戦略を初期設計から計画します。
⑧組織設計値（会社コード・プラント等）の引き継ぎ：既存の組織設計値をPublic Editionにセットアップする「マイグレーションワークシート（Migration Templates）」が提供されています。
⑨バックグラウンドジョブの移行：SM36のジョブ定義をFiori「Manage Scheduled Jobs」に移行します。カスタムABAPジョブは移行できないためBTP Process Automation等への代替が必要。
⑩データ移行ツール：Public EditionのデータマイグレーションはSAP標準の「Data Migration Cockpit（LTMC / LTMOM）」または「Data Migration to SAP S/4HANA Cloud」ツールを使用します。ただし対応するマイグレーションオブジェクトはPrivate Cloud版Data Migration Cockpitより少ない場合があります。対象データ・移行方法の検討が早期に必要です。
以上
12. 製造業向け機能比較：Private / Public 業務領域別差分
本章は、日本の製造業（特に個別受注生産・ETO型）を念頭に、Private EditionとPublic Editionの機能差を業務領域別に整理したものです。設計・生産計画・現場ロジスティクス・原価管理の各局面において「できること・できないこと」を明確に把握しておくことが、導入形態の選定において不可欠です。
12.1 設計・エンジニアリング領域（ECTR / PLM / PEO）
CADデータ（図面）からERPの製造BOM・現場作業指示までをどう繋ぐか。設計変更（ECO）の流れが現場にリアルタイムに届くかどうかで製品品質と手戻りコストに直結します。
| 業務要件・機能 | Private Edition（プライベート） | Public Edition（パブリック） |
|---|---|---|
| ECTRによるCAD直結 | 【可能】 各種3D CAD（SolidWorks等）とS/4HANAがダイレクトに通信し、品目マスタやEBOMを自動生成。 | 【不可・制限あり】 直接の密結合は不可。外部PLMからAPIやBTPを介してテキスト（BOMデータ）として非同期連携する。 |
| EBOM→MBOM変換 | 【可能（PEO）】 画面上で設計BOMと製造BOMの差分（構成・数量）を視覚的に比較しながら変換・同期できる。 | 【不可】 PEOがスコープ外のため、ERP内部での変換は不可。外部PLM側でMBOMまで作りきってからERPに流し込む必要がある。 |
| 図面・仕様書の添付（DMS） | 【可能（大容量対応）】 専用コンテンツサーバーに図面PDF等を格納し、各伝票に紐付け可能。 | 【制限あり】 コアの肥大化を防ぐため制限あり。BTPのオブジェクトストレージや外部ストレージ（SharePoint等）へのリンク管理が基本。 |
| 4M変更・電子作業手順 | 【可能（PEO）】 設計変更（ECO）に連動し、現場の3D図面付き電子手順書や工具・スキルの指定まで厳格に統制。 | 【不可】 標準の「工順（Routing）」のみ。テキストベースの簡易な作業指示に留まる。 |
12.2 プロジェクト・製番管理領域（PS / CO）
日本の個別受注生産（ETO）の核となる、手配・在庫・原価の「製番紐付け」に関する差分です。階層型の製番管理と製番別原価計算はPrivate Editionの最大の強みです。
| 業務要件・機能 | Private Edition（プライベート） | Public Edition（パブリック） |
|---|---|---|
| 階層型の製番管理 | 【可能（PS-WBS）】 親製番→子製番→孫手配といった、複雑なブレイクダウン構造をシステム内で完全に表現。 | 【不可】 製造業向けの階層型WBSは原則スコープ外。SD（受注伝票明細）単位のフラットな1階層管理（MTO）に制限される。 |
| プロジェクト在庫（製番別在庫） | 【可能】 「製番A-001専用の在庫」として、評価・非評価を含め完全に分離して管理。 | 【不可】 WBSに紐付いたプロジェクト在庫の管理は原則不可。受注伝票に紐付く「受注個別のセグメント在庫」のみ対応。 |
| 製番間の在庫融通（振替） | 【可能】 「製番Aの材料を急遽製番Bへ流用する」といった在庫の振替処理（伝票移動）が標準対応。 | 【不可】 受注個別在庫の他受注への流用や振替は、標準プロセス（Best Practices）上、著しく制限または考慮されていない。 |
| 製番別の実際原価計算 | 【可能】 WBSを原価コレクタとし、購買・製造の実績原価、共通費の配賦を集約し、着地原価を算出。 | 【制限あり】 サービス業向けの「プロジェクト原価管理」はあるが、製造業向けの実際原価・配賦ロジックは標準範囲では対応できない。 |
12.3 生産計画・詳細スケジューリング領域（PP / PP-DS）
有限能力（設備・人員の制約）を考慮したリアルな生産計画が組めるかどうかの差分です。PP-DSエンジンの有無がPrivateとPublicの最大の技術的分岐点となります。
| 業務要件・機能 | Private Edition（プライベート） | Public Edition（パブリック） |
|---|---|---|
| プロジェクトMRP（製番MRP） | 【可能】 WBS（製番）を起点にMRPを回し、「製番付きの購買依頼・製造指図」を全階層で一括生成（MD51等）。 | 【不可】 PS駆動のMRPは動かない。SD（受注伝票）を起点にした「受注個別MRP（MD50）」で代用する。 |
| 有限能力スケジューリング | 【可能（PP-DS）】 機械や金型のキャパ上限を認識し、分・秒単位での自動「山崩し」や段取り替え最適化が可能。 | 【不可】 PP-DSエンジンが非搭載。日次・週次ベースの「無限能力MRP（機械の空きを無視した山積み）」しかできない。 |
| シミュレーション（マルチシナリオ） | 【可能（PP-DS）】 「特急注文が入ったら既存計画にどう影響するか」をガントチャート上でシミュレーション。 | 【不可】 コアERP内での詳細なビジュアルシミュレーションは不可。大枠の需給調整は外部のSAP IBPで行う思想。 |
12.4 現場ロジスティクス・製造実行領域（EWM / MES / PM）
工場の倉庫・自動設備・製造ラインの動きをコントロールする実行系の差分です。EmbeddedとSide-by-Sideのアーキテクチャ方針の違いが如実に現れます。
| 業務要件・機能 | Private Edition（プライベート） | Public Edition（パブリック） |
|---|---|---|
| マテハン・自動倉庫直結（MFS） | 【可能（Embedded EWM）】 ERPの内部から直接、工場のクレーンやコンベア（PLC層）へ搬送指示の信号を送れる。 | 【不可】 Public内蔵の倉庫管理（ライト版）にはMFSがない。外部の個別WMSやマテハン制御システムと別途作り込む必要あり。 |
| 高度な倉庫実行（ウェーブ等） | 【可能（Embedded EWM）】 複数オーダーをまとめてピッキング（ウェーブ）、作業員の労務管理、動線最適化を内蔵。 | 【不可】 棚番管理やシンプルな入出庫実績のみ。高度なロジスティクス実行が必要なら外部の本格EWMと連携。 |
| クラウドMES連携（SAP DM） | 【可能】 S/4HANAから製造指図を送り、現場の実績（4M）を双方向でリアルタイム連携。 | 【可能・推奨】 PublicでMES領域を高度化する場合の「唯一の標準シナリオ」。ERP側が軽い分、この連携が必須となる。 |
| 突発修繕と生産計画の連動 | 【可能】 PM（保全管理）で機械の故障・修理を登録すると、PP-DSの能力情報に即座に反映され計画が自動補正。 | 【制限あり】 PM機能はあるが、PP-DSのような詳細スケジューラがないため、分単位の自動後ろ倒しには対応できない。 |
12.5 クラウド運用・カスタマイズ領域（BTP / ABAP）
システムの運用ライフサイクルとアドオン開発ルールにおける決定的な違いです。この領域の制約がプロジェクト全体のスコープとコストに最も大きな影響を与えます。
| 業務要件・機能 | Private Edition（プライベート） | Public Edition（パブリック） |
|---|---|---|
| ソースコードの修正（改造） | 【可能】 従来のABAP開発により、標準プログラム（CMOD/SMOD、BAdI、拡張スポット）を書き換えて独自ロジックを注入可能。 | 【絶対禁止】 標準コードの修正は1ミリも不可。拡張はBTP上に別アプリを作るか、標準が用意した限定的な拡張ポイントのみ。 |
| 画面のカスタマイズ（GUI） | 【自由】 SAP GUI・Fioriどちらも対応。現場が使い慣れた「独自のアドオン画面」をT-Code単位で量産可能。 | 【Fiori限定】 SAP GUIは利用不可。画面変更はFioriの標準テンプレートの範囲内か、BTPで画面を新規スクラッチ開発。 |
| 自動アップデートの影響 | 【コントロール可能】 年1回の製品リリースに対し、自社のタイミングでバージョンアップを決定。入念な回帰テストが可能。 | 【強制自動適用】 年2回、半強制的に最新パッチ・機能が適用される。アドオンをClean Coreにしておかないとシステムが壊れる。 |
12.6 アーキテクトの視点：この差異が意味する「総括」
これら5つの領域を横断して見えてくるのは、「PrivateとPublicでは、目指している企業の姿が根本的に違う」ということです。どちらが優れているかではなく、自社のビジネスモデルとどちらが合致しているかを問うべきです。
| Private Edition：現場力・擦り合わせのデジタル化 |
|---|
| 日本の優れた製造業が持つ「設計変更への柔軟な対応」「現場プランナーの神業的な段取り替え」「製番ごとのドロドロとした原価管理」を、システム側が形を変えて飲み込む（Embedded）ことができる重厚な仕組み。独自ノウハウをシステムに落とし込み、競争優位を維持したい企業に適する。 |
| Public Edition：業務の標準化・割り切りのデジタル化 |
|---|
| 独自のこだわりを捨て、「世の中の標準（Best Practice）」に業務を徹底的にハめ込む。ERPのコア（白ご飯）を一切汚さないため、最新のAI機能（Joule）や新機能を年2回自動で享受し続けられる、運用コストの極めて低い俊敏な仕組み。スピードと俊敏性を優先し、グローバル展開を見据える企業に適する。 |
「最初はPublicで始め、特定の製造機能だけPrivateに移行する」というハイブリッド構成も理論上は可能ですが、移行コストと複雑性から実務的には稀です。導入前の構想策定フェーズにおいて、この差分を経営陣・IT部門・現場が共有し、「何を捨て、何を守るか」を意思決定することが成功の前提条件となります。