ユーザ管理の全体イメージについて
ご一読ください（2026.4現在）
・この記事は、DocsやOCI上の実操作、SRを実施した経験をもとに、独自にまとめています。時間が経過した場合、クラウド側の仕様変更等で、内容が一致しない可能性もあることをご了承ください。
この記事の対象者
・OCI契約後、ユーザ＆環境管理をこれから始められる方
・OCI Architect 試験に向けた勉強を行う方
この記事を書くきっかけ
自分の検証環境のためにOCIを契約しましたが、最初のユーザ管理周りの理解で苦労したので、これから始められる方にとって、何かの役に立てばと思い、記事にして残しました。
概要
１：使われている言葉について
・Tenancy（テナンシ）：契約直後、クラウド環境を利用するための大きな箱。OCIでは、請求アカウント単位のイメージ。
・コンパートメント：VM等を管理する際に紐づける箱のイメージ。
・ドメイン：ID管理のまとまり。ADサーバーやLDAPサーバーのイメージが近い。
・グループ：ユーザーをまとめるグループ。
・ユーザー：ユーザー。ユーザーが何かしらの権限を得るためには、権限を付与されたグループに属する必要がある。
・ポリシー：特定のグループ/対象に権限を与えるために記載するルール。
・各コンポーネントの関係性についてイメージでお伝えします（下記ご参照ください）。
２：Rootドメインのみに存在するグループ（推測）：契約管理ができる。権限移譲にはSRが必要。
１：使われている言葉について
契約後、ユーザ管理を考えるうえで、最初に知っておきたい言葉（コンポーネント）について記載します。
Tenancy（テナンシ）
OCIでは、請求アカウント単位のイメージが近いようです。
そのため、OCIアカウント＝テナンシ のイメージが近い形になります。
テナンシーの中に、各コンポーネント（後述のコンパートメントなど）が含まれる形になります。
※企業によっては、複数のテナンシーを一括管理するような場面が現れますが、より高度な話になりますので、今回は、単一テナンシーに絞って記載します。
こちらは、ほかのクラウドサービスの場合、例えばAWSでは、アカウントに近いイメージとなります。Azureでは、テナント＋最初のサブスクリプションのイメージが近いかもしれません。
そのため、「OCIでは、テナンシ＝契約者が管理する環境全体」のイメージの方が近いと思います。
イメージ図としては、以下になります。
※契約形態によって順番が前後する場合があります。図は、PAYG（Pay As You Go）の場合です。
ちなみに、AIに契約形態を分かりやすくまとめてもらうと、下記のようになるようです。
コンパートメント
１つのテナンシの中に作成する、箱のイメージになります。
VM等を管理する際に紐づける箱（またはグループ）と捉えれば分かりやすいかもしれません。
※グループと混同しやすいため、ここでは箱と記載します。
OCI上のVMやストレージなどは、必ず、１つのコンパートメントに属するルールがあるため、このルールを利用して、管理者の範囲を定めたり、コスト管理することもできます。
最初は、ルートコンパートメントが払い出され、そこに属する形となります。
また、コンパートメントの中に子供のコンパートメントを作ることもできます。
簡単な例え方をすると、以下のようなイメージでも良さそうです。
テナンシー = 会社まるごと入っている「ビル」
コンパートメント = ビルの中の「部屋」（開発室、本番室、営業部の部屋など）
イメージ図は以下になります。
ドメイン
ドメインは「ユーザーと認証方式をまとめて管理する領域」です。
1つのテナント内に複数のドメインを作り、「社内ユーザー用」「外部委託用」のようにセキュリティポリシーを分けることができます。イメージしやすいのは、ADサーバーやLDAPサーバーのイメージが近いと思います。Windows技術者だと１つのドメインコントローラ、Linux技術者だと１つのLADPサーバでしょうか。
実際の運用では、「このコンパートメント（例：本番環境）で使うユーザーは、このドメインのユーザーだけ」「このコンパートメントにはこのドメインのポリシーを適用」という形で紐づけて考えます。つまり、コンパートメントが「どのリソースをまとめる箱」だとすると、ドメインは「その箱に入れることを許された人・認証ルールのセット」です。
主な利点は、セキュリティを分けやすいことです。
例えば、本番用コンパートメントには厳しいパスワードポリシーのドメインを使い、一部の外部業者には別ドメイン＋限定コンパートメントだけアクセスさせる、などができます。
実運用のイメージだと、管理責任の分離がありそうです。
認証やユーザー管理はドメイン管理者、リソースの作成や運用は各コンパートメントの管理者、と役割を分けて運用できます。
まとめると、
コンパートメント = 「部屋」
ドメイン = 「その部屋に入るための社員証の発行窓口」
になりそうです。
イメージは下図の通りになります。
ユーザー
文字の通り、ユーザーとなりますが、ドメイン内で管理される形になります。
実際に使用するには、何かしらのグループに所属し、そのグループの権限を得る必要があります。
イメージとしては以下になります。
グループ
契約直後には、AdministratorsとAll Domain Usersがあります。
ユーザーは、これらのグループに所属することで、ユーザグループの権限を使用することができます。ドメインごとにユーザグループは設定されており、ユーザグループに紐づけ（アタッチ）されたポリシーによって、権限が決まります。
イメージとしては以下になります。
ポリシー
グループや、VMなどのコンポーネントに、”何を許可するか”を指定することができるルールになります。
OCIの全体ポリシーとして、最初は、必要最小限の許可のみが設定されているため、その他は、全て拒否される環境となります。そのため、”何に対して、何を許可するか”を記載する形をイメージ頂くとよいと思います。
ポリシーの特徴
・ポリシーの継承
親のコンパートメントにアタッチされたポリシーは、子供のコンパートメントに継承されます。
下記がイメージになります。
なので、上記図の場合、compartment_01にポリシーをアタッチすると、compartment_01-01のみに継承される形になります。
２：Rootドメインのみに存在するグループ（推測）
※こちらは推測になります（存在確認が取れた際には、こちらの注釈を削除いたします）
契約時に作成された、最初のAdministratorsユーザーですが、このユーザにのみ存在する権限が、契約管理系の権限になります。そのため、契約管理系のグループがないと、実質、最初のAdministratorsユーザーのみが、契約管理ができることの説明がつきません。。。
この問題に直面するのは、恐らく、OCIの環境自体の管理者を変更する際に、もしくは、契約管理を実施するユーザ自体の変更が必要になった際に遭遇する形になります。
通常はこのユーザグループは表示されていないため、環境全体の管理者（契約管理も含む）の変更が必要になった際には、SRの申請が必要になります。
※最初のAdministratorユーザを削除する際などは、全権限を新管理者へ移譲する必要があり、契約管理系の権限や、その他、細かい権限の移譲が必要になります。必ずSRを申請し、指示に従ってください。
以下、想定しているイメージです。
利用開始する際に、色々疑問がわくと思いますし、
クラウドなどの仕組みは、ドキュメントからは見えてこない部分もあり、いざという時に、あれっ？？？て思ううことが多々あると思います。
何か困ったことがあれば、お気軽にご返信ください。
BEになりますが、なるべく早く返せればと思います。
今後も、少しずつですが、参考になるような記事を投稿したいと思います。
よろしくお願いいたします。