SAP Business Technology Platform の全体像・技術仕様・制約・導入設計
2026年6月
SAPは2000年代以降、S/4HANA・Ariba・SuccessFactors・Concur等のクラウドアプリケーションをそれぞれ独立したSaaSとして展開してきました。しかしこの「製品ごとに独立したクラウド」というアーキテクチャは、企業にとって深刻な問題をもたらしました。各アプリケーション間のデータがサイロ化し、統合にコストがかかり、AI・データ分析の基盤もばらばらでした。また、S/4HANAをはじめとするコアシステムに手を加えるABAPカスタマイズは「アップグレードの障壁」となり、SaaSの恩恵（自動アップグレード・クラウドスケール）を享受できませんでした。
SAP BTP（Business Technology Platform）はこの課題を解決するために生まれた「テクノロジー統合基盤」です。アプリケーション開発・統合・データ分析・AIという四つの能力を一つのプラットフォームに集約し、SAP製品群と企業の独自システムをつなぐ「デジタルコア」として位置付けられています。
本稿では、BTPを深く理解するために必要な「アーキテクチャ・各サービスの技術仕様・制約・コスト構造・実装パターン」まで踏み込んで解説します。「BTPで何ができ何ができないのか」「どのサービスをいつ使うべきか」という実践的な判断基準を提供することを目的とします。
BTPの管理単位は「グローバルアカウント（Global Account）→ディレクトリ（Directory）→サブアカウント（Subaccount）」という三層階層で構成されます。この階層の理解はBTPガバナンス設計の出発点です。
グローバルアカウント：SAPとの契約単位。エンタイトルメント（利用権・ライセンス）がここに割り当てられます。グローバルアカウント管理者は全サブアカウントの管理権限を持ちます。一企業で複数のグローバルアカウントを持つケースは稀ですが、子会社・M&A先の統合時に問題となることがあります。
ディレクトリ：サブアカウントをグループ化する中間管理層（オプション）。「事業部別」「環境別（開発・検証・本番）」「地域別」等の管理単位に応じてディレクトリを設計します。ディレクトリへのエンタイトルメント割り当て（子サブアカウントへの均等配分）も可能です。
サブアカウント：BTPサービスの実際の利用・デプロイ単位。各サブアカウントは独立したリージョン（データセンター地域）・環境（Cloud Foundry / Kyma / ABAP）・セキュリティ設定を持ちます。開発・検証・本番ごとに別サブアカウントを作成する設計が標準です。
BTPサービスを利用するには、グローバルアカウントに「エンタイトルメント（Entitlement）」が付与され、それをサブアカウントに割り当てる必要があります。エンタイトルメントはSAPとの契約で決まる「利用可能なサービスとその量・プラン」の定義です。
各BTPサービスには複数の「サービスプラン（Service Plan）」があり、プランによって機能範囲・リソース上限・課金方式が異なります。
Freeプラン：開発・PoC目的の無料枠。本番利用は不可・性能制限あり・SLAなし。フリープランでPoC後に有償プランへ移行するパターンが一般的。
Standardプラン：本番利用向け有償プラン。機能フルセット・SLA保証（可用性99.9%以上等）。
Premiumプラン：高性能・大容量・追加機能（一部サービスのみ）。
BTPの課金モデルは大きく「消費ベース（Consumption-Based）」と「サブスクリプション（Subscription-Based）」の二種類があります。
CPEA（Cloud Platform Enterprise Agreement）：消費ベース契約の旧名称。グローバルアカウントにクレジットプールを購入し、実際に使用したBTPサービスの従量分がクレジットから消費される方式。使用しないサービスのコストが発生しない柔軟性がある一方、クレジット消費速度の予測が難しく、計画外のコスト増が発生するリスクがあります。
BTPEA（BTP Enterprise Agreement）：2023年以降のCPEA後継モデル。基本構造はCPEAと同様の消費ベースですが、対象サービス範囲が拡大され、購入クレジットの有効期間設定が改善されています。
サブスクリプション：特定サービスを固定料金・固定量で年間契約する方式。Integration Suiteのメッセージ数・Build Process Automationのワークフロー件数等、量が予測できる場合はサブスクリプションの方がコスト管理しやすい。
コスト管理の重要ポイントとして、BTP Cockpitの「Cost & Usage」画面でサービス別消費状況をリアルタイムモニタリングする運用が不可欠です。特に開発者が自由にサービスを有効化できる設定になっていると、想定外のクレジット消費が発生します。サブアカウント単位でのエンタイトルメント量の上限設定（Quota）によるコスト制御が推奨されます。
BTPには三つの実行環境（Runtime）が存在し、開発する拡張アプリケーションの性質・開発チームのスキル・将来の保守性によって使い分けます。三つのうち複数を同時に使用するアーキテクチャも一般的です。
Cloud Foundry（CF）はPaaS（Platform as a Service）として、アプリケーションのデプロイ・スケーリング・ライフサイクル管理を提供します。BTPにおいて最も長い歴史を持ち、最多のBTPサービス（Integration Suite・SAP Work Zoneの特定コンポーネント等）がCF上で稼働しています。
サポート言語・フレームワーク：Java（Spring Boot・TomEE）・Node.js・Python・Go・Ruby。「Buildpack」というミドルウェア設定テンプレートで各言語環境を自動構成します。
メモリ・CPU管理：アプリケーションごとにメモリ割り当て（例：512MB・1GB）を設定します。「Application Instance」の数でスケールアウトします（水平スケーリング）。垂直スケーリング（インスタンスサイズの変更）はアプリ再起動が必要です。
CF制約：コンテナの実行時間制限（ディスクI/O・長時間バッチ処理には向かない）・ファイルシステムはエフェメラル（再起動でリセット）・コンテナ間通信はHTTP/HTTPSのみ（ソケット通信は原則不可）。
サービスバインディング：データベース・メッセージキュー・認証等のBTPサービスを「サービスバインディング（Service Binding）」でアプリケーションに接続します。接続情報（接続文字列・認証情報）はCF環境変数「VCAP_SERVICES」に自動注入されます。
ABAP EnvironmentはBTP上でABAPコードを実行する環境です。オンプレミスS/4HANAのABAPとは異なり「ABAPクラウド（Steampunk）」と呼ばれる制限付きABAPサブセットのみが使用可能です。
ABAPクラウドの制限：従来のABAPで使用できた「Function Module・BAPI・内部テーブルの直接DDICアクセス・トランスポート層への直接アクセス」等の多くがABAPクラウドでは利用不可または非推奨です。代わりにRESTful ABAP Programming Model（RAP）・CDS（Core Data Services）・Business Services（OData V4）による開発が標準です。
RAPモデル：Restful ABAP Programming ModelはBTPでのABAPアプリ開発の中核フレームワークです。CDS Viewでデータモデルを定義し、Behavior Definitionでビジネスロジック（CRUD・アクション・バリデーション）を実装し、Service Definitionで自動的にOData V4 APIを公開します。Fiori Elements UIとの親和性が高く、「データモデル定義だけでリスト・詳細・編集画面が自動生成される」という生産性が特徴です。
S/4HANAオンプレミスとのコード共用：オンプレミスS/4HANAのABAPコードをABAPクラウドに移植するには、「ABAP Test Cockpit（ATC）」でABAPクラウド互換性チェックを行い、非互換APIの置き換えが必要です。大規模な既存ABAPコードベースの移植は相当な工数を要することが多い点が制約です。
Kymaは「Kubernetes（k8s）ベースのコンテナ実行環境」です。BTPのランタイムの中で最もインフラ的な柔軟性が高く、コンテナ化されたマイクロサービスを任意の言語・フレームワークでデプロイできます。
アーキテクチャ：SAP管理のKyma Kubernetes Clusterが提供されます。ユーザーはHelm Chart・Kubernetes Manifest（YAML）でアプリケーションをデプロイします。Istioサービスメッシュ（トラフィック管理・mTLS通信暗号化・オブザーバビリティ）が標準搭載されています。
Eventing（イベント駆動）：SAP Event Mesh（後述）またはKymaのネイティブEventing（NATS/CloudEvents標準）でS/4HANAやBTPサービスからのイベントをKymaアプリが受信できます。「S/4HANAでBP（ビジネスパートナー）が作成されたらKymaアプリがリアルタイムにトリガーされる」というイベント駆動アーキテクチャが実現します。
スケーリング：Kubernetes HPA（Horizontal Pod Autoscaler）によるオートスケーリング・ゼロスケール（アイドル時にポッドを0にしてコスト削減）が利用できます。ただしゼロスケール状態からのコールドスタートには数秒〜数十秒の遅延が発生します。
Kymaの難易度：Kymaは三つの実行環境の中でインフラ知識（Kubernetes・Docker・Helm）が最も要求されます。SAP BTP開発者にKubernetesスキルがない場合は、Cloud Foundryを優先選択するか、Kymaの学習コストを導入計画に組み込む必要があります。
三環境の選択基準を整理します。
Cloud Foundry：Javaまたは Node.jsでの標準的なWeb API・UIアプリ開発。BTPサービス（Integration Suite等）のサポートが必要な場面。開発チームにKubernetesの知識がない場合。
ABAP Environment：SAP標準のABAPで開発された既存ロジックのクラウド移植。S/4HANAのカスタムOData APIを公開する場合。ABAPスキルを持つ開発チームが主体の場合。
Kyma：マイクロサービスアーキテクチャ・コンテナファースト設計・イベント駆動型のリアルタイム処理・任意の言語（Python/Go/Rust等）での開発が必要な場合。長時間バッチ・GPUコンピューティング等のCF非適合ワークロード。
SAP Integration Suite（IS）はBTPの統合機能の中核を担うサービスセットです。企業とSAP・非SAP・オンプレミス・クラウドを問わないシステム間の統合を提供します。サービスとして提供される統合プラットフォーム（iPaaS）の位置付けです。
Cloud Integration（旧称：HCI / SAP Cloud Platform Integration）は「iFlow（Integration Flow）」と呼ばれる統合処理フローをグラフィカルに設計・実行するエンジンです。iFlowはBPMN2.0ライクな設計ツールで「受信アダプタ→処理ステップ→送信アダプタ」という構造を持ちます。
iFlowが接続できるアダプタ（コネクタ）は70種類以上あります。主要アダプタと技術特性を示します。
HTTPS/REST：最も汎用的。REST API・Webhook・ポーリングによるデータ取得に対応。OAuth 2.0・APIキー・Basic認証をサポート。
SFTP/FTP：レガシーシステムとのファイル連携。「ポーリング間隔・ファイルパターン（*.csv）・処理後の削除/アーカイブ」を設定します。SFTP秘密鍵認証もサポート。
IDoc（SAP）：S/4HANAのIDoc送受信に特化したアダプタ。IDocタイプを指定し、S/4HANAのRFC宛先と接続します。IDocのパース・変換・エラーハンドリングがiFlowで制御できます。
OData：OData V2/V4でのCRUD操作。SAP・非SAPのOData APIへの接続に使用。Batch Request・$expand等のOData機能も利用可能。
AS2（EDI）：B2Bの電子商取引（EDI）で使用する暗号化・署名付き通信プロトコル。取引先との電子商取引ドキュメント（受発注・請求書）の自動交換。
AMQP/Kafka：メッセージキューブローカー（Azure Service Bus・AWS SQS・Apache Kafka等）との非同期連携。高スループット・高可用性のイベント連携に使用。
アダプタの制約として「全アダプタが全サービスプランで利用可能ではない」点に注意が必要です。Enterprise版では利用可能なアダプタが、StandardプランやTrialではブロックされるものがあります。プロジェクト開始前に使用予定のアダプタがエンタイトルメントに含まれているかを確認する必要があります。
iFlow内で利用できる主要処理ステップの種類を示します。
Message Transformation：XML⇔JSON変換・メッセージマッピング（Graphical Mapping・XSLT・Groovy Script）・Content Modifier（ヘッダー・プロパティの追加/修正）・Filter（条件に合致する要素のみ抽出）。
Routing：「Content-Based Router（メッセージ内容によって送信先を切り替え）」「Splitter（大きなメッセージを複数の小さなメッセージに分割）」「Aggregator（複数メッセージを一つに集約）」「Multicast（同一メッセージを複数宛先に並列送信）」。
Persistence：「Persist（メッセージの中間保存）」「Data Store（Key-Valueでの一時データ保存）」「Local Variable（iFlow実行中の変数管理）」。Data Storeはスループット集計・重複排除・べき等処理（Idempotency）の実装に利用されます。
エラーハンドリング：iFlowはエラー時の挙動を「Exception Subprocess」で定義します。リトライ設定（最大リトライ回数・リトライ間隔）・デッドレターキュー（リトライ上限後の隔離）・アラート通知（電子メール・SAP Alert Notification）が構成できます。
Integration Suite上でiFlowを設計・デプロイする基本的な流れを示します。
Packageの作成：統合シナリオをグループ化する「Integration Package（統合パッケージ）」を作成します。パッケージ内にiFlow・Message Mapping・Value Mapping等のアーティファクトを格納します。
iFlowの設計：「Add」→「Integration Flow」でiFlowを追加し、WebブラウザベースのUIエディタで設計します。パレットからアダプタ・処理ステップをドラッグ&ドロップで配置し、プロパティパネルで各ステップの詳細設定（エンドポイントURL・認証方式・変換ロジック等）を入力します。
シミュレーション：デプロイ前にテストメッセージでiFlowの処理をシミュレーションできます。各ステップの入出力メッセージを可視化することでデバッグが効率化されます。
デプロイ：「Deploy」ボタンでiFlowをBTPにデプロイします。デプロイはCF上のContainer（Osgi Bundle）として実行されます。デプロイ完了後、エンドポイントURLが発行され、外部システムからの呼び出し・スケジューラによる定期起動が可能になります。
モニタリング：「Monitor > Integrations」で実行中・完了・エラーのメッセージ処理状況をリアルタイム確認できます。エラーメッセージの詳細ログ（受信データ・変換後データ・エラースタックトレース）を確認してデバッグします。
API Management（APIM）は企業のAPIを「管理・保護・公開・収益化」するAPIゲートウェイです。S/4HanaやBTPサービスのOData APIをAPIManagement経由で外部公開することで、認証・レートリミット・分析・バージョン管理を一元管理します。
APIプロキシ（API Proxy）：バックエンドAPIの前段にプロキシを配置し、ポリシー（Policy）を適用します。ポリシーは「Security（OAuth認証・APIキー検証・IP制限）」「Traffic Management（レートリミット・クォータ・スパイクアレスト）」「Mediation（リクエスト/レスポンスの変換・ヘッダー操作）」「Extension（Groovy/JavaScript実行）」の四カテゴリに分類されます。
Developer Portal（APIカタログ）：API利用者（社内開発者・外部パートナー）向けのセルフサービスポータル。API仕様（OpenAPI/Swagger）の参照・テスト実行・APIキー発行申請が可能です。APIエコシステムの構築（PartnerAPI公開・内部API活用促進）に活用されます。
API Analytics：APIコール数・レスポンスタイム・エラー率・利用者別トラフィック等のAPI利用分析ダッシュボード。SLAモニタリング・異常検知アラート設定が可能です。
制約：API Managementのレートリミット・クォータ設定はAPI Proxyレベルでの設定です。複数のAPIProxyをまたいだグローバルレートリミット（ユーザー全体のAPIコール総量制限）は設定できません。また、GraphQL APIの管理は限定的なサポートとなっています。
SAP Event MeshはBTPのメッセージブローカー（Message Broker）です。CloudEvents標準に準拠したイベントの発行（Publish）・配信（Subscribe）・永続化（Persistence）を提供します。
メッセージキューとトピック：Event Meshは「Queue（キュー、P2P配信）」と「Topic（トピック、Pub/Sub配信）」の二つのメッセージングモデルをサポートします。Queueは送信したメッセージが一つの受信者に配信されます。Topicは複数のサブスクライバーが同じメッセージを受信できます（Fan-out）。
S/4HANAとの統合：S/4HANA 2020以降では「Business Events（ビジネスイベント）」機能によりBPの作成・変更・注文の確認等のビジネスイベントがEvent Mesh Topicに自動発行されます。KymaやCloud Foundryアプリがそのイベントをリアルタイムに受信してリアクティブな処理を実行できます。
メッセージ永続化：Event Meshはメッセージを一定期間（設定可能）永続化します。サブスクライバーが一時的にダウンしていた間に発行されたメッセージを後から受信できます。この「少なくとも一度の配信（At-Least-Once）」保証が非同期処理の信頼性を高めます。
制約：Event Meshのメッセージサイズ上限（デフォルト1MB）・キュー深度（最大メッセージ保持件数）・スループット上限はサービスプランにより異なります。大容量ファイルの転送にはEvent Meshは適さず、SFTP/Object Storageとの組み合わせが必要です。
SAP Open ConnectorsはSalesforce・ServiceNow・Slack・Box・Google Drive・HubSpot等の170種類以上のSaaS製品に対する標準コネクタを提供します。
Open Connectorsの特徴は「各SaaSのAPIを正規化（Normalize）して統一APIとして提供する」点です。例えばSalesforceとHubSpotはそれぞれ異なるAPI設計を持ちますが、Open Connectorsを経由することで同一のAPI設計でどちらのCRMにもアクセスできます。iFlowとの統合により「外部SaaSのデータをS/4HANAに同期する」統合フローが標準コネクタで構築できます。
制約として、Open Connectorsが提供するコネクタは「読み取り・基本CRUD」が中心であり、接続先SaaSの高度機能（バッチAPI・Webhook等）については個別サポート状況の確認が必要です。また、コネクタの仕様変更に追随するアップデートタイミングがSAP側の対応速度に依存する点が制約となります。
SAP Build Apps（旧称：AppGyver）はコード不要（No-Code）〜ローコード（Low-Code）でWebアプリ・モバイルアプリを開発するビジュアル開発ツールです。
UIコンポーネント：ドラッグ&ドロップで配置可能なUIコンポーネント（ボタン・テーブル・フォーム・チャート・マップ等）が200種類以上提供されます。カスタムCSS・カスタムJavaScript（Formula関数）の注入も可能で、ノーコードの制限を超えたカスタマイズができます。
データ接続：OData V2/V4・REST API・GraphQL・BTP Destination（接続設定）を通じてS/4HANAや外部システムのデータをリアルタイム取得・更新できます。BTP上のCAPアプリ（SAP Cloud Application Programming Model）との連携が最も統合性が高く推奨されます。
ビジネスロジック：「Flow Function（処理フロー）」を視覚的に定義します。IF/Else分岐・ループ・変数操作・API呼び出し・エラーハンドリングを視覚的なフローチャートで記述します。複雑なロジックにはJavaScript Formula関数を利用します。
モバイル出力：Webブラウザに加え、iOSアプリ・Androidアプリとしてビルド・配布できます。OTA（Over-The-Air）アップデートにより、ストア再申請なしにアプリコンテンツを更新できます。
制約：Build Appsはオフライン対応（オフラインデータキャッシュ・オフライン操作のキュー保存）をサポートしますが、複雑なオフラインシナリオ（大量レコードの差分同期・コンフリクト解決）の設計は課題が多くなります。また、非常に高度な3DビジュアライゼーションやリアルタイムAR機能は対応していません。
SAP Build Process Automation（SBPA）はワークフロー自動化とRPA（Robotic Process Automation）を統合したサービスです。ビジネスプロセスの承認フロー・タスク管理・ボット自動化を一つのプラットフォームで設計・運用できます。
プロセス設計：BPMNライクなビジュアルエディタでワークフローを設計します。「ユーザータスク（承認・入力）」「自動ステップ（APIコール・条件分岐）」「並列分岐（複数承認者への同時割り当て）」「タイマー（期日アラート・エスカレーション）」を組み合わせます。
フォームデザイナー：ワークフロー内のユーザータスクに表示する「入力フォーム」をノーコードで設計します。フィールドタイプ（テキスト・数値・日付・選択肢・添付ファイル）・バリデーション・条件表示（特定条件の場合のみフィールドを表示）が設定できます。
My Inbox（タスクポータル）：承認担当者はSAP Build Work ZoneのMy Inboxまたはモバイルアプリから承認待ちタスクを処理します。タスク一覧・タスク詳細・承認/却下/転送の操作がシンプルなUIで提供されます。
プロセス可視性（Process Visibility）：現在実行中のワークフローインスタンスのステータス（どのステップで止まっているか）・過去実行の履歴・平均処理時間・ボトルネック分析をダッシュボードで確認できます。
SAPのRPAは「Cloud Studio（ボット設計）」と「Desktop Agent（ボット実行）」の二つのコンポーネントで構成されます。Desktop Agentはボットを実行するPCにインストールするエージェントソフトウェアです。
自動化対象：画面操作の記録（Record & Play）で自動化シナリオを作成します。Webブラウザ（Chrome/Edge）・Windowsデスクトップアプリ・SAP GUI・Excel・PDF操作を自動化できます。
SAP GUI自動化：SAP GUI（BEx・SE11・ME21N等のトランザクション画面）の自動操作は「SAP GUI Automation」コンポーネントで専用サポートされています。画面上の要素（フィールド・ボタン・テーブル行）をTechnical Name（ID）で特定するため、画面レイアウト変更に対する堅牢性が高いです。
制約：RPAボットはDesktop Agentが起動しているPCでのみ実行されます。PCがシャットダウン・ロックされているとボットは停止します。サーバーサイドでの常時稼働にはVM（Virtual Machine）上のAgent実行が必要です。また、キャプチャ（CAPTCHA）・多要素認証（MFA）が必要な画面の自動化は困難です。
SAP Build Work Zone（旧称：SAP Launchpad Service）はSAP Fioriアプリ・BTPアプリ・外部Webアプリ・コンテンツ（ニュース・ナレッジ記事）を一つのポータル画面に統合する「デジタルワークプレイス」です。
Site Designer：Work ZoneのポータルUI（Site）をノーコードで設計します。ページ・セクション・カード・ウィジェットをドラッグ&ドロップで配置し、役割（Role）に応じたページの出し分け（Personalization）を設定します。
ビジネスコンテンツ統合：S/4HanaのFioriアプリ・BTPのカスタムアプリ・SAP Analytics CloudのAnalyticsダッシュボード・Ariba・SuccessFactorsの各ポータルへのリンクを一元化します。ユーザーはWork Zoneにログインすることで、複数システムへのシングルアクセスポイントを得ます。
My Inbox統合：SBPAのワークフロー承認タスク・S/4HANAのワークフロー（SWDD/SWI5相当）をWork ZoneのMy Inboxに統合表示できます。承認作業のOne-Stop化が実現します。
制約：Work Zoneの「Standard版」と「Advanced版」で機能が大きく異なります。Advanced版のみ利用できる機能（カスタムコンテンツ（Page Builder）・HR統合・Microsoft 365統合・AI推薦コンテンツ）が多数あります。ライセンスプランの選定に注意が必要です。
SAP HANA Cloud（HC）はインメモリ列指向データベースを中核とするクラウドネイティブDBaaSです。オンプレミスSAP HANA（S/4HANAの基盤となるDB）のクラウド版として位置付けられますが、アーキテクチャは大きく異なります。
コンピュート・ストレージ分離：HANA Cloudはコンピュート（CPU・インメモリ）とストレージ（ディスク）が分離されたアーキテクチャを採用しています。データは「Native Storage Extension（NSE）」によってホットデータ（インメモリ）・ウォームデータ（ディスク）・コールドデータ（オブジェクトストレージ）の三層に自動的にティアリングされます。これにより、全データをメモリに載せるコストを抑えながら高速クエリを維持します。
マルチモデル：リレーショナル（SQL）・グラフ（Cypher/SPARQL）・空間（Spatial/GIS）・ドキュメント（JSON）の複数データモデルを単一DBエンジンで扱います。グラフ分析と空間分析をSQLと組み合わせて単一クエリで実行できます。
HANA Cloud Data Lake（QRC）：コールドデータをSAP HANA Data Lake（HDL）に格納し、HANA Cloud経由でSQL連携するアーキテクチャ。大容量の過去データを低コストで保持しながら、必要に応じてHANA Cloud上でJOINクエリが実行できます。
拡張モデル：BTPアプリ（CAPアプリ等）からHANA Cloudへの接続はHDB（HANA Database）ドライバを介します。Node.js（@sap/hana-client）・Java（NGDBC）・Python（hdbcli）ドライバが提供されています。
「SAP Cloud Application Programming Model（CAP）」はBTPでのアプリケーション開発フレームワークです。CAPはNode.js（cds npm）またはJava（Spring Boot拡張）で記述し、BTPのCF/Kymaにデプロイします。
CAPはHANA CloudをネイティブDBとして利用するように設計されています。CDS（Core Data Services）でデータモデルを定義すると、HANA CloudのテーブルDDLが自動生成され、OData V4 APIが自動的に公開されます。「データモデル定義→APIが自動生成される」というRAD（Rapid Application Development）的な開発効率が特徴です。
マルチテナント：CAPはBTPのマルチテナントSaaS拡張アプリの開発フレームワークとしても利用されます。テナント分離はHANA Cloudのスキーマ分離（テナントごとの独立スキーマ）で実現します。SAPのISVパートナーがBTP上でSaaS製品を構築する際の標準フレームワークです。
制約：CAPの生産性は高いですが、HANA Cloud固有の高度な機能（Advanced Analyticsビュー・Calculation View等）をCAPのCDSから直接活用するには、HDBアーティファクト（.hdbtable・.hdbcalculationview等）との混在設計が必要となり、設計の複雑性が増します。
SAP Datasphere（旧称：SAP Data Warehouse Cloud）はデータ統合・データモデリング・データ仮想化・データ共有を一元管理するデータファブリックプラットフォームです。
ビジネスデータファブリック：DatasphereはSAP HANACloud・S/4HANA・Azure Synapse・Snowflake・Databricks等の複数データソースを「仮想テーブル（Remote Table）」として統合します。実際のデータ移動なしに複数DBを横断したSQL/Analytics Viewが作成できます（データ仮想化）。
SAP BW Bridgeによる移行支援：SAP BWからDatasphereへの移行を支援する「BW Bridge」機能が提供されています。BW InfoObject・BW Query（BEx）をDatasphereのエンティティに変換するツールが用意されており、既存のBW投資を段階的にクラウドに移行できます。
知識グラフ（Business Layer）：DatasphereのBusiness LayerはSAPアプリケーション（S/4HANA・Ariba・SuccessFactors）のセマンティクス（業務意味付け）を自動取込します。「仕入先・受注・損益」等の業務概念がデータモデルに自動反映され、分析ユーザーが技術的なテーブル名を知らずにデータを理解・活用できます。
SAC（SAP Analytics Cloud）との統合：DatasphereをSACのライブ接続先として設定すると、DatasphereのモデルをSACのStory/Planningからリアルタイム参照できます。Datasphere側でのデータアクセス制御（行レベルセキュリティ）がSAC側にも透過的に適用されます。
制約：Datasphereのデータ仮想化（Remote Table）は、クエリを実行するたびにリモートデータソースにクエリが委譲されます。リモートDBの性能がクエリ性能を制約します。大容量データのアドホック分析にはデータ複製（Replication Flow）でDatasphereのローカルストレージに取り込む設計が適しています。
SAP IAS（Identity Authentication Service）はBTPのIDプロバイダー（IdP）です。SAP Cloud製品（BTP・S/4HANA Cloud・Ariba・SuccessFactors等）へのシングルサインオン（SSO）を提供します。
SAMLとOpenID Connect：IASはSAML 2.0とOpenID Connect（OIDC）の両プロトコルをサポートします。BTPアプリへのSSOはOIDC（Authorization Code Flow）が主流です。SAP Fiori LaunchpadやBTPサービスへのSSOにはSAMLが使われるケースもあります。
コーポレートIdPとの連携（Proxy）：社内のActive Directory（Microsoft Entra ID / 旧Azure AD）やOkta等の企業IdPをIASのPROXY構成で利用できます。ユーザーは企業のIdPで認証し、IASを経由してBTPサービスにSSOします。この構成により「ユーザーのID管理は既存企業IdPに委ね、SAPクラウドへのSSOはIASが担う」という責任分離が実現します。
MFA（多要素認証）：IASはTOTP（Google Authenticator等）・SMS OTP・Biometrics（FIDO2/WebAuthn）のMFAをサポートします。特定アプリケーション・特定ユーザーグループ・特定IPレンジ以外からのアクセスに対してMFAを強制するポリシー設定が可能です。
Risk-Based Authentication：アクセスのリスクレベル（未知IPからのアクセス・海外からのアクセス・勤務時間外アクセス等）に応じて認証要求レベルを自動的に上げる「リスクベース認証」がサポートされています。
SAP XSUAA（Extended Services User Account and Authentication）はBTPのOAuth 2.0認可サーバーです。BTPアプリが発行するアクセストークン（JWT）の検証・スコープ管理・ユーザーとRole Collectionのバインディングを管理します。
Role・Role Collection・Scope：BTPアプリのアクセス制御は「Scope（権限の最小単位）→Role（Scopeの集合）→Role Collection（Roleの集合）→User/Group（Role Collectionの割り当て）」の四層で構成されます。アプリケーション開発者がScopeを定義し、管理者がRole Collectionをユーザーに割り当てます。
アプリ間の認可（OAuth Client Credentials）：BTPアプリ同士・BTPアプリからS/4HANA APIへのM2M（Machine-to-Machine）認証には「OAuth 2.0 Client Credentials Flow」を使用します。XSUAAがクライアントID・クライアントシークレットに対してアクセストークンを発行し、APIゲートウェイでトークンを検証します。
Principal Propagation（ユーザー伝播）：BTPからS/4HANAへのAPI呼び出しにおいて「BTPアプリにログイン中のユーザーIDをS/4HANA側に伝播する」Principal Propagation設定が可能です。これにより「BTPアプリからS/4HANAを操作した記録がS/4HANA側の変更文書に実ユーザーIDで残る」という監査トレーサビリティが確保されます。
Destination Serviceはbtp上のアプリが外部システム（S/4HANA・Ariba・外部REST API等）に接続するための「接続設定（認証情報・エンドポイントURL）を集中管理するサービス」です。
接続設定（Destination）はSubaccountまたはInstance（アプリインスタンス）レベルで管理され、アプリケーションコード内に接続先URLや認証情報をハードコードする必要がありません。環境（開発・検証・本番）ごとに同じDestination名で異なる接続先を定義することで、コードを変更せずに環境切り替えができます。
認証タイプ：Basic認証・OAuth 2.0（Client Credentials・Authorization Code・SAML Bearer Assertion）・Certificate（クライアント証明書）・Principal Propagation（ユーザー伝播）をサポート。
On-Premise接続（SAP Connectivity Service + Cloud Connector）：Destinationが「On-Premise」タイプの場合、BTPからオンプレミスシステム（S/4HANAオンプレミス・社内REST API等）への接続は「Cloud Connector（SCC）」を経由します。SCCは社内ネットワークに設置するプロキシソフトウェアで、BTPとオンプレミスシステム間の暗号化トンネルを確立します。インターネットに対してポート開放が不要な「リバーストンネル」方式のため、ネットワークセキュリティ上の懸念が少ない接続方式です。
制約：Destination Serviceはサブアカウント単位でDestinationリストを管理します。大規模環境で接続先が多い場合、Destinationの命名規則・バージョン管理・変更追跡の仕組みを設計しないと管理が煩雑になります。DestinationをソースコードリポジトリでIaC（Infrastructure as Code）管理するためのBTP CLI / BTP Terraform Providerの活用が推奨されます。
「クリーンコア（Clean Core）」はSAPが推進するS/4HANAの標準コードを「汚染」しない拡張アーキテクチャの設計原則です。従来のSAP導入では、業務要件に合わせてABAPコードを修正・追加する「改造（Modification）」が常態化しており、SAP標準コードの上書き（EXIT・BAdI・Enhancement Spot）が大量に行われていました。
この改造の蓄積がS/4HANAへのマイグレーション・定期アップグレード（SAP S/4HANAは年1回のメジャーアップデート）の最大の障壁となっています。クリーンコア戦略は「S/4HANAのコアコードを標準のまま維持し、拡張はすべてBTPの外側で行う」という方針です。
クリーンコア準拠の拡張には三つのパターンが定義されています。
In-App Extension（インアプリ拡張）：S/4HANA内部でABAPクラウドAPI（Released API・Business Object Interface）のみを使用した拡張。ABAPクラウドのRAPモデルでS/4HANAのカスタムオブジェクトを追加します。S/4HANA標準コードを変更せず、Released APIの範囲内に留まるため、アップグレード影響を受けません。ただし「Released APIとして公開されていない業務ロジックへのアクセスは不可」という制約があります。
Side-by-Side Extension（サイドバイサイド拡張）：BTP上のアプリ（CAPアプリ・Build Appsアプリ等）がS/4HANAのPublic OData/RFCのAPIを呼び出して拡張する方式。S/4HANAとは完全に独立したコードとして管理され、S/4HANAのアップグレード影響を受けません。複雑なUI・外部システム統合・AI機能の追加に適しています。最もクリーンコア原則に沿った拡張方式です。
Developer Extension（ISV/パートナー拡張）：SAPのパートナー・ISVがBTP上でSaaS拡張製品を構築してSAP App Centerで提供する形式。顧客は標準を維持しながら、パートナーの付加価値機能をサブスクリプションで追加します。
クリーンコア準拠の実装において最大の課題は「S/4HANAのReleased API（公式サポートAPIリスト）」の範囲確認です。
SAP API Business Hub（api.sap.com）でS/4HANAのReleased OData API・BAPI・CDS Viewのリストを確認できます。しかし「業務要件に必要な機能がReleased APIに含まれていない」ケースは実際の導入で頻繁に発生します。この場合の対処選択肢は「①S/4HANAのExtensibility機能（Key User Extensibility）で標準機能を設定拡張してAPI化する」「②SAP Support Notesに解決策がないか確認する」「③クリーンコア原則を一時的に妥協してIn-App拡張でカバーする（将来リファクタリングを計画）」です。
SAPはReleased APIの範囲を毎年拡張しており、過去に対応できなかった業務要件がAPIとして公開されるケースも増えています。クリーンコア準拠度は「パーフェクトなゼロ改造」を目指すのではなく、「改造のないS/4HANAコア（改造スコアの定量的な管理）」と「BTP側での機能代替計画」を組み合わせた現実的な目標設定が重要です。
SAPはBTP上でAI関連サービスを「SAP AI Core・SAP AI Launchpad・SAP Generative AI Hub・個別AIサービス（Document Information Extraction・Business Entity Recognition等）」として提供しています。BTPはSAPアプリケーション全体のAIインフラとして機能します。
SAP AI Coreは機械学習モデルのトレーニング・デプロイ・推論を実行するMLOpsプラットフォームです。BTP上のKyma（Kubernetes）基盤上で動作します。
ワークフロー（Workflow）：MLパイプライン（データ前処理→モデルトレーニング→モデル評価→モデル登録）をKubernetesネイティブの「Argo Workflows」で定義します。GPU対応のKubernetesノードでのトレーニングが可能です。
デプロイメント（Deployment）：学習済みモデルをREST APIエンドポイントとして公開します。モデルのA/Bテスト・カナリアリリース・スケーリング（リクエスト量に応じた自動スケール）が管理できます。
モデルレジストリ：学習済みモデルのバージョン管理・メタデータ（精度指標・学習データセット・ハイパーパラメータ）を記録します。SAP AI LaunchpadのUIからモデルの評価比較・プロモーション（dev→prod昇格）が操作できます。
制約：SAP AI CoreはKubernetes基盤のため、MLOps経験・Kubernetes知識が必要です。GPU付きインスタンスの利用は別途費用とクォータ申請が必要。日本リージョン（jp10）でのGPUノード利用可能性は事前確認が必要です。
SAP Generative AI Hubは複数のLLM（大規模言語モデル）プロバイダーへのアクセスを一元管理するサービスです。プロバイダーとしてOpenAI（GPT-4o等）・Anthropic（Claude等）・Google（Gemini等）・Meta（Llama等）・MistralAI等をサポートしており、単一のAPI（GenAI Hub API）でモデルを切り替えて利用できます。
LLMアクセスのガバナンス：GenAI Hubは単なるLLMプロキシではなく、「モデルごとのアクセス制御・コスト追跡（モデル別トークン消費量）・プロンプトフィルタリング（有害コンテンツ除去）・コンテンツログ（監査）」を一元管理します。SAPのデータプライバシーポリシーに基づき、入力データがLLMプロバイダーのトレーニングに使用されないよう制御されています。
Orchestration Service：GenAI Hub内の「Orchestration Service」はRAG（Retrieval-Augmented Generation）・プロンプトテンプレート・Chain-of-Thought等のLLMアプリケーション構築パターンをOrchestrationフレームワークとして提供します。BTPアプリからOrchestration APIを呼び出すことでRAGシステムを短期間で構築できます。
SAP Jouleとの関係：SAP JouleはGenAI HubのLLMを使用して動作します。Jouleが提供するNL（自然言語）インターフェースのバックエンドはGenAI Hubです。企業がカスタムAIアシスタントを構築する場合もGenAI Hub APIを基盤として利用します。
BTPが提供する個別AIサービス（AI Services）は特定の業務タスクに特化した学習済みモデルをAPIとして提供します。
Document Information Extraction（DIE）：請求書・注文書・納品書等の非構造化ドキュメント（PDF・画像）からキーフィールド（発行日・金額・仕入先名・品目等）を自動抽出するサービス。OCR＋NLPの組み合わせで動作します。SAP Cash Applicationの入金消込自動化で活用されています。
Business Entity Recognition（BER）：テキスト（メール・契約書・報告書）からビジネスエンティティ（会社名・製品名・取引先担当者名等）を認識・抽出します。
Translation Hub：SAP公式の機械翻訳サービス。SAP製品UIの多言語化・ドキュメント翻訳に特化した翻訳品質を提供します。
Intelligent Situation Automation（ISA）：S/4HANAの業務例外（在庫不足・支払遅延等の「Situation」）を検知して自動対処アクションをトリガーするAI機能。Situationの検知→影響分析→推奨アクション（担当者通知・自動転記等）を自動実行します。
SAP BTPはグローバルで35以上のリージョン（データセンター地域）で提供されています。リージョンは基盤となるハイパースケーラー（Infrastructure Provider）によって以下に分類されます。
SAP独自データセンター（CF専用）：SAP自社運用のデータセンター（EU10/eu1：Frankfurt等）。最も長い提供歴史を持ちますが、新機能の提供が他ハイパースケーラーリージョンより遅延するケースがあります。
Microsoft Azureリージョン（ap21等）：Azureのグローバルインフラ上で稼働するBTPリージョン。Azure NativeのサービスとBTPサービスの組み合わせが容易。
Amazon Web Services（AWSリージョン）：AWSインフラ上で稼働するBTPリージョン（ap10：シドニー・us10：バージニア等）。
Google Cloud Platform（GCPリージョン）：GCPインフラ上で稼働するBTPリージョン（us30等）。
日本リージョン（jp10）：AWSの東京リージョンをインフラとするBTPリージョン。データ所在地が日本国内に限定されます。日本の個人情報保護法・金融規制・医療規制等のデータ所在要件に対応。
BTPの可用性設計においてマルチリージョン構成とディザスタリカバリ（DR）の考え方を理解する必要があります。
BTPのプロダクション環境は原則として単一リージョン（単一サブアカウント）で稼働します。SAP BTPのSLA（Service Level Agreement）は「月次可用性99.9%以上（一部サービスは99.5%）」が標準です。ただしSLAはあくまで「SAP起因の障害」に対する保証であり、ユーザーのアプリコードに起因する障害・計画メンテナンスは対象外です。
アクティブ-アクティブなマルチリージョン構成（複数リージョン間での負荷分散）はBTP標準機能では提供されません。高可用性が要求されるシステムでは「アクティブ-パッシブDR構成（プライマリリージョン障害時に別リージョンで手動フェイルオーバー）」の設計が必要となり、アプリのデプロイ・データレプリケーション（HANA System Replication等）の追加設計が必要です。
SaaS基盤であるBTPは定期的な計画メンテナンス（Platform Upgrade）が実施されます。計画メンテナンスはSAP Cloud Availability Center（SAP for Me）で事前通知されます。
特にCloud Foundry環境のランタイムアップデート・HANA Cloudのメンテナンスウィンドウは、本番業務への影響を事前に評価するための管理プロセスが必要です。「変更管理プロセスにSAPのメンテナンス通知をインプットする」運用設計が重要です。
BTPはアプリ開発・統合・データ・AI・ローコードが混在するプラットフォームのため、「誰が何をどう使うか」というガバナンス設計が導入の成否を決定します。多くの企業でBTP CoE（Center of Excellence）を組織横断的なチームとして設置する事例が増えています。
グローバルアカウント設計：グローバルアカウントの管理権限（Global Account Administrator）は組織の中央IT部門が保持し、各事業部・プロジェクトにサブアカウントを払い出すモデルが標準です。事業部が独自にグローバルアカウントを作成すると、ライセンス・セキュリティ・コストの管理が分散して管理コストが増大します。
コスト配賦モデル：BTPの消費ベース課金は「使った分だけコストが発生」するため、各サブアカウントのコスト配賦（誰がどれだけ使ったか）の仕組みが必要です。BTPのCost Reporting APIを使ったコスト可視化・サブアカウント別予算割り当て・アラート設定を組み合わせたFinOps（クラウドコスト最適化）の実践が重要です。
開発・検証・本番の分離：BTPプロジェクトでは開発（Dev）・品質保証（QA）・本番（Prod）ごとに独立したサブアカウントを作成し、デプロイパイプライン（CI/CD）による自動プロモーションを構築します。手動でのBTP設定変更・手動デプロイは本番環境では禁止し、全変更をCI/CDパイプライン経由でトレースできる体制が推奨されます。
BTP Cockpit（WebUI）による手動設定は可視性・再現性・変更管理の面で限界があります。BTPのCI/CD・IaC化に利用できるツールを示します。
BTP CLI（btpcli）：コマンドラインからグローバルアカウント・サブアカウント・エンタイトルメント・サービスインスタンスを管理するCLIツール。スクリプト化によるサブアカウントの自動作成・サービス有効化の自動化が可能です。
Terraform Provider for SAP BTP：HashiCorp TerraformでBTPリソース（サブアカウント・エンタイトルメント・サービスインスタンス・DestinationサービスのDestination等）をコードとして管理するプロバイダー。IaC化によりBTPインフラの変更管理・バージョン管理・再現性が向上します。
SAP Cloud MTA Build Tool（MBT）：Cloud Foundryへのデプロイに使用するMTA（Multi-Target Application）ビルドツール。Java・Node.jsアプリ・iFlow等を一つのMTAアーカイブ（.mtar）にパッケージ化してデプロイします。
GitHub Actions / Azure DevOps統合：BTPのCI/CDはSAP標準のPiper（SAP pipeline framework）またはGitHub Actions・Azure DevOps等の外部CI/CDとの統合で実現します。コードPush→自動ビルド→自動テスト→BTPへの自動デプロイというパイプラインが標準的な構成です。
BTPプロジェクトに必要なスキルセットは多岐にわたります。「一人のSAPエンジニアが全部できる」という前提は危険で、役割別のスキルマトリクスを明確にすることが重要です。
BTPアーキテクト：アカウント設計・セキュリティ設計・統合アーキテクチャ・コスト見積もり。SAP認定資格「SAP Certified Associate - SAP BTP Solution Architect」が参照基準。
Cloud Foundry/CAPアプリ開発者：Node.js・Java・CAPフレームワーク・OData API・HANA Cloud。
ABAPクラウド開発者：ABAPクラウド・RAPモデル・CDS View・Released API。S/4HANAのABAP経験があっても、ABAPクラウドへの学習転換が必要（使用可能なAPI・フレームワークが大きく異なるため）。
統合開発者（iFlow）：Integration Suite・iFlow設計・アダプタ設定・Groovy Script・XMLマッピング。EDI・メッセージング経験があると親和性が高い。
インフラ/DevOpsエンジニア：Kubernetes（Kyma）・Docker・Terraform・CI/CDパイプライン設計。
グローバルに展開する製造業A社は、SAP S/4HANA・Ariba・SuccessFactors・Concurをそれぞれ独立したSaaSとして導入していました。しかし各製品間のデータ連携が「ポイントツーポイント統合」の積み重ねとなっており、統合の管理・障害時のトレーサビリティ・統合の変更コントロールが困難な状況でした。また、S/4HANAへの改造（ABAP修正）が蓄積しており、年次アップグレードのたびに改造コードの修正対応に数百万円規模のコストが発生していました。
A社はBTPのIntegration Suite（Cloud Integration）を統合ハブとして採用し、すべてのSAP製品間の統合をCloud Integration上のiFlowに集約しました。SAP標準の統合シナリオ（Integration Packages）を最大限活用することで、iFlow開発工数を従来のポイントツーポイント統合比で大幅に削減しました。また、S/4HANAの改造コードをBTP上のCAP/Side-by-Side拡張に段階的に移行するリファクタリングプロジェクトを実施し、S/4HANAのアップグレードを阻害する改造スコアを改善しました。Integration Suiteのモニタリングにより統合エラーの早期発見・対処が可能となり、統合障害対応時間が大幅に短縮されたと報告されています。
消費財を扱う小売業B社は、小規模取引先からの受注がFAX・メール・電話で届き、受注担当者がSAP GUIに手入力するというアナログプロセスが残っていました。繁忙期には受注入力工数が激増し、入力ミスによる誤発注が頻発していました。受注入力自動化のためのEDI導入を検討しましたが、小規模取引先側のEDI対応工数・コストが障壁となって推進できませんでした。
B社はBTPのDocument Information Extraction（DIE）で受注メールの添付PDF（注文書）からキー情報（取引先名・品目コード・数量・納期）を自動抽出するAI処理フローを構築しました。抽出データはBuild Process Automationのワークフローで「低リスク受注（既存取引先・正常金額範囲内）は自動承認→SAP GUIへの自動入力（Desktop Automation RPA）→受注確認メール自動送信」するフローを実現しました。「高リスク受注（新規取引先・大口受注）」のみ担当者の確認フローを経由します。受注担当者の手入力工数が大幅に削減されると共に、入力ミスによる誤発注が減少したと報告されています。
証券・資産運用を主事業とする金融サービス業C社は、リスクモニタリングに使用しているシステムがS/4HANAと外部マーケットデータプロバイダーの二系統に分かれており、統合されたリアルタイムリスク可視化ができていませんでした。S/4HANAのカスタム改造で統合することも検討しましたが、監査・コンプライアンス上の要件からS/4HANA標準コードの維持が必要でした。
C社はS/4HANAのビジネスイベント（Business Events）をEvent Mesh経由でKyma上のリスク集計マイクロサービスにリアルタイム配信するアーキテクチャを構築しました。Kymaアプリは外部マーケットデータプロバイダーのストリームAPIからのリアルタイムデータと、S/4HANAのイベントデータを組み合わせてHANA Cloudにリスクサマリーを書き込みます。SAC（SAP Analytics Cloud）のLive Connection経由でHANA Cloudのリスクサマリーをリアルタイム可視化するダッシュボードをデジタルボードルームとして整備しました。S/4HANAの標準コードを一切変更せずに外部データとの統合リアルタイム分析を実現し、監査上の課題が解消されたと報告されています。
BTPは広大な機能領域をカバーしますが、特定の場面では制約や代替手段の設計が必要です。
◎できる：SAP製品群のAPIベース統合（Cloud Integration）・カスタムアプリ開発（CAP/Build Apps）・ワークフロー自動化（SBPA）・APIゲートウェイ（API Management）・クラウドDB（HANA Cloud）・LLM活用（GenAI Hub）
△条件次第：オンプレミスシステムとのリアルタイム同期（Cloud Connectorが必要・レイテンシ課題あり）・複雑なオフラインモバイルアプリ（Build Appsで基本対応可だが高度な差分同期は困難）・ミッションクリティカルなリアルタイムERPトランザクション（BTPアプリは補完的役割、コアトランザクションはS/4HANA上で実行が基本）
✕できない：オンプレミスS/4HANAのABAPコード直接実行（ABAP EnvironmentはABAPクラウドのみ）・Cloudに非対応のネットワーク経路（閉域網専用DBへの直接接続）・インターネット非接続環境でのBTPサービス利用（BTPはパブリッククラウド前提）
BTP導入を成功させるために、プロジェクト開始前に確認・設計すべき重要事項を示します。
エンタイトルメントの確認：使用予定のサービス・機能がSAPとの契約に含まれているか。消費ベース課金のクレジット残量は十分か。サービスプラン（Free/Standard/Premium）による機能制限はないか。
リージョン選択の確認：データ所在地要件に対応したリージョンが利用可能か。日本リージョン（jp10）で必要なサービスが提供されているか（一部新サービスはまず欧米リージョン先行でリリースされる）。
スキル調達計画：プロジェクト開始時点でのチームのBTPスキル評価と、必要なトレーニング・採用・外部支援の計画。BTPは「SAP経験者が学習すれば即戦力」とはならず、Cloud Native開発・統合・MLOps等の追加スキルが必要な領域が多い。
ガバナンス先行設計：アカウント階層・コスト管理・セキュリティポリシー・開発プロセス（CI/CD）をプロジェクトのDay 1から設計・運用することが、BTP投資の長期的な健全性を維持する最重要要件です。
以上