Oracle Visual Builder

解決する課題

業務で必要なちょっとした Web 画面や社内アプリを、フロントエンド・バックエンド・ホスティングまで一式そろえて作るのは負担が大きい作業です。Visual Builder は、画面設計から REST 連携、認証、デプロイまでをローコードのビジュアル開発でまとめて提供し、内製のスピードを上げます。

• フロントエンドのビルド環境やホスティング基盤を自前で用意したくない
• ボタン1つで動く社内ツールや申請画面を、専任のフロント開発者なしで素早く出したい
• 既存の REST API や SaaS データを画面にバインドして、入力・一覧・更新の UI を組みたい
• 認証や権限管理を個別に作り込まず、ID 基盤と連携した状態で公開したい

AWS では、Web/モバイルのフロントエンド開発とホスティング、バックエンド連携を束ねる Amplify に近い領域で、ローコードに寄せた開発体験を提供する点が特徴です。

主要概念と用語

• ビジュアルアプリケーション（Visual Application）: 開発の単位。Web アプリ、モバイルアプリ、サービス接続、ビジネスオブジェクトなどをまとめて持つプロジェクト
• ページ（Page）/ フロー（Flow）: 画面の最小単位がページ、複数ページの遷移をまとめたものがフロー。ドラッグ操作で UI コンポーネントを配置する
• コンポーネント（Component）: 入力・表・ボタン・チャートなどの UI 部品。Oracle JET をベースにした標準コンポーネント群を使う
• サービス接続（Service Connection）: 外部の REST API や SaaS を呼び出す接続定義。エンドポイント・認証・レスポンス構造を取り込んで画面にバインドする
• ビジネスオブジェクト（Business Object）: アプリ内に持てる軽量なデータ実体。標準で REST エンドポイントが生成され、簡易なバックエンドとして使える
• アクションチェーン（Action Chain）: ボタン操作やイベントに応じて実行する処理の連なり。データ取得・分岐・遷移などをローコードで定義する
• 変数（Variable）/ タイプ（Type）: ページやアプリのスコープで状態を保持する仕組み。コンポーネントの表示や入力と双方向にバインドする
• ステージとライブ（Stage / Live）: 検証用と本番用の公開先。アプリをステージで確認してからライブへ昇格する運用ができる

仕様・制限・クォータ

• **インスタンス（環境）**は特定リージョンに作成するリージョナルなリソースで、その中に複数のビジュアルアプリケーションを保持する
• フロントエンドは Oracle JET ベースで、標準コンポーネントに加えてカスタムコンポーネントの取り込みにも対応する
• アプリのデータは、外部 REST/SaaS をサービス接続で参照するほか、ビジネスオブジェクトとして軽量に内部保持できる
• 1 インスタンスあたりのアプリ数・ストレージ・同時利用などにはサービス上の上限があり、提供形態やリージョンで異なる
• ソースは内部的にバージョン管理され、Git ベースの履歴管理や外部リポジトリ連携を取れる構成がある
• 具体的な上限値・料金・対応バージョンは変動するため、最新の公式ドキュメントで確認する

内部の仕組み

Visual Builder はマネージドな開発・実行環境です。開発者はブラウザのデザイナーで画面とロジックを組み立て、ビルド・ホスティング・スケーリングはサービス側が引き受けます。生成物は Oracle JET ベースの Web アプリとして動作します。

• デザイナーで配置したページ・コンポーネント・変数は宣言的なメタデータとして保持され、ビルド時に実際の JET アプリへ変換される
• データ取得はサービス接続を介した REST 呼び出しが基本で、レスポンスを変数にバインドして画面に描画する
• アクションチェーンがイベント駆動の処理単位となり、取得・分岐・遷移・代入などを順に実行する
• ビジネスオブジェクトを使うと、内部に持つデータへ自動生成された REST API でアクセスでき、簡易なバックエンドとして機能する
• 公開はステージとライブの2段階で扱え、検証してから本番へ昇格する流れを取れる

設計パターン / ベストプラクティス

• 既存 API のフロント化: 社内の REST API や SaaS をサービス接続で取り込み、一覧・詳細・入力の画面を素早く組む
• 軽量バックエンドはビジネスオブジェクト: マスタ管理や申請データなど小規模なデータ保持はビジネスオブジェクトで完結させ、別 DB を立てない
• 重い処理は外出し: 集計・連携・長時間処理は OCI Functions / OIC に委譲し、画面はトリガーと結果表示に徹する
• 認証は ID 基盤に集約: ログインや権限は **IAM / IDCS（Identity ドメイン）**と連携し、画面ごとに作り込まない
• ステージで検証してからライブへ: 公開は段階を分け、検証環境で確認したものだけを本番へ昇格する
• コンポーネントの再利用: 共通の入力フォームや表をフラグメント化し、ページ間で重複実装を避ける

運用・監視

• アプリの公開状態はステージ/ライブの2系統で管理し、本番へは検証済みのものだけを昇格する
• ソースはバージョン管理され、変更履歴の追跡やロールバックを前提に運用する
• フロントの動作はブラウザ側のログやネットワークトレースで切り分け、データ取得の失敗はサービス接続先の応答（4xx/5xx）を確認する
• バックエンド側の連携（Functions・OIC・外部 API）は、それぞれのサービスのメトリクスやログと突き合わせて障害箇所を特定する
• インスタンス自体の状態やライフサイクルは、OCI Console / CLI で確認・管理できる

コスト

Visual Builder のコストは主にインスタンス（環境）の稼働に応じて発生します。アプリ本数より、動かしている環境の規模と稼働時間がコストを左右する点を意識します。バックエンドに使う Functions・OIC・外部サービスの料金は別計上です。

セキュリティ

• IAM ポリシーとコンパートメントで、インスタンスの作成・管理権限を最小化する
• ログインや権限管理は **Identity ドメイン（IDCS）**と連携し、アプリ側で認証を独自実装しない
• 外部 API への接続情報（API キー・OAuth トークン）はサービス接続の認証設定で安全に扱い、画面やコードに直書きしない
• 公開アプリはステージとライブを分離し、検証中のものを誤って本番公開しないようにする
• 画面に表示・保持するデータに個人情報や機密が含まれる場合は、表示範囲とログ出力を最小化し、最小権限を徹底する

関連サービス・比較

Visual Builder は「画面を作って公開する」フロント寄りの位置づけで、同じ OCI の APEX（データベース中心のローコード）や OIC（連携・自動化）と役割が分かれます。ここでは最も近い OCI APEX と対比します。

関連して、外部公開と保護には API Gateway、サーバーレス処理には Functions、SaaS/アプリ連携と業務フローには OIC、認証には Identity ドメイン（IDCS）、秘密情報管理には Vault を組み合わせるのが定番です。

ハンズオン / CLI例

Visual Builder のアプリ本体はブラウザのビジュアルデザイナーで作るのが基本ですが、インスタンス（環境）の作成・確認・管理は OCI CLI（oci vb）で自動化できます。

# Visual Builder インスタンスを作成（ノード数などは要件に合わせて指定）
oci vb vb-instance create \
  --compartment-id ocid1.compartment.oc1..xxxxx \
  --display-name my-vb \
  --node-count 1

# コンパートメント内の Visual Builder インスタンスを一覧
oci vb vb-instance list \
  --compartment-id ocid1.compartment.oc1..xxxxx \
  --query "data.items[].{name:\"display-name\", state:\"lifecycle-state\", url:\"instance-url\"}" \
  --output table

# 単一インスタンスの詳細を取得（エンドポイント URL や状態を確認）
oci vb vb-instance get \
  --vb-instance-id ocid1.vbinstance.oc1..xxxxx

# ノード数を変更してスケールする
oci vb vb-instance update \
  --vb-instance-id ocid1.vbinstance.oc1..xxxxx \
  --node-count 2