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