OCIコンパートメント階層設計とIAMポリシーの書き方を図解！AWSアカウント分割との違いも整理
※当ページにはAmazonアソシエイト等の広告リンクを含みます。
公式ドキュメントで検証最終検証 2026-10-31編集部出典 4件
当ページの解説・制限値・構成図は、一般公開されている Oracle Cloud Infrastructure (OCI) 公式ドキュメント、Oracle Cloud Price List、および Oracle University 公開試験ガイドを一次根拠として検証し、独自のSVG視覚図解として作成しています。
1. AWS経験者のための「OCIリソース階層と用語」1対1マッピング
AWSでは「本番環境（Prod）」と「開発環境（Dev）」を分ける際、AWS Organizationsを使って「AWSアカウント自体を分ける（マルチアカウント構成）」のが一般的です。一方、OCIでは 1つのテナンシ（Tenancy＝最上位の契約単位）の中に、ツリー構造の「コンパートメント（Compartment）」を作って論理分割する アプローチが基本となります。
なぜOCIではコンパートメント分割がこれほど強力なのでしょうか。それは、VCNを1つのネットワーク用コンパートメントに置き、別のコンパートメントのVMやDBからそのサブネットを使える（クロス・コンパートメント参照） ので、管理権限だけを分けられるからです。ただし、コンパートメントだけではネットワークは分離されません。本番は開発と別のVCNに分け、DRGのハブ＆スポークで束ねる構成も検討します。
2. 現場でそのまま使える！推奨コンパートメント階層設計パターン
ルートの直下に、機能別（ネットワーク・セキュリティ）と環境別（Prod / Dev）のコンパートメントを並べる例を図2に示します。規模が大きければ部門などでもう1階層足します。図では cmp-security を省略しています。
表1：推奨コンパートメント構成と各コンパートメントの役割・管理者
| コンパートメント名 | 配置する主なOCIリソース | 権限を持つIAMグループ | 設計の勘所 |
|---|---|---|---|
Root (Tenancy) | 原則として実リソースは置かない （IAMアイデンティティ・ドメイン等のみ） | Tenancy-Admins（特権管理者のみ） | ここにリソースを置くと権限分離ができなくなるため、必ず子コンパートメントを作る。 |
cmp-network | VCN、サブネット、ルート表、Security List / NSG、DRG、FastConnect、LB | Net-Admins | インフラ・NWチームのみが変更可能。アプリ担当には use virtual-network-family（利用のみ）を許可する。 |
cmp-security | OCI Vault（暗号鍵・シークレット）、Logging、Cloud Guard関連 | Sec-Admins | 開発者が本番の暗号鍵やログ設定を変えられないよう独立させる。 |
cmp-app-prod | Autonomous AI DB / Base DB、本番 Compute VM | App-Prod-Ops | 本番運用チームのみに管理権限を付与。開発者には read または inspect のみ付与。 |
cmp-app-dev | 検証用 DB、開発用 VM | App-Devs | instance-family などサービス別に manage を付与し、ポリシー管理は渡さない。Quota（上限）でコスト暴走を防ぐ。 |
3. OCI IAMポリシーの構文（4つの動詞とリソース・ファミリー）
AWSのIAMポリシーはJSON形式で記述しますが、OCIのIAMポリシーは 人間が読んでそのまま意味が通じる英語構文（1行ステートメント） で記述します。最もよく使う基本形は次のとおりです。主語は dynamic-group など、場所は in tenancy にもできます。
Allow group <グループ名> to <動詞(Verb)> <リソース種別(Resource-Type)> in compartment <コンパートメント名> [where <条件>]このうち、4つの動詞（Verb）の強弱関係は実務でも認定資格試験（OCI Architect Associate / Foundations）でも頻出の最重要ポイントです。
表2：OCI IAMポリシーの4つの動詞（Verb）の権限レベル（下に行くほど強い）
| 動詞（Verb） | できること（権限範囲） | 具体例（実務での使いどころ） |
|---|---|---|
1. inspect | リソースの一覧表示・メタデータ確認のみ（中身や設定値は見られない） | 監査担当者やコスト集計ツールに「どんなリソースが何個存在するか」だけを見せる場合。 |
2. read | inspect ＋ リソースの詳細設定やステータスの閲覧（変更・作成は不可） | 開発者に本番コンパートメント（cmp-app-prod）の稼働状況や設定値だけを閲覧させる場合。 |
3. use | read ＋ 既存リソースの利用・更新（新規作成・削除は原則不可。ポリシー、ルート表、セキュリティリストの更新など、manage が必要なものもある） | 最重要：アプリ担当者に、NWチームが作った cmp-network 内のサブネットを使ってVMを起動させる（use virtual-network-family）場合。 |
4. manage | 作成・変更・削除を含むすべての操作（フルコントロール） | 各コンパートメントの責任チーム（NW管理者や開発環境のエンジニア）に付与する場合。 |
4. Dynamic Group（動的グループ）でAPIキーレス認証を実現する
Compute VM上のスクリプトからObject Storageへバックアップを置きたい場合や、OCI Vaultのシークレット（パスワード）を読みたい場合、個人のユーザーAPIキー（秘密鍵ファイル）を発行して設定するのはセキュリティ上のアンチパターンです。
OCIでは Dynamic Group（動的グループ。AWSのIAMロールに近い仕組み） を使います。
- 「特定のコンパートメント（例：
cmp-app-prod）に属するインスタンス」というマッチングルールでDynamic Groupを定義します。 - そのDynamic Groupに対して
Allow dynamic-group dg-app-prod-vm to read secret-bundles in compartment cmp-securityのようにポリシーを付与します。 - これにより、秘密鍵のローテーション管理なしで、VMからOCIサービスを呼び出せます（Instance Principal認証）。
Compute以外のサービスは、対象の種類やルールが異なるため、各サービスの公式手順を確認します。
よくある質問（FAQ）
- OCIのコンパートメントは最大何階層までネスト（入れ子）できますか？
- ルート・コンパートメント直下から最大6階層までネストして作成できます。実務では管理が複雑になりすぎないよう、2〜3階層（例：親＝ネットワーク/共通基盤・部門、子＝本番/検証/開発）に抑えるのがベストプラクティスです。
- 親コンパートメントに付与したIAMポリシーは、子コンパートメントにも引き継がれますか？
- はい、これがOCIの最重要ルールである「ポリシーの継承（Policy Inheritance）」です。上位のコンパートメントに付与された権限は、配下のすべての子コンパートメントに自動的に継承されます。
- 一度作成したリソースを別のコンパートメントへ後から移動することはできますか？
- Computeインスタンス、Block Volume、Autonomous AI Database、VCNなど大半の主要OCIリソースは、再作成することなくコンソールまたはCLIから別コンパートメントへ移動可能です（ただし移動先のIAMポリシーが即座に適用される点に注意が必要です）。