クリーンアーキテクチャのシステム開発は、要件整理から定着まで、6つのフェーズを順に進めます。各フェーズで業務ルールを守り、変更に強い構造を目指します。全体像は、下の完全ガイドの記事もご覧ください。
▼全体ガイドの記事
・クリーンアーキテクチャのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
クリーンアーキテクチャのシステム開発の全体像
クリーンアーキテクチャでは、業務ルールとユースケースを中心に置きます。画面やDB、クラウド、外部APIなどは、交換可能な部品として扱います。
求められるのは、業務上の判断を見つけ、技術詳細との境界をチームで守ることです。最初から理想の構造を完成させる必要はありません。
クリーンアーキテクチャの定義
クリーンアーキテクチャは、中心に置いた業務ルールを、画面やDB、クラウドなどの技術要素から独立させる設計です。
たとえば、受注確定の条件、承認者の規則、在庫を引き当てる順序は、ユースケースやドメインに置きます。逆に、画面から直接SQLを呼ぶ構造は避けます。
業務ルールを分けておくと、DBをPostgreSQLから別製品へ、REST APIをメッセージ連携へ変える場合でも、業務ルールのテストを大きく書き換えずに済むことを目指します。
向いている業務システムと向いていないシステム
適用範囲を判断するときは、業務ルールの複雑さや変更頻度、運用期間を見ます。
- 適しやすい業務：受発注や在庫、請求などのルールが複雑なもの。
- 連携と変更：複数部門や外部サービスと連携し、数年後も仕様変更が続くシステム。
- 初期工数に注意：短期間の単純なCRUD画面や、小規模で利用期間が短い社内ツール。
監査ログやデータ移行、段階的な機能追加が必要な基幹系では、業務ルールと技術詳細を分ける効果が大きくなります。一方、単純なツールでは、インターフェースやDTO、テストコードが増え、初期工数が過剰になる場合があります。
マイクロサービスやクラウドとの違い
採用しても、マイクロサービス化やクラウド利用を前提とするわけではありません。最初は、1つのリポジトリの中で業務境界を分けるモジュラーモノリスという形でも構いません。
分散システムにすると、ネットワーク障害やデータ整合性、監視などへの対応が増えます。そのため、組織体制と運用能力を先に確認します。
レイヤードやヘキサゴナル、オニオン、DDDとは、考え方が重なる部分があります。名称よりも、業務ルールが外側の技術に引きずられていないかを見ます。
クリーンアーキテクチャのシステム開発の進め方
基本は6つのフェーズです。要件整理と選定に続き、設計・開発、テストを経て、稼働と定着に至ります。各段階で成果物と判断基準を決めておき、納期や予算が膨らむのを抑えます。
代表的なユースケースは、早い段階で縦に通します。業務ルール、権限、外部連携、エラー処理、監査ログを、実際に動かして確かめます。
フェーズ1：業務ルールと変更点の洗い出し
画面の一覧に置き換える前に、誰が、どの条件で何を確定し、例外時にどう判断するかを整理しておきます。
- 業務の流れ：受注や承認、返品、請求、在庫などのイベントを時系列に並べる。
- ルールと責任：用語、マスタ管理者、権限、保存期間、外部連携、手作業の引継ぎを確認する。
- 成果物：業務フロー、ユースケース一覧、用語集、権限マトリクス、データ項目、非機能要件、受入基準。
採用理由は、業務側が説明できる形にしておきます。「将来変更に強くしたい」という表現だけでは伝わりにくいため、具体的な変更条件を示します。
たとえば、承認経路が頻繁に変わるときや、会計や物流の連携先が増えるとき、5年以上運用するときが該当します。レガシー機能を順番に置き換える場合も当てはまります。
反対に、登録や検索が中心で業務がほぼ固定なら、標準機能やSaaSを優先し、独自開発は限定します。
フェーズ2：方式・技術・発注先の選定
選定では、業務の標準化度や差別化の必要性、自社で変更できる範囲を比べます。
- 方式：SaaS、パッケージへの追加開発、スクラッチ開発、クラウド移行と段階再構築。
- 独自実装：競争力の源泉となる計算、承認、在庫のルールを対象にする。
- 技術：チーム経験、LTS、採用市場、脆弱性対応、テスト容易性、運用監視実績で判断する。
標準化されていて差別化が薄い業務は、SaaSやパッケージを使い、独自のルールだけを実装する方法もあります。その場合の独自実装は、主に自社で開発・変更できる領域が対象です。
言語の流行よりも、チームの実績で技術を選びます。Java・Spring Boot、.NET、TypeScript・NestJS、Python・FastAPI、Goなどが候補になります。
発注先には、ドメインモデリングや依存方向の検査方法、ユニット・統合・E2Eテストの例を尋ねます。また、API障害時の再試行と重複防止の方法も確認します。
提案デモでは、正常系に加えて、権限エラーや外部API停止の場面も見ます。異常時の対応を見ると、会社ごとの設計力を比べられます。
フェーズ3：代表ユースケースを縦に通す設計・開発
最初の設計では、責務と依存の向きを定めます。そうすることで、業務ルールが画面や技術に引きずられない境界を作れます。
- ドメイン層：エンティティ、値オブジェクト、業務上の不変条件を置く。
- アプリケーション層：「受注を確定する」などのユースケースを置く。
- 外側の接続：DBや外部APIをポートとアダプターとして閉じ込める。
次に、Domain、Application、Infrastructure、Presentationなどの責務を定義し、依存の向きを文書にします。
重要な受注や承認などを1本選び、画面またはAPIからテストまで一周させます。途中では、業務ルールやDB、権限、監査ログも通します。
設計書だけに数か月を費やすと、現場が理解できない用語や使いにくい操作を後になって見つけることになります。このため、縦に通した成果物をレビューします。
レビューでは、依存関係や例外処理、トランザクション境界、ログの個人情報マスキング、テストの読みやすさを確認します。そのうえで、機能を広げます。
フェーズ4：ルール・連携・非機能を分けたテスト
テストの種類ごとに確認対象を分け、重要なルールや障害時の振る舞いを確かめます。
- 単体テスト：ドメインの業務ルールと境界条件を高速に確認する。
- アプリケーションテスト：ユースケースの振る舞いを見る。
- 統合・受入テスト：DB、外部APIアダプター、実データに近い連携を確かめる。
- E2Eテスト：画面の主要シナリオを検証する。
- 異常系：例外、権限、重複実行、タイムアウト、部分失敗を含める。
テストでは、カバレッジの数値を目標にするより、重要な業務ルールをテストケースに含めることを優先します。
非機能要件も、受入基準に含めます。性能や可用性、バックアップと復旧、監視、セキュリティなどが対象です。
OWASPのSecure Cloud Architectureは、脅威モデリングや認証・認可、ネットワーク制御を挙げています。さらに、ログ・監視や第三者ライブラリの更新も挙げられています。
セキュリティは、テスト工程だけに任せず、要件整理の段階から脅威と、どこまでを誰が受け持つかを決めます。CI/CDでは、依存ライブラリも検査します。
フェーズ5：移行リハーサルと切り戻し条件の事前決定
稼働前は、移行や切り戻しの段取りを先に決めておきます。
- 一括停止する場合：少なくとも本番相当データで移行リハーサルを複数回行い、所要時間と差分データを測る。
- 停止が難しい場合：Strangler Fig型の機能単位移行や、一定期間の並行稼働を検討する。
- 照合：データの件数と金額を確認する。
稼働前に、障害時の切り戻し条件や権限設定、バックアップ、監視アラート、問い合わせ窓口も準備します。
レガシー刷新は、変更頻度が高く、障害や手作業の負担が大きい領域から順に切り出します。全機能を一度に作り直す形は取りません。
IBMのAPIS IT事例では、AI支援で古いJCL・PL/IやEGL/CICSを解析しました。そのうえで、SOAPサービスをクリーンアーキテクチャのREST APIへ改修したと報告されています。
事例の数値は、自社にそのまま当てはめられません。ただし、現行仕様を一覧にし、自動テストも先に用意しておけば、段階移行の安全性を高められます。
フェーズ6：利用状況と変更リードタイムによる定着の評価
稼働後も、利用部門が業務を続けられるよう備えたうえで、利用状況と変更のしやすさを評価します。
- 運用マニュアル：業務用語、判断基準、例外対応、権限申請、問い合わせ先、リリース手順を残す。
- 初月の確認：問い合わせ件数、処理時間、エラー率、手作業の削減量、利用率を見る。
- 継続改善：現場の声を次の改善バックログに反映する。
価値は、構造の見た目よりも、変更範囲を把握しやすく、回帰テストを短時間で実行できる点にあります。
たとえば半年後に承認経路や連携先、料金計算を変えるとき、要件からリリースまで何日かかるかを測ります。
変更リードタイムや障害復旧時間、テスト自動化率、運用担当者の属人化を追うと、設計投資の成果を経営層に説明する材料になります。
クリーンアーキテクチャのシステム開発の費用相場と内訳
クリーンアーキテクチャ単体の公的な価格表はありません。費用は、機能数やドメインの複雑さ、利用者数、外部連携で変わります。加えて、データ移行や非機能要件、チーム体制も影響します。
次に示すのは、SIA株式会社が2026年7月に公開した一般相場と、設計・テスト・運用の工数をもとにした記事用の概算です。個別案件の確定見積ではありません。
規模別の概算費用と期間
規模の目安は、含める機能や連携、可用性、移行作業を踏まえて確認します。
- 小規模：350万〜850万円、3〜5か月程度。
- 中規模：800万〜1,800万円、5〜9か月程度。
- 大規模：2,000万〜1億円以上、8〜18か月以上の場合がある。
小規模は、単一業務の社内システムを想定しています。認証や基本マスタ、1〜2本の業務フローに加えて、ドメイン層、単体テスト、簡易CI/CDを含みます。
中規模は、複数ロールや承認、外部API、監査ログを含む部門横断の案件を想定します。移行リハーサルや運用監視も含みます。
大規模は、複数ドメインやレガシー連携、大量データを扱う基幹系を想定しています。厳しい可用性や災害対策、性能試験も含みます。
SIA株式会社の2026年版相場は、一般開発の場合で小規模100万〜300万円、中規模500万〜1,000万円、大規模1,000万円以上としています。
本記事のレンジは、ドメイン設計やテスト自動化、運用設計を含む業務システムとして上振れさせた推定です（出典: SIA株式会社「システム開発の費用・相場【2026年版】」、2026年）。
費用を左右する工数と内訳
見積もりでは工程ごとの金額を分け、初期費用と5年間の総保有コスト（TCO）を比べます。
- 要件・設計：要件整理、ドメインモデリング、基本・詳細設計。
- 開発・検証：実装、テスト、移行、運用設計。
- 管理：プロジェクトマネジメントの費用と工数は、別に切り出す。
一般的な業務システムでは、要件定義10〜12%、設計・環境構築22〜24%、実装48〜50%、テスト15〜17%程度が目安です。ただし、この割合は案件の性質で変わります。
要件整理やドメイン設計、テスト、文書化を削ると、変更の影響範囲を調べる作業や手戻りが増えます。そのため、実装費だけを下げる見積もりには注意が必要です。
初期工数は、単純なCRUD開発より10〜25%増えるものとして仮に置けます。この数値は、ドメイン設計、ポートとアダプター、テスト自動化、CI/CD、文書化を含めた推定です。市場統計による数値ではありません。
要件が複雑で変更が多い案件では、5年間の追加開発や障害対応、教育、ベンダー交代の費用まで含めたTCOで評価します。
保守運用費とクラウド費の切り分け
保守運用費、クラウド費、SaaS本体費、追加開発費を分け、契約と前提条件を確認します。
- 保守運用：初期開発費の年15〜25%程度が目安。契約範囲により月額の場合もある。
- 確認項目：脆弱性・OS・ライブラリ更新、監視・バックアップ、法改正、問い合わせ、追加開発、SLA。
- クラウド：ログ、バックアップ、冗長化、WAF、性能監視、障害対応の費用を含める。
クラウドにすれば安くなるとは限りません。このため、月額費用の前提条件を見積書に残しておきます。
SaaSやパッケージでは、本体の初期費用や利用料と、独自業務の追加開発費を分けて考えます。SaaS本体の内部設計は変更できないため、API連携やアドオン部分に適用する設計ルールを決めます。
契約終了時にデータを出力できるか、独自コード、IaC、設計書、テスト資産を引き渡せるかも、将来の移行費用を左右します。
クリーンアーキテクチャのシステム開発で見積もりを取るポイント
成果物や品質を比べるには、確認方法と合格条件まで資料にまとめておく必要があります。「クリーンアーキテクチャ対応」という表現だけでは、比較の基準にしにくいためです。
見積もり依頼には、対象業務や優先順位、利用者と権限、外部連携、データ移行を記載します。さらに、性能や可用性、セキュリティなどの非機能要件、運用体制、納品物、受入基準も書き添えます。
「柔軟な設計」や「高品質なコード」のように、提案会社ごとに解釈が変わる表現は、検査方法や合格条件に置き換えます。
RFPと要件資料に入れるチェック項目
業務、アーキテクチャ、テスト、運用の要件をそろえておくと、提案内容を同じ基準で評価できます。
- 業務要件：ユースケース、例外、用語、マスタ責任者、承認経路、権限、監査ログ、保持期間。
- 設計要件：依存方向、ドメイン層、外部接続の抽象化、技術選定理由、ADR、レビュー方法。
- テスト納品：重要ルールの単体、アダプターの統合、主要シナリオのE2Eの範囲。
テストは、「全コードを対象にする」と書くより、テストの種類と納品範囲を決めます。
運用では、CI/CDやIaC、ログ・メトリクス・トレース、アラートなどを確認します。加えて、バックアップや復旧目標、脆弱性対応、障害時の連絡経路も見ます。
クラウドでは、認証・認可やライブラリ更新、ログへの個人情報混入防止、コスト上限アラートについても、どこまでを誰が担うかを決めます。
OWASPは、マネージドサービスを使う場合でも、認証・認可、ログ・監視、コードセキュリティ、第三者ライブラリのパッチ適用が開発側の責任になり得ると説明しています（出典: OWASP「Secure Cloud Architecture Cheat Sheet」、確認日2026年8月）。
複数社比較で見る価格以外の確認事項
提案会社を比べるときは、総額と工程別の工数・成果物を同じ粒度で確認します。
- 工程別の内訳：要件整理、設計、実装、テスト、移行、運用の金額と工数。
- 前提条件：成果物、担当者、レビュー回数、前提、除外項目。
- 契約条件：「一式」の人月、役割、期間、受入基準、追加変更の単価と扱い。
安い提案は、要件定義やテストを削っている場合があるため、金額の差を工程と成果物で確かめます。
会社選定では、用語の実績数よりも、業務理解や設計レビュー、自動テスト、障害対応、運用引継ぎの実績を重視します。
大規模案件を統制する会社と、小回りの利く専門会社とでは、得意領域が異なります。そのため、自社案件に参加する担当者の経験と成果物を見ます。
NTT DATAは、Agile、DevOps、Cloud Native、iPaaSなどと従来型開発を組み合わせる方針を示しています。同社は、アプリケーション開発者6万人以上、SAFe有資格者2,000人以上を掲げています（出典: NTT DATA「アプリケーション開発・管理」、2026年確認）。
会社規模の数字は、判断材料の一つにとどめます。
契約と成果物の分界の決め方
契約では、納品物の帰属と引き渡し、保守、障害対応、追加開発の条件を定めます。
- 納品物：設計書、ソース、テスト、CI/CD設定、IaC、データモデル、API仕様、運用手順、監視設定、データ出力手順。
- 権利と情報：別会社への移行に備え、著作権、著作権法27条・28条、第三者ライセンス、秘密情報の扱いを整理する。
- 納品後：脆弱性対応、障害復旧、OS・ライブラリ更新、追加開発の見積方法を契約書やSLAに含める。
設計品質は、納品時にソースコードが動くかどうかよりも、変更や運用にどう備えているかで評価します。
発注側は、変更を理解できる設計資料、再実行できるテスト、ログで原因を追える体制、別会社でも行えるビルドとデプロイを確認します。
確認を避ける会社では、初期見積が安くても、将来のロックイン（特定の会社への依存）や改修費用が大きくなる可能性があります。
クリーンアーキテクチャのシステム開発でよくある質問
発注前によくある質問を、採用条件、費用、既存システムとの関係に分けて回答します。万能な正解はないため、条件ごとに判断します。
小規模なシステムにもクリーンアーキテクチャは必要ですか？
業務ルールが単純で、利用期間が短く変更も少ない小規模システムなら、全面採用は不要です。
一方で、変更が多い業務ルールや外部連携の境界だけを分離する部分採用なら、初期工数と保守性のバランスを取りやすいという利点があります。
業務の複雑さ、変更頻度、連携数、運用年数で採用理由を説明できるかを基準にします。
クリーンアーキテクチャにすると開発費はどのくらい上がりますか？
公的な相場はなく、業務の複雑さや成果物の範囲で変わります。なお、初期工数が10〜25%増えるという記事内の値は推定です。
単純なCRUD開発と比べて、ドメイン設計やポートとアダプター、テスト自動化、CI/CD、文書化を含む想定です。市場統計ではありません。
要件定義、設計、実装、テスト、移行、運用の内訳を出してもらい、5年TCOで比較します。
既存の密結合なシステムを段階的に移行できますか？
段階的に移行できます。まず、現行の依存関係やデータ、業務ルール、外部連携を一覧にし、変更頻度と障害影響の大きい機能から切り出します。
Strangler Fig型で新旧を並行稼働する場合は、二重更新やデータ整合性、切替条件、監視、切り戻しを設計します。
全面刷新より期間が長くなる場合もあります。ただし、業務停止のリスクや一括移行の不確実性を分散できます。
開発会社に最初に確認すべき質問は何ですか？
設計・テスト・運用の実物やデモを示せるか、担当者や契約条件まで含めて確認します。
- 設計：業務ルールをどの成果物に置き、依存方向をどう検査するか。
- 検証：代表ユースケースのテスト例、外部API障害、権限エラーへの対応。
- 契約と体制：コード等の引渡し条件、担当アーキテクトの経験、レビュー体制、追加単価、SLA、移行支援。
回答を比べるときは、用語の説明より、どの成果物で答えられるかを見ます。
まとめ
6フェーズによる業務と技術の確認
クリーンアーキテクチャは、業務ルールを技術詳細から分け、変更やテストをしやすくする設計方針です。採用範囲は、業務の複雑さや将来の変更、外部連携、運用期間で決めます。
成果物と5年TCOによる費用の比較
進行の区切りと費用の見方をふまえ、発注先を比べる際の要点を整理します。
- 進行：要件整理から定着までの6フェーズを成果物と受入基準で区切る。
- 実動確認：代表ユースケースを縦に通し、権限、例外、API障害、監査ログ、移行、復旧を確認する。
- 小規模の概算：350万〜850万円。設計・テスト・運用を含む業務システムの検討レンジ。
- 中・大規模の概算：中規模800万〜1,800万円、大規模2,000万〜1億円以上。
- 発注先の比較：初期費用、保守、クラウド、追加開発、移行支援に分け、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を創業。