SAP CAP入門｜Cloud Application Programming Modelの全体像とABAP RAPとの違い

はじめに：CAPとは何か、なぜ今学ぶのか

SAPの拡張開発の中心は、長らくABAPでした。S/4HANA時代になっても、コア業務オブジェクトの拡張やトランザクション系アプリの開発はABAP（特にRAP）が主役です。一方で、SAP本体に手を入れないSide-by-Side拡張の世界では、別のフレームワークが標準になっています。それがCAP（SAP Cloud Application Programming Model）です。

CAPはBTP（SAP Business Technology Platform）上で動作する、Node.jsまたはJavaベースのアプリケーション開発フレームワークです。SAPのClean Core戦略においてSide-by-Side拡張の中核と位置づけられており、新規のクラウドネイティブなSAP拡張アプリは、原則としてCAPで構築するのが標準になっています。

なぜ今CAPを学ぶ必要があるのか（why so）。S/4HANA Public CloudやS/4HANA Cloud Private EditionでClean Coreを徹底するほど、コア外に出すべきカスタム業務ロジックが増えます。それらをBTPに置く際の標準フレームワークがCAPだからです。

so what：BTPでの拡張開発を始めるなら、まずCAPの全体像を押さえるのが最短ルートです。本記事ではCAPのアーキテクチャ・Node.js/Java選択・ABAP RAPとの違い・BTPデプロイの流れまで、実務でCAPを始めるために必要な基礎知識を整理します。

なお、3つの「CDS」（ABAP CDS / HANA Cloud CDS / CAP CDS）の言語的な違いについてはHANA Cloud CDSとは｜ABAP CDS・CAP CDSとの違いで解説しています。本記事はCAP CDSという「言語」の話よりも、CAP「フレームワーク」全体の話に焦点を当てます。

まず結論：CAPの全体像

最初に全体像を提示します。

CAPの基本思想

CAPの中核思想は「データモデルを書けばサービスが自動生成される」という点に尽きます。開発者は.cdsファイルにエンティティとサービスを宣言的に書くだけで、CAPフレームワークがOData v4サービスを自動生成し、HANA Cloudへの永続化・認証・ページング・フィルタリングなどを面倒見てくれます。

開発者が書くもの：

1. データモデル（エンティティ、関連、属性）— db/schema.cds
2. サービス定義（公開エンティティ、アクション）— srv/cat-service.cds
3. カスタムロジック（イベントハンドラ、バリデーション）— srv/cat-service.js（Node.js）または srv/CatService.java（Java）

これだけで、OData v4サービス・HANA Cloudへのデプロイ・認証連携・Fiori Elementsでの画面自動生成までが揃います。

CAPのアーキテクチャ図

flowchart LR
  subgraph dev["開発者が書くもの"]
    direction LR
    db["db/schema.cds
データモデル"]
    srv["srv/*.cds
サービス定義"]
    handler["srv/*.js or *.java
カスタムロジック"]
  end
  subgraph runtime["CAPランタイム"]
    direction LR
    cap_eng["CAPフレームワーク
（Node.js or Java）"]
  end
  subgraph backend["バックエンド"]
    direction LR
    hana[("HANA Cloud
or SQLite")]
    btp_auth["XSUAA
認証"]
  end
  consumer(("Fiori UI
外部システム"))
  db --> cap_eng
  srv --> cap_eng
  handler --> cap_eng
  cap_eng --> hana
  cap_eng --> btp_auth
  cap_eng -->|"OData v4"| consumer

ポイントは、開発者の書くコードが薄く済み、定型処理はフレームワークが受け持つ点です。

CAPのアーキテクチャ：3層モデル

CAPアプリは典型的に3つの層で構成されます。Mavenのモジュール分割やNPMのワークスペースに対応し、それぞれが独立してデプロイされる構造です。

db層：データモデル定義

db/フォルダにschema.cdsを配置し、エンティティとリレーションを定義します。

namespace my.bookshop;

entity Books {
  key ID    : Integer;
  title     : String(100);
  stock     : Integer;
  author    : Association to Authors;
}

entity Authors {
  key ID    : Integer;
  name      : String(100);
  books     : Association to many Books on books.author = $self;
}

Association toでテーブル間の関連を宣言的に書ける点はABAP CDSと同じ思想です。CAPはこの定義から、HANA Cloud用のDDL（CREATE TABLE文）を自動生成します。ローカル開発時はSQLiteでも動作するため、BTP環境がなくても開発を始められます。

srv層：サービス定義

srv/フォルダにcat-service.cdsを配置し、外部に公開するエンティティと操作を定義します。

using my.bookshop as my from '../db/schema';

service CatalogService {
  entity Books as projection on my.Books;

  action submitOrder(book: Books:ID, quantity: Integer) returns OrderConfirmation;

  type OrderConfirmation {
    confirmationNumber: String;
    deliveryDate: Date;
  }
}

ここでもprojection onという構文が登場します。CAPもRAPも、データモデル層と公開層をProjectionで分離する設計を採用しているのです。

サービス定義を書くと、CAPは自動的にOData v4のCRUDエンドポイント（GET/POST/PATCH/DELETE）を生成します。アクション（submitOrder）はOData v4の関数/アクションとして公開されます。

handler層：カスタムロジック

定型のCRUDだけで完結しないビジネスロジックは、handler層で書きます。Node.jsの場合：

const cds = require('@sap/cds');

module.exports = cds.service.impl(async function() {
  const { Books } = this.entities;

  this.before('CREATE', Books, (req) => {
    if (req.data.stock < 0) {
      req.error(400, 'Stock cannot be negative');
    }
  });

  this.on('submitOrder', async (req) => {
    const { book, quantity } = req.data;
    return { confirmationNumber: 'ORD-' + Date.now(), deliveryDate: '2026-05-01' };
  });
});

CAPはイベント駆動型のハンドラモデルを採用しており、before（処理前）・on（メイン）・after（処理後）のフックでカスタムロジックを差し込みます。

Node.js版とJava版の選択

CAPはNode.js版とJava版の2つの公式ランタイムを提供しています。どちらを選ぶかは初学者がまず迷うポイントです。

なぜNode.js版が初学者向きか（why so）。SAP公式のチュートリアルやサンプル（Bookshopなど）はNode.js版が先行しており、ドキュメントとサンプルコードが見つけやすいからです。Java版は遅れて提供される機能もあり、ドキュメントの厚みではNode.jsに及びません。

so what：CAPを初めて学ぶならNode.js版から始めるのが定石です。プロダクション要件で本格的にJavaが必要になった時点でJava版へ移行を検討する、という順序が現実的です。両者は同じ.cdsファイル（データモデル・サービス定義）を共有できるため、移行時の負担も軽減されます。

CAPとABAP RAPの違い・棲み分け

CAPとABAP RAPは、表面的にはどちらも「CDSベースのトランザクションアプリを作るフレームワーク」に見えます。しかし、動作環境・対象領域・運用前提が大きく異なります。

比較表

どちらを選ぶか

判断軸は「S/4HANAコアと密結合か、独立して動かすか」です。

• S/4HANAの業務オブジェクト（販売伝票、購買発注など）を直接扱い、リアルタイムでデータを読み書きするアプリ → ABAP RAP
• S/4HANAとはAPI経由で連携するだけで、独自の業務ロジック・データを持つアプリ → CAP
• S/4HANAのライフサイクル（アップグレード周期）と切り離して頻繁にリリースしたい → CAP
• ABAP開発者しかいないチーム → ABAP RAP（学習コスト最小）
• フルスタック / クラウドネイティブ志向のチーム → CAP

ABAP RAPの詳細・全体像についてはABAP CDSの全体像 — VDMとRAPの違い・棲み分けを理解する、Clean Core戦略との関係についてはSAP Clean Core戦略を参照してください。

CAPでの開発の流れ：cds initからデプロイまで

CAPアプリを最小構成で立ち上げる手順を、Node.js版を例に整理します。

1. プロジェクトの初期化

npm install -g @sap/cds-dk
cds init bookshop
cd bookshop
npm install

cds initコマンドでCAPプロジェクトの雛形が生成されます。db/、srv/、app/の3フォルダ構造ができ、必要なpackage.jsonもセットアップされます。

2. データモデル・サービス定義の作成

db/schema.cdsにエンティティを書き、srv/cat-service.cdsにサービス定義を書きます。前述のサンプルコードがそのまま使えます。

3. ローカル実行

cds watch

cds watchコマンドで、ローカルにOData v4サービスが立ち上がります。デフォルトではSQLiteを使ってインメモリでデータを保持するため、HANA Cloudの環境がなくても動作確認ができます。ブラウザでhttp://localhost:4004/にアクセスすると、サービスのエンドポイント一覧が表示されます。

4. ハンドラの実装

srv/cat-service.jsにカスタムロジックを追加します。

5. HANA Cloudへの接続準備

ローカル開発ではcds add hanaコマンドでHANA Cloudへの接続設定を追加し、db/data/にCSVファイルを置けば初期データもデプロイできます。

6. BTPへのデプロイ

cds add mta
mbt build
cf deploy mta_archives/bookshop_1.0.0.mtar

cds add mtaでMTA（Multi-Target Application）の設定ファイルmta.yamlを生成し、mbt buildでMTARアーカイブを作成、Cloud Foundry CLIでBTPサブアカウントにデプロイします。HANA Cloud HDIコンテナへのスキーマデプロイも自動的に行われます。

7. Fiori Elementsで画面を生成

cds add fioriを実行すると、Fiori Elements用のmanifestを含むapp/フォルダが追加されます。Fiori Elementsは@UIアノテーションを参照して画面を自動生成するため、追加の画面コードを書かずに一覧画面と詳細画面が完成します。Fiori Elementsの仕組みはFiori Elementsとはで解説しています。

BTP / BAS / HANA Cloudとの関係

CAPは単独で動くものではなく、BTP上の複数のサービスと連携します。

Business Application Studio（BAS）

BTP上で提供されるWebベースの統合開発環境がBAS（Business Application Studio）です。BASには「Full Stack Cloud Application」というDev Spaceテンプレートが用意されており、CAP・UI5・MTA関連のツールがプリインストールされています。BTPサブアカウントから直接ブラウザで開けるため、ローカルにNode.jsやJDKをインストールせずに開発を始められます。BASの詳細はBusiness Application Studio入門を参照してください。

ローカルのVS CodeでもCAP拡張をインストールすれば同等の開発が可能ですが、BTP環境との統合（HANA Cloudへの接続、デプロイ）はBASのほうがスムーズです。

HANA Cloud

CAPの永続化レイヤとしてはHANA Cloudが標準です。BTPサブアカウントでHANA Cloudインスタンスを作成し、HDIコンテナをCAPアプリに割り当てることで、本番グレードのDBとして利用できます。HANA Cloud内部のCDS（HDBCDS）はCAPが自動生成するため、開発者がHDBCDSを直接書くことは通常ありません。HANA Cloud CDSとの違いについてはHANA Cloud CDSとはを参照してください。

XSUAA / IAS

認証はBTPの認証サービス（XSUAAやIAS）と連携します。CAPの@requiresや@restrictアノテーションで認可ルールを宣言的に書けるため、コードレベルでの認証実装は最小限に抑えられます。

Cloud Foundry / Kyma

CAPアプリはCloud Foundry環境にデプロイするのが一般的ですが、Kyma（Kubernetesベース）にもデプロイ可能です。Kymaを選ぶとコンテナベースの運用ができ、より柔軟なスケーリングが可能になります。BTP全体の構成についてはSAP BTP入門を参照してください。

Clean Coreとの関係

CAPはSAPのClean Core戦略におけるSide-by-Side拡張の標準フレームワークです。

なぜCAPがClean Coreに重要か（why so）。S/4HANAコアにカスタムコードを置かない方針を徹底するほど、ビジネスロジックの置き場所が必要になります。BTP上で動作し、S/4HANAとAPI経由で疎結合に連携するCAPは、まさにこの「Coreの外」を担う技術として設計されています。

so what：CAPで作ったアプリは、S/4HANAのアップグレード周期に縛られず独立してリリースできます。プロダクト改善のサイクルを早めたい組織にとって、CAPによるSide-by-Side拡張は競争優位の源泉になり得ます。

ABAP CloudのDeveloper Extensibility（On-Stack拡張）とCAP（Side-by-Side拡張）は競合ではなく補完関係です。コア業務オブジェクトの拡張はDeveloper Extensibility、業務横断の独立アプリはCAP、という棲み分けを意識して使い分けてください。

CAPを学ぶときのリソース

公式リソース

• SAP Help Portal: capire（CAPのフレームワークドキュメント）
• SAP Tutorial Navigator: 「Create a Business Application Using CAP」シリーズ
• SAP Discovery Center: BTPサービスのカタログとサンプル

これらのリソースを使うコツは、まず公式サンプル（Bookshopアプリ）を一度動かしてから、自分のドメインに置き換えてみることです。CAPの設計思想は「公式サンプルがそのまま実プロジェクトの雛形になる」ことを前提にしているため、サンプルをいじり倒すのが最短の学習方法です。

よくある最初のつまずき

• cdsコマンドが見つからない → npm install -g @sap/cds-dkを忘れている
• BAS上でHANA Cloudに接続できない → BTPサブアカウントのEntitlementsでHANA Cloudが有効化されているか確認
• ローカルで動くがBTPデプロイで失敗する → MTA Buildのログを確認、mta.yamlの依存関係を見直す
• OData v4のクエリが意図通りに動かない → CAPの@cds.query.limitや@readonlyなどのアノテーションが効いていないか確認

よくある疑問（FAQ）

Q1. CAPでABAPの知識は必要ですか？

CAP単体の開発には不要です。Node.js版ならJavaScript、Java版ならJavaのスキルがあればCAPの開発はできます。ただし、S/4HANAと連携するCAPアプリを作る場合、ABAP側のRAPサービスやReleased APIの読み方は知っておくと役立ちます。

Q2. CAP CDSとABAP CDSは互換ですか？

互換ではありません。構文は似ていますが、CAP CDSはCAPコンパイラで処理され、ABAP CDSはABAPスタックで処理されます。両者は思想を共有しているものの、同じファイルを共有することはできません。

Q3. CAPのライセンス・コストは？

CAPフレームワーク自体はオープンソース（MITライセンス相当）で無償です。BTPに乗せて運用する際のBTPサービス利用料（HANA Cloud、Cloud Foundry、認証サービスなど）が発生します。

Q4. CAPでマイクロサービスは作れますか？

可能です。CAPアプリを複数のmtaモジュールに分割し、それぞれを独立したCloud Foundryアプリとしてデプロイすることで、マイクロサービス的な構成を組めます。Kyma環境ならコンテナベースのマイクロサービスとして展開しやすくなります。

Q5. CAPでファイルアップロード・添付ファイル機能は実装できますか？

可能です。CAPはMedia Entity（@Core.MediaType）に対応しており、画像やPDFのアップロード・ダウンロードを宣言的に扱えます。HANA Cloud側にBLOBとして保存されるか、外部ストレージ（Object Store on BTP）に逃がす設計にすることもできます。

Q6. CAPでバッチ処理・定期実行は実装できますか？

CAPフレームワーク単体ではcron的な仕組みは持ちませんが、BTPのJob Schedulerサービスと連携することで定期実行が実現できます。CAPサービスのアクション（OData function/action）をJob Schedulerから呼び出すパターンが標準です。

Q7. CAPはS/4HANA Cloudとどう連携しますか？

CAPからS/4HANA CloudのOData APIを呼び出す形が一般的です。CAPのcds.connect.toでS/4HANA APIへの接続を定義し、Destination Service経由で認証・接続情報を管理します。S/4HANA側はReleased APIを使う必要があり、Custom CDSビュー＋Service Bindingで公開した独自APIや、SAP標準の事前公開APIを利用します。

まとめ

• CAPはBTP上で動くNode.js / JavaベースのSAP公式アプリ開発フレームワークで、Side-by-Side拡張の中核技術
• 「データモデルを書けばOData v4サービスが自動生成される」という宣言的開発が中心思想
• アーキテクチャは3層（db / srv / handler）に明確に分かれ、CDSとイベントハンドラの組み合わせで完結する
• Node.js版はチュートリアル・コミュニティが豊富で初学者向き、Java版はエンタープライズ規模・高負荷向き
• CAPとABAP RAPの使い分けは「S/4HANAコアと密結合か、独立クラウドアプリか」で判断する
• 開発はBAS（Business Application Studio）が標準環境、永続化先はHANA Cloud、認証はXSUAA / IAS
• Clean Core戦略におけるSide-by-Side拡張の中核を担い、S/4HANAのアップグレード周期から独立してリリースできる
• 学習開始は公式チュートリアル（Bookshopアプリ）を動かしてから自ドメインに置き換えるのが最短

ABAP RAPとの棲み分けや、ABAP CDSの中での位置づけについてはABAP CDSの全体像 — VDMとRAPの違い・棲み分けを理解する、3つのCDS（ABAP / HANA Cloud / CAP）の言語的な違いについてはHANA Cloud CDSとは｜ABAP CDS・CAP CDSとの違い、BTP全体の位置づけはSAP BTP入門を参照してください。

CAPを実装レベルで学ぶなら、ABAP・BTP CAPM・RAP・OData・UI5 Fioriまでを一気通貫で扱う実践講座が効率的です。CAPのcds initからHANA Cloudデプロイ・Fiori Elements統合までを手を動かして体験できます。