従来型の拡張（サンドボックス・ページ構成・Application Composer）

従来型（ADF ベース）の画面の拡張は、サンドボックスの中で行い、確認してから公開（Publish）して全員に反映します。
画面の見た目は Page Composer、ナビゲータやホームのアイコンは Structure、用語の置き換えは User Interface Text、データモデルと業務ロジックは Application Composer（Groovy）が担当します。
Application Composer は主に CX（Sales・Service など）で使われ、SCM でも一部の領域で使われます。ERP（財務・調達）の項目追加は、フレックスフィールドが基本です。
Page Composer などの変更は Redwood ページには効きません。Redwood 版へ切り替える画面は、VBS で作り直す前提で棚卸しします。

全体像

従来型の拡張ツール

ツール	変えるもの	主な利用場面	Redwood ページ
サンドボックス（Sandboxes）	変更を試すための隔離された作業場所	すべての従来型ツールの土台。公開するまで他のユーザーに影響しない	VBS の拡張でも、未公開のデータモデル変更を使うときにワークスペースへ紐付ける
Page Composer	画面の部品の表示・非表示、並び、プロパティ	従来型ページの項目を隠す・並べ替える	使えない（VBS を使う）
Structure	ナビゲータのメニュー、ホームのアイコン	メニューの整理、外部リンクの追加	―
User Interface Text	画面の文言	用語を社内用語に置き換える（全ページ一括も可）	Redwood のメッセージやページ・タイトルの変更にも使う
Application Composer	カスタム項目・カスタム・オブジェクト、トリガー、検証、ワークフロー（Groovy）	主に CX のデータモデルと業務ロジック	データモデルを作り、画面は VBS で出す

ほかに、ロゴや配色を変える Appearance などのツールもあります。使えるツールはリリースと製品によって異なるため、公式ガイド「Configuring and Extending Applications」で確認してください。

サンドボックスの考え方

サンドボックスは「本番の画面に影響させずに変更を試す場所」です。

サンドボックスを作り、使うツールを選びます。
サンドボックスに入った状態（アクティブ）で、各ツールで変更します。変更はそのサンドボックスに入っているユーザーにだけ見えます。
確認が済んだら公開（Publish）し、全員に反映します。
他のサンドボックスが先に公開された場合などは、最新の状態に合わせる（Refresh）必要があります。

VBS との関係では、Application Composer などでの未公開のデータモデル変更を、VBS のワークスペースに紐付けて使えます。公式ドキュメントは次の運用を勧めています。

サンドボックスに紐付けたブランチで作業し、終わるまで同じブランチとサンドボックスの組み合わせを使う
別のデータモデル案を試すときは、新しいブランチに別のサンドボックスを紐付ける。ブランチとサンドボックスの組ごとにワークスペースを分ける
サンドボックスは、拡張の公開と同時か直前に公開する

Page Composer

Page Composer は、従来型ページの部品を画面上で編集するツールです。項目やリージョンの表示・非表示、並び替え、ラベルなどのプロパティ変更ができます。サンドボックスをアクティブにしてから、ユーザー名のメニュー（Settings and Actions）の編集メニューで開きます。変更を全員に適用するか、特定のジョブ・ロールに適用するかを選べるページもあります（編集できる範囲と方法はページにより異なるため公式ドキュメントで確認）。

HCM・SCM の Redwood 拡張ガイドの比較表では、Page Composer は従来型（レスポンシブ）ページ専用で、Redwood ページには使えないと明記されています。Redwood ページでは、同じ目的（項目の表示・必須・並び替え）を VBS の Express モードで実現します。

Structure と User Interface Text

Structure：ナビゲータのグループ・ページの並びや表示、ホーム画面のアイコンを構成します。社内ポータルなど外部ページへのリンクも追加できます。
User Interface Text：画面の単語・文言を置き換えます。たとえば「従業員」を「社員」に一括で置き換えるような、用語の統一に使います。Redwood ページのメッセージやページ・タイトルの変更にも使われます。

Application Composer と Groovy

Application Composer は、ブラウザ上でデータモデルと業務ロジックを拡張するツールです。

機能	内容
カスタム項目	標準オブジェクトに項目を追加する（API 名に `_c` が付く）
カスタム・オブジェクト	独自のオブジェクト（表に相当）を作る。REST API も使えるようになる
トリガー・検証ルール	保存時などの処理、入力値の検証を Groovy で書く
オブジェクト・ワークフロー	条件に応じて項目更新・通知などを行う

主な利用製品：CX（Sales、Service など）が中心です。SCM でも一部の領域で使われます。どのアプリケーション・オブジェクトが対象かは、Application Composer の画面と製品ごとのドキュメントで確認します。
Groovy：Java に近いスクリプト言語です。Application Composer で使えるのは安全のために制限された範囲で、使える関数・クラスは公式の Groovy スクリプトのリファレンスに従います。
VBS との役割分担：Application Composer でデータモデル（項目・オブジェクト）を作り、Redwood の画面にはそれを VBS で出します。公式ドキュメントも「データモデルの変更は Application Composer で先に行い、VBS で UI に出す」順序を示しています。

ERP での適用範囲

ERP（財務・調達）の案件では、従来型の拡張は次のように使い分けるのが一般的です。

要件	主な手段
取引・マスタに項目を足す	付加フレックスフィールド（DFF）、拡張可能フレックスフィールド（EFF、対応オブジェクトのみ）
従来型ページの項目を隠す・並べ替える	Page Composer（サンドボックス内）
Redwood ページの表示・必須・既定値	VBS（Express モードのビジネス・ルール）
メニューの整理	Structure
社内用語への置き換え	User Interface Text
業務ロジック（承認の経路など）	承認ルールなどの設定（承認ワークフロー）
帳票・抽出	BI Publisher、OTBI（レポーティングツールの全体像）

ERP の業務オブジェクトでは Application Composer を使う場面は限られます。項目追加の設計はフレックスフィールドと値セットを参照してください。

設定・実装の手順

従来型ページの項目を隠す（Page Composer の例）

サンドボックスを作り、Page Composer を使うツールとして選んで、サンドボックスに入ります。
対象の従来型ページを開き、ユーザー名のメニュー（Settings and Actions）から編集メニューを開いて Page Composer に入ります。
隠したい項目やリージョンを選び、表示のプロパティを変更します。
サンドボックスの中で、対象ロールのユーザーの見え方を確認します。
サンドボックスを公開して全員に反映します。

Redwood へ切り替える前の棚卸し

従来型ページで行っている変更（Page Composer、HCM の Transaction Design Studio など）を一覧にします。
Redwood 版のページで、同じことが VBS の Express モード（ビジネス・ルール、ページ・プロパティ）でできるかを確認します。
できないもの（例：HCM・SCM の Redwood 拡張ガイドで「サポート外」とされている書式の変更など）は、要件そのものを見直します。
Redwood 版を有効にする時期に合わせて、VBS の拡張を作り、テスト環境で確認してから公開します。HCM のように、Redwood ページを有効にすると、同じビジネス・オブジェクトを使う他のページ向けのルールを無効にする必要がある製品もあります。

環境間の移送

従来型ツールで作った公開済みの変更（サンドボックスで公開したもの）は、Fusion の構成の移送機能（Configuration Set Migration など）で別の環境へ移します。
設定データ（設定および保守の設定）は、機能設定マネージャの構成パッケージで移送します（機能設定マネージャ（FSM））。
VBS の拡張は、VBS のデプロイ（パイプラインや Manage Extension Lifecycle）で配布します。

手段ごとに移送の仕組みが違うため、移送計画では「どの変更を、どの仕組みで、どの順番で移すか」を一覧にします。具体的な画面操作は、リリースにより異なるため公式ドキュメントで確認してください。

コード例

Application Composer の Groovy（例）

次は、カスタム・オブジェクトのトリガーと検証ルールのイメージです。項目名（_c が付いた API 名）と使える関数は、実際のオブジェクトと公式リファレンスで確認してください。

// 見積金額が 100 万円以上なら、優先度を HIGH にする
if (EstimatedAmount_c != null && EstimatedAmount_c >= 1000000) {
  setAttribute('Priority_c', 'HIGH')
}

// 終了日は開始日以降であること
return (EndDate_c == null || StartDate_c == null || EndDate_c >= StartDate_c)

移行前の棚卸しシート

ID,従来型ページ,現在の変更,手段,Redwood での代替,判定
CL-01,購買依頼の作成,「緊急区分」を必須表示,Page Composer,VBS Express のフォーム・ルール（Required）,代替可
CL-02,仕入先の照会,項目の並び替え,Page Composer,ページ・プロパティ／ルール・セット（ページによる）,要確認
CL-03,ナビゲータ,社内ポータルへのリンク,Structure,Structure（継続）,継続
CL-04,請求書の照会,金額を赤字の太字で表示,Page Composer,書式の変更は対象外の可能性が高い,要件見直し

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

サンドボックスは目的ごとに作り、長期間放置しないようにします。複数のサンドボックスで同じ対象を変えると、公開時の競合の原因になります。
従来型の変更も拡張一覧に載せ、Redwood への切り替えとアップデートのたびに見直します。
Groovy は短く、テストしやすく書きます。重い処理や外部連携は、OIC などの連携側に寄せます。

試験対策ポイント

対応する試験：Redwood 模擬テストの「VBS による Fusion Cloud 拡張の構成（Explain the types of supported extensions）」
Redwood でないページは VBS で拡張できず、Application Composer などの従来の手段を使う。
データモデルの変更（Application Composer・サンドボックス）が先、VBS で UI に出すのが後。サンドボックスは拡張と同時か直前に公開。
Page Composer・Transaction Design Studio は従来型（レスポンシブ）ページ専用で、Redwood ページでは VBS の Express モードを使う。
用語の置き換えは User Interface Text。