Visual Builder Studio の基本（プロジェクト・ワークスペース・Git・公開）

Visual Builder Studio（VBS）は、ブラウザで動く開発環境（Designer）と、Git・ビルド・環境管理などの DevOps 機能を1つにしたサービスです。Fusion の Redwood ページの拡張も、新しい App UI の開発も VBS で行います。
中心になるのは プロジェクト（チームと Git リポジトリの入れ物）、ワークスペース（自分専用の作業場所。ブランチ・環境・サンドボックスを決める）、環境（配布先の Fusion インスタンス）、拡張（配布の単位）の4つです。
Publish は「コミット → プッシュ → ターゲット・ブランチへのマージ → デプロイ」をまとめて行う操作です。既定では CI/CD パイプラインを使わず、ワークスペースの開発環境へ直接デプロイします。
テスト・本番への昇格は、パイプラインか拡張ライフサイクル管理（Manage Extension Lifecycle）で行います。配布先は開発環境と同じ Fusion リリースである必要があります。

全体像

VBS の構成要素

要素	役割	ポイント
組織・プロジェクト	チーム、Git リポジトリ、ビルド、環境をまとめる入れ物	所有者（Owner）がメンバー追加やマージ制限を管理する
Git リポジトリ	拡張のソース（JSON・JavaScript など）を保存	1つの App UI の変更は1つのリポジトリにまとめるのが推奨
ワークスペース	自分専用の作業場所	Git のブランチ、配布先の環境、（任意で）サンドボックスを決める
Designer	ブラウザ上の開発画面	Express モード（機能管理者向け）と Advanced モード（開発者向け）
環境（Environment）	配布先の Oracle Cloud Applications インスタンス	既定で Development 環境が作られ、Publish の配布先になる
ビルド（ジョブ・パイプライン）	パッケージ作成とデプロイの自動化	パッケージ・ジョブで成果物を作り、デプロイ・ジョブで配布する
拡張（Extension）	配布の単位	既存アプリへの構成、自作の App UI、共有リソース（サービス接続など）を含む

プロジェクトには、マージ・リクエスト（コードレビュー）、課題管理（Issues）、ボード、Wiki などのチーム開発機能もあります。表示される機能はプロジェクトの種類と権限によって異なります。

ワークスペースとリポジトリの関係

ワークスペースは「完全に自分専用の作業場所」です。Designer で拡張を触る前に、必ずワークスペースを選ぶか作ります。

プロジェクト
 ├─ Git リポジトリ（リモート）── main ブランチ ＝ 公開済みの拡張
 ├─ 環境：Development（開発用 Fusion）／Test／Prod
 └─ ビルド：パッケージ・ジョブ → デプロイ・ジョブ（パイプライン）

ワークスペース（ユーザーごと・自分だけ）
 ├─ ローカル・リポジトリ（リモートのクローン）＋ 作業ブランチ
 ├─ 配布先の環境（例：Development）
 └─ サンドボックス（任意。未公開のデータモデル変更を使うとき）

変更は、リポジトリにマージする・共有（Share）する・公開（Publish）するまで、他のメンバーには見えません。
VBS インスタンスは環境ファミリー内の各インスタンス（DEV、TEST など）に紐付き、インスタンスごとにユーザーの ID も別になります。そのため、ワークスペースもインスタンスごとに持つことになります。
同じファイルを複数のワークスペースで触る場合は、片方で公開・マージしてから切り替えると競合を避けられます。

Fusion 環境との接続（ID の伝播）

環境の Fusion インスタンスは、ID ドメイン（Identity Domain）の方式で接続するのが推奨です。この方式では REST 呼び出しがログイン中のユーザーの ID で行われます。Basic 認証や OAuth で接続すると、接続を作成したユーザーの ID で呼び出されるため、一部の操作が失敗する原因になります。

設定・実装の手順

入口は2つ

Fusion の画面から入る（Redwood ページの拡張）：拡張したい Redwood ページを開き、ユーザー名のメニュー（Settings and Actions）から Edit Page in Visual Builder Studio を選びます。
- プロジェクトを選びます（Recommended のバッジ付きが推奨）。メンバーでなければ Request Membership で参加を申請します。プロジェクトがなければ + Create で作成し、作成者が所有者になります。
- ワークスペースは自動で作られます。名前は Workspace PILLAR（例：Workspace CX）の形式で、同じピラー（製品群）のページは同じリポジトリとワークスペースを共有します。
VBS から入る（新しい App UI の作成）：プロジェクトの Workspaces タブで New > New Application Extension を選びます。

新しい拡張を作る（VBS から入る場合）

前提として、プロジェクトに Development 環境が定義され、有効な Fusion インスタンスを指している必要があります。

Workspaces タブで New > New Application Extension を選びます。
拡張の名前を入力します。短く意味のある名前にし、「extension」や「UI」「app」のような一般的な語は避けます。
必要なら extension ID（site_ が接頭辞として付く）とワークスペース名を変えます。
必要なら Root Folder（既定 extension1）を変えます。リポジトリ内のこのフォルダに拡張のファイルが置かれます。
Development Environment を選びます。Basic 認証・OAuth で接続した環境は一覧に出ません。
未公開のサンドボックスのデータモデル変更を使うなら、sandbox を選びます。
Create new repository でリポジトリとブランチの名前を入れます。試すだけなら Use Scratch repository を選べます（自分にしか見えず、Git 操作やビルド・ジョブ、パイプラインは作られません）。
Create をクリックします。作成後は Menu > Settings で説明を書いておくと、他の人が依存関係として追加するときに役立ちます。

新しい App UI は、自作の App UI のベースとなる Unified Application の上に作られます。

拡張のライフサイクル（Redwood ページの構成）

Oracle の公式ドキュメントが示す流れを、実務の言葉で整理すると次の通りです。

データモデルを準備する：必要な項目の追加（サンドボックスでの変更など）を先に済ませます。
Designer を開く：Edit Page in Visual Builder Studio からプロジェクトとワークスペースを選びます。
構成する：拡張できるコンポーネントは青い枠で表示されます。プロパティ・ペインやルール・セット・エディタで変更します。
プレビューする：Designer のヘッダーの Preview で、ブラウザでの見え方を確かめます。
共有する：Menu > Share でプレビュー URL を作り、レビュー担当に送ります（サンドボックスを使う場合はその名前も伝えます）。
コミット・プッシュする：ヘッダーの Git メニューでリモートのブランチへ反映します。
マージ・リクエストを作る：レビューと承認を受けます。所有者はマージ・リクエストとレビューを必須にできます（main ブランチのマージ制限）。
マージしてデプロイする：main にマージし、配布先へデプロイします。Publish を使うと、コミット・プッシュ・マージ・デプロイを1回で行えます。
結果を確認する：Fusion で画面を開いて確認します。最新の変更を見るには、サインアウトして再度サインインが必要な場合があります。

Publish の動きとパイプライン

Publish は、現在のブランチの変更をターゲット・ブランチ（既定は main）のローカル・ブランチにコミットし、リモートへプッシュし、その内容をデプロイします。

設定	動き	向いている場面
Enable CI/CD pipeline がオフ（既定）	Publish でワークスペースの開発環境へ直接デプロイ	開発中の確認を早く回したい
オン	パッケージ・ジョブが成果物を作り、デプロイ・ジョブが配布。テスト環境・本番環境への配布も構成できる	テスト・本番への昇格、追加ジョブの自動実行

25.01.1 以降に Edit Page in Visual Builder Studio から作ったワークスペースと、25.10 以降に New Application Extension から作ったワークスペースでは、パイプラインは既定でオフです。既存の拡張は従来の設定のままです。
設定はブランチ単位で、そのブランチへ公開する全員（Express モードの利用者を含む）に影響します。むやみに切り替えないようにします。
パイプラインがオフの場合、Publish は即座にデプロイするため、公開の途中でマージ・リクエストを作る機会がありません。レビューが必要なら、Publish の前にマージ・リクエストを作ります。
Publish がデプロイするのは、公開元のブランチだけです。他の作業ブランチの変更も含めたいなら、先にターゲット・ブランチへマージしておきます。

テスト・本番への昇格

Advanced モード：Deploy でリモート・ブランチと配布先の環境（Target Environment）を選んでデプロイできます。
拡張ライフサイクル管理：Designer のヘッダー・メニューの Extension Lifecycle で Manage Extension Lifecycle ページを開き、拡張の Deploy to Environment で配布先の環境を選びます。一覧にない環境は Add Environment でベース URL と資格情報を登録します。Delete Extension で削除すると、そのインスタンスは拡張前の状態に戻ります。
配布先は開発環境と同じ Fusion リリースである必要があります。ずれていると「Dependent Extension with Extension id: xxxx and version >=xxxxx doesn’t exist」のようなエラーになることがあります。テストが先に更新される期間は、本番の更新を待ちます。

Designer の画面構成

領域	主な要素
ヘッダー	ワークスペース、Git リポジトリとブランチ（未コミットがあると黄色の点）、元に戻す・やり直し、サンドボックス、通知、Preview、Publish、Menu（Share・Import・Export・Settings）
ナビゲータ	App UIs、Layouts、Services、Dependencies、Components、Translations、Source、Git
キャンバス・エディタ	Page Designer、アクション、イベント・リスナー、変数、JSON、JavaScript など
プロパティ・ペイン	選択した部品の見た目と動作。表やリストでは Quick Start タブ
フッター	Audits（監査）、Find in Files、Git History、Logs、Tests

一部の Fusion ページでは、ヘッダーに Express|Advanced の切替が表示されます。HCM・SCM・調達（Procurement）の Redwood ページは Express モードのみをサポートします（26C 時点の公式ガイド）。

拡張の設定（Settings）

Menu > Settings で、拡張全体の設定を確認・変更します。主な項目は次の通りです。

Extension ID（site_ で始まる内部 ID）、Extension Name（依存関係の一覧に出る名前）、Version
Extension Pillar（CX、HCM などの製品群）と Extension Pillar Subcategory（CX のときの CX Sales・CX Service・CX Marketing）
Pillar Theme（App UI のカラーテーマ）
Unified Application のバージョン（実行時の依存関係を決める。Oracle JET のバージョンと合わせて使える機能が決まる）
Target Branch、Create CI/CD Pipeline、Enable CI/CD pipeline

コード例

レビュー担当がローカルで差分を確認する

VBS の Git リポジトリは通常の Git として扱えます。クローン用の URL と認証方法は、プロジェクトの Git 画面で確認してください（以下の URL は例）。

git clone "https://<your-vbs-host>/<path-to-repo>/extensions-scm.git"
cd extensions-scm

# リモートのブランチ一覧
# （Publish のたびに作られる <ユーザー名>-<タイムスタンプ> 形式のブランチが含まれることがある）
git fetch origin
git branch -r

# main と作業ブランチの差分（変更ファイルの一覧）
git diff --stat origin/main...origin/<feature-branch>

マージ・リクエストの説明テンプレート

マージ・リクエストの説明には、レビュー担当が動きを確かめられる情報を入れます。Share で作ったプレビュー URL を貼るのが公式にも推奨されています。

## 変更内容
- 対象ページ：購買依頼（Redwood）
- 変更：JP01 営業単位のとき、DFF「検収担当」を必須にするフォーム・ルールを追加

## 確認方法
- プレビュー URL：<Share で作成した URL>
- サンドボックス：なし
- テストデータ：JP01 と US01 の営業単位で1件ずつ

## 影響範囲
- 同じビジネス・オブジェクトを使う他のフォームにも適用される（ビジネス・ルールはオブジェクト単位）

以前のバージョンに戻す（ロールバック）

公式ドキュメントでは、まず以前のビルド成果物を再デプロイする方法を勧めています。成果物がない場合は、次の回避策があります（Advanced モード）。

1. Designer でブランチを以前のバージョン（<ユーザー名>-<タイムスタンプ>）へ切り替える
   （Create new branch based on parent branch を選ぶ）
2. 新しいブランチをリモートへプッシュする
3. Builds で拡張のパッケージ・ジョブに Branch パラメータを追加する（既定値は main のまま）
4. パッケージ・ジョブを手動実行し、Branch に新しいブランチ名を入れる
   → 成果物が作られ、デプロイ・ジョブが自動で動く

落とし穴とベストプラクティス

Publish で本番に直接出してしまう：パイプラインがオフだと、Publish はワークスペースの環境へ即座にデプロイします。本番に紐付いたワークスペースで作業しない。
リリースの異なる環境へデプロイする：テストが先に新リリースへ上がる期間は、本番へのデプロイを待つ。
Basic 認証の環境を使う：REST の実行ユーザーが接続作成者になり、権限の違いで失敗する。ID ドメイン方式で接続する。
サンドボックスを使ったまま拡張だけ公開する：サンドボックスは拡張と同時か直前に公開する。
複数のワークスペースで同じファイルを同時に編集する：片方を公開・マージしてから切り替える。

プロジェクトは環境ファミリー（開発・テスト・本番）ごとに1つ、リポジトリはピラー（HCM、CX など）ごとに分けるのが公式の推奨構成です。
拡張は App UI 単位ではなく、拡張全体として管理・配布されます。特定の App UI だけを別に公開したい場合は、ブランチを分けて個別に公開します。
main ブランチにマージ制限を設定し、マージ・リクエストのレビューを必須にします。
公開後に画面が変わらない場合は、サインアウトして再度サインインします。それでも変わらなければ、デプロイ・ジョブのログ（フッターの Logs）を確認します。

試験対策ポイント

対応する試験：Redwood 模擬テストの「VBS による Fusion アプリ開発（Developing Fusion Apps with Visual Builder Studio）」「VBS による Fusion Cloud 拡張の構成」
ワークスペースが決めるもの：Git リポジトリとブランチ、配布先の環境、サンドボックス（任意）。ワークスペースは自分専用。
Publish ＝コミット・プッシュ・マージ・デプロイ。パイプライン無効（既定）なら開発環境へ直接デプロイ。テスト・本番へはパイプラインか Manage Extension Lifecycle。
配布先は同じ Fusion リリースであること。
スクラッチ・リポジトリ（自分だけ・Git 操作なし・ビルドなし）、extension ID の site_ 接頭辞、ルート・フォルダ extension1。
依存関係（Dependencies）は App UI 単位ではなく拡張単位で追加する。