※ 本記事は、Monica Godoyによる”Transforming Oracle Forms to Oracle APEX in the AI Era: Introducing the Modernization Forms to APEX Skill“を翻訳したものです。

2026年11月9日

第1回では、AIを活用した刷新の手順で、Oracle FormsのサンプルアプリケーションのCustomersモジュールとOrdersモジュールを分析しました。FormsのXMLとデータベースの依存関係を調べ、再利用できる業務ロジックを特定しました。そして、モダンなOracle APEXアプリケーションを構築するために、機能要件仕様書、トレーサビリティマトリクス、刷新に関するレポートを作成しました。

サンプルのFormsアプリケーション

このデモでは、Summit Sample Formsアプリケーションのうち、以下に示すCustomersモジュールとOrdersモジュールを使います。

図1：Customersフォーム

図2：Ordersフォーム

アプリケーションでは、大きく分けて次の機能を提供します。

  • 顧客の検索と管理を行うCustomer Workbench。
  • 注文の検索と作成を行うOrders Workbench。
  • 選択した注文とその明細を表示するOrder Detailページ。
  • 顧客、注文、注文明細用のドロワーフォーム。
  • 商品と倉庫ごとの在庫を表示するProduct Inventoryページ。
  • 支払いの検証、出荷日の検証、明細番号の生成、商品のデフォルト値、注文合計の計算には、提供済みのデータベース関数とプロシージャを使用。

前提条件

第1回で挙げた前提条件に加え、次の準備が必要です。

  • Oracle APEX 26.1環境へのアクセス
    ダウンロードするか、OCIに無料のOracle AI Autonomous Databaseをプロビジョニングします。
  • AIコーディングエージェントにAPEXlangのスキルをインストール
    VS CodeでOracle APEX開発を始めるを参照してください。
  • スキーマのメタデータファイルを生成
    Formsで使うOracleデータベースのテーブル、列、データ型、キー、制約、索引、Formsとデータベースから読み取った業務ルールを記録したファイルです。このファイルは第1回で生成しました。
  • Summit Sample Applicationの機能要件書を生成
    第1回で生成した、APEXアプリケーション用の仕様書です。

機能要件書を確認する

自然言語の機能要件書ができたら、要件に不足がないかを確認します。特に、業務に合わせて改善・簡素化できる処理や、すでに不要になっていて廃止できる処理を見極めることが重要です。

読み進めると、アプリケーションを大きく改善できる点や、使いたいAPEXコンポーネントを、より明確に指定したい点に気付くかもしれません。次に例を示します。

  • ナビゲーションを簡素化
    変更前： システムは、次のグローバルナビゲーション項目を提供する。
    – Customer Workbench（顧客ワークベンチ）
    – Customer Directory（顧客ディレクトリ）
    – Orders Workbench（注文ワークベンチ）
    – Order Detail（注文詳細）
    – Product Inventory（商品在庫）
    – Administration / Reference Data（管理／参照データ）
    変更後： システムは、次のグローバルナビゲーション項目を提供する。
    – Customer Workbench（顧客ワークベンチ）
    – Orders Workbench（注文ワークベンチ）
    – Product Inventory（商品在庫）
    – Administration / Reference Data（管理／参照データ）
    独立した顧客ディレクトリページは、その機能をCustomer Workbenchに統合したため削除しました。注文詳細はグローバルナビゲーションから外しましたが、Orders Workbenchから開く関連ページとして残します。
  • Customer Workbenchを拡充
    変更前： 顧客を閲覧・絞り込みするCustomer Workbenchページを提供する。国と営業担当者で絞り込めるようにし、Formsの階層ツリーの動作を、APEX標準のフィルター、ファセット検索、またはツリーリージョンで置き換える。
    変更後： 顧客の閲覧・絞り込みに加え、作成と更新ができるCustomer Workbenchページを提供する。国と営業担当者で絞り込めるようにし、Formsの階層ツリーの動作を、APEX標準のフィルターと、クラシック・レポートを組み合わせたファセット検索で置き換える。
    要件と、アプリケーションで使いたいAPEXコンポーネントを、正確に記述してください。
  • 役立つホームページを作成
    変更前： 初期表示ページから、顧客検索、注文検索、最近の注文、未処理の注文にすぐアクセスできるようにする。
    変更後： 初期表示ページに、利用者の役に立つダッシュボードを用意する。関連する業務データを、APEXのチャートで表示する。
    アプリケーションのホームページになるため、適切なKPIを示す有用なダッシュボードを作るのが自然です。

FormsからAPEXへの刷新スキル

刷新プロジェクトの事情は組織によって異なります。複数のモジュールやアプリケーションに共通で適用する、独自のルール、動作、安全上の制約が必要になる場合があります。スキルを入手し、組織の要件に合わせて調整してください。この刷新スキルでは、第1回で作成した機能要件とスキーマのメタデータを、正式な入力情報として扱います。アプリケーションを生成する前に、次の刷新手順を定めます。

  1. 業務プロセス、エンティティ、トランザクション、検証、計算、レポート、マスターと明細の関係を特定します。
  2. その要件を、データベースのスキーマと既存の業務ロジックに照らして整合させます。
  3. ファセット検索、クラシック・レポート、スマート・フィルター、対話モード・レポート、フォーム、ドロワーページ、LOV、検証、計算、動的アクションなどを使い、APEXに適した操作環境を設計します。組織で刷新するすべてのアプリケーションに対し、特定のFormsコンポーネントをAPEXでどう置き換えるかを、ここで定義できます。
  4. キャンバス、ウィンドウ、キーボードトリガー、アラート、ツリーコントロール、ナビゲーションの組み込み機能など、Forms固有の実装の詳細を除外します。
  5. 各要件と、その根拠となるデータベースの情報、対応先のAPEXコンポーネントを結ぶトレーサビリティマトリクスを作成します。
  6. APEXlangでアプリケーションを生成し、インポート前にAPEXコンパイラで検証します。

目指すのは、Oracle Formsの画面をそのまま再現することではなく、業務プロセスとOracle Databaseへの投資を生かすことです。たとえば、Formsのマスター明細モジュールには、次の置き換え方があります。

  1. 業務上、画面内での直接編集が必要なら、マスター明細の編集画面にします。APEXでは、対話グリッドで似た操作を実現できます。
  2. 2段階のページ構成にします。利用者はワークベンチでレコードを閲覧・絞り込みし、概要を把握できます。レコードを作成または選択すると、親レコードの概要と関連する子レコードを表示する詳細ページを開きます。APEXでは、ファセット検索ページ、クラシック・レポート、ドロワーページを組み合わせて実現できます。

本記事では、Formsモジュール内のすべてのマスター明細コンポーネントに、2番目の方法を適用するようスキルを設定します。組織の操作性やガバナンスの基準に合わせ、このルールを変更したり、別のルールを追加したりできます。

スキルの出力

アプリケーション生成を依頼し、ワークスペースの入力情報が確定すると、スキルで次のファイルを生成します。

  • .apexlang/application-spec.md：ページ、業務フロー、検証、ナビゲーション、データベースへの依存関係を定義します。
  • .apexlang/app-ux-contract.json：ページ構成、マスター明細の文脈、アクション、LOV、再表示の動作、受け入れテストを定義します。
  • 生成したAPEXlangアプリケーション
    • application.apx
    • ページの.apxファイル
    • 共有コンポーネント
    • ナビゲーションとパンくずリスト
    • LOV
    • フォームとレポート
    • 検証、計算、プロセス、動的アクション
  • 検証の記録
    • 利用可能な場合は、ローカルの検証レポート
    • コンパイラの判定を基準にした監査
    • SQLcl／APEXでの検証記録
    • 実行前の確認と、検証のみを行った場合のレポート
    • 明示的に許可され、実施した場合は、インポートと実行時の確認記録
条件に応じて出力するもの
  • 要件に不足や矛盾がある場合は、機能要件仕様書（FRS）の改訂版、または要件の補足
  • 安全に生成できない場合は、差分と不足する入力情報のレポート
  • 再利用可能なトランザクション処理の業務ロジックが必要な場合は、任意のPL/SQLパッケージ仕様部と本体
  • 廃止するFormsコンポーネントと除外する組み込み機能について、根拠を示した一覧

完了状態も、次の値で明確に報告します。

  • BLOCKED（続行不可）
  • VALIDATED-BUT-NOT-IMPORTED（検証済み、未インポート）
  • IMPORTED-BUT-NOT-RUNTIME-VERIFIED（インポート済み、実行時は未検証）
  • COMPLETE（完了）

スキルを実行する

次のようなプロンプトで、スキルを呼び出せます。

Oracle APEXを使い、CustomersとOrdersのOracle Formsアプリケーションを刷新してください。
使用するもの：

  • 機能要件としてcustomers-orders-spec.md
  • 正式なスキーマのメタデータとしてschema_metadata.md
  • modernize-oracle-forms-to-apexスキルとAPEXlangスキル

重要事項：

  • ワークスペース：<F2A>
  • 完全なAPEXlangアプリケーションを作成し、インポート可能であることを確認してください。
  • アプリケーション名：Customers and Orders App – Skill
  • アプリケーション作成に要した経過時間と作業量を示してください。

アプリケーションをインポートしてテストする

デモ動画を見る

作業中に分かったこと

1. ナビゲーションメニューでキャッシュをクリアする
Customer Workbenchから顧客の注文を開いた後、ナビゲーションメニューでOrders Workbenchに移動すると、顧客の情報がキャッシュに残ります。その結果、その顧客の注文だけを表示してしまいます。修正するには、ナビゲーションメニューの項目で、Orders Workbenchページのキャッシュをクリアするよう設定します。

図3：顧客の注文を開けるCustomer Workbenchページ

2. 外部キーと制約を考慮する
テーブルの列をフォームのデータソースに使い、その列に外部キーがある場合、APEXでは対応する値リストを自動作成します。今回も、正しく作成されました。さらに、S_CUSTOMERテーブルのcredit_rating列にはチェック制約があり、許可された値が、Customer Formページの選択リストに自動的に含まれました。

図4：テーブルの制約と、APEXアプリケーションでの表現

3. 業務ロジックを再利用する
Ordersのフォームページには、第1回でエージェントが特定し、機能要件書に記録した関連ロジックを適切に組み込めました。出荷日と支払い種別を検証し、明細がある注文は削除できないようにしています。

図5：Orders Formページの検証

まとめ

完成したのは、Formsの各画面をそのまま置き換えたものではありません。重要な業務プロセスを維持した、APEX本来の構成のアプリケーションです。

  • 顧客と、その顧客の注文との関連を維持します。
  • 注文と、その注文明細との関連を維持します。
  • 商品を選ぶと、適切なデフォルト値を設定します。
  • 与信と出荷に関するルールを引き続き適用します。
  • 明細番号を自動生成します。

繰り返し使える刷新の手順は、次のとおりです。

分析 → 仕様化 → 整合性の確認 → 設計 → 生成 → 検証 → インポート → テスト

このように、既存のOracle Databaseへの投資の価値を保ちながら、機能要件からモダンなOracle APEXアプリケーションを作成できます。