クリーンアーキテクチャのシステム開発は、業務ルールと受入基準をそろえ、契約と見積を整えたうえで、試作と段階リリースで確かめながら発注するのが基本です。変更や運用への備えも、発注の段階から考えておきます。
発注形態、要件整理、契約、開発の進め方、費用と委託先の見極めを順に説明します。
▼全体ガイドの記事
・クリーンアーキテクチャのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
クリーンアーキテクチャのシステムを発注する前に知るべき全体像
クリーンアーキテクチャは、業務ルールを画面、DB、クラウド、外部APIなどの技術詳細から分離する設計方針です。製品やクラウドサービスの名前ではありません。そこで、発注時は「クリーンアーキテクチャで作る」と伝えるだけでなく、守りたい業務や変更に強くしたい部分も示します。
業務ルールを守るための設計方針
設計では、業務ルールを中心に置き、技術詳細との境界を分けます。
- 中心に置くもの：受注確定、与信判定、承認完了などのユースケースとドメインルール
- 処理の境界：画面からDBを直接呼ばず、ユースケースを介し、外部接続はポートとアダプターに閉じ込める
- 変更の影響：DBやREST APIの連携方式を変えても、業務ルールへの影響を限定しやすい
ただし、採用だけで低コスト、高性能、マイクロサービスになるわけではありません。小規模で単純なCRUDには、層やインターフェース、テストコードが増えるぶん、初期工数が過剰になる場合があります。業務ルールが複雑で、長期運用や仕様変更がある案件ほど、採用理由を説明しやすくなります。
向く案件と採用を限定したい案件
業務ルールや変更の頻度に応じて適用範囲を分けると、品質と予算を調整できます。
- 適用しやすい案件：部門横断の業務、制度変更の多い基幹システム
- 連携が多い案件：複数SaaSや会計・決済・物流と接続するシステム
- 段階刷新する案件：既存システムを少しずつ置き換える案件
- 限定適用する案件：数画面の申請フォームや短期利用のキャンペーンサイト
適用する案件では、機能追加の影響を調べやすく、回帰テストも行いやすくする狙いがあります。一方で、小規模案件では、重要な業務ルールにドメイン層と自動テストを使い、単純な参照画面は簡素化する方法もあります。
発注形態の選び方：スクラッチ・パッケージ・SaaS
業務の独自性や変更の頻度が高ければスクラッチを、標準化できる部分が多ければSaaSやパッケージを優先します。クリーンアーキテクチャは、パッケージやSaaSの外側に作る独自の連携・拡張部分にも使えます。まず、設計手法を選ぶ前に、標準機能に業務を合わせるか、自社固有の資産として作るかを業務ごとに決めます。
独自業務のスクラッチと標準化業務のSaaS
選び方の基準は、業務ルールの独自性と、標準機能への適合度です。
- スクラッチ：承認、料金計算、在庫引当が競争力に直結する場合
- SaaS：勤怠、経費、一般的なワークフローを標準化できる場合
- パッケージ：標準機能を使い、自社向け設定や追加開発も行う場合
スクラッチでは、ドメインモデルやユースケースを設計します。そのうえで、外部連携、データ移行、監査ログまでを設計の対象にします。
SaaSでは、差別化する部分だけをAPI連携やアドオンで補うと、導入期間と保守の負担を抑えやすくなります。ただし、SaaSの内部を自由に変えられるとは限りません。そのため、RFPでは拡張サービスの境界、API停止時の復旧、製品変更時のテストを確かめておきます。
最初からのマイクロサービス分割と段階移行の選択肢
マイクロサービス化や既存システムの刷新は、段階を分けて進められます。
- クリーンアーキテクチャとマイクロサービスは別の概念なので、まずはモジュラーモノリスから始めます。
- 負荷、組織体制、障害分離の必要性がはっきりした領域に限って分けます。
- 既存システムの刷新では、Strangler Figで受注照会、在庫引当、請求の順に置き換えます。
- 旧システムと連携しながら移行し、並行稼働、移行リハーサル、切り戻し条件を先に決めます。
サービスを増やすと、ネットワーク、認証、監視の費用が増えます。さらに、データ整合性やリリース管理の費用も加わります。
IBMが公開するAPIS ITの事例では、10年前のSOAPサービスを.NET 8のREST APIへ刷新しました。同事例では、クリーンアーキテクチャ化によって、コードと依存関係が30%減り、レイヤーが50%簡素化したとされます。
これは特定案件の結果です。そのため、提案を比べるときは、自社の変更時間や障害対応時間に置き換えて確認します。
RFPと要件整理で開発会社に伝える内容
RFPは、提案条件をそろえて比較する共通資料です。IPAの要件定義実践入門は、背景や目的、求めるシステム、提案・契約手続きを挙げています。
RFPには、業務フローや要件一覧、課題一覧に加えて、現行システム構成図も補足として添えます。設計用語よりも、業務と受入基準を中心に書きます。
RFPに書く目的、業務、非機能、成果物、前提条件
提案条件の抜けを防ぐため、RFPには次の情報を記載します。
- 目的：課題、目標、効果の測定者
- 業務：対象部門、利用者数、権限、例外処理
- データと連携：マスタ、データ量、保存期間、既存システム
- 非機能：稼働時間、応答時間、同時利用、バックアップと復旧目標
- 成果物：仕様書、コード、テスト結果、CI/CD、IaC、運用・教育資料
目的は「受注処理を速くする」で止めず、入力から出荷指示までの期間を何日から何日にするかまで決めます。そのうえで、手作業をどの程度減らすか、誰が効果を測るかを整理します。
監視や障害通知、個人情報の扱いも明記します。さらに、アクセス制御、脆弱性診断、ログ保存期間も書き添えます。「開発一式」は、追加費用や引き継ぎの問題につながりやすい表現です。
代表ユースケースと受入基準による設計品質の確認
正常系と例外系を含む代表シナリオを一通り通して、業務担当者と開発会社の認識をそろえます。
- 受注確定：入力検証、在庫・与信判定、承認、外部API
- 失敗時：権限不足、外部サービスのタイムアウト、依頼の再送
- 記録と通知：二重登録、監査ログ、通知の扱い
受入基準には、ドメイン層がWebフレームワークやDBに直接依存しないことも含めます。そのうえで、外部接続をインターフェースの外に置き、ユースケース単位でテストできるかを確かめます。
依存の方向は、レビューで確かめる項目として受入基準に含めます。カバレッジの数値だけを合格条件にすると、意味のないテストが増えることがあります。そこで、重要な業務ルールを、テストケースと業務シナリオで説明できる状態を目指します。
クリーンアーキテクチャのシステム開発を外注する進め方
企画からリリースまでを一続きの計画にします。業務責任者を決め、毎週のレビューで仕様を確認します。また、優先順位や未決事項、変更の影響も同じ場で確かめます。
業務用語や境界を早い段階でそろえておかないと、後工程で層だけが増え、業務ルールが曖昧になります。
要件定義での業務用語と境界の決定
画面一覧より先に業務イベントとルールを整理し、概念の境界を決めます。
- 「注文」と「受注」を同じ意味で使うかどうか。
- 受注確定後の価格変更や、返品時の在庫・請求処理の扱い。
- 顧客、商品、取引、請求を、境界づけられたコンテキストとして整理する。
税率や承認経路、料金計算のように変更の頻度が高いルールは、ユースケースやドメインに寄せて扱います。一方で、メール送信やDBアクセスは外側のアダプターに置き、変更の理由が異なるものを分けます。
重要業務のPoCと縦切りによる提案内容の検証
提案書だけで実践力を判断するのは難しいため、重要業務の小さな試作で確かめます。
- 対象：受注、承認、在庫引当などの最重要業務
- 縦切り：画面、API、業務ルール、DB、外部連携、監査ログ
- 確認：利用者向けデモ、外部API障害や権限エラーのテスト
PoCは全体を作るものではないため、目的と範囲、期間を先に合意します。さらに、成果物と、製品版へ再利用するコードの扱いも決めておきます。
コードを捨てるか本開発へ引き継ぐかで、必要なテストと文書化の費用が変わります。
生成AIや自動化ツールの提案では、人のレビューや機密情報の入力制限も評価します。加えて、生成物の著作権と脆弱性の確認を、提案の評価に含めます。
テストと運用を含む段階リリース
テストと運用の担当、時期、提出物を決め、納品直前に確認が集中しない計画にします。
- テスト：ドメイン単体、ユースケース、DB・外部APIの統合、画面E2E
- 品質確認：性能、セキュリティ、障害復旧、移行、権限
- 移行と運用：リハーサル、並行稼働、教育、窓口、切り戻し
誰がどの環境で何を確認し、結果をどの形式で出すかは、RFPと契約書に定めておきます。
リリース後は、エラー率や処理時間、利用率、手作業の削減量などをKPIとして設定します。その数値は、保守契約の定例会で振り返ります。さらに、運用設計と引き継ぎも開発の範囲に含めます。
契約形態の選び方：請負と準委任
成果物と完成条件を定めやすい工程は請負、業務理解や設計を深める工程は準委任が基本です。たとえば、要件定義は準委任、設計・開発は請負、リリース後は準委任のように、工程ごとに使い分けます。なお、IPAの「ユーザのための要件定義ガイド」は、ユーザー企業が主体となり、準委任を基本とする考え方を示しています。
請負の完成条件と準委任の進め方・役割
契約形態ごとに、発注者と受託会社それぞれの責任を定めておきます。
- 請負：納品、検収、契約不適合、納期、変更管理
- 準委任：稼働時間と役割、会議体、レビュー成果、記録、進捗報告
請負の検収条件は、依存の方向と代表ユースケースのテストから決めます。成果物や性能、セキュリティの基準も、検収条件に分けて書きます。
要件が未確定のまま固定価格にすると、変更のたびに追加費用や納期の延長が起きやすくなります。一方で、準委任では、発注者の意思決定が遅れると受託会社の作業時間が増えることがあります。そのため、プロダクトオーナー、業務責任者、技術責任者を置き、未決事項の期限と決裁者を定めておきます。
成果物、知的財産、終了時の引き継ぎに関する契約条件
契約が終わったあとも保守を続けられるよう、成果物と権利の範囲をはっきりさせます。
- 成果物：納品後の保守に必要な実装資産と設計資料
- 運用資料：バックアップ手順、データ出力方法
- 権利：著作権、第三者ライセンス、再利用部品、著作権法第27条・第28条
契約時には、ソースコードや設計書を引き渡しの対象に含めるかを確かめます。API仕様やテストコードも、同じ観点で確認します。CI/CDの設定、Infrastructure as Code、監視設定は、別に引き渡しの対象に含めるかを確かめます。
秘密情報の管理は法務担当と整理し、別の会社へ保守を移せるかは発注前に確認します。
保守の条件では、一次対応や脆弱性修正の期限、SLAを記載します。クラウドや監視の費用、バックアップ、追加開発の単価も明記します。再委託先と終了時の移行支援は、分けて定めます。
基盤を提供会社が管理している場合でも、認証・認可やアプリの責任は残ることがあります。また、ログや監視、第三者ライブラリの更新は、開発側や利用企業の責任に含まれる場合があります。
OWASPの「Secure Cloud Architecture」は、共有責任を踏まえた確認の考え方を示しています。確認項目には、認証とログ・監視のほか、コードセキュリティやライブラリ更新があります。
クリーンアーキテクチャのシステム発注費用相場
クリーンアーキテクチャ単体の公的な価格表はありません。費用は、機能数や業務の複雑さ、外部連携で変わります。
さらに、移行や利用者数、非機能要件も費用を左右します。体制や納期も、費用に関わる要素です。
SIA株式会社の2026年7月更新記事では、一般開発の場合、小規模は100万〜300万円、中規模は500万〜1,000万円としています。大規模は1,000万円〜数千万円以上、人月単価は60万〜200万円程度です（出典：SIA株式会社「システム開発の費用・相場【2026年版】」）。
業務規模別の推定費用：350万〜1億円以上
次の金額は、発注を検討するための推定です。ドメイン設計や設計文書、テスト自動化を含め、CI/CDと監視も前提に入れています。
- 小規模：単一業務の社内システムは350万〜850万円、3〜5か月
- 中規模：複数ロールや外部APIを扱い、800万〜1,800万円、5〜9か月
- 大規模：基幹連携、大量データ、段階移行を含み、2,000万〜1億円以上、8〜18か月以上
これらは、一般相場や業務システムの規模別データをもとにした推定です。同じ方式だけの市場統計ではありません。
単純なCRUDより要件定義や設計が深くなるため、初期工数が10〜25%増える可能性を仮置きします。この幅は、案件ごとの見積で確かめてください。提案会社には、工程と工数の内訳を確認します。
見積の工程別内訳：要件定義、実装、テスト、移行
見積は、開発一式でまとめず工程別にして、前提と作業範囲を比べます。
- 設計・構築：要件定義、ドメイン設計、アーキテクチャ、画面・API
- 開発・検証：実装、単体、結合・E2E、性能・セキュリティテスト
- 移行・運用：データ移行、教育、リリース、保守
業務システムQ&A整理（出典：リサーチノート内のローカル一次Q&A）では、開発費の大部分は人件費とされます。比率は、要件定義、設計・環境構築、実装、テストで異なります。計上の方法も、会社や案件によって変わります。
保守運用は、初期開発費の年15〜25%程度という目安が紹介されることがあります。ただし、監視やクラウド、脆弱性対応を含むかどうかで変わります。さらに、法改正や問い合わせ、追加開発、SLAの扱いでも差が出ます。
保守費率だけで判断せず、5年間の総保有コストを比べます。変更時の調査や手作業のテストによって、費用や納期が膨らむ場合もあります。
委託先選定と見積比較で確認すべきポイント
設計手法の実績だけで決めず、業務理解やモデリングを評価します。そのほか、テストや運用、移行、セキュリティも確かめます。
担当アーキテクトが、要件定義から保守まで同じチームで関わるかを確認します。再委託の範囲や、コードとIaCの引き渡し条件も確かめておきます。
提案会社への具体例つきの質問：設計・テスト・障害対応
技術名の説明だけでなく、業務シナリオに沿った回答を求めます。
- 業務ルール：受注確定をどの層に置くか
- 変更と障害：DB変更時のテスト、API停止時の表示
- 確認範囲：依存方向、リトライ、冪等性、ログ、監査証跡
匿名化した設計書や、テスト計画、コード、障害対応の振り返りを確認します。実物の提示が難しければ、仮想の受注シナリオで設計レビューを行います。
正常系だけでなく例外系も見て評価します。デモでは、権限のない操作や二重送信、連携障害、移行後の照合を試します。
見積比較での前提条件と除外項目のそろえ方
複数社には同じ条件を渡し、作業範囲をそろえて比較します。
- 共通条件：RFP、ユースケース、利用者数、データ量、納期
- 体制と検証：要件定義、設計者の関与、レビュー、テスト環境
- 移行後：リハーサル、監視、教育、保証、保守
設計やテストが含まれない安い見積は、価格の差より作業範囲の差を示している場合があります。比較表には、初期費用や追加変更の単価、保守を書きます。さらに、クラウドとライセンスの実費、障害対応時間、SLAも記載します。
納品物や再委託費、契約終了時の移行費も並べます。そのうえで、前提条件を発注者側の作業とリスクに分けて書きます。前提条件の例には、「業務ルールは発注者が提示」「外部API仕様は確定済み」「データ品質は保証しない」などがあります。
なお、数字の根拠を質問できる会社は、契約後の変更管理も透明になりやすいです。
よくある質問
発注時の費用や技術、適用範囲、契約条件について回答します。
クリーンアーキテクチャのシステム開発は通常より高くなりますか？
初期費用は、単純なCRUD開発より高くなる可能性があります。設計やテスト自動化、文書化に工数がかかるためです。
10〜25%程度の上振れは、市場統計ではなく案件条件からの推定です。提案の内訳で確かめてください。
変更の頻度が高い場合は、影響調査や回帰テストを減らせる可能性があります。そこで、5年TCOで判断します。
小規模な社内システムでもクリーンアーキテクチャは必要ですか？
すべての小規模システムに必要なわけではありません。変更が少なく、ルールも単純なら、シンプルな構成が適しています。
利用者が少なくても、料金計算や承認、在庫が複雑なら、重要な業務だけに適用できます。権限や法改正、外部連携が複雑な場合にも、同じように考えられます。
クリーンアーキテクチャ対応をうたう開発会社はどう選びますか？
用語の実績だけでなく、業務理解やユースケース設計を確認します。加えて、テストや障害対応、レビュー、引き継ぎも確かめます。
担当アーキテクトの関与や、依存方向とテスト条件の説明を質問します。さらに、コード、IaC、設計書の引き渡し条件も確認します。
可能であれば、匿名化した実績や、仮想シナリオの設計レビューを見て判断します。
まとめ
設計手法の指定そのものを目的にせず、業務ルールと将来の変更や運用を守る条件として扱います。独自業務と標準化できる業務を分けたうえで、スクラッチやパッケージ、SaaSのほか、段階移行も比べます。
発注前のRFPと受入基準の確認
RFPでは、目的や業務フロー、ユースケースを具体化します。さらに、非機能や成果物、移行、セキュリティ、運用も具体的に書きます。
設計用語の確認で終わらせず、依存方向、テスト、障害対応、引き継ぎを受入基準に含めます。
見積の初期費用と5年TCOの比較
費用と契約後の負担を、工程と運用期間に分けて比べます。
- 見積内訳：要件定義、設計、実装、テスト、移行、教育、保守を分け、前提と除外項目も比べる
- 5年TCO：変更、障害、クラウド、脆弱性対応、契約終了時の移行を含めて委託先を判断する
- 契約と運用：工程ごとに請負と準委任を使い分け、変更時間や障害復旧も確認する
▼全体ガイドの記事
・クリーンアーキテクチャのシステム開発の完全ガイド
▼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を創業。