オニオンアーキテクチャは、業務ルールを中心に置き、技術の詳細を外側へ分けて設計する方式です。
保守性とテスト性を高めやすい理由から、4層の役割、向いているシステム、開発の進め方、費用の目安、開発会社の選び方までを順に見ていきます。
▼関連記事一覧
・オニオンアーキテクチャのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・オニオンアーキテクチャのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・オニオンアーキテクチャのシステム開発の見積相場や費用/コスト/値段について
・オニオンアーキテクチャのシステム開発の発注/外注/依頼/委託方法について
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
オニオンアーキテクチャのシステム全体像
オニオンアーキテクチャは、システムを同心円状の層に分ける設計思想です。依存関係は外側から内側へ向け、業務上の判断を担う内側は、Webフレームワークやデータベースを直接参照しません。
メールやクラウドなどの技術も外側へ分離すると、業務の変化と技術の変更を別々に扱えます。その分け方が、数年後の改修コストを左右します。
中心に置くドメイン層の役割
ドメイン層は、業務固有の不変条件を技術の詳細から切り離して表す層です。
- 業務ルール：在庫がない商品は出荷確定できないなど、業務上の条件を扱います。
- モデル化：ルールを画面やSQLに埋め込まず、エンティティや値オブジェクト、集約などの単位で表します。
- 技術からの分離：データベースのテーブル構造や特定のORMに依存させず、業務ルールを単体テストで直接検証できるようにします。
- 業務担当者との連携：用語をそろえず技術者だけで作ると、現場と異なるルールになり得ます。
Application・Infrastructure・Presentation層の役割
外側の3層は、ユースケースの調整、技術実装、利用者との入出力を分担します。特に、データベースや外部サービスの実装は、内側から切り離してInfrastructure層に置きます。
- Application層：ユースケースやトランザクションの境界を定める層です。
- Infrastructure層：データベースや外部サービスの実装を置く場所です。
- Presentation層：画面やAPIなどの入口を受け持ちます。
Application層では、注文登録や在庫引き当てなどの処理を進めます。
入出力DTOや、リポジトリと通知サービスのインターフェースも、この層で定めます。機能の契約は内側に置きます。
Infrastructure層では、データベースアクセスやORM、ファイル保存のほか、メール送信やキューも実装します。外部SaaS連携や認証基盤も、この層に実装します。
Presentation層は、Web画面やバッチ、CLIのほか、RESTやGraphQLのAPIを入口とします。
入力をユースケースへ渡し、結果は画面やレスポンスに変換します。
依存関係逆転とドメイン設計によって、Application Coreと外部実装を分けやすくなると、一般的なWebアプリケーションの技術解説でも説明されています（出典: 一般的なWebアプリケーションアーキテクチャの技術解説、2025年公開・2026年確認）。
オニオンアーキテクチャが向いているシステム
業務ルールが複雑で、数年から10年以上の運用や段階的な機能追加を見込むシステムに向いています。ただし、短命なCRUDツールでは、画面からDBへ登録するだけの処理でも、層やインターフェースを増やす初期コストが利点を上回ることがあります。
レイヤード・クリーン・ヘキサゴナルとの違い
方式ごとの違いは、層の責務や依存方向、外部との境界に表れます。
- レイヤード：Presentation、Application、Domain、Data Accessなどに責務を分けます。
- オニオン：依存関係逆転を用い、内側で定めたインターフェースを外側が実装します。
- クリーン・ヘキサゴナル：クリーンは同心円で表す依存方向やユースケース中心の設計を一般化し、ヘキサゴナルはポートとアダプターで外部接続を表します。
上位層が下位層の実装へ直接依存する構成も多く、DBの都合が業務ロジックへ入りやすい点に注意が必要です。
実務では呼称が重なり、同じプロジェクトで複数の名前が使われることもあります。そのため、名称だけでなく、依存方向と境界、テスト方針、外部連携の切り離し方を成果物で確かめます。
向いているケースと過剰設計になりやすいケース
適用を判断するときは、業務の複雑さや運用期間を、必要な設計の深さと見比べます。
- 適する業務：受発注や在庫、契約など、例外や状態遷移が多いシステムです。請求、審査、会計連携も含まれます。
- 適する条件：複数の部門や利用経路で、同じ業務ルールを共有する場合です。
- 軽量構成が合理的な場合：数週間から数か月の検証用ツール、単純な台帳、少人数向けの一時画面では、変化の多い領域だけを分け、参照処理を簡素化します。
部門ごとに権限が異なる場合や、Web、バッチ、外部APIから共通ルールを使う場合も適しています。
将来データベースや外部サービスを入れ替える場合も、技術の変更が内側へ波及しにくい点が生きます。
オニオンを選ぶ場合でも、最初から全機能を厳密に4層へ分ける必要はありません。
オニオンアーキテクチャのシステム開発の進め方
開発では、フレームワークやDBより先に、業務の境界とルールを明らかにします。
最初は、最重要の1業務を選び、モデルとユースケースを作ったうえで、テストと運用まで通して検証します。そのうえで、検証で学んだ内容を次の領域へ広げると、失敗の影響を抑えやすくなります。
▶ 詳細はこちら：オニオンアーキテクチャのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
要件定義とドメインモデリング
業務の流れと境界を、業務担当者と確かめながら順に整理します。
- 業務のイベントや用語、担当者を洗い出し、権限や例外、状態遷移も書き出します。受注では見積承認から請求締めまでを並べ、実行者と条件を確かめます。
- 画面一覧では見えない判断や例外を担当者から聞き、Bounded Contextと呼ばれる業務境界を決めます。
- 販売や在庫、購買、会計を一つの巨大なモデルに混ぜず、同じ商品や顧客、締め日でも部門ごとに異なる意味を区別します。
- 用語集やイベント一覧、業務ルールを残し、境界図と優先順位表で、Must機能と後回しにできる機能を分けます。
層の設計とMVP開発
層の契約を決めたうえで、最重要業務をMVPとして通し、実運用に必要な点を確かめます。
- Domain層とApplication層の契約を先に決め、Infrastructure層とPresentation層をつなぎます。
- ORMの型やSQLをDomain層に漏らさず、依存性注入で実DBをテスト用の実装に差し替えられるようにします。
- MVPでは受注登録から請求データ作成まで、在庫引当や出荷指示を含めて縦切りで作り、本番に近い環境で利用者が操作します。
- 公開サンプルには、Application Core、Infrastructure、Webに分ける構成のものがあります。
リポジトリや認証・認可、通知のアダプターを整理します。そのあとは、決済やファイル保存、外部APIのアダプターも整理します。
検証では、データの整合性やエラー処理を確かめます。
監査ログや権限、バックアップも、検証の対象に含めます。
テスト・リリース・運用改善
各層のテストから本番運用まで、失敗ケースや移行方法を含めて確かめます。
- 層ごとのテスト：Domainは単体で、Applicationはユースケースとトランザクションで確かめます。外側はDB・API・画面との結合を見ます。
- 例外と連携：在庫不足や二重送信、締め後の修正を正常系と同じ重要度で試し、契約テストと移行データの照合も行います。
- リリース後の観測：障害件数や処理時間、手戻り、利用率、問い合わせを見て、モジュラーモノリスの境界を保ちます。
- 段階的な刷新：負荷や組織体制の理由がはっきりした部分だけを、サービス化します。
既存システムを刷新する場合は、読み取り連携から始めるストラングラーフィグ型の移行を、旧システムとの並行稼働やデータ照合と組み合わせます。
オニオンアーキテクチャのシステムの費用相場
オニオンアーキテクチャだけを対象にした公的な価格統計はありません。そのため、以下の数字は、2026年時点の一般的な業務システム相場に追加工数を加味した推定です。
追加工数には、ドメイン分析やインターフェース設計、テスト、マッピングが含まれます。予算を検討する際の目安として使い、個別の見積もりは別途取ってください。
▶ 詳細はこちら：オニオンアーキテクチャのシステム開発の見積相場や費用/コスト/値段について
規模別の初期費用と開発期間
初期費用と期間は規模で変わります。各区分に含まれる機能や連携範囲と合わせて読むと、費用の前提を比べられます。
- 小規模：PoCや1業務が対象で、300万〜800万円、3〜5か月です。管理画面、API、DB、認証、単体・結合テストを含みます。
- 中規模：複数部署、権限、帳票、外部API、移行、監査ログを含む規模で、800万〜2,000万円、6〜10か月程度です。
- 基幹刷新：複数領域やERP・会計・物流との連携、大量データ、災害対策を含み、3,000万円〜1億円超、12〜24か月以上になる場合があります。
2026年の調査では、人月単価はスキルや地域により60万〜200万円程度です。
簡易ツールは数十万円から、複雑な基幹システムは数千万円から億単位まで幅があります（出典: 2026年版システム開発費用調査、2026年確認）。
オニオン構成でも、金額を左右するのは業務ルールの複雑さや連携数です。移行データの品質や非機能要件も、金額に効いてきます。そのため、画面数だけで単純に比べると危険です。
費用の内訳とランニングコスト
初期見積もり、運用費、導入方式を分けて見ると、費用の前提を比べやすくなります。
- 初期見積もり：要件定義から保守まで、工程ごとに分けて示してもらいます。
- 運用費：初期費用の年15〜25％が目安で、クラウド利用料や監視、バックアップ、脆弱性・法改正対応、障害対応、追加開発を分けて見ます。
- SaaS：初期費用は無料から数十万円、導入支援込みでは20万〜60万円程度で、月額利用料が加わる場合があります。
- ハイブリッド方式：標準化しやすい会計や人事はSaaSやパッケージ、独自業務は個別開発にします。
内訳には、ドメインモデリングや、UI・API設計、Domain・Application・Infrastructureの実装が含まれます。インフラやテスト、移行も対象です。教育やリリース支援、保守も含めて見ます。
見積もりを「開発一式」とすると、設計や検証の工数が分からず、追加費用が膨らむおそれがあります。
成果物と担当者、工数は、見積明細に記載してもらいます。前提条件や除外範囲も、同じ明細に記載してもらいます。
オニオンアーキテクチャの開発会社・ベンダーの選び方
開発会社やベンダーは、業務境界と依存方向、テスト・運用設計を、提案と成果物で確かめて選びます。名称の認知度よりも、その中身で判断します。
自社業務に適用する範囲と、適用しない範囲を説明できる相手が適しています。特定の技術を一方的に勧める提案の場合は、まず適用範囲を確かめます。
アーキテクチャとドメイン設計の実力の確認
提案と成果物、コードを照らし合わせて、業務モデルと依存方向を実装できるかを確かめます。
- 設計説明：受注や在庫の例を使い、Domainのルール、Applicationの調整、DB・APIの接続ポートを説明してもらいます。
- 設計過程：サンプルコードの出来だけでなく、業務用語のモデル化や例外対応、境界変更の基準から、実案件での再現性を判断します。
- 成果物：用語集やイベント図、Bounded Context図、依存図を見て、ユースケースやAPI仕様、テスト・運用設計まで揃っているかを確かめます。
- コードレビュー：DomainがORMやHTTPの型に依存せず、Infrastructureは内側へ依存しないか、単体テストが業務ルールを検証するかを見ます。
進め方・見積もり・体制の比較
提案を比べるときは、要件定義の体制、費用の前提、変更時の契約方式を見ておきます。
- 進め方：担当やワークショップの回数、MVPの範囲を確かめます。開発会社だけでモデルを作ると、暗黙知を逃す恐れがあります。
- 体制：プロダクトオーナーや業務責任者、アーキテクトなどの役割と、意思決定者、交代時の引き継ぎを明確にします。
- 見積もり：工程ごとに前提や納期、対象外の作業、変更単価を比べます。テスト、移行、監視、教育などの別料金も見ます。
- 契約方式：要件が確定した部分は請負、検証や継続改善は準委任にするなど、不確実性に合わせて選びます。
契約で押さえる成果物・権利・保守の切り替え
納品の範囲や知的財産、保守、将来の引き継ぎ条件は、契約前に具体化しておきます。
- 納品物：ソースコードや設計書、テストコードのほか、CI/CD、Infrastructure as Code、監視設定、データ移行用スクリプトを含めます。
- 権利：利用許諾に加え、必要な第27条・第28条の扱いを確認します。第三者ライセンスや再委託先の成果物も対象です。
- 保守と移管：保守の内容と、別の会社や内製チームへ移す条件を定めます。
障害受付時間や復旧目標、ログ保存期間を記載します。移管時の協力範囲や脆弱性・法改正対応、クラウド費用、追加開発も、あわせて明記しておきます。
アカウントやリポジトリ、ドメイン知識、運用手順も、発注側が引き継げる状態にします。
▶ 詳細はこちら：オニオンアーキテクチャのシステム開発でおすすめの開発会社/ベンダー6選と選び方
▶ 詳細はこちら：オニオンアーキテクチャのシステム開発の発注/外注/依頼/委託方法について
セキュリティ・クラウド・契約で見落とせない点
オニオンアーキテクチャは、業務ロジックと技術詳細を分ける設計で、セキュリティ対策そのものは別に考えます。個人情報や取引情報、権限情報を扱うなら、安全管理措置を初期段階から要件に含めます。
その対策には、アクセス制御や暗号化、監査、バックアップ、脆弱性対応が含まれます。いずれも、要件として定義します。
個人情報・権限・監査ログの要件化
個人情報や権限情報を扱うなら、アクセス制御から検知まで、一体で定めます。
- 権限・認証：利用者と管理者を分けたうえで、最小権限や多要素認証、外部IdP連携を検討します。
- データ保護：認可はユースケース単位で行い、暗号化や鍵管理、バックアップ保護、開発環境への持ち出し禁止を定めます。
- 監査・検知：誰が、いつ、どのデータに何をしたかを記録して保護します。ログの保存期間と確認担当を決め、異常ログイン、権限変更、大量出力を検知します。
個人情報保護委員会のQ&Aでは、技術的安全管理措置や端末の暗号化、従業者研修が確認事項とされています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン」に関するQ&A、2025年7月更新）。
クラウド移行と運用責任の分担
クラウド利用では、サービス条件や責任分担、外部接続、運用手順を、そろえて確かめます。
- サービス条件：可用性やバックアップ、復旧目標、所在地などを確認します。監視、連絡経路、サービスレベルも見ます。
- 責任分担：事業者、発注側、開発側の担当を責任共有モデルで整理し、クラウド任せにはしません。
- 外部接続：認証や決済、メール、ファイル保管をアダプターに置くと、交換やテストがしやすくなります。
- 運用手順：秘密情報やAPIキーの更新、障害時の代替、削除を定めます。月次の脆弱性確認や依存ライブラリ更新、復旧訓練は、保守計画に入れます。
オニオンアーキテクチャのシステムに関するよくある質問
オニオンアーキテクチャは、技術者だけの設計用語ではありません。業務ルールや将来の変更を考えるための共通言語としても使えます。発注前によく出る疑問に回答します。
オニオンアーキテクチャとDDDは同じものですか？
両者は別のものです。
- DDD：業務領域を理解して、ドメインモデルや境界を設計する考え方です。
- オニオンアーキテクチャ：業務ロジックを技術詳細から隔離する構造の一つです。
DDDを使わずに層だけ作ることもできますが、業務モデルが曖昧だと効果は限られます。
オニオンアーキテクチャならデータベースを簡単に変更できますか？
変更しやすくなりますが、無条件に簡単になるわけではありません。Domain層やApplication層がDBやORMに依存しなければ、外側の実装を差し替える余地が生まれます。
データ型や検索性能、トランザクションは、別途設計が必要です。既存データの移行や運用監視も、設計が要ります。将来の変更が必要な範囲にだけ、抽象化を適用します。
オニオンアーキテクチャを採用するとマイクロサービス化が必要ですか？
マイクロサービス化は前提ではありません。オニオンアーキテクチャは、アプリケーション内部の依存関係を整理する設計です。
- マイクロサービス：システムを複数の独立したサービスに分ける運用・組織・配置方式です。
- 最初の段階：モジュラーモノリスで、業務境界とテストを確立します。
- サービス化の時期：独立したデプロイや負荷分散、組織の分割など、明確な理由が生じたときに検討します。
過剰設計を避けるには何を決めればよいですか？
過剰設計を避けるには、層を分ける範囲と設計の深さを、次の4点を目安に決めます。
- 分ける対象：将来変わる可能性が高い業務ルールと、変更しにくい外部接続を先に分けます。
- 単純な参照処理：複雑な抽象化を重ねず、簡素な構成にとどめます。
- 設計の深さ：変更頻度や障害時の影響、テストの難しさ、運用期間を基準に決めます。
- MVPでの確認：最初のMVPで変更を経験し、必要な境界だけを強化します。
まとめ
オニオンアーキテクチャは業務ルールを中心に置き、Application、Infrastructure、Presentationなど外側へ技術詳細を分離します。
保守性とテスト性、外部技術の交換しやすさが強みです。一方で、単純なシステムへ無理に適用すると、初期工数や構造の複雑さが増えます。
採用判断で押さえる3つの要点
業務のイベントや用語、例外、境界を先に整理し、依存方向と成果物で設計を評価します。
費用は、小規模PoCの300万〜800万円から、大規模刷新の1億円超まで幅があります。業務ルールや連携、移行、非機能要件に分けて見積もります。
SaaSやパッケージで標準化できる領域と、独自開発で競争力を出す領域を分けます。そのうえで、モジュラーモノリスから段階的に進めます。
次に準備する資料
発注前には、対象業務の課題や業務イベント、用語集を整えておきます。利用者と権限、既存システムとの連携、移行対象データも書き出します。さらに、目標期間と予算上限、必要なセキュリティ水準も決めておきます。
要件定義やドメイン設計、テスト、移行、運用まで含む提案を比べます。ソースコードや設計書の引き渡しも、比較の対象にします。そのうえで、自社に必要なオニオンアーキテクチャの範囲を判断しやすくなります。
▼関連記事一覧
・オニオンアーキテクチャのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・オニオンアーキテクチャのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・オニオンアーキテクチャのシステム開発の見積相場や費用/コスト/値段について
・オニオンアーキテクチャのシステム開発の発注/外注/依頼/委託方法について
▼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を創業。