TL;DR

  • Oracle AI World 2026 では、基調講演と複数のセッションで、AI に APEXlang の定義を生成させ、APEX Engine で実行するアプリ開発が紹介された。
  • 作りたいアプリを伝えると、AI が人の読める定義を書き、認証や監視、パッチといったアプリの基盤部分は APEX Engine と Oracle AI Database が受け持つ。データへのアクセス制御も APEX がかける。
  • 本記事では、React で作ったアプリとの比較デモを中心に、私の考察を交えて APEXlang を解説する。

はじめに

2026 OCI Top Partner Engineers の今井です。

2026年10月25日〜28日にラスベガスで開催された Oracle AI World 2026 に参加した。今年は基調講演でも APEXlang が取り上げられ、ほかにも APEXlang と絡めた話題のセッションが多くあったと感じた。

ここからは、私が参加した3つの講演で語られた仕組みとデモをもとに、APEXlang を掘り下げる。

APEXlang とは？

APEXlang は、Oracle APEX のアプリを、人が読める宣言的な定義として書くための言語だ。APEX 26.1 で登場した機能で、OCI の ADB のほか、オンプレミスでもすでに使える。登壇者は SQL にたとえた。SQL では欲しいデータを書けば、取り出し方は SQL Engine が担う。同じように、作りたいアプリを伝えると、AI が APEXlang で機能を定義し、APEX Engine がそのアプリを実行する。

作りたいアプリを伝えると、AI が APEXlang で機能を定義し、APEX Engine が実行する
作りたいアプリを伝えると、AI が APEXlang で機能を定義し、APEX Engine が実行する

基調講演では、成り立ちも語られた。APEX の強みは、アプリを動かす仕組み（APEX Engine）にあった。そこでアプリの定義を新しい言語に落とし込み、AI エージェントが APEX Engine の上でアプリを作れるようにしたという。

APEXlang でできること

できること 中身
AI にアプリの機能だけを生成させる 作りたいアプリを伝えると、AI が実装ではなく機能を APEXlang で定義し、APEX Engine が実行する
生成された定義を人が読んで直す フォームの定義は、対象の表（EMP）と許可する操作（追加・更新・削除）を書くだけの簡単な例として示された。アプリは application.apx とページごとの .apx ファイルなどで構成される
本番向けの仕組みを最初から使う IdP（ID プロバイダー）連携・ログ・監視・パッチが含まれ、コンテナやオーケストレーターを用意しなくてよい
データへのアクセスを権限で絞る 従業員情報を扱うアプリでは、作る人が意識しなくても、権限のある人だけがデータを見られるよう、APEX が制限をかける
パッチを一度で全アプリに当てる APEX Engine にパッチを当てれば、そのエンジンを使うアプリすべてに効く
フォームを定義する APEXlang の例。どの表をどう編集できるかが読める
フォームを定義する APEXlang の例。どの表をどう編集できるかが読める

ここで重要なのは、AI が書くのはアプリの「何をするか」だけで、「どう動かすか」は書かない点だ。認証や監視の作り込みを AI に任せないので、生成された定義を読むだけで、アプリがどの表に何をするかを確かめられる。

生成されたアプリの定義。アプリ全体の定義とページごとのファイルに分かれている
生成されたアプリの定義。アプリ全体の定義とページごとのファイルに分かれている

基調講演のデモでは、社員オンボーディングのアプリを自然言語で説明し、APEXlang でアプリの定義と必要な表の構造を生成していた。このアプリにも、権限に応じた制限が自動でかかっている。

基調講演のデモで生成された、社員オンボーディングのアプリ
基調講演のデモで生成された、社員オンボーディングのアプリ
同じアプリを APEX の開発画面で開いたところ。選んだ部品（Onboarding Metrics）に、データの取得元と SQL が設定されている
同じアプリを APEX の開発画面で開いたところ。選んだ部品（Onboarding Metrics）に、データの取得元と SQL が設定されている

発表のポイント

1. React 版と APEXlang 版を同じプロンプトで作り比べた

あるセッションのデモでは、Codex に同じプロンプトを渡し、従業員データ（EMP・DEPT 表）のダッシュボードを React と APEXlang のそれぞれで作った。画面に出る指標・グラフ・レポートは、どちらもほぼ同じだった。

違いは裏側にある。

React 版は多くのディレクトリにまたがる多数のファイルと、多数のサードパーティのライブラリで構成され、AI がどう作ったかを理解し、依存ごとに脆弱性を見張る必要がある。本番に載せるには、アプリケーションサーバへの配置、データベース、コンテナ、オーケストレーター、IdP 連携、ログ、監視、パッチまで用意しなければならない。デモの説明者は、アプリはすぐに作れたが、社内のコンプライアンスを通すには数週間から数か月かかりうると話した。

左が React 版のコード。右に、React 版を本番に載せるまでに必要な作業が示された
左が React 版のコード。右に、React 版を本番に載せるまでに必要な作業が示された

APEXlang 版は、最初から本番で使える状態にあると紹介された。コンテナが要らず、本番向けの仕組みも含まれている。私が自分の環境で試したときも、Autonomous AI Database（ADB）だけで、アプリケーションサーバやコンテナを用意せずに、APEXlang で作ったアプリをすぐに動かせた。

右が APEXlang 版の定義。APEX Engine と AI Database の組み合わせでは、コンテナが不要になり、IdP 連携・ログ・監視・パッチが含まれる
右が APEXlang 版の定義。APEX Engine と AI Database の組み合わせでは、コンテナが不要になり、IdP 連携・ログ・監視・パッチが含まれる

2. アプリが増えるほど、APEX Engine に任せる意味が大きくなる

基調講演では、AI はすでにアプリを生成できるのに、なぜこの仕組みが要るのかという問いに答えていた。AI に作らせたアプリは、手元で動いても、まだ社内の ID 基盤とつながっていないことが多い。ほかの人が使い始めた途端に ID 連携が必要になり、個人情報や給与情報が入っていれば社内の統制もかかる。

APEX では、こうした統制をアプリの層で受け持ち、利用者の ID をデータベースまで渡すと説明された。

アプリが1つなら、ID の仕組みが変わっても、そのアプリを直せば済む。しかし数が増えると、コードで作ったアプリを1つずつ改修することになる。アプリの定義と、それを動かす APEX Engine を分けておけば、変更は APEX Engine 側で受け持てる。

最後に、AI には任された仕事に必要な、いちばん高い抽象度だけを与えるべきだという考え方が示された。

ユースケースの考察

APEXlang 自体は少し前からある機能だが、AI がデータにアクセスできるアプリを、安全かつ簡単に生成できるようになった点で、AI エージェント時代に合った進化だと感じた。

想定しやすいのは、部門ごとに小さな業務アプリが次々に必要になる社内の場面だ。いまは、AI で作ったアプリを本番に載せるたびに、認証・監視・パッチの仕組みを用意し、審査を通す手間がかかる。

APEXlang なら、「コードを書く」のではなく「定義を書く」ことで、データにアクセスするアプリを安全に用意できる。そうなると、必要なアプリやエージェントをあらかじめ作り込んでおかなくても、データだけをしっかりつないで使える状態にしておけばよくなる。前提として、データの権限設計は、これまで以上にデータベース側で固めておく必要がある。

まずは、手元で AI に作らせた小さなアプリを1つ選び、APEXlang で同じものを生成して、動くアプリができるまでの手軽さを比べてみるとよい。