Title here
Summary here
命名規則：パターンと原則
TL;DR
- SAPが公式に命名制約を提供しているリソースタイプは、サブドメイン（最大63文字、小文字、ハイフンのみ）とサービスインスタンス（英数字、ハイフン、アンダースコア）の2種類のみです。それ以外の宛先、ロールコレクション、ディレクトリなどは、組織が定義した命名規則が必要です。
- 命名規則は、最初の本番サブアカウントが存在する前のガバナンス設計段階で確立する必要があります。50以上のサブアカウント、数十のサービスインスタンス、数百の宛先にわたる命名の後付けは、構成変更ではなく、複数スプリントにわたる移行作業となります。
- 最もコストのかかる命名の失敗は、形式の誤りではなく、デプロイ後に変更される宛先名です。宛先はアプリケーションコード内でシンボリック名によって解決されるため、名前を変更するということは、xs-app.json、CAPサービス、統合フロー、およびそれを参照するすべての自動化スクリプトなど、すべての利用者に影響が及びます。
本記事の位置づけ
| ID | カテゴリ | コンポーネント | スコープ |
|---|---|---|---|
| BTP-F01 | 概要 | BTPアーキテクチャ設計 | 概要と主要な決定事項 |
| BTP-F02 | アカウント設計 (1) | サブアカウント設計 | パターンと原則 |
| BTP-F03 | アカウント設計 (2) | エンタイトルメントとクォータ管理 | パターンと原則 |
| BTP-F04 | 認可 (1) | ロールコレクション設計 | パターンと原則 |
| BTP-F05 | 認可 (2) | 命名規則 | パターンと原則（本記事） |
| BTP-F06 | 開発と移送 | CI/CDと移送管理 | パターンと原則 |
| BTP-F07 | ユースケース | BTPアーキテクチャ設計 | ユースケースと決定パターン |
参考資料
| リソース | URL |
|---|---|
| 命名およびディレクトリテンプレート（BTPベストプラクティス） | help.sap.com → |
| アカウントモデル（ラベル仕様） | help.sap.com → |
| サービスインスタンスの作成 — CF CLI（文字制約） | help.sap.com → |
| 接続性および宛先サービス | help.sap.com → |
| アカウントモデルの設定 | help.sap.com → |
1) 命名規則の全体像
BTPの命名規則は、4つの異なるリソースファミリーを対象としています。各ファミリーには、異なる技術的制約、異なる変更コストプロファイル、および異なる所有モデルがあります。
| リソースファミリー | 命名対象 | 主な管理者 |
|---|---|---|
| アカウントリソース | サブアカウント、ディレクトリ、サブドメイン、CF組織、スペース、Kymaクラスター、名前空間 | プラットフォーム / クラウド管理者チーム |
| サービスリソース | サービスインスタンス、サービスバインディング、サービスキー | アプリケーション / DevOpsチーム |
| 接続リソース | 接続先、Cloud Connectorシステムマッピング | インテグレーション / プラットフォームチーム |
| 認可リソース | ロールコレクション（カスタム）、ラベルボキャブラリ | セキュリティ / ガバナンスチーム |
これらは代替可能ではありません。サブアカウント名はコックピットを整理し、宛先名はランタイムのルックアップキーであり、サービスインスタンス名はAPIや課金に表示され、ロールコレクション名はIdPグループマッピングルールに現れます。これらのいずれかをリネームすると、影響範囲が異なります。（ SAPベストプラクティス）
2) S/4HANA への接続方法
BTPの命名規則は、SAP BTPがSAP S/4HANAに接続する際に運用上極めて重要になります。命名に関する決定事項は、以下の3つの統合ポイントに直接影響を及ぼします。
S/4HANA (ABAP system)
|
| [Cloud Connector tunnel]
|
BTP Subaccount ──── Destination: "s4hana-prod"
| ↑
| referenced by name
| in xs-app.json /
| CAP services /
| Integration Suite iFlows
|
Service Instance: "connectivity-svc-integration-prod"
|
Role Collection: "PROD_S4Integration_Viewer"重要ポイント: BTPサブアカウントにデプロイされたアプリケーションが destinationService.getDestination("s4hana-prod") を呼び出す場合、文字列 "s4hana-prod" はアプリケーションロジックにハードコードされています。運用チームが一貫性のために宛先名を "sap-s4hana-prod-eu" に変更すると、すべてのコンシューマーを同時に更新しない限り、接続は設定エラーではなく404で静かに切断されます。
同じロックインは、Kubernetesデプロイメント、MTA記述子、CAPバインディング設定で参照されるサービスインスタンス名にも存在します。最初のデプロイメントの前に命名を確立し、後から変更しないでください。（ SAPベストプラクティス）
3) 成熟度マップ
| リソースタイプ | 成熟度 | 備考 | |
|---|---|---|---|
| サブドメイン / CF組織の命名 | ✅ 本番環境対応 | SAPがパターンとハード制約（63文字、小文字、ハイフン）を文書化。逸脱は不可。 | |
| サービスインスタンスの命名 | ✅ 本番環境対応 | SAPが文字セット（英数字、ハイフン、アンダースコア）を文書化。パターンは組織定義だが、制約はプラットフォームによって強制される。 | |
| サブアカウントの表示名 | ⚠️ 前提条件ありで対応可能 | SAPが例と原則を提供。技術的な制約は強制されず、一貫性はガバナンスの規律に完全に依存する。 | |
| ディレクトリの命名 | ⚠️ 前提条件ありで対応可能 | SAPがガイダンス（説明的、機能/地域/子会社別）を提供。人的プロセス以外に強制メカニズムはなし。 | |
| 宛先の命名 | ⚠️ 前提条件ありで対応可能 | SAP公式パターンなし。デプロイ後の変更コストが高い。事前のガバナンスが必要。 | |
| ロールコレクションの命名 | 🔶 アーリーアダプター | SAP公式の命名規則なし。コミュニティパターンは存在するが、SAPによる検証は未実施。サブアカウント間の不整合が監査の複雑性を生む。 | |
| ラベル語彙 | ⚠️ 前提条件ありで対応可能 | SAPが構造（最大10ラベル、最大10値、大文字小文字を区別）を文書化。語彙ガバナンスは組織定義され、普及前に強制される必要がある。（ SAPヘルプポータル） |
4) 要件チェックリスト
サブアカウントとディレクトリの命名
| チェックリスト項目 | 重要な理由 |
|---|---|
| 最初の非トライアルサブアカウントを作成する前に命名パターンを定義する | 一貫性のない形式では、サブアカウントが50を超えるとAccount Explorerが検索不可になる |
表示名には大文字を使用した自然言語を使用する（例：HR Dev、Sales Prod） | 表示名はグローバルアカウントのコンテキストでコックピットに表示される。ここでは簡潔さよりも明確さを優先する |
表示名から小文字＋ハイフンを使用してサブドメインとCF組織を派生させる（例：mycompany-hr-dev） | SAPの公式推奨。URLエンコーディングの競合や大文字小文字の衝突問題を防止する |
| サブドメインを63文字以内に抑える | SAPのハード制約：サブドメインは63文字を超えないURLに表示される |
| サブドメインとCF組織名に会社識別子をプレフィックスとして付ける | 会社プレフィックスにより、マルチテナント環境やパートナー管理環境での衝突を防止する |
| DEV/TEST/PROD全体で同一のCFスペース名とKymaネームスペース名を使用する | 異なるサブアカウントのスペース間にはシステムレベルのリンクは存在しない。同一名のみが唯一のトレーサビリティメカニズムとなる |
| 構造化軸（機能、地理、子会社）を反映した説明的なディレクトリ名を使用する | ディレクトリ名はAccount Explorerで表示される唯一のグループ化ラベルである |
| 最初のプロジェクトをオンボーディングする前に、ガバナンステンプレートに命名パターンを文書化する | サブアカウントの事後的な名前変更には、Cloud Connectorマッピング、IAM割り当て、自動化スクリプトの更新が必要となる |
サービスインスタンスの命名
| チェックリスト項目 | 重要性 |
|---|---|
| 英数字、ハイフン、アンダースコアのみを使用し、スペースは使用しない | SAPの公式制約であり、CF APIで強制されます。スペースがあるとCLIエラーが発生します（ SAPヘルプポータル） |
インスタンス名にサービス短縮名を埋め込む（例：xsuaa-、hana-、dest-svc-） | サービス管理画面ではサービス種別のコンテキストが表示されないため、名前だけで内容がわかるようにする必要があります |
環境識別子を埋め込む（例：-dev、-test、-prod） | 異なるサブアカウントのサービスインスタンスはリンクされないため、名前がそのランドスケープ段階を示す唯一の指標となります |
| 複数のプロジェクトがサブアカウントを共有する場合、アプリケーションまたはプロジェクト識別子を埋め込む | 請求情報に同一サービスの複数インスタンスが表示された際、運用上の混乱を防ぎます |
バインディング名とキー名はインスタンスと同じ命名規則で定義する（例：xsuaa-hr-prod-binding） | バインディングとキーはサービス詳細やCLI出力に表示されるため、一貫した命名でサポート時間を短縮できます |
| 本番環境の認証情報については、インスタンスごとにサービスキーを最大1つに文書化する | インスタンスごとに複数のキーがあると、古いキーがローテーションされない場合に監査リスクが生じます |
宛先の命名
| チェックリスト項目 | 重要性 |
|---|---|
| 宛先名は公開API契約として扱い、初回デプロイ前に定義する | アプリケーションコード、MTA記述子、統合フローは宛先名を参照するため、変更にはコードリリースが必要（ SAPヘルプポータル） |
<ターゲットシステム>-<環境> または <ターゲットシステム>-<プロトコル> のパターンを使用（例：s4hana-prod、successfactors-odata-test） | 宛先設定を開かなくても、オペレーターがターゲットと目的を即座に把握可能 |
| 環境修飾子は、宛先がステージ分離されたサブアカウントに存在する場合のみ省略する | 共有サービスサブアカウントやマルチテナントシナリオでは、修飾子が必須 |
| 全環境（DEV、TEST、PROD）で同じ宛先名を維持し、ターゲットURLのみ変更する | アプリケーションコードは環境に依存せず、BTPコックピットの設定のみ環境ごとに変更 |
backend や api のような汎用的な名前は避ける（最初のプロジェクトでは機能しても、3つ目のプロジェクトでは曖昧になる） | 曖昧な名前は、オペレーターがターゲットシステムを特定するために全宛先を開く必要が生じる |
| プロジェクトアーキテクチャ文書に、宛先名、ターゲットシステム、認証方式、スコープを記載する | 宛先は設定でありコードではないため、MTAやTerraformで管理しない限りgitにバージョン履歴が残らない |
ロールコレクションの命名
| チェックリスト項目 | 重要性 |
|---|---|
| 最初のカスタムロールコレクションを作成する前に、カスタムロールコレクションの命名パターンを確立する | ロールコレクションはSAP Cloud Identity Servicesのグループマッピングルールに表示されます。事後的な名称変更には、すべてのIdPグループマッピングの更新が必要になります |
環境と機能をエンコードするパターンを使用する：<環境>_<機能>_<レベル>（例：PROD_IntegrationSuite_Admin） | 各コレクションを展開しなくても、コックピット上でコレクションのスコープ、対象アプリケーション、権限レベルを一目で把握できます |
ランドスケープ全体に適用されるコレクションでない限り、必ず環境を区別する（DEV_、TEST_、PROD_） | 本番環境で誤って割り当てられたSubaccount_Administratorロールコレクションは、監査証跡なしでは復旧できません |
複数の環境にまたがるコレクションにはALL_プレフィックスを使用する（例：ALL_BTPCockpit_Viewer） | 意図的にクロス環境スコープであることを示し、誤った環境固有の扱いを防ぎます |
| 権限レベルにはSAPのAdmin/Viewer/Auditorサフィックス規則に従う | 一貫したサフィックスにより、IdPグループマッピングルールでプレフィックスパターンを使用できるようになり、個別のマッピングルール数を削減できます |
| デプロイ前に、各カスタムロールコレクションにマッピングするIdPグループを文書化する | 文書化がない場合、IdPグループとロールコレクションのマッピングは暗黙知となり、担当者が変わると失われます |
ラベルガバナンス
| チェックリスト項目 | 重要性の理由 |
|---|---|
| グローバルアカウントのラベル用語集を、プロジェクトがラベルを作成する前に定義する | ラベルは大文字小文字を区別する。Dev、dev、DEVはそれぞれ別のラベルとなり、バリアントが存在するとフィルタリングが機能しなくなる |
最低限、Cost Object（コスト対象）、Landscape（ランドスケープ）、Contacts（連絡先）、Status（ステータス）を定義する | SAP公式の例であり、これら4つでコスト追跡、環境分類、所有権、ライフサイクル管理をカバーする |
カテゴリ別ラベル（例：Landscape: Dev | Test | Production）の値セットを標準化する | DEV、Development、dev environmentのような自由記述値はすべて同じ意味だが、アカウントレベルのフィルタリングを破壊する |
| ラベルをセキュリティ区分の唯一のメカニズムとして使用しない | ラベルはメタデータのみであり、アクセス制御はサブアカウントとロールコレクションレベルで行う。ラベルレベルでは決して行わない |
すべてのサブアカウントとディレクトリに、少なくとも2つの値を持つContactsラベルを適用する | 単一所有者のサブアカウントは、所有者が離脱した場合に運用リスクが生じる |
| ランドスケープの拡大に伴い、ラベル用語集を四半期に少なくとも1回見直す | ラベルは蓄積される。未使用のキーはエンティティあたり10ラベルの制限を消費し、コックピットのフィルタリングにノイズを追加する |
5) 意思決定基準
最初に問うべき3つの質問
Q1. 現在10を超えるサブアカウントをお持ちですか、または今後6か月以内に10に達する見込みですか？
もし「はい」なら、命名規則はオプションではなく、インフラそのものです。Account Explorerの検索、コストレポート、IAMレビューはすべて、一貫性があり読みやすい名前に依存しています。10という閾値は恣意的なものではなく、一貫した命名の手がかりなしに、人間の記憶ではどのサブアカウントがどのプロジェクトに属するかを追跡できなくなるポイントです。（ SAPベストプラクティス）
Q2. チーム間での命名規則の所有者は誰で、それを強制できますか？
命名規則は、所有権が分散していると機能しません。明確な所有者（通常はプラットフォーム / クラウドセンター・オブ・エクセレンスチーム）がいなければ、個々のプロジェクトチームは局所的に最適化された名前を作成し、全体として破綻します。所有者は、規則に違反するサブアカウント作成リクエストを拒否する権限を持たなければならず、単に助言するだけでは不十分です。
Q3. ネーミングガバナンスに対する経営陣のスポンサーシップはありますか？
命名規則は、開発者の自律性（プロジェクトチームは自身のリソースを自由に命名したい）、運用ツール（自動化スクリプトは名前変更に脆弱）、そして財務（コスト帰属レポートは一貫した命名に依存する）に影響を及ぼします。部門間の紛争を解決し、事後的なクリーンアップに資金を提供できるスポンサーがいなければ、命名規則は1年以内に形骸化します。
プロジェクトコンテキストによるリソーススコープ
| プロジェクトの状況 | 命名の優先順位 |
|---|---|
| グリーンフィールドBTP導入、単一チーム | 4つのリソースファミリーすべて。最初のサブアカウント作成前に確立すること |
| 既存ランドスケープの拡張（5つ以上の新規サブアカウント） | サブアカウントと宛先の命名を最優先。サービスインスタンスとロールコレクションの命名は並行して実施 |
| S/4HANA拡張プロジェクト（BTPサイドバイサイド） | 宛先の命名がクリティカルパス。直ちに確立すること |
| マルチチーム共有プラットフォーム（CCoE管理） | 4つのファミリーすべてに加え、ラベル語彙のガバナンス |
| レガシーランドスケープのリファクタリング（既存サブアカウント20以上） | まず既存の命名を監査。将来の命名規則を確立し、プロジェクト単位で段階的に移行 |
| 明確な課題が未特定 | 停止。命名規則の前にアカウントモデル設計（BTP-F02）を調整すること。 |
コストとライセンスに関する影響
| リソース | 命名コスト | 名称変更コスト | |
|---|---|---|---|
| サブアカウント表示名 | ゼロ | 低（コックピットのみ、下流への影響なし） | |
| サブドメイン | ゼロ | 高 — 新しいサブアカウントの作成が必要。サブドメインは不変 | |
| CF組織/スペース | ゼロ | 中 — CFを対象としたすべてのCI/CDスクリプトとアプリマニフェストの更新が必要 | |
| サービスインスタンス | ゼロ | 高 — MTA記述子、Kubernetesマニフェスト、CAPバインディング、CI/CDパイプラインの更新が必要 | |
| 宛先 | ゼロ | 非常に高 — すべてのアプリケーションコード利用者の更新と新バージョンのリリースが必要 | |
| ロールコレクション | ゼロ | 高 — SAP Cloud Identity ServicesにおけるすべてのIdPグループマッピングルールの更新が必要 | |
| ラベルキー/値 | ゼロ | 低 — ラベルはメタデータのみ。下流への技術的依存関係なし |
6) よくある障害
障害 1: 最初の本番サブアカウントの前に命名規則がない
チームは、まだ標準が存在しないため、プロジェクトチーム名（HR-Portal-DEV、portal-hr-d、HumanResources_Dev）を使用してDEVおよびTESTサブアカウントを作成します。PRODサブアカウントが作成される頃には、3つの一貫性のないパターンが確立されており、チームはどれを標準化すべきかで議論します。解決には手動監査と、時間的制約下でのガバナンス上の決定が必要です。（
SAPベストプラクティス）
障害 2: 初期ターゲットを反映した宛先名であり、論理的な目的を反映していない
開発者は、プロジェクト開始時の特定のシステムホスト名に基づいて、s4hana-eu-central-1-system-001 という宛先を作成します。6か月後、システムは2つのノードに負荷分散され、ホスト名は意味を失います。この名前は現在、不正確で誤解を招くものとなっていますが、コードリリースなしでは変更できません。正しいアプローチ：宛先は、そのインフラストラクチャ上の識別子ではなく、論理的な役割（s4hana-prod）に基づいて命名します。
障害 3: マルチステージサブアカウントにおける環境修飾子のないサービスインスタンス名
チームは単一のサブアカウントでDEVおよびTESTワークロードを管理しています。xsuaa-app および xsuaa-app-v2 という名前のサービスインスタンスを作成しました。3か月後、運用担当者はバインディングを確認しない限り、どのインスタンスがどのデプロイメントで使用されているかを判断できなくなります。環境修飾子（-dev、-test）を使用していれば、即座に区別がついたはずです。
障害 4: 有機的に増殖するロールコレクション名
新しいアプリケーションがオンボーディングされました。開発者は MyApp_Admin および MyApp_User という名前のロールコレクションを作成します。次のプロジェクトでは ProjectB_Administrator と ProjectB_ReadOnly を作成します。IdP グループマッピングルールには、さまざまな形式が混在して蓄積されます。セキュリティ監査ですべての管理者レベルのロールコレクションをレビューする必要がある場合、名前が権限レベルを一貫してエンコードしていないため、チームは各コレクションを手動で検査する必要があります。
障害5: 初年度以降のラベル用語の乖離
グローバルアカウントは、適切に管理されたラベル（Landscape: Dev、Landscape: Test、Landscape: Production）で始まります。6か月後、新しいチームが参加し、Landscape: DEV と Landscape: development を作成します。Landscape: Dev でフィルタリングされたCockpitは、開発用サブアカウントの一部のみを返すようになります。コストレポートは3つのバリエーションに分割されます。ラベルは大文字と小文字を区別し、ガバナンスの強制メカニズムがないため、これを修正するにはすべてのサブアカウントに手を加える必要があります。
障害 6: URL制約に対してサブドメインが長すぎる
プロジェクトはサブドメイン mycompany-human-resources-development-subaccount（50文字）を作成します。これは63文字の制限に収まりますが、CF APIエンドポイントがリージョンサフィックスを追加するため、一部のツールでは合計URLが制限を超えます。この障害は断続的に発生し、環境に依存します。略語を使用してください：mycompany-hr-dev は16文字で同じ結果を達成します。
障害 7: DEV/TEST/PROD 間で CF スペース名が異なる
DEV サブアカウントには portal-dev というスペースがあり、TEST では portal-qa、PROD では portal を使用します。CI/CD パイプラインでは、1つのパラメータ化された値ではなく、3つの個別のスペース名設定が必要です。SAP は、異なるサブアカウントのスペース間にシステムレベルのリンクが存在しないため、すべてのランドスケープステージで同一のスペース名を使用することを明示的に推奨しています。
FAQ
Q: SAPはBTPリソースの命名規則を強制していますか？
SAPは技術的な制約（サブドメインの文字セットと長さ、サービスインスタンスの文字セット）を強制しますが、組織的な命名パターンは強制しません。パターンと一貫性の規律はお客様の責任です。SAPのベストプラクティスガイドでは例と原則が示されていますが、abc123とHR Devを拒否するようなコックピット検証は存在しません。（
SAPベストプラクティス）
Q: 当社には、確立された命名規則を持つオンプレミスのSAPランドスケープがあります。それを再利用できますか？
部分的に。オンプレミスの命名規則（SID 3文字のシステム識別子）はシステムレベルで機能し、BTPリソースレベルでは機能しません。環境分類（DEV/QAS/PRD）と機能領域分類（HR、FI、MM）をBTP名の構成要素として再利用してください。組織内の知識がなければ解読できない、難解なBASISの略語は引き継がないでください。
Q: 情報を名前にエンコードする代わりに、ラベルを使用すべきなのはどのような場合ですか？
運用上重要な情報を名前にエンコードする：環境、機能オーナー、論理的な目的。作成後に追加される横断的メタデータにはラベルを使用する：コストセンター、コンプライアンスフラグ、データ分類、連絡先。ラベルは変更可能だが、ほとんどのリソースにおいて名前は不変である。
Q: 複数の子会社がグローバルアカウントを共有する場合、命名はどのように扱えばよいですか？
サブドメインとCF組織に子会社プレフィックスを含める：subsidiary-a-hr-dev、subsidiary-b-sales-prod。エンタイトルメント管理を有効にしたディレクトリを使用して子会社ごとにグループ化します。これにより、単一のグローバルアカウント内で明確な課金、アクセス制御、および命名の境界が維持されます。
Q: ロールコレクション名は環境ごとに異なるべきですか？
はい、環境固有のコレクションについてはその通りです。PROD_IntegrationSuite_Admin は DEV_IntegrationSuite_Admin とは異なります。これらは異なるサービスインスタンスを指すロールを含んでいます。ランドスケープ全体の読み取り専用コレクションには、ALL_ を使用してクロス環境スコープを示します。
Q: 人事異動があっても命名規則を維持するにはどうすればよいですか？
規約を個人のWikiページではなく、ガバナンスフレームワーク内の企業標準として保存してください。含める内容：各リソースファミリーのパターン、その根拠、正しい名前と誤った名前の例、および所有者。これをBTPセットアップ自動化（Terraform、btp-setup-automator、MTAテンプレート）と一緒に保管し、パイプラインエンジニアが直接参照できるようにしてください。
概要
BTPの命名規則は、運用、ガバナンス、アーキテクチャの接点に位置します。サブドメインとサービスインスタンスという2つのリソースタイプには、SAPによって強制される技術的な制約があります。残りの4つ（宛先、ロールコレクション、ディレクトリ、ラベル）は、プラットフォームが強制しないため、組織的な規律が必要です。（ SAPベストプラクティス）
一貫して機能するフィールドパターン：アーキテクチャ設計時に命名規則を定義し、それを企業標準として文書化し、プラットフォームチーム内に責任者を割り当て、サブアカウント作成の自動化に組み込むこと。ランドスケープが稼働した後に命名を決めるプロジェクトは、本来の成果物の提供ではなく、クリーンアップに不釣り合いな時間を費やすことになります。63文字のサブドメイン制限は事実であり、50サブアカウントによる認知過多は選択の問題です。