オニオンアーキテクチャのシステム開発会社は、業務ルールからドメイン設計、テスト、クラウド運用まで一つの流れで説明できるかを基準に比べると選びやすいです。
株式会社riplaを最初に、業務システムの設計・開発・運用を相談しやすい実在企業5社を加えた計6社を紹介します。いずれも、採用を公表した会社の順位ではなく、公開情報から得意領域を整理したものです。
▼全体ガイドの記事
・オニオンアーキテクチャのシステム開発の完全ガイド
- 業務ルールとドメイン設計
- テスト・クラウド運用を含む6社比較
- 公開情報から相談先を見極める方法
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
オニオンアーキテクチャのシステム開発でパートナー選びが重要な理由
オニオンアーキテクチャは、プロジェクトをDomainやInfrastructureといったフォルダに分けただけでは完成しません。受注、在庫、請求などの業務ルールを見つけ、どの処理をシステムの中心に置くかを決めなければなりません。そのため、技術だけでなく、業務理解と要件定義の力が成果を左右します。
適切なパートナー選定が成否を分ける理由
オニオンアーキテクチャでは、中心のDomain層が業務上の意味を担います。たとえば、顧客や契約、受注といった概念がここに当たります。在庫や請求も、この層で扱う業務上の意味です。
業務担当者へのヒアリングが浅いまま実装を始めると、データベースの項目を業務ルールと取り違え、後から例外処理や権限管理が外側へ散らばることがあります。そうなると、設計を分けたように見えても、変更に強い状態にはなりません。そのため、相談時は次の3点で、業務の理解が設計にまで届いているかを確かめます。
- 業務ルールの扱い：受注確定から請求までの流れを、どのようにモデル化しているか
- 依存の向き：業務の中心が、データベースや外部サービスに依存していないか
- テストと外部連携：単体テストや外部連携も含めて、一つの設計として説明できるか
Microsoft Learnは、DDDや依存関係逆転の原則に基づく構成が、オニオンアーキテクチャやクリーンアーキテクチャなどの名称で説明されてきたと整理しています（出典: Microsoft Learn「一般的なWebアプリケーションアーキテクチャ」）。そのため、会社名の知名度よりも、設計の考え方を具体的に確かめる必要があります。
発注前に確認すべきポイント
提案依頼では、「オニオンで作れますか」と聞くより、具体的な質問で判断します。たとえば、「受注確定から請求までの業務ルールを、どのようにモデル化しますか」「DBを変更したとき、Domain層への影響をどう検証しますか」「外部決済や会計サービスを差し替えるとき、何を納品しますか」と尋ねます。
回答に、境界づけられたコンテキストやユースケース、ポートとアダプターが含まれる会社は、比較しやすいです。テスト方針や移行計画まで示されていれば、なお判断しやすくなります。
さらに、開発後の運用担当者や、ソースコードとIaCの引き渡し方を事前に確かめます。脆弱性対応や再委託、保守終了時の切り替え条件も、合わせて決めておきます。設計の美しさだけでなく、社内にノウハウを残せる契約かどうかが、5年後の保守費用と変更速度を左右します。
株式会社ripla｜コンサルから開発まで一気通貫で支援
riplaは、コンサルティングから開発まで一気通貫で支援できる企業です。IT事業会社として社内DXを推進してきた経験を活かし、ビジネスの成果創出とシステムの定着支援に強みがあります。
営業や顧客管理の仕組みから、生産・販売管理まで、幅広い基幹システムの構築と導入の実績があります。また、企業の業務要件に合わせて、柔軟に対応できる体制を整えています。
特徴と強み
riplaに相談する際は、業務上の成果から逆算して、アーキテクチャの適用範囲を決められる点が強みです。
たとえば、受発注の不変条件や承認フローはDomainとApplication側で守り、標準化できる会計や人事はSaaSやパッケージと連携させる構成も検討できます。
最初から全社をマイクロサービスへ分割せず、モジュラーモノリスとして始める選択肢も含めて検討するため、費用と変更リスクを並べて比べやすくなります。
得意領域と相談時の確認事項
独自の業務フローを持つ企業や、複数部門のデータをつなぎたい企業、現場の定着まで支援してほしい企業に向く候補です。
相談時は、見積もりに業務イベントの整理や、用語集・ドメインモデルの作成が含まれるかを見ます。さらに、ユースケース単位のテスト、データ移行、リリース後の伴走も、対象に入るか確かめます。
大切なのは、自社の業務知識をどうコードとテストへ落とし込むか、そして、どこまでを社内へ引き渡すかを具体化することです。実装実績の数は、その判断材料の一つです。
株式会社NTTデータ｜大規模・高信頼の業務システムを総合支援
NTTデータは国内大手のITサービス企業で、公共や金融から製造、通信まで、幅広い分野でシステム開発と運用を手がけています。
公式のクラウドサービス情報では、ハイブリッド環境について、企画から開発・運用まで支援すると説明しています。ハイブリッド環境は、オンプレミス、プライベートクラウド、パブリッククラウドなどを組み合わせた環境です。
特徴と強み
複数ベンダーが関わる基幹刷新、厳格な可用性・セキュリティ要件、既存資産を含むクラウド移行を一括して管理したい場合に候補となります。
大規模案件では、Domain層をどのチームが持つか、共通部品と業務固有の部分をどう分けるか、設計判断をどの会議体で承認するかが重要です。
ハイブリッドクラウドを採用する場合は、実行環境の違いをInfrastructureのアダプターへ閉じ込められるかを、提案書で確かめます。
得意領域・実績から見る適性
金融や公共など、監査・権限・災害対策を重視するシステムでは、開発だけでなく運用設計まで含めて比べやすい会社です。
大規模な体制では、組織や工程が大きくなりやすいため、小規模なPoCでは意思決定の速さと体制が予算に合うかを見る必要があります。
RFPには、最初に検証する業務の境界と、将来の内製化の範囲、ソースコードとテスト資産の納品条件を明記しておくと、提案の差が見えやすくなります。
富士通株式会社｜業務アプリケーションのモダナイズと自動化
富士通は、業務アプリケーションの開発基盤、クラウド、運用サービスを組み合わせ、既存システムのモダナイズを支援する企業です。公式の「FUJITSU Hybrid IT Service Digital Application Platform」では、業務システムの開発に加え、ビルドやテストの自動化、API管理などを提供すると説明しています。
特徴と強み
オニオンアーキテクチャを長期運用するには、中心ロジックの単体テストに加えて、外側との接続を確かめる統合テストも必要です。外側には、APIやDB、認証のほか、メッセージングもあります。
富士通のように開発プロセスやCI/CDの自動化を含めて相談できる会社なら、設計ルールをレビューとパイプラインに組み込み、担当者が替わっても品質を保つ方法を検討できます。
既存アプリを全面改修せず段階的に移行したい場合は、どの境界から切り出すかを先に確かめます。
得意領域・実績から見る適性
既存の業務アプリケーションをクラウドへ移行しながら、リリース頻度とテストの再現性を高めたい企業に向く候補です。
見積もりでは、アプリケーションの改修費と、CI/CD環境や監視の費用を分けてもらいます。ログ保管やテストデータ管理、運用教育の費用も、別々に示してもらうと比べやすくなります。
オニオンの層分けが開発基盤の標準にどう組み込まれるかを、コードレビューの基準と納品物のサンプルで確かめておくと安心です。
日本電気株式会社（NEC）｜標準化を軸に業務改革とクラウド導入
NECは、業種向けの基幹システムやクラウドサービス、業務改革支援を幅広く提供する国内大手企業です。
公式に公開しているハンシン建設の事例では、SaaS型ERPの「建設クラウド」を導入し、標準業務プロセスを活用して業務を見直した経緯が紹介されています。
特徴と強み
業務を標準機能へ寄せられる部分と、企業固有の競争力として残す部分を分けたい場合に、相談しやすい候補です。
オニオンアーキテクチャを適用する場合は、標準化できる会計や人事をSaaSやパッケージに任せる方法があります。一方で、独自の受注・工事・在庫などは、個別のアプリケーションとして設計できます。
標準機能へ業務を合わせる際は、必要な業務変更を現場が受け入れられる計画にできるかも重要です。
得意領域・実績から見る適性
法改正や業界標準への対応を継続しながら、基幹業務を安定させたい企業に適しています。ハンシン建設の事例では、法改正やインフラ更新に伴う改修の負担を、サービス側で都度対応し、運用コストを平準化する考え方が示されています（出典: NEC「株式会社ハンシン建設様 導入事例」）。
自社独自の領域をオニオン構成で残す場合は、標準サービスとのAPI連携や、データの所有権、将来の切り離し方まで提案してもらいます。
SCSK株式会社｜パッケージと独自業務を切り分けた刷新
SCSKは、基幹システムやクラウド、ローコード開発を組み合わせ、運用サービスも含めて企業のIT刷新を支援する会社です。淺沼組の公式事例では、会計や人事給与にはクラウドERPを採用し、営業・工事系の独自業務はローコード開発基盤FastAPPで構築する方針が紹介されています。
特徴と強み
業務すべてをフルスクラッチする予算は抑えつつ、独自の業務ノウハウはシステムへ残したい企業に合う候補です。
オニオンアーキテクチャでも、会計SaaSやERPをInfrastructure側のアダプターとして扱い、独自ドメインのユースケースを別のアプリケーションとして保護する設計を考えられます。
ローコード部分とコード部分の境界や、テストの自動化を見ます。将来ベンダーを変えるとき、データを取り出せるかも確かめます。
得意領域・実績から見る適性
淺沼組の事例では、FastAPPの採用によってランニングコストを従来比で約3分の2に圧縮したと説明されています（出典: SCSK「淺沼組様 基幹業務システム刷新事例」）。標準業務と独自業務を切り分けて、カスタマイズ費用と運用負荷を抑える考え方の参考になります。ただし、この数字はオニオンアーキテクチャの費用効果を示すものではありません。
見積もりでは、ライセンスとローコード開発、個別APIを分けて比べます。移行や保守も別の項目として比べると、見通しが立ちやすくなります。
TIS株式会社｜基幹システムからクラウド基盤まで幅広く対応
TISは、公式の企業情報で、基幹システムから競争力を生むアプリケーション、システム基盤のプラットフォームまで、幅広いITサービスを提供していると説明している企業です。
プラットフォームサービスでは、パブリッククラウドやプライベートクラウドを組み合わせた提案を行っています。セキュリティやマネージドサービスなども、組み合わせに含まれます。
特徴と強み
複数の業務システムとクラウドを接続し、セキュリティや運用監視まで一体で整えたい企業に向く候補です。
オニオンアーキテクチャを採用する場合は、アプリケーションのポートをどのチームが定義し、クラウド、認証、データ連携の実装をどのアダプターへ配置するかを設計書で確認します。
技術選定では、C#、Java、TypeScript、Goなどの流行にとらわれず、社内人材と保守会社が扱えるかで判断します。
得意領域・実績から見る適性
大企業・中堅企業の複数部門をまたぐ基幹連携や、クラウドと既存オンプレミスの併用を検討する場合に、比較対象へ入れやすいです。
相談時は、業務モデルを自社の言葉で管理できるか、開発標準やレビュー記録を納品できるかを確かめます。あわせて、障害時の一次対応について、クラウド事業者とどこまでを誰が受け持つかが明確かも確認します。
特にデータ連携が多い案件では、失敗時の再実行、重複登録、監査ログまでユースケースとして定義してもらいます。
オニオンアーキテクチャのシステム開発会社を選ぶポイント
6社を比べるときは、まず自社の業務の複雑さや既存資産から候補を絞ります。社内の開発体制、予算と期間も合わせて見ると、候補をさらに絞れます。会社規模や知名度は、その後で確かめます。
オニオンアーキテクチャは、複雑な業務ルールを長く育てるシステムほど効果を出しやすい一方、単純なCRUDや短期の社内ツールでは初期の設計コストが過剰になりやすいです。
実績と経験の確認方法
実績は「オニオンアーキテクチャ何件」という数だけでなく、似た業務の複雑さで確認します。たとえば、受注の状態遷移や在庫引当があるかを聞きます。複数部門の承認や会計連携、個人情報の権限管理が含まれるかも確かめます。
公開できない案件でも、匿名化した構成図やテスト方針、移行前後の受け持ち範囲なら、説明できることがあります。また、PoCから本番まで同じ担当者が関われるかを確かめます。要件定義を別会社へ丸投げしないか、業務担当者とのワークショップを何回行うかも、あわせて聞きます。
要件定義書や用語集、ドメインモデルは、一つずつ示してもらいます。API仕様やテスト仕様書、運用手順書も示してもらい、見積書の「一式」を減らすことが大切です。
技術力と専門性の評価
技術評価では、Domain層がUIやORM、DBに依存していないかを確認します。外部APIについても、同じ観点で見ます。インターフェースを中心側で定義し、Infrastructure側が実装する依存関係逆転になっているかを見ます。単体テストをDBなしで高速に動かせるか、統合テストと契約テストの範囲を説明できるかも、判断の材料になります。
認証・認可や監査ログ、暗号化は、アーキテクチャを分けるだけで自動的に安全になるものではありません。バックアップや脆弱性対応も同様です。開発会社には、設計時の脅威モデリングや脆弱性診断を、どこまで担当するかを確かめます。ログ監視やインシデント時の連絡網についても、担当範囲を確認します。
個人情報を扱う場合は、個人情報保護委員会が示す内容を要件に落とします（出典: 個人情報保護委員会「標的型メール攻撃や、その他不正アクセス等による個人データの漏えい等の被害を防止するために」令和7年7月更新）。要件の例には、アクセス制御や暗号化、被害を最小化する仕組みがあります。従業者への研修なども、あわせて要件として扱います。
プロジェクト管理体制の確認
開発会社の選定では、技術者のスキルだけでなく、意思決定の仕組みと契約形態を見ます。業務部門と情報システム部門、ベンダーのうち誰が優先順位を決めるか、変更要求をどの単位で見積もるか、受入基準とリリース判定を誰が承認するかを、先に決めておく必要があります。準委任でアジャイルに進める場合も、成果物と品質基準があいまいにならないようにします。
費用は、オニオン固有の公的な相場統計があるわけではありません。2026年時点の一般的な業務システムの目安として、1業務を対象にしたPoCは300万〜800万円で3〜5か月です。中規模業務システムは800万〜2,000万円で6〜10か月、大規模な基幹刷新は3,000万円〜1億円超で12〜24か月以上を見込む考え方があります。
これは推定のレンジで、業務ルールの複雑さや連携数によって変動します。データ移行や非機能要件でも変わります。初期費用のほかに、運用費は開発費の年15〜25％程度として見込みます。そのうえで、監視やクラウド、バックアップの費用と、法改正や脆弱性対応の費用を分けて確認します。
よくある質問（FAQ）
開発会社へ相談する前に、よく寄せられる疑問を取り上げます。オニオンアーキテクチャを導入しても、それだけで高品質になるわけではありません。そのため、適用範囲と検証方法を具体的に考えることが大切です。
オニオンアーキテクチャのシステム開発会社は何を基準に選べばよいですか？
業務モデリングや依存関係逆転、テスト自動化を、一つの提案として説明できるかで選びます。
既存システム連携やクラウド運用も、同じ提案の中で語れるかを確かめます。
オニオンという名称の採用実績だけでなく、匿名化した設計書やテスト方針、担当者の経験を見ると、自社に合う会社を見分けやすいです。納品後の内製化支援まで確認すると、さらに判断材料がそろいます。
オニオンアーキテクチャを採用すると費用は高くなりますか？
ドメイン分析やインターフェース設計が増えるため、単純なCRUDより初期費用が高くなる可能性があります。マッピングや単体テストといった作業も加わります。
この設計を長期運用するなら、DB変更や外部サービス変更の影響を局所化でき、将来の改修費やテスト費を抑えられる場合があります。
また、PoCで最重要の業務だけを検証し、標準化できる機能はSaaSやパッケージに任せる方法もあります。過剰投資を避けやすいです。
オニオンアーキテクチャならマイクロサービス化も必要ですか？
マイクロサービス化は必須ではありません。オニオンアーキテクチャは主にアプリケーション内部の依存方向を整える考え方であり、1つのデプロイ単位であるモジュラーモノリスにも適用できます。
サービスを分割すると、データ整合性や分散トランザクション、監視の費用が増えます。デプロイや障害対応の費用も増えます。そのため、境界が明確になり、独立運用のメリットが出る段階で検討します。
発注契約でソースコードや保守について何を確認すべきですか？
ソースコードだけでなく、設計書やIaC、CI/CD設定の引き渡し範囲を明記します。テストコードとテストデータの扱いも、契約に書いておきます。API仕様と運用手順書についても、引き渡しの範囲を決めておきます。
著作権の帰属や利用許諾、第三者ライブラリのライセンスは、契約に含めます。
再委託先、脆弱性・法改正対応の責任、保守終了時の移管期間と費用も、同じ契約で扱います。特に、Domainモデルと業務ルールの文書を自社で使える状態にしておくと、ベンダーロックインを減らせます。
まとめ
オニオンアーキテクチャのシステム開発会社を選ぶときは、設計パターンの採用有無だけで判断しないことが大切です。
業務ルールを中心に据えた要件定義と、依存方向を守る実装を見ます。そのうえで、テスト自動化や外部連携を、移行から運用までの流れで比べます。
株式会社riplaやNTTデータ、富士通などの6社は、それぞれ支援の得意領域が異なります。そのため、自社の規模と課題に合わせて相談先を絞ります。
最重要業務から始めるPoC
初回相談では、全社刷新の結論を急がず、最も変更が多く事業への影響が大きい業務を一つ選びます。
受注や在庫の業務が候補になり、承認や請求の業務も挙がります。
300万〜800万円、3〜5か月程度のPoCという推定レンジを起点にします。そのうえで、業務モデルやユースケース、テストを検証します。外部連携や運用監視も確かめ、本開発へ広げる条件を合意します。見積もりは、要件定義やドメイン設計、UI/APIに分けてもらいます。インフラや移行の費用、教育や保守も、それぞれ別に示してもらいます。
業務と技術をつなげた相談
業務部門が抱える例外や判断基準を、Domainモデルとテストへつなげられる会社を選ぶことが、オニオンアーキテクチャを活かす近道です。
SaaSやパッケージ、スクラッチを組み合わせ、必要な領域だけをカスタム開発すると、初期費用と将来の変更しやすさのバランスを取りやすくなります。
候補会社には、設計の考え方だけでなく、運用や契約の条件まで具体的に示してもらいましょう。内製化の条件や納品物も同じ水準で挙げてもらうと、比べる材料がそろいます。
▼全体ガイドの記事
・オニオンアーキテクチャのシステム開発の完全ガイド
▼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を創業。