この記事のポイント
- RAPはS/4HANA本体（on-stack）でFiori対応OData APIをABAPで作る開発モデル
- 振る舞い定義→実装→サービス定義→サービス公開の4層構造でアプリが組み上がる
- Managed（標準永続化）とUnmanaged（既存ロジック活用）の2シナリオがある
- S/4HANA本体内の拡張はRAP、BTP上のサイドバイサイド拡張はCAPという役割分担が標準
01WHAT RAPとは何か、なぜ必要とされるのか
RAP（ABAP RESTful Application Programming Model）は、SAPが提供するモデル駆動型のABAP開発モデルです。CDS（Core Data Services）でデータモデルを定義し、そこに「振る舞い（Behavior）」を宣言的に追加することで、Fiori Elements UIとOData V4 APIを備えたアプリケーションをS/4HANA本体の中に構築できます。バリデーションや自動採番などの業務ロジックをABAPクラスに実装し、標準のフレームワークが永続化・トランザクション処理を肩代わりする点が特徴です。
なぜ従来のABAP開発から置き換わったのか
従来のクラシックABAP開発（BAPIやモジュールプールなど）は自由度が高い反面、S/4HANAアップグレード時に非互換の内部APIへ依存してしまうリスクがありました。RAPはリリースされたAPI（Released API）のみに依存することを前提に設計されており、SAPが将来のアップグレードでも互換性を保証する範囲内でアプリを組み立てられます。これにより、拡張アプリがS/4HANAのバージョンアップに巻き込まれて壊れるリスクを大きく減らせます。
Managed と Unmanaged、2つのシナリオ
RAPには「Managed」と「Unmanaged」の2つのシナリオがあります。Managedはデータの永続化（保存・更新・削除）をフレームワークに任せる標準パターンで、新規開発の第一選択です。Unmanagedは、既存のBAPIやファンクションモジュールなど、すでにある業務ロジックをRAPの皮をかぶせて再利用したい場合に使います。既存資産を活かしながらFiori化したいケースで重宝します。
用語補足：on-stack と released API
「on-stack」はS/4HANA本体の中で動くことを指す。RAPが依拠する「released API」は、SAPが将来のバージョンでも互換性を保証すると明言したAPI群のことで、これに限定して開発することが拡張のアップグレード耐性を生む。
02POINTS RAPアプリを作る5ステップ
- ①CDSビューでデータモデルを定義取得したいデータの構造をCDS（Core Data Services）で宣言的に定義する。テーブルやビューを組み合わせてルートエンティティを決める。
- ②振る舞い定義を追加
managedキーワードを付けて振る舞い定義（Behavior Definition）を作成し、作成・更新・削除などの操作を宣言する。 - ③振る舞いを実装バリデーション・決定（Determination）・アクションなどの業務ロジックをABAPクラスに実装する。標準の永続化処理はフレームワークが自動生成する。
- ④サービス定義・サービス公開公開したいエンティティをサービス定義にまとめ、サービス公開（Service Binding）でOData V4のエンドポイントとFiori Elementsのプレビューを有効化する。
- ⑤SAP Business Application StudioやFiori Elementsプレビューで確認生成された画面と挙動を確認し、必要に応じてFiori注釈（Annotation）でUIをカスタマイズする。
アップグレード耐性を保つコツ
RAPで開発する際は、必ずreleased APIのみを参照するように意識する。SAP API Business Hubでオブジェクトのリリース状況を確認する習慣をつけておくと、将来のS/4HANAバージョンアップ時に手戻りが発生しにくい。
03INSIGHT RAPとCAP、どちらを選ぶべきか
RAPとCAPはどちらもモダンなSAP拡張開発モデルですが、動く場所が異なります。RAPはS/4HANA本体の中（on-stack）で動き、既存のABAPオブジェクトや権限モデルと密接に統合したい場合に向いています。一方CAPはBTP上（サイドバイサイド）で動き、Node.js/Javaの自由度や非SAPデータソースとの連携、S/4HANA本体を直接変更したくない場合に向いています。CAPの詳しい仕組みはSAP BTP CAP入門：Cloud Application Programming Modelで作るS/4HANA拡張アプリで解説しています。
実際のプロジェクトでは、どちらか一方だけでなく、両方を組み合わせるケースも珍しくありません。例えばS/4HANA本体内の入力チェック強化はRAPで、複数システムを横断するダッシュボードはBTP上のCAPで、という役割分担です。S/4HANA移行プロジェクトでは、既存のカスタマイズをRAPとCAPのどちらに振り分けるかが標準化のカギになります。移行プロジェクト全体の進め方はS/4HANA移行、最初に押さえるべき5つのポイントをご覧ください。
豆知識：RAPの前身
RAPが登場する前、S/4HANAの拡張にはBOPF（Business Object Processing Framework）という内部フレームワークが使われていた。RAPはBOPFの思想を引き継ぎつつ、CDSとABAP RESTfulの考え方を統合してよりシンプルなモデルとして再設計されたものといえる。
まとめ
- RAPはS/4HANA本体でFiori対応OData APIをABAPで作る開発モデル
- CDSビュー→振る舞い定義→振る舞い実装→サービス公開の4ステップでアプリが組み上がる
- Managed（標準永続化）とUnmanaged（既存資産再利用）の2シナリオがある
- released APIのみに依存することで、S/4HANAアップグレードへの耐性を確保する
- S/4HANA本体内の拡張はRAP、BTP上のサイドバイサイド拡張はCAPという役割分担が基本
04FAQ よくある質問
RAPとクラシックABAP開発の違いは何ですか？
クラシック開発は自由度が高い反面、内部APIへの依存でアップグレード時に壊れるリスクがあります。RAPはreleased APIのみに依拠し、CDSと振る舞いの宣言的な定義でアプリを組み立てるため、アップグレード耐性と開発生産性の両方が向上します。
ManagedとUnmanagedはどう使い分けますか？
新規開発は基本的にManagedを選び、永続化処理をフレームワークに任せます。既存のBAPIやファンクションモジュールを活かしたい場合はUnmanagedで、既存ロジックをRAPの構造に載せ替えます。
RAPを使うにはクラウド版のABAP（Steampunk）が必要ですか？
いいえ。RAPはオンプレミス版のS/4HANA（ABAP Platform）でも、SAP BTP ABAP Environment（通称Steampunk）でも利用できます。クラウド版の方がreleased APIの制約がより厳格です。
RAPを学ぶには何から始めればいいですか？
まずは簡単なCDSビューにManagedの振る舞い定義を追加し、サービス公開までを一通り流してFiori Elementsプレビューで動きを確認するのが近道です。SAP公式のRAP100などのチュートリアルも公開されています。
出典・参考
- SAP Help Portal — ABAP RESTful Application Programming Model（SAP） https://help.sap.com/docs/abap-cloud
- SAP Community — ABAP RESTful Application Programming Model（SAP） https://community.sap.com/topics/abap-restful-application-programming-model
※本記事は上記の公開情報をもとに、アラディンテクノロジー株式会社編集部が独自に整理・考察したものです。内容は執筆時点（2026-08-19）の情報です。考察部分は当社の見解であり、特定の製品・導入を推奨するものではありません。