はじめに
OCI Resource Manager を試していきましょう。
OCI Resource Manager とは
OCIリソースのデプロイメントと操作を自動化するOracleマネージドサービス です。
AWS で言うところの AWS CloudFormation と同じ立ち位置ですね。
Terraform 実行エンジンが OCI 上に実装されています。
すごくざっくり言うと、今までローカルで実行していた Terraform 環境や操作をまるっと OCI 上にもっていった サービスです。
各種コンポーネント
リソースをプロビジョニングする際の全体像は以下の通りです。
構成
構築する OCI リソースを定義している HCL 形式 もしくは json 形式のファイル のことを指します。
単に Terraform ファイルのことだと思っていただいて大丈夫です。
そしてそれらファイルのソースとして指定可能なものが幾つかあります。
ソースについて、実際の OCI コンソールと紐づけながら記載していきます。
マイ構成
以下 3 つの形式があります。
| 形式 | 概要 |
|---|---|
| フォルダ | ローカルで作成した Terraform ファイルをまとめたフォルダごとアップロード |
| オブジェクト・ストレージ・バケット | ローカルで作成した Terraform ファイルを バケットにアップロードし参照する |
| Zipファイル | ローカルで作成した Terraform ファイルを Zip形式で圧縮しアップロード |
テンプレート
ユースケースに沿って Oracle 社が事前定義した Terraform ファイル群であり、それらをソースとする形式です。
「テンプレートの選択」をクリックすると、カテゴライズされた幾つかのテンプレートが用意されています。
「クイックスタート」「サービス」「アーキテクチャ」は Oracle 社提供のテンプレートであり、「プライベート」は組織の管理者が定義したテンプレートです。

テンプレートについてはこちらを参照ください。
ソース・コード制御システム (構成ソース・プロバイダ)
外部のソース・コード管理プラットフォームにて管理されている Terraform ファイルをソースとする形式です。
2025 年 11 月時点では以下をサポートしています。
- Bitbucket クラウド
- Bitbucket サーバー
- OCI DevOps
- GitHub
- GitLab
詳細はこちらを参照ください。
既存のコンパートメント
既存コンパートメント内に作成されているリソースを Stack 管理にする形式です。
Stack
Terraform ファイルで定義された OCI リソースの集合体 のことを指します。
言い換えると上述した構成(ファイル)群のことです。
OCI Resource Manager は Stack 単位でリソースを管理します。
Job
リソースに対する 更新・作成・削除などの Stack に対する操作のこと です。
Terraform の Plan / Apply / Destroy 等のことです。
特定の Stack に対しては同時に 1 つの Job のみ実行できます。
異なる Stack の Job は 並行して実行できます。
Job の詳細は以下を参照ください。
Job のライフサイクルは以下の通りです。
何がうれしいのか
大きく以下 2 つだと考えています。
State ファイルの管理が不要
OCI Resource Manager が自動生成し管理及び更新してくれます。
ローカル環境で実行する場合だと、大抵はオブジェクト・ストレージで管理するかと思いますが、その手間が省けます。
- State ファイルの手動編集は不可となります
実行ユーザーの一元管理
OCI IAM と統合されているため、実行権限等を OCI IAM で管理できます。
ローカル環境で実行する場合だと、実行ユーザー毎に API キーもしくは セッション・トークンを生成する必要がありセキュリティリスクとなりますが、そのリスクを低減することができます。
デメリットはあるのか
強いてあげるとすれば、 Terraform のバージョンアップに追従する必要があることです。
Terraform のバージョンは OCI が管理しており、対応しているバージョンにも限りがあります。
メジャーバージョン / マイナーバージョンは固定で、パッチバージョンは選べるという形ですね。
※画像は 2025 年 11 月時点

実践
それでは実際に試していきます。
今回はローカルでファイルを作成し、ファイルがまとめられているフォルダをアップロードしていきます。
まずフォルダ構成は以下の通りです。
work
|-- locals.tf
|-- main.tf
|-- modules
| `-- vcn
| |-- main.tf
| `-- variables.tf
|-- providers.tf
`-- versions.tf
各 Terraform ファイル中身
# デプロイ先コンパートメントID定義
locals {
compartment_id = "ocid1.compartment.oc1..aaaaaaaao7es4oejvbuffragkycdcgrjyb3rhogehogehogehogehogehoge"
}
# OCI プロバイダーのバージョン指定
terraform {
required_providers {
oci = {
source = "oracle/oci"
version = "~> 7.25.0"
}
}
}
provider "oci" {
region = "ap-tokyo-1"
}
# Terraform のバージョン指定
# これにより、コンソール上での選択可能バージョンが固定される
terraform {
required_version = "~> 1.5.0"
}
# 変数定義
variable "compartment_id" {
type = string
}
variable "cidr_block" {
type = string
}
# リソース定義
resource "oci_core_vcn" "vcn" {
compartment_id = var.compartment_id
cidr_block = var.cidr_block
}
# モジュール呼び出し
module "vcn" {
source = "./modules/vcn"
compartment_id = local.compartment_id
cidr_block = "10.0.0.0/16"
}
スタックの作成より「マイ構成」→「フォルダ」を選択し、Terraform ファイルがまとめられたフォルダをアップロードします。

「作業ディレクトリ」は、Terraform コマンドを実行するディレクトリを指します。
今回の構成では、work ディレクトリ直下の main.tf でリソース作成を定義しているため、work を指定しています。

「カスタムプロバイダ」は以下のサイトに記載されているプロバイダ以外のものを使う時に使用します。今回は使用しないためチェックしません。
「名前」「説明」はオプションです。
「コンパートメントに作成」は、スタックをどのコンパートメントに所属させるかを指定するものです。

「Terraform のバージョン」は文字通り実行する Terraform のバージョン指定です。

- 今回の環境では、
versions.tfにて Terraform のバージョンを制限しています - そのためコンソール上から変更が出来なくなっています
- アップロードしたファイルから判断してくれていますね
「タグ」は任意です。今回は付けずに画面左下「Next」をクリックします。

続いて「変数」を入力する画面になります。
今回はリソース定義のある main.tf にて variables ブロックの呼び出しを行っていないため特に入力がありません。
画面左下の「Next」をクリックします。

最終確認画面に遷移するので内容を確認します。
「適用の実行」にチェックを入れない場合、スタックが作成されるのみでジョブは実行されません。
今回はスタック作成と同時にジョブを走らせたいのでチェックを入れます。
問題なければ「作成」をクリックします。

数分待ち、ジョブが成功となれば完了です。
※リソースの確認は割愛させていただきます

おわりに
本記事では OCI Resource Manager について調べたことをまとめました。
OCI における 唯一の IaC サービスであり、IaC 実行環境をマネージドで管理してくれるので非常に重要なサービスです。
実行環境を別途用意せずとも、OCI コンソール上で一元管理できるのは非常にありがたいですね。
OCI を商用で展開していく際には必ず通るサービスかと思いますので、これを機にマスターしていきましょう!
🌟この記事が誰かの役に立てば幸いです!
また、ご質問やフィードバックもお待ちしています。
番外編
アップロードした Terraform ファイルは直接編集可能
新規作成したファイルがある場合は、再度フォルダ含めてアップロードする必要がありますが、
既にアップロードしたファイルを編集したい場合は、直接編集することが可能です。
スタック詳細画面から「編集」→「Terraform構成をコード・エディタで編集」をクリックします。

すると CloudShell が起動し、スタック内のファイルを編集することが可能となります。

- 起動できなかった場合は、CloudShell の権限が足りないのでポリシーを追加してください
クラウド・シェルは、コンパートメント・レベルでのポリシーをサポートしていません。テナンシ・レベルのみです。








