SAP BTP(SAP Business Technology Platform)は、S/4HANAの外側で拡張アプリ・システム連携・データ処理を動かすSAPのPaaSです。この記事では、クリーンコアの考え方で拡張をBTPへ置く理由と、Cloud Foundry・ABAP・Kymaの環境の選び方、トライアルとFree Tier・BTPEA・PAYGの料金モデルの違いを整理します。そのうえで、CAP(Node.js 10系・2026年10月時点)を使い、S/4HANAの業務APIを取り込んだ拡張アプリをCloud Foundryへデプロイするまでを、ローカルでの起動から本番構成の追加まで実行コマンドで示す構成です。最後に、BTPに置くべき拡張と見送るべき場面の線引きを言い切ります。
まとめ:SAP BTPは拡張の置き場所で、CAPとFree Tierから試すのが近道
SAP BTPは「S/4HANA本体を改造せずに、外で作る」ための実行基盤です。本体には標準とリリース済みAPIだけを残し、独自の画面・複数システムをまたぐ処理・AIの組み込みはBTP側へ逃がします。こうしておくと、S/4HANAのバージョンアップで独自コードが壊れる範囲を小さく保てます。
実装者が最初にやることは2つです。会社で触るならFree Tier、個人の学習ならトライアルのアカウントを作る。ローカルに@sap/cds-dkを入れて、CAPでサービスを1本起動する。本番化はcf CLIとMTAビルドツールを揃えてcds upを実行する流れで、必要なコマンドはCAPの公式ガイドにまとまっています。費用は契約モデルとサービスプランで決まるため、構成が固まってからDiscovery Centerで積み上げてください。
SAP BTPとは何かをクリーンコアと拡張の置き場所から整理する
BTPを機能一覧で覚えても、設計の場面では役に立ちません。S/4HANAの拡張をどこに置くか、という問いの答えの1つとして捉えると位置づけがはっきりします。
S/4HANAの外で拡張・連携・データ処理を動かすPaaSという位置づけ
BTPは旧SAP Cloud Platformの流れをくむPaaSで、アプリの実行環境に加え、認証、宛先(destination)管理、SAP HANA Cloud、連携、ワークフローなどの機能をサービス単位で提供します。利用者はグローバルアカウントの下にサブアカウントを切り、サブアカウントごとに環境とサービスを有効にして使います。
SAP Learningのサイドバイサイド拡張の解説は、この種の拡張は「S/4HANA Cloud上ではなくSAP BTP上で動く」と明記しています。S/4HANAのデータはリモートAPIで読み書きし、BTP側で他のサービスや外部データと組み合わせる構成です。S/4HANA本体の導入形態やECCとの違いはSAP S/4HANAの導入形態と移行方式の解説で整理しています。
クリーンコアで拡張をキーユーザー・開発者・サイドバイサイドへ振り分ける基準
クリーンコアは、S/4HANA本体への改造(モディフィケーション)をやめ、拡張を決められた3つの置き場所に振り分ける考え方です。BTPが受け持つのはそのうち1つだけで、すべての拡張をBTPへ出すわけではありません。
| 置き場所 | 動く場所 | 向いている拡張 |
|---|---|---|
| キーユーザー拡張 | S/4HANA本体 | 項目追加・画面の表示調整・簡単なロジック |
| 開発者拡張(ABAP Cloud) | S/4HANA本体 | 本体のデータと密に結合する処理 |
| サイドバイサイド拡張 | SAP BTP | 独立した業務アプリ・複数システム連携・AI |
判断の軸は「S/4HANAのデータは要るが、S/4HANAの実行環境は要らないか」です。前述のSAP Learningも、この条件を満たす処理をサイドバイサイドの候補としています。逆に、本体のトランザクションと同じ論理単位で更新したい処理は、BTPへ出すと整合性の担保が重くなります。
Cloud Foundry・ABAP・Kymaの3環境を開発言語と既存資産で選ぶ方法
BTPのアプリ実行環境は、主にCloud Foundry・ABAP環境・Kymaの3つです。どれを選ぶかは、チームの言語と既存資産でほぼ決まります。
| 環境 | 主な言語・方式 | 選ぶ場面 |
|---|---|---|
| Cloud Foundry | Node.js・JavaのCAP | Web系エンジニア中心で拡張アプリを作る |
| ABAP環境 | ABAP Cloud・RAP | ABAP資産と人材を活かして作る |
| Kyma | Kubernetes上のコンテナ | 既存のコンテナ運用基盤に寄せたい |
ABAP環境はSAPのABAP向けPaaSで、SAP HANAデータベースが同梱され、開発にはEclipse版ABAP Development Toolsを使います。ABAPの言語仕様とADTの準備はABAPの特徴と実装の解説に譲り、本記事はWeb系エンジニアが入りやすいCloud FoundryとCAPで手順を進めます。
SAP BTPを試すアカウント選び:トライアル・Free Tier・契約モデルの違い
BTPのアカウントには、個人向けのトライアルと、企業契約にひもづくEnterpriseの2種類があります。どちらで始めるかで、使えるサービスプランと期限が変わります。
トライアルは合計90日で削除、Free Tierは本番アカウント内で期限なし
SAP Developersのトライアルのツアーによると、トライアルは合計90日まで使え、30日で一度停止します。停止時に表示される「Extend Trial」で延長でき、90日を過ぎるとアカウントは削除されます。用途は個人の検証で、本番利用やチーム開発は対象外です。
会社で評価するならFree Tierを選びます。Free Tierの申し込み手順では、Free Tierのプランだけを有効にしていれば期限なしで無料で使え、データを保ったまま有償プランへ切り替えられると説明しています。注意点は、Enterpriseアカウントの中に作るため有償プランも選べてしまうことです。Cloud Foundryを有効にするときにfreeプラン以外を選ぶと課金が始まります。
BTPEA・CPEA・PAYG・サブスクリプションの4モデルの課金条件
Enterpriseアカウントの契約モデルは、消費型3種とサブスクリプション型に分かれます。Enterpriseアカウントの入門に書かれた条件を並べると次のとおりです。
| モデル | 支払い方 | 押さえる条件 |
|---|---|---|
| BTPEA | 前払いのクラウドクレジット | 最低投資額あり・超過分は定価で後払い |
| CPEA | 前払いのクラウドクレジット | 2024年4月15日以降は既存契約のみ |
| PAYG | 使った分を月次請求 | 初期費用・最低利用額なし・3か月ごとの自動更新 |
| サブスクリプション | サービスごとの固定費 | 契約した上限まで・増やすときは契約変更 |
BTPEAは2024年4月にCPEAの後継として導入され、以後の新サービスはBTPEA側にだけ追加されます。新規で複数サービスを使う見込みならBTPEA、まず1〜2サービスを小さく動かすならPAYGが入口になります。BTPEAのグローバルアカウントはNeo環境に対応しないため、Neo上の古いアプリを抱えている場合は移行計画とセットで契約を決めてください。RISE with SAPの契約に含まれるBTPの範囲はRISE with SAPの契約範囲と責任分界で確認できます。
Discovery Centerでサービスプラン単位に費用を積み上げる見積もり手順
BTPの費用は「BTPの料金」という1つの値ではなく、有効にしたサービスのプランごとの消費量の合計です。SAP Discovery Centerでサービスを選ぶと、プランの種類、Free Tierの有無、課金の単位を確認できます。
- 構成図からサービスを洗い出す(Cloud Foundryランタイム、SAP HANA Cloud、認証、宛先、HTML5アプリ配信など)
- Discovery Centerで各サービスのプランと課金単位を確かめる
- 開発・検証・本番のサブアカウントごとに消費量を見積もる
- 合計額で消費型とサブスクリプション型を比べる
見落としやすいのは、検証用サブアカウントのHANA Cloudを止め忘れる費用です。開発中はCAP標準のSQLiteで進め、HANA Cloudは結合テストから有効にすると消費を抑えられます。
CAPのローカル開発環境を作りcds-dkでサービスを起動する手順
CAP(SAP Cloud Application Programming Model)は、BTP上の業務アプリを作るためのSAPのフレームワークです。CDSでデータとサービスを定義すると、ODataのエンドポイントが自動で用意されます。ソースはGitHubのcap-jsでも公開されています。
Node.js 22以上・cds-dk 10系の導入とcds versionでの確認手順
CAPのリリース一覧では、2026年6月のメジャー版(Node.js 10・Java 5)から最小Node.jsが22に上がりました。2026年10月時点の最新はNode.js 10.2・Java 5.2です。npmの@sap/cds-dkも10.2.0が公開されています。
node -v # v22 以上であること
npm i -g @sap/cds-dk # CAP の開発ツールを入れる
cds version # @sap/cds-dk のバージョンを確認
Windowsでは、Getting Startedの手順どおりSQLiteも入れます。Node.js 20以前の環境に10系を入れると起動時に失敗するため、社内の共通開発環境を使う場合は先にNode.jsの版を確認してください。
cds initとcds watchでCDSモデルからODataサービスを起動する流れ
プロジェクトを作り、サンプルのサービス定義を足して起動します。cds watchはファイルの変更を検知して再起動するので、モデルを書き換えながら確かめられます。
cds init bookshop
cd bookshop
cds add tiny-sample # srv/cat-service.cds が追加される
cds watch
追加されるサービス定義は次の形です。エンティティを書くだけで、開発用のインメモリDBとODataサービスが立ち上がります。
service CatalogService {
entity Books {
key ID:Integer; title:String; author:String;
}
}
ブラウザでhttp://localhost:4004/odata/v4/catalog/Booksを開くと、ODataの応答が返ります。ここまでがS/4HANAにつながない状態での最小構成です。
S/4HANAの業務APIをcds importで取り込むサイドバイサイド拡張の実装
サイドバイサイド拡張の中心は、S/4HANAのリリース済みAPIを呼ぶ処理です。CAPではAPI定義を取り込み、必要な項目だけを自分のサービスとして公開します。
APIのEDMXをcds importでsrv/externalへ取り込む手順
SAP Business Accelerator Hubから、使うAPI(例:取引先のAPI_BUSINESS_PARTNER)の仕様ファイルをダウンロードします。CAPのConsuming Servicesによると、cds importはEDMX(OData V2・V4)、OpenAPI、AsyncAPIを受け付けます。
cds import API_BUSINESS_PARTNER.edmx --as cds
実行するとCDS形式の定義がsrv/externalに作られ、package.jsonに外部サービスとして登録されます。他プロジェクトのCDSファイルを手でコピーするのは避けてください。同ガイドは、不要なDBテーブルが作られる、インクルードが解決できない、といった問題を挙げています。
projectionでの公開項目の限定とdestinationによる本番接続先の切り替え
取り込んだAPIをそのまま公開せず、自分の名前空間で項目を絞ったprojectionを定義します。S/4HANA側の項目名が変わっても、影響をこの定義の中に閉じ込められます。
using { API_BUSINESS_PARTNER as bupa } from '../srv/external/API_BUSINESS_PARTNER';
entity Suppliers as projection on bupa.A_BusinessPartner {
key BusinessPartner as ID,
BusinessPartnerFullName as fullName,
BusinessPartnerIsBlocked as isBlocked,
}
接続先はpackage.jsonの[production]ブロックでBTPの宛先名を指定します。開発中はモックで動かし、本番だけ宛先経由でS/4HANAへつなぐ切り替えがこの設定で済みます。
"cds": {
"requires": {
"API_BUSINESS_PARTNER": {
"kind": "odata",
"model": "srv/external/API_BUSINESS_PARTNER",
"[production]": {
"credentials": {
"destination": "S4HANA",
"path": "/sap/opu/odata/sap/API_BUSINESS_PARTNER"
}
}
}
}
}
宛先「S4HANA」はBTPコックピットで作り、認証情報はアプリのコードに書きません。SAP以外のSaaSも含めて連携の数が多い場合は、BTPで個別に作るかiPaaSに寄せるかをiPaaSの課金単位と接続数による比較と見比べて決めます。
Cloud FoundryへMTAでデプロイするcds addとcds upの実行手順
ローカルで動いたアプリを、HANA Cloudと認証つきでCloud Foundryへ出します。手順はCAPのDeploy to Cloud Foundryに沿っています。
cf CLI 8以上・multiappsプラグイン・mbtの3つを揃える前提ツール
デプロイには、Cloud Foundry CLIの8以上、MTAを扱うMultiApps CF CLI Plugin、Cloud MTA Build Tool(mbt)が必要です。Windowsではmbtの動作にGNU Makeも入れます。
cf -v # 8 以上であること
cf add-plugin-repo CF-Community https://plugins.cloudfoundry.org
cf install-plugin -f multiapps
cf install-plugin -f html5-plugin
npm i -g mbt
社内PCでプラグインの取得先が遮断されていると、ここで止まります。プロキシ設定の確認は、BTPのアカウント作成より先に済ませておくと手戻りが減ります。
cds add hana・xsuaa・mtaで本番構成を足しcds upでデプロイする
本番用の構成はcds addで足していきます。開発中のSQLiteをSAP HANA Cloudへ、仮の認証をXSUAAへ置き換え、最後にmta.yamlを生成します。
cds add hana # 本番 DB を SAP HANA Cloud に
cds add xsuaa # XSUAA 認証。xs-security.json も生成
cds add mta # デプロイ記述子 mta.yaml を生成
cf login --sso # SAP Universal ID でログイン
cf target # デプロイ先のスペースを確認
cds up # ビルドとデプロイを一括実行
cds upの中身は、依存関係のインストールの後にmbt build -t gen --mtar mta.tarとcf deploy gen/mta.tar -fを実行する処理です。CI/CDに載せるときは、この2行をそれぞれ個別に呼び出す形へ分解する手順です。Fioriの画面を配信する場合はcds add portal(SAP Cloud Portal)かcds add approuter(独自のApp Router)を追加します。Fiori画面の生成はSAP Fiori toolsのOpen UX Toolsが使えます。
SAP BTPで拡張を作るべき条件と見送るべき場面の判断基準
BTPは何でも置ける場所ではありません。費用と運用の責任が増えるぶん、置く理由がはっきりしている拡張だけを出します。
BTPに置くべき拡張:複数システム連携・AI・S/4HANAの版上げと切り離す処理
次のどれかに当てはまる拡張は、BTPのサイドバイサイドで作ります。
- S/4HANAと他のSaaS・オンプレミスの複数システムをまたいで処理する
- 生成AIや機械学習など、S/4HANAの実行環境に無い機能を組み込む
- 取引先ポータルや現場向けモバイル画面など、S/4HANAのユーザー以外が使う
- S/4HANAの年次アップグレードと別のリリースサイクルで改修したい
この4つは、本体に入れるとアップグレードのたびに回帰テストの対象が増えるものです。アドオンの棚卸しで「BTPへ移設」に振り分ける候補は、まずこの条件で絞ってください。2027年の保守期限に向けた移行計画の全体はSAPの2027年問題と移行・延命の判断で扱っています。
BTPを見送る場面:項目追加はキーユーザー拡張、ABAP中心ならABAP環境
画面に項目を1つ足す、承認条件を少し変える、といった変更にBTPは過剰です。キーユーザー拡張で済むものをBTPで作ると、ランタイム・HANA Cloud・認証の費用と、アプリの監視・証明書・ライブラリ更新の運用が丸ごと増えます。
本体のデータと同じ論理単位で更新する処理も、BTPには出しません。リモートAPI越しの更新は失敗時の取り消しを自前で作る必要があり、開発者拡張(ABAP Cloud)で本体に置くほうが安全です。チームがABAP中心でNode.jsやJavaの運用経験が無いなら、Cloud FoundryではなくBTPのABAP環境を選びます。言語を変える学習コストは、拡張1本の規模では回収できません。
外注時に見積もりへ入れるべき環境構築・HANA Cloud・認証・CI/CDの範囲
BTPの拡張開発を外注するときは、アプリの画面と機能だけで見積もると漏れが出ます。次の項目が見積もりに入っているかを確認してください。
- サブアカウント構成(開発・検証・本番)と権限設計
- SAP HANA Cloudのスキーマ設計と、開発中のSQLiteからの移行
- XSUAAのロール設計と、S/4HANAへの宛先・認証方式の設定
- mbtとcf deployを使うCI/CDパイプライン
- CAPのメジャー版更新(年1回・最小Node.jsの引き上げを含む)への追従
5番目は特に抜けやすく、CAPは2026年6月のメジャー版で最小Node.jsを22へ上げています。一創のSAPコンサルティング・導入支援サービスでは、アドオンの棚卸しからBTPへの移設判断、CAPでの拡張開発までを一続きで相談いただけます。
よくある質問
SAP BTPを調べ始めた実装者から多い質問に、公式ドキュメントの記述をもとに答えます。
SAP BTPは無料で使えますか?
2つの方法で無料で試せます。個人の学習ならトライアルで、合計90日(30日で停止し延長が必要)まで使えます。会社で評価するならFree Tierで、Free Tierのプランだけを有効にしていれば期限なしで無料です。ただしFree TierはEnterpriseアカウントの中に作るため、有償プランを選ぶと課金されます。Cloud Foundryの有効化時はfreeプランを選んでください。
SAP BTPの料金はどう決まりますか?
料金を決める要素は、契約モデルと、有効にしたサービスのプランごとの消費量です。消費型にはBTPEA(前払いクレジット・最低投資額あり)、既存契約向けのCPEA、初期費用なしで月次請求のPAYGがあり、ほかにサービスごとの固定費で払うサブスクリプション型があります。具体額はDiscovery Centerでプランと課金単位を確かめ、サブアカウントごとに積み上げて見積もります。
SAP BTPとS/4HANAの違いは何ですか?
S/4HANAは会計・販売・購買などの業務を処理するERP本体で、SAP BTPはその外側で拡張アプリや連携を動かすPaaSです。クリーンコアの考え方では、S/4HANAには標準機能とリリース済みAPIだけを残し、独自の業務アプリや複数システムをまたぐ処理をBTPへ置きます。両者は置き換えの関係ではなく、組み合わせて使う関係です。
SAP BTPの開発にはABAPが必要ですか?
必須ではありません。Cloud Foundry環境ではCAPを使い、Node.jsかJavaで開発できます。CDSでデータとサービスを定義し、業務ロジックをJavaScriptやJavaで書く形です。既存のABAP資産と人材を活かしたい場合は、BTPのABAP環境でABAP CloudとRAPを使う選択肢もあります。チームの得意言語で環境を選ぶのが原則です。
SAP BTPのNeo環境はまだ使えますか?
新規の開発先には選びません。2024年4月に導入されたBTPEAのグローバルアカウントはNeo環境に対応していないと、SAP Developersの入門資料に明記されています。Neo上に古いアプリがある場合は、Cloud Foundryなどへの移行を前提に契約モデルを決めてください。移行の期限や支援内容はSAPの営業窓口で最新の条件を確かめる必要があります。
関連記事
- SAP S/4HANAとは?ECCとの違い・導入形態・移行方式と2027年問題への備えを解説:拡張の土台となるERP本体の導入形態と移行方式
- RISE with SAPとは:契約に含まれる範囲・GROWとの違いと移行方式・責任分界を解説:契約に含まれるBTPの範囲を確認できる記事
- ABAPとは?SAP専用の業務開発言語の特徴と2027年問題への備えを実装解説:ABAP環境や開発者拡張を選ぶときの言語の基礎
- コンポーザブルERPとは?ポストモダンERPとの違い・メリットと導入判断を解説:本体と拡張を分ける設計思想の全体像
- SAPの2027年問題とは?ERP保守終了の影響とS/4HANA移行・延命の判断を解説:アドオンをBTPへ移す判断の前提になる移行計画