オニオンアーキテクチャのシステム開発費用は、300万円から1億円超まで幅があります。
その差を生むのは、業務範囲、ドメインの複雑さ、連携・移行の範囲です。一業務に絞ったPoCなら300万〜800万円が目安になります。
▼全体ガイドの記事
・オニオンアーキテクチャのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
オニオンアーキテクチャの概要
オニオンアーキテクチャは、顧客・受注・請求・在庫などの業務ルールやドメインモデルを中心に置く設計思想です。データベース、Webフレームワーク、外部APIなどの技術の詳細は、外側へ分けて扱います。
費用を考えるときは、画面数だけでなく、業務ルールを整理する工数や、長く変更しやすい設計と検証にかかる工数も見ておく必要があります。
費用に影響するドメイン層の役割
層ごとの役割を分けておくと、業務ルールと技術の詳細のどちらを扱うかがはっきりします。
- Domain層：顧客の状態、受注条件、在庫引当、請求確定などの業務ルールを担う
- Application層：ユースケースや処理の流れを組み立てる
- Infrastructure層：データベース、メール、外部SaaSとの接続を担う
- Presentation層：画面やAPIの入力を受け取り、Application層へ渡す
層を分けるには、業務用語の整理、境界の設計、インターフェースやDTOの作成が必要になります。そのため、同じ画面数の単純なCRUDに比べて、初期費用が高くなる場合があります。一方で、データベースや外部サービスを替える際は、業務ルールまで書き換えるリスクを抑えられます。
採用すると費用対効果が出やすいシステム
採用を判断するときは、業務の複雑さ、運用期間、将来の変更の可能性を確認します。
- 複雑な業務：複数部署の受発注・在庫・会計や、承認・権限が複雑な業務
- 長期運用：長期運用する基幹システムや、複数サービスと連携するシステム
- 将来の変更：データベースやクラウドサービスを替える際、外側を交換できる設計が投資の保険になる
短期間だけ使う管理画面や、登録・一覧・更新だけの小さなツールでは、全層を厳密に作ると過剰設計になりがちです。そのため、小規模な機能から始め、変更の多い業務境界に設計を厚くすると、費用と品質の釣り合いを保てます。
オニオンアーキテクチャのシステム開発費用の相場
オニオンアーキテクチャだけを対象にした公的な価格統計は確認できていません。そこで、2026年の一般的な業務システムの相場に、ドメイン分析、テスト、連携、移行の工数を加えた予算の幅を示します。
画面数より業務上の分岐が費用を左右するため、見積もりでは機能数だけでなく、業務ルールの複雑さと非機能要件も確認してください。
小規模PoC・1業務は300万〜800万円
一業務に絞ったPoCは、対象の範囲と含める機能をそろえてから費用を見積もります。
- 費用と範囲：受注管理など一業務。管理画面、API、データベース、認証、単体・結合テスト込みで300万〜800万円程度
- 期間と条件：3〜5か月程度。既存データ移行や複雑な権限を含むと上側へ寄る
一般的な業務システムでは、単一業務のカスタムシステムの目安が100万〜500万円とされています（出典: Cataly Design「業務システム開発の費用相場」、2026年）。
オニオン構成でドメイン整理とテストを厚くする場合は、同じ機能範囲でも単純な画面開発より高めの予算を置いておくと、後から設計を削る事態を避けられます。
中規模業務システムは800万〜2,000万円
中規模の案件では、対象機能と進行期間をそろえて予算を組みます。
- 費用と範囲：複数部署の権限、帳票、承認、外部API、監査ログ、移行を含み800万〜2,000万円程度
- 期間と進め方：6〜10か月程度。要件定義とドメインモデリング後、優先度の高いユースケースから実装
なお、2026年版の相場情報では、複数業務を統合する基幹システムは1,000万〜3,000万円以上とされています（出典: Cataly Design「業務システム開発の費用相場」、2026年）。また、連携先が増える場合や旧システムと並行稼働する場合は、費用が3,000万円以上になる可能性もあります。
大規模・基幹刷新は3,000万円〜1億円超の範囲
対象は、受注・在庫・購買・会計など複数のドメインをまたぐ基幹刷新です。ERP、物流、決済、認証基盤との接続も含みます。
- 費用と範囲：大量データや高可用性まで求める基幹刷新は3,000万円〜1億円超のレンジ
- 期間と作業：12〜24か月以上の場合がある。現行調査、移行リハーサル、教育、並行稼働、障害対応計画を含む
2026年の相場情報では、人月単価は60万〜200万円程度とされ、スキルや地域によって変わります（出典: SIA「システム開発の費用・相場」、2026年）。
大規模案件では、PM、業務アーキテクト、上級SEの配置時期と人数が総額に直結します。開発者、テスト担当、インフラ担当も、人数と配置時期で総額が変わります。単価だけでなく、体制と工数の内訳も確認してください。
オニオンアーキテクチャの費用の内訳
業務ルールを中心に置く設計では、画面やAPI以外の作業も品質を支えます。そのため、見積書は一式にまとめず工程ごとに分けて、作業の抜けによる追加費用を防ぎます。
要件定義・ドメイン設計・アーキテクチャ設計
上流設計では、業務の境界と各層の責任を定め、その内容を成果物に残します。
- 境界の整理：業務イベント、用語、役割、権限、例外、状態遷移を洗い出し、Bounded Contextとユースケースを決める
- 層の設計：Domain層が保証する範囲、Application層の処理、Infrastructure層のアダプター配置を決める
- 成果物：業務フロー、用語集、画面とAPIの一覧、受入条件、依存関係図として残す
Microsoft Learnは、ドメイン駆動設計やクリーンアーキテクチャについて、データアクセスをカプセル化し、依存関係を内側の抽象へ向ける考え方を説明しています（出典: Microsoft Learn「アーキテクチャの原則」）。
業務の境界が曖昧なままでは、名称だけ採用しても費用対効果は出ません。見積もりには、設計担当者と、ワークショップ・レビューの回数を明記してもらいます。
実装・テスト・インフラ構築
実装、検証、基盤の費用は、作業範囲ごとに分けて確認します。
- 実装：ユースケース、エンティティ、値オブジェクト、リポジトリ抽象を作る
- 接続：データベース、API・画面、認証・認可、ログ、外部サービスとの接続
- テスト：単体、Application層のユースケース、Infrastructure層の統合、外部API契約、画面から業務処理までの検証
- 基盤：CI/CD、Docker、監視、バックアップ、障害通知、IaCを構築する
Domain層を技術から独立させるには、インターフェース、DTO、マッピングが必要になる場合があります。このため、単純なCRUDに比べて、コードとレビューの量が増えます。
変更の多いドメインルールにテストを集中させると、後の修正費を抑えられます。
データ移行・教育・保守運用
移行、利用者への支援、運用に必要な作業は、分けて見積もります。
- データ移行：抽出、名寄せ、変換、欠損確認、リハーサル、本番切替、旧システムとの照合を行う
- 変換設計：旧データと新Domainモデルが一対一でない場合、変換ルールの設計・検証費も見積もる
- 利用者支援：教育、操作マニュアル、問い合わせ窓口を用意し、リリース後の混乱を防ぐ
- 運用：クラウド利用料、監視、バックアップ、脆弱性・法改正・障害対応、追加開発の範囲を契約で定める
概算では、運用費を初期開発費の年15〜25％程度とみる方法があります。運用費は、24時間監視や高可用性、外部SaaSの利用量によって変わるため、固定費と従量費を分けて確認してください。
オニオンアーキテクチャの費用が変動する主な要因
同じ設計を採用しても、対象業務と品質要求が違えば費用は変わります。そのため、見積もりの差は単価だけでなく、どのリスクを工数に含めたかで比べます。
業務ルール・権限・例外処理の複雑さ
画面数より業務上の分岐が費用を左右します。受注では、取引先ごとの掛率、在庫引当の優先順位、承認金額の扱いが、モデルとテストを増やします。また、返品やキャンセル、締め処理、法改正対応も、業務ルールの分岐を増やします。
役職・部署・拠点・代理承認を組み合わせる権限設計も、画面の追加だけでは見えにくい工数です。
通常ケースに加えて、例外時に誰が何を戻せるか、確定後に修正できるか、監査で何を証明するかを、要件定義の段階で確認します。例外と不変条件を洗い出しておくと、必要な設計に予算を配分しやすくなります。
外部連携・データ移行・非機能要件
外部接続では、接続先の数と検証環境の条件が工数に影響します。
- 接続・検証：会計、販売、物流、決済、本人確認、メール、IdPとのAPI仕様、再送、タイムアウト、整合性、契約更新を確認する
- 調整：テスト環境がない、または相手企業との調整が必要な場合は、待ち時間と調整費も見込む
可用性や性能、バックアップ、災害対策は、費用を変える要件です。また、データ所在地や監査ログ、個人情報保護も、費用を左右します。
個人情報保護委員会は、安全管理措置として、アクセス制御や暗号化、被害の最小化、従業者教育などを示しています（出典: 個人情報保護委員会「安全管理措置」）。
可用性などの要件を後から付けると、設計のやり直しや移行の停止が起きることがあります。そのため、見積もりの前提に含めてください。
モジュラーモノリスとマイクロサービスの使い分け
オニオンの採用とマイクロサービス化は別々に判断し、分割する範囲に応じて費用を見積もります。
- モジュラーモノリス：まず境界と依存方向を整え、分散トランザクション、監視、デプロイ、データ整合性の費用を抑える
- 複数サービス：同時に作ると各サービスのインフラ、ログ、認証、障害対応、リリース手順が増える
- 将来の分割：DomainとApplicationの依存方向を守る設計へ予算を使うと、短期の開発費と長期の運用費を見通しやすい
オニオンアーキテクチャの開発費用を最適化する進め方
費用を抑えるには、設計を削るよりも、価値の低い範囲を作らないことが有効です。まず、業務の中心と将来変更が多い部分を見極めます。
標準化できる業務はSaaSやパッケージに任せ、競争力や独自ルールに関わる部分をカスタム開発します。
最重要の1業務によるMVPの作成
全社同時には作らず、効果が大きく、業務ルールを検証しやすい1業務を選びます。受注から出荷までを対象にする場合は、段階を追って確かめます。
- 用語、状態遷移、権限、例外、監査ログを整理する
- DomainとApplicationのテストを先に作る
- 利用者が試せるMVPを3〜5か月程度で検証する
検証の結果に応じて、後続機能の優先順位と必要な予算を見直します。PoCでは、画面の見栄えだけでなく、業務ルールの再現、外部連携の失敗時の復旧、既存データの変換を確かめます。そこで、受入条件と本番移行の仮説を先に置いておくと、技術検証だけで終わるPoCや、本開発での作り直しを減らせます。
SaaS・パッケージ・スクラッチの使い分け
標準化できる業務と独自性の高い業務を分け、方式ごとの費用条件を比べます。
- 標準業務：会計、人事、勤怠はSaaSやパッケージを使う。独自の受注ルール、商品構成、承認、顧客体験にはカスタム開発を適用する
- SaaS費用：初期無料〜数十万円、導入支援込み20万〜60万円程度に月額利用料が加わる場合がある。人数や連携数で総額が変わる
- パッケージ費用：ライセンス数十万〜数百万円程度から。設定、移行、連携、個別開発が加わる
- スクラッチ費用：数百万円から大規模では5,000万〜1億円超。5年間のライセンス、クラウド、保守、追加開発を含めて比べる
既存システムの段階移行
ビッグバン方式は、移行に失敗したときの影響が大きくなります。段階移行には並行稼働と照合の費用が加わりますが、全社停止や手戻りを抑えられ、重要業務の総コストの最適化につながります。
- 読み取り連携や一部業務から始め、旧・新システムを並行稼働させてデータを照合する
- 旧仕様を新モデルへ変換するアダプターを用意し、現行の癖をDomain層へ持ち込みにくくする
- 業務ごとに成功条件、戻し方、データの正本、問い合わせ窓口を決める
予算を削る対象と、削ってはいけない検証は、分けて考えてください。SCSKの淺沼組向け刷新事例では、標準業務と独自業務を分ける考え方などによって、ランニングコストを約3分の2に圧縮できる見込みが示されています（出典: SCSK「淺沼組様 基幹業務システム刷新事例」）。
この数字は、オニオンアーキテクチャ導入の効果そのものではありません。ただし、標準化と独自開発の境界を設計することは、運用費を見直すヒントになります。
オニオンアーキテクチャの見積もり・発注時のチェックポイント
見積もりは、総額の安さより前提条件と成果物がそろっているかで比べます。保守性やテスト性を目的にする場合は、その品質を確かめられる成果物と受入条件が必要です。
見積書の工程・成果物・前提条件での分け方
会社ごとに比べられるよう、作業範囲、成果物、追加費用につながる条件を、見積書で具体的に示してもらいます。
- 工程：要件定義、業務イベント、ドメイン・アプリ設計、UI・API、インフラ、テスト、移行、教育、保守を行単位にする
- 各行の記載：担当ロール、工数、期間、成果物、レビュー回数、対象外範囲を明記する
- 追加費用の条件：「外部連携は別途」「移行は概算」「性能要件は対象外」などの注記を確認する
- 見積もり前提：連携先、データ件数、同時利用者数、レスポンスタイム、稼働時間、バックアップ保持期間を確認し、未確定なら複数ケースで見積もる
開発会社に確認する技術と体制
技術は、名称だけでなく設計の進め方と引き継ぎ条件を確認して判断します。
- 設計とテスト：業務イベント・不変条件のモデル化、Domain層へのORM等の混入防止、ユースケースの検証方法を質問する
- 技術選択：C#・ASP.NET Core、Java・Spring Boot、Kotlin、TypeScript・NestJS、Goなどを比較する
- 担当体制：アーキテクトの要件定義参加、ワークショップの進行役、レビューと自動テストの担当を確認する
- 引き継ぎと契約：ソースコード等の納品、保守会社の変更、再委託、著作権の範囲を確認する
技術は、既存の人材や運用体制、採用のしやすさを踏まえて決めます。
契約と変更管理による追加費用の防止
要件定義と開発を固定価格で一括契約する場合でも、変更要求の扱いを明確にしておく必要があります。変更時の費用負担は、成果物や運用の引き継ぎ条件と合わせて定めておきます。
- 追加費用の範囲：業務ルール・連携仕様の変更、法改正、脆弱性対応、クラウド料金増加が契約内か別途か決める
- 変更手順：受付、影響分析、承認、見積もり、リリースの流れを合意し、予算の見通しを立てられるようにする
- 権利と引き継ぎ：知的財産権、再利用部品、第三者ライセンス、コード・設計書、アカウント、ログ、保守終了時の引き継ぎを確認する
ベンダーロックインに陥って将来の変更費用が高くなると、設計への投資を活かせなくなります。
よくある質問（FAQ）
最後に、費用相場を調べる方から寄せられやすい疑問に、順に回答します。金額を比べるだけでなく、採用目的と必要な範囲を合わせて考えるとよいでしょう。
オニオンアーキテクチャにすると開発費用は必ず高くなりますか？
必ず高くなるわけではありません。初期はドメイン設計、抽象化、テスト、マッピングの工数が増えやすい一方、複雑な業務を長期運用する場合は、変更や障害対応の手戻りを減らす効果が期待できます。
短命な小規模ツールでは、適用範囲を絞るほうが合理的です。
SaaSを使う場合もオニオンアーキテクチャは必要ですか？
すべてをカスタム開発する必要はありません。会計や人事など標準化できる業務はSaaSやパッケージに任せ、独自業務との境界にアダプターを置く構成が現実的です。
SaaSのAPI変更やサービス停止が業務ルールに直結しないよう、外部接続はInfrastructure側にまとめておくと、交換やテストがしやすくなります。
オニオンアーキテクチャを採用したらマイクロサービス化が必要ですか？
必要ではありません。まず1つのアプリケーション内で境界と依存方向を整理するモジュラーモノリスから始め、負荷、組織、リリース頻度などの理由が明確な境界だけを分割します。
最初から細かく分けると、インフラや監視、データ整合性、障害対応の費用が増えやすいからです。
見積もりで最低限確認すべき項目は何ですか？
要件定義、ドメイン設計、実装は、工程ごとに分けて見積もります。テスト、移行、教育は、各工程の成果物と対象外を確認します。インフラと保守も、成果物と対象外を工程ごとに確認します。
業務ルールの例外、外部連携、データ移行は、「別途」扱いになっていないかを確認します。また、権限、監査ログ、性能、バックアップ、脆弱性対応も、同じ観点で見ます。
3社程度から同じ前提で提案を受けて、金額だけでなく体制と契約条件を比べると、判断の根拠がはっきりします。
まとめ
開発費用の目安は、一業務のPoCで300万〜800万円、中規模業務システムで800万〜2,000万円、大規模・基幹刷新で3,000万円〜1億円超です。
この数字は、オニオン固有の定価や公的統計ではありません。2026年の一般的な相場に、設計、テスト、連携、移行、非機能要件の工数を加えたレンジです。
費用を適正化するには、最重要の1業務でMVPを検証し、標準化できる領域はSaaSやパッケージに任せます。そのうえで、独自ルールに設計とテストを集中させ、見積書では外部連携、移行、権限、監査ログ、保守、ソースコードの権利まで確認します。設計パターンを採用すること自体を目的にせず、将来の変更と運用を含む総コストで判断すると、失敗しにくい発注につながります。
▼全体ガイドの記事
・オニオンアーキテクチャのシステム開発の完全ガイド
▼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を創業。