BTPアーキテクチャ設計：ユースケースと意思決定パターン

JinJin48

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

May 14, 2026 · 21 min read

本記事の位置づけ#

参考資料#

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

BTPアーキテクチャを3つの明確なドメインに分類する意思決定。各ドメインは異なる問いに答え、異なる担当者によって運用されます（ SAP BTPアカウントモデル）。

これら3つのドメインはデプロイ時に相互作用しますが、それぞれ独立して設計されます。互いに代替となるものではありません。

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

以下の図は、サイドバイサイド拡張シナリオにおける、S/4HANAバックエンドに対するBTPの一般的な配置を示しています。

  ┌─────────────────────────────────────────────────────────────┐
  │                   SAP BTP Global Account                    │
  │                                                             │
  │  ┌───────────────────┐   ┌───────────────────────────────┐  │
  │  │  Dev Subaccount   │   │       Prod Subaccount         │  │
  │  │  ┌─────────────┐  │   │  ┌─────────────────────────┐  │  │
  │  │  │  CF Runtime │  │   │  │  CF Runtime / Kyma       │  │  │
  │  │  │  (CAP App)  │  │   │  │  (CAP App, event-driven) │  │  │
  │  │  └──────┬──────┘  │   │  └───────────┬─────────────┘  │  │
  │  └─────────┼─────────┘   └──────────────┼────────────────┘  │
  │            │  Destination service         │ Destination svc   │
  │            │  (OnPremise)                 │ (OnPremise /      │
  │            │                              │  Private Link)    │
  └────────────┼──────────────────────────────┼───────────────────┘
               │                              │
         Cloud Connector               Cloud Connector
         (Dev tunnel)                  (Prod tunnel)
               │                              │
  ─────────────┼──────────────────────────────┼──── On-premises network
               ▼                              ▼
        S/4HANA Dev                    S/4HANA Prod
        (ABAP system)                  (ABAP system)

Cloud Connector は顧客のオンプレミスネットワークにインストールされ、BTP サブアカウントへのアウトバウンドトンネルを開始します。インバウンドのファイアウォールポートは不要です（ SAP BTP Connectivity）。BTP 内のアプリケーションは、エンドポイント URL と認証情報のランタイム設定ストアとして機能する Destination サービスを介してバックエンド接続を消費します。

重要ポイント: 各BTPサブアカウントは、独自のCloud Connector論理ロケーションにマッピングされます。そのため、開発用と本番用のサブアカウントは分離しておく必要があります。単一のCloud Connectorトンネルをライフサイクルステージ間で安全に共有することはできません。

3) 成熟度マップ#

この表を使用して、各機能領域が設計に着手する前にどの程度本番環境に対応しているかを評価してください。ランタイムコストの比較については、 SAP Architecture Center の総保有コストリファレンス を参照してください。

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

以下のチェックリストは、アーキテクチャパターンをプロジェクトにコミットする前に満たすべき最低要件をまとめたものです。ソリューション設計の承認前に、各項目を確認してください。BTPアカウント階層（グローバルアカウント → ディレクトリ → サブアカウント）は、このセクションのすべてのエントリの構造的基盤です（ SAP BTPアカウントモデル）。

ランタイム環境の選択#

接続アーキテクチャ#

アカウント構造設計#

イベント駆動型アーキテクチャ#

5) 意思決定基準#

Q1: 問題点や非効率性はどこにありますか？#

BTPへの投資を引き起こす具体的なシナリオを特定します。一般的なトリガーとそのランタイムへの影響：

• S/4HANAのサイドバイサイド拡張（コアABAPでは実現できないUI、ワークフロー、レポート）：チームのスキルと規模に応じてCloud FoundryまたはKymaを選択。
• クラウドネイティブなABAP開発、または既存のABAPロジックの移行：ABAP環境のみ。
• 大量のイベント駆動型統合（在庫同期、注文イベント、IoT）：KymaとSAP Integration Suite Advanced Event Meshを組み合わせて使用。
• 複数の事業部門向けの社内SaaSプラットフォーム（プロダクトとして）：Cloud FoundryまたはKyma上のマルチテナントSaaSパターン（ SAP Architecture Center — マルチテナントSaaSリファレンスアーキテクチャ）。

もしその課題が具体的なボトルネックとして明確に表現できないのであれば、アーキテクチャの決定に進んではいけません。

Q2: データはどこに保存され、誰が所有するのか？#

データの保存場所と所有権は、後から安価にリファクタリングできない方法で、接続アーキテクチャとアカウント構造を決定します。

• オンプレミスのSAPまたは非SAPシステム：Cloud Connectorが必要、宛先ProxyTypeはOnPremise。
• AzureまたはAWSでホストされるバックエンド：インターネット経由を回避するため、SAP Private Linkサービスが推奨されるパスです（ SAP Architecture Center — Secure Connectivity with SAP Private Link）。
• データ保存に関する規制が適用される場合：BTPサブアカウントは特定の準拠リージョンに作成する必要があります。ランタイムを決定する前に、そのリージョンでKymaが利用可能かどうかを確認してください。
• 複数の国または子会社がある場合：部門ベースのグループ化ではなく、リージョンごとのディレクトリアカウント構造を使用します。

Q3: スポンサーは誰で、予算モデルはどのようなものですか？#

予算権限と商用モデルは、ランタイムコストの最適化とライセンステーブルの両方を推進します。

ライセンスに関する参考情報#

6) よくある障害#

SAP Cloud Transport Managementは、関心の分離を維持するために、他の共有サービスとともに専用のサブアカウントで実行する必要があります。これは、以下のいくつかの障害の根底にある原則です（ SAP Architecture Center — DevOps with SAP BTP）。

障害 1: すべてのライフサイクルステージに単一のサブアカウントを使用

Teamsは、オーバーヘッド削減のためにDev、Test、Prodで1つのサブアカウントを作成した後、Destination名がサブアカウントごとに一意でなければならないことや、Cloud Connectorトンネルが本番バックエンドを開発側のデプロイメントに公開してしまうことを発見します。この問題を解消するには、サービスインスタンスを再作成し、すべてのアプリケーションを再デプロイする必要があり、多くの場合、ライブプログラム中に行うことになります。

障害 2: Kubernetesの専門知識なしにKymaを選択

Kymaが選ばれる理由は、よりモダンに聞こえるから、または別のチームが使用していたからであり、プロジェクトチームがKubernetes CRDを操作、サービスメッシュを設定、またはHelmチャートを管理できることを確認していないためです。その結果、名目上は稼働しているものの、保守、監視、またはチューニングが行われていないランタイムが生まれ、セキュリティ態勢は悪化し、Cloud Foundryを上回るコストが発生する一方で、アーキテクチャ上の利点はまったく得られません。

障害 3: 単一サブアカウントにマッピングされた Cloud Connector

1 つの Cloud Connector インスタンスは、本番サブアカウントにのみマッピングされます。開発時にオンプレミスのバックエンドを呼び出す必要がある場合、チームは本番用コネクタを共有する（リスクが生じる）か、インターネット経由のプロキシを経由する（レイテンシとセキュリティ上の露出が生じる）かのいずれかになります。正しいパターンは、最初から各ライフサイクルステージのサブアカウントに個別にマッピングされた Cloud Connector を使用することです。

障害 4: ハイパースケーラーがホストするバックエンドに対して Private Link が評価されていない

SAP Private Link は、Azure または AWS でホストされるワークロードで利用可能ですが、チームが Cloud Connector に慣れているため、接続設計フェーズで評価されないことがよくあります。その結果、機密性の高いバックエンドデータ（例：Azure VM でホストされる S/4HANA）が不必要にパブリックインターネットを経由して転送され、本番稼働後のセキュリティレビューでコンプライアンス上のギャップとして表面化します。

障害 5: エンタープライズ規模のイベントボリューム向けに Event Mesh を選択

プロジェクトは、SAP Integration Suite内のEvent Mesh機能を選択し、最終的に異種ブローカー間で1日あたり数百万のイベントを処理するユースケースに対応します。Event Meshは、スターターおよび中程度のワークロードに適していますが、プロジェクト途中でのAdvanced Event Meshへの移行により、イベントスキーマガバナンスが中断され、すべてのコンシューマアプリケーションの再バインドが必要となり、計画外のライセンスコストが発生します。

障害 6: 共有サービスサブアカウントがない

SAP Cloud Transport Management、SAP Cloud ALM、および集中監視は、専用の共有サービスサブアカウントではなく、アプリケーションサブアカウントにデプロイされます。プロジェクトのエンタイトルメントが再編成されたり、アプリケーションサブアカウントが廃止されたりすると、トランスポート管理の設定が失われます。アプリケーションのライフサイクル変更に耐えられるよう、共有サービスは最初から分離しておく必要があります。

障害 7: Q1の課題が明確になる前にアーキテクチャが決定される

ソリューションが技術を中心に設計されています。「KymaとAdvanced Event Meshを使う」といった具合に、具体的なビジネスの課題が選択の原動力になっていません。6か月後、プロジェクトはビジネスがまだ実際には必要としていない統合パターンのためのインフラを構築しており、一方で真のボトルネック（S/4HANAにおける手動承認ワークフロー）は未解決のままです。アーキテクチャ上の決定は、名前の付いた非効率性に遡れるものでなければなりません。

FAQ#

Q: 当社のS/4HANAはオンプレミスです。それでもBTP上のCloud Foundryを使用できますか？

はい。BTP上のCloud Foundryは、Cloud ConnectorおよびDestinationサービスを介してオンプレミスのバックエンドに接続します。Cloud Connectorはお客様のオンプレミスネットワークにインストールされ、BTPサブアカウントへのアウトバウンドトンネルを確立します。そのため、お客様側でインバウンドのファイアウォールルールは不要です（ SAP BTP Connectivity）。その後、BTPアプリケーションは、ProxyTypeをOnPremiseに設定したDestinationを使用して、オンプレミス接続を利用します。これは、S/4HANAオンプレミス拡張における最も一般的な接続パターンです。

Q: Kymaの高コストが価値を持つのはどのような場合ですか？

Kymaのコストは、同等のテナント数でCloud Foundryよりも約25～30％高くなります。その主なコスト差は、マネージドKubernetesクラスターに起因します。このプレミアムが正当化されるのは、以下の場合です。(a) チームがすでにKubernetesスキルを有しており、学習曲線によるコストが発生しない場合、(b) ワークロードがイベント駆動型かつサーバーレスであり、Kymaの組み込みイベント基盤とサービスメッシュによってカスタム統合作業が削減される場合、または(c) アプリケーションに高度なネットワークセキュリティ（サービスメッシュ、サービス間のmTLS）が必要であり、Cloud Foundryではネイティブに提供されない場合。

Q: プロジェクトのスケジュールにリスクがある場合、何をスコープから外すべきですか？

まず、イベント駆動型統合レイヤーのスコープを縮小します。短期的にはAdvanced Event Meshを直接RFCまたはAPI呼び出しに置き換え、段階的なアップグレードを計画します。次に、初期導入時にはよりシンプルなアカウント構造（少数のディレクトリ、少数のサブアカウント）に集約しますが、ターゲット構造を文書化し、最初のテナントオンボーディング前に実装できるようにします。Dev/Test/Prodのサブアカウント分離はスコープから外さないでください。これを削除し、後で復元する必要が生じた場合の再作業コストは、ほぼ常に節約される時間を上回ります。

Q: チームの入れ替わりがあってもアーキテクチャの決定を残すには、どのように文書化すべきでしょうか？

アーキテクチャ決定記録（ADR）はプロジェクトリポジトリに保存することを最低条件とします。各ADRには以下を記録する必要があります：決定内容、検討した代替案、根拠（Q1の課題に関連付けること）、および日付。BTP固有の決定については、以下を記載します：選択したランタイムとその理由、バックエンドシステムごとの接続パターン、アカウント構造図、および命名規則ドキュメントの参照先（BTP-F05を参照）。これらのドキュメントはコードと共にバージョン管理されるため、スライドデッキよりも有用です。

Q: 複数の事業部門向けに社内SaaS製品を構築しています。どのランタイムとデータ分離戦略を採用すべきですか？

標準的なパターンでは、プロバイダサブアカウント（アプリケーションをホスト）と、ビジネスユニットごとに1つのコンシューマサブアカウントを使用します（ SAP Architecture Center — Multi-Tenant SaaS Reference Architecture）。ランタイムには、Cloud FoundryとKymaのどちらも使用可能であり、CAPフレームワークは両方をサポートしています。データ分離については、SAPはコストと分離のバランスとして、HANA HDIコンテナスキーマ分離（テナントごとに1つのHDIコンテナ）を推奨しています。カラム弁別子は、リスクが非常に低いデータにのみ有効です。テナントごとに専用データベースを使用すると、最大の分離が得られますが、HANA Cloudのコストが大幅に増加します。ABAP環境は、このモデルでのマルチテナントSaaSをサポートしていません。

Q: S/4HANA Cloud のビジネスイベント消費に適したイベントツールは何ですか？

SAP Cloud Application Event Hubは、S/4HANA Cloud、SuccessFactors、その他のSAPクラウドアプリケーションからネイティブビジネスイベントを消費するための適切な出発点です。サポート対象のSAPクラウドアプリケーションに直接接続し、カスタムイベントチャネルの設定を必要とせずに、BTP拡張アプリケーションにイベントを公開します。非SAPシステムにまたがる異種環境や高ボリュームのシナリオでは、SAP Integration Suite Advanced Event Meshがマルチブローカーの基盤と集中管理の可視性を提供します。

概要#

実際のBTPアーキテクチャの決定は、ランタイムの選択、接続設計、アカウント構造の3つの領域に集約されます。これらの決定は複合的に影響し合います。誤ったランタイムの選択は単独で留まらず、利用可能な接続オプション、コストモデル、チームの運用負荷にまで影響を及ぼします。

この記事で紹介するパターンは、エンタープライズ規模で実際に機能するものを反映しています。ほとんどの拡張シナリオではCloud Foundry、チームがKubernetesに対応しておりイベント駆動型アーキテクチャが中心となる場合はKyma、ABAP Cloud開発が明確な目的である場合にのみABAP環境を使用します。接続性はバックエンドの物理的な場所に従います。オンプレミスの場合はCloud Connector、ハイパースケーラーでホストされている場合はPrivate Linkの評価（ SAP Architecture Center — Secure Connectivity with SAP Private Link）、インターネットの場合はProxyType Internetを使用したDestinationサービスです。アカウント構造は、初日からライフサイクルステージを分離し、共有サービスをアプリケーションサブアカウントから分離する必要があります。

意思決定基準の質問（Q1～Q3）は、形式的なものではなく、ゲートとして扱ってください。Q1（具体的な課題の明確化）を省略したプロジェクトは、BTPアーキテクチャを過剰に設計し、ビジネス価値を十分に提供できないことが常です。

次に読むべきもの#