BTPアーキテクチャ設計：概要と主要な決定事項

JinJin48

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

May 13, 2026 · 25 min read

本記事の位置づけ#

参考資料#

1) BTPアーキテクチャランドスケープ#

SAP BTPのアーキテクチャ設計は、相互接続された5つの構造レイヤーにわたっており、各レイヤーには明確な意思決定者と異なる可逆性の特性があります。 SAP BTPアカウントモデルは、組織の原則を定義しています。グローバルアカウントは1つのSAP契約に対応し、その下でディレクトリとサブアカウントが組織的および運用上の境界を反映するように構成されます。

これらのレイヤーは代替ではありません。堅牢なランタイムの選択は、不適切に設計されたアカウント階層を補うことはできません。

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

BTPはS/4HANAを実行するのではなく、拡張します。すべてのBTPアーキテクチャ上の決定は、SAPコアとの定義された関係に遡らなければなりません。 SAP BTP Guidance Frameworkはこの関係を形式化しています。BTP上のサイドバイサイド拡張により、ビジネスロジックがS/4HANAカーネルから切り離され、カスタムコードを壊すことなくアップグレードが可能になります。

┌─────────────────── Global Account ──────────────────────┐
│  ┌── Directory: Core ERP ───────────────────────────┐   │
│  │  Subaccount: S4-Ext-Dev / Test / Prod (CF)       │   │
│  └──────────────────────────────────────────────────┘   │
│  ┌── Directory: Integration ────────────────────────┐   │
│  │  Subaccount: IS-Dev / IS-Prod (Integration Suite)│   │
│  └──────────────────────────────────────────────────┘   │
│  ┌── Directory: Platform Services ──────────────────┐   │
│  │  Subaccount: cTMS  │  Subaccount: CI-CD          │   │
│  └──────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────┘
         │ Cloud Connector (RFC/HTTP)     │ Private Link
         ▼                                ▼
  ┌── On-Premise ──────────┐   ┌── Hyperscaler VPC ────┐
  │ SAP S/4HANA (ECC/OP)  │   │ SAP S/4HANA (RISE)   │
  └────────────────────────┘   └───────────────────────┘

BTP上のS/4HANA拡張はサイドバイサイドパターンを採用します。BTPサブアカウント内のカスタムロジックが、OData、RFC、またはイベントを介してS/4HANAと通信します。Clean Coreの原則では、すべてのカスタマイズをS/4HANAカーネルではなくBTP上に配置することが求められます。

重要ポイント: BTPサブアカウント構造は、単一アプリケーションのデプロイメント段階だけでなく、S/4HANAランドスケープのステージ（開発/テスト/本番）と組織境界を反映する必要があります。

3) 成熟度マップ#

以下に翻訳したMarkdownブロックを示します。

以下の成熟度評価は、SAPの公開ドキュメントおよびコミュニティ発表に基づいています。In-Metro DRのRPO/RTO数値とAWS/Azureのみの制限は、 SAPコミュニティによるIn-Metroディザスタリカバリの発表を参照しています。Terraformの状態ドリフト動作は、 SAP BTP Terraformプロバイダコミュニティブログに記載されています。

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

アカウントモデルの前提条件#

SAP BTPアカウントモデルのドキュメントと アカウントモデルのベストプラクティスガイドは、このチェックリストのすべての項目の基盤となります。特に、ディレクトリの最大5階層、命名規則のガイダンス、および本番サブアカウントを分離するという普遍的な推奨事項が重要です。

リージョンとプロバイダーの選択#

サブアカウント作成時のリージョン選択は元に戻せません。これは SAP BTPリージョンヘルプ記事で確認されており、各サブアカウントは正確に1つのリージョンに関連付けられ、作成後にそのリージョンを変更できないことが文書化されています。

ランタイム環境の前提条件#

SAP Community による BTP ランタイム環境の比較では、重要な選択原則が確立されています。Cloud Foundry、Kyma、ABAP はそれぞれ個別の製品であり、ライセンスとコスト体系も異なり、互換性のあるホスティングオプションではありません。

接続の前提条件#

SAP Cloud Connector ヘルプ記事には、HA マスター/シャドウ構成要件と、各サブアカウントに公開されるバックエンドリソースを制限するアクセス制御リスト (ACL) 設計の両方が記載されています。

IAM の前提条件#

SAP BTP Identity and Access Management ヘルプ記事には、ロールコレクションはアカウントレベル間で伝播されず、本番環境の企業IdPフェデレーションにはカスタムIASテナントが必要であることが記載されています。

5) 意思決定基準#

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

Q1. このBTP実装によって解決される、測定可能なビジネスの非効率性または技術的な課題は何ですか？

もし答えが「デジタルトランスフォーメーション」や「モダナイゼーション」であれば、そのプロジェクトは真の要件を特定できていません。有効な回答は、具体的なプロセス、定量化可能なコスト、および指名されたビジネスオーナーを示すものです。これらがない場合、アーキテクチャの決定はプラットフォームの探索に陥ります。

Q2. データはどこに存在し、誰が所有し、どの法域がそのデータの保存を管轄するのか？

サブアカウント作成時のリージョン選択は変更できません。データ主権に関する規制（GDPR、PDPA、業界ルール）により、どのBTPリージョンが許可されるかが決まります。 SAP BTPリージョンに関するドキュメントでは、リージョンはサブアカウントごとに選択され、後から変更できないことが確認されています。法務/コンプライアンス部門はこの点を回答し、サブアカウントを作成する前に、承認済みの制約事項として文書化する必要があります。

Q3. 実装費用と継続的な消費コストの両方をカバーする、予算権限が確認された社内スポンサーはいますか？

BTPサービスは、プロジェクト予算とは別に継続的なコストを発生させます。 Entitlements and Quotasのヘルプ記事では、サブアカウントごとに割り当てられたクォータに対して消費が追跡されることが説明されています。一度限りの導入コストは承認したものの、運用予算を承認していないスポンサーは、確約されたスポンサーとはみなされません。ランタイムおよびHA層の決定は、承認された消費予算に照らして検証される必要があります。

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

ライセンスとコスト#

6) よくある障害#

以下に示す障害は、SAPが公開しているガイダンスに基づく要件段階の欠落を表しています。Terraformの状態ドリフト動作については、 SAP BTP Terraform Providerコミュニティブログに記載されています。Private LinkのAWS/Azure限定の制限事項は、 SAP Cloud ConnectorおよびConnectivityヘルプ記事で説明されています。

障害 1: プロビジョニング後に判明したリージョンロックイン

チームがLegal/Compliance（法務/コンプライアンス）に相談せずにBTPリージョンを選択した。UAT（ユーザー受入テスト）で法務レビューにより、顧客のPII（個人識別情報）を国外に出せず、選択したリージョンが非準拠であることが判明した。サブアカウントは別のリージョンに移動できないため、ランドスケープ全体を再構築する必要がある。

障害2: スコープの前提 — 「BTPは単なるデプロイメントプラットフォーム」

Teamsは、BTPをフォルダ構造のように扱い、すべての環境とサービスに対して単一のサブアカウントをプロビジョニングします。プロジェクト途中でIntegration Suiteが追加されると、宛先名の競合が発生し、Cloud Connectorが本番バックエンドシステムを開発者に公開してしまいます。各サブアカウントは、共有テナント内のコンテナではなく、完全に分離された独立したテナントです。

障害 3: ID プロバイダの信頼設定が遅すぎる

Corporate IAMは最終スプリントでのみ関与します。IASと企業IdP間の信頼関係の確立には、ネットワーク変更、証明書の交換、セキュリティ、AD、ネットワーク各チームにわたる属性マッピングが必要ですが、これらのチームはプロジェクトに参加していません。本番稼働は、スケジュールに組み込まれたことのないIDフェデレーション作業によって妨げられています。

障害4: コネクティビティ設計における例外処理の欠落

1 つの Cloud Connector インスタンスがすべてのプレゴーライブテストに合格しました。6か月後、OSパッチ適用によりSCCホストが15分間オフラインになり、オンプレミスに依存するすべてのBTPアプリケーションが停止します。HAマスター/シャドウSCCは、実装の詳細ではなく、要件段階の項目です。

障害5：マルチリージョンDRにおけるデータガバナンスの遅延

クロスリージョンDRアーキテクチャが部分的に構築された後、法務部門がセカンダリリージョンがデータレジデンシー契約に違反していることを特定しました。アーキテクチャを再設計する必要があります。セカンダリリージョンの法務レビューは、アーキテクチャ承認の前に行われる必要があり、その後に続くものではありません。

障害 6: 混合プロビジョニングによるTerraform状態のドリフト

プラットフォームチームは、すべてのBTPリソースをTerraform経由でプロビジョニングしています。グローバルアカウント管理者が、コックピット経由で1つのサブアカウントを手動で作成しました。Terraformの状態が実環境と一致しなくなり、次回のterraform applyで予期しない変更が発生します。IaCのみ、またはコックピットのみのガバナンスは、初日から決定しておく必要があります。

障害7: 本番環境におけるエンタイトルメント不足

プロジェクトはプロトタイピング中に、ほとんどのCPEAクォータを開発に割り当てます。本番サブアカウントが作成されると、必要なサービスプランのクォータが枯渇し、再割り当てには調達サイクルが必要になります。エンタイトルメントの消費は、クォータが割り当てられる前に、計画されているすべてのサブアカウントにわたってモデル化されなければなりません。

FAQ#

Q: SAP BTPのアーキテクチャ上の決定は、稼働開始後に変更できますか？

リージョンはサブアカウントごとに不変です — SAP BTP アカウントモデルのドキュメントでは、リージョンの選択はサブアカウント作成時に行われ、後から変更できないことが確認されています。命名規則、ディレクトリ階層、IAMトラストは、事後的に修正するのに多大なコストがかかります。アーキテクチャの決定を前倒しで行うことは、後付けで修正するよりも常に低コストです。

Q: BTPアーキテクチャはオンプレミスのSAP S/4HANAにも適用されますか？

はい。BTPはオンプレミスのSAPシステムを拡張するために設計されています。 SAP Cloud Connectorは、インバウンドのファイアウォール開放を必要とせず、セキュアなリバースインボークトンネリングを提供します。課題は接続が可能かどうかではなく、SCCがHA構成されており、そのアクセス制御リスト（ACL）が必要最小限のバックエンドリソースに限定されていることを確実にすることです。

Q: BTPのライセンスはどのように機能し、アーキテクチャを確定する前に何を確認すべきですか？

BTPはCPEAまたはBTPEAの下でライセンス供与されます。これは、公開レートで消費される前払いクレジット残高です。 エンタイトルメントとクォータに関するヘルプ記事では、クォータがグローバルアカウントからディレクトリ、サブアカウントへとどのように流れるかを説明しています。以下の点を確認してください：合計残高と期間、個別に計上されるサービス、予想される月間消費率、およびABAP環境またはIntegration Suiteに個別のサブスクリプション契約が必要かどうか。

Q: マルチリージョンのHA/DR要件は、いつ対象外とすべきですか？

In-Metro DRがビジネス要件を満たす場合、クロスリージョンアーキテクチャは不要なオーバーヘッドとなります。 SAP Community In-Metro DR発表には、RTO ≤ 2時間、RPO ≤ 5分という契約上のSLAが記載されています。クロスリージョンDRではサブアカウントが2倍になり、ステートレスなアプリケーション設計が必要となり、テスト済みのフェイルオーバーラン ブックが求められます。ビジネスが2時間の停止コストを定量化できない場合は、要件に異議を唱えてください。

Q: BTPアーキテクチャの決定はどのように文書化すべきですか？

各項目をアーキテクチャ決定記録（ADR）として取得する：決定領域、検討したオプション、選択したオプション、満たされた制約、および決定責任者。 SAP BTP Guidance Frameworkは、各ADRを防御可能な根拠に結び付けるための決定ガイドとリファレンスアーキテクチャを提供します。リージョン、ランタイム、接続性、IAMトラスト、およびHA階層は、サブアカウントが作成される前に、アーキテクトとスポンサーによる副署が必須です。

Q: オンプレミス接続要件を文書化する正しいアプローチは何ですか？

すべてのオンプレミスシステムをリストアップしてください：システムID、ホスト名/IP、RFCまたはHTTPパス、利用するサブアカウント、データ分類。これにより、SCCのアクセス制御リスト（ACL）、ファイアウォール変更依頼、HAサイジングが決まります。これがないと、SCCは通常、すべてを許可するアクセスで誤設定され、すべてのセキュリティ監査で指摘事項となります。

Q: 1つのSAP IASテナントで、すべてのBTPサブアカウントをカバーできますか？

はい、ほとんどの組織において該当します。 SAP BTP IAMドキュメントによると、単一のカスタムIASテナントは信頼設定を介して複数のサブアカウントに適用可能です。複数のテナントが必要となるのは、子会社が統合されていない企業IdPを持つ場合や、セキュリティポリシーにより本番環境と非本番環境のIDストアを厳格に分離する必要がある場合のみです。

概要#

SAP BTPアーキテクチャ設計は、10の相互に関連する構造上の決定から成るセットであり、そのほとんどはサブアカウントがプロビジョニングされると元に戻せません。これらの決定は、アカウント階層、リージョン、ランタイム、接続性、IDフェデレーション、エンタイトルメント管理、HA/DR階層、インフラ自動化に及びます。最も一般的な失敗パターンは、誤った技術的選択ではなく、先送りされたガバナンス上の決定です。法的レビューなしのリージョン選択、HAなしのSCC、企業IdPとの連携なしのIAMトラスト、またはステートガバナンスなしのTerraformなどです。 SAP Architecture Centerおよび SAP BTP Guidance Frameworkは、各決定を防御可能な根拠に基づかせるリファレンスアーキテクチャを提供しています。

次に読むべきもの#