オニオンアーキテクチャのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

オニオンアーキテクチャのシステム開発は、業務ルールを中心に据え、要件整理から定着までを段階的に進めることで、将来の変更に強い業務システムを実現する方法です。

しかし、「オニオンアーキテクチャで作りたい」と考えても、どの業務から始めるのか、SaaSやパッケージをどこまで使うのか、設計・テストにどの程度の費用をかけるのかは判断しにくいものです。この記事では、受発注や在庫管理のような業務システムを想定し、要件整理、開発方式の選定、設計・開発、テスト、稼働、定着の6フェーズに分けて、実務で使える進め方とチェックポイントを解説します。

▼全体ガイドの記事
・オニオンアーキテクチャのシステム開発の完全ガイド

オニオンアーキテクチャのシステムとは何ですか？全体像を理解する

オニオンアーキテクチャとは、顧客、受注、在庫、請求などの業務ルールを内側のDomain層に置き、データベース、Webフレームワーク、外部API、メールやキューなどの技術要素を外側へ分離する設計思想です。依存関係は外側から内側へ向かい、中心の業務ロジックがInfrastructureや画面の都合に引きずられない点が大きな特徴です。

Domain層には「出荷済みの受注はキャンセルできない」「与信枠を超えた受注は承認が必要」といった、業務上の不変条件を置きます。Application層には「受注を登録する」「在庫を引き当てる」「請求を発行する」といったユースケースを置き、処理の順序やトランザクションの境界を管理します。リポジトリや通知サービスは、この内側の層がインターフェースとして定義します。

Infrastructure層は、PostgreSQLやSQL Serverへの接続、ORM、外部の会計SaaS、メール、認証基盤、メッセージキューの具体的な実装を担当します。Presentation層はWeb画面、RESTやGraphQLのAPI、バッチ、CLIなどで、入力をユースケースへ渡し、返ってきた結果を画面やレスポンスに変換します。Microsoft Learnも、Application Coreを他のアプリケーション層に依存させず、依存関係逆転によってインフラストラクチャを切り離す考え方を説明しています（出典: Microsoft Learn「一般的なWebアプリケーションアーキテクチャ」、2026年確認）。

向いているのは、業務ルールが複雑で、数年から10年以上にわたり改修する業務システムです。受注経路が複数ある、部署ごとに権限や承認が異なる、外部サービスとの連携が多い、将来にデータベースやクラウドを変更する可能性がある、といった条件があれば、業務ロジックと技術詳細を分ける効果が出やすくなります。業務の中心を単体テストで検証できるため、画面やDBを変更する際にも影響範囲を確認しやすくなります。

一方、項目を登録して一覧表示するだけの短命なCRUDや、数週間で廃止する検証用ツールでは、層、DTO、マッピング、インターフェースを用意する初期工数が価値を上回る場合があります。オニオンアーキテクチャは性能やセキュリティを自動的に高める仕組みでもありません。対象業務の寿命、変更頻度、連携数、失敗時の損失を評価し、適用範囲を業務単位で決めることが重要です。

オニオンアーキテクチャのシステム開発の進め方

進め方の基本は、技術を先に決めるのではなく、業務上の判断と例外を整理し、検証可能な小さな単位から作ることです。ここでは、要件整理、選定、設計・開発、テスト、稼働、定着の6フェーズに分けます。各フェーズの終了条件を文書化しておくと、会議で決まったつもりの事項が後工程で膨らむリスクを抑えられます。

最初に、現場で起きている業務イベントを時系列に並べます。受注管理なら「見積を作成する」「受注を確定する」「在庫を引き当てる」「出荷する」「請求する」といった出来事を洗い出し、誰が、どの情報を使い、どの条件で次の状態へ進めるのかを確認します。「顧客」「取引先」「案件」など同じ言葉が異なる意味で使われていないかも確認し、用語集として残します。

成果物は、業務フロー、用語集、権限一覧、状態遷移、例外一覧、データ項目表、非機能要件です。特に「承認者が不在の場合」「在庫が不足した場合」「外部APIが停止した場合」「同じ注文を二重送信した場合」を先に挙げます。ここで業務部門の責任者がMust、Should、後回しにできる機能を合意できれば、最初のMVPを過大にせずに済みます。

次に、標準化できる業務と、競争力の源泉になる独自業務を分けます。会計、勤怠、人事など法改正や標準処理が多い領域はSaaSやパッケージを優先し、独自の受注判断、配車、在庫引き当て、見積計算などはオニオン構成のカスタム領域として検討します。すべてをスクラッチにすると柔軟性は増しますが、導入費用、テスト範囲、保守責任も増えます。

選定時は製品名だけでなく、APIの仕様、データのエクスポート可否、認証方式、監査ログ、SLA、障害時の連絡体制を確認します。外部サービスの仕様変更をInfrastructure層のアダプターに閉じ込められるか、契約終了時にデータを返却してもらえるかも重要です。大規模案件でも最初からマイクロサービスに分けず、境界を明確にしたモジュラーモノリスから開始し、分割の必要性が確認できた領域だけをサービス化すると判断しやすくなります。

設計では、まずDomain層のエンティティ、値オブジェクト、集約、ドメインサービスと不変条件を定義します。次にApplication層でユースケースとトランザクション境界を定め、リポジトリや通知のインターフェースを置きます。その後でInfrastructure層のDB実装や外部連携、Presentation層の画面やAPIを接続します。DBのテーブル構造をそのままDomainのモデルにしないことが、業務ルールを技術詳細から守るポイントです。

技術はASP.NET CoreとC#、JavaとSpring Boot、Kotlin、TypeScriptとNestJS、Goなどから、チームの経験、採用、運用体制を含めて決めます。ORMの型やアノテーションをDomain層へ持ち込まない、依存性注入で実装を差し替えられるようにする、APIの入出力DTOとドメインモデルを分ける、といったルールを設計書とコードレビュー基準に落とし込みます。1つの重要ユースケースを縦に通すスパイクを先に作ると、層の分け方を早く検証できます。

テストは最後にまとめて実施するのではなく、Domain層の単体テストを先に作ります。「与信枠を超えた受注は承認待ちになる」「出荷済みの受注はキャンセルできない」といったルールを、正常系、境界値、例外系で確認します。DBや外部APIをモックに置き換えれば、中心のロジックを高速に繰り返し検証できます。これはオニオンアーキテクチャを採用する代表的なメリットです。

続いて、Infrastructureとの統合テスト、APIの契約テスト、画面の受け入れテスト、移行データの照合、負荷試験、権限試験を実施します。テストケースは機能一覧から機械的に作るのではなく、要件整理で挙げた業務イベントと例外一覧に対応づけます。合格条件として、未解決の重大障害数、処理時間、データ照合率、バックアップからの復旧時間をあらかじめ合意しておくと、リリース判定が主観的になりません。

稼働前には、データ移行の対象、変換ルール、移行リハーサル、切り戻し条件を決めます。既存システムを一度に置き換えるのが難しい場合は、読み取り連携や一部の外部アプリから始め、旧システムと新システムを一定期間並行稼働させます。旧システムの用語やデータ形式が新しいDomainモデルへ混ざらないように、変換を担う腐敗防止層をアダプターとして置く方法も有効です。

本番移行の判定会議では、機能の完成度だけでなく、権限設定、監視、バックアップ、障害連絡、問い合わせ窓口、手作業の代替手順を確認します。NECの建設クラウド事例のように、標準業務に合わせたプロトタイプと、足りない業務を外部アプリで補う組み合わせは、全機能を一度に作り込まない現実的な選択肢です。移行後のデータ件数と金額を旧システムと照合し、現場責任者が受け入れ確認を終えてから切り替えます。

稼働して終わりにせず、利用率、入力漏れ、処理時間、差し戻し件数、問い合わせ内容を計測します。毎月または四半期ごとに業務部門と開発・運用チームが指標を確認し、ルールの変更、追加機能、マスタ整備、教育の課題を優先順位づけします。Domain層の業務ルールを変更する場合は、関連するユースケースとテストを同時に更新します。

運用契約では、クラウド利用料、監視、脆弱性対応、法改正対応、追加開発、障害対応を誰が担うかを分けて記載します。内製化を目指す場合は、設計書の説明会、ソースコード、IaC、テスト、リリース手順、ログの見方まで引き渡してもらいます。月次の定着会議で、ベンダーに依存せず自社で判断できる状態へ近づいているかを確認することが大切です。

オニオンアーキテクチャのシステム開発の費用相場とコストの内訳

オニオンアーキテクチャ単体の公的な価格統計はないため、以下は2026年時点の一般的な業務システム開発情報と、ドメイン分析・テスト・移行を含めた推定レンジです。開発会社の見積もりを保証する金額ではなく、予算を検討するための幅として扱います。業務ルールの複雑さ、連携数、データ移行、可用性、セキュリティ要件によって大きく変動します。

小規模PoCや1業務のMVPで、管理画面、API、DB、認証、単体・結合テストを含める場合は、300万〜800万円、期間は3〜5か月程度が推定レンジです。複数部署、権限、帳票、外部API、監査ログ、データ移行まで含む中規模業務システムは、800万〜2,000万円、6〜10か月程度が一つの目安です。複数ドメイン、ERP・会計・物流連携、大量データ、災害対策を含む基幹刷新は、3,000万円〜1億円超、12〜24か月以上の計画になる可能性があります。

このレンジは、オニオン固有の実績値ではなく、一般的な業務システム相場に上流設計と検証の工数を加味した推定です。SIA株式会社の2026年7月更新情報でも、受託開発費用は要件の複雑さ、体制、工程、技術要件など複数要素で決まり、単価だけで比較できないと整理されています（出典: SIA株式会社「受託開発の費用相場と9つの決定要素」、2026年）。したがって、安価な開発会社を一社だけ選ぶより、同じ要件書で複数社から内訳を取り、Domain設計やテストを削っていないかを確認する必要があります。

費用の内訳は、企画・要件整理、ドメインモデリング、UI・API設計、実装、インフラ構築、単体・統合・受け入れテスト、データ移行、教育、プロジェクト管理に分けます。オニオンアーキテクチャでは、中心の業務ルールを整理する時間、インターフェースを定義する時間、DTOやマッピングを検証する時間が必要になるため、単純な画面数だけで見積もると不足しやすくなります。

SaaSは初期費用が小さく、導入支援込みで数十万円規模から始められる場合がありますが、月額利用料、ユーザー数、オプション、連携費用が継続します。パッケージはライセンスや設定、個別開発が必要になり、スクラッチは数百万円から大規模では5,000万〜1億円超まで幅があります。運用費は、クラウド、監視、バックアップ、脆弱性対応、法改正対応を分けて、初期開発費とは別に計画します。SCSKの淺沼組事例では、標準的な業務をクラウドERP、独自業務を個別構築に分け、ランニングコストを約3分の2に圧縮したと公表されています（出典: SCSK「淺沼組様 基幹業務システム刷新事例」、2026年確認）。

見積もりを取る際のポイントとチェックリスト

オニオンアーキテクチャを採用する見積もりでは、「何画面作るか」だけでなく、「どの業務ルールをどの層で守るか」を確認します。見積書が一式表記だけだと、予算超過が起きたときに、要件変更なのか、初期見積もりの漏れなのか判断できません。次の項目をRFPや提案依頼書に含め、各社が同じ前提で回答できるようにします。

業務要件では、業務フロー、用語、状態、権限、承認、例外、帳票、外部連携、移行対象を明記します。非機能要件では、利用者数、ピーク時の同時実行、目標応答時間、稼働時間、バックアップ世代、復旧目標、監視、ログ保存期間、データ所在地を定めます。オニオンの適用範囲も、「受注と在庫のDomain・Applicationを対象にし、会計はSaaS連携とする」のように書くと、過剰な設計を防げます。

成果物は、ドメインモデル、アーキテクチャ方針、API仕様、DB設計、テスト計画と結果、移行設計、運用設計、ソースコード、IaC、教育資料まで列挙します。受け入れ条件には、重要ユースケースのテスト合格、移行データの照合、権限テスト、障害時の復旧手順確認を入れます。成果物の納品形式とレビュー回数まで決めると、納品後に使えない設計書が残る事態を防げます。

開発会社には、「オニオンを採用した実績がありますか」だけでなく、「業務ルールをどのようにDomainへ抽出しますか」「ORMをどの層に置きますか」「DBを変更するとき、どのテストで影響を確認しますか」と質問します。DDDやドメインモデリング、依存関係逆転、テスト自動化を、実案件の設計書やコードレビューの進め方で説明できるかを確認します。名称だけを掲げ、画面とDBの結合を避けるルールがない場合は注意が必要です。

選定では、要件整理に参加する業務アナリスト、ドメイン設計を担うアーキテクト、開発リーダー、テスト責任者、運用担当の役割を確認します。再委託の有無、担当者が途中で交代する条件、内製化支援、障害時の連絡経路、保守の最低期間も比較対象です。大規模案件では、技術力だけでなく複数ベンダーを統制する責任者が誰かをRFP回答に書いてもらいます。

個人情報や機密情報を扱う場合は、アクセス制御、最小権限、通信・保存データの暗号化、ネットワーク分離、監査ログ、バックアップ、脆弱性管理、インシデント時の遮断と報告を要件化します。個人情報保護委員会も、技術的安全管理措置だけでなく、従業者教育や委託先管理を含む安全管理を確認する考え方を示しています（出典: 個人情報保護委員会「標的型メール攻撃や不正アクセス等に関する安全管理措置」、2025年更新）。オニオンアーキテクチャを採用しても、これらの対策が自動的に実装されるわけではありません。

契約では、ソースコード、設計書、テスト、IaC、ログ設定の所有・利用権、著作権法第27条・第28条の権利、第三者OSSのライセンス、再委託、データ返却、保守切り替えを確認します。要件変更の手続きは、変更内容、影響範囲、追加費用、納期、承認者を記録する方式にします。法改正対応や脆弱性対応が保守に含まれるのか、追加請求になるのかも、見積もりと契約の両方に明記しておく必要があります。

オニオンアーキテクチャのシステムに関するよくある質問

ここでは、発注前に特に質問されやすい論点をまとめます。オニオンアーキテクチャの採用可否だけでなく、業務の複雑さ、将来の変更、チームの運用能力を合わせて判断することが大切です。

同じものではありません。DDDは業務領域を理解してドメインモデルを設計するための考え方で、オニオンアーキテクチャはそのモデルを中心に置き、技術要素への依存方向を管理する構造です。DDDを使わずに層だけ増やしても業務ロジックの整理にはつながらないため、要件整理と設計をセットで進めます。

必ずしもマイクロサービスにする必要はありません。まずはモジュラーモノリスとして業務境界と依存方向を明確にし、チームの分割、独立デプロイ、負荷分散、障害分離に明確な効果がある境界だけをサービス化します。最初から分散構成にすると、監視、データ整合性、通信障害、リリース管理の負担が増えるため、必要性を数値や運用課題で説明できるかが判断基準です。

移行できますが、全体を一括で書き換える必要はありません。最初に重要な業務の読み取り連携や外部アプリを切り出し、旧データを新しい用語へ変換するアダプターを設け、並行稼働とデータ照合を行う段階移行が現実的です。旧システムの仕様が不明な場合は、現行の入出力と業務ルールをテストとして記録し、振る舞いを保ったまま内側のモデルを置き換えます。

最も有効なのは、独自性の高い業務を1つに絞り、標準化できる会計や人事はSaaS・パッケージと連携する方法です。最初から全社機能やマイクロサービスを作らず、300万〜800万円程度の小規模PoCでドメインモデルとテストの有効性を確かめてから拡張すると、不要な作り込みを避けやすくなります。ただし、テスト、移行、監視、セキュリティを削るだけでは将来費用が増えるため、削る範囲と残す品質基準を分けて判断します。

まとめ

オニオンアーキテクチャのシステム開発では、DomainとApplicationに業務の判断を集め、DB、外部API、認証、画面などを外側のアダプターへ隔離します。これにより、業務ルールを単体テストで検証しやすくなり、DBや外部サービスを変更した際の影響範囲も管理しやすくなります。ただし、層を増やすこと自体が目的ではなく、長く使い、変更が続く業務に適用することが重要です。

実務では、要件整理で用語・例外・優先順位をそろえ、選定でSaaS・パッケージ・スクラッチの境界を決め、設計・開発で内側から外側へ責務を分けます。テストでは業務ルール、権限、連携、移行データを確認し、稼働では切り戻しと並行運用を準備します。最後に定着の指標を測り、改善を継続します。

予算は小規模PoCで300万〜800万円、中規模で800万〜2,000万円、大規模な基幹刷新で3,000万円〜1億円超という推定レンジを起点にし、業務ルール、連携、データ移行、非機能要件で調整します。見積もりでは工程別の工数、成果物、保守範囲、ソースコードと権利、セキュリティ責任を確認し、価格だけでなく将来の変更と運用を含めて比較します。

▼全体ガイドの記事
・オニオンアーキテクチャのシステム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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