Apache Derbyのシステム開発の完全ガイド

Apache Derbyのシステム開発では、構成、開発手順、保守、移行判断を整理すると、退役後の採用・継続の判断に役立ちます。開発費は、DBの価格より人件費や工程で決まります。

Derbyは2025年10月10日に開発とバグ修正が終わっているため、継続か移行かの判断も欠かせません。詳細は下の関連記事もご覧ください。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Apache Derbyのシステム全体像

Apache Derbyは、Javaの業務アプリケーションにデータベースエンジンとJDBC接続を組み合わせた構成です。大規模なデータベース製品を別途導入せずに済むため、開発環境や単体製品の保存先として使われてきました。

Derbyは退役済みなので、導入の手軽さだけでなく将来の保守責任も含めて判断する必要があります。

純Javaで動くRDBMSとしての特徴

Derbyは純Javaのリレーショナルデータベース管理システムで、主な接続方法は標準SQLとJDBCです。

提供構成：10.17.1.0には、組み込みエンジン、Network Server、ネットワーク用JDBCドライバーがそろっています。
付属ツール：SQL実行用のij、スキーマ確認用のdblook、環境調査用のsysinfoを含みます。
配布の利点：ライセンス費を抑えやすく、JARとしてアプリの配布物に含めやすい点が利点でした。

2026年時点の退役状況と採用判断

Apache Derbyでは、2025年10月10日にプロジェクトが読み取り専用となり、開発とバグ修正が終了しました（出典: Apache Derby Downloads、2025年）。そのため、今後のリリースは予定されておらず、既存の配布物も現状有姿で提供されます。

新しい基幹システムで採用するなら、脆弱性対応、Java更新、障害復旧、代替DBへの移行費用を誰が負担するかを確認しておく必要があります。

Apache Derbyのシステムの種類と特徴

JVM内で完結する構成と複数接続の構成が並びます。

DerbyにはEmbeddedとNetwork Serverの2つの構成があり、JVMの境界や接続方法、障害の影響範囲、運用責任が異なります。用途に合わせて選ぶには、それぞれの違いを先に押さえておく必要があります。

選ぶときは、利用者数だけでなく、同時実行、データの重要度、バックアップ、拠点間接続も確認します。

単一アプリに組み込むEmbedded構成

Embedded構成では、Derbyのエンジンが業務アプリケーションと同じJVM内で動きます。

サーバー不要：専用のDBサーバーを別に起動せず、導入環境を小さくできます。
向く用途：Javaデスクトップ製品、端末別の業務ツール、テスト用DBに適します。
接続遅延：アプリとDBが同じプロセスで動くため、遅延を抑えやすい構成です。

ただし、Embedded構成は複数JVMや複数ホストからDBを直接共有する用途には向きません。アプリの停止がDBの処理にも影響しやすいため、同時利用者が多いWeb業務システムでは、ファイル共有に頼らず構成を見直す必要があります。

複数クライアントから接続するNetwork Server構成

Network ServerはDerbyをサーバー側のJVMで起動し、別のJVMや業務端末からネットワーク接続します。

複数ユーザーが同じデータを使う部門システムでは候補になります。

Embedded構成より便利になる反面、DBを一つのサービスとして運用する責任も増えます。

認証と通信：サーバー認証、通信経路、ファイアウォール、接続元を設計します。
運用管理：ログ、バックアップ、容量監視の仕組みを決めます。

得意な用途と慎重に判断すべき用途

DerbyはJava製品の内部や開発・テスト用データ、限定的な小規模業務に適しています。

標準SQL・トランザクション・JDBCで既存アプリへ組み込みやすい一方、用途との適合性は慎重に評価する必要があります。

慎重な評価が必要：大量アクセス、複数拠点の常時接続、厳格な監査がある場合です。
高可用性：24時間365日の稼働や長期サポートを求める基幹システムです。

ライセンス費がかからない点だけで判断すると、大規模な用途では費用の見込みが外れやすくなります。性能試験・障害対応・監視・脆弱性調査・JDK更新・移行演習には、ライセンス費以外の費用がかかるためです。

適合性は、データ量や画面数に加えて、停止許容時間と保守期限を基準に判断します。

ポイント

EmbeddedかNetwork Serverかは、アプリとDBを同じJVMで動かすか、複数の端末から接続するかで決まります。同時接続や拠点間接続も合わせて見ると判断しやすくなります。

Apache Derbyのシステム開発の進め方

開発の前に、新規採用、既存資産の延命、別のRDBへの移行を分けて考えます。

退役後は技術の選定自体がリスクの評価になるため、要件定義の段階で保守と移行の出口まで決めておきます。

▶ 詳細はこちら：Apache Derbyのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

企画・要件定義で決める項目

企画・要件定義では、業務の要件と既存環境の両方を洗い出します。

業務とデータ：利用者・業務範囲・データ種類・保存期間・1日あたりの処理件数・ピーク同時接続数を整理します。
保護要件：個人情報・機密情報の扱い・外部公開の有無・RTOとRPO・バックアップ世代数・監査ログの保存期間を決めます。
採用理由：Derbyを使う理由と、代替DBとの比較結果を要件書に残します。
既存環境：Derby・JDK・JDBCドライバー・アプリケーションサーバー・フレームワーク・OSを一覧にします。
関連資産：起動停止手順・DBファイルの場所・設定・バッチ・バックアップスクリプト・障害手順書を調べます。

ソースコード以外も確認しておかないと、移行後に見えない依存関係が残るおそれがあります。

設計・開発でのDB交換への備え

将来のDB交換に備えて、アプリの分離設計とJava環境の互換性を確かめておきます。

層を分ける：新規開発や既存改修では、業務ロジックとデータアクセス層を分けて、SQLを一か所に集めます。
差分を管理：予約語・日付と数値の型・NULL・自動採番・LOB・トランザクション分離の違いを記録します。
移行余地を残す：保守が続く代替RDBへ移せるよう、Derby固有の機能を画面や業務ロジックに広げないようにします。
Java互換性：10.17.1.0は、Java SE 21以上とJDBC 4.2に対応しています。
環境を検証：Java 8や11ではDerbyの版だけで解決しない場合があるため、Java、フレームワーク、ドライバー、テスト環境を互換性マトリクスで確認します。

Java 21より前の環境は対象外です（出典: Apache Derby 10.17.1.0 Release、2023年）。

テスト・移行・リリースで確認する項目

移行の成否と切替時の復旧に関わる項目を、順に検証します。

単体テストに加えて、業務シナリオ・同時接続・長時間稼働・異常終了・容量上限・権限・通信障害を確認します。
バックアップから復元し、移行時には件数・金額の合計・日付・タイムゾーンを照合します。
画面の表示だけでなく、文字コード・NULL・LOB・索引・制約・採番値を検証して、業務結果が一致するかを確かめます。
初回移行・差分同期・業務停止・切替・検証・ロールバックをリハーサルします。
問題が起きたときの判断者と、何分以内にどの状態へ戻すかを決めておき、現場の混乱を抑えます。
納品物には、ソース・DB定義・移行スクリプト・テスト仕様書・復元と障害対応の手順を含めます。

ポイント

進め方の分かれ目は、要件定義で採用理由と保守・移行の出口を決めることです。設計では代替DBへの交換余地を残し、移行時には件数と業務結果の照合まで見通しておく必要があります。

Apache Derbyのシステム開発にかかる費用相場とコストの内訳

対象業務が広がるほど、示される費用範囲も上がります。

DerbyはOSSのため、ライセンスの購入費が大きくかからないケースが多いです。一方で、開発費はDBの価格ではなく、人件費・要件定義・設計によって大きく決まります。ほかに、次の作業も開発費に含まれます。

実装
移行
テスト
運用設計

ここに示す金額は、Derby公式の価格表ではなく、2026年の一般的な業務システム相場とJava/JDBCの工程から推定した目安です。

▶ 詳細はこちら：Apache Derbyのシステム開発の見積相場や費用/コスト/値段について

規模別の初期費用と開発期間

2026年1月公開の相場では、小規模スクラッチ開発は100万〜300万円で3〜6か月です（出典: ノーコード総合研究所「業務システム開発の費用相場」、2026年）。同資料では、中規模が300万〜800万円で6〜12か月、中〜大規模が800万円〜数千万円で12か月以上です。

技術検証・小規模社内ツール：50万〜150万円です。
画面・認証・帳票を含む小規模業務システム：150万〜500万円です。
複数業務や外部連携を含む部門システム：500万〜1,500万円です。
既存Derbyからの移行：300万〜1,200万円程度が目安です。

工数は画面数、権限、外部連携、データ量によって変わります。さらに、移行対象期間、性能要件、停止可能時間も工数を左右します。

既存DBへ接続するPoCは、短期間で済む場合もあります。ただし、10年分の履歴を扱う場合や、複数システムと日次で連携する場合、休日に切替演習を行う場合には、調査と検証の比重が高まります。

ランニングコストとTCO

Derby自体の料金だけで見積もらず、インフラ費と退役後の保守作業も含めます。

小規模クラウド：サーバー・ストレージ・バックアップ・ログ保管・監視を含めて、月額5万〜30万円程度です。
高い運用要件：冗長化・24時間監視・複数環境・厳格なログ保管を求めると、月額30万〜100万円以上になる場合があります。
費用の範囲：上記はインフラ費と運用体制の目安で、Derbyの保守料金ではありません。
退役後の作業：互換性・脆弱性の影響・JDK更新の試験・代替DBのPoCも見込みます。
TCO：3〜5年の運用費・障害対応費・移行準備費を合算します。

見積書で「OSSなので無料」という項目を見たら、それだけで判断せず、担当者・作業時間・対象環境・担当テストを確かめます。

ポイント

開発費は規模と移行の有無で幅が出るため、退役後の保守作業も含めて見積もることが大切です。3〜5年のTCOで比べると、費用の差が見えやすくなります。

Apache Derbyのシステムで必要なセキュリティと運用設計

Network Serverは、設定を整えてはじめて安全に使えます。公式文書は、初期設定の通信が平文であること、権限が広いこと、テーブルが無制限に増大し得ることを注意点に挙げています（出典: Apache Derby「Vulnerabilities of unsecured databases」、10.17）。

また、接続の試行やSQLがCPUを消費する可能性も示されています。機密情報を扱うほど、運用設計の重要性は高まります。

通信・認証・権限の最小化

接続元は業務サーバーや許可した端末に限り、DBポートはインターネットへ直接公開しません。通信はTLSなどの暗号化を検討し、認証情報はソースコードに埋め込まず、秘密情報の保管場所と更新手順を分けておきます。さらに、アプリ接続ユーザー、運用管理者、参照専用ユーザーを分け、通常の処理では管理者権限を使わないようにします。

バックアップ・監視・復旧の実測

復元にかかる時間、日常の監視、更新時の影響を、あらかじめ確かめておきます。

復元確認：別環境で復元し、業務再開まで何分かかるか測ります。
保管方法：日次で足りるか、更新量に応じて差分やログも保管するか、世代数を決めます。
監視項目：ストレージ残量・DB増加率・CPU・メモリ・接続数・エラー・バックアップ成否を監視します。
通知：しきい値を超えたときの通知先と対応者を定めます。
継続困難時：自社で修正や検証を続けられない場合は、短期の延命と同時に、期限付きの移行計画と予算を承認します。

退役後も使い続ける場合は、公開されている脆弱性情報に加えて、JDK・OS・コンテナ・周辺ライブラリの更新による影響を定期的に確認します。

継続利用・移行・再構築の判断方法

調査と小規模検証を経てから、移行と並行稼働へ進みます。

Derbyを継続するか移行するかは、技術者の好みではなく、業務への影響と将来の費用で決めます。判断するには、新規開発か既存の保守か、外部公開や機密データがあるか、必要なJDKへ更新できるかを確認します。

あわせて、停止や障害を自社で受け止められるかと、代替DBのPoCで業務結果が一致するかも調べます。この順に確かめると、短期の互換性と長期の保守性を分けて考えやすくなります。

新規システムでの代替DBの優先

明確な採用理由がなければ、保守とセキュリティ対応が続くRDBやマネージドDBを優先します。Java組み込みだけを理由にすると、JDK更新や担当者の交代が事業継続のリスクになるおそれがあります。

Derbyを使う場合は、採用期間・担当者・脆弱性対応・移行先候補・移行開始条件を設計書に明記します。

既存システムの期限付き延命と段階移行

既存環境では、全面刷新を行う前に段階移行を検討します。

現行の調査と、代替DBの小規模なPoCを行います。
データ移行とアプリ改修を進めて、並行稼働させます。
切替後に件数・業務結果・性能・障害復旧・運用手順を確認します。

読み取り処理や参照画面を先に移し、更新処理や外部連携は後から移す方法もあります。

インターネット接続がある場合や、個人情報を扱う場合、復旧手段がない場合、JDK更新を妨げている場合、担当者が一人だけの場合、復元が未検証の場合は、移行の優先度を高めます。一方で、短期で廃止する予定があり、外部接続がなく、復旧手順を検証済みであれば、期限と予算を定めて一時的に継続する選択肢もあります。

ポイント

継続か移行かは、業務への影響と将来の費用で決めます。新規開発では代替DBを第一候補にし、既存システムは期限を決めて延命したうえで段階的に移し替えます。

Apache Derbyのシステム開発会社・ベンダーの選び方

Derbyのシステム開発会社は、「Derbyに詳しい」という表示だけでなく、調査から移行後の保守まで計画できるかで選びます。

候補の会社には、Java/JDBC・SQLの差分・移行・サーバー運用・セキュリティ・切替後の保守の進め方を示してもらいます。専用のサポートを公開していない事業者もあるため、実績と責任範囲も提案の時点で尋ねておきます。

Java・DB移行の調査力

Derbyの版・JDK・DBファイル・ソース・ログ・外部連携の一覧を候補の会社に渡し、現行構成をどう調べるかを聞きます。予約語・日付・LOB・採番の差分について、確認テストを説明できるかを見ます。さらに、トランザクション・文字コード・例外処理の差分と確認テストも見ます。

サンプルデータによる有償の技術検証を本開発の前に行うと、見積もりの精度を高めやすくなります。

提案内容と見積もりの同条件での比較

複数の会社に同じRFPを渡し、継続利用・短期延命・代替DBへの段階移行の3案を、同じ粒度で出してもらいます。見積もりは、現行調査から保守まで工程ごとに示してもらい、前提・対象外・追加費用の条件を明記するよう求めます。価格だけでなく、運用負担と3〜5年のTCOも比べます。

納品物・保守・責任範囲の契約前確認

契約の前に、納品物と退役後の保守責任を具体的に決めておきます。

納品物：設計書・ソース・DB定義・移行スクリプト・テスト結果・復元と障害対応の手順を含めます。
運用設定：監視設定を納品物に含め、脆弱性調査・回避策・緊急パッチの担当について合意しておきます。
責任範囲：代替DBへの切替判断・月次と四半期のレビュー・連絡時間帯・復旧目標・再委託の範囲を決めます。

▶ 詳細はこちら：Apache Derbyのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：Apache Derbyのシステム開発の発注/外注/依頼/委託方法について

ポイント

開発会社は、「Derbyに詳しい」という表示ではなく、調査から移行後の保守まで計画できるかで選びます。提案は同じ条件で比べ、責任範囲も契約前に詰めておきます。

よくある質問（FAQ）

Derbyの検討でよく質問される内容を取り上げ、要件定義や見積もりで確認したい点を添えます。

Apache Derbyは2026年も使えますか？

既存の配布物を使えば動かすことはできますが、2026年時点では新規開発もバグ修正も終了しています。

新規に採用する場合は、脆弱性対応・JDK更新・障害復旧・移行費を含めて代替DBと比べます。継続して使う場合も、期限と移行先を決めておきます。

EmbeddedとNetwork Serverはどちらを選べばよいですか？

単一のJavaアプリ内で使うならEmbedded、複数のクライアントで共有するならNetwork Serverが候補になります。後者の場合は、認証・暗号化・接続元の制限・バックアップ・監視も設計します。

利用者の人数よりも、同時接続・可用性・復旧目標・外部公開の有無で判断します。

Apache Derbyのシステム開発費用はどのくらいですか？

目安は、技術検証が50万〜150万円、小規模業務システムが150万〜500万円です。複数業務や外部連携を含む部門システムは500万〜1,500万円、既存Derbyからの移行は300万〜1,200万円程度です。

費用は、画面数・データ量・外部連携によって大きく変わります。ほかにも、次の項目が費用を左右します。

移行期間
性能と可用性
テスト範囲

発注側は、工程ごとの人日と対象外の作業を、見積もりで確かめます。

Derbyから別のデータベースへ移行する際の注意点は何ですか？

SQLだけでなく、型・予約語・NULL・日付・採番・LOBを確認します。分離レベル・例外コード・インデックス・文字コードも確認の対象です。件数と業務結果を照合したうえで、差分同期・性能・障害復旧・復元・切替・ロールバックをリハーサルします。

アプリ改修とデータ移行を別々に考えず、業務シナリオ単位で受け入れテストを行います。

まとめ

Derbyは純Java・JDBCの軽量な組み込みDBとして、開発環境や限定的な業務に使われてきました。2025年10月10日に開発とバグ修正が終わったため、2026年は保守リスクを含めたTCOで評価することが求められます。

判断の要点

新規開発では、保守が続く代替DBを優先します。Derbyを採用する場合は、理由と移行期限を記録します。

既存環境では、構成とJDKとの互換性を確かめます。さらに、機密データや外部公開の有無、復元、性能、障害対応体制も見ます。

移行は、現行調査・技術検証・データ照合・業務テスト・切替リハーサルの順に進めます。

最初に行うべきこと

判断の前に、必要な現行情報を集めておき、案を比較してベンダーへ伝えます。

Derbyの版・JDK・接続方式・データ量・利用者数・外部連携・バックアップと復元の実績を一覧にします。
継続・短期延命・移行の3案を同じ条件で比べ、3〜5年の運用費と移行費も含めて決めます。
ベンダーに現行資料とサンプルデータを渡し、調査・テスト・納品物・保守責任を明確に伝えます。

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
 ・スクラッチシステム開発の完全ガイドブック
 ・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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