Oracle APEXのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Oracle APEXのシステム開発は、業務要件とデータ・権限の設計を先に固め、要件整理から定着までの六つの工程で進めます。

段階的なテストとリリースが、短納期と品質の両立につながります。

全体像から見積もりの確認事項まで、発注側の視点で見ていきます。各テーマの詳細は関連記事もご覧ください。

▼全体ガイドの記事
・Oracle APEXのシステム開発の完全ガイド

Oracle APEXのシステム開発の全体像

ブラウザ、APEX実行環境、Oracle REST Data Services、Oracle Databaseを上下4層に並べた構成図。
Web画面の背後に実行環境とデータベースが並びます。

Oracle APEXは、ブラウザとAPEX実行環境で動きます。

基本構成には、Oracle REST Data Services(ORDS)とOracle Databaseも含まれます。

登録や検索、承認などの業務画面と、ダッシュボードを宣言的に組み立てられます。

SQLやPL/SQLを使えば、業務ルールやバッチも拡張できます。

データモデルと業務ルールをどこに置くかが、開発の速さとあわせてシステム品質を左右します。

Oracle Databaseの資産を活かせる強み

Oracle Databaseに業務データが蓄積されている会社では、既存データを活用できます。さらに、別のデータ基盤へ複製するより、SQLで活用しながらWeb化できる可能性があります。

  • 活用する資産:販売、在庫、案件、購買、設備、申請などの既存データ。
  • 向く業務:業務データと画面の距離が近いAPEXで、入力、検索、集計、承認を行う業務。

Oracle Databaseを持たない場合は、APEXを選んでも必ず安くなるとは限りません。DBや認証、ネットワークなどの基盤が別に必要になります。さらに、帳票やAPIも必要になり、監視やバックアップも欠かせません。

そこで、確かめる点は、Oracle資産を中核にできるか、業務の中心がデータ処理か、オフラインや高度な端末制御が必須かです。これらを押さえると、SaaSやパッケージ、通常のWeb開発との境界が見えてきます。

向いている業務と慎重に検討する業務

APEXと相性がよいのは、部門業務や既存Oracle DBのWeb化などの業務です。

  • 部門業務:申請・承認、案件台帳、マスタ管理、点検記録。
  • データ活用:在庫照会、データ登録、既存Oracle DBのWeb化。
  • 業務画面:部門向けダッシュボードや、画面・検索・帳票・ワークフローの調整。

また、既存システムの周辺業務を切り出し、利用部門を限って公開する進め方にも合います。標準SaaSとフルスクラッチの中間案として、検討の対象になります。

一方で、複雑なオフライン処理や端末固有の高度な操作、巨大な公開サービスは、慎重に検討する必要があります。Oracle環境と接続できないデータ基盤が主軸なら、最初からAPEXに決めないほうが安全です。

高いピーク負荷や厳しい応答保証、国や拠点をまたぐデータ分離がある場合は、PoCで確かめます。PoCでは、性能や権限、障害時の挙動を見ます。そのうえで、採用の判断は、ローコードかどうかより、データ・業務・運用との適合性で行います。

ポイント

Oracle Databaseに既存データがあり、入力・検索・承認が中心の業務ならAPEXが候補です。オフラインや端末固有の高度な操作が必須なら、SaaSやパッケージ、通常のWeb開発と比べて判断します。

Oracle APEXのシステム開発の進め方

開発は、要件整理から始まり定着で終わる六つの工程で進みます。最初は要件整理と選定を行い、続けて設計・開発に入ります。その後、テストを経て、稼働と定着へ進みます。

画面試作は、要件定義の代わりにせず、会話の材料にします。そうすると、要件の抜けを早く見つけられます。また、各工程の完了条件を決めておくと、手戻りを抑えられます。

1. 要件整理:業務課題と成功条件

見積もりに必要な条件をそろえるには、まず業務の背景を把握します。

  • 業務の把握:誰がいつ何のために、何を登録・参照・承認するか。
  • 課題の具体化:「ExcelをWeb化」ではなく、集計に三日、問い合わせが多い、在庫差異を追えないなど。
  • 成功条件:入力時間、承認リードタイム、差戻し率、問い合わせ件数などのKPIを一つ以上。
  • 業務要件:フロー、画面・帳票、項目、必須・任意、重複、承認経路、組織変更。
  • 運用前提:保持期間、個人情報、利用者・同時利用数、ピーク、既存DB・ERP・会計・メール・IdP・APIの接続先、目標復旧時間。

要件整理で画面数だけを数えて、連携・権限・移行を曖昧にしたまま進めると、後から作業が膨らみます。

2. 選定:APEX、クラウド、オンプレミスの境界

まず、APEXの稼働環境と管理範囲を決めます。OCIのマネージドサービスは、環境運用の負担を下げやすい選択肢です。一方で、オンプレミスは、既存Oracle資産や閉域網、社内規程との整合を取りやすい選択肢です。

Autonomous Databaseでは、既存ライセンスやDBへの直接接続、バックアップと復旧、リージョン、ネットワークを比較します。

候補を比べる際は、APEXが業務に合うかを、五つの観点で判定します。

  • データ基盤:Oracle Databaseをデータの正にできるか。
  • 開発・保守:SQL・PL/SQLの人材または支援会社がいるか。
  • 連携:外部連携方式と遅延許容度が明確か。
  • セキュリティ:認証、ロール、行単位制御、監査ログを実装できるか。
  • 選定理由:SaaSやパッケージよりAPEXを選ぶ業務上の理由があるか。

3. 設計・開発:データと権限の先行整備

設計・開発では、画面より先にデータモデルと権限を固めておきます。

  • データモデル:主テーブル、明細、マスタ、履歴、論理削除、登録者・更新者・日時、状態遷移を定義。
  • 既存データ:一意性をDBでも担保し、項目の意味、コード、NULL、重複、過去データを確認。
  • 権限:ページ、ボタン、処理、行単位で分け、管理者・部門責任者・担当者・閲覧者・外部利用者の役割と不足時の表示・ログを設計。
  • 開発シナリオ:代表画面を利用部門と試作し、共通・個別機能を検索、登録、更新、承認、CSV入出力、添付、帳票、APIエラー時の再処理につなぐ。
  • 支援機能:APEX 26.1はAPEXlangによる可読なアプリ仕様やAI支援を提供。

一意性や既存データの扱いが曖昧なままだと、画面を整えても集計値の信頼性を保てません。

Oracle公式資料は、認証・認可スキームやロール、必要に応じた行レベルのデータセキュリティを示しています(出典: Oracle APEX 26.1公式ドキュメント、2026年)。

生成物はそのまま本番へ出さず、人が確認してから進めます。確認するのは、データモデル、認証・認可、監査、性能、テスト結果です。

4. テスト:業務シナリオでのデータ・権限・連携の確認

テストでは、画面の表示だけでなく、業務シナリオ全体が完了するかを確かめます。

  1. 単体テストでは、入力検証、計算、PL/SQL、認可を確認します。
  2. 結合テストでは、API、メール、帳票、基幹連携がつながるかを見ます。
  3. 総合テストでは、月末・締め処理のピーク、重複送信、タイムアウト、連携先停止、途中保存、差戻し、組織変更を試します。
  4. 受入テストでは、利用者がKPIに関わる業務を完了できるかを判定します。

特に重要なのがデータ移行リハーサルです。件数や合計金額、ステータス別件数に加えて、親子関係、日付、コード変換、権限別の見え方も突き合わせます。

さらに、移行に要する時間が業務停止時間を超えないか、失敗時に戻せるかを確かめます。切替後に旧システムへ戻す条件も、あらかじめ決めておきます。

個人情報を扱う場合は、テストデータのマスキング、操作ログの保管期間、バックアップからの復元も確認します。

5. 稼働:切替手順と戻し方の決定と本番化

本番化は、環境の準備、切替、障害時の戻し方を、この順に整えていきます。

  1. 本番構成や環境変数、接続先、証明書、メール、権限、監視、バックアップ、復旧手順を確かめます。
  2. アプリのエクスポート、DBオブジェクト、ORDS設定、外部接続情報の管理者を決めて、作業者しか知らない設定を残さないようにします。
  3. 切替方式は、一括切替、並行稼働、部門ごとの段階展開から選びます。
  4. 開始条件、最終バックアップ、移行承認、利用者告知、障害時の連絡先、切戻しの判断者を、時刻入りの手順書にまとめます。
  5. 一部門・一業務で始めて、ログと問い合わせを見てから広げます。段階的なリリースは、APEXの短い改善サイクルを活かせる進め方です。

6. 定着:教育・保守・改善の運用への組み込み

稼働後の支援は、利用者と管理者への対応と、継続保守に分けて準備します。

  • 利用者教育:操作説明、よくあるエラー、問い合わせ先、申請・承認ルール。
  • 管理者手順:ユーザー登録、ロール変更、データ修正、ログ、障害連絡、バックアップ復元。
  • 研修・質問対応:実データに近い演習を行い、稼働後の質問をFAQに反映。
  • 保守範囲:問い合わせ、障害、監視、APEX・ORDS・Oracle Database更新、脆弱性、法改正、追加開発。
  • 改善・引き継ぎ:利用状況を見直し、成果物を次の担当に渡します。

月次では、利用率や処理時間、エラー、差戻し、問い合わせ、KPIを確認します。そのうえで、未使用の画面や二重入力を改善します。

引き継ぐのは、コードだけでなく、APEXアプリのエクスポート、DB定義、環境設定、テスト仕様と結果、運用手順です。

資料をそろえて引き継いでおけば、将来の内製化やベンダー変更に備えられます。

ポイント

業務要件とデータ・権限を先に固められるかが、各工程の判断の目安です。画面試作は会話の材料とし、各工程の完了条件を決めておくと手戻りを抑えられます。

Oracle APEXの費用相場とコストの内訳

PoC・画面試作から全社・基幹周辺までの4段階について、開発費レンジを横棒で示した図。
連携や移行を含むほど、見積もりの幅も大きくなります。

費用は、APEXだけでなく、Oracle Database、OCI、ネットワーク、バックアップ、監視ごとに分けて考えます。

開発会社に依頼する場合は、要件定義、開発、移行、教育、保守の費用も見積もります。

APEXで開発工数を減らせる可能性はあります。ただし、要件・データ設計、セキュリティ、テスト、運用設計は、別に必要です。

Oracleの利用料金と環境・利用量による変動

Oracle公式の料金ページでは、OCIのAPEX Application Development Serviceの料金が掲載されています。

2 ECPU・20GBを31日連続で稼働させた場合、月額は約122ドルです。

一方、APEX with Autonomous Databaseは月額約502ドルからです。1ドル=150円で単純に換算すると、前者は月額約1.8万円、後者は月額約7.5万円です。

月額の金額は、計算資源とストレージの参考値です(出典: Oracle APEX Pricing、Oracle公式、2026年8月確認)。

為替やリージョン、稼働時間などで変動し、追加ストレージやバックアップ、ネットワーク、契約でも変わります。

  • クラウド課金:アプリ数、開発者数、利用者数ごとではなく、主に計算資源とストレージで課金。
  • オンプレミス:対応するOracle Databaseに追加ライセンス費用なしで含まれる案内。
  • 別途費用:DBライセンス、サーバー、ORDS、保守、運用担当者。
  • Always Free:検証・学習向け。本番の可用性、監視、サポート、セキュリティ要件は別途判断。

開発費と規模・連携・移行の範囲

APEX固有の国内開発費の統計は限られています。そのため、以下は一般的な業務システムの相場と、APEXの画面実装の特性をもとにした見積もりのたたき台です。

  • PoC・画面試作:100万〜300万円。
  • 部門向け業務アプリ:300万〜800万円。
  • 複数システム連携・移行あり:800万〜2,000万円。
  • 全社・基幹周辺:高可用性や段階展開を含み、2,000万〜5,000万円超。

案件ごとに前提が異なるため、相場をそのまま発注額とみなさないでください(出典: 業務システム全般の指定Q&Aを基にした推定、2026年)。

期間の目安は、PoCで1〜2か月、部門アプリで2〜4か月、外部連携を含む複数部門で4〜8か月です。

全社・基幹周辺では、6〜12か月以上を見込みます。その期間には、要件定義と移行、API本数、権限を含めます。テスト環境、教育、切戻し、稼働後の支援も含めます。

NRIの公式事例では、APEXで11個のアプリを本番展開し、アプリ開発作業を平均65%削減したと紹介されています。ただし、これはOracle DatabaseとSQLの知見を持つチームの個別事例で、すべての案件を保証するものではありません(出典: Oracle公式NRI導入事例、2026年確認)。

保守・運用費と初期開発費の切り分け

運用費は、基盤にかかる費用と保守契約の条件に分けて見積もります。

  • 基盤・サービス:OCIまたはオンプレミス、監視、バックアップ、ログ、ドメイン・証明書、外部サービス。
  • 保守作業:問い合わせ、障害対応、更新、追加開発。保守費は初期開発費の15〜25%が目安。
  • 変動条件:監視時間、SLA、問い合わせ数、夜間対応、パッチ、法改正対応。
  • 契約:月額定額と作業単価を分け、追加請求の条件を記載。

ポイント

費用の幅は、Oracle Databaseの有無や利用量、開発の規模、連携・移行の範囲、保守条件で変わります。見積もりを比べるときは、どこまでが費用に含まれるかを先に確かめます。

Oracle APEXの見積もりを取る際のポイント

見積もりの共通前提として、規模、システム要件、成果物、契約・引き渡しを示す4枚のチェックカード。
同じ条件をそろえると、各社の提案を照らし合わせやすくなります。

画面数だけで見積もりを比べると、判断を誤りかねません。そのため、各社には同じ前提を渡します。

開発、移行、テスト、教育、保守の境界を分けておくと、金額差の理由を比べられます。

合計額に加えて、成果物や前提条件、除外事項、変更時の単価も確認します。

要件と前提のまとめ方

未決事項も含めて、提案会社が確認事項と見積もりの条件を把握できる形にまとめます。

  • 規模:対象業務・部門、利用者・同時利用数、画面・帳票・CSV数。
  • システム要件:既存データの件数・品質、接続先・API、認証・権限、監査・保持期間、可用性・性能、ブラウザ・モバイル。
  • 未決事項:「未定」として確認依頼。画面5つでも権限10種、連携4本、移行リハーサル2回なら別規模。
  • 成果物:要件・業務フロー・ER図・画面帳票・権限・API・テスト・移行資料、アプリ出力・SQL・PL/SQL・ORDS・環境設定。
  • 契約・引き渡し:バックアップ・復旧、運用・教育資料、コード権利、著作権、外部ライブラリ、再委託、終了後の受け渡しと切替協力。

複数社の同条件比較とAPEX実績の確認

少なくとも3社に同じ条件を示し、工程別の見積もりと実績を比べます。

  • 工程・技術:要件定義・設計・開発・テスト・移行・教育・保守、APEX実績数、SQL・PL/SQL体制。
  • 対応力:OCI・オンプレミス、API・移行経験、セキュリティ、内製化、障害時の一次対応。
  • 実績確認:公式事例・受賞は品質保証ではない。同規模・同業界の担当者、成果物、保守体制も尋ねる。
  • 継続運用:退職後の保守、アプリ出力・自社管理、行権限テスト、Oracle・OCI更新検証、障害復旧を質問。
  • 回答の根拠:標準手順、サンプル成果物、体制表、SLAで提示できるか確認。

回答を資料で確かめられれば、ベンダーロックインのリスクを小さくできます。

安すぎる見積もりの除外範囲とリスク

見積もりの理由を確かめるには、対象範囲と情報管理の要件を照らし合わせます。

  • 相場より安い場合:要件定義、テスト、移行、教育、運用設計、セキュリティ、帳票、障害対応の除外を確認。
  • 工数の前提:短納期でも、データクレンジングや権限の組織設計が短くなるとは限らない。
  • 高い場合:汎用基盤・過剰機能や、段階リリースで先送りできる範囲を確認。
  • 情報管理:認証連携、最小権限、行制御、暗号化、秘密情報、ログ、パッチ、バックアップ、復旧目標、データ所在地。

クラウド利用でも、利用事業者側の安全管理責任はなくなりません(出典: 個人情報保護委員会「個人情報保護法に関するQ&A」、2026年確認)。

見積もりの抜けを防ぐには、誰が何を管理するかを一覧にします。

ポイント

見積もりは、同じ前提を各社に渡してから比べます。合計額に加えて、工程ごとの内訳や除外事項、変更時の単価まで見ると、金額差の理由が分かります。

Oracle APEXのシステム開発でよくある質問(FAQ)

料金や期間、内製化の可否は、Oracle Databaseの有無や連携数、権限、移行、運用要件によって変わります。

Oracle APEXは無料なので開発費も安くなりますか?

開発費全体を見ると、APEX本体の料金のほかに、DBや基盤、認証、ネットワークの費用も発生します。開発、移行、テストの費用もかかります。教育や保守も、見積もりに含めておく必要があります。

画面の工数を減らせる可能性はあります。ただし、業務要件、権限、連携、品質保証の費用まで、なくなるわけではありません。

Oracle APEXの開発期間はどのくらいですか?

PoC・画面試作は1〜2か月、部門向け業務アプリは2〜4か月が一つの目安です。

API連携や移行、複数部門の権限、高可用性、教育、段階展開を含む場合は、4〜8か月です。

全社・基幹周辺では、6〜12か月以上を見込みます。移行リハーサルと受入テストも含めて計画します。

Oracle APEXの開発は自社だけで進められますか?

小さな検証や単純な台帳なら、Oracle DatabaseとSQLの知識を持つ担当者が学びながら進められます。

一方で、本番利用には、要件やデータ、認証・認可を設計できる体制が必要です。性能やバックアップの設計も欠かせません。移行、監視、障害対応まで見通す必要があります。

外部委託の場合でも、業務責任者と運用担当者は社内に置きます。そのうえで、成果物とアプリのエクスポートを受け取り、内製化できる状態を目指します。

ポイント

自社で進めるかは、本番利用に必要な設計体制を社内で持てるかで判断します。料金や期間は、Oracle Databaseの有無や連携数、権限、移行、運用要件を前提に見ます。

まとめ

Oracle APEXの開発は、要件整理から定着までの六つの工程で進みます。最初は要件整理と選定を行い、続けて設計・開発に入ります。その後、テストを経て、稼働と定着へ進みます。判断の材料は、Oracle Databaseを中核にできるか、データ中心の業務に合うか、認証・権限・連携・移行・復旧を設計できるかです。PoCや段階リリースを使えば、リスクを小さくできます。

費用と発注で押さえる要点

開発費の金額は推定のレンジです。そのため、見積もりの際には前提条件を明示しておきます。

  • 内訳:APEX、Oracle Database・OCI、開発、移行、テスト、教育、保守。
  • PoC・試作:100万〜300万円。
  • 部門向け:300万〜800万円。
  • 連携・移行あり:800万〜2,000万円。全社・基幹周辺:2,000万〜5,000万円超。
  • 発注比較:同じRFPで工程・成果物・除外・保守・切替後の引き継ぎを比べる。

最初の一歩としての代表業務のPoC

PoCは、代表業務の選定から始め、準備を経て、結果の評価まで進めます。

  1. 利用者が多く、入力・検索・承認が明確で、Oracle Databaseを活かせる業務を一つ選びます。
  2. 業務フロー、サンプルデータ、権限、連携先、成功KPIをそろえます。
  3. 1〜2か月程度のPoCで使いやすさ、性能、権限、移行難易度を確認します。

PoCの成果は、本番化を判断する材料にします。そのうえで、全社導入を急ぐより、使われている業務から広げるほうが、APEXの価値を引き出せます。

▼全体ガイドの記事
・Oracle APEXのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。