CDS Viewとは何か？S/4HANAのデータモデリングを支える新しい基盤

はじめに

S/4HANAの開発・拡張に関わると、必ず目にするのが CDS View（Core Data Services View） です。従来のSAPでは、データの定義はABAP Dictionary（Tコード SE11）で行い、ビジネスロジックはABAPプログラムに書くのが基本でした。CDS Viewはこの常識を変え、データモデルの定義・アクセス制御・UIの振る舞いまでをコードベースで宣言的に記述する仕組みです。

本記事では、CDS Viewを以下の3つの軸で解説します。

1. CDS Viewとは何か — 従来のSE11ビューとの違い、基本的な考え方
2. アノテーションの仕組み — @で始まるメタデータがCDS Viewの力の源泉
3. S/4HANAにおけるCDS Viewの役割 — OData公開・Fiori・分析レポートとの関係

なぜCDS Viewを学ぶ必要があるのか（why so）：S/4HANAでは、標準のFioriアプリ・Analytical Query・ODataサービスの裏側がCDS Viewで構成されています。カスタム開発や標準機能の拡張を行う場合、CDS Viewを理解していないと「何がどこで定義されているか分からない」状態に陥ります。S/4HANA時代の開発基盤がABAP DictionaryからCDS Viewに移行しているという現実を押さえることが、技術者にもコンサルタントにも求められています。S/4HANAのデータベース基盤（SAP HANA）についてはS/4HANAのインメモリデータベースを理解するで解説しています。

CDS Viewとは何か

一言で言うと

CDS Viewとは、SQLのVIEWをABAPの世界で宣言的に定義し、データモデルにメタデータ（アノテーション）を付加できる仕組みです。定義はEclipseベースの開発環境（ADT：ABAP Development Tools）上でコードとして記述します。

従来のSE11ビューとの比較

DCL（Data Control Language）は、CDS Viewに対するアクセス制御ルールを定義するための言語で、従来のABAP権限オブジェクトに相当する役割を果たします。

flowchart LR
  subgraph "従来（SE11ビュー）"
    A1["SE11で\nビュー定義"] --> A2["ABAPプログラムで\nSELECT文"] --> A3["アプリ層で\nデータ加工"]
  end
  subgraph "CDS View（S/4HANA）"
    B1["Eclipseで\nCDS View定義\n+ アノテーション"] --> B2["HANA DB層で\n直接実行"] --> B3["結果をそのまま\nOData / Fioriへ"]
  end

読者への示唆（so what）：この比較から分かる最も重要な点は、CDS Viewが「単なるビューの進化版」ではなく、データモデル・権限・UI定義・API公開を一箇所に集約する基盤に変わったことです。従来は複数の場所（SE11、ABAPプログラム、SEGW、SU21など）に分散していた定義が、CDS View＋アノテーションに集約されつつあります。

CDS Viewの基本構文

CDS Viewのソースコードは、以下のような構造をしています。

@AbapCatalog.sqlViewName: 'ZV_PO_HEADER'  -- ※DDICベースCDS View構文
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '購買発注ヘッダ'

@OData.publish: true

define view Z_I_PurchaseOrderHeader
  as select from ekko
  association [1..*] to Z_I_PurchaseOrderItem as _Item
    on $projection.PurchaseOrder = _Item.PurchaseOrder
{
  key ebeln as PurchaseOrder,
      bukrs as CompanyCode,
      lifnr as Supplier,
      erdat as CreatedAt,

      // Navigation
      _Item
}

※ 上記はDDICベースのCDS View構文です。S/4HANA 2020以降ではDEFINE VIEW ENTITY（CDS View Entity）が推奨されており、@AbapCatalog.sqlViewNameは不要になります。

各行の意味を整理します。

注目すべきポイント：テーブルの技術名（ebeln、bukrs）を、ビジネス上分かりやすいエイリアス名（PurchaseOrder、CompanyCode）に変換しています。これにより、ODataやFioriの世界では技術名を意識せずに業務的な名前でデータにアクセスできるようになります。

アノテーション — CDS Viewの力の源泉

アノテーションとは

CDS Viewの最大の特徴が、@で始まる**アノテーション（Annotation）**です。アノテーションはCDS Viewにメタデータを付加する仕組みで、「このビューをどう扱うべきか」をシステムに宣言的に伝えます。

プログラミングでいう「設定ファイル」のようなものですが、CDS Viewのソースコードに直接埋め込める点が特徴です。

主要なアノテーション一覧

なお、@OData.publish: trueはOData V2サービスのみを生成する旧方式です。新規開発ではRAP（Service Definition + Service Binding）が推奨されます。

flowchart LR
  subgraph "CDS Viewのアノテーション"
    A1["@OData.*\nAPI公開設定"] --> R["CDS View\n本体"]
    A2["@UI.*\nFiori画面設定"] --> R
    A3["@AccessControl.*\n権限制御"] --> R
    A4["@Semantics.*\n意味情報"] --> R
  end
  subgraph "自動的に反映"
    R --> O["ODataサービス"]
    R --> F["Fiori UI"]
    R --> S["権限チェック"]
  end

なぜアノテーションが画期的なのか（why so）：従来のSAP開発では、「データモデルはSE11で定義」「ODataサービスはSEGWで構築」「権限はSU21/PFCGで設定」「画面はWebDynproやBSPで実装」と、各要素がバラバラのツール・場所に分散していました。アノテーションにより、これらの設定がCDS Viewという1つのソースコードに集約されるため、開発・保守の効率が飛躍的に向上します。SAPの権限管理の基本についてはSAP権限管理の基本で解説しています。

読者への示唆（so what）：CDS Viewのアノテーションは「覚えるもの」ではなく「必要な時に調べるもの」です。種類が膨大（数百種類）なため、すべてを暗記する必要はありません。重要なのは「アノテーションで何ができるか」のカテゴリ（OData公開、UI定義、権限制御、意味情報）を押さえることです。

S/4HANAにおけるCDS Viewの役割

CDS Viewはどこで使われているか

S/4HANAでは、CDS Viewが以下の3つの主要な場面で基盤として使われています。

flowchart LR
  subgraph "CDS Viewの3つの活用場面"
    direction LR
    A["① Fioriアプリ\nUIの裏側のデータソース"]
    B["② ODataサービス\n外部連携のAPI基盤"]
    C["③ 分析レポート\nAnalytical Query"]
  end
  D["CDS View\n（共通基盤）"] --> A
  D --> B
  D --> C

① Fioriアプリのデータソース

S/4HANAの標準FioriアプリはCDS Viewをデータソースとして使っています。@UIアノテーションにより、「一覧画面にどの列を表示するか」「検索条件にどの項目を出すか」といった画面定義もCDS View内で行われます。標準Fioriアプリの動作を調査する際は、基になるCDS Viewの@UIアノテーションを確認すると、画面構成の意図が理解できます。Fioriの全体像についてはSAP Fioriの基本と導入効果で解説しています。

② ODataサービスの基盤

CDS ViewはODataサービスの作り方を根本的に変えました。従来はSEGW（SAP Gateway Service Builder）でエンティティの定義・マッピング・ロジックを手動で構築する必要がありましたが、CDS Viewなら：

• V2の場合：@OData.publish: true のアノテーション1行でODataサービスが自動生成される
• V4の場合：RAP（RESTful ABAP Programming Model）を通じて、CDS ViewがAPIの基盤になる

ODataの基礎（エンティティ設計やNavigation Propertyの考え方）についてはODataとは何か？SAPの外部連携を支えるAPIプロトコルの基礎で解説しています。SEGWを使った従来方式の詳細はOData Gatewayの仕組み、CDS ViewアノテーションによるODataサービスの具体的な作成手順はODataサービスの作り方をご覧ください。OData公開の方式を理解しておくと、新規開発時に「SEGW手動構築」と「CDS View＋アノテーション自動生成」のどちらを採用すべきか、プロジェクトの要件に応じて判断できるようになります。

③ 分析レポート（Analytical Query）

CDS Viewは集計・グルーピングの機能を持っているため、分析レポートのデータソースとしても使われます。@Analytics.query: trueアノテーションを付けたCDS Viewは、Fiori上でAnalytical Queryとして利用でき、従来のBExクエリ（SAP BWで使われる従来の分析レポート定義ツール）に近い分析機能を実現します。Embedded Analyticsの活用を検討する際は、既存のBWレポートをCDS Viewベースに置き換えられるかどうかが、S/4HANA移行の重要な判断ポイントになります。

CDS Viewのレイヤー構造（VDM）

SAPの標準CDS Viewは、Virtual Data Model（VDM） というレイヤー構造で整理されています。

上記のほかに、R_（Restricted Reuse View：再利用を制限したビュー）やP_（Private View：内部専用ビュー）といった接頭辞も存在しますが、実務で遭遇する頻度は比較的低いため、まずはI_・C_・A_の3層を押さえておけば十分です。

flowchart LR
  subgraph "データベース層"
    T1["EKKO\n（テーブル）"]
    T2["EKPO\n（テーブル）"]
  end
  subgraph "Interface層（I_）"
    I1["I_PurchaseOrderHeader"]
    I2["I_PurchaseOrderItem"]
  end
  subgraph "Consumption層（C_ / A_）"
    C1["C_PurchaseOrderQuery\n（分析用）"]
    C2["A_PurchaseOrder\n（API用）"]
  end
  T1 --> I1
  T2 --> I2
  I1 --> C1
  I2 --> C1
  I1 --> C2
  I2 --> C2

なぜレイヤー構造が重要か（why so）：レイヤーを分けることで、テーブル構造が変わってもInterface Viewだけを修正すれば、Consumption Viewやアプリケーション側への影響を最小限に抑えられます。これはソフトウェア設計でいう「関心の分離」と同じ考え方です。

読者への示唆（so what）：カスタム開発でCDS Viewを作る際は、SAPの標準Interface View（I_）をベースにConsumption Viewを作るのがベストプラクティスです。テーブルから直接CDS Viewを作ることもできますが、SAPが提供するInterface Viewには権限制御やビジネスロジックが組み込まれているため、それを活用する方が安全かつ効率的です。このアプローチはSAPが推進するクリーンコア戦略とも整合しています。

なお、VDMの考え方とRAP（RESTful Application Programming Model）との関係、そしてProjection Viewの位置づけについてはABAP CDSの全体像 — VDMとRAPの違い・棲み分けを理解するで詳しく整理しています。「VDMとRAPの違いがいまいち掴めない」という方は、CDS Viewの基礎を押さえたあとに併せてご覧ください。

CDS ViewとODataの関係

CDS ViewとODataは密接に関連しており、**CDS ViewがODataサービスの「設計図」、ODataがその「公開手段」**という関係にあります。

flowchart LR
  A["CDS View\n（データモデル定義）"] -->|"@OData.publish\nまたはRAP"| B["ODataサービス\n（API公開）"]
  B -->|"HTTPリクエスト"| C["Fioriアプリ\n外部システム"]
  A -->|"association"| D["関連CDS View"]
  D -->|"Navigation\nProperty"| B

この対応関係を理解しておくと、「ODataサービスでこういう構造にしたい」→「CDS Viewをこう設計すればいい」という逆算ができるようになります。

よくある疑問

Q1. CDS ViewとHANA Viewは何が違うのですか？

HANA View（Calculation View、Attribute Viewなど）はHANA Studio上でHANAデータベースに直接定義するビューです。一方、CDS ViewはABAPの世界で定義し、HANAだけでなくABAPのトランスポートシステムで管理されます。

S/4HANAでの開発はCDS Viewが標準です。HANA Viewは、ABAPを介さない純粋なHANA上の分析要件でのみ使われます。なお、BTP側でSAP HANA Cloudを直接使うCAP（Cloud Application Programming Model）ベースの開発との違いはHANA Cloud CDS vs ABAP CAPの使い分けで整理しています。

Q2. CDS Viewを使うにはEclipse（ADT）が必須ですか？

はい。CDS ViewはSAP GUIのSE11では作成できず、Eclipse上のABAP Development Tools（ADT）が必須です。ただし、CDS Viewの「参照」はSE11やトランザクションコードからも可能です。新規作成・編集にはEclipseが必要と理解してください。

Q3. 既存のSE11ビューはCDS Viewに移行すべきですか？

すべてを移行する必要はありません。判断基準は以下の通りです。

• 移行すべき場面：ODataサービスとして公開したい、Fioriアプリのデータソースにしたい、権限制御（DCL）を付けたい
• 現状維持でよい場面：ABAPプログラム内でのみ参照しており、今後もFiori/OData化の予定がない

S/4HANAの新規開発では、原則としてCDS Viewを使うべきです。

Q4. アソシエーションとJOINは何が違うのですか？

JOINは「常にデータを結合する」のに対し、アソシエーションは「必要な時だけ結合する（遅延評価）」仕組みです。

-- JOINの場合：常にEKKOとEKPOを結合する
define view Z_V_PO_Join as select from ekko
  inner join ekpo on ekko.ebeln = ekpo.ebeln
{ ... }

-- アソシエーションの場合：_Itemが参照された時だけ結合する
define view Z_V_PO_Assoc as select from ekko
  association [1..*] to ekpo as _Item
    on $projection.ebeln = _Item.ebeln
{ ..., _Item }

アソシエーションの方が、不要なJOINを避けられるためパフォーマンスに優れています。また、ODataのNavigation Propertyに直接マッピングされるため、OData公開を前提とする場合はアソシエーションが推奨されます。

CDSの背後にあるABAPの土台を押さえたい人へ

CDS Viewはアノテーション中心の宣言的な世界ですが、実務ではABAPコード（CDS Table Function、Behavior Implementation、ABAPベースのカスタムロジックなど）と隣り合わせで動きます。CDSだけ覚えても、結局背後のABAPやデータディクショナリの語彙が分かっていないと、エラー時の調査や周辺コードの読解で詰まりやすいところです。

「ABAP側の基礎を一度ちゃんと整理しておきたい」というフェーズの方には、アレグス株式会社・久米正通氏の『SAP ABAPプログラミング入門』が無難な1冊です。CDS/RAPに進む前のベースづくりとして読んでおくと、この記事の内容も腹落ちしやすくなります。

まとめ

• **CDS Viewは「SQLのVIEW + メタデータ」**であり、S/4HANAのデータモデリング・API公開・UI定義の中核を担う基盤
• 従来のSE11ビューとの最大の違いは、アノテーションによりOData公開・Fiori画面定義・権限制御を宣言的に行える点
• アノテーションはCDS Viewの力の源泉であり、@OData（API公開）、@UI（画面定義）、@AccessControl（権限）、@Semantics（意味情報）の4カテゴリを押さえるのが重要
• S/4HANAではFioriアプリ・ODataサービス・分析レポートの3つの場面でCDS Viewが基盤として使われている
• VDM（Virtual Data Model）のレイヤー構造（Interface → Consumption）を理解し、標準のInterface Viewをベースにカスタム開発するのがベストプラクティス
• CDS ViewのアソシエーションはODataのNavigation Propertyに対応し、「必要な時だけ結合する」遅延評価によりJOINより効率的

関連記事として、ODataサービスの具体的な作り方（SEGWとCDS Viewアノテーション方式の比較）はODataサービスの作り方で解説しています。ODataの基礎についてはODataとは何か？SAPの外部連携を支えるAPIプロトコルの基礎、S/4HANAにおける拡張開発のベストプラクティスについてはSAPクリーンコア戦略もあわせてご覧ください。

CDS Viewの知識をさらに実践レベルに引き上げるなら、ABAP CDSからRAP・OData・UI5 Fioriまでを一気通貫で学べる実践講座が効率的です。CDS Viewの定義からOData公開、Fiori画面の自動生成までを手を動かして体験できます。