はじめに
SAPのシステムは「なんとなく難しそう」と思われがちですが、その基本的な仕組みは3つの層（レイヤー）に分かれた構造で成り立っています。これを「3層アーキテクチャ」と呼びます。
3層アーキテクチャとは、システムを次の3つの役割に分けて設計する考え方です。
- プレゼンテーション層：ユーザーが操作する画面（フロントエンド）
- アプリケーション層：業務ロジックを処理するサーバー（ミドルウェア）
- データベース層：データを永続的に保存する場所（バックエンド）
なぜこの3層構造が重要なのか（why so）：各層を分離することで、それぞれを独立してスケールアップ・メンテナンスできます。たとえばユーザー数が増えたときはアプリケーション層のサーバーだけを追加すればよく、データベース層には手を加えなくて済みます。SAPの技術的な会話でたびたび登場する「APサーバー」「DBサーバー」という言葉は、この3層構造を前提にしています。初心者のうちにこの全体像を掴んでおくと、Basisの話題についていきやすくなります。
3層アーキテクチャの全体像
まず全体像をMermaid図で確認します。
flowchart LR
subgraph "プレゼンテーション層"
A["SAPGUIまたはFiori
（ユーザーのPC / ブラウザ）"]
end
subgraph "アプリケーション層"
B["ABAPアプリケーションサーバー
（ワークプロセス群）"]
end
subgraph "データベース層"
C["DBサーバー
（SAP HANA など）"]
end
A -->|"操作・リクエスト"| B
B -->|"SQL・データ取得"| C
C -->|"結果返却"| B
B -->|"画面描画データ"| Aこの図が示すように、ユーザーの操作はプレゼンテーション層からアプリケーション層に渡り、アプリケーション層がデータベース層へ問い合わせてデータを取得し、結果をユーザーに返します。各層は独立していますが、常に連携して動作しています。
プレゼンテーション層：ユーザーが触れる画面
SAPGUIとは
プレゼンテーション層の代表格がSAPGUI（SAP Graphical User Interface）です。SAPを使ったことがある人なら、あの独特の画面を思い浮かべるでしょう。SAPGUIはユーザーのPC（Windows・Mac・Linux）にインストールして使うクライアントアプリケーションです。
SAPGUIの特徴：
- PC上で動作するデスクトップアプリ
- トランザクションコード（Tコード）を入力して機能を呼び出す
- 長年にわたってSAPの標準的な操作UIとして使われてきた
SAP Fioriとは
SAPGUIに対して、SAP Fiori（フィオーリ）は現代的なWebブラウザベースのUIです。スマートフォンやタブレットでも操作でき、直感的なデザインが特徴です。
| 比較項目 | SAPGUI | SAP Fiori |
|---|---|---|
| 動作環境 | PC専用アプリ | Webブラウザ（スマホ・タブレット対応） |
| 操作方法 | Tコード入力 | タイル型メニューから選択 |
| 見た目 | 従来型のSAP画面 | モダンなWebアプリUI |
| 主な用途 | バックオフィス・詳細操作 | フロントオフィス・承認ワークフローなど |
so what：S/4HANAへの移行を機に、多くの企業がFioriへの切り替えを進めています。しかしSAPGUIがすぐになくなるわけではなく、会計・購買などのバックオフィス業務では依然としてSAPGUIが主流の現場も多いのが実情です。両方の特性を理解しておくことが実務で役立ちます。
アプリケーション層：業務ロジックの心臓部
ABAPアプリケーションサーバーとは
アプリケーション層の核心はABAPアプリケーションサーバー（ABAP AS）です。ABAPとは「Advanced Business Application Programming」の略で、SAP独自のプログラミング言語の名前でもあります。
このサーバーが担う主な役割：
- ユーザーのリクエストを受け取り、業務ロジックを実行する
- 認証・権限チェックを行う
- データベースへの問い合わせ（SQL発行）を行う
- 処理結果をプレゼンテーション層に返す
ワークプロセスとは
ABAPアプリケーションサーバーの内部では、複数のワークプロセス（WP: Work Process）が並行して動作しています。ワークプロセスとは、ユーザーのリクエストを処理する実行単位です。
| ワークプロセスの種類 | 役割 |
|---|---|
| ダイアログWP（DIA） | ユーザーの画面操作を処理するメインのプロセス |
| バックグラウンドWP（BGD） | 夜間バッチ処理など、画面なしで動くジョブ |
| スプールWP（SPO） | 帳票の印刷処理を担う |
| エンキューWP（ENQ） | データのロック管理（二重更新防止）を担う |
| メッセージWP（MSG） | 複数APサーバー間の通信を調整する |
なぜワークプロセスの仕組みを知るべきか（why so）：ユーザー数が増えてシステムが遅くなるとき、「ダイアログWPが枯渇している」というケースがよくあります。ワークプロセスの概念を知っていると、Basisチームの障害報告や性能改善の議論を理解しやすくなります。
データベース層：データを永続的に保存する場所
データベース層の役割
データベース層は、SAPのあらゆるデータを保存する場所です。マスタデータ（品目、仕入先、得意先など）、トランザクションデータ（発注書、受注、会計伝票など）、カスタマイジング設定のすべてがここに格納されています。
SAPが対応する主なデータベース：
- SAP HANA（インメモリデータベース。S/4HANAでは必須）
- Oracle、Microsoft SQL Server、IBM Db2 など（旧来のR/3時代）
SAP HANAとは
SAP HANA（High-performance ANalytic Appliance）は、SAP自社開発のインメモリデータベースです。「インメモリ」とは、データをハードディスクではなくメインメモリ（RAM）に置いて処理するアーキテクチャを指します。
インメモリデータベースのメリット：
- 従来のディスクベースのDBに比べて処理速度が劇的に速い
- リアルタイムの分析・集計が得意
- ディスクI/Oのボトルネックを解消できる
so what：SAP HANAの登場は、SAPアーキテクチャに大きな変革をもたらしました。従来は分析処理と業務処理を別システムで行っていましたが、HANAの高速性によって業務処理と分析を同一データベース上でリアルタイムに実行できるようになりました。これがS/4HANAへの移行が推進される最大の理由の一つです。
SAP HANAで変わった「2層化」の話
従来の3層構造の課題
従来のSAP（SAP R/3やECC時代）では、アプリケーション層で複雑な集計・計算ロジックを実行することが多くありました。データベースは「データを保存・取得するだけ」の存在で、処理の中心はアプリケーション層でした。
HANAによるコードプッシュダウン
SAP HANAでは、データベース内でも高度な計算・集計処理ができるようになりました。これを**「コードプッシュダウン」**と呼びます。
flowchart LR
subgraph "従来（ECC + 汎用DB）"
A1["APサーバー
（集計・計算ロジックを実行）"] -->|"大量データ転送"| B1["汎用DB
（データ保存のみ）"]
B1 -->|"生データを返す"| A1
end
subgraph "現在（S/4HANA + HANA）"
A2["APサーバー
（ロジックをDBに委譲）"] -->|"処理命令"| B2["SAP HANA
（DB内で集計・計算も実行）"]
B2 -->|"処理済み結果のみ返す"| A2
endコードプッシュダウンにより、アプリケーション層とデータベース層の役割分担が変わり、「実質的に2層に近い感覚で動く」と言われるようになりました。アプリケーション層を介してデータを大量転送する処理が減り、全体のパフォーマンスが向上します。
なぜこれが重要なのか（why so）：SAPのコンサルタントや技術者と話すとき、「S/4HANAではHANAが前提」という文脈でこの話が出てきます。S/4HANAへの移行を検討する際、データベースをHANAに統一することがシステム性能改善の鍵であることを押さえておくと、導入判断の議論に参加しやすくなります。
システムランドスケープとの関係
3層アーキテクチャは「1つのシステム」の中の話
ここまで説明した3層アーキテクチャは、1つのSAPシステム（たとえば開発システム）の内部構造を指します。一方、実際のSAP運用では複数のシステムを使い分けます。これをシステムランドスケープと呼びます。
典型的な3システム構成（DEV / QAS / PRD）では、それぞれのシステムが独立した3層アーキテクチャを持ちます。
flowchart LR
subgraph "DEV（開発システム）"
D_AP["APサーバー"]
D_DB["HANA DB"]
D_AP --- D_DB
end
subgraph "QAS（検証システム）"
Q_AP["APサーバー"]
Q_DB["HANA DB"]
Q_AP --- Q_DB
end
subgraph "PRD（本番システム）"
P_AP["APサーバー"]
P_DB["HANA DB"]
P_AP --- P_DB
end
DEV -->|"移送（Transport）"| QAS -->|"移送（Transport）"| PRD各システムが独立した3層構造を持つため、DEVでプログラムやカスタマイジングを開発・テストし、移送（Transport） という仕組みでQAS、最終的にPRDへ反映します。移送を経ることで、本番環境への意図しない変更を防ぎます。
クライアントとシステムランドスケープの詳細はSAPのクライアントとは何か（分離の考え方・設計事例をわかりやすく解説）で解説しています。SAPの全体像を体系的に学びたい方はSAP初心者が最初に学ぶべき5つのことも合わせて参照してください。
よくある疑問
Q1. SAPGUIとFioriは共存できますか？
はい、共存できます。同じSAPシステムに対して、SAPGUIとFioriの両方からアクセスできます。会計担当者はSAPGUIを使い、現場の承認担当者はスマートフォンのFioriアプリを使う、という運用も一般的です。どちらのUIを使ってもアプリケーション層・データベース層は共通です。UI（プレゼンテーション層）だけが異なります。
Q2. 「APサーバーを増やす」とはどういう意味ですか？
ユーザー数が増えてシステムが重くなった場合、アプリケーション層のサーバーを追加することで処理能力を増強できます。これをAPサーバーの水平スケールアウトと言います。3層アーキテクチャでは各層が独立しているため、アプリケーション層だけを増強できます（データベース層の変更は不要）。ただし、負荷分散の仕組み（ロードバランサー）が必要になります。
Q3. SAP HANA Cloudとオンプレミスのハードウェアは何が違いますか？
オンプレミス（自社設置）のSAP HANAでは、物理サーバーを自社で用意してHANAをインストールします。一方、SAP HANA Cloudはクラウド上でHANAをサービスとして提供するものです（DBaaS: Database as a Service）。S/4HANA Cloudを利用する場合は自動的にSAP HANA Cloudがデータベース層になります。サーバーのハードウェア管理・OSパッチ適用・バックアップなどをSAP側が担うため、ユーザー企業はインフラ運用の負担を大幅に削減できます。
まとめ
- SAPは3層アーキテクチャ（プレゼンテーション層・アプリケーション層・データベース層）で構成されており、各層を独立して管理・スケールできる
- プレゼンテーション層にはSAPGUI（デスクトップアプリ）とFiori（Webブラウザ）があり、S/4HANA移行を機にFiori化が進んでいるが両者は共存可能
- アプリケーション層（ABAPアプリケーションサーバー）が業務ロジックを実行し、複数のワークプロセスがユーザーのリクエストを並行処理する
- データベース層にSAP HANAを採用することで、インメモリ処理による高速化とコードプッシュダウンによるDB内集計が実現する
- SAP HANAの登場によりアプリケーション層の負荷が下がり、「実質2層化」と呼ばれる処理モデルへ進化した
- システムランドスケープ（DEV / QAS / PRD）では、各システムが独立した3層構造を持ち、移送によってシステム間で設定・プログラムを反映する
3層アーキテクチャの仕組みを理解したら、次はS/4HANAが各層でどう進化しているのかを全体像として押さえておくと、システム設計の議論に入りやすくなります。約2時間の動画で主要機能と特徴を一通りカバーできます。