拡張の全体像（構成・パーソナライズ・拡張・PaaS）

Fusion を変える手段は「構成（設定）→ パーソナライズ → 拡張 → 連携 → PaaS」の順に、標準に近いものから検討します。
Redwood ページの画面変更は Visual Builder Studio（VBS）、従来型（ADF）ページはサンドボックス上の Page Composer・Structure などが担当です。ページのメニューに Edit Page in Visual Builder Studio が出るかどうかが見分け方です。
項目（データモデル）を足すのはフレックスフィールドや Application Composer、それを画面に出して制御するのが VBS、という役割分担で考えます。
SaaS 本体のコードは変更できません。四半期アップデート後も残るのは、Oracle が用意した拡張ポイント（動的コンポーネント、ビジネス・ルール、ページ・プロパティ、フレックスフィールド、REST API）を使った変更だけです。
Fusion の外で動く、Fusion ユーザー以外が使う、独自のデータベースが必要、といった要件は Visual Builder の Web アプリ・APEX・OCI などの PaaS で作ります。

全体像

5つの手段

Fusion で「標準と違うことをしたい」ときの手段は、次の5つに分けられます。上にあるものほど標準に近く、アップデートの影響を受けにくくなります。

手段	誰が・どの範囲に	代表的なツール	例（架空：サンプル商事）
構成（Configuration）	導入担当がサイト全体に設定	設定および保守（Setup and Maintenance）の設定タスク	付加フレックスフィールド（DFF）のセグメント定義、参照タイプ、承認ルール
パーソナライズ（Personalization）	エンドユーザーが自分だけに	各画面の表示設定	列幅の変更、検索条件の保存
拡張（Extension）	管理者・開発者が設計時にサイト全体へ	VBS（Redwood ページ）、Page Composer・Structure・Application Composer（従来型ページ）	JP01 営業単位の取引だけ DFF を必須にする
連携（Integration）	開発者	REST・SOAP API、FBDI、ビジネスイベント、Oracle Integration（OIC）	外部の経費システムから請求書を取り込む
PaaS（独自アプリ）	開発者	Visual Builder（Web アプリ）、APEX、OCI	取引先向けポータル、独自 DB を持つ申請アプリ

構成と拡張の境目は、Oracle の Redwood 拡張ガイドの例がわかりやすいです。DFF を設定タスクで有効にするのは「構成」、その DFF を特定の画面で特定の国のときだけ表示するのは VBS による「アプリケーション拡張」です。パーソナライズは実行時にエンドユーザー本人だけに効く変更で、拡張は設計時にサイト全体へ効く変更です。

ページの種類で使うツールが変わる

26C 時点の Fusion には、Redwood ページと従来型ページ（Redwood 以前の ADF ベースの画面）が混在しています。どちらのページかで、使える拡張ツールが変わります。

ページ	見分け方	画面の拡張	項目の追加
Redwood ページ	ユーザー名のメニュー（Settings and Actions）に Edit Page in Visual Builder Studio が出る	VBS（Express モード／Advanced モード）	DFF（設定タスク）を定義し、VBS のルールで表示・必須を制御
従来型ページ	上記のリンクが出ず、サンドボックス内で Page Composer が使える	Page Composer、Structure（ナビゲータ）、User Interface Text	DFF、Application Composer（主に CX）

VBS の公式ドキュメントは「ページを開いて Edit Page in Visual Builder Studio が見えたら、Fusion 側のツールではなく VBS で UI を変更する合図」と説明しています。リンクが出ない理由は、Redwood 未対応のページであることのほかに、VBS へのアクセス権限がない、その環境に VBS インスタンスが紐付いていない、という場合もあります。

データモデルと UI を分けて考える

拡張の設計では「何を足すか」を3層に分けると整理しやすくなります。

データ（項目・オブジェクト）：ERP・SCM ではフレックスフィールド（DFF・EFF）が基本です。CX では Application Composer でカスタム項目・カスタム・オブジェクトを作ります。
画面（表示・必須・既定値・入力チェック）：Redwood ページでは VBS のビジネス・ルールやルール・セットで制御します。
外部とのデータの受け渡し：REST API、FBDI、ビジネスイベント、OIC を使います。

VBS のドキュメントは、データモデルの変更（Application Composer など）を先に済ませてから、VBS で画面に出す順序を推奨しています。

設定・実装の手順（手段の選び方）

要件ごとに、次の順番で手段を決めます。

標準機能・設定で実現できないか確認する（Fit to Standard）。設定で済むものを拡張にしません。考え方は標準機能とアドオンの考え方を参照してください。
本人だけの好みならパーソナライズに任せます。全員に強制する必要がなければ拡張は作りません。
画面の表示・必須・読取専用・既定値・入力チェックは、Redwood ページなら VBS のビジネス・ルール（Express モード）で実現します。従来型ページなら Page Composer です。
項目を増やすときは、DFF を設定タスクで定義・デプロイし、Redwood ページではビジネス・ルールで表示と必須を制御します（フレックスフィールドと値セット）。
用語・ラベルの一括変更は User Interface Text ツールで行います。
新しい画面（Fusion のデータを Fusion のユーザーが使う）は、VBS で App UI を作ります。Fusion と同じ見た目・同じ認証で動きます。
Fusion の外で動く画面（外部ユーザー、独自 DB、独自デザイン）は Visual Builder の Web アプリ、APEX、OCI で作ります。
データの受け渡しは連携方式の全体像、帳票・分析はレポーティングツールの全体像の範囲です。

PaaS の選び方

画面を新しく作る場合の選択肢を比べます。

選択肢	向いている要件	Fusion との関係	注意点
VBS の App UI	Fusion ユーザー向けの新画面、Fusion データの参照・更新	Fusion 上で動き、他の Redwood アプリと同じ見た目になる	独自のビジネス・オブジェクト（DB）は持てない。Fusion の外では動かない
Visual Builder の Web アプリ	外部ユーザー、独自のビジネス・オブジェクト、高度な認証方式の REST、独自デザイン	サービス・カタログ経由で Fusion のデータを利用でき、Fusion に埋め込むこともできる	Visual Builder の実行環境を別に運用する
APEX	SQL 中心の業務アプリ、独自テーブルでの集計・帳票	REST データ・ソースとして Fusion の REST API を呼ぶ	Fusion の DB は直接参照できない（REST や抽出データ経由）
OCI（Functions、Autonomous Database など）	重い計算、独自 API、データ基盤	REST・イベント・BICC 抽出で連携	画面は別途必要。運用設計の負荷が大きい
OIC	システム間連携（画面なし）	ERP Cloud アダプタ、ビジネスイベント	画面開発の手段ではない

VBS の公式ドキュメントは、App UI では足りない典型として「高度な認証方式の REST への接続」「自前の DB でのカスタム・ビジネス・オブジェクト」「Oracle Cloud Applications の外での実行」「Fusion の資格情報を持たないユーザーへの提供」「独自のルック・アンド・フィール」を挙げ、これらはレスポンシブ（Web）アプリで作るよう案内しています。

SaaS 拡張の原則

四半期アップデートに耐える

Fusion は四半期ごと（26A〜26D）に更新されます。通常はテスト環境が先に、本番が後に更新されます（VBS のドキュメントでは、ポッドの更新はおおむね2週間以内の差）。
アップデート後も残るのは、Oracle が用意した拡張ポイントを使った変更です。VBS では Designer 上で「拡張可能な領域」として示された部分しか変更できず、ページの中身を直接書き換えることはできません。この制約が拡張を守っています。
製品ごとの拡張ガイドに書かれた範囲に留めます。たとえば Redwood 版のセルフサービス調達（25B）の新機能説明では、ガイドに載っていない変更は将来の更新と互換性がなく、ページが正しく表示されなくなるおそれがあると注意しています。
開発環境と配布先のリリースを揃えます。新リリースに上がったテスト環境で作った拡張を、旧リリースのままの本番へデプロイしてはいけません。本番の更新を待ってからデプロイします。
拡張の実行時依存（Unified Application のバージョンと Oracle JET のバージョン）も定期的に更新します。VBS は更新を促すポップアップを表示します。

サポート範囲と責任分担

Oracle が提供するのは標準機能と拡張の仕組み（ツール）です。作った拡張の中身（ルールの条件、JavaScript、独自の App UI）は導入側の成果物として、設計書・ソース管理・テストを含めて管理します。契約上のサポート範囲はサポート契約と Oracle のポリシーで確認してください。
障害の切り分けでは、拡張を外した状態で再現するかを確かめます。VBS のビジネス・ルールは個別に非アクティブにでき、デプロイ済みの拡張は削除すると元の状態に戻ります。

セキュリティは拡張で作らない

項目を画面で隠しても、データへのアクセス権は変わりません。VBS のドキュメントも「サービス接続はデータへのアクセスを提供するが、データ・セキュリティは課さない」と明記しています。見せてはいけないデータは、ロールとデータ・アクセスで制御します（セキュリティの基本）。

コード例

拡張は「数が増えるほど、アップデート時の確認が重くなる」ため、一覧で管理します。次は拡張一覧（RICEW の E）の例です。

ID,対象画面,要件,手段,拡張ポイント,アップデート時の確認
EXT-001,購買依頼（Redwood）,JP01営業単位のとき検収担当（DFF）を必須,VBS Express,フォーム・ルール（Required）,ルールの評価結果と項目の有無
EXT-002,ショッピング・カート（Redwood）,Distribute Project Costs アクションを一般ユーザーに表示しない,VBS Express,ビジネス・ルール,アクションの表示・非表示
EXT-003,請求書の照会（従来型）,社内用語に合わせて項目ラベルを変更,User Interface Text,テキストの置換,ラベルの表示
EXT-004,取引先ポータル（新規）,取引先が自社の請求状況を確認,Visual Builder Web アプリ,Fusion REST API,API の互換性と認証

手段を選ぶときの流れは、次のように整理できます。

要件
 ├─ 設定タスクで実現できる？ ─────────── はい → 構成
 ├─ その人だけの好み？ ───────────────── はい → パーソナライズ
 ├─ 既存画面の表示・必須・既定値・検証？
 │    ├─ Redwood ページ ───────────────→ VBS（ビジネス・ルール／ルール・セット）
 │    └─ 従来型ページ ─────────────────→ Page Composer（サンドボックス内）
 ├─ 項目が足りない？ ─────────────────→ DFF（ERP/SCM）／Application Composer（主に CX）
 ├─ Fusion ユーザー向けの新画面？ ──────→ VBS の App UI
 ├─ Fusion の外・外部ユーザー・独自 DB？ ─→ Visual Builder Web アプリ／APEX／OCI
 └─ システム間のデータ連携？ ────────────→ REST・FBDI・OIC

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

項目を隠せばセキュリティになると考える：画面で隠しても REST API などからは参照できます。権限はロールで制御します。
従来型ページの Page Composer の変更が Redwood 版に引き継がれると思い込む：Page Composer は Redwood ページには使えません。Redwood へ切り替える前に、VBS で作り直す計画を立てます。
リリースの異なる環境へデプロイする：テスト環境が先に新リリースになっている期間に作った拡張を、旧リリースの本番へ配布しない。
データモデルの変更と拡張の公開タイミングがずれる：サンドボックスで行ったデータモデル変更は、拡張の公開と同時か直前に公開します。
ガイドにない方法で画面をいじる：将来のアップデートで動かなくなる原因になります。

「設定 → パーソナライズ → 拡張 → PaaS」の順で検討し、検討結果（なぜ拡張が必要か）を記録します。
拡張は一覧で管理し、四半期アップデートのたびに回帰テストの対象にします（環境管理・四半期アップデート・テスト）。
画面側の入力チェックは利便性のためと割り切り、必須の業務ルールは承認ルールや設定など、画面以外でも守られる仕組みを優先します。

試験対策ポイント

対応する試験：Redwood 模擬テストの「Redwood エクスペリエンス（The Redwood Experience）」「VBS による Fusion Cloud 拡張の構成（Configuring Oracle Fusion Cloud Extensions with Visual Builder Studio）」
Edit Page in Visual Builder Studio が出るページは VBS で拡張する。出ない理由（Redwood 未対応、権限不足、VBS インスタンスなし）も問われます。
構成（設定タスク）・パーソナライズ（本人だけ・実行時）・拡張（サイト全体・設計時）の違い。
データモデルの変更（Application Composer・フレックスフィールド）が先、VBS で画面に出すのが後。
App UI と Web アプリの使い分け（外部ユーザー、独自 DB、Fusion の外での実行は Web アプリ）。
Oracle 自身も VBS と Oracle JET で Redwood アプリを作っているため、顧客の拡張も同じ道具で作れる、という Redwood プラットフォームの考え方。