SAP BTP アーキテクチャ:エンタープライズアーキテクトのための実践ガイド
- SAP BTPは、グローバルアカウント → ディレクトリ → サブアカウントという3層のアカウント階層を採用しており、組織構造やコスト構造に直接対応します。
- Cloud Foundry、Kyma、ABAPの3つのランタイム環境は、それぞれ異なるユースケースに対応しており、適切な環境を選択することが最も影響力の大きいアーキテクチャ上の判断となります。
- Clean Core戦略とは、拡張機能や統合機能をBTP上でサイドバイサイドアプリケーションとして配置し、S/4HANAのアップグレード可能性と安定性を維持することを意味します。
はじめに
SAP Business Technology Platform(SAP BTP)は、エンタープライズクラウド変革の戦略的基盤としての地位を確立しています。SAPの全アプリケーションポートフォリオを支える接続レイヤーとして、BTPは組織がシステム統合、アプリケーション拡張、プロセス自動化、AI導入を単一のプラットフォーム上で実現することを可能にします。2025年7月にSAPが委託した IDC調査では、SAP BTPとSAPビジネスアプリケーションを組み合わせた組織の3年間のROIが516%に達すると予測されており、プラットフォームの商業的重要性の高まりが示されています。
しかし、多くのSAPアーキテクトやプロジェクトチームにとって、BTPは複雑に見えるかもしれません。数十のサービス、複数のランタイム環境、そして階層化されたアカウント階層。本記事では、アカウントモデルからランタイムの選択、AI機能に至るまで、BTPのコアアーキテクチャを構造的に解説します。これは、情報に基づいた設計上の意思決定を行う必要があるアーキテクトやシニアコンサルタント向けに設計されています。
1) SAP BTPとは?
SAP BTPは、SAPシステムと非SAPシステムを接続、拡張、自動化するPlatform-as-a-Service(PaaS)製品です。 SAPの公式製品ページによると、BTPはSAP Business Suiteの基盤として機能し、お客様が以下のことを実現するのに役立ちます。
- 財務、人事、サプライチェーン、調達にわたるプリビルト統合により、価値実現までの時間を短縮
- 2025年2月にGigaOmが報告したように、目的特化型フレームワークによりアプリ開発を約3倍高速化
- ビジネスコンテキストに基づいたAIエージェントにより、エンタープライズプロセスをエンドツーエンドで自動化
このプラットフォームは、ERPコアをクリーンに保つという基本原則に基づいて設計されています。組織はSAP S/4HANAを直接変更するのではなく、BTP上でサイドバイサイドのアプリケーションとして拡張機能や統合機能を構築します。これにより、継続的なイノベーションを可能にしながら、アップグレードパスを維持することができます。
2) 本記事の全体像における位置づけ

BTPのアーキテクチャを理解するには、アカウントモデル、ランタイム環境、サービスカテゴリ、AIレイヤーという4つの相互接続されたレイヤーを検討する必要があります。各レイヤーは明確に区別されますが、相互に依存しています。例えば、アカウントモデルの確実な理解を省略すると、後工程でガバナンスやコストの透明性に問題が生じます。これは、BTP導入を急いだ組織に共通するパターンです。
3) SAP BTP アカウントモデル

アカウントモデルは、SAP BTPの組織的な基盤です。 SAPの公式ドキュメントによると、アカウントは3つのレベルにわたって構造化されています。
グローバルアカウント
グローバルアカウントは、SAPとの商用契約を具体化したものです。サブアカウント、メンバー、エンタイトルメント、およびクォータを管理します。商用モデルには、従量課金モデル(消費ベース)とサブスクリプションモデル(容量コミットメント)の2種類があります。グローバルアカウントはリージョンや環境に依存せず、配下のサブアカウントがどこで実行されていても、それらすべてにまたがって機能します。
ディレクトリ
ディレクトリは、グローバルアカウントとサブアカウントの間に位置するオプションのグループ化構造です。これにより、アーキテクトはプラットフォーム内で部門、地域、子会社、プロジェクトごとに組織構造をモデル化できます。ディレクトリには他のディレクトリやサブアカウントを含めることができ、最大7階層(グローバルアカウント+最大5階層のディレクトリ+サブアカウント)の階層構造を実現できます。
ディレクトリはオプションのエンタイトルメント管理をサポートしています。管理者はディレクトリレベルでクォータを割り当てることができ、それが子サブアカウントに配分されます。これは特にチャージバックモデルやマルチビジネスユニットのデプロイメントに有用です。
サブアカウント
サブアカウントは実際の作業が行われる場所です。各サブアカウントは特定のリージョン(物理データセンター)と環境(Cloud Foundry、Kyma、またはABAP)に紐づけられます。グローバルアカウント内のサブアカウントは互いに完全に独立しており、セキュリティドメイン、ユーザー管理、データ境界が分離されています。SAPは、ワークロードごとに少なくとも開発、テスト、本番の3つのサブアカウントを設定する標準パターンを推奨しています。
コスト監視は、サブアカウントレベル(またはディレクトリ/Cloud Foundryスペースレベル)で機能します。コストの透明性を考慮して設計するアーキテクトは、消費を追跡したい粒度にサブアカウントをマッピングする必要があります。
4) ランタイム環境

サブアカウントで選択された環境は、開発者が利用できるランタイム、ツールセット、および運用モデルを定義します。2026年現在、SAP BTPは3つのアクティブな環境を提供しており、レガシーのNeo環境は2028年12月31日にサンセット(提供終了)となる予定です。
Cloud Foundry 環境
Cloud Foundryは、クラウドアプリケーションを構築するための成熟したエンタープライズグレードの環境です。Cloud Foundry Foundationが管理するオープンソースプラットフォームをベースとしており、Java、Node.js、Python、Ruby、Go、PHPなど複数のプログラミング言語をサポートし、高度な自動化を提供します。 SAPのランタイム比較ドキュメントによると、Cloud Foundryはルーティング、ネットワーキング、スケーリング、パッチ適用を自動的に処理するため、開発者はインフラストラクチャではなくビジネスロジックに集中できます。
Cloud Foundryは、チームが幅広い言語サポートと迅速な価値創出を必要とし、コンテナオーケストレーションの細かい制御を必要としない場合に最適な選択肢です。12要素アプリの方法論とステートレスマイクロサービスのパターンを採用しています。
Kyma環境
Kymaは、オープンソースのKymaプロジェクトをベースにしたフルマネージドのKubernetesランタイムです。 SAPの技術文書に記載されているように、KymaはKubernetesを業界最高水準のオープンソースツールで拡張します。サービスメッシュ用のIstio、イベント駆動型メッセージング用のNATS JetStream、サービス消費用のSAP BTP Operatorを備えています。サーバーレス関数(スケール・トゥ・ゼロ)と、任意のプログラミング言語によるコンテナ化されたマイクロサービスをサポートします。
Kymaは、Kubernetesの専門知識を持つチーム、高いスケーラビリティが求められるワークロード、イベント駆動型アーキテクチャ、または複雑なマルチクラウド統合要件に適した選択肢です。その代償として、Cloud Foundryと比較して運用の複雑さが増し、学習曲線が急峻になります。
重要な点として、SAPの公式ドキュメントでは、Cloud FoundryとKymaの選択は二者択一である必要はないと強調されています。両者は同一のSLAレベルとマルチアベイラビリティゾーンインフラストラクチャを共有し、どちらもSAPによって完全に管理されています。組織は、同一ランドスケープ内で両方を使用することができ、また多くの場合、そうすべきです。
ABAP環境(Steampunk)
2018年に導入されたABAP環境は、ABAPプラットフォームをPaaSサービスとしてクラウドに提供します。ABAP RESTfulアプリケーションプログラミングモデル(RAP)、SAP Fioriインターフェース、およびCore Data Services(CDS)をサポートします。既存のABAP専門知識とABAPベースのカスタムコードを持つ組織にとって、この環境はチームの再トレーニングなしにクラウドネイティブなABAP開発への最速の道を提供します。
2022年後半時点で、SAP S/4HANA Cloud上の組み込みSteampunkは、純粋なサイドバイサイドのBTP拡張では対応できないシナリオに対して、オンスタックの開発者拡張性を実現します。
5) サービスカテゴリ

ランタイムを超えて、SAP BTPは幅広いマネージドサービスのカタログを提供しています。これらは4つの戦略的カテゴリに分類されます。
統合

SAP Integration Suiteは、統合サービスのフラッグシップ製品です。事前構築済みアダプター、API管理、イベントメッシュ、統合フローを活用して、SAPシステムと非SAPシステム(クラウドおよびオンプレミス)を接続します。例えば、マクドナルドはIntegration SuiteとAdvanced Event Meshを使用して、100以上のSuccessFactors統合と16のAriba統合を構築し、ポイントツーポイント統合からパブリッシュ-サブスクライブアーキテクチャへ移行しました。これにより、 erp.todayが2026年2月に報じたところによると、23カ国にわたるスケーラビリティが向上しました。
アプリケーション開発

SAP Buildは、主要なローコード/ノーコード開発プラットフォームです。シチズンデベロッパーとプロフェッショナルデベロッパーの両方が、アプリケーションの作成、ワークフローの自動化、AIエージェントの構築を可能にします。 2025年2月のGigaOmフィールドテストでは、SAP Buildがカスタムコーディングと比較して約3倍のアプリケーション開発速度を実現することが示されました。プロコード開発向けには、SAP Business Application Studio(BAS)が、CAP(Cloud Application Programming Model)、SAPUI5、その他のフレームワークをサポートするクラウドベースのIDEを提供します。
データと分析

SAP HANA Cloudは、リアルタイム分析とアプリケーションデータ管理を支えるインメモリデータベースサービスです。SAP Datasphereは、データファブリックアプローチを用いてシステム間のデータ調和を実現します。SAP Analytics Cloud(SAC)は、財務、サプライチェーン、業務領域全体にわたるリアルタイムダッシュボード、予測分析、およびコラボレーティブプランニングを提供します。
AIと自動化




SAP AI Coreは、機械学習モデルのトレーニング、デプロイ、管理を行うためのプラットフォームです。AI Core内のジェネレーティブAIハブは、ガバナンスとコスト管理機能を備えた単一のAPIを通じて、SAP、パートナー、およびオープンソースの大規模言語モデル(LLM)への集中アクセスを提供します。これは、生のAPIキーを公開したり監査証跡を失うことなく、複数のモデルを管理する必要がある組織にとって重要な機能です。
JouleはSAPのAIコパイロットであり、SAPアプリケーション全体に組み込まれています。Joule Studio(2025年6月より一般提供開始)はこれをさらに拡張し、ユーザーがローコードインターフェースを使用してカスタムJouleスキルやAIエージェントを設計、デプロイ、管理できるようにします。これらのエージェントは、SAPのビジネスデータを推論し、マルチステップのワークフローを実行し、非SAPシステムと相互運用することができます。
6) クリーンコア戦略とBTP

4つのサービスカテゴリーすべてに共通するテーマは、クリーンコア戦略です。基本原則はシンプルで、SAP ERPコアを変更しないことです。代わりに、すべての拡張、統合、自動化をSAP BTP上にサイドバイサイドアプリケーションとして配置します。このアプローチは、複数の実稼働環境での導入実績に基づき、カスタムコードのリグレッションテストなしでSAPアップグレードを適用できるようにします。
erp.todayの2026年2月の記事で紹介されたあるグローバルコンサルティング企業は、BTP Business Process Automationを導入後、20カ国、40,000人以上の従業員を抱える環境でクリーンコアを維持しながら、企業間取引の処理ステップを15分から10秒未満に短縮しました。HANA Cloud、Integration Suite、Event Mesh、Analytics Cloud、Datasphereにまたがる同社が採用したアーキテクチャは、現在、大規模なBTP導入のリファレンスパターンとなっています。
7) 適切なランタイムの選択:意思決定フレームワーク

アーキテクトは、特定のワークロードに対してどのランタイムを使用すべきかという問いに頻繁に直面します。SAPの公式ガイダンスとコミュニティのベストプラクティスに基づく以下のフレームワークは、その出発点を提供します。
Cloud Foundryを使用するケース:
- チームがJava、Node.js、またはその他の標準言語を使用し、管理されたインフラストラクチャを好む場合
- ワークロードが従来のエンタープライズアプリケーションまたはAPIサービスである場合
- 初回デプロイまでの時間が優先される場合
- チームにKubernetesの専門知識がない場合
Kymaを使用すべきケース:
- イベント駆動型またはサーバーレス機能を必要とするワークロード
- マルチクラウドの移植性のためにコンテナベースのデプロイメントが必要な場合
- チームに既存のKubernetesの専門知識がある場合
- 複雑な統合パターン(サービスメッシュ、イベントストリーミング)が必要な場合
ABAP環境を使用するケース:
- チームが主にABAP開発者で構成されている場合
- ワークロードがSAP S/4HANAまたは他のABAPベースのシステムの拡張である場合
- RAPベースの開発(ODataサービス、Fioriアプリ)が目標の成果物である場合
ランタイムは補完的です。大企業向けに適切に設計されたBTPランドスケープでは、多くの場合、イベント駆動型統合用のKyma、Webアプリケーション用のCloud Foundry、コアSAP拡張用のABAP Environmentの3つすべてが使用されます。
概要

SAP BTPのアーキテクチャは階層的でありながら論理的です。アカウントモデル(グローバルアカウント → ディレクトリ → サブアカウント)は、ガバナンスとコスト管理のフレームワークを提供します。ランタイム環境(Cloud Foundry、Kyma、ABAP)は、各ワークロードに適した実行コンテキストを開発者に提供します。サービスカテゴリ(統合、アプリケーション開発、データ、AI)は、エンタープライズソリューションのための構成要素を提供します。そして、クリーンコア戦略は、長期的な俊敏性を保護する設計思想でこれらすべてを結びつけます。
BTPを評価するアーキテクトやシニアコンサルタントにとって、最初の最も重要なステップはランタイムの選択ではなく、アカウントモデルの設計です。適切に構造化されたアカウント階層は、ガバナンス、セキュリティ、コストの透明性、そして開発ライフサイクル管理を直接的に実現します。基盤を正しく構築すれば、プラットフォームのその他の運用が格段に容易になります。
FAQ
Q: 1つのサブアカウントで複数の環境を使用できますか?
A: いいえ。各サブアカウントは1つの環境(Cloud Foundry、Kyma、またはABAP)に紐づけられます。複数の環境を使用するには、共有ディレクトリの下に複数のサブアカウントを作成してください。
Q: ディレクトリとサブアカウントの違いは何ですか?

A: ディレクトリは組織的なコンテナであり、サブアカウントをグループ化しますが、アプリケーションの実行やサービスの消費は行いません。サブアカウントは、環境がプロビジョニングされ、サービスが消費される実際のデプロイメントターゲットです。
Q: Neo環境はまだ利用可能ですか?
A: Neoは引き続き運用されていますが、2028年12月31日にサンセット(提供終了)が予定されています。新規プロジェクトではNeoを使用すべきではありません。SAPは、既存のNeoワークロードをマルチクラウド環境に移行することを強く推奨しています。
Q: 生成AIハブとは何ですか? A: 生成AIハブは、SAP AI Core内の機能であり、SAP、パートナー、オープンソースプロバイダーからの複数のLLMにアクセスするための単一のAPIを提供し、一元化されたガバナンス、コスト管理、監査ログを備えています。これにより、各モデルごとに個別のAPI認証情報やエンドポイントを管理する必要がなくなります。
Q: SAP BTPはRISE with SAPとどのような関係がありますか? A: RISE with SAPは、SAP S/4HANA CloudとBTPの機能をバンドルしたビジネス変革オファリングです。BTP自体は独立して利用可能です。RISEのコンテキストでは、BTPは含まれるS/4HANAシステムの拡張および統合レイヤーとして機能します。
参考資料
- SAP Business Technology Platform 製品ページ — 2026年5月5日アクセス
- SAP BTP アカウントモデル (SAP-docs GitHub) — 2026年5月5日アクセス
- SAP BTP 環境:Cloud Foundry vs ABAP vs Kyma (SAP Community) — 2026年5月5日アクセス
- 比較:SAP BTP Kyma ランタイムと Cloud Foundry ランタイム (SAP Help Portal) — 2026年5月5日アクセス
- SAP BTP 開発環境の解説 (SAP PRESS) — 2026年5月5日アクセス
- SAP BTP ベストプラクティス:アカウントモデル (SAP PRESS) — 2026年5月5日アクセス
- SAP Sapphire 2025 における SAP BTP のイノベーション (SAP News) — 2026年5月5日アクセス
- SAP BTP AI 機能 — 2026年5月5日アクセス
- Clean Core のために SAP BTP を活用するグローバル企業 (erp.today) — 2026年5月5日アクセス
- Kubernetes を用いた SAP BTP Kyma CAP (christian-sonek.de) — 2026年5月5日アクセス
次に読むべきもの
このサイトでは、BTPのナレッジを以下の構成で整理しています。
| L1. 全体像 | L2. 機能領域 |
|---|---|
| BTP-001 BTPとは | L2-A. 統合 |
| BTP-002 BTPアーキテクチャ(本記事) | L2-B. アプリケーション開発と自動化 |
| BTP-003 BTP機能マップ | L2-C. データと分析 |
| BTP-004 デプロイメントモデル | L2-D. AI |
| BTP-005 ライセンスモデル | L2-E. 基盤サービス |
| BTP-006 クリーンコア戦略 | L2-F. アーキテクチャと運用 |
| L2-G. ユースケースとパターン |