ABAP CDSの全体像 — VDMとRAPの違い・棲み分けを理解する

はじめに：CDSは分かった、でもVDMとRAPって何？

S/4HANAの開発に関わると、CDSの周辺で必ず出てくる用語が「VDM」と「RAP」です。さらに「Projection View」「Behavior Definition」「Service Binding」といった言葉が次々と登場し、CDSは理解したつもりなのに、それぞれの関係性が掴めないという状態に陥りやすい領域です。

なぜ混乱するのか（why so）。VDMはCDSビューの「整理パターン（お作法）」、RAPは「トランザクション系アプリの開発モデル」と性格が違うものなのに、どちらもCDSを土台にしているため、初学者には同じレベルの選択肢のように見えてしまうからです。

ではどう整理すべきか（so what）。VDMとRAPは「対立する2つの選択肢」ではなく、「異なる目的のための異なるレイヤー」として捉えるのが正解です。本記事ではこの棲み分けを、対応表と図で一気に整理します。

なお、「そもそもCDSとは何か」「CDS Viewの基本構文・アノテーションとは」については、本記事では深く扱いません。CDS Viewそのものの解説はCDS Viewとは何か？S/4HANAのデータモデリングを支える新しい基盤で網羅していますので、CDSの基礎が曖昧な方は先にそちらを参照してください。本記事は「CDS Viewは知っているが、VDMとRAPの関係が分からない」読者を対象にしています。

まず結論：ABAP CDSの中でのVDMとRAPの位置関係

最初に全体像を提示します。詳細は後の章で深掘りしますが、まずこの図と表を頭に入れてから読み進めると、各章の位置づけが理解しやすくなります。

構造図

flowchart LR
  subgraph cds["ABAP CDS（言語そのもの）"]
    direction LR
    syntax["CDS DDL
（define view entity 等）"]
  end
  subgraph vdm["VDM：整理パターン"]
    direction LR
    I["Basic Interface
I_*"] --> Comp["Composite Interface
I_*"] --> C["Consumption
C_* / A_*"]
  end
  subgraph rap["RAP：開発モデル"]
    direction LR
    iv["Interface View
I_*"] --> proj["Projection View
R_* / C_*"]
    proj --> bdef["Behavior Definition
+ Implementation"]
    proj --> sdef["Service Definition
+ Binding"]
  end
  cds --> vdm
  cds --> rap
  vdm -.利用.-> rap

ポイントは、ABAP CDSという言語の上に、VDMとRAPという性格の異なる2つの体系が乗っていること、そしてRAPは内部でVDM的な階層構造を取り込んでいることです。

位置づけの対応表

ここで強調しておきたいのは、VDMには「振る舞い層」が存在しないという点です。VDMはあくまで読み取り系の階層化思想であり、登録・更新・削除といったCUD（Create/Update/Delete）の概念を持ちません。CUDが必要な場合はRAPに移る、という棲み分けです。

VDMとは：読み取り系の整理パターン

VDMの基本思想

VDM（Virtual Data Model）は、SAPがCDSビューを業務オブジェクトごとに階層化して整理するためのお作法です。SAP S/4HANA標準のCDSビューはほぼ例外なくVDMに従って配置されており、命名規則と階層が一貫しています。

VDMの目的は、テーブル直叩きを避け、再利用可能なビューを段階的に積み上げていくことです。下位層は技術寄り、上位層は業務寄り、という構造になっています。

VDMの3層構造

接頭辞の意味を補足します。

• I_：Interface View（再利用前提の中間層）
• C_：Consumption View（Fiori分析クエリやアプリ向け）
• A_：API View（外部システム向けのRemote API）
• R_：Restricted Reuse View（再利用先を限定したビュー）
• P_：Private View（同一パッケージ内の内部利用専用）

実務で頻繁に登場するのはI_・C_・A_の3つです。R_・P_はまずは「そういうものがある」と認識しておけば十分です。VDMレイヤーの詳細はCDS Viewとは何か？S/4HANAのデータモデリングを支える新しい基盤でも触れています。

VDMが解決する課題

なぜこの階層化が必要か（why so）。テーブル構造はSAPのリリースアップグレードや機能拡張で変わる可能性があります。アプリケーションがテーブルを直接参照していると、その都度コードを書き換えなければなりません。VDMではBasic Interface View（I_）が「テーブルとアプリの間の緩衝材」になり、テーブル変更の影響をI_層内に閉じ込めることができます。

so what：S/4HANAでカスタム開発を行う際は、テーブルから直接CDSビューを作るのではなく、SAP標準のI_ビューをベースにComposite Interface ViewやConsumption Viewを組み立てるのが鉄則です。これはClean Core戦略とも整合しており、Released APIとして公開されているI_ビューを起点にすることで、アップグレード耐性のあるカスタム開発が実現できます。

VDMの典型例

flowchart LR
  subgraph db["DB層"]
    T1["EKKO"]
    T2["EKPO"]
    T3["LFA1"]
  end
  subgraph basic["Basic Interface（I_）"]
    B1["I_PurchaseOrderTP"]
    B2["I_PurchaseOrderItemTP"]
    B3["I_SupplierTP"]
  end
  subgraph composite["Composite Interface（I_）"]
    M1["I_PurchaseOrder
明細・仕入先を結合"]
  end
  subgraph consume["Consumption（C_ / A_）"]
    C1["C_PurchaseOrderQuery
分析クエリ用"]
    A1["A_PurchaseOrder
Remote API用"]
  end
  T1 --> B1
  T2 --> B2
  T3 --> B3
  B1 --> M1
  B2 --> M1
  B3 --> M1
  M1 --> C1
  M1 --> A1

下位層から上位層に向かって、テーブルの技術名が業務名に置き換わり、複数テーブルが結合され、最終的にユースケース別のビューに分岐していくのが分かります。

RAPとは：トランザクション系の開発モデル

RAPの基本思想

RAP（RESTful Application Programming Model）は、ABAP Cloud時代のトランザクション系アプリを構築するためのフレームワークです。CDSが「データモデル定義のための言語」だったのに対し、RAPは「データ・振る舞い・サービス公開を一気通貫で扱うための開発モデル」という位置づけです。

なぜRAPが必要だったか（why so）。VDMは読み取り系の整理にはよくできていますが、登録・更新・削除といったトランザクション処理の枠組みを持っていません。S/4HANA時代に新規のFiori画面を量産するには、Create/Update/Deleteとビジネスロジック・バリデーションを宣言的に記述できる仕組みが必要だったのです。

so what：新規にトランザクション系のFiori画面やOData v4サービスを作るなら、RAPが第一選択肢になります。古いBOPF（Business Object Processing Framework）やSEGW（SAP Gateway Service Builder）はRAPの登場で役目を終えており、新規開発ではRAP一択です。Clean Core時代のABAP開発の全体像についてはABAP Cloud入門を参照してください。

RAPの構成要素

RAPは複数の開発オブジェクトの組み合わせで成立します。

flowchart LR
  iv["Interface View
I_PurchaseOrder"] --> pv["Projection View
C_PurchaseOrder"]
  pv --> bdef["Behavior Definition
BDEF"]
  bdef --> bimpl["Behavior Implementation
ABAPクラス"]
  pv --> sdef["Service Definition"]
  sdef --> sb["Service Binding
OData V4"]
  sb --> ext(("Fiori
外部システム"))

ポイントは、Interface Viewから先にProjection Viewが挟まり、そこからBehavior定義・Service定義が枝分かれしていく構造です。データモデル層と公開層を分離することで、同じデータから複数の見せ方（UI用・API用）を派生させられる柔軟性が得られます。

RAPとVDMの関係

ここで誤解されやすい点を1つ整理します。RAPはVDMを否定したり置き換えたりするものではありません。むしろ、RAPアプリのデータ層（Interface View）はVDM風の階層構造で組まれることが多いです。

具体例：購買発注のRAPアプリを作る場合、

1. データ層は I_PurchaseOrderTP（Basic）→ I_PurchaseOrder（Composite）と積み上げる（ここまではVDMと同じ）
2. その上に Projection View C_PurchaseOrder を被せ、@UI・@ODataアノテーションを付ける
3. Projection ViewにBDEFを紐づけ、Create/Update/Deleteのロジックを実装
4. Service DefinitionとService BindingでOData V4として公開

つまりRAPは「VDMで整理されたデータ層の上に、Projection・Behavior・Serviceの層を追加した構造」とも言えます。両者は補完関係にあり、対立するものではありません。

Projection View — RAPのConsumption層を作る仕組み

Projection Viewとは何か

Projection Viewは、CDS View Entityの一形態で、define view entity ... as projection on ...という構文で書かれるビューです。RAPのConsumption層（C_層・R_層）を実現するために導入されました。

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '購買発注 Projection'
@Metadata.allowExtensions: true

@Search.searchable: true
@UI.headerInfo: { typeName: 'PurchaseOrder', typeNamePlural: 'PurchaseOrders' }

define root view entity C_PurchaseOrder
  provider contract transactional_query
  as projection on I_PurchaseOrder
{
  key PurchaseOrder,
      @UI.lineItem: [{ position: 10 }]
      @Search.defaultSearchElement: true
      Supplier,

      @UI.lineItem: [{ position: 20 }]
      CompanyCode,

      @Semantics.amount.currencyCode: 'Currency'
      TotalAmount,

      Currency
}

なぜProjection Viewが必要だったか

why so：RAPで「同じデータモデルから複数の見せ方を派生させたい」場面が頻発するためです。たとえば1つのI_PurchaseOrderから、

• Fiori一覧画面用：絞り込まれた項目セット + @UIアノテーション
• 外部API用：別の項目セット + @ODataアノテーション
• 別の管理画面用：また別の項目セット + 別のUIアノテーション

を作り分けたい場合、Interface View側に全パターンの@UIアノテーションを混ぜ込むのは現実的ではありません。Interface Viewは「データモデル」に専念させ、Projection Viewが「見せ方ごとの宣言」を担うという分離が、RAPの設計思想です。

so what：RAPアプリでは、Projection Viewを必ず1段挟むのが標準パターンです。直接Interface ViewにBDEFやService Definitionを紐づけることもできますが、将来の拡張性・複数チャネル公開を考えるとProjection Viewを挟むのが安全です。

Projection ViewとBehavior Projection

Projection ViewにBDEFを紐づける場合、BDEF側も「Behavior Projection」と呼ばれる対応する記述が必要になります。

projection;

define behavior for C_PurchaseOrder alias PurchaseOrder
{
  use create;
  use update;
  use delete;

  use action confirm;
  use action cancel;
}

projection;キーワードで「これはProjection側のBDEFだ」と宣言し、Interface View側のBDEFで定義された振る舞いの中から「このProjectionでどれを公開するか」を選択する形になります。同じBDEFを土台に、用途別のProjection Behaviorで公開範囲を絞り込めるわけです。

Projection Viewの位置づけまとめ

つまりProjection Viewは「CDSの構文機能ではあるが、用途は完全にRAPのためのもの」という性格です。

VDMとRAPの違い・棲み分けを整理する

ここまでの内容を踏まえ、VDMとRAPをどう使い分けるかを最終整理します。

観点別の比較

CRUDのRはCDSが担う、CUDはRAPが担う

ここは最も重要な棲み分けポイントです。CDS（VDMで整理されたCDSビュー）はCRUDのRをそのもので実現する仕組みです。CDSビューを定義した時点で、SELECT文がDBに発行され、データが返ります。

一方、CRUDのCUD（Create/Update/Delete）はCDSの守備範囲外です。CDSビューに対してINSERT/UPDATE/DELETEを直接発行する仕組みは存在しません。CUDを扱うには、Behavior DefinitionとBehavior Implementationを使って「振る舞い」を別途定義する必要があり、それを担うのがRAPです。

flowchart LR
  subgraph cds_role["CDS（VDM階層）"]
    R["Read（参照）
CDSビューが直接担当"]
  end
  subgraph rap_role["RAP（追加レイヤ）"]
    C["Create"]
    U["Update"]
    D["Delete"]
    Act["カスタムアクション"]
    V["バリデーション"]
  end
  R --> rap_role

so what：「読み取りだけならVDM＋CDSビューで十分」「登録・更新を伴うならRAPが必要」というシンプルな判断軸が成立します。Embedded Analyticsや分析レポートだけが目的ならRAPは不要、トランザクション画面や登録系APIを作るならRAPが必要、と切り分けてください。

実務での判断フロー

新規開発の際の判断順序を整理しておきます。

1. その機能は読み取り（参照・分析）だけか、それとも登録・更新も含むか
2. 読み取りだけ → VDM階層でCDSビューを組む。OData公開が必要なら@OData.publishかRAPのread-only Service Definitionで対応
3. 登録・更新も含む → RAPで構築。Interface View → Projection View → BDEF → Service Definition → Service Bindingの順に作る
4. いずれの場合も、データ層はSAP標準のReleased Interface View（I_*）を起点にするのが原則

CAPとの位置関係（補足）

VDMとRAPはどちらもABAPスタック上の話ですが、SAPの世界にはBTP上で動く別のフレームワークとして「CAP（SAP Cloud Application Programming Model）」があります。

CAPもCDSという名前の言語を使うため、ABAP CDSと混同されやすいのですが、CAPは別世界の技術です。

CAPの詳細・アーキテクチャ・始め方については別記事SAP CAP入門で扱います。3つのCDS（ABAP CDS / HANA Cloud CDS / CAP CDS）の言語的な違いについてはHANA Cloud CDSとは｜ABAP CDS・CAP CDSとの違いと現在のユースケースもあわせてご覧ください。

so what：本記事の主題はあくまで「ABAP CDSの中での」VDMとRAPの棲み分けです。CAPはタブを切り替えて別世界の話、と割り切って整理してください。

よくある疑問（FAQ）

Q1. VDMとRAPは併用できますか？

併用というよりRAPがVDMを内包するのが標準形です。RAPアプリのInterface View（データ層）はVDMのI_階層に従って組むのが推奨であり、その上にProjection View・BDEF・Serviceを被せます。「読み取り部分はVDM、振る舞い部分はRAP」という役割分担で1つのアプリが構成されます。

Q2. クラシックCDS View（define view）とCDS View Entity（define view entity）はどちらを使うべきですか？

新規開発ではCDS View Entity一択です。RAPはView Entityを必須としており、VDMの新規ビューもView Entityで作るのが推奨されています。クラシックCDS View（DDIC-based）はS/4HANA初期に作られたビューや既存資産で見かけますが、新規ではView Entityに統一してください。

Q3. Projection Viewを使わずInterface Viewに直接BDEFを紐づけてはダメですか？

技術的には可能ですが推奨されません。理由は、Interface Viewは「データモデル本体」であり、これに@UIや特定の公開設定を直接付けると、別の用途で再利用しにくくなるからです。Projection Viewを必ず挟むことで、データモデルと見せ方を分離できます。

Q4. Behavior Definitionは必ず実装クラスが必要ですか？

不要なケースがあります。マネージド（managed）モードを使えば、SAPフレームワークが自動的にDBへの書き込みを行ってくれるため、シンプルなCRUDなら実装クラスを書かずに済みます。バリデーション・確定ロジック・カスタムアクションが必要な場合のみ、Behavior Implementationクラスを書きます。アンマネージド（unmanaged）モードは既存BAPI/Function Moduleをラップする際に使います。

Q5. RAPで作ったODataサービスはV2とV4のどちらですか？

Service Bindingの設定で選べますが、新規開発では原則OData V4 UI / OData V4 Web APIを選択します。OData V2は既存資産との互換のため残されていますが、新機能はV4でしか使えないものが多くあります。ODataの基礎についてはODataとは何か？、サービス作成の流れについてはODataサービスの作り方を参照してください。

Q6. RAPに移行するとSEGWはもう使わないのですか？

S/4HANA Cloud時代の新規開発では使いません。SEGW（SAP Gateway Service Builder）はOData V2サービスを手動で構築するレガシー方式で、現在はRAP（Service Definition + Service Binding）が標準です。SEGWの仕組みについてはOData Gatewayの仕組みで扱っています。

まとめ

• VDMとRAPは対立する選択肢ではなく、ABAP CDSの上に積まれた異なる目的のレイヤーである
• VDM（Virtual Data Model）はCDSビューを業務オブジェクトごとに階層化する整理パターンで、読み取り系・分析系で力を発揮する
• RAP（RESTful Application Programming Model）はトランザクション系アプリの開発モデルで、CDSビュー＋Behavior Definition＋Service Definition＋Service Bindingの組み合わせで構成される
• VDMはCRUDのR（参照）のみを担い、CUD（Create/Update/Delete）とカスタムアクションはRAPが担う
• Projection ViewはRAPのConsumption層を実現するための仕組みで、Interface Viewから複数の見せ方を派生させる役割を持つ
• 新規開発では、読み取りだけならVDM＋CDSビュー、登録・更新を含むならRAPで構築するのが標準
• データ層は必ずSAP標準のReleased Interface View（I_*）を起点にし、Clean Coreを保つ
• CAPは別世界（BTP）の技術であり、本記事のVDM/RAPとはタブを切り替えて整理する

ABAP CDSは「言語」、VDMは「整理パターン」、RAPは「開発モデル」、Projection Viewは「RAPの中の1要素」。この階層関係さえ押さえれば、CDS周辺の用語の混乱は解消されるはずです。

CDS Viewそのものの基本構文・アノテーション・S/4HANAでの役割についてはCDS Viewとは何か？S/4HANAのデータモデリングを支える新しい基盤、ABAP Cloud全体の開発思想についてはABAP Cloud入門、Clean Core戦略との関係についてはSAP Clean Core戦略もあわせてご覧ください。

VDMとRAPの理解を実装レベルに落とし込むなら、ABAP CDS・RAP・OData・UI5 Fioriまでを一気通貫で学べる実践講座が効率的です。Interface ViewからProjection View・BDEF・Service Bindingまでを手を動かして体験できます。