ADT AladdinALADDIN TECHNOLOGY

ホーム › 記事 › SAP・BTP

BLOG — SAP・BTP

SAP BTP CAP入門：Cloud Application Programming Modelで作るS/4HANA拡張アプリ

CAP（Cloud Application Programming Model）は、SAP BTP上で拡張アプリを素早く作るためのオープンソース開発モデルです。CDSでデータモデルを定義するだけでOData APIとFiori Elements UIが自動生成され、S/4HANAとも安全に連携できます。本記事では、全体像をSAPの画面イメージ付きで解説します。

文：アラディンテクノロジー編集部　監修：劉 瑞（代表取締役社長）

読了目安：約8分閲覧数：—

目次

  1. WHAT　なぜCAPが生まれたのか：BTP開発の複雑さとその解消
  2. POINTS　CAP開発で押さえる3つのポイント
  3. INSIGHT　CAPが変える「SAP×AI」の可能性
  4. FAQ　よくある質問
  5. 出典・参考

この記事のポイント

  • CAPはBTP上のオープンソース開発モデル（Apache 2.0）。CDS定義からOData API・Fiori UIを自動生成
  • Node.js（@sap/cds）とJava（Spring Boot）の2ランタイム。cds initから10分で動くAPIができる
  • S/4HANA拡張の標準は「スタック内=RAP、BTP上=CAP」。destination経由のRemote Serviceで安全に連携
SAP BTP Cockpit風のモックアップ。CAPで作った拡張アプリ「incidents-app」が稼働している様子
SAP BTP Cockpit風モックアップ：CAPで作った拡張アプリ「incidents-app」をサブアカウントにデプロイした状態（実データではなくイメージ）

WHAT　なぜCAPが生まれたのか：BTP開発の複雑さとその解消

SAP BTP上でアプリを開発する際、従来は言語・フレームワークの選定から、ODataサービスの実装、認証、DB接続、UI構築までをすべて手作業で行う必要がありました。この「土台づくり」に工数が取られ、本来作りたい業務ロジックに時間を使えないというのが、多くのプロジェクトに共通する課題でした。

CAP（Cloud Application Programming Model）は、この課題を解消するためにSAPが提供するオープンソースの開発モデル（Apache 2.0ライセンス・GitHub: sap/cap）です。データモデルをCDS（Core Data Services）という宣言的な言語で定義するだけで、データベース層・OData V4 API・Swagger UI・Fiori Elements UIが自動生成されます。サポートするランタイムはNode.js（@sap/cds）とJava（Spring Boot）の2つで、ローカル開発中はSQLite、本番ではSAP HANA CloudやPostgreSQLに接続し、Cloud FoundryまたはKyma（Kubernetes）へデプロイします。

CAP開発フロー — CDS定義だけでAPI・UIが自動生成される cds init プロジェクト作成 schema.cds データモデル定義 service.cds サービス公開 cds watch ローカル起動 OData V4 API Swagger UI Fiori Elements cds init から Fiori Elements 画面まで、最短10分
図1：CAP開発フロー。CDSでデータモデルとサービスを定義するだけで、OData API・Swagger UI・Fiori Elements UIが自動生成される

S/4HANAの拡張開発では「スタック内（on-stack）はRAP（ABAP RESTful Application Programming Model）、BTP上（サイドバイサイド）はCAP」という役割分担が標準です。S/4HANAのABAP環境を直接変更せず、BTP上に分離された拡張アプリを構築できるため、S/4HANAアップグレードの影響を受けにくいという利点があります。

RAP と CAP の役割分担 S/4HANA スタック内（on-stack） RAP ABAP RESTful Application Programming Model SAP BTP（サイドバイサイド） CAP Cloud Application Programming Model API疎結合 S/4HANA本体を直接変更しないため、アップグレードの影響を受けにくい
図2：RAPとCAPの役割分担。S/4HANA本体の拡張はRAP、BTP上の拡張アプリはCAPという疎結合構成が標準

POINTS　CAP開発で押さえる3つのポイント

  • ① 開発の流れ：cds init incidents-appでプロジェクトを作成 → db/schema.cdsでデータモデルを定義 → srv/service.cdsでサービスを公開 → cds watchでローカル起動。たったこれだけで http://localhost:4004 にOData v4のエンドポイントとSwagger UIが生まれ、cds add fioriでFiori Elementsの画面プレビューまで自動生成されます。10分もあれば「動くAPI」が完成します
  • ② 2つのランタイムとデプロイ先：Node.jsはExpressベースの@SAP/cds、JavaはSpring Bootベース。ビルドした成果物はCloud Foundryならcf push、Kubernetes環境ならKymaへデプロイします。マルチテナント対応（MTX）や監査ログ、認証（XSUAA）も標準機能として備わっています
  • ③ 既存SAPとの連携：Remote Serviceを使うと、S/4HANAやSAP SuccessFactorsなどのODataサービスをdestination経由で呼び出せます。cds importでS/4HANAのサービス定義をインポートし、顧客マスタや受注データを参照する拡張アプリを安全に構築できます。Enterprise Messagingを介したイベント連携で、業務イベントをトリガーにした非同期処理も可能です
BTPデプロイ構成 — 2つのランタイムと実行基盤 Node.js @sap/cds Java Spring Boot CAPアプリ XSUAA認証・MTX Cloud Foundry cf push Kyma Kubernetes HANA Cloud / PostgreSQL ローカル開発はSQLite → 本番はHANA CloudやPostgreSQLへ切り替えるだけ
図3：BTPデプロイ構成。Node.js/Javaで書いたCAPアプリをCloud FoundryまたはKymaにデプロイし、HANA Cloud等に接続する
S/4HANAとの安全な連携 — Remote Service と Enterprise Messaging CAPアプリ Remote Service cds import destination サービス（認証仲介） S/4HANA OData サービス CAPアプリ 非同期処理 Enterprise Messaging（業務イベント）
図4：S/4HANAとの安全な連携。同期取得はdestination経由のRemote Service、非同期のイベント連携はEnterprise Messagingを使う
SAP Business Application Studio風のモックアップ。CAPプロジェクトのサービス定義（service.cds）とcds watchの起動ログ
SAP Business Application Studio風モックアップ：service.cdsのサービス定義と、cds watchで自動起動するローカル環境（実データではなくイメージ）
SAP Fiori elements風のモックアップ。CAPから自動生成されたインシデント管理のList Report画面
SAP Fiori elements風モックアップ：CAPのサービス定義から自動生成されるList Report画面（実データではなくイメージ）

INSIGHT　CAPが変える「SAP×AI」の可能性

CAPの本質は「既存SAPのデータ資産を、モダンな開発手法で活用するための橋渡し」です。BTP上に分離された拡張アプリは生成AIやLLMと組み合わせる自由度が高く、ADTはこの領域で「SAP×AI」の支援を進めています。例えば、S/4HANAの受注・保守データをRAGの知識源にし、現場の問い合わせに答える社内CopilotをCAPで構築する、といった形です。機密データを外部に送らずに済むローカルLLMの活用方法は、ローカルLLMで実現する、安全なSAP×AI活用の記事で解説しています。

SAP×AI — CAPを起点にした社内Copilot構成イメージ S/4HANA 受注・保守データ CAP Remote Service ローカルLLM / RAG 社外にデータを送らない 社内Copilot 現場の問い合わせ対応 機密データは社内ネットワーク内のLLMで処理し、外部API・クラウドLLMには送らない構成
図5：SAP×AI構成イメージ。CAPがS/4HANAデータとローカルLLM/RAGの橋渡しとなり、機密データを外部に出さずにCopilotを構築する

S/4HANA移行を計画中の企業にとっては、移行後の拡張基盤としてCAPを位置づけることで、レガシーなカスタマイズの新規追加を防ぎ、標準化と拡張性を両立できます。移行プロジェクト全体の進め方は、S/4HANA移行、最初に押さえるべき5つのポイントをご覧ください。また、基幹業務データを扱う際の画面・データ設計の考え方は、SAP S/4HANA固定資産管理 ①資産を「買う」ときの記事も参考になります。

FAQ　よくある質問

CAPとRAPの違いは何ですか？

CAPはBTP上でNode.js/JavaとCDSを使うクラウドネイティブな開発モデル、RAPはS/4HANA内部でABAPを使う開発モデルです。S/4HANAスタック内の機能拡張はRAP、BTP上でのサイドバイサイド拡張はCAPが標準です。

CAPを学ぶのに必要な知識は？

JavaScript（またはJava）の基礎とCDSの考え方です。SAP GUIやABAPの経験は不要です。cds initでひな型を作り、cds watchで動かしながら学ぶのが最短ルートです。

CAPは無料で使えますか？

CAP自体はApache 2.0のオープンソースで、Node.js環境ならローカル開発は無料です。BTP上へのデプロイにはBTPアカウント（無料のトライアルあり）が必要です。公式ドキュメント cap.cloud.sap で一通り学べます。

出典・参考

※本記事は上記の公開情報をもとに、アラディンテクノロジー株式会社編集部が独自に整理・考察したものです。内容は執筆時点（2026-08-19）の情報です。考察部分は当社の見解であり、特定の製品・導入を推奨するものではありません。掲載の画面はSAPの画面を参考にしたモックアップ（イメージ）です。

関連記事

AIローカルLLMで実現する、安全なSAP×AI活用 SAP・移行S/4HANA移行、最初に押さえるべき5つのポイント SAP・FICOSAP S/4HANA固定資産管理 ①資産を「買う」ときシステムの中で何が起きているか

BTP × CAPによる拡張基盤づくり、
S/4HANA移行とあわせて検討しませんか

S/4HANA移行後の拡張基盤の設計、CAPでのPoC開発、SAP×AIのCopilot構築まで、ADTのSAPコンサルタントが支援します。ご相談・お見積りは無料です。

無料で相談する →
ABOUT

この記事について

執筆

アラディンテクノロジー株式会社 編集部

SAPコンサルティングとAI活用の現場知見をもとに、基幹業務のスマート化に役立つ情報をお届けしています。

監修

劉 瑞（リュウ ズイ）

代表取締役社長。SAP ABAP開発からコンサルティングまで15年、来日20年弱。「SAP×AI」の融合による価値創造に注力しています。

記事一覧に戻る