SAP BTP（SAP Business Technology Platform、SAP のクラウドアプリ開発・統合基盤）を複数事業部で使い始めた組織で、気づくとコストと権限管理が破綻しているケースがあります。インフラ担当・SRE（Site Reliability Engineering、システムの信頼性を運用面で担保する役割）として BTP のガバナンス設計に関わる方に向けて、何が起きやすいか、なぜ起きるかを整理します。
BTP はオンプレミス中心だった SAP 環境を、クラウドネイティブなサービス群（SAP HANA Cloud、SAP Integration Suite、Cloud Foundry、Kyma Runtime など）に拡張するプラットフォームです。導入初期はアプリ開発とサービス提供に注目が集まりがちで、ガバナンス（統治の仕組み）の設計が後回しになりやすい構造があります。
何が起きるか
ガバナンス不在のまま BTP 運用が広がると、複数の事業部がそれぞれ独立に Subaccount（BTP のリソース分離単位で、AWS のアカウントや GCP のプロジェクトに近い概念）を作成します。
結果として同じ機能のサービスが重複して作られ、ネーミング規則もバラバラになります。
さらに深刻なのは権限設計です。各チームが個別に IAM（Identity and Access Management）を設定するため、過剰な権限を持つユーザーが放置されやすくなります。
コスト面では、entitlement（サービス利用権の割り当て）とクォータ（利用上限）が全社で可視化されず、気づいたときには請求額が想定を大きく超えている、という状況になりがちです。
運用面では監視・監査ログ・バックアップ・災害復旧（DR）の方針がSubaccountごとに異なり、インシデント対応の標準化が困難になります。
なぜ起きるか（原因の分解）
原因は大きく3段階に分けて考えられます。
第一に、アカウント階層設計の欠如です。BTP は Global Account の下に Directory（階層構造）、その下に Subaccount という3層構造を持ちますが、この階層をどう区切るか（事業部単位か、環境単位か、リージョン単位か）の方針がないまま運用が始まると、後から統合するコストが跳ね上がります。
第二に、Infrastructure as Code（IaC、インフラ構成をコードで宣言的に管理する手法）の不在です。Subaccount 作成やサービスの entitlement 割り当てを手作業のコンソール操作で行うと、構成の差分が積み重なり、誰が何をいつ変更したかの追跡ができなくなります。
第三に、CI/CD パイプラインと自動コンプライアンス検証の不在です。アプリのデプロイ標準やセキュリティポリシーがコードとして強制されないと、チームごとに解釈が変わり、Clean Core 原則（SAP 標準機能を極力カスタマイズせず、拡張はサイドカー的に分離する設計方針）の遵守もばらつきます。
これらが重なることで、監視・ログ・バックアップの標準化がされないまま規模だけが拡大し、障害対応の仕組み化が追いつかなくなります。
自分のプロジェクトが該当するかの確認方法
以下の観点で、現状の BTP 環境を棚卸ししてみてください。
- Global Account 配下の Directory・Subaccount 一覧を BTP Cockpit（管理コンソール）の「Account Explorer」で確認し、命名規則が統一されているか目視で確認する
- Subaccount ごとの entitlement（サービスプラン割り当て）をコンソールまたは BTP CLI (
btp get accounts/subaccount <ID> --show-quota) で取得し、未使用のまま確保されているクォータがないか確認する - 各 Subaccount の Role Collection（権限のまとまり）に、Administrator 相当の権限を持つユーザーが何人いるか棚卸しする
- Subaccount や Service Instance の作成が Terraform や Pulumi などの IaC ツール経由か、それともコンソールの手動操作で行われているか、変更履歴（Audit Log Service）で確認する
- コスト管理について、SAP BTP の Cost Analysis や外部の FinOps（クラウド費用を運用プロセスとして管理する考え方）ツールと連携しているか確認する
Subaccount 数が数十を超えている、あるいは命名規則にルールが見当たらない場合は、ガバナンス設計を見直す段階に来ていると判断してよいと考えます。
対策の手順
以下は段階的に進められる実務手順です。
1. アカウント階層の標準を先に決める
Directory の分割基準（本番/検証/開発、または事業部単位）を1枚のドキュメントにまとめ、新規 Subaccount 申請時にこの基準への準拠を必須にします。
2. IaC でSubaccount作成を宣言的に管理する
SAP は Terraform Provider for SAP BTP を公式提供しています。Subaccount の作成、entitlement の割り当て、Role Collection の付与をコードで管理することで、変更差分が Git 履歴として残ります。
terraform init
terraform plan -out=btp.plan
terraform apply btp.plan手動でコンソールから変更を加えた場合は、次の terraform plan で差分（drift、コードと実態のずれ）が検出できるため、定期的に plan を実行してドリフトの有無を確認する運用がすすめられます。
3. 中央集権的な ID 管理へ寄せる
SAP Cloud Identity Services を使い、各 Subaccount が個別に IdP（Identity Provider）を持つのではなく、全社で単一の ID 基盤に統合します。これにより権限監査の対象が一元化されます。
4. CI/CD にコンプライアンス検証を組み込む
アプリのデプロイパイプラインに、命名規則チェックや Clean Core 準拠チェックを自動化ステップとして追加します。人手のレビューだけに頼らない仕組みが、規模拡大後の一貫性を支えます。
5. コスト可視化とアラートを先に設定する
Subaccount ごとの利用量とクォータをダッシュボードで可視化し、閾値を超えたら通知が飛ぶようにしておきます。これは事後の請求額確認より、予防的なコスト管理につながります。
確認すべきことのまとめ
SAP BTP のマルチ Subaccount 環境は、放っておくと権限もコストも監査対象も分散していきます。
次の一歩として、まず現状の Subaccount 一覧とentitlement を棚卸しし、Terraform Provider for SAP BTP の導入余地があるか検討してみてください。
IaC 化と中央 ID 管理、CI/CD へのコンプライアンス検証組み込みの3点は、後回しにするほど移行コストが増える性質のものです。
規模が小さいうちに標準を決めておくことが、後の障害対応や監査対応の負荷を大きく左右します。