H2 Databaseのシステムを外注するには、要件を整理してから委託先と契約を選び、開発・テスト・移行・保守の順に進めます。この順番で決めていくと、業務要件に合った運用につながります。
▼全体ガイドの記事
・H2 Databaseのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
H2 Databaseのシステムを外注する前の全体像
H2 Databaseのシステムとは、データ保存層にH2を使うJava業務システムなどを指します。Spring BootなどのWebシステムでは、H2を開発・テスト用のDBとして使う場合もあります。
発注時には、発注者がH2の採用に加えて、利用業務、求める可用性、セキュリティを先に決めておきます。そのうえで、画面や業務ロジック、認証、帳票の設計・開発が必要です。外部連携、バックアップ、監視なども、あわせて設計する対象になります。
H2のライセンス費用とシステム開発費の違い
ライセンスの扱いと見積もりの区分は、次の4点を押さえておくと整理しやすくなります。
- ライセンス：MPL 2.0またはEPL 1.0のデュアルライセンスです。
- 商用利用：組み込みを含む無償利用の選択肢があります（出典: H2 Database公式License、2026年確認）。
- 改変・再配布：ライセンス表示と免責表示の扱い。
- 見積区分：H2のライセンス費とシステム開発費を、分けて示してもらいます。
ライセンス料が0円でも、人件費はかかります。要件定義やDB設計、Java実装、テストから移行、運用設計まで、工程ごとに人の作業が発生するためです。
本番DBとテストDBの使い分け
H2の強みは、インメモリ型ならテストを高速化しやすいことです。組み込み型なら、小規模な配布アプリや閉域の社内ツールを構成できます。
複数拠点からの大量同時接続や厳格な可用性が求められる基幹系では、PostgreSQLやMySQLを本番DBにする設計も有力です。複雑なDB固有機能や災害対策が必要なときも、この選択肢は検討の対象になります。H2をテスト用に限定する場合もあります。
H2の互換モードを使っても、本番DBと完全に一致するとは限りません。そのため、本番と同じDBを使う結合テストを委託範囲に含めておきます。
H2 Databaseのシステムで選べる発注形態
発注形態には4つの選択肢があります。パッケージ導入とクラウドサービス、スクラッチ開発、既存システムの改修です。
H2はDBエンジンの一つで、クラウドかオンプレミスか、パッケージか自社開発かは、H2とは別に決めます。発注形態は、業務の独自性とデータの重要度を基準に、納期や社内の保守要員と並べて比べます。
標準機能で足りる場合のパッケージ・クラウド
業務フローを標準機能に合わせられる場合、パッケージやクラウドが候補になります。初期開発を小さくでき、バックアップや監視をサービス側に任せられることもあります。
H2をJavaアプリに同梱することやオフラインで動かすことが採用理由なら、一般的なSaaSでは解決できない場合があります。そのため、カスタマイズやデータ連携、月額費、解約時のデータ返却費を、契約前に確かめます。
独自業務や既存資産がある場合のスクラッチ開発・改修
独自の承認経路や複雑な料金計算、現場ごとの帳票がある場合や、既存Java資産との連携がある場合は、スクラッチ開発や既存システムの改修が適しています。
H2を組み込みDBにする場合も、データモデルや排他制御、認証認可の設計は欠かせません。ログやバックアップ復元についても、設計が必要です。
既存H2システムの保守を外注するときは、資料を渡してから調査見積もりを依頼します。渡す資料は、ソースコードやDDL、接続設定、SQL初期化です。バッチやバックアップ手順、障害履歴も、あわせて渡します。
発注前のRFPと要件整理の決定事項
RFPは提案依頼書で、発注者の課題や実現したい業務、提案と契約の手続きを、候補会社へ同じ条件で伝える資料です。
IPAの要件定義解説では、背景や目的、求めることに加えて、業務フローや要件一覧を補足資料にする考え方が示されています。課題一覧や現行システム構成図も、補足資料として添えられます。こうした資料を添えると、短いRFPでも見積もりの前提を揃えられます。
業務要件と利用規模の数値整理
最初に、業務課題や利用部門、利用者の役割を整理します。そのうえで、現行手順や承認者、必要な画面・帳票・通知を洗い出します。
次に、登録データの種類と件数、年間増加量を記載します。同時利用者数やピーク時間帯、検索条件、保存期間も、書き添えます。
数量を「多い」「大量」などの言葉で済ませず、通常時とピーク時の人数を分けて書きます。そうすると、DB設計や性能試験の前提が揃います。
非機能要件とH2固有の条件の明記
RFPには、非機能要件とH2固有の条件を次のとおり書きます。
- 可用性：稼働時間、許容停止時間、RTO（復旧目標時間）、RPO（復旧時点目標）
- 運用・安全性：バックアップ世代数、監視時間、性能目標、アクセス権限、監査ログ、個人情報の暗号化
- H2の利用モード：インメモリ、ファイル、組み込み、サーバー、混在のいずれか
- 開発環境と移行：H2・Java・Spring Boot各版、JDBC・JPA・Hibernateの採用、将来の移行方針
なお、H2公式のFeaturesでは、AESによるファイル暗号化やSSL、ユーザーとロールなども案内されています。
機能があっても、それだけで安全な運用が保たれるとは限りません。そのため、復元や同時更新、プロセス異常の試験に加えて、バージョンアップやSQL互換性の確認も指定します。
準委任・請負・多段階契約の使い分け
契約形態は、契約書の名称だけで判断せず、作業の不確実性と成果物の明確さを見て決めます。
契約書では、業務範囲や発注者の協力義務、検収条件、仕様変更の扱いを確認します。知的財産権や再委託、秘密保持のほか、障害対応や途中解約の条件も、契約前に見ておきます。法務判断が必要な場合は、専門家にも確認します。
要件定義や調査に向く準委任契約
業務ヒアリングや現行H2システムの調査、データ移行の可否確認は、開始時に完成形を決めにくい作業です。技術検証や要件定義も、完成形を先に固定しにくい作業です。こうした作業には、一定期間の作業と専門家の稼働を委託する準委任契約が候補になります。
準委任では、作業時間だけでなく成果物も合意しておきます。調査報告書や要件定義書、課題一覧を成果物に含めるほか、概算見積もりや次工程の判断材料も合意対象にします。
仕様と検収条件が決まった開発に向く請負契約
画面一覧やデータ項目、API仕様が固まり、成果物を特定できる段階では、請負契約が候補になります。テスト仕様や納期、受入基準も含めて固まっていることが条件です。
納品物には、要件定義書、設計書、ソースコードを明記します。テスト結果や操作手順、バックアップ・復元手順、ライセンス一覧も、あわせて書き出してもらいます。
動作確認だけを納品の基準にしないよう、範囲を契約に書いておきます。また、検収期間や不具合の扱い、仕様変更時の再見積もりも、契約前に確認しておきます。
不確実性が高い案件の多段階契約
H2から別DBへの移行や、古いJava資産の刷新、複数部門の業務統合では、初期の段階で最終仕様を決められないことがあります。そのため、企画・要件定義、外部設計、開発・テストを分けて契約し、成果を確認してから次の契約へ進む方法が有効です。
IPAの「システム開発の健全化に向けて」では、要件定義や外部設計を準委任、ソフトウェア開発を請負とする例が示されています。情報が増えるにつれて、見積もりの精度を上げていく考え方です。
H2 Databaseのシステム発注費用・相場と内訳
H2 Database本体は無償で利用できます。一方で、発注費用は要件や画面数、連携数によって変わり、データ移行やセキュリティ、保守時間でも差が出ます。
ここで示す金額は、H2固有の公的な価格表ではありません。業務システム一般の相場と公開された費用例をもとにした、比較用のレンジです。正確な金額は、要件定義のあとに再見積もりを受けて確かめます。
用途別の初期費用の幅：20万円から1億5,000万円超まで
用途別の初期費用と期間は、次の比較レンジを起点に考えます。いずれも、H2だけでなくシステム全体の推定です。
- 検証・小規模PoC：20万〜100万円程度、2〜6週間
- 社内の小規模業務システム：300万〜800万円程度、2〜4か月
- 部門横断の中規模Web業務システム：800万〜3,000万円程度、4〜10か月
- 重要業務や既存システム連携：3,000万〜1億5,000万円超、8か月〜2年程度
金額の出典は、業務システム全般の公開Q&Aとリサーチノートです（2026年確認）。期間や費用は、データ移行や現場テスト、法令対応、24時間監視の有無で変わります。
発注ナビに掲載された株式会社ムクイルの業務システム刷新例は、合計500万円です。この金額には、要件定義・基本設計や詳細設計、製造が含まれます。さらに、クラウド環境構築や各種テスト、移行・操作説明も含みます（出典: 発注ナビ「H2 Databaseに対応するシステム開発会社一覧」、2026年確認）。
この事例が、H2を採用した案件かどうかは確認できません。そのため、この金額はH2のライセンス費ではなく、小〜中規模業務システムの比較材料として扱います。
見積書の工程費と運用費の分け方
工程別の目安は次のとおりです。ただし、比率は案件ごとの参考値です。
- 要件定義・基本設計：要件定義10〜15%、基本設計15〜20%
- 詳細設計・開発：詳細設計10〜15%、開発・単体テスト30〜40%
- テスト・移行：結合・総合テスト15〜20%、移行・導入5〜10%
画面や連携が少ないPoCでは、要件定義の比重が上がります。一方で、既存データが多い案件では、移行とテストの比重が上がります。
見積書は、人月単価だけでなく、各工程に何人月使うかで比べます。
保守費は、初期開発費の年15〜20%程度が一般的な目安です。たとえば500万円の開発であれば、年75万〜100万円、月6万2,500円〜8万3,000円程度が起点になります（出典: 業務システム全般の公開Q&Aおよびリサーチノート、2026年確認）。ただし、これはH2公式の保守価格ではなく、業務システム保守の比較用の目安です。
保守の内容は、平日営業時間内の問い合わせや障害一次対応、監視を分けて示してもらいます。バックアップ確認や脆弱性対応、月次改修枠、24時間365日のSLAも項目ごとに分けると、見積差を比べやすくなります。
H2 Databaseの委託先選定と見積比較のポイント
候補の会社を選ぶときは、「H2 Database対応」と書かれているかを入り口にします。ただし、その記載だけでは発注先として十分とはいえません。加えて、Java・Spring Bootの実装力から運用保守まで、一つの計画として説明できるかを見ます。
要件定義やクラウド・ネットワークの対応状況に加えて、データ移行やセキュリティ、テストも確かめます。そのうえで、候補会社に同じRFPを渡し、見積もりの前提と除外項目を揃えて比較します。
H2の利用実績と技術検証の確認項目
候補会社には、H2の利用実績と技術検証について、次の点を質問します。
- 利用実績：本番・テストのどちらで使ったか、H2の対応バージョン、Java・Spring Boot・JPAの構成
- 利用規模と運用：同時接続数、データ量、障害復旧の経験
- 技術検証：SQL差異の検証、Testcontainersなどを使う結合テスト、移行リハーサルの回数
実績を開示できない会社もあります。その場合は、検証方法を説明できるかどうかで、技術力を見極めます。
H2公式では、敵対的な環境は想定しておらず、TCPサーバーを信頼できない接続元に公開しないよう案内しています。外部から接続する場合は、localhostや制限された閉域網に加えて、SSLと強い認証情報を組み合わせます。
Spring Boot公式は、H2 Consoleを開発用途としたうえで、本番では有効化しないよう注意しています。この点の説明があいまいな会社は、価格が安くても慎重に評価します。
前提条件と抜け漏れの比較
見積もりを比べるときは、工程ごとの作業と、必要な費用がどこまで含まれているかを見ます。
- 工程：要件定義、基本・詳細設計、開発、単体・結合・総合テスト、移行、教育、リリース支援、保守
- 環境・ツール：H2のJAR、クラウド、開発環境、監視、バックアップストレージ、SSL証明書、脆弱性診断、移行ツール
- 比較条件：提案の具体性、発注者の作業量、担当者固定、再委託、成果物、変更単価、保守時間、障害連絡経路
見積額が極端に安い場合は、テストや移行、文書、リリース後の不具合対応が除外されていないかを、まず見ます。
要件が未確定なのに確定額を強く約束する提案より、未確定事項と再見積もりの条件を示す提案のほうが、追加費用を管理しやすい場合があります。
発注からリリース・保守までの進め方
発注後は、要件定義と設計から始まり、開発、テスト、移行を経て、リリースと保守へ進みます。H2を採用するかは、要件定義と技術検証の段階で決めます。そのうえで、本番利用として妥当かを、その後も確かめます。
発注者側にも、業務担当者と意思決定者を置いておきます。さらに、レビューと受入テストを、あらかじめ予定に組み込みます。
要件定義と設計でのH2の責任範囲
要件定義では、業務フローや機能に加えて、データの正確性や同時更新の扱いを決めます。さらに、トランザクション境界や検索性能、保存期間、削除・訂正権限も定めます。
設計では、テーブルやインデックス、制約、接続プールを決めます。あわせて、トランザクションやログ、バックアップと復元の仕組みも定義します。
暗号化やネットワーク分離も定義します。H2ファイルのバックアップを取るだけでなく、復元後にアプリが正常に動くところまで検証します。
テスト・移行・保守の発注範囲
次の試験と確認は、発注範囲に含めておきます。
- テスト：機能、権限、同時更新、異常系、性能、脆弱性、バックアップ復元、電源断・プロセス異常
- DB差異：別DBへの移行時の整合性（開発H2・本番PostgreSQLなら、本番DBでの結合テスト）
- 移行データ：件数、主キー・外部キー、文字コード、日付・小数、NULL、タイムゾーン、履歴データ
リリース後は、監視項目やバックアップ結果、ログ保管を運用手順に書きます。障害連絡や脆弱性対応、H2・Javaの更新方針も、運用手順に含めます。
記事の執筆時点で公式リリースに掲載されているH2 2.4.240は、2025年9月22日の公開です（出典: H2 Database公式GitHub Releases、2026年確認）。採用時には、最新安定版をJava・ORM・Spring Bootとの組み合わせで検証します。無条件に最新版へ上げず、検証を経てから切り替える運用にします。
H2 Databaseのシステム発注でよくある質問
発注時は、費用だけでなく、本番利用の可否や技術者の経験、契約後の責任分界も確かめておきます。よくある質問に、順に答えます。
H2 Databaseは本番環境で使えますか？
小規模で単一プロセスの構成や、閉域・配布型のシステムなら、要件を満たせば本番利用を検討できます。
H2公式は、信頼できない接続元への公開を避けるよう案内しています。また、H2 Consoleも開発用途を前提としています。
複数拠点や大量同時接続、高可用性が必要なとき、あるいは厳格な監査や災害対策が求められるときは、本番DBにPostgreSQLなどを採用し、H2をテスト専用にする構成も比べます。
H2 Databaseのシステム開発は無料で依頼できますか？
H2のライセンス費が無償でも、開発には費用がかかります。要件定義や設計、Java開発、テストには人手と費用がかかります。移行やインフラ、保守にも、費用が必要です。
PoCは20万〜100万円程度、社内向けの小規模業務システムは300万〜800万円程度といった具合に、用途と範囲に応じて相談します。確定した金額は、要件定義のあとに確かめます。
RFPには何を書けば見積もりが比較しやすくなりますか？
まず、目的や対象業務、利用者を書きます。そのうえで、画面・帳票や外部連携、データ件数、同時接続数を記載します。H2の利用モードとJava・Spring Bootのバージョンも、あわせて書きます。
バックアップやRTO・RPO、セキュリティに加えて、移行先と保守時間も記載します。現行資料やサンプルデータがあれば添付します。さらに、成果物や前提、除外項目、追加費用の条件についても、回答してもらいます。
IPAの要件定義資料にある業務フローや課題一覧の考え方も、参考になります。
既存のH2 Databaseシステムの保守や移行も外注できますか？
外注はできます。ただし、先に既存システムを調査する契約が一般的です。
その際は、ソースコードやH2ファイル、DDL、SQLを受け取ります。接続設定やバッチ、運用手順、障害履歴も、確認の対象にします。
- 見積もりの前提：データ件数と依存関係を確認し、保守や移行の見積もりに反映する
- 差異の検証：H2からPostgreSQLなどへ移す場合は、SQLの方言や型、NULL、日付・文字コードの違いを検証する
- 動作の違い：インデックスやトランザクションの違いも、あわせて確かめる
- 移行の進め方：リハーサルと切り戻し手順まで定めておく
まとめ
発注前の本番要件とH2の役割
H2を本番DBにするか、テスト専用にするか、将来PostgreSQLなどへ移行するかによって、設計・試験・保守の進め方が変わります。
発注者が業務目的や利用規模を整理し、データの重要度やRTO・RPOを決めてから委託先へ相談すると、過不足の少ない提案を受けられます。
見積書と契約書での責任分界
見積額と納品後の担当範囲を示し、どこまでを誰が受け持つかを決めます。
- 見積書：H2ライセンス、開発、テスト、移行、クラウド、監視、保守を、別々の項目で示す
- 契約書：成果物、検収、仕様変更、障害対応、知的財産権、再委託の取り決め
- 運用分担：運用開始後の担当範囲を合意して、長期的な利用を支える
費用項目を分けて比べると、追加費用や運用トラブルを抑えやすくなります。
H2 Databaseの発注では、業務目的と本番要件に合う構成かどうかを判断します。無償で利用できるかどうかは、その判断の一部にすぎません。
テストやPoCにはインメモリ型が向き、配布型や小規模な閉域システムには組み込み型が候補になります。複数プロセスや複数端末で使う場合は、サーバー構成を検討します。重要業務では、PostgreSQLなどを本番DBにする選択肢も含めます。
発注前には、データ量や同時利用者数、接続モードをRFPで揃えます。バックアップやRTO・RPO、移行先も、RFPに書き込みます。セキュリティや保守範囲のほか、Java・Spring Boot・DB移行・運用実績も確認します。
準委任、請負、多段階契約は工程の不確実性に合わせて使い分けます。
▼全体ガイドの記事
・H2 Databaseのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。