オニオンアーキテクチャのシステム開発は、業務ルールと例外を整理し、RFPと契約を合意してからMVPへ進めるのが基本の流れです。段階的に開発するため、長期保守や将来の変更に備えやすくなります。
発注で判断が分かれやすいのは、業務ごとの発注形態と、要件をどこまで固めてから契約するかです。
▼全体ガイドの記事
・オニオンアーキテクチャのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
オニオンアーキテクチャのシステムを外注する前に知るべき全体像
発注前に、長く守るべき業務ルールと、将来入れ替えられるようにしておく技術を分けて考えます。相談の場では、業務の内容と変更の頻度を伝えます。連携先や運用期間も示すと、開発会社が見積もりの前提をそろえやすくなります。
オニオンアーキテクチャのシステムの概要
オニオンアーキテクチャは、顧客や受注の業務ルールを中心に置く構成です。在庫や請求などの業務ルールも、この中心に置かれます。データベースやWebフレームワーク、外部APIなどの技術要素は、業務ルールの外側に分けます。
- Domain層：業務モデルと不変条件
- Application層：ユースケースと、内側で定義するインターフェース
- Infrastructure層・Presentation層：DBや外部サービス、画面やAPI
依存関係は外側から内側へ向かうため、業務ルールが特定のDBや画面に引きずられにくくなります。
Microsoft Learnは、クリーン、オニオン、ヘキサゴナルを近い考え方として説明しています。これらは依存関係逆転とDDDを土台にした考え方です（出典: Microsoft Learn「一般的なWebアプリケーションアーキテクチャ」、確認日2026年）。ただし、採用しただけで性能やセキュリティが自動的に高まるわけではありません。
発注に向くシステムと向かないシステムの違い
発注に向くかどうかは、業務ルールの複雑さと、利用期間、複数の機能からの再利用で判断します。
- 複雑な業務：複数の画面・API・バッチで同じ業務ロジックを使う
- 長期運用：数年から10年以上使う予定がある
- 技術変更：将来DBやクラウドを変更する可能性がある
受発注システムでは、承認条件や在庫引当をドメインモデルにまとめます。さらに、返品や締め処理も同じモデルに置くと、画面ごとに同じ処理を重ねて実装するのを防げます。
一方で、数週間で廃止する検証画面や単純なCRUD、既製SaaSで標準化できる業務では、過剰設計になりやすいです。なお、会計や人事をSaaSやパッケージに任せ、独自業務だけをカスタム開発する方法もあります。
オニオンアーキテクチャの発注形態の選び方
発注形態は、標準化できる業務と独自性の高い業務を切り分けてから決めます。システム全体をスクラッチにする必要はありません。
SaaS・パッケージ導入を中心とする構成
会計や人事給与、勤怠のように業界で共通する業務には、SaaSやパッケージを使います。そのうえで、必要な連携部分だけをアダプターとして開発します。
- 標準機能：パッケージに含まれる範囲
- 設定：設定で対応する範囲
- 追加開発：業務ルールをDomain層で管理できるか
パッケージのDBや画面に直接依存する実装が増えると、将来のバージョンアップの影響を受けやすくなります。
初期費用に加えて、月額利用料とユーザー数に応じた費用も比べます。さらに、API利用料やデータ保管料、解約時のデータ出力費用も比較に含めます。
SCSKの淺沼組の事例では、汎用業務にクラウドERPを、独自の営業・工事業務には別の基盤を使い分けました。また、ランニングコストは従来比で約3分の2に圧縮したとされています（出典: SCSK「淺沼組様 基幹業務システム刷新事例」、確認日2026年）。
スクラッチ開発とハイブリッドの構成
独自の承認や価格計算を中心に置く場合は、スクラッチ開発が候補になります。在庫引当や製造・工事の進捗を中心に置く場合も、同じ考え方で選べます。
- MVP：全社の基幹を一度に作らず、小さく始める進め方
- 段階移行：既存システムの刷新で、読み取り連携から始めて旧システムと新システムを一時的に並行稼働させる
- 腐敗防止層：旧データや旧仕様による汚染を防ぐ変換処理（RFPに記載）
- 構成の判断：モジュラーモノリスで始めるか、サービスを分割する条件を発注先から説明してもらう
MVP（Minimum Viable Product）では、最も重要な1業務を開発します。そのうえで、ドメインモデルとテストの妥当性を確かめてから範囲を広げます。
RFPと要件整理で発注先へ伝える内容
RFPは、機能一覧に加えて、発注先が同じ前提で見積もるための文書です。オニオンアーキテクチャを求める理由も、技術名ではなく業務上の目的で伝えます。
- 業務の前提：目的、対象業務、利用者、現状の課題
- 開発の条件：データ、外部連携、非機能要件、納期、予算の考え方
- 依頼内容：納品物と選定基準
たとえば、「業務ルールを長期的に保守したい」「DB変更の影響を抑えたい」のように理由を書くと、提案の質が上がりやすくなります。
業務イベントと例外の先行整理
業務は、「誰が、何をきっかけに、どの状態へ変えるか」の形で書き出します。受注業務の流れと例外を整理しておくと、ドメインモデルや受入条件を作るときの材料になります。
- 通常処理：見積作成、承認、受注確定、在庫引当、出荷、請求、返品
- 例外処理：キャンセル、分納、値引き、権限外操作、締め後の修正
用語の揺れも、あらかじめ解消しておきます。たとえば、「顧客」「取引先」「請求先」が同じものか別のものかを、業務責任者と決めておきます。
同じ言葉でも部門ごとに意味が違う場合は、Bounded Contextとして分けることを検討します。業務用語集と現行帳票をRFPに添付すると、開発会社が業務をどこまで理解したかを確かめられます。
RFPに含める成果物と非機能要件
納品後に手元へ残す成果物は、ひとつずつ個別に指定します。「設計書一式」や「システム一式」とだけ書くと、中身が分からなくなります。
- 設計とテスト：要件定義書、業務フロー、ドメインモデル、画面・API仕様、テスト計画と結果
- 移行と運用：データ移行計画、運用手順
- 開発資産：ソースコード、インフラ定義、設計判断の記録
内製化や別会社への保守切替を予定する場合は、リポジトリとCI/CD設定の受け渡し形式を確認します。IaCやテストデータについても、渡し方を決めておきます。
非機能要件には、利用者数や処理時間、稼働時間を含めます。バックアップや障害復旧目標、ログ保存期間も、あわせて書いておきます。
権限と監査の扱いも、RFPで指定します。データの所在地や脆弱性対応についても、あらかじめ定めておきます。
個人情報を扱う場合は、安全管理措置を確認するよう、個人情報保護委員会が示しています。その中身は、アクセス制御や認証、暗号化などです。ログ監視、脆弱性対策、従業者教育も含まれます（出典: 個人情報保護委員会「標的型メール攻撃や不正アクセス等に関する安全管理措置」、確認日2026年）。
契約形態の選び方（請負と準委任）
要件が固まる前のドメイン整理と、仕様が確定した後の開発とでは、適した契約が異なることがあります。そのため、工程ごとに責任と完了条件を明確にします。
成果物と完成条件を固めた後の請負契約
請負契約は、合意した成果物を完成させて納品する契約です。そのため、受入条件を定めやすい開発工程に向いています。
- 受入条件：画面、API、業務ルール、テスト結果
- 契約条件：検収期間、不具合の扱い、仕様変更の手続き、納期遅延時の協議方法
業務ルールが曖昧なまま請負にすると、開発会社がリスクを見込んで見積もりを高くしたり、後から変更費用が増えたりすることがあります。
その場合の選択肢として、要件定義を準委任で依頼し、設計・開発の一部を請負へ切り替える二段階の契約があります。
探索と継続改善の準委任契約
準委任契約は、一定の業務を専門家として遂行してもらう契約です。前提を更新しながら進める工程で使います。
- 調査・設計：業務ヒアリング、ドメインモデリング、技術検証、既存データ調査、アーキテクチャ判断
- 稼働条件：月ごとの稼働時間、役割、会議体、成果報告の方法
アジャイル開発やMVPでは、準委任で短いサイクルを回し、各スプリントの成果を受入確認する方法もあります。
予算上限と優先順位の決定者がないと、期間だけが伸びることがあります。追加作業の承認フローと品質基準も、事前に決めておきます。
契約には、ソースコードの権利や第三者ライブラリの扱いを含めます。再委託や情報管理、終了時の引き継ぎも、契約に入れておきます。
オニオンアーキテクチャのシステムの費用相場
オニオンアーキテクチャだけを対象にした公的な価格統計はありません。そのため、ここで示すのは、一般的な業務システムの2026年相場に、設計やテストなどの工数増を加えた推定レンジです。
実際の金額は、対象業務や利用者数、画面数で変わります。外部連携やデータ移行、非機能要件、発注先の体制によっても変わります。ここでの金額は、予算計画の初期目安として扱います。
規模別の初期費用と期間の目安
規模ごとの推定費用と期間は、含める機能や移行の範囲で異なります。
- 小規模PoC・1業務MVP：300万〜800万円程度、3〜5か月
- 中規模業務システム：800万〜2,000万円程度、6〜10か月
- 複数ドメインの基幹刷新：3,000万円〜1億円超、12〜24か月以上となる可能性
小規模の金額は、管理画面やAPI、DBを含む場合の目安です。認証や単体・結合テストも含みます。
中規模では、複数部署での利用や権限、帳票、外部APIを含みます。監査ログとデータ移行も含まれます。
大規模では、複数ドメインやERP・会計・物流との連携を含む場合があります。大量データや災害対策が加わることもあります。
SIA株式会社が示す2026年の一般相場は、小規模が100万〜300万円、中規模が500万〜1,000万円、大規模が1,000万円〜数千万円以上です。人月単価は、60万〜200万円程度と整理されています（出典: SIA「システム開発の費用・相場 2026年版」、確認日2026年）。
この記事の推定レンジは、一般相場に、ドメイン分析や抽象化の工数を加味したものです。マッピングやテスト設計の工数も、そこに含めています。ただし、オニオンアーキテクチャを採用しただけで金額が一律に決まるわけではありません。
見積書で分けて確認する設計・開発・運用の内訳
費用を比べるときは、工程と成果物ごとに内訳を確認します。
- 開発工程：要件定義・ドメイン設計、UI/API設計、Infrastructure実装、テスト
- 導入後：移行、教育、保守
- オニオン構成：Domain・Application設計、インターフェース、DBマッピング、単体テスト
これらが「開発一式」の中に埋もれている場合は、作業内容と成果物を開発会社に尋ねます。
運用費は、初期開発費の年15〜25％程度を目安に、別枠で持つ考え方もあります。この割合は一般的な予算の目安で、保守の範囲によって大きく異なります。
クラウド利用料や監視、バックアップは、月額分と都度見積もり分に分けて考えます。脆弱性対応から問い合わせ対応まで、同じ区分で扱います。
Cataly Designの2026年情報では、人件費は費用の60〜70％を占める目安です（出典: Cataly Design「業務システム開発の費用相場」、確認日2026年）。
単価だけでなく、人月と作業範囲も見ます。
委託先の選定と見積比較の見方
委託先は、過去の成果物と担当者の説明から、開発と運用、引き継ぎの力を確かめて選びます。アーキテクチャ名の知識は、その判断材料の一つです。
- 業務理解：業務をモデル化し、テストでルールを守る力
- 技術・運用：クラウドや外部連携を運用する力
- 引き継ぎ：納品後に発注側へ移管する力
候補は2〜3社程度に絞り、同じRFPで概算を依頼すれば、条件をそろえて比べられます。
技術力の確かめ方（質問と成果物）
提案時は、回答がユースケースやエンティティで説明されているかを確認します。リポジトリのインターフェースやアダプター、テスト例まで示せるかも見ます。
判断には、似た業界の画面より、業務フローや変更履歴を見ることが役立ちます。テストカバレッジや障害対応も確認します。保守体制と担当者の継続性も、あわせて見ます。
- 層と依存関係：業務ルールを置く層と、Domain層へDBやORMを漏らさない方法
- 連携と境界：外部APIの差し替えテスト、例外、トランザクション境界の扱い
- 分割方針：将来のマイクロサービス化の条件と、その説明の仕方
- 開発実績：テストカバレッジの考え方と、リリース後の保守体制
- 保守と手法：公式実績がなくても、DDD、依存関係逆転、テスト自動化を説明できれば候補になる
見積比較で前提と除外範囲をそろえること
見積もりの金額が安いからといって、優れているとは限りません。作業範囲の違いによって、金額に差が出ることがあります。
要件定義やテストが含まれているかを確認します。データ移行を誰が担当するか、保守・監視の契約、外部API仕様変更の扱いも確認します。
- 体制と工程：工程、担当人数、人月
- 成果と条件：成果物、前提条件、対象外、検収条件
- 費用：変更時の単価、保守費
見積もりを比べるときは、「この作業を外すと何ができなくなるか」「どの前提が変わると増額するか」と質問します。リスクの説明が具体的か、業務担当者が理解できるかも、選定の基準になります。
最終判断では、価格と技術だけでなく、体制や契約、引き継ぎも合わせて見ます。
よくある質問
技術を採用するかどうかや費用は、自社の業務変更と運用責任に結びつけて判断します。契約や委託先の選定も、同じ考え方で進めます。
オニオンアーキテクチャにすると必ず開発費用が高くなりますか？
必ず高くなるわけではありません。ドメイン分析やテストを丁寧に行う分、単純なCRUDより初期の工数が増える傾向があります。インターフェースやマッピングの作業も、その一部です。
将来の変更や長期保守を重視するシステムでは、初期費用だけでなく変更時の影響調査やテストのしやすさも比べます。
オニオンアーキテクチャならマイクロサービス化も必要ですか？
マイクロサービス化は必要ありません。オニオンアーキテクチャは、コードの依存関係と業務ロジックの分離を扱う考え方で、単一アプリケーションのモジュラーモノリスにも適用できます。
最初から分散トランザクションや複数のデータストア、サービス間監視を増やすより、境界が明確な部分だけを後から分割するほうが、発注費用と運用リスクを抑えやすくなります。
オニオンアーキテクチャの実績がない会社へ発注できますか？
発注はできます。確認するのは、名称の実績よりも、業務をモデル化して説明できるかです。依存関係逆転やテスト自動化、外部連携、保守移管についても、説明を求めます。
候補会社には、小さな業務を題材に設計方針や成果物を提示してもらいます。テスト戦略や変更時の影響範囲も示してもらい、業務担当者が理解できる説明かを評価します。
できれば、要件定義や技術検証を小さな契約で依頼し、本開発の前に相性を確かめます。
要件が曖昧な状態でも見積もりを取れますか？
概算見積もりは取れます。ただし、金額の幅は広くなり、前提条件やリスク費用も含んだ数字になります。
まずは、業務課題と対象範囲、利用者を整理します。主要な例外や外部連携、希望時期も書き出します。そのうえで、要件定義と本開発の概算を分けて依頼してください。
要件定義後に確定した範囲で開発見積もりを取り直すと、予算の精度を上げられます。
まとめ
発注時は、技術名だけでなく、業務ルールを中心に置く理由と、変更や保守で得たい効果をRFPに記します。標準的な業務はSaaSやパッケージ、独自の業務はカスタム開発とする切り分けも検討します。
費用は一般相場を基準にしたうえで、内訳で比べます。内訳には、ドメイン設計やテスト、連携が含まれます。データ移行や非機能要件も、内訳に入ります。
小規模PoCは300万〜800万円程度、中規模は800万〜2,000万円程度です。
大規模な基幹刷新は3,000万円〜1億円超の推定レンジで、確定額ではありません。2〜3社に同じRFPを渡し、前提と除外範囲をそろえて比べます。成果物や保守、権利、引き継ぎの条件も、同じ基準で比べます。
重要な1業務をMVPとして検証し、モジュラーモノリスから段階的に広げていくと、過剰設計や大規模な手戻りを避けやすくなります。
関係者が用語と受入条件を共有し、契約と運用責任まで合意しておけば、利点を発注後も生かせます。
▼全体ガイドの記事
・オニオンアーキテクチャのシステム開発の完全ガイド
▼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を創業。