SAP BTP 上のアプリケーション開発：概要と機能マップ

JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

May 10, 2026 · 20 min read

本記事の位置づけ#

参考資料#

1) アプリケーション開発のランドスケープ#

SAP BTPには単一の「開発ツール」はありません。異なる開発者ペルソナと異なるランタイムを中心に構築された4つのファミリーがあります。これらを互換可能なものとして扱うことは、この分野における要件定義段階で最もよくある誤りです。

これらは代替手段ではありません。Build AppsのノーコードプロジェクトがCAPサービスになることはなく、ABAP Cloud拡張機能を書き換えなしにBuild Codeマイクロサービスとして再パッケージ化することもできません。ファミリーの選択は、アセットのライフサイクル全体にわたって一方通行の判断であり、要件定義段階で行うべきものです。

2) S/4HANA への接続方法#

すべてのBTP開発ファミリーはS/4HANAと通信しますが、方向性、結合、および契約は異なります。

                         SAP BTP — Application Development
   ┌────────────────────────────────────────────────────────────────────┐
   │  Pro Code:    Build Code / BAS / CAP   ─── Cloud Foundry / Kyma    │
   │  Low Code:    Build Apps / Build Process Automation                │
   │  ABAP:        BTP ABAP Environment (Steampunk, side-by-side)       │
   │  Portal:      Build Work Zone (standard + advanced)                │
   └────────────────────────────┬───────────────────────────────────────┘
                                │ Released APIs, OData, events
                                ▼
   ┌────────────────────────────────────────────────────────────────────┐
   │  S/4HANA Cloud (public or private edition)                         │
   │  ┌──────────────────────────────────────────────────────────────┐  │
   │  │  Embedded Steampunk (in-stack ABAP extensions, tight-coupled)│  │
   │  └──────────────────────────────────────────────────────────────┘  │
   └────────────────────────────────────────────────────────────────────┘
                                ▲
                                │ Released APIs (RFC where still allowed)
                                │ via SAP Cloud Connector
   ┌────────────────────────────┴───────────────────────────────────────┐
   │  S/4HANA on-premise                                                │
   └────────────────────────────────────────────────────────────────────┘

重要ポイント: サイドバイサイドのBTP開発はS/4HANAのアップグレードサイクルから切り離されており、任意の言語を使用できます。一方、組み込み型（インフラ内）ABAPは密結合であり、ABAPのみが使用可能です。この線引きを誤ると、アップグレードを妨げる拡張機能や、コアから乖離する拡張機能が生まれます。

3) 成熟度マップ#

4) 要件チェックリスト#

各ファミリーには、コミットする前にクリアすべき異なる質問セットがあります。これらをゲート項目として扱ってください。要件段階で1行でも未回答のままの場合、そのプロジェクトは設計に入る準備ができていません。

Pro Code (Build Code、BAS、CAP)#

ローコード / ノーコード（アプリ構築、プロセス自動化構築）#

ABAP（BTP ABAP環境 + Embedded Steampunk）#

ポータル（Build Work Zone）#

5) 意思決定基準#

最初に問うべき3つの質問#

Q1. 新しいアプリが解消すべき測定可能な非効率性は何ですか？

測定可能な出発点（週あたりの時間、フルタイム換算コスト、エラー率、顧客待ち時間）がなければ、「近代化しよう」という提案は最終的に資金を失います。この質問は、ツール名を挙げる前に具体的な数値を強制します。

Q2. データはS/4HANAコアのどちら側に存在しますか？

ロジックが標準のS/4HANAテーブルや標準ビジネスオブジェクトのカスタムフィールドに対して直接動作する場合、正しい答えはインフラ（Embedded Steampunkまたはキーユーザー拡張性）です。一方、コア外のデータ（パートナーデータ、IoTデータ、顧客向けポータルなど）に対して主に動作する場合は、BTP上でのサイドバイサイドが正解です。

Q3. このアプリの今後3年間の所有者は誰ですか？

プロコードのCAPプロジェクトに恒久的なオーナーがいない場合、ローコードアプリよりも早くレガシー化します。スポンサーのいない市民開発アプリはシャドーITと化します。アップグレードテストのオーナーがいないABAP拡張機能は、アップグレードの阻害要因となります。オーナーを明確に指定することが、その成否を分ける鍵です。

プロジェクトコンテキストによるドメイン選択#

ライセンスとコスト#

6) よくある障害#

障害1: すべてにSAP Buildを選択する

“SAP Build"はマーケティング上の総称であり、単一の製品ではありません。「Build」と言いながらApps、Code、Process Automation、Work Zoneを明示しないチームは、誤ったサブスクリプションを調達することになります。要件段階でファミリーとツールの選択を強制し、それをチャーターに明記してください。

障害 2: Embedded Steampunk が適している場合のサイドバイサイド

S/4HANA標準テーブルへのカスタムフィールドは、ほとんどの場合Embedded Steampunkで実現可能であり、S/4HANA Cloudの権利に含まれています。BTP上で構築するとクレジットを消費し、機能的なメリットがないままデータのラウンドトリップが発生します。引き金となるフレーズ：「単なるカスタムフィールドである拡張機能にBTPクレジットを支払っている」

障害 3: Kubernetes オペレーションなしの Kyma

Kymaは真のクラウドネイティブですが、それはKubernetesです — ノードプール、RBAC、ネットワークポリシー、可観測性。モダンに聞こえるからという理由で、他でKubernetesを運用した経験がないままこれを選んだチームは、開発時間の短縮効果を運用のトラブル対応で失うことになります。Cloud Foundryは、引き続きより安全なデフォルトの選択肢です。

障害 4: 記録システム向けのシチズン開発アプリ

Build Appsは、部門ツールやプロトタイプに最適です。しかし、市民開発者が構築したアプリがマスタデータを管理したり、監査対象となるトランザクションを生成したり、財務報告にデータを提供するようになった場合、それはもはや市民開発アプリではありません。明確に文書化された「廃止または昇格」ルールを適用してください。定義された閾値に達した時点で、IT部門がプロコード系の技術で再構築します。

失敗5：プロセスマップなしでのプロセス自動化

Build Process Automationは、与えられたプロセスを増幅させるものです。プロセスが文書化されていない場合、自動化は混乱を拡大し、不透明な依存関係を生み出します。SBPAのスコープに対する入力として、文書化されたプロセスマップを要求することは、最も低コストの防御策です。

障害 6: BTP クレジット予算が12ヶ月目ではなく1ヶ月目に紐づけられている

初日は何も稼働していないため、クレジットは余裕があるように見えます。しかし12か月目になると、HANA Cloud、Joule呼び出し、Build Appsフロントエンドを備えたイベント駆動型CAPアプリが、パイロットの想定よりも速くクレジットを消費します。最初から商用ケースに12か月目の曲線を組み込んでください。

障害 7: アップグレード全体でABAP拡張機能に対するオーナーシップがない

Embedded Steampunk 拡張機能は、S/4HANA Cloud の四半期ごとのリリースサイクルに従います。各リリース候補に対して ATC チェックと回帰テストを実行する指名された所有者がいない場合、稼働開始時に機能していた拡張機能が、2年目にはアップグレードの妨げとなります。

FAQ#

Q: オンプレミスのSAPユーザーはこれらのBTP開発ファミリーを利用できますか？

はい。BTP開発は、ソースシステムがS/4HANA CloudかS/4HANA on-premiseかに依存しません。サイドバイサイドパターン（CAP、ABAP環境、Build Apps）はすべて、SAP Cloud Connectorと公開APIを通じてオンプレミスシステムと連携します。Embedded SteampunkのみがS/4HANA Cloudを必要とします。これは、そのランタイム内部で動作するためです。

Q: ライセンスはどのように機能しますか — 請求は1つですか、それとも複数ですか？

商業モデルによって異なります。BTPEA（BTP Enterprise Agreement）では、ほとんどのBTP開発サービスが単一のクレジットプールを共有し、サービスのアクティベーションに応じてそこから引き落とされます。スタンドアロンサブスクリプション（BAS、一部のBuildエディション）は別途請求されます。HANA Cloudは、BTPEA内であってもほぼ常に別ラインとして請求されます。契約前に、クレジット＋サブスクリプション＋データベースの合計をモデル化してください。

Q: いつ開発ファミリーをプロジェクトからスコープ外にすべきですか？

Q1（測定可能な課題）で「最新化したい」と回答があり、数値が示されない場合は対象外とする。Q3（3年間の責任者）で「後で決める」と回答された場合も対象外とする。チームが問題の要件ではなく、自身の知識に基づいてファミリーを選択している場合は、アーキテクチャリーダーにエスカレーションし、制約を明示的に文書化する。

Q: 開発ファミリー要件を適切に文書化するにはどうすればよいですか？

プロジェクト憲章では、アセットごとに1行で記述します。
アセットXは、ファミリーY、ツールZ、ランタイムRを使用し、所有者はO、使用プロファイルPに合わせてサイジングされています。
5つのフィールド、1行です。空のフィールドは、要件が未確定であることを意味します。長いドキュメントはギャップを隠しがちです。

Q: 開発者向けJouleは初日から必要ですか？

いいえ。JouleはコアシナリオにおいてGA（一般提供）であり、SAPが公表する効率向上（執筆時間約20%、テスト時間約25%）は現実のものですが、4つのファミリーのいずれにおいても必須の前提条件ではありません。Jouleは、開発プラクティス自体が既に健全である場合にチームが採用するアクセラレーターとして捉えてください。CI/CDやテスト規律のないチームにJouleを導入しても、根本的な問題は解決されません。

Q: Clean Core 拡張性はこれらのファミリーにどのように対応しますか？

クリーンコア「レベルA」とは、カスタムコードがデジタルコアの外部に存在し、公開されたAPIやイベントを介してアクセスされることを意味します。4つのファミリーすべてが、正しく使用されればレベルAの拡張機能を生成できます。ABAP Cloud（インフラまたはサイドバイサイド）、CAP、SAP Buildはすべて該当します。ファミリーの選択は、チームとユースケースに基づくものであり、クリーン度の評価自体に基づくものではありません。

概要#

SAP BTPのアプリケーション開発領域は、Pro Code、Low-Code、ABAP、Portalの4つのファミリーで構成されています。各ファミリーは、特定の開発者ペルソナ、ランタイム、および商用ラインに対応しています。これらは互換性がなく、ファミリーの選択は各アセットのライフタイムにおいて一方通行の決定となります。

2026年には、すべてのファミリーが本番環境に対応します。プロコードにはCloud Foundry、ABAPチームにはBTP ABAP Environmentが最も安全なデフォルトとして残ります。Kymaは、すでにKubernetesを運用しているお客様にメリットをもたらします。Joule for Developersは、開発プラクティスがすでに健全なチームの開発を加速します。

コンサルタントの役割は、「すべてにSAP Buildを使おう」という提案を断り、一つの測定可能な課題を一つのファミリーに変換し、別の課題が現れるまでその他を先送りすることです。B02からB08では、各ファミリーを個別に掘り下げ、B08で意思決定パターンに収束させます。

次に読むべきもの#