ABAP Cloud入門｜Clean Core時代の新しいABAP開発モデルとReleased API

はじめに：従来ABAPが抱えていた課題

S/4HANAの登場、そしてS/4HANA Cloudへの移行が進む中で、長年SAPの拡張を支えてきた従来のABAP開発モデルは大きな転換点を迎えています。オンプレミスのECC時代には、SAP標準テーブルを直接SELECTし、標準FunctionやBAPIを呼び出し、ユーザーエグジットでロジックを差し込む——こうしたやり方が当たり前でした。しかしこの「自由度の高さ」こそが、アップグレードを困難にし、保守コストを膨張させ、結果としてSAPのバージョンアップを「数年がかりの大プロジェクト」に変えてしまったのです。

why so：標準オブジェクトに依存したアドオンは、SAPがその標準を変更するたびに動かなくなります。so what：「アップグレードしやすいSAP」を実現するには、標準への依存を切り離し、SAPが安定的に維持を保証するインターフェースだけを使う仕組みが必要になります。これがClean Core戦略であり、その技術的な実装手段がABAP Cloudです。

本記事では、ABAP Cloudとは何か、Released APIとはどういう考え方か、そして従来のクラシックABAPからどう移行していけばよいかを、実務の観点で整理します。

ABAP Cloudとは：3層モデルで理解する

ABAP Cloudは単なる「クラウド版ABAP」ではありません。正確には、Clean Coreを実現するための開発モデルそのものの再定義です。SAPはABAP開発を3つの層に整理しました。

ポイントは、最上位の「ABAP Cloud」層ではSAPがReleased（公開）と宣言したAPIだけしか使えないという強い制約があることです。why so：SAPがリリース管理しているオブジェクトだけを使えば、SAPはその後方互換性を保証できます。so what：開発者は「アップグレードで壊れるかもしれない不安」から解放され、SAPは安心して標準の内部実装を改善できます。両者にとってwin-winの構造になっているわけです。

逆に言えば、この層では従来当たり前だった「VBAKをそのままSELECT」「MM_PUR_PO_CREATEを直接呼び出す」といったコードは書けません。代わりに、リリース済みCDSビューやリリース済みクラスを経由してデータにアクセスします。

Released APIの考え方

Released APIとは、SAPが「このオブジェクトは安定版として外部から使ってよい」と公式に宣言したインターフェースのことです。対象となるのはCDSビュー、ABAPクラス、インターフェース、Function、ドメイン、データ要素など多岐にわたります。

ADT（ABAP Development Tools）のRepository Treeでは、Released状態のオブジェクトに専用アイコンが付き、コード補完でも非Releasedオブジェクトは赤くハイライトされて使えません。SAPは「CDSビュー基礎」で解説したCDSビューを中心に、I_BusinessPartner、I_ProductなどのInterface Viewを公式APIとして整備しており、これがClean Core開発のデータアクセスの中心になります。

why so：SAP標準テーブル（KNA1、MARAなど）はHANA移行や機能拡張の都度内部構造が変わる可能性があります。so what：直接SELECTせず、I_*のCDSビュー越しに読むことで、テーブル構造が変わってもCDS側でSAPが吸収してくれるため、アドオンは動き続けます。

Released APIはSAP API Business Hub（現SAP Business Accelerator Hub）でも検索できるため、開発前に「やりたいことを実現できるAPIが既にあるか」を必ず確認するのが定石です。

開発環境：ADT（Eclipse）が必須

ABAP Cloud開発では、従来のSE80やSE38は使えません。開発はすべてEclipseベースのADT（ABAP Development Tools）で行います。

why so：CDSビュー、Behavior Definition、Service Bindingといった新しい開発オブジェクトはテキストベースで定義するため、SE80のフォーム型UIでは扱えません。so what：開発者はEclipseのワークスペース概念、プロジェクト管理、Gitライクな差分確認に慣れる必要があります。最初は戸惑いますが、コード補完・リファクタリング・シンタックスチェックの強さは旧来のSE80と比較になりません。

ADTでは、Released APIへのアクセス制御、ATC（ABAP Test Cockpit）によるClean Coreチェック、リリース契約の確認などが統合されており、「Clean Coreを破るコードはそもそもsyntax errorで弾かれる」という強制力が働きます。

主要構成要素：RAP / CDS / Behavior Definition

ABAP Cloudの中核技術がRAP（RESTful Application Programming Model）です。RAPは「データモデル」「ビジネスロジック」「サービス公開」を明確に分離するフレームワークで、以下の3つの構成要素から成り立ちます。

flowchart LR
  A[CDS View
データモデル] --> B[Behavior Definition
振る舞い定義]
  B --> C[Behavior Implementation
ABAPクラス]
  A --> D[Service Definition
公開項目]
  D --> E[Service Binding
OData/REST]
  E --> F((Fiori/外部))

CDSビューがデータの構造とリレーションを定義し、Behavior Definition（BDEF）がそのデータに対する作成・更新・削除・アクションといった「振る舞い」を宣言的に記述します。実際のロジックはBehavior Implementationクラス（ABAP OO）に書きます。Service DefinitionとService Bindingを経由すれば、同じデータモデルからOData V2/V4、REST、SQLなど複数のチャネルで公開できます。

why so：従来のABAPでは画面・ロジック・データが密結合していました。so what：RAPで層を分離することで、同じビジネスロジックをFiori UIにもAPIにも再利用でき、テストも層ごとに書けるようになります。

RAPの構成要素（Interface View / Projection View / Behavior Definition / Service Definition / Service Binding）と、VDMとの棲み分けについてはABAP CDSの全体像 — VDMとRAPの違い・棲み分けを理解するで詳しく整理しています。BTP側のSide-by-Side拡張フレームワークであるCAPについてはSAP CAP入門もあわせて参照してください。

なお、RAPで書くロジックの中身は依然としてABAP OOです。性能を意識した書き方の基本は変わらないため、ABAPパフォーマンスチューニングで解説した「内部テーブルキー設計」「FOR ALL ENTRIESの罠」などの知識はそのまま活きます。

従来ABAPからの移行アプローチ

既存のクラシックABAPアドオンを一気にABAP Cloudに書き換えるのは現実的ではありません。SAPが推奨する移行ステップは次の通りです。

第一段階はATCによる現状分析です。ABAP Test Cockpitに「ABAP Cloud Migration」用のチェックバリアントが用意されており、既存コードのうち「非Releasedオブジェクトを使っている箇所」を一覧化できます。これをもとに移行対象の規模感をつかみます。

第二段階は、非Releasedな依存を1つずつReleased APIに置き換える作業です。例えばVBAKのSELECTをI_SalesOrderのSELECTに、BAPI_SALESORDER_CREATEFROMDAT2をI_SalesOrder用のEMLステートメント（RAPのビジネスロジック実行命令）に置き換えます。代替APIが見つからない場合は、SAPに「Influence」サイト経由でリリースリクエストを出すことができます。

第三段階は、新規開発はすべてABAP Cloud層で書くというルールの徹底です。古いコードは段階的にリファクタしつつ、新規分は最初からClean Coreで作る——この二段構えが現実解です。

MM BAdI実装ガイドで扱ったような従来のBAdI実装も、S/4HANAではCloud BAdI（Released BAdI）に置き換えが進んでおり、Key User Extensibility画面から実装できるものも増えています。

拡張ティア：3つの拡張パターンを使い分ける

ABAP Cloud時代の拡張は、用途に応じて3つのティアから選びます。

flowchart LR
  subgraph On-Stack拡張
    A[Key User
Extensibility] --> B[Developer
Extensibility]
  end
  subgraph Off-Stack拡張
    C[Side-by-Side
BTP ABAP Env]
  end
  B -.-> C
  S4((S/4HANA Core)) --- A
  S4 --- B
  S4 -.イベント/API.-> C

Key User Extensibilityは、ブラウザ上のFiori画面でカスタム項目・カスタムロジックを追加できる仕組みで、業務部門のキーユーザーでも扱えます。簡易な拡張はまずここで検討します。

Developer Extensibilityは、S/4HANA Cloud Private Edition上で本格的なABAP Cloud開発を行う層です。ADTから接続し、Released APIだけを使ってアドオンを構築します。これが従来の「アドオン開発」の正統な後継です。

Side-by-Side拡張は、SAP本体には一切手を入れず、SAP BTP入門で解説したBTP ABAP Environment（旧Steampunk）上に拡張アプリを構築するパターンです。why so：本体にコードを置かないため、S/4HANAのアップグレードが拡張に一切影響しません。so what：頻繁に変更したい業務ロジックや、外部システム連携、複数のSAPシステムを横断する処理は、Side-by-Sideに置くのが原則となります。

逆に言えば、これらを使い分けずに何でもCoreに書いてしまうと、Clean Coreの理念は崩壊します。「まずKey User、無理ならDeveloper Extensibility、それでも無理ならSide-by-Side」という拡張判断のフローを組織のルールとして定着させることが重要です。

よくある疑問（FAQ）

Q1. オンプレミスのS/4HANAでもABAP Cloudは使えますか？ A. はい。S/4HANA 2022以降、オンプレミス/Private Editionでも「ABAP Cloud Development Model」が利用可能です。新規開発はABAP Cloud層で、既存アドオンはClassic層で並走させる構成が標準です。

Q2. SE80はもう使えなくなりますか？ A. クラシックオブジェクトの保守用としては当面残りますが、新規開発では使いません。CDSやBDEFはSE80では編集不可能なため、ADTへの移行は事実上必須です。

Q3. Released APIに必要な機能がない場合は？ A. SAPのCustomer Influenceサイトでリリース要望を出すのが正規ルートです。投票数が多い要望はSAPがリリース対応します。暫定的にはWrapper Classで隔離し、将来差し替えやすくしておくのが定石です。

Q4. RAPとBOPF（旧Business Object Processing Framework）の関係は？ A. BOPFはRAPの登場で役目を終えました。新規開発はRAP一択です。

Q5. Clean Coreを徹底すると開発の自由度が下がりませんか？ A. 短期的にはYesです。しかし、アップグレードコスト・保守コスト・属人化リスクを5年スパンで見ると、Clean Coreの方が圧倒的にTCOが下がります。「今書きやすいか」ではなく「3年後に維持できるか」で判断するのがポイントです。

ABAPそのものの基礎を固めたい人へ

この記事ではClean Core時代の新しい開発モデル（ABAP Cloud / RAP / CDS）を扱いましたが、そもそもABAP自体の文法・SE11/SE38の使い方・内部テーブル・ABAPディクショナリといった足場が曖昧なままだと、RAPやCDSに進んでも腑に落ちにくい部分が出てきます。AIに断片的に質問していくのも効率的ですが、語彙と全体構造を一度紙の本で押さえておくと、その後の学習や質問の精度が大きく変わります。

腰を据えて1冊やるなら、アレグス株式会社・久米正通氏の『SAP ABAPプログラミング入門』が章立ても業務寄りでまとまっています。古典的なABAPの基礎をひと通り体系化してくれているので、この記事のような新しい話題に進む前のベースづくりに向いています。

まとめ

• ABAP CloudはClean Coreを実現するための新しいABAP開発モデルで、3層モデル（Cloud / Cloud API Enabled / Classic）で整理される
• 最上位のABAP Cloud層ではReleased APIだけが利用可能で、SAPが後方互換性を保証する
• 開発環境はEclipseベースのADTが必須で、Clean Core違反はsyntax errorとして弾かれる
• 中核技術はRAPで、CDSビュー・Behavior Definition・Service Bindingで層を分離する
• 既存アドオンの移行はATCによる影響分析→Released API置き換え→新規はCloud層で書くの三段構え
• 拡張はKey User → Developer Extensibility → Side-by-Sideの順で検討し、Coreに不要なコードを置かない
• 「今の書きやすさ」より「3年後の維持しやすさ」で技術選定する姿勢が、Clean Core時代の開発者に求められる

ABAP Cloudへの移行は単なる技術移行ではなく、開発文化の転換でもあります。最初のハードルは高く感じられますが、一度身につければアップグレード対応の負担が劇的に軽くなり、SAPの新機能をいち早く享受できるようになります。まずは小さなRAPアプリを1本作ってみることから始めるのがおすすめです。

ABAP CloudやRAPの最初の一歩を踏み出すなら、ABAP基礎からBTP CAPM・RAP・OData・UI5 Fioriまでカバーした実践講座で実際にコードを書きながら学ぶのが最短ルートです。全335レクチャーでClean Core時代の開発スキルを一気に習得できます。