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

オニオンアーキテクチャのシステム開発は、6つのフェーズで進みます。最初の2つで業務の言葉と境界を決め、残りを設計・開発からテスト、稼働、定着へと進めます。

技術より先に業務ルールを整理し、段階的に稼働させて定着まで進めることで、変更に強い業務システムにつながります。構造の全体像は、完全ガイドでも取り上げています。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

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

オニオンアーキテクチャは、顧客、受注、在庫、請求などの業務ルールを内側のDomain層に置く設計思想です。

DBやWebフレームワーク、外部API、メール、キューは、外側へ分離します。

依存関係は外側から内側へ向かいます。そのため、中心の業務ロジックがInfrastructure層や画面の都合に引きずられにくくなります。

受発注業務に置き換えた4つの層

受発注業務を例にすると、受注や在庫の業務ルールは内側の層に、DBや画面などの実装は外側の層に分けて担わせます。各層の役割は、次のように整理できます。

• Domain層：出荷済みの受注のキャンセル不可や、与信枠を超えた受注の承認など、業務ルールを担います。
• Application層：受注登録、在庫引き当て、請求発行のユースケースと、その処理順序・トランザクション境界。
• Infrastructure層：PostgreSQLやSQL Serverへの接続、ORM、会計SaaS、メール、認証基盤、メッセージキューの実装。
• Presentation層：Web画面、REST・GraphQL API、バッチ、CLIからユースケースを呼び、結果を画面やレスポンスに変換します。

リポジトリや通知サービスのインターフェースは内側で定義し、依存関係逆転によってインフラを分離します。Application Coreは、他の層に依存させません。

Microsoft Learnもこの考え方を説明しています（出典: Microsoft Learn「一般的なWebアプリケーションアーキテクチャ」、2026年確認）。

向いているシステムと過剰設計になりやすいシステム

適用を判断するときは、業務の寿命や複雑さと、設計に必要な初期工数を見比べます。

• 向いている業務：複雑なルールがあり、数年から10年以上改修されるシステム。
• 効果が出やすい条件：複数の受注経路、部署ごとの権限や承認、多数の外部連携。
• 過剰設計になりやすい対象：短命なCRUDや、数週間で廃止する検証用ツール。

DBやクラウドを将来変える可能性がある業務では、ロジックを単体テストで確かめやすく、画面やDBの変更による影響も追いやすくなります。

一方で、層やDTO、マッピング、インターフェースの初期工数が、得られる価値を上回る場合もあります。なお、性能やセキュリティも、構造を変えただけでは自動的に高まりません。

業務の寿命、変更頻度、連携数、失敗時の損失を評価します。

適用する範囲は、業務単位で決めます。

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

技術を先に決めず、まずは業務上の判断と例外を整理して、小さく検証できる単位から作ります。

6フェーズに分け、各フェーズの終了条件を文書にしておくと、後工程で決定事項が膨らむリスクを抑えられます。

1. 要件整理：業務イベントと用語のすり合わせ

最初のMVPが膨らまないよう、業務の流れ、用語、例外、優先順位をそろえておきます。

• 業務イベント：受注管理なら見積作成、受注確定、在庫引き当て、出荷、請求を時系列に並べ、担当者、使う情報、次の状態へ進む条件を洗い出します。
• 用語：「顧客」「取引先」「案件」が別の意味で使われていないかを確かめ、用語集に残します。
• 成果物と例外：業務フロー、権限一覧、状態遷移、例外一覧、データ項目表、非機能要件をまとめます。承認者不在、在庫不足、API停止、注文の二重送信も挙げます。
• 優先順位：業務部門の責任者がMust、Should、後回しにできる機能を合意します。

2. 選定：SaaS・パッケージ・スクラッチの境界の決定

選定では、標準化できる業務と、競争力の源泉になる独自業務を分けます。そのうえで、次の境界と契約条件を確かめます。

• SaaS・パッケージ：法改正や標準処理が多い会計、勤怠、人事などを優先します。
• カスタム領域：独自の受注判断、配車、在庫引き当て、見積計算を検討します。
• 製品・契約条件：API、データ出力、認証、監査ログ、SLA、障害連絡体制。
• 終了時の条件：仕様変更をアダプターに閉じ込められるか、契約が切れたときにデータを返却できるか。

すべてをスクラッチにすると柔軟性は高まります。一方で、導入費用、テスト範囲、保守責任も増えます。製品名だけでなく、上記の条件を同じ前提で比べます。

大規模案件でも、最初からマイクロサービスに分けず、境界を明確にしたモジュラーモノリスから始めます。

分割の必要性を確認できた領域だけを、サービス化します。

3. 設計・開発：内側から外側への責務の実装

業務ルールを技術の詳細から守るため、Domain層から外側へ順に責務を設計します。

• Domain・Application：エンティティ、値オブジェクト、集約、ドメインサービス、不変条件を定義し、ユースケースとトランザクション境界を定めます。
• 外側の層：リポジトリや通知のインターフェースを置き、InfrastructureのDB実装・外部連携、Presentationの画面・APIを接続します。
• 技術との分離：DBのテーブル構造をDomainモデルにせず、ORMの型や注釈もDomain層へ持ち込みません。
• 実装ルール：依存性注入による実装の差し替えと、APIの入出力DTOとドメインモデルの分け方。

技術は、ASP.NET CoreとC#、JavaとSpring Boot、TypeScriptとNestJSなどから選びます。KotlinやGoも候補になります。

チームの経験、採用、運用体制も判断材料です。

実装ルールは設計書とコードレビューの基準に記します。また、重要なユースケースを縦に通すスパイクを先に作ると、層の分け方を早く検証できます。

4. テスト：業務ルールと境界の自動検証

テストは最後にまとめず、Domain層の単体テストから作ります。業務ルールは、正常系、境界値、例外系の3つの観点で確かめます。

• 与信：与信枠を超えた受注が承認待ちになること。
• 出荷：出荷済みの受注をキャンセルできないこと。

DBや外部APIをモックに置き換えると、中心のロジックを高速に繰り返し検証できます。この点は、オニオンアーキテクチャを採用する代表的なメリットです。

続いて、Infrastructureとの統合テストやAPIの契約テスト、画面の受け入れテストを行います。移行データの照合、負荷試験、権限試験も、この段階で確かめます。

テストケースは機能一覧から機械的に作らず、要件整理で挙げた業務イベントと例外一覧に対応づけます。

合格条件は、未解決の重大障害数と処理時間を含め、事前に合意しておきます。データ照合率やバックアップからの復旧時間も、合格条件に入れます。そうすると、リリースの判定が主観的になりにくくなります。

5. 稼働：移行と並行運用による業務の継続

稼働に向けて、移行計画と本番切替に必要な確認事項を整理します。

• 移行準備：対象、変換ルール、リハーサル、切り戻し条件を決めます。
• 段階導入：一度に置き換えるのが難しい場合は、読み取り連携や一部の外部アプリから始めます。
• 並行運用：旧システムの用語や形式がDomainモデルへ混ざらないよう、腐敗防止層をアダプターとして置く方法も有効です。
• 本番判定：機能、権限、監視、バックアップ、障害連絡、問い合わせ窓口、手作業の代替手順を確認します。
• 切替：移行後はデータ件数と金額を旧システムと照合し、現場責任者が受け入れを確認してから移ります。

たとえば、NECの建設クラウド事例のように、標準業務に合わせたプロトタイプと不足業務を補う外部アプリを組み合わせる方法もあります。全機能を一度に作り込まずに済む、現実的な選択肢です。

6. 定着：運用データの次の改善への活用

稼働後の計測と定期確認を、業務改善や運用体制の見直しにつなげます。

• 指標の確認：利用率、入力漏れ、処理時間、差し戻し件数、問い合わせを測り、毎月または四半期ごとに業務部門と開発・運用チームで振り返ります。
• 改善とテスト：ルール変更、追加機能、マスタ整備、教育課題に優先順位を付けます。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、教育資料も含めます。

受け入れ条件には、重要ユースケースのテスト合格と移行データ照合、権限テストを入れます。障害時の復旧手順の確認も、受け入れ条件に含めます。納品形式とレビュー回数も、あらかじめ決めておきます。

説明力と体制による開発会社の比較

実績の名称だけでなく、設計の説明力、担当者の役割、保守体制を同じ条件で比べます。

• 技術の説明力：設計の判断理由を、実案件の例で話せるかを見ます。
• 担当体制：役割の分担と、運用・保守の条件を具体的に比べます。
• 大規模案件の統制：複数ベンダーを束ねる責任者を、RFP回答に記載してもらいます。

質問するのは、業務ルールをDomainへ抽出する方法、ORMの配置、DB変更を検証するテストです。

DDDやドメインモデリング、依存関係逆転、テスト自動化の4つは、実案件の設計書やコードレビューで説明できるかを確かめます。

画面とDBの結合を避けるルールがない場合は、注意が必要です。

業務アナリストやアーキテクト、開発リーダーの役割を確認します。テスト責任者と運用担当の役割も確かめます。

再委託の有無や、担当者が途中で交代する条件を比べます。

内製化支援、障害時の連絡経路、保守の最低期間も比較します。

契約でのセキュリティ・権利・変更管理

個人情報や機密情報を扱う場合は、安全管理の対象を要件に含めます。

• 技術対策：アクセス制御、最小権限、通信・保存データの暗号化、ネットワーク分離。
• 運用対策：監査ログ、バックアップ、脆弱性管理、事故時の遮断と報告。
• 管理体制：安全管理措置を、人と委託先の両面で整えること。

個人情報保護委員会も、技術対策だけでなく従業者教育や委託先管理を含む安全管理を示しています（出典: 個人情報保護委員会「標的型メール攻撃や不正アクセス等に関する安全管理措置」、2025年更新）。

オニオンアーキテクチャを採用しても、これらの対策が自動で実装されるわけではありません。

契約では、次の4点を明確にしておきます。

• 成果物の権利：ソースコード、設計書、テスト、IaC、ログ設定の所有・利用権。
• 知的財産：著作権法第27条・第28条の権利、第三者OSSのライセンス。
• 継続・変更：再委託、データ返却、保守切り替え、要件変更の記録手続き。
• 保守範囲：法改正・脆弱性対応が保守内か追加請求かの区分。

要件が変わったときは、変更の内容と影響範囲を記録します。追加費用、納期、承認者も、同じ記録に残します。

保守範囲は、見積もりと契約の両方に記載します。

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

採用の可否は、業務の複雑さや将来の変更だけでなく、チームの運用能力も合わせて判断します。発注前に質問されやすいのは、DDDとの違いと、マイクロサービス化の是非です。また、既存システムの移行や開発費の抑え方も、よく問われる論点です。

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

両者は別の考え方で、力点を置く場所が異なります。

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

要件整理と設計は、セットで進めます。

オニオンアーキテクチャなら最初からマイクロサービスにすべきですか？

必ずしもマイクロサービスにする必要はありません。まずモジュラーモノリスで、業務の境界と依存方向を明確にします。

サービス化するのは、効果が明確な境界だけです。効果が見込めるのは、4つの点に限られます。

• チーム分割
• 独立デプロイ
• 負荷分散
• 障害分離

必要性を数値や運用課題で説明できるかが、判断の基準になります。

分散構成では、監視やデータ整合性の負担が増えます。通信障害やリリース管理の手間も増えます。

既存システムをオニオンアーキテクチャへ移行できますか？

移行は可能ですが、全体を一括で書き換える必要はありません。段階移行が現実的で、押さえる点は3つあります。

• 重要業務：読み取り連携や外部アプリから切り出します。
• 旧データの変換：新しい用語へ変換するアダプターを設け、並行稼働とデータ照合を行います。
• 旧仕様が不明な場合：現行の入出力と業務ルールをテストに記録し、振る舞いを保ちながら内側のモデルを置き換えます。

オニオンアーキテクチャのシステム開発費を抑える方法はありますか？

独自性の高い業務を1つに絞り、標準化できる会計や人事はSaaS・パッケージと連携します。全社機能やマイクロサービスも、最初からは作らない方法です。

小規模PoCを300万〜800万円程度で行い、ドメインモデルとテストの有効性を確かめてから拡張すると、不要な作り込みを避けやすくなります。

ただし、テスト、移行、監視、セキュリティを削るだけでは、将来費用が増えます。削る範囲と残す品質基準を分けて判断します。

まとめ

DomainとApplicationに業務判断を集め、DB、外部API、認証、画面を外側のアダプターへ隔離します。

業務ルールを単体テストで確かめられ、DBや外部サービスの変更による影響も管理しやすくなります。

層を増やすこと自体は目的ではなく、長く使い、変更が続く業務に適用することが大切です。

6フェーズの終了条件の合意

各フェーズを終える前に確かめる内容を、フェーズの順に並べます。

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

最重要の1業務からの相談

小規模PoCは300万〜800万円、中規模は800万〜2,000万円、大規模な基幹刷新は3,000万円〜1億円超が推定レンジです。

まずは最重要の1業務から相談し、業務ルールや連携の条件を見ながら、この幅を詰めていきます。移行や非機能要件についても、同じように調整していきます。

見積もりは、工程別の工数と成果物を確認します。保守範囲やソースコードの権利、セキュリティの責任も、同じ条件で確かめます。価格だけでなく、将来の変更と運用も含めて比べます。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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