サブアカウント設計：パターンと原則

JinJin48

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

May 14, 2026 · 23 min read

本記事の位置づけ#

参考資料#

1) サブアカウント設計の全体像#

SAP BTPは、3段階のアカウント階層を通じてプラットフォームリソースを整理します。各階層は明確なガバナンスの役割を果たし、互換性はありません（ SAP BTPアカウントモデル）。

グローバルアカウント、ディレクトリ、およびサブアカウントは、それぞれ独自のガバナンスレイヤーを所有しています。これらは互いに代替するものではありません。

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

BTPランドスケープ内でオンプレミスのS/4HANAと通信する必要がある各サブアカウントには、独自のCloud Connectorインスタンス登録が必要です。これは、サブアカウントの増加に伴う接続コストとして最も過小評価されがちな点です（ SAP BTPのベストプラクティス）。

[S/4HANA on-premise]
        │
  [Cloud Connector]    ←── registered per subaccount
        │
  ┌─────┴──────────────────────────────────────┐
  │  BTP Global Account                         │
  │  ┌──────────────┐  ┌──────────────────────┐ │
  │  │ Dev Directory│  │ Prod Directory       │ │
  │  │ ┌──────────┐ │  │ ┌──────────────────┐ │ │
  │  │ │ DEV sub  │ │  │ │ Consolidation    │ │ │
  │  │ └──────────┘ │  │ │ sub              │ │ │
  │  │ ┌──────────┐ │  │ └──────────────────┘ │ │
  │  │ │ TEST sub │ │  │ ┌──────────────────┐ │ │
  │  │ └──────────┘ │  │ │ PROD sub         │ │ │
  │  └──────────────┘  │ └──────────────────┘ │ │
  │                    └──────────────────────┘ │
  │  ┌──────────────────────┐                   │
  │  │ Services Directory   │                   │
  │  │ CI/CD sub, WZ sub    │                   │
  │  └──────────────────────┘                   │
  └─────────────────────────────────────────────┘
        │
[SAP S/4HANA Cloud]  ←── destination configuration per subaccount

重要ポイント: Cloud Connectorのトンネル、宛先設定、信頼設定はすべてサブアカウントスコープです。ランドスケープにサブアカウントを追加すると、この運用オーバーヘッドは設計上倍増します — 後から気づくのではなく、事前に計画してください。

3) 成熟度マップ#

すべてのサブアカウント設計パターンが同等の本番環境対応性を持つわけではありません。シンプルなモデルは無条件に本番環境対応ですが、より高度なモデルには、多くの組織が見落としがちなガバナンスの前提条件が必要です（ SAP BTP アカウントモデル（ディレクトリとサブアカウントを使用））。

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

アカウント階層計画#

ランドスケープセグメンテーション#

エンタイトルメントガバナンス#

Identity and Access（アイデンティティとアクセス）#

命名規則とタグ付け#

5) 意思決定基準#

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

Q1. このBTPプロジェクトが解決する、測定可能な統合または運用上のギャップは何ですか？

BTPサブアカウントの複雑性はスコープに応じて拡大します。単一の承認ワークフローを自動化するチームには、シンプルな3層ランドスケープが必要です。6つの並行する統合ストリームを運用するチームには、プロジェクトの分離が必要です。ランドスケープを設計する前に、具体的な課題を明確に定義してください。「BTPが必要」という曖昧な指示では、未知の将来に対応するために過大な規模のランドスケープが生まれます。

Q2. このワークロードには、どのようなデータ主権、データ保存地、およびデータ分離の要件が適用されますか？

BTPにおけるデータ分離は、Cloud Foundryスペースレベルではなく、サブアカウント境界で行われます（ SAP BTP アカウントモデル）。規制上または契約上の要件により、2つのアプリケーションが同一のデータベースインスタンスを決して共有してはならない場合、それぞれ別のサブアカウントが必要です。サブアカウント作成時のリージョン選択により、データの保存場所は特定のハイパースケーラーデータセンターに永続的に固定され、作成後に変更することはできません。

Q3. BTPランドスケープ管理を担当するチームはどこですか。また、そのチームは予算権限を持っていますか。

Global Account Administratorのアクセス権限には、エンタイトルメント管理権限が含まれます（ エンタイトルメントとクォータ）。指名され権限を与えられた管理者がいない場合、エンタイトルメントは管理されず、クォータの枯渇は検出されず、ガバナンスは機能不全に陥ります。ランドスケープスポンサーは、技術的なアクセス権限と、サブアカウント作成リクエストを承認する組織的な権限の両方を保持している必要があります。

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

ライセンスとコスト#

6) よくある障害#

障害 1: 複数の同時進行プロジェクトで DEV サブアカウントを共有する

複数のプロジェクトが1つのDEVサブアカウントを共有すると、サービスインスタンスの依存関係が共有されます。あるプロジェクトがPostgreSQLやRedisのインスタンスを再作成すると、同じインスタンスを使用している他のプロジェクトのデータが失われます。この副作用はサブアカウントレベルでは回避できません。対策：1プロジェクトにつき1つのDEVサブアカウント。

障害 2: 統合レイヤーのスキップ

従来のDev/Test/Prodモデルでは、プロジェクトレベルのDEVから直接共有の本番環境へ移行します。スキーマの非互換性、競合するサービスバインディング、データ移行の問題といった統合の失敗は、障害コストが最も高い本番環境でのみ表面化します。統合サブアカウントは、本番データのリスクを伴わずに本番トポロジーを反映した管理された環境で、これらの問題を捕捉します。

障害 3: データ分離にCloud Foundryスペースを使用する

データアクセスとデータの可視性は、CFスペースの境界ではなく、サブアカウントの境界で分離されます（ SAP BTPのベストプラクティス）。CFスペースを使用してプロジェクト間やテナント間でデータを分離しているチームは、誤ったセキュリティの前提に基づいて運用しています。同じサブアカウント内の異なるスペースにある2つのアプリケーションは、サービスインスタンスを共有し、同じデータベースにアクセスできます。データの分離には、個別のサブアカウントが必要です。

障害 4: 開発ディレクトリにエンタイトルメント上限が設定されていない

管理対象エンタイトルメントディレクトリがない場合、すべてのサブアカウントは同じグローバルアカウントのエンタイトルメントプールからリソースを消費します（ ディレクトリとサブアカウントを使用したアカウントモデル）。開発用やテスト用のサブアカウントでは、開発者が実験のために自由にサービスをプロビジョニングできるため、本番環境用に確保されたクォータを静かに消費してしまう可能性があります。その結果、本番環境でのサービスプロビジョニングが、3か月前の開発実験ですでにクォータが消費されていたために、本番稼働開始時に失敗するという障害モードが発生します。

障害5：ランドスケープ起動時の命名規則未定義

Account Explorerの検索はサブアカウント名に依存しています。モニタリングダッシュボードやTerraformのステートファイルはサブアカウント名を参照します。各プロジェクトチームがアドホックに名前を選択すると、サブアカウントが50以上になった時点でランドスケープの検索が困難になります。サブアカウントの名前を変更するには再作成が必要です。これは、名前が宛先設定やロールコレクションの割り当てに組み込まれているためです。最初のサブアカウントを作成する前に、<組織>-<プロジェクト>-<環境>-<リージョン> という命名スキーマを定義してください。

障害6：設計時に接続オーバーヘッドを無視

Cloud Connectorのシステムマッピング、宛先構成、およびSAP S/4HANA Cloud API認証情報は、すべてサブアカウントごとの構成です。サブアカウントを（分離のために正しく）増やすランドスケープ設計において、接続設定のオーバーヘッドを考慮しない場合、運用保守コストを過小評価することになります。オンプレミスアクセスを必要とする新しいサブアカウントごとに、Cloud Connectorエントリ、宛先、および構成・保守用のテクニカルユーザーが必要となります。

障害7：サブアカウント作成後にアイデンティティプロバイダ設定を先送り

SAP BTPと企業IDプロバイダー間のSAMLトラスト設定は、サブアカウントごとの操作です。先にサブアカウントを作成し、後からフェデレーションを計画するチームは、既に構築された環境全体に対して遡及的な設定作業を行う必要があります。これは運用コストが高く、ユーザーが企業IdPではなくデフォルトのSAP IDサービスに対して認証を行う期間が生じ、企業のセキュリティ監査に不合格となる原因となります。

FAQ#

Q: 開発とテストの両方で1つのサブアカウントを使用して、セットアップのオーバーヘッドを削減できますか？

短期的にはその通りです。しかし長期的には、今のセットアップの手間を、後で強制的な移行と引き換えにすることになります。開発環境では頻繁なサービス再起動、資格情報のローテーション、設定の実験が行われます。テスト環境には、テストスプリントを通じて安定した本番に近い設定が必要です。DEVでの開発者の操作が、テストパイプラインが依存するサービスインスタンスをリセットした瞬間、SAPが別々のサブアカウントを推奨する理由が理解できるでしょう。まずは3層の基本構成から始めてください。

Q: サブアカウントの数はSAP BTPのライセンスコストにどのように影響しますか？

サブアカウント自体には個別のライセンス費用は発生しません（ エンタイトルメントとクォータ）。コストは、サブアカウント内でプロビジョニングされるサービスインスタンス、サービスサブスクリプション、およびコンピュートリソースによって決まります。サブアカウントの数が増えると、分離の可能性が高まりますが、これは多くの場合、並行して実行されるサービスインスタンス（環境ごとに1つ）の増加につながります。エンタイトルメントの予算は、サブアカウント数ではなく、サービスに対して計画してください。

Q: 初期プロジェクトフェーズからサブアカウントの増設をスコープ外とするべきタイミングはいつですか？

追加のサブアカウントが現在のプロジェクトの具体的なニーズではなく、理論上の将来の要件に対応する場合は、その使用を控えてください。1つの統合シナリオをデプロイするプロジェクトには、並行開発のためのプロジェクト分離型DEVサブアカウントは不要です。必要なのは3つのサブアカウント（Dev、Test、Prod）と、2つ目のプロジェクトが開始された際の拡張計画です。時期尚早なサブアカウントの増設は、即時のメリットなしに接続設定のオーバーヘッドを追加するだけです。

Q: ガバナンス監査のためにサブアカウントの設計判断をどのように文書化すればよいですか？

最低限、以下の内容を文書化すること：選択したセグメンテーション軸とその理由、命名規則とその構成要素、サブアカウントごとのエンタイトルメント割り当てと承認者、適用したトラスト設定、およびCloud Connectorのシステムマッピング。これらをプロジェクト文書とともにアーキテクチャ決定記録（ADR）として保存すること。BTPコックピットの説明フィールド（バージョン管理されていない）には保存しないこと。

Q: Cloud Foundry スペースレベルの分離は、個別のサブアカウントの必要性を代替するものですか？

いいえ。これはBTPランドスケープ設計において最も一般的で最も危険な誤解です。Cloud Foundryスペースは組織化とアクセス制御の分離を提供しますが、データの分離は提供しません（ SAP BTPアカウントモデル）。サービスインスタンスは同じサブアカウント内のスペース間で共有できます。2つのチームまたは2つのテナントがデータベースアクセスを共有してはならない場合、個別のサブアカウントが必要です。データ分離のためにCFスペースに依存すると、BTP独自のアクセスモデルが保護しないデータ漏洩にさらされることになります。

Q: エンタープライズ規模のBTPランドスケープにおける標準的なサブアカウント数はいくつですか？

2つの事業部門で5～8件のBTPプロジェクトを運用する中堅企業では、通常20～35のサブアカウントに到達します。プロジェクトごとに3サブアカウント（15～24）、1～2の統合サブアカウント、1～2の本番サブアカウント、さらに3～5のサービスサブアカウント（CI/CD、Work Zone、API管理、モニタリング）です。サブアカウントが50を超えると、Account Explorerによるナビゲーションとガバナンスツール（Terraform、モニタリングダッシュボード）は、オプションではなく前提条件となります。

Q: サブアカウントが割り当てられたクォータを使い切るとどうなりますか？

そのサブアカウントでは、サービスプロビジョニングが即座に失敗します。グレースフルデグラデーション（段階的な機能低下）もキューもなく、失敗前にユーザーに表示される警告もありません。プロビジョニングAPIがエラーを返します。既存の実行中のサービスインスタンスには影響はなく、新しいプロビジョニング試行のみが失敗します。修正には、グローバルアカウント管理者がサブアカウントの割り当て量を増やす必要があります。この変更は即座に有効になりますが、多くの場合、活発な開発中またはリリース期間中に手動による介入が必要となります。

概要#

サブアカウント設計は一度きりの作業ではありません。それは、すべての下流のBTPプロジェクトを形作る基盤となるガバナンス上の決定です。3層のDev/Test/Prodモデルは正しいベースラインですが、プロジェクトごとに分離されたDEVサブアカウントと統合レイヤーがなければ、マルチプロジェクト環境では機能しません。データの分離はサブアカウントの境界で行われます。規制上または契約上のデータ分離が必要な場合、Cloud Foundryのスペースはサブアカウントの分離の代わりにはなりません。ディレクトリ上のエンタイトルメント管理、命名規則、SAMLトラスト設定は、ローンチ後のクリーンアップ項目ではなく、ローンチ前の前提条件です。最初のサブアカウントが作成される前に構造を正しく設定してください。なぜなら、稼働中のランドスケープを再構築するには、サブアカウントの再作成、エンタイトルメントの再割り当て、すべてのCloud Connectorマッピングの再設定をゼロから行う必要があるからです。

次に読むべきもの#