SAPの3システムランドスケープとは ― なぜDEV/QAS/PRDに分けるのか、構成バリエーションまで解説

はじめに

SAPプロジェクトの話を聞いていると「DEVで作ってQASでテスト、PRDに上げる」という言い回しが頻繁に登場します。この DEV / QAS / PRD がSAPの 3システムランドスケープ で、SAP運用のもっとも基本的な構成です。

なぜ初学者が最初に押さえるべきか（why so）：SAPは業務要件の追加・変更が毎週のように発生するシステムです。変更を「どこで作って」「どこで試して」「どう本番に届けるか」という仕組みを知らないと、開発者との会話もプロジェクト計画の議論も噛み合いません。さらに、この構成を理解していないと「なぜ本番で直接直せないのか」という素朴な疑問が解けず、SAPの運用文化そのものが腑に落ちません。

この記事で分かること（so what）：

• システムランドスケープとは何か、なぜ3つに分けるのか
• DEV / QAS / PRD それぞれの役割と、典型的な作業内容
• 2層・4層・N+1など、プロジェクトの規模や方針で変わる構成バリエーション
• クライアント概念や移送（STMS）との関係

1. システムランドスケープとは何か

システムランドスケープ（System Landscape）は、1つのSAP環境を支える 複数のSAPシステム（物理的に独立したインスタンス）の集まり を指します。ここで言う「システム」とは、ハードウェア・OS・データベース・SAPインスタンスを含む、1つの独立した実行環境のことです。

1つの会社が使うSAPは「1システム」ではなく、用途の違う複数システムで構成されます。この構成全体がランドスケープです。

「システム」と「クライアント」の違い

混同しやすいので先に整理しておきます。

クライアント側の詳細はSAPのクライアントとは何かで詳しく解説しています。本記事ではシステムレベルの分離に焦点を当てます。

2. なぜ3つに分けるのか ― 1システム運用の何が危険か

「別々のサーバーを何台も用意するのは面倒そう」と感じる方もいるでしょう。なぜSAPはここまでして環境を分離するのでしょうか。

「本番で直接直す」ことの何が問題か

SAPの世界では「本番環境で直接プログラムや設定を変更する」ことは原則として禁止されています。これは単なる慣習ではなく、以下のリスクが現実に存在するためです。

• 即時の業務停止リスク：変更に不具合があった場合、業務が止まる。SAPは基幹業務を支えるため、数分の停止でも出荷遅延・売上損失につながる
• 変更履歴の喪失：直接変更するといつ誰が何を変えたか追跡できず、監査要件（SOX法など）を満たせない
• 切り戻し困難：失敗時に「変更前の状態」に戻す手段が不完全で、長時間の障害になる
• テスト不足：他機能への影響を検証する余地がなく、玉突き事故を起こす

why so：SAPは会計・購買・販売・生産といった基幹業務を横断的に結ぶため、1つの設定変更が予想外のモジュールに波及することがよくあります。たとえば購買の移動タイプを1つ変えるだけで、在庫・原価・会計伝票の全てに影響するといったケースです。本番で直接変更するとその影響が直ちに現場に出てしまいます。

so what：SAPの運用は「変更は安全な場所で作り、段階的に検証し、最後に本番へ運ぶ」という流れを前提に設計されています。そのために 開発環境・検証環境・本番環境 という3つの独立したシステムが必要になります。

3. DEV / QAS / PRD それぞれの役割

3システム構成では、各システムに役割が明確に割り当てられます。

flowchart LR
  subgraph DEV["DEV（開発）"]
    D1[カスタマイジング]
    D2[ABAP開発]
    D3[単体テスト]
  end
  subgraph QAS["QAS（検証）"]
    Q1[結合テスト]
    Q2[UAT]
    Q3[性能試験]
  end
  subgraph PRD["PRD（本番）"]
    P1[日常業務運用]
  end
  DEV -->|移送| QAS -->|移送| PRD

DEV（開発システム / Development）

開発者とコンサルタントが 変更を作る場所 です。カスタマイジング設定の変更・ABAPプログラムの開発・Fioriアプリのビルドなど、すべての変更作業はここで始まります。

この環境の特徴は、変更が自由にできる代わりに本番データは入っていない ことです。テスト用の架空データ（マスタ・トランザクション）を使って機能を作り込みます。開発者は自分のタスク単位で試行錯誤するため、データが汚れていても問題になりません。

QAS（検証システム / Quality Assurance）

DEVで作られた変更を 業務シナリオで試す場所 です。「結合テスト」「UAT（User Acceptance Test：ユーザー受入テスト）」「性能試験」などが行われます。

QASの特徴は、本番により近い構成と、より多くのデータ量 を持つことです。DEVでは1件のテストデータしか入れていない状況でも、QASでは「月次決算で1万件のデータを処理した時の動き」を再現します。エンドユーザーが実際に触って「業務として使えるか」を判定するのもこのフェーズです。

why so：DEVだけでテストを終えると、単独では動くが業務フロー全体では詰まる、という問題を発見できません。たとえば「受注登録は動くが、与信チェックの連動が抜けていた」という不具合は、DEVの単体テストでは露見せず、QASの結合テストで初めて見つかります。

PRD（本番システム / Production）

業務部門が 日常業務で実際に使うシステム です。PRDには原則として直接変更を加えません。すべての変更はDEVで作られ、QASでテストされ、最後にPRDへ運ばれます。

PRDの特徴は、変更が極めて厳格に管理 されていることです。具体的には次のような制約が敷かれます。

• クライアント設定で カスタマイジング変更不可 にロック
• 直接コード編集は禁止、変更は必ず移送経由
• インポート前に承認プロセスを必須化（大規模プロジェクトではChaRMを利用）
• 本番インポートは業務時間外のメンテナンスウィンドウで実施

「本番環境では人間が直接触らない」ことがSAP運用の第一原則と言われるのはこのためです。

4. 変更はどう伝わるか ― 移送の流れ

DEV→QAS→PRDという流れは、単なる「順番」ではなく 移送（Transport） という仕組みで物理的に繋がっています。変更をひとまとめにした「移送リクエスト」を順番にインポートすることで、各環境に変更が反映されます。

flowchart LR
  A[DEV
変更作成] --> B[移送リクエスト
リリース]
  B --> C[QAS
インポート・テスト]
  C --> D[承認]
  D --> E[PRD
インポート・本番稼働]

移送の具体的な仕組み・TRの種類・STMSの操作についてはSAP移送リクエスト・STMS入門で詳しく解説しています。本記事では「3システムが移送で連結されている」という全体像を押さえるだけで十分です。

why so：この移送の流れは 一方向 であることが重要です。DEV→QAS→PRDという順序は崩さず、逆方向（PRD→QASにデータを戻すなど）は特別な手順を使わない限り行いません。一方通行にすることで「本番には必ず検証済みの変更だけが届く」という安全性を担保しています。

5. 構成バリエーション ― 3層がすべてではない

ここまで3システム構成を標準として説明しましたが、実務ではプロジェクトの規模や運用方針によって バリエーション があります。

2システム構成（DEV + PRD）

小規模な追加開発や、検証フェーズを省略できる特殊なケースでは、DEVとPRDだけの2層構成を取ることがあります。ただしQASがない分、テストはDEVで兼ねる 必要があり、開発と検証でクライアントを分ける運用（例：DEVのクライアント100で開発、クライアント200でテスト）が一般的です。

リスク：本番相当のデータ量での検証ができないため、性能試験を省略することになります。大規模運用では推奨されません。

4システム構成（DEV + QAS + PRE-PRD + PRD）

大企業や高信頼性が求められるプロジェクトでは、本番直前の PRE-PRD（ステージング環境） を追加する4層構成が使われます。

PRE-PRDは 本番データを定期的にコピーして最新状態を保つ 環境で、本番リリース直前のドライラン（リハーサル移送）や緊急修正の動作確認に使います。

N+1構成（並行開発対応）

複数のプロジェクトが並行して走る場合、DEVを複数用意して プロジェクトごとに分離 する構成もあります。

flowchart LR
  D1[DEV-A
プロジェクトA] --> M[MERGE
統合DEV]
  D2[DEV-B
プロジェクトB] --> M
  M --> Q[QAS] --> P[PRD]

プロジェクトAとBがそれぞれ独立したDEVで開発し、一定のタイミングで統合DEVにマージしてQASへ運びます。大規模SI案件やマルチベンダー体制で採用される構成です。

サンドボックス（SBX）の追加

3層・4層いずれの構成でも、サンドボックス（Sandbox） という「壊してもよい実験環境」を追加することがよくあります。SBXは移送経路には含まれず、初期設定検証や破壊的な試行錯誤に使います。

so what：構成の選び方は「何を重視するか」で決まります。スピード重視なら2層、信頼性重視なら4層、並行開発なら N+1 といった具合に、プロジェクトの性質に合わせて選定するのがBasisコンサルタントやアーキテクトの腕の見せ所です。

6. クライアント概念との関係

3システムランドスケープは「物理的な分離」ですが、各システムの中はさらに クライアント という論理的な区画に分かれています。この二重構造こそがSAPの環境管理の肝です。

why so：ABAPプログラムやテーブル定義はクライアント非依存なので、同じシステム内では共有されます。つまり「DEVの中でテスト用クライアントを増やしても、プログラムは全クライアントに共通」です。このため、プログラムレベルの分離が必要な場合はシステムを分けるしかありません。二重の分離構造 は、データと実装の両方を安全に隔離するために必要なのです。

クライアント依存・非依存の区別やゴールドクライアントの設計パターンはSAPのクライアントとは何かで詳しく解説しています。

7. S/4HANA Cloud時代のランドスケープはどう変わるか

クラウド版のS/4HANAが登場したことで、ランドスケープの考え方にも変化が生まれています。

S/4HANA Cloud Public Edition

Public Editionでは SAP側があらかじめランドスケープを用意 しており、ユーザー企業は「テナント」としてそこに入居する形です。伝統的な「DEV用サーバーを自社で調達」といった作業はなく、Starter/Test/Productionといった標準的なテナント構成が提供されます。

ただし「開発→検証→本番」という概念自体は残っており、Software Collections という新しい単位で変更を運びます。考え方はオンプレ時代の移送と本質的に同じです。

S/4HANA Cloud Private Edition

Private Editionはオンプレに近い構成で、従来通りのDEV/QAS/PRDの3層ランドスケープを採用できます。インフラはSAP側が管理しますが、論理構成はユーザーが設計します。

so what：クラウド時代になっても「変更を段階的に運ぶ」という運用思想は不変です。インフラの調達や物理構成は変わっても、「本番には検証済みの変更だけが届く」という原則はどのエディションでも守られています。

よくある疑問（FAQ）

Q1. なぜ最低でも3つもシステムが必要なんですか？2つではダメですか？

理論上は2つでも運用できますが、QASがないと「開発者以外の第三者が本番に近い環境でテストする」機会が失われます。結果として、開発者の盲点になっていた業務ケースの不具合が本番で初めて見つかり、業務停止につながるリスクが高まります。3層は「開発者」「テスト担当者」「本番ユーザー」という3つの役割を物理的に分離するための最低限の構成です。

Q2. 各システムの「データ」は同じですか？違いますか？

違います。DEVには開発者が作った架空のテストデータ、QASには本番に近いマスタデータ＋テスト用のトランザクションデータ、PRDには実際の業務データが入っています。DEVやQASに本番データをコピーすることもありますが、個人情報の扱いに注意が必要なため、マスキング（匿名化）処理を加えることが一般的です。

Q3. 本番で障害が起きたとき、本番で直接直してはダメですか？

原則ダメです。緊急時でも「Hotfix用の移送リクエストをDEVで作成→QASで最小限の確認→PRDにインポート」という手順を踏みます。ただし、あまりに致命的な障害（業務が完全停止しているなど）では、SAPが提供する 緊急修正モード を使って例外的に本番直接修正を行うこともあります。その場合も後から正規の移送で上書きし直すのが鉄則です。

Q4. DEV/QAS/PRDのSID（3文字のシステムID）はどう決めるんですか？

会社やプロジェクトの命名規則によりますが、一般的には「プロジェクト略称＋環境識別」で決めます。たとえば「ERP本番プロジェクト」ならDEV=D01、QAS=Q01、PRD=P01、または単純にDEV/QAS/PRDそのものをSIDにするケースもあります。SIDはシステムの識別子としてログやSTMS画面で頻繁に目にするため、分かりやすい命名が推奨されます。

まとめ

• SAPの3システムランドスケープ（DEV/QAS/PRD） は、変更を安全に本番まで運ぶための物理的な分離構造
• 本番で直接変更しない ことがSAP運用の第一原則。業務停止リスク・監査要件・切り戻し困難さが理由
• DEVは変更を作る場所、QASは業務シナリオで試す場所、PRDは業務部門が日常業務で使う場所
• 変更は移送（STMS）の仕組みで一方向に流れる。逆方向の移送は原則行わない
• 規模や方針に応じて 2層・4層・N+1 などのバリエーションがある。サンドボックス（SBX）の追加も一般的
• システムレベルの分離とクライアントレベルの分離の 二重構造 で、データと実装の両方を安全に隔離する
• S/4HANA Cloud時代 でも「段階的に変更を運ぶ」思想は不変。PublicではSoftware Collections、Privateではオンプレとほぼ同様のランドスケープを採用

SAPの基本を体系的に学ぶなら、動画で全体像をつかむのが効率的です。ランドスケープの位置付けも含めて、約2時間でS/4HANAの主要機能と特徴を一通り押さえられます。