はじめに（全体の体系と記事の種類）
本ブログでは、OCI学習を体系立てて整理するために、次の2種類の記事を扱います。
- 知識ノート（N-xx）：概念・設計の考え方・判断基準を整理します。
- 検証（L-xx）：手順・設定値・つまずきポイントを、再現可能な形で記録します。
本記事は検証（L-00）として、OCIの学習・検証を継続するための「共通の土台」を先に整備します。
本ブログにおける「知識ノート（N）」と「検証（L）」の位置づけ
- 知識ノート（N）で「なぜその設計・設定が必要か」を理解し、
- 検証（L）で「実際に手を動かして再現できる状態」を作ります。
本記事で扱う検証範囲
本記事で行うこと
- 検証用コンパートメントの作成（推奨）
- 命名規約（名前の付け方）の決定
- タグ設計（最低限のキー）の決定と適用方針
- 主要リソースの“置き場所”を固定（例：
dev配下に集約）
1. 検証概要
- 本検証は、OCI学習に必要な「検証環境」を整備します。
- 命名規約とタグを設定し、リソースの棚卸し・削除・コスト把握を容易にします。
- 以降のNetwork/Compute検証を、同じ前提で再現できる状態にします。
2. ゴール（到達条件）
次の条件を満たすことをゴールとします。
- 検証用コンパートメント（例：
dev）が作成され、以降のリソース配置先が確定している - 命名規約（プレフィックス、環境名、用途、連番など）が文章化されている
- 必須タグ（例：
env/owner/purpose/ttl）の方針が決まり、少なくとも1リソースに適用できている - 「どこに何を作るか」のルール（リージョン、コンパートメント、命名、タグ）が1ページで確認できる状態になっている
3. 前提（構成・権限）
3-1. 構成前提
- OCIテナンシにログインできること
- 利用リージョンが決まっていること（例：Japan East（Tokyo））
- 検証用の配置先としてコンパートメントを新規作成できること
- 以降の検証で作成する予定の代表リソースを想定していること
- VCN / Subnet / IGW・NAT・SG / Route Table / NSG
- Compute Instance / Block Volume
- Object Storage Bucket（必要に応じて）
3-2. 権限前提（最小限）
以下のいずれかを満たすことが必要です。
- テナンシ管理者相当の権限がある
または - 対象コンパートメント配下で「コンパートメント作成」「タグ（定義/利用）」「主要リソース作成」に必要な権限が付与されている
※権限は組織ルールにより異なります。最小権限で進める場合は、後続のIAM記事に沿って段階的に付与します。
4. 設定値（一覧表）
※理解のために最初に固定します（例です）。
| 項目 | 推奨値（例） | 補足 |
|---|---|---|
| 利用リージョン | Japan East（Tokyo） | 学習では1リージョン固定が管理しやすいです |
| コンパートメント | dev（配下に必要なら network / compute など） | まずは dev のみでも問題ありません |
| 命名プレフィックス | oci もしくは任意の短縮名 | 例：oci-dev-net-vcn-01 |
| 環境名（env） | dev | 本番想定がある場合は stg/prod を将来追加します |
| 必須タグ（例） | env, owner, purpose, ttl | ttl(Time To Live) は検証リソースの削除忘れ防止に有効です |
| 連番 | 01, 02, 03... | 同種リソース複数作成時の識別に使用します |
命名規約（推奨フォーマット）
{prefix}-{env}-{domain}-{resource}-{nn}
- 例：
oci-dev-net-vcn-01 - 例：
oci-dev-cmp-vm-01 - 例：
oci-dev-obj-bkt-01
domain例：net（network）/ cmp（compute）/ obj（object）/ sec（security）
5. 手順
手順1：検証用コンパートメントを作成します
- OCIコンソールで Identity & Security → Compartments を開きます。
- Create Compartment を選択し、
devを作成します。 - 必要に応じて、配下に
network/computeなどの子コンパートメントを作成します（任意）。
確認ポイント：作成したコンパートメントが一覧に表示され、選択できる状態になっていること。
手順2：タグ方針を決定し、タグを付与できる状態にします
- 最低限のタグキーを決めます（例：
env/owner/purpose/ttl）。 - 可能であれば、タグ・ネームスペース（またはタグ定義）を作成します（組織ルールに従います）。
- 任意の既存リソース、または新規に作成した簡易リソースにタグを付与します。
確認ポイント：リソース詳細画面で、タグが表示されること。
手順3：命名規約を本文として固定し、以降の検証で統一します
- 命名規約フォーマット（例：
{prefix}-{env}-{domain}-{resource}-{nn}）を記事に記載します。 - domainの略称（
net/cmp/obj/secなど）を表として定義します。 - 以降の検証記事では、この命名規約でリソース名を付けることを明記します。
確認ポイント：次の検証（Network/Compute）で、命名規約どおりの名前を付ける準備ができていること。
6. 結果（成功/失敗のスクショ）
成功時（証跡）
- コンパートメント一覧に
devが表示されている画面
- 任意のリソース詳細で、タグが付与されている画面
失敗時（典型例）
- コンパートメント作成ボタンが表示されない／作成が失敗する
- 原因例：権限不足（ポリシー未付与）
- 対応例：管理者に必要権限の付与を依頼する（対象コンパートメント範囲を明確化）
さいごに（所感）
検証環境は、最初に「置き場所（コンパートメント）」と「識別方法（命名規約・タグ）」を固定しておくと、作業を効率的に進めやすくなります。あわせて、リソースが増えた場合でも整理・検索がしやすくなり、構成を見失いにくいと感じました。
情報ソース
- OCI公式：IAM 概要（権限の考え方）
https://docs.oracle.com/en-us/iaas/Content/Identity/Concepts/overview.htm - OCI公式：ポリシー（Policies）
https://docs.oracle.com/en-us/iaas/Content/Identity/Concepts/policies.htm - OCI公式：コンパートメント管理
https://docs.oracle.com/en-us/iaas/Content/Identity/Tasks/managingcompartments.htm - OCI公式：リージョンと可用性ドメイン
https://docs.oracle.com/en-us/iaas/Content/General/Concepts/regions.htm - OCI公式：タグ（Tagging）
https://docs.oracle.com/en-us/iaas/Content/Tagging/Concepts/taggingoverview.htm
コメント