OCI Organizations (Tenancy Management)

解決する課題

組織が成長してテナンシ（OCI の最上位アカウント境界）が複数に増えると、請求がバラバラになり、契約クレジットの按分やガバナンスの統一が難しくなります。OCI Organizations（Tenancy Management）は、複数のテナンシを親子の階層で束ねて一元統治することで、これらの課題を解決します。

• 事業部・子会社・買収先などで増えたテナンシを一つの傘下にまとめて管理したい
• 請求を親テナンシに集約し、まとめて支払い・把握したい
• 購入したユニバーサルクレジットやサブスクリプションを複数テナンシで共有したい
• 子テナンシの操作に**組織横断のガードレール（ガバナンス）**を効かせたい
• 新しいテナンシを組織の管理下で作成・参加させ、野良アカウントの乱立を防ぎたい

AWS で言えば AWS Organizations に相当する位置づけです。AWS の「アカウント」が OCI の「テナンシ」に対応し、請求集約とガバナンスを束ねる発想は共通します。

主要概念と用語

• テナンシ（Tenancy）: OCI で契約・分離される最上位のアカウント境界。組織管理はこのテナンシを束ねる単位で行う。AWS の「アカウント」に相当する
• 組織（Organization）: 親テナンシを起点に、複数の子テナンシを束ねた管理上のまとまり。AWS Organizations の組織に相当する
• 親テナンシ（Parent / Root Tenancy）: 組織を統括する側のテナンシ。請求集約や組織管理の操作を行う中心。AWS の管理アカウントに近い
• 子テナンシ（Child Tenancy）: 組織に参加し、親の統治下に置かれるテナンシ。AWS のメンバーアカウントに近い
• テナンシの作成（Create child tenancy）: 親テナンシの管理者が、組織の傘下に新しい子テナンシを直接作成できる機能
• 既存テナンシの参加（Link / Invitation）: 既存の独立テナンシを招待し、組織に参加させる仕組み。承認を経て親子関係を結ぶ
• 集約請求（Consolidated Billing）: 子テナンシの利用料を親テナンシにまとめて計上し、組織全体の支出を一括で把握・支払いする仕組み
• サブスクリプション共有（Subscription Sharing）: 親が保有するユニバーサルクレジット契約などのサブスクリプションを、子テナンシに割り当てて共有する仕組み
• ガバナンスルール（Governance Rule）: 親から子テナンシへ横断的に適用する統制。リージョン許可やポリシー・タグなどを組織レベルで強制する
• Cross-Tenancy ポリシー（エンドースメント／アドミット）: テナンシをまたいでリソースアクセスを許可するための IAM の仕組み。組織内での共有を支える土台になる

仕様・制限・クォータ

• 組織は1 つの親テナンシを起点とし、その下に複数の子テナンシをぶら下げる階層構造で管理する
• 子テナンシは新規作成して傘下に置くか、既存テナンシを招待・参加させて組織に加える、の 2 通りで増やせる
• 集約請求は親テナンシに紐づく。子の利用料は親にロールアップされ、組織全体の請求が一本化される
• サブスクリプション／クレジットの共有は親から子へ割り当てる。どの子が共有を使えるかは親が管理する
• ガバナンスルールは親から子へ一方向に適用され、子テナンシ側はその制約の範囲内で運用する
• テナンシをまたぐリソースアクセスには Cross-Tenancy のエンドースメント／アドミットポリシーが別途必要で、組織に入れただけで全リソースが自動共有されるわけではない
• 組織に参加できるテナンシ数や子テナンシの作成上限などには**テナンシ単位の制限（クォータ）**があり、必要に応じてサービスリクエストで引き上げる
• 組織管理・請求の操作は原則としてホームリージョン側で扱う（IAM 系操作と同様の前提）

内部の仕組み

組織管理は、親テナンシを統治の起点として、請求のロールアップ・サブスクリプションの割り当て・ガバナンスの適用という 3 つの流れを子テナンシに対して行う仕組みです。

• 請求の集約: 各子テナンシで計測された使用量・コストが、課金エンジンを通じて親テナンシに集約される。親側で組織全体の請求と内訳を参照できる
• サブスクリプションの割り当て: 親が保有する契約（ユニバーサルクレジット等）を子テナンシに割り当てることで、子はその契約のクレジットや料率で利用できるようになる
• ガバナンスの適用: 親で定義したガバナンスルール（許可リージョン、ポリシー、タグなど）が子テナンシに伝播し、子の操作可能範囲を制約する
• 参加・離脱のライフサイクル: 既存テナンシの参加は招待と承認のやり取りを経て成立し、離脱すると親子関係と集約請求の紐づけが解かれる
• アイデンティティの独立性: 組織は請求とガバナンスを束ねるが、各テナンシの IAM（ユーザー・グループ）は基本的に独立しており、テナンシ間でリソースを共有するには Cross-Tenancy ポリシーを別に結ぶ

設計パターン / ベストプラクティス

• 親テナンシは管理専用に絞る: 親はガバナンスと請求の統括に徹し、本番ワークロードは子テナンシ側に置く。親の事故が組織全体に波及するのを避ける
• テナンシ分割の基準を決める: 事業部・環境（本番／検証）・規制境界などでテナンシを分ける方針をあらかじめ定め、コンパートメント分割で足りるケースと使い分ける
• ガバナンスルールでガードレールを敷く: 許可リージョンや必須タグ、共通ポリシーを組織レベルで強制し、子テナンシ任せのばらつきを防ぐ
• サブスクリプション共有でクレジットを最適化: ユニバーサルクレジットを子へ共有し、テナンシごとに別契約を抱える無駄をなくす
• 新規テナンシは組織経由で作る: 個別に独立テナンシを作らせず、組織管理から作成・参加させて統治下に置く
• Cross-Tenancy 共有は最小限に: テナンシをまたぐアクセスはエンドースメント／アドミットで必要な範囲だけ許可し、過剰共有を避ける

運用・監視

• 組織構造の把握: 親から組織配下のテナンシ一覧を定期的に確認し、想定外の参加・離脱がないかを点検する
• 請求の内訳を追う: 集約請求は親で一本化されるため、コスト配賦は子テナンシ単位やタグ単位で内訳を見て、どのテナンシがいくら使ったかを把握する（Cost Analysis と併用）
• 操作の監査: 「誰がいつテナンシを参加・離脱させたか」「ガバナンスを変更したか」は OCI Audit で追跡する。組織レベルの操作は影響が大きいため監査証跡が重要
• ガバナンス適用状況の確認: 親で定義したルールが子に意図どおり効いているかを点検し、子側の例外運用がないかを確認する
• サブスクリプション残量の管理: 共有しているクレジットの消費状況を監視し、枯渇前に補充・再配分する
• 権限不足の切り分け: 組織操作が行えない場合は、親テナンシ側の組織管理に関する IAM ポリシーが付与されているかを確認する

コスト

OCI Organizations（Tenancy Management）の組織管理機能そのものに対して、通常は別途の利用料は発生しないのが一般的です。課金されるのは、各テナンシで実際に利用したクラウドリソースの料金であり、それらが親テナンシへ集約されて請求されます。

組織化の主なコスト面のメリットは、請求を一本化して全体最適を図れることと、サブスクリプション（ユニバーサルクレジット）を子テナンシで共有してクレジットを無駄なく消費できることにあります。

セキュリティ

• 親テナンシ管理者の権限を厳格に管理: 親の組織管理者は組織全体に影響を与えられるため、対象者を限定し、多要素認証（MFA）を必須にする
• 最小権限で組織操作を分離: テナンシの参加・離脱、サブスクリプション共有、ガバナンス変更などの強い操作は、専用グループにのみ IAM ポリシーで許可する
• テナンシ境界は強い分離: 組織化しても各テナンシの IAM は独立しているため、テナンシ間共有は Cross-Tenancy のエンドースメント／アドミットで明示的に・最小限に結ぶ
• ガバナンスで規制境界を守る: 許可リージョンや必須タグを組織ルールで強制し、データ所在やコンプライアンス要件を子テナンシに一律で効かせる
• 組織操作の監査: テナンシのライフサイクル操作やガバナンス変更は OCI Audit で証跡を残し、内部不正や誤操作を検知できるようにする

Well-Architected の観点

• 運用上の優秀性（Operational Excellence）: 複数テナンシを組織で一元管理し、ガバナンスルールでガードレールを統一する。新規テナンシも組織経由で統制下に置ける
• コスト最適化（Cost Optimization）: 請求を親に集約して全体最適を図り、サブスクリプション共有でクレジットを無駄なく消費する
• セキュリティ（Security）: 親管理者を最小限にし、テナンシ間共有を Cross-Tenancy ポリシーで明示的に絞ることで、過剰権限と横移動のリスクを抑える
• 信頼性（Reliability）: 規制境界や事業部ごとにテナンシを分けて爆発半径を限定しつつ、組織として統一的に統治できる

試験で問われるポイント

関連サービス・比較

OCI Organizations と、相当する AWS のサービスである AWS Organizations を比較します。テナンシ（OCI）とアカウント（AWS）という最上位境界を束ね、請求集約とガバナンスを統括する点で発想が共通します。

なお OCI 内では、テナンシ内のコスト内訳把握に Cost Analysis / Budgets、操作の監査に Audit、リソース作成上限の統制に Compartment Quota を組み合わせて使います。

ハンズオン / CLI例

oci organizations 系のコマンドで、組織の参照や子テナンシの管理を行えます。次は、所属する組織と配下のテナンシ一覧を確認し、テナンシの参加要求（リンク）を扱う例です。

# 1) 自テナンシが属する組織の一覧を確認する
oci organizations organization list \
  --compartment-id "$TENANCY_OCID" --output table

# 2) 組織配下のテナンシ（子テナンシ）一覧を確認する
oci organizations tenancy list \
  --organization-id "$ORGANIZATION_OCID" --output table

# 3) 特定の子テナンシの詳細を取得する
oci organizations tenancy get \
  --organization-id "$ORGANIZATION_OCID" \
  --tenancy-id "$CHILD_TENANCY_OCID"

# 4) 既存テナンシを組織へ参加させる招待（リンク）の一覧を確認する
#    招待の作成・承認は強い操作のため、限定したグループにのみ許可する
oci organizations work-request list \
  --compartment-id "$TENANCY_OCID" --output table

# 5) 組織操作の監査は OCI Audit で追跡する（操作証跡の確認）
oci audit event list \
  --compartment-id "$TENANCY_OCID" \
  --start-time "2026-06-01T00:00:00Z" \
  --end-time "2026-06-28T00:00:00Z" --output table