OCI入門 Vol1 テナンシ・コンパートメント・リージョン設計とAlways Free

1. この記事について — AWS実務者のためのOCIアカウント設計入門

1-1. 本記事のゴール

本記事は、「OCI入門シリーズ」の第1弾として、OCIアカウントを構成する基本階層を理解することを目的としています。

本記事を読み終えると、次の状態になることを目指しています。

• OCIアカウントの最上位概念である「テナンシ」と、AWSアカウントとの共通点・相違点を説明できる
• リソースを整理する「コンパートメント」の役割と、最大6階層まで作成できるネスト構造を理解している
• 「リージョン」「アベイラビリティドメイン(AD)」「フォルトドメイン(FD)」という物理階層の関係を、AWSの「リージョン」「アベイラビリティゾーン(AZ)」と対比しながら説明できる
• Always Free枠でどこまでの範囲を無料で試せるかを把握し、実際にコンパートメントを作成して学習を始められる状態になる

本記事はハンズオン手順そのものではなく、その前提となるアカウント構造の全体像を整理する記事です。実際の操作手順は、本シリーズの次巻以降で扱います。

本記事の対象範囲を明確にするため、扱わない内容もあらかじめ整理しておきます。

• OCIコンソールの画面操作やCLIコマンドの具体的な手順(次巻以降で扱います)
• IAMポリシーの文法やIdentity Domainsの詳細設定(次巻のIAM入門で扱います)
• VCN(ネットワーク)やコンピュート・ストレージサービス個々の設定手順(Vol3以降で扱います)

本記事はあくまで、これらのハンズオンの前段階として押さえておくべきアカウント構造の全体像に絞って解説します。

なぜ今OCIのアカウント設計を学ぶのか

クラウド戦略の選択肢としてマルチクラウドを検討する組織が増えており、AWSに続く基盤としてOCIが候補に挙がる場面も出てきています。OCIを検討する際、最初につまずきやすいのがアカウントそのものの構造です。

テナンシとコンパートメントの関係を理解しないままリソースを作り始めると、後になってコンパートメント階層を作り直す手間が発生しかねません。特にコンパートメントの最上位階層やホームリージョンは、後から変更する際の影響範囲が大きい設定です。実際に手を動かす前に、今のうちにアカウント設計の基礎を押さえておくことには意味があります。

OCIを採用する組織が増えれば、AWS実務者がOCI案件に携わる機会も今後増えていくと考えられます。そのとき慌てて用語を覚え直すのではなく、早いうちから「AWSの何に相当するか」という地図を持っておくことで、いざという場面でもスムーズに対応できます。

本記事で登場する主な用語を、先取りして一言で整理すると次のとおりです。詳しい説明は§2以降で行います。

この対応関係はあくまで概略です。それぞれの用語がAWSのどの概念に近く、どこが異なるのかという詳しい対比は§2で表としてまとめて整理します。

用語の一覧を眺めるだけでは実感が湧きにくいと思いますので、次節以降ではこれらの用語がなぜそのように設計されているのかという背景も含めて、順を追って説明していきます。

1-2. 読者像 — AWSは分かるがOCIは初めて

本記事は、AWSでのアカウント設計やIAM運用、マルチアカウント管理の実務経験をお持ちの方で、OCIには初めて触れる方を主な読者として想定しています。

OCIのドキュメントを読み始めると、「テナンシ」「コンパートメント」「フォルトドメイン」といった聞き慣れない用語が次々と登場します。AWSの知識があるからこそ、かえって「これはAWSの何に相当するのか」が気になり、対応関係が分からないまま読み進めるのに疲れてしまうことも少なくありません。

AWS実務者がOCIに触れた際、よく戸惑うポイントとして次のようなものが挙げられます。

• テナンシとコンパートメントという2つの階層概念が、それぞれAWSアカウントとOUのどちらに近いのか整理がつかない
• コンパートメントが最大6階層までネストできると聞いても、AWSのOU設計とどう使い分ければよいか分からない
• 「アベイラビリティドメイン」と「フォルトドメイン」という似た響きの用語が何を指すのか区別できない
• リージョンによってアベイラビリティドメインの数が異なることを知らず、AWSと同じ感覚で可用性設計を進めてしまう

本記事では、皆さんが既にお持ちのAWSアカウント設計の知識を出発点として、OCIの概念を一つずつ対応づけながら解説を進めます。ゼロから用語を暗記するのではなく、「AWSでいうところの何か」という橋渡しを通じて、短時間でOCIアカウントの全体像を掴んでいただくことを狙いとしています。

なお、AWSの経験がない方でも、対比元となるAWSの概念については都度簡単に補足しますので、本記事単体でも読み進めていただけます。

対比を軸に学ぶメリットは、単に用語を覚える手間を減らせることだけではありません。「AWSではこう設計していたから、OCIでも同様の考え方が使えるはずだ」という仮説を持って読み進められるため、細部の違いに気づいたときの理解の定着も早くなります。逆に対応関係を意識せずに新しい用語を丸暗記しようとすると、テナンシとコンパートメントの違いのように紛らわしい概念でつまずきやすくなります。

1-3. OCIとは — Oracle Cloud Infrastructure の位置づけ

OCI(Oracle Cloud Infrastructure)は、Oracleが提供するパブリッククラウドサービスです。仮想マシンやベアメタルサーバー、コンテナ実行基盤、各種データベースサービス、ストレージ、ネットワークといった基盤サービス群を備えており、AWSやAzure、Google Cloudと同様にIaaS・PaaS領域を幅広くカバーしています。

OCIの主な特徴として、次のような点が挙げられます。

• Oracle Databaseをはじめとするデータベース製品との親和性が高いこと
• コンピュート・ネットワーク・ストレージを組み合わせた基盤サービスを、世界各地のリージョンで提供していること
• オンプレミス環境と接続するハイブリッドクラウド構成にも対応していること
• 従量課金を基本としつつ、契約に応じた割引が適用される課金モデルを採用していること

本記事が扱うテナンシやコンパートメントといったアカウント管理の仕組み自体は、特定のワークロードに限らずOCI全般を支える基盤として設計されています。本シリーズでは、特定のワークロードに限定せず、まずはアカウントの土台となる構造を理解することを優先します。

Oracleは、OCIを既存の主要クラウドサービスの経験を踏まえて設計し直した基盤と位置づけて訴求しています。この経緯もあり、テナンシやコンパートメントといったアカウント管理の考え方は、AWSやAzureと共通する部分を持ちながらも、細部の設計思想において異なる箇所が随所に見られます。次章以降では、この共通点と相違点を意識しながら、具体的な階層構造を見ていきます。

OCIの性能面やサービスの詳細な優劣比較には本記事では立ち入りません。まずは「AWSアカウントに相当するものがOCIにどう存在するか」という構造理解に絞って解説します。

1-4. 本シリーズの構成 — OCI入門シリーズの読み方

本記事は「OCI入門シリーズ」の第1弾として、OCIアカウントの土台となるテナンシ・コンパートメント・リージョン設計とAlways Free枠を扱います。本シリーズは今後、次のようなテーマへ発展させていく学習ロードマップを予定しています。

本記事で扱うコンパートメント設計とリージョン構造の理解は、次巻以降で扱うIAMポリシーのスコープ設計やネットワーク設計を理解するための前提知識となります。まずは本記事でアカウントの骨格をしっかりと押さえておくことをお勧めします。

なお、本記事ではOCIコンソールの具体的な操作手順やCLIコマンドの詳細には立ち入りません。次巻以降のハンズオンでは、コンパートメントの指定やホームリージョンの確認といった場面が繰り返し登場します。本記事で押さえるアカウント構造の考え方が、その土台になります。

→ 次巻: OCI IAM入門(Identity Domains・ポリシー・ダイナミックグループ)

2. OCIアカウント構造の全体像 — テナンシを頂点とする階層

図1では、テナンシを頂点として左側に論理階層(コンパートメントのツリー構造)、右側に物理階層(リージョン・AD・FDの配置)を並べ、両者が独立した軸であることを示しています。あわせて、それぞれの階層に対応するAWSの概念(AWSアカウント・OU・リージョン・AZ)を隣接して配置し、対応関係を一目で確認できるようにしています。以降の節では、この図が示す内容を1つずつ言葉で説明していきます。

図の左右を見比べながら読み進めることで、「今どちらの階層の話をしているのか」を見失わずに理解を進められます。

2-1. OCIの2つの階層 — 論理階層と物理階層

OCIのアカウント構造を理解する鍵は、「論理的な組織化階層」と「物理的な配置階層」という2つの軸を分けて捉えることです。

論理階層は、テナンシを頂点として、その配下にコンパートメントを何層にもネストさせて作る階層です。リソースをどのチーム・環境・プロジェクトに属させるか、IAMポリシーをどの範囲に適用するかを決める、いわば組織図に相当する階層です。

物理階層は、テナンシの下にリージョン、さらにリージョンの下にアベイラビリティドメイン(AD)、ADの下にフォルトドメイン(FD)という順で構成される、リソースが実際にどの地理的・物理的な場所に配置されるかを表す階層です。可用性設計や災害対策を検討するうえで基準となります。

AWSに慣れている方であれば、論理階層は「AWSアカウント配下のOU(組織単位)構造」、物理階層は「リージョン・アベイラビリティゾーン(AZ)の関係」にそれぞれ相当すると捉えれば理解しやすくなります。ただし対応は完全な1対1ではなく、次節で触れるとおりOCIには「フォルトドメイン」というAWSに明示的な対応物のない階層が存在する点は大きな違いです。

この2つの階層は独立した軸であり、あるリソースは「どのコンパートメントに属するか(論理的な所属)」と「どのリージョン・ADに配置されるか(物理的な配置)」を、それぞれ別に指定します。この分離を意識することが、以降の章を読み進めるうえでの前提になります。

この2軸を分離しておくことには実務上のメリットがあります。組織構造やプロジェクト体制が変わってコンパートメントの整理をやり直したい場合でも、リソースがどのリージョン・ADに配置されているかという物理的な位置には影響しません。逆に、災害対策のために新しいリージョンへリソースを展開する場合でも、コンパートメントによる権限設計をゼロから作り直す必要はありません。論理と物理を独立した軸として設計しておくことで、どちらか一方の変更がもう一方に波及しにくくなります。

物理階層をさらに正確に表すと、テナンシの下に「リアルム(Realm)」という区分が存在し、リアルムの下に複数のリージョンが属するという構成になっています。リアルムは、商用ワークロード向けや政府機関向けなど、利用目的に応じて分離されたリージョン群のグルーピングです。一般的な商用テナンシは商用リアルムに属し、そのリアルム配下にある複数のリージョンを選んで利用します。本記事で扱う東京リージョンや大阪リージョンも、この商用リアルムに属するリージョンです。

まとめると、物理階層はテナンシ→リアルム→リージョン→アベイラビリティドメイン(AD)→フォルトドメイン(FD)という順で構成されています。日常の運用でリアルムを意識する場面は多くありませんが、「テナンシは特定のリアルムに属し、そのリアルム内のリージョンにしかアクセスできない」という前提は、マルチリージョン展開を検討する際に押さえておく価値があります。

論理階層のイメージをつかむために、あるSaaS企業がOCIを使い始める場面を例に考えてみます。この企業では、開発環境と本番環境を分離し、さらに開発環境の中でもフロントエンドチームとバックエンドチームでリソースを分けたいと考えているとします。この場合、論理階層は次のようなツリー構造になります。

• テナンシ(ルートコンパートメント)
• コンパートメント「開発」
  • コンパートメント「開発 / フロントエンド」
  • コンパートメント「開発 / バックエンド」
• コンパートメント「本番」

この例からも分かるとおり、コンパートメントの階層はあくまで組織やチームの都合に合わせて自由に設計する論理的な構造であり、リージョンやADといった物理的な配置とは無関係に決められます。実際にコンパートメントをどう設計するかという具体的な指針は、本記事の§4および§7で扱います。

2-2. AWSとOCIの概念対応マップ

ここまでの説明を踏まえ、AWSとOCIの主要な概念を対応表として整理します。

この表はあくまで「近い概念」を対応づけたものであり、厳密な1対1対応ではありません。特に注意すべき点を以下に補足します。

コンパートメントとOUの違い

AWSのOUはAWS Organizations配下で複数アカウントをグループ化する仕組みですが、OCIのコンパートメントは単一テナンシ内でリソースを論理的に区切る仕組みです。「複数アカウントを束ねる」OUと「1つのテナンシ内を区切る」コンパートメントでは、対象とする範囲がそもそも異なります。

AWSでは環境やチームを分離する際にアカウントそのものを分ける戦略(マルチアカウント戦略)を取ることが多くありますが、OCIでは単一のテナンシの中でコンパートメントを使って同様の分離を実現します。「アカウントを分けるか、コンパートメントで区切るか」という判断軸の違いは、初めてOCIに触れると混乱しやすいポイントです。

フォルトドメインはOCI固有の階層

AWSのAZに相当する概念はOCIのADですが、OCIはAD内にさらにフォルトドメインという物理的なハードウェア隔離グループを持ちます。AWSにはこれに明示的に対応する階層はありません。フォルトドメインの詳細は本記事の§5で解説します。

AWSでもパーティションプレイスメントグループなど、近い目的を持つ機能自体は存在しますが、OCIのフォルトドメインのように「すべてのADに標準で3つ存在する」という明示的な階層としては提供されていません。この違いは、単一ADしか持たないリージョンでの可用性設計を考える際に特に重要です。

IAMの対応

OCIのIAMは、Identity Domainsという仕組みを介して提供されます。ポリシーの記述方法やスコープの考え方はAWS IAMと異なる点が多く、この違いは次巻のIAM入門で詳しく扱います。

一点だけ本記事で触れておくと、OCIのIAMポリシーはテナンシ全体、または特定のコンパートメント単位でスコープを指定します。つまり、コンパートメントの階層設計がそのままIAMポリシーの適用範囲の設計に直結します。この点は本記事の§4-4および§7-2でもう一度取り上げます。

複数アカウント・複数テナンシの管理

AWS OrganizationsはAWSアカウントそのものを複数束ねて一元管理する仕組みですが、OCIでは通常、1つの組織に対して1つのテナンシを持つ運用が基本になります。複数テナンシを組み合わせた高度な運用パターンは、本シリーズでは扱いません。

物理階層についても、同様に対応表として整理しておきます。

AWSのパーティションは普段の運用ではほとんど意識することがありませんが、OCIのリアルムも同様に、商用テナンシを利用している限りは意識する場面の少ない区分です。両者とも「利用目的によってアクセスできるリージョン群が分かれている」という点で近い役割を持っています。

いずれの場合も、通常の商用ワークロードで意識すべきは、その内側にある「リージョン」「AD」「FD」の3階層です。次節ではこの3階層とコンパートメントの関係を、実際のリソース配置の視点から見ていきます。

2-3. テナンシ・コンパートメント・リージョンの関係

テナンシ、コンパートメント、リージョンという3つの概念は、それぞれ異なる役割を持ちながら1つのアカウント構造を形作っています。

テナンシは、OCIサインアップ時に割り当てられる、組織ごとに1つだけ存在するルートの隔離空間です。テナンシ自体が「ルートコンパートメント」を兼ねており、その配下に複数階層のコンパートメントをツリー状に作成していきます。コンパートメントはあくまで論理的な区分であり、特定のリージョンに紐づくものではありません。

一方、実際に作成する仮想マシンやデータベースといったリソースは、必ず特定のリージョンに、さらにそのリージョン内の特定のアベイラビリティドメインに配置されます。つまり、「このリソースはどのコンパートメントに属するか(論理的な所属)」と「このリソースはどのリージョン・ADに存在するか(物理的な配置)」は、それぞれ独立して指定する必要があります。

例えば、「開発チームのコンパートメント」に属するリソースは、東京リージョンへ置くことも大阪リージョンへ置くこともでき、同じコンパートメントのまま複数リージョンへリソースを分散配置できます。図1で示したとおり、コンパートメントという論理的な区切りと、リージョン・AD・FDという物理的な配置は、縦横の異なる軸として重なり合う関係にあります。

この関係は、OCIコンソールの操作にもそのまま表れます。コンソール画面左上のリージョンセレクターで対象リージョンを切り替え、リソース一覧・作成画面ではコンパートメントセレクターで対象コンパートメントを切り替えるという、2つの独立した操作でリソースの表示・作成範囲を絞り込みます。AWSマネジメントコンソールでリージョンを切り替える操作に近い感覚である一方、OCIではさらにコンパートメントという軸が加わる点で異なります。

このため、「あるリソースが見当たらない」というときは、コンパートメントの指定が誤っているのか、リージョンの指定が誤っているのか、あるいはその両方かを切り分けて確認する必要があります。次章以降でテナンシ・コンパートメント・リージョンそれぞれを個別に深掘りする中で、この切り分けの感覚を掴んでいただければと思います。

コンソールに限らず、OCI CLIやAPIでリソースを操作する場合も同じく、コンパートメントを指定するパラメータとリージョンを指定するパラメータはそれぞれ別に渡す設計です。GUIかCLI/APIか、どちらを使っても「論理的な所属」・「物理的な配置」を独立して指定するという考え方は一貫しています。

論理軸(コンパートメント)と物理軸(リージョン)が独立していることを、先ほどのSaaS企業の例を使って表にすると次のようになります。

このように、同じコンパートメントに属するリソースであっても、リージョンをまたいで自由に配置できます。逆に、同じリージョンの中に複数のコンパートメントのリソースが混在することも珍しくありません。

ここまで見てきた各階層について、後からどこまで変更できるかを整理すると次のようになります。設計を始める前に、どの設定が「やり直しがきくか」「やり直しがきかないか」を把握しておくと、初期設計で慎重になるべき箇所の見極めがしやすくなります。

テナンシとホームリージョンは「最初の一回で決まる」設定である一方、コンパートメントは比較的柔軟に見直せる設定であるという対比も、あわせて押さえておくとよいでしょう。この違いを知っておくだけでも、設計初期にどこへ時間をかけて検討すべきかの優先順位が見えてきます。

なお、コンパートメントと似た用途で使われる仕組みに「タグ」があります。コンパートメントがリソースの所属先を決める階層構造であるのに対し、タグはリソースに任意のラベルを付与する仕組みで、複数のタグを横断的に付けられる点が異なります。コンパートメント設計だけでは表現しきれない分類(例えばコスト配分の担当者や、プロジェクトの契約期間など)を補うために、タグを併用するのが一般的です。タグの具体的な運用方法は§7-3で扱います。

参考として、OCI上の個々のリソースには「OCID(Oracle Cloud Identifier)」という一意の識別子が割り当てられます。OCIDにはリソースの種類やテナンシの情報が含まれており、AWSのARN(Amazon Resource Name)に近い役割を持ちます。OCIDそのものにはコンパートメントやリージョンの情報が直接埋め込まれているわけではありませんが、リソースを一意に特定するという目的はARNと共通しています。OCIDの具体的な構造は、実際の操作を扱う次巻以降で必要に応じて触れます。

2-4. よくある誤解 — AWS実務者が陥りやすいポイント

ここまでの内容を踏まえ、AWS実務者がOCIの階層構造を学ぶ際によく抱く誤解を5つ取り上げます。

誤解1: コンパートメントを分ければ請求(課金)も自動的に分離される

コンパートメントは論理的なリソース整理の仕組みであり、それ自体が請求書を分ける単位ではありません。課金の実体はテナンシ単位で発生します。コンパートメントごとの利用状況を把握したい場合は、コスト分析画面でコンパートメント単位のフィルタや、タグを使って内訳を確認します。具体的な予算アラートの設定方法は§7-3で扱います。

誤解2: コンパートメントはAWSアカウントと同様、完全に独立した環境である

AWSでマルチアカウント戦略を取る場合、アカウント単位でネットワークやIAMの境界が明確に分離されます。一方、OCIのコンパートメントはあくまで同一テナンシ内の論理的な区分であり、ネットワーク(VCN)はコンパートメントをまたいで参照できるなど、AWSアカウントほど厳密な独立性はありません。この違いはネットワーキングを扱う本シリーズの後続の巻で詳しく解説します。

誤解3: リージョンを選べば、その中のアベイラビリティドメイン数もAWSと同程度だろう

AWSでは多くのリージョンが3つ以上のAZを持ちますが、OCIではリージョンによってAD数が異なり、東京リージョンのようにAD数が1つのリージョンも存在します。可用性設計を進める前に、対象リージョンのAD数を必ず確認する必要があります。この点は§5で詳しく扱います。

誤解4: テナンシを作成した時点で、いくつかのコンパートメントがあらかじめ用意されている

OCIでサインアップした直後の時点では、ルートコンパートメント(テナンシ自体)のみが存在し、それ以外のコンパートメントは自動的には作成されません。環境別・チーム別のコンパートメントは、利用者が設計方針を決めたうえで、自ら作成する必要があります。AWSでもアカウント作成直後からOUがあらかじめ用意されているわけではありません。この点はOCIと共通しています。ただしOCIでは、リソースをどこにも所属させずに作成すると自動的にルートコンパートメントに置かれてしまうため、意識的にコンパートメントを設計・作成する姿勢がより重要になります。

誤解5: どのリージョンを選んでも、OCIの全サービスを同じように使える

新しいOCIサービスや機能は、まず一部の主要リージョンから提供が始まり、その後順次他のリージョンへ展開されるのが一般的です。東京リージョンを含むすべてのリージョンで、常に全サービス・全機能が同時に利用できるとは限りません。使いたいサービスが対象リージョンで提供されているかどうかは、公式のリージョンごとの提供状況ページで確認することをお勧めします。この考え方は、AWSで新サービスがまず一部のリージョンから展開されるのと同様です。

これら5つの誤解に共通するのは、「AWSでの経験則をそのままOCIに当てはめてしまう」という点です。対応関係を理解することは学習の近道になりますが、細部まで完全に同じだと思い込んでしまうと、かえって思わぬ落とし穴にはまります。次章以降でテナンシ・コンパートメント・リージョン・AD・FDをそれぞれ個別に見ていく際は、この「似ているが同じではない」という前提を意識しながら読み進めてください。

2-5. 本章以降の道筋

ここまでで、OCIアカウント構造の全体像として、論理階層(テナンシ・コンパートメント)と物理階層(リージョン・AD・FD)という2つの軸があることを確認しました。

以降の章では、この全体像を構成する各要素を順番に掘り下げていきます。

§3 テナンシ

テナンシがサインアップ時にどのように割り当てられるか、そしてテナンシが同時に「ルートコンパートメント」を兼ねているという二重の役割を詳しく見ていきます。あわせて、後から変更できない「ホームリージョン」の考え方も扱います。

§4 コンパートメント

コンパートメントが最大6階層までネストできる仕組みと、IAMポリシーのスコープとして機能する仕組みを解説します。環境別・チーム別といった設計パターンについても、AWSのOU設計との対比を交えて整理します。

§5 リージョン・AD・FD

東京リージョン(ap-tokyo-1)を具体例として、リージョン・アベイラビリティドメイン(AD)・フォルトドメイン(FD)という物理配置の仕組みを詳しく見ていきます。AD数がリージョンによって異なる点や、その違いが可用性設計にどう影響するかも扱います。

§6 Always Free枠

期限なしで使える無料リソースの範囲を、コンピュート・ストレージ・ネットワーク・データベースといったカテゴリ別に整理します。実際にコンパートメントを作成し、学習を始めるための最初のステップも案内します。

§7・§8 実践とまとめ

§3から§6までで個々の要素を掘り下げたあと、§7ではコンパートメント設計・日常運用ユーザー・コスト管理を含めた初期セットアップのベストプラクティスを扱います。最後の§8では、本記事全体を振り返り、次巻のIAM入門へ橋渡しします。

それぞれの章を読み進めることで、本章で示した全体像の解像度を一段階ずつ上げていくことができます。特に§2で整理した「論理階層(テナンシ・コンパートメント)」と「物理階層(リージョン・AD・FD)」という2軸の分離は、以降のすべての章で繰り返し前提として使う考え方ですので、次章へ進む前にもう一度図1を見返しておくことをお勧めします。

本記事を最後まで読み終える頃には、OCIの公式ドキュメントに登場する用語を見ても、それがアカウント構造のどの階層の話をしているのかを迷わず判断できるようになっているはずです。

それでは、まずテナンシから見ていきましょう。

3. テナンシ — OCIアカウントのルート隔離パーティション

3-1. テナンシとは — サインアップで割り当てられる隔離空間

Oracle Cloud Infrastructure(OCI)にサインアップすると、Oracleは利用者ごとに「テナンシ(Tenancy)」と呼ばれる、セキュアかつ隔離されたパーティションを割り当てます。テナンシは、コンピュートインスタンスやネットワーク、ストレージ、データベースなど、OCI上のあらゆるクラウドリソースを作成・組織化・管理するためのルートコンテナです。

AWSに置き換えると、テナンシはAWSアカウントに相当する概念といえます。ただし、テナンシ自体が後述の「ルートコンパートメント」を兼ねており、リソース組織化の起点そのものになっている点が、AWSアカウントとの明確な違いです。企業やチームで利用する場合、テナンシは組織そのものと同一視されることが多く、1つのテナンシの中に複数のプロジェクトやチームのリソースをコンパートメントで分けて配置していく設計が基本になります。

3-2. ホームリージョンと登録リージョン

テナンシには「ホームリージョン」と呼ばれる特別なリージョンが1つ存在します。ホームリージョンは、ユーザー・グループ・ポリシー・コンパートメントといったIAMリソースのマスター定義が置かれるリージョンです。

テナンシ作成後、必要に応じて追加のリージョンを「登録リージョン」としてサブスクライブすることで、複数リージョンでリソースを展開できるようになります。登録リージョンにもIAMリソースの情報は反映されますが、実際に変更できるのはあくまでホームリージョン側のマスター定義のみです。

なお、ホームリージョンはテナンシ作成後に変更できません。AWSでは利用リージョンを都度自由に選べますが、OCIではテナンシ作成時にホームリージョンの選定を慎重に行う必要があります。将来的に東京リージョン(Japan East (Tokyo)、リージョン識別子ap-tokyo-1)を中心に利用する計画がある場合は、サインアップ時点でホームリージョンとして東京を選択しておくことが推奨されます。

3-3. ルートコンパートメントとテナンシの関係

テナンシは、それ自体が「ルートコンパートメント」としての役割も兼ねています。OCIでコンパートメントを新規作成する際は、必ずこのルートコンパートメント(テナンシ)の直下、もしくはその子孫コンパートメントの下に作成します。

言い換えると、テナンシはOCIリソース階層の頂点であると同時に、コンパートメント階層の起点でもあるという二重の役割を持ちます。次節で扱うコンパートメントの階層構造は、常にこのルートコンパートメント(テナンシ)を根として展開されます。

3-4. テナンシ管理のベストプラクティス(概要)

小規模な検証(PoC)段階では、ルートコンパートメントに直接リソースを置いて始めても問題はありません。ただし公式ドキュメントでは、その場合でも動作確認用の「サンドボックスコンパートメント」を1つ用意し、機能検証用のリソースをそこに隔離しておくことを推奨しています。

また、ユーザーやグループといったIAMリソースは常にテナンシ(ルート)レベルで作成する仕様になっており、コンパートメント単位では作成できません。運用が本格化する段階では、ルート直下に本番リソースを置かず、プロジェクトや環境ごとにコンパートメントを分けて管理する設計へ早めに移行することが望ましいといえます。具体的な設計パターンは次章で解説します。

4. コンパートメント — リソース組織化と最大6階層設計

4-1. コンパートメントとは — 論理的なリソース隔離境界

コンパートメントは、テナンシ内のリソースを論理的に区切って組織化するための境界です。物理的なリソースの配置場所(リージョンやアベイラビリティドメイン)とは独立した概念で、環境(開発/ステージング/本番)、チーム、プロジェクト、ワークロードといった単位でリソースを分類できます。

AWSでいうOU(組織単位)やリソースグループに近い発想ですが、OCIのコンパートメントは同時にIAMポリシーのスコープ単位でもあります。つまり「どのコンパートメントに、誰が、何の権限を持つか」を定義することが、そのままアクセス制御の基本設計になります。

4-2. 最大6階層のネスト構造

コンパートメントは、その配下にサブコンパートメントを作成することで階層化できます。公式ドキュメントによれば、このネスト可能な階層はルートコンパートメントを含めて最大6階層までと定められており、1テナンシあたり作成できるコンパートメント数の上限は6,000です。

また、コンパートメントはテナンシ全体で有効な概念であり、作成したコンパートメントはテナンシがサブスクライブしているすべてのリージョンで利用できます。親コンパートメントの管理者は、その配下にあるすべての子コンパートメントに対しても管理権限を持つ点も覚えておく必要があります。

4-3. コンパートメント設計パターン — 環境別・チーム別

公式ドキュメントでは、組織規模に応じて主に次の3パターンのコンパートメント設計が紹介されています。

AWSのOU設計と同様、階層を必要以上に深くしすぎると管理が煩雑になります。最大6階層まで作成可能とはいえ、実務では2〜3階層程度(例: 環境別→チーム別)に留めるケースが多く、まずはシンプルな構成から始め、必要に応じて拡張していくアプローチが現実的です。

4-4. コンパートメントとIAMポリシーのスコープ

OCIのIAMポリシーは、テナンシ全体、または特定のコンパートメントのいずれかにスコープを指定して定義します。一方で、ユーザー・グループ・コンパートメント自体・テナンシに直接アタッチされたポリシーといった一部のIAMリソースは、テナンシ(ルートコンパートメント)にのみ存在し、個別のコンパートメント内では作成・管理できません。

このため、コンパートメントの設計はそのままIAMの権限設計と直結します。「どの単位でコンパートメントを切るか」を決めることは、実質的に「どの単位で権限を分離するか」を決めることと同義です。より詳細なIAMポリシーの書き方やダイナミックグループについては、次巻のIAM入門編で扱います。

5. リージョン・AD・FD — 物理配置と可用性設計

5-1. リージョン — 地理的なデータセンター群(東京 ap-tokyo-1)

OCIにおける「リージョン」は、独立したデータセンター群が存在する地理的な区画です。物理階層はテナンシの下に、リアルム、リージョン、アベイラビリティドメイン(AD)、フォルトドメイン(FD)という順で構成されており、テナンシは自身が所属するリアルム内の全リージョンにアクセスできます。

日本国内では、東京リージョンが「Japan East (Tokyo)」という名称でOCI公式に登録されており、リージョン識別子はap-tokyo-1です。本リージョンはすでに一般提供(GA)されており、日本国内の実務でも本番ワークロードのホストリージョンとして利用可能です。

AWSでも「リージョン」は地理的な区画という点でほぼ同じ概念ですが、OCIは物理階層に「リアルム」という上位区分を持つ点が異なります。リアルムは商用・政府専用など利用目的で分離されたリージョン群のグルーピングであり、通常の商用テナンシはOC1リアルムに属します。

5-2. アベイラビリティドメイン(AD) — 独立したデータセンター

アベイラビリティドメイン(AD)は、独立した電源・冷却設備・内部ネットワークを備えた、物理的に隔離されたデータセンターです。同一リージョン内の他のADとは相互に障害の影響を受けないよう設計されており、AWSのアベイラビリティゾーン(AZ)に相当する概念といえます。

ただし、AWSのAZ数がリージョンごとに異なるのと同様、OCIのAD数もリージョンによって異なります。例えば米国のUS East (Ashburn)リージョンは3つのADを持ちますが、2026年7月時点でOCI公式ドキュメントを確認したところ、東京リージョン(ap-tokyo-1)はAD数1の「シングルAD構成」のリージョンです(大阪リージョンap-osaka-1も同様にAD数1です)。

これはAWS東京リージョン(ap-northeast-1)が3つのAZを持つ点と対照的であり、東京リージョンでOCIを利用する場合は、AD単位の冗長化という選択肢が実質的に存在しない点を最初に押さえておく必要があります。この制約は次の5-4で解説する可用性設計に直結します。

5-3. フォルトドメイン(FD) — AD内のハードウェア隔離グループ

フォルトドメイン(FD)は、AD内部をさらに細分化したハードウェア隔離グループです。OCI公式ドキュメントでは、いずれのADも例外なく3つのFDを持つと定義されており、東京リージョンのようにAD数が1つのリージョンであっても、そのAD内には必ず3つのFDが存在します。

同一AD内で複数のコンピュートインスタンスを異なるFDに配置すると、OCIが自動的にアンチアフィニティ配置し、物理的に異なるハードウェア(電源・ネットワークスイッチなど)上にインスタンスを分散します。これにより、特定のラックやハードウェアの障害が全インスタンスに波及するリスクを下げられます。

AWSにはFDに相当する明示的な階層は用意されておらず、AZ内でのハードウェア分散は主にAWS側の内部制御に委ねられています。この「AD内を自分でFD分散できる」という点は、OCI特有の設計要素です。

5-4. 可用性設計 — AD/FDを使った高可用構成

複数のADと複数のFDを組み合わせることで、高可用性(HA)や災害復旧(DR)を実現できます。ADが複数あるリージョンでは、AWSのMulti-AZ構成と同様に、異なるAD間でリソースを分散配置することで、データセンター単位の障害からワークロードを保護できます。

一方で、東京リージョンのようにAD数が1つのリージョンでは、AD単位の冗長化は選択できません。この場合に取り得る現実的な選択肢は、(1) 単一AD内で複数のFDに分散配置してハードウェア障害への耐性を高める、(2) 大阪リージョンなど別リージョンとの間でマルチリージョン構成を組み、リージョン単位の災害復旧に備える、の2通りです。

東京リージョンで本番ワークロードを設計する際は、単一AD構成であることを前提に、FD分散とマルチリージョンDRの両方を初期設計段階で検討しておくことが重要です。この点はAWS東京リージョン(AZ3つ)からの移行者にとって特に見落としやすい差異といえます。

6. Always Free枠 — 無料で始めるOCI

6-1. Always Free枠とは — 期限なしで使える無料リソース

OCIには2種類の無料枠があります。ひとつは新規サインアップ時にクレジットが付与される「30日間の無料トライアル」、もうひとつは期限の定めなく使い続けられる「Always Free」です。Always Freeで提供されるリソースは、トライアル期間が終了した後もそのまま無料で利用を継続できます。

AWSの無料利用枠と比較すると、AWSは新規アカウント向けの「12か月間無料」の枠と、期間の制限がない「Always Free」(Lambdaの月100万リクエストやDynamoDBの一定容量など)の2階層に分かれています。OCIの場合は、次節以降で紹介するコンピュート・ストレージ・データベースといった主要サービスの大部分が、最初からAlways Free対象として用意されている点が特徴です。学習用途で継続的に手を動かし続けたい場合、比較的手厚い無料枠設計といえます。

6-2. コンピュート無料枠 — Ampere A1 と AMD Micro

2026年7月時点でOCI公式のAlways Freeページを確認したところ、Arm系のOCI Ampere A1コンピュートは、月間1,500 OCPU時間および9,000 GB時間分が無料枠として提供されています。常時起動し続ける前提で換算すると、おおよそ2 OCPU・メモリ12GB相当のインスタンスを1か月動かし続けられる計算になります。なお、過去には「4 OCPU・24GBまで無料」という案内がされていた時期がありましたが、現在は時間単位のクレジットを消費する制度に変わっているため、実際に確保できる構成は起動時間の配分によって変動します。

AMD系では、VM.Standard.E2.1.Microシェイプ(1/8 OCPU・メモリ1GB)のインスタンスを最大2台まで無料で起動できます。学習用の軽量な検証環境であれば、Ampere A1とAMD Microを併用して複数台構成を試すことも可能です。

6-3. ストレージ無料枠 — ブロックとオブジェクト

ブロックボリュームは、ブートボリュームとブロックボリュームを合算して合計200GBまで、ボリュームバックアップは5世代まで無料です。

オブジェクトストレージについては、公式ドキュメント上、無料トライアルのクレジットを使い切りAlways Freeのみが有効になっているテナンシの場合、Standard・Infrequent Access・Archiveの3階層合算で20GB、APIリクエストは月間50,000回までが無料枠となります。トライアルのクレジットがまだ残っているテナンシでは各階層10GBずつ(合計30GB)という異なる基準が適用されるため、自分のテナンシがどちらの状態かをコンソール上の請求情報で確認しておくとよいでしょう。

6-4. ネットワーク・データベース無料枠

仮想クラウドネットワーク(VCN)は、無料枠内で最大2つ作成可能です。Autonomous Databaseは、1 OCPU・ストレージ20GB(同時セッション数上限20)のインスタンスを最大2つまで無料枠として利用可能です。

コンピュート・ストレージに加えてネットワークとデータベースもひととおり無料枠内に収まっているため、小規模なアプリケーション環境を一通り組み立てて学習するには十分な内容です。無料枠の範囲で、Webサーバーとデータベースを組み合わせた簡易な構成を試すこともできます。

6-5. Always Free枠で始める学習ステップ

実際に手を動かす際は、次の順序で進めるとつまずきにくくなります。まずOCIアカウントにサインアップし、ホームリージョンを選択します。§3-2で触れた通りホームリージョンは後から変更できないため、東京や大阪など実際に利用したいリージョンを最初に選ぶことが重要です。次に、§4で解説したコンパートメントを用途別に作成し、リソースを整理する土台を整えます。その上でAmpere A1やAMD Microのコンピュートインスタンスを無料枠内で起動し、実機での操作に慣れていきます。

無料枠の詳細な数値は今後も変更される可能性があります。実際に構築する際は本記事の数値を参考にしつつ、最終的な判断は必ずOCI公式のAlways Freeページで最新情報をご確認ください。本シリーズの次巻以降では、これらのAlways Free枠を使ったハンズオン手順を扱っていきます。

7. 実践 — アカウント初期設計のベストプラクティス

7-1. コンパートメント設計 — 最初に決めるべき階層

OCIアカウントを開設したら、最初に着手すべきなのがコンパートメント設計です。§4で解説した通り、コンパートメントは最大6階層までネスト可能な柔軟な構造を持ちますが、自由度が高いからこそ、設計の指針を定めずに進めると後から整理し直すコストが大きくなります。

まず避けたいのが、ルートコンパートメント(テナンシ自体)の直下に本番のリソースを直接作成してしまうことです。§3で触れた通り、ルートコンパートメントはテナンシ全体を管理する最上位の権限スコープであり、ここに個別のワークロードのリソースを混在させると、IAMポリシーのスコープ設計が複雑になります。

設計の第一階層は、多くの組織で「環境」または「事業部門・チーム」のいずれかを基準に分割されます。

• 環境ベース: dev / staging / prod のように環境ごとに最上位のコンパートメントを分け、その配下でワークロード単位にさらに分割する
• 組織ベース: 事業部門やチームを最上位に置き、その配下で環境を分割する

AWSでマルチアカウント戦略のOU(組織単位)をどう設計するかに近い判断ですが、OCIではAWSのようにアカウントそのものを物理的に分離するのではなく、単一テナンシ内でコンパートメントという論理的な境界を使う点が異なります。どちらを最上位に据えるかは組織構造やガバナンス要件によって変わるため一概に正解はありませんが、後から最上位階層を変更するのはリソースの移動を伴い手間がかかるため、初期段階でチームの合意を得ておくことが重要です。

7-2. 管理者以外の日常運用ユーザー設計

テナンシ管理者(Administratorsグループに所属するユーザー)は、テナンシ全体に対する強力な権限を持ちます。AWSにおけるルートユーザーの取り扱いと同様に、この管理者権限を日常のオペレーションで使い続けることは避けるべきです。

具体的には、日常運用に必要な権限だけを付与した専用のグループを作成し、コンパートメント単位でスコープを絞ったIAMポリシーを適用する運用が推奨されます。例えば、特定のコンパートメントの読み取り専用権限のみを持つグループや、特定のワークロードのリソースだけを操作できるグループを用意することで、誤操作や権限の濫用のリスクを抑えられます。

IAMポリシーの具体的な文法や、Identity Domains・ダイナミックグループを使った権限設計の詳細は、本シリーズ次巻のOCI IAM入門で扱います。本記事の段階では、「管理者権限は温存し、日常運用は専用グループで行う」という設計思想を押さえておいてください。

7-3. コスト管理 — 予算アラートとタグ

Always Free枠の範囲内で学習している間は課金の心配は基本的にありません。ただし§6で紹介した通り無料枠には利用量の上限が設けられており、これを超過したリソースを作成すると課金の発生するケースもあります。想定外の請求を防ぐために、予算アラートの設定をお勧めします。

OCIのコスト管理サービスでは、テナンシ全体またはコンパートメント単位で予算を設定し、実績や予測が閾値に達したとき、通知を受け取る仕組みが提供されています。AWSのAWS Budgetsに相当する機能と考えれば理解しやすいでしょう。

また、リソースにタグを付与しておくことで、どのプロジェクトやチームがどれだけのリソースを利用しているかを後から追跡しやすくなります。OCIにはフリーフォームタグと、値の形式を統一できる定義済みタグの2種類があり、AWSのコスト配分タグと同様にコスト分析に活用できます。具体的なタグ運用ルールは組織によって異なるため、本記事では「初期段階からタグ付け方針を決めておく」という点にとどめます。

7-4. 初期セットアップ チェックリスト

ここまでの内容を踏まえ、OCIアカウントを使い始める際に確認しておきたい項目を整理します。

• ホームリージョンが想定通りか確認したか(§3で触れた通り、ホームリージョンは後から変更できません)
• コンパートメントの初期階層(環境別/組織別)を設計したか
• テナンシ管理者アカウントにMFAを設定したか
• 日常運用向けの専用グループとIAMポリシーを用意したか
• 予算アラートを設定したか
• タグ付けの方針を決めたか

これらは最低限の初期設計項目であり、実際の要件によってはさらに検討すべき項目が増えるケースもあります。組織のセキュリティ要件やガバナンス方針に応じて、公式ドキュメントも参照しながら適宜追加することを推奨します。

8. まとめ — OCIアカウント設計の基礎と次のステップ

8-1. 本記事の振り返り

本記事では、OCIアカウントを構成する4つの柱について解説してきました。

まず、OCIアカウントの最上位概念である「テナンシ」は、AWSアカウントに相当する隔離されたルートコンテナです。次に、リソースを論理的に整理する「コンパートメント」は、最大6階層までネスト可能な構造を持ち、IAMポリシーのスコープ単位としても機能します。さらに、リソースが物理的に配置される「リージョン・アベイラビリティドメイン(AD)・フォルトドメイン(FD)」という3階層の物理配置は、AWSのリージョン・AZよりも一段階詳細な障害隔離の単位を提供します。そして、これらの概念を無料で試すための「Always Free枠」は、期限のない無料リソースとして学習に活用できます。

AWSの実務経験がある方であれば、アカウント=テナンシ、OU=コンパートメント、AZ=ADという対応関係を軸に理解を進めることで、OCI特有の概念(コンパートメントの最大6階層、AD配下のFD)への理解もスムーズに進んだのではないでしょうか。

8-2. 次巻予告 — OCI IAM入門

本記事で扱ったコンパートメント設計は、そのままIAMポリシーの設計に直結します。次巻では、OCIのIAM(Identity and Access Management)について、Identity Domains・ポリシー・グループ・ダイナミックグループといったトピックを深掘りします。

本記事の§7-2で触れた「管理者以外の日常運用ユーザー設計」の具体的な実装方法も、次巻で詳しく解説する予定です。テナンシとコンパートメントという土台を理解した上で、次はその上にどのようなアクセス制御を構築していくかを見ていきましょう。

→ 次巻: OCI IAM入門(Identity Domains・ポリシー・ダイナミックグループ)