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

オニオンアーキテクチャのシステムとは、受注・在庫・請求などの業務ルールを中心に置き、データベースや画面、外部サービスを外側へ分離する設計方法です。中心の業務ロジックを技術の変更から守ることで、長期運用する業務システムの保守性とテスト性を高めやすくなります。

一方で、オニオンアーキテクチャを採用すれば自動的に高品質なシステムになるわけではありません。この記事では、4層の役割、クリーンアーキテクチャやヘキサゴナルアーキテクチャとの違い、向いているシステム、費用相場、開発の進め方、発注時の確認事項、セキュリティ、よくある疑問までを、技術担当者以外の方にも判断できるように整理します。

オニオンアーキテクチャのシステム全体像

オニオンアーキテクチャは、システムを同心円状の層に分け、依存関係を外側から内側へ向ける設計思想です。業務上の判断を担う内側の層が、Webフレームワーク、データベース、メール、クラウドなどの外側の技術を直接参照しないことが基本になります。業務システムでは、業務の変化と技術の変更を別々に扱えるかどうかが、数年後の改修コストを大きく左右します。

中心に置くドメイン層とは何ですか？

ドメイン層は、企業や業務に固有のルールを表す層です。たとえば受注管理なら「在庫が確保できない商品は出荷確定できない」「締め処理後の請求書は無断で変更できない」といった不変条件を、画面の処理やSQLの中に埋め込まず、エンティティ、値オブジェクト、集約、ドメインサービスとして表現します。

この層は、データベースのテーブル構造や特定のORMに依存させないことが重要です。業務ルールを単体テストで直接検証できるため、画面を操作しなければ発見できない不具合を減らせます。ただし、業務担当者と用語をそろえずに技術者だけでモデルを作ると、層を分けても現場と違うルールを実装する結果になります。

Application・Infrastructure・Presentation層の役割

Application層は、利用者が実行するユースケースを表す層です。「注文を登録する」「在庫を引き当てる」「請求を確定する」といった処理の流れ、トランザクション境界、入力と出力のDTO、リポジトリや通知サービスのインターフェースを定義します。実装は外側にあっても、使うべき機能の契約は内側に置くという考え方です。

Infrastructure層には、データベースアクセス、ORM、ファイル保存、メール送信、外部SaaS連携、キュー、認証基盤などの具体的な実装を置きます。Presentation層はWeb画面、RESTやGraphQLのAPI、バッチ、CLIなどの入口で、受け取った入力をユースケースへ渡し、結果を画面やレスポンスへ変換します。公開されている一般的なアーキテクチャの技術資料でも、依存関係逆転とドメイン設計を用いると、Application Coreと外部実装を分離する構成になりやすいと説明されています（出典: 一般的なWebアプリケーションアーキテクチャの技術解説、2025年公開・2026年確認）。

オニオンアーキテクチャはどのシステムに向いていますか？

結論から言うと、オニオンアーキテクチャは、業務ルールが複雑で、数年から10年以上の運用や段階的な機能追加を見込む業務システムに向いています。逆に、画面からデータベースへ登録するだけの短命なCRUDツールでは、層やインターフェースを増やす初期コストがメリットを上回る場合があります。

レイヤードアーキテクチャは、Presentation、Application、Domain、Data Accessのように責務を層へ分ける考え方です。ただし、上位層が下位層の具体実装へ直接依存する構成も多く、データベースの都合が業務ロジックへ入り込みやすい点に注意が必要です。オニオンアーキテクチャは、依存関係逆転の原則によって、内側がインターフェースを定義し、外側がそれを実装する点を強く意識します。

クリーンアーキテクチャは、同心円で表される依存方向やユースケース中心の設計をより一般化した呼び方です。ヘキサゴナルアーキテクチャは、アプリケーションの内側をポート、外部との接続をアダプターとして扱います。実務では呼称が重なり、同じプロジェクトで複数の名前が使われることもあります。名称の一致を確認するより、依存方向、境界、テスト方針、外部連携の切り離し方を成果物で確認することが大切です。

向いているケースと過剰設計になりやすいケース

向いているのは、受発注、在庫、契約、請求、審査、会計連携など、例外や状態遷移が多いシステムです。部門ごとに異なる権限があり、Web、モバイル、バッチ、外部APIなど複数の入口から同じ業務ルールを使う場合も適しています。将来、データベースや外部サービスを入れ替える可能性がある場合は、技術の変更を内側へ波及させにくい点が有効です。

一方、数週間から数か月で廃止する検証用ツール、業務ルールがほとんどない単純な台帳、利用者が少ない一時的な管理画面では、軽量な構成が合理的です。オニオンを選ぶ場合でも、最初から全機能を厳密に4層へ分ける必要はありません。変化が多いドメインだけを中心に設計し、単純な参照処理は簡素化するなど、変更リスクに応じて設計の深さを調整します。

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

開発では、いきなりフレームワークやデータベースを決めるのではなく、業務の境界とルールを先に明らかにします。最初から全社基幹を一括で作るより、最重要の1業務でモデル、ユースケース、テスト、運用を検証し、学んだ内容を次の領域へ広げる方が失敗の影響を抑えられます。

▶ 詳細はこちら：オニオンアーキテクチャのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

要件定義とドメインモデリング

まず、業務イベント、業務用語、担当者、権限、例外、状態遷移を洗い出します。受注管理なら「見積を承認する」「受注を確定する」「在庫を引き当てる」「出荷を完了する」「請求を締める」といったイベントを時系列に並べ、誰がどの条件で実行できるかを確認します。画面一覧だけでは見えない判断や例外を業務担当者から引き出すことがポイントです。

次に、Bounded Contextと呼ばれる業務境界を設定します。販売、在庫、購買、会計を一つの巨大なモデルに混ぜると、同じ「商品」「顧客」「締め日」という言葉に別の意味があることを見落としやすくなります。用語集、イベント一覧、業務ルール、境界図、優先順位表を成果物として残し、Must機能と後回しにできる機能を分けます。

層の設計とMVP開発

設計では、Domain層とApplication層が定義する契約を先に決め、Infrastructure層とPresentation層を後から接続します。リポジトリのインターフェース、認証・認可のポート、通知、決済、ファイル保存、外部APIのアダプターを整理し、ORMの型やSQLがDomain層へ漏れない構造にします。依存性注入を使えば、実際のDBの代わりにテスト用の実装を差し込めます。

MVPでは、最重要の業務を最後まで通します。たとえば「受注登録から在庫引き当て、出荷指示、請求データ作成まで」を一つの縦切りで作り、利用者が本番に近い環境で操作します。公開されているサンプルでも、Application Core、Infrastructure、Webを分ける構成が示されています。見た目だけの試作品ではなく、データ整合性、エラー処理、監査ログ、権限、バックアップまで含めて検証することが重要です。

テスト・リリース・運用改善

テストは、Domain層の業務ルールを高速な単体テストで確認し、Application層でユースケースとトランザクションを検証し、外側の層でDB・API・画面との結合を確認します。たとえば「在庫が不足した場合」「同じ注文が二重送信された場合」「締め処理後に修正を試みた場合」を正常系と同じ重要度でテストします。契約テストや移行データの照合も、外部連携が多い業務システムでは欠かせません。

リリース後は、障害件数、処理時間、業務の手戻り、利用率、問い合わせ内容を観測します。最初からマイクロサービスへ分割するのではなく、モジュラーモノリスとして境界を保ち、負荷や組織体制の理由が明確になった部分だけをサービス化する方が現実的です。既存刷新では、読み取り連携から始めるストラングラーフィグ型の段階移行、旧システムとの並行稼働、データ照合を組み合わせます。

オニオンアーキテクチャのシステムの費用相場

オニオンアーキテクチャだけを対象にした公的な価格統計はありません。以下は、2026年時点の一般的な業務システム相場に、ドメイン分析、インターフェース設計、テスト、マッピングの追加工数を加味した推定です。個別見積もりではなく、予算を検討するための目安として利用してください。

▶ 詳細はこちら：オニオンアーキテクチャのシステム開発の見積相場や費用/コスト/値段について

規模別の初期費用と開発期間

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

2026年のシステム開発費用調査では、人月単価はスキルや地域によって60万〜200万円程度とされ、簡易ツールは数十万円から、複雑な基幹システムは数千万円から億単位まで幅があります（出典: 2026年版システム開発費用調査、2026年確認）。オニオン構成では、画面数だけでなく、業務ルールの複雑さ、連携数、移行データの品質、非機能要件によって金額が変わるため、単純な機能数比較は危険です。

費用の内訳とランニングコスト

見積もりは、要件定義、ドメインモデリング、UI・API設計、Domain・Application実装、Infrastructure実装、インフラ構築、テスト、データ移行、教育、リリース支援、保守に分けて確認します。「開発一式」だけでは、どこに設計と検証の工数が含まれるのか分からず、後から追加費用が膨らみやすくなります。成果物、担当者、工数、前提条件、除外範囲を明細化してもらいます。

運用費は、初期開発費の年15〜25％程度を一つの目安として、クラウド利用料、監視、バックアップ、脆弱性対応、法改正対応、障害対応、追加開発を分けて見込みます。SaaSは初期費用が無料から数十万円、導入支援込みで20万〜60万円程度に月額利用料が加わることがあります。標準化できる会計や人事はSaaS・パッケージ、競争力の核となる独自業務だけをカスタム開発するハイブリッド方式は、柔軟性とコストのバランスを取りやすい選択肢です。

オニオンアーキテクチャの開発会社・ベンダーの選び方

開発会社やベンダーを選ぶときは、「オニオンアーキテクチャという名前を知っているか」だけで判断しないことが大切です。業務の境界を整理し、依存方向を守り、テストと運用まで設計できるかを、過去の成果物や提案内容で確かめます。特定の技術を押し込む会社ではなく、自社の業務に適用する範囲と適用しない範囲を説明できる相手が適しています。

アーキテクチャとドメイン設計の実力を確認する

提案時には、受注や在庫などの業務例を一つ示し、「どのルールを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月更新）。

クラウド移行と運用責任の分担を確認する

クラウドを使う場合は、可用性、バックアップ、復旧目標、データ所在地、ネットワーク分離、監視、障害時の連絡経路、サービスレベルを確認します。クラウド事業者が守る範囲と、発注側・開発側が設定する範囲は異なるため、「クラウドなので安全」と考えず、責任共有モデルで整理します。

外部サービスの認証、決済、メール、ファイル保管をInfrastructure層のアダプターに閉じ込めると、交換やテストはしやすくなります。しかし、秘密情報の保管、APIキーの更新、障害時の代替手段、データ削除の手順まで設計しなければ、分離しただけでは運用リスクは残ります。月次の脆弱性確認、依存ライブラリの更新、復旧訓練を保守計画へ入れてください。

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

オニオンアーキテクチャは、技術者だけのための設計用語ではありません。業務ルールをどこで守るか、将来の変更をどこまで許容するか、開発会社へ何を依頼するかを決めるための共通言語として使えます。ここでは、発注前によく出る疑問へ直接回答します。

オニオンアーキテクチャとDDDは同じものですか？

同じものではありません。DDDは、業務領域を理解してドメインモデルや境界を設計するための考え方で、オニオンアーキテクチャは、その業務ロジックを技術詳細から隔離する構造の一つです。DDDを使わずにオニオンの層だけを作ることもできますが、業務モデルが曖昧なままだと、層分けの効果は限定的です。

オニオンアーキテクチャならデータベースを簡単に変更できますか？

変更しやすくはなりますが、無条件に簡単になるわけではありません。Domain層やApplication層が特定のDBやORMへ依存していなければ、外側の実装を差し替える余地が生まれます。しかし、データ型、検索性能、トランザクション、既存データの移行、運用監視は別途設計が必要です。将来の変更可能性が本当に必要な範囲にだけ抽象化を適用します。

オニオンアーキテクチャを採用するとマイクロサービス化が必要ですか？

必要ありません。オニオンアーキテクチャは一つのアプリケーション内部の依存関係を整理する設計で、マイクロサービスはシステムを複数の独立サービスへ分ける運用・組織・配置の方式です。まずはモジュラーモノリスで業務境界とテストを確立し、独立デプロイ、負荷分散、組織分割などの明確な理由が生まれたときにサービス化を検討します。

過剰設計を避けるには何を決めればよいですか？

将来変わる可能性が高い業務ルールと、変更しにくい外部接続を優先して分離します。単純な参照処理まで複雑な抽象化を重ねず、変更頻度、障害時の影響、テストの難しさ、運用期間を基準に設計の深さを決めます。最初のMVPで実際の変更を経験し、必要な境界だけを強化する進め方が有効です。

まとめ

オニオンアーキテクチャのシステムは、業務ルールを中心に置き、Application、Infrastructure、Presentationなどの外側へ技術詳細を分離する設計です。保守性、テスト性、外部技術の交換しやすさに強みがありますが、単純なシステムへ無理に適用すると、初期工数や構造の複雑さが増えます。

採用判断で押さえる3つの要点

第一に、業務イベント、用語、例外、境界を先に整理し、オニオンという名前ではなく依存方向と成果物で設計を評価します。第二に、費用は小規模PoCの300万〜800万円から大規模刷新の1億円超まで幅があるため、業務ルール、連携、移行、非機能要件を分解して見積もります。第三に、SaaSやパッケージで標準化できる領域と、独自開発で競争力を出す領域を分け、モジュラーモノリスから段階的に進めます。

次に準備する資料

発注前には、対象業務の課題、業務イベント、用語集、利用者と権限、既存システムの連携、移行対象データ、目標期間、予算上限、必要なセキュリティ水準を一枚に整理します。そのうえで、要件定義、ドメイン設計、テスト、移行、運用、ソースコードや設計書の引き渡しを含む提案を比較すると、自社に必要なオニオンアーキテクチャの範囲を判断しやすくなります。