ヘキサゴナルアーキテクチャのシステム開発費用は、業務の規模、連携や移行の範囲、非機能要件によって、50万円から1億円以上までの幅があります。
ケース別の費用と期間、費用の内訳、方式の選び方を取り上げます。全体像は、下の完全ガイドもご覧ください。
▼全体ガイドの記事
・ヘキサゴナルアーキテクチャのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ヘキサゴナルアーキテクチャのシステム開発費用の相場
ヘキサゴナルアーキテクチャは、業務ルールを中心に置く設計パターンです。Web画面、REST API、データベース、外部サービス、メッセージ基盤などの技術要素は、ポートとアダプターの外側へ分離します。
この考え方は、業務の中心と技術要素の境界を設計するもので、六角形の数だけ機能を作る方式ではありません。費用は、「ヘキサゴナル対応料金」が別に加わるのではなく、通常の開発費に設計、インターフェース、テスト、移行の工数を加えて見積もります。
アーキテクチャ診断・設計の費用：50万〜150万円程度
診断・設計では、現状の調査範囲と成果物を確認します。
- 調査範囲：コード、業務フロー、ドメイン境界、ユースケース、入出力ポート、アダプターの責任、移行優先順位を整理します。
- 期間と難易度：一業務で資料がそろえば2〜6週間程度です。古いコード、属人化したルール、複数DBや外部APIの調査で工数が増えます。
- 成果物：現状分析報告書、対象ドメイン候補、ポート・アダプター一覧、PoC範囲、概算見積もり。
- 価格を左右する作業：業務担当者とのワークショップや、テスト用アダプターによる小規模検証の有無で変わります。
この段階では本開発費を断定せず、調査・設計の範囲に応じた概算として扱います。
小規模な新規業務システムの費用：500万〜1,000万円程度
小規模開発では、対象業務と業務ルールの複雑さが費用を左右します。
- 対象範囲：受注登録や在庫照会など、一つから二つの業務を扱います。
- 基本機能：Web画面またはREST API、RDB、認証、基本権限、単体・結合テストを作ります。
- 設計工数：ドメインモデル、ユースケース、入出力ポート、依存性注入、テストダブルを丁寧に設計すると増える可能性があります。
- 複雑な業務：受注可否、在庫引当、締め処理、重複防止、API再送などが複雑なら、ドメイン設計とテストが費用の中心です。
- 単純な業務：マスタ登録だけで連携先や変更予定がなければ、抽象化を最小限にする方が合理的です。
部門横断の中規模システムの費用：1,000万〜3,000万円程度
中規模の費用は、対象業務と連携の広さに加え、一般的な開発相場との差も踏まえて見積もります。
- 対象業務：販売、在庫、購買、請求、会計、配送などをつなぎます。
- 入口：Web画面、外部公開API、夜間バッチ、メッセージ連携など、複数の経路を扱います。
- 連携設計：ERP、会計、決済、在庫、メール、認証基盤ごとにアダプターを設計し、タイムアウト、エラー、再実行、冪等性、監査ログを決めます。
- 一般相場：2026年公開のSIA株式会社の目安は500万〜1,000万円程度です。ヘキサゴナル採用案件の金額ではありません。
そのため、ヘキサゴナル案件では、業務境界、アダプター、テスト、連携の複雑さを別途加味します。業務数が多い場合や移行を伴う場合は、1,000万〜3,000万円程度まで広がる前提で見積もります。
ケース別の費用と開発期間の比較
下の概算は、ヘキサゴナルアーキテクチャを採用する業務システムを想定した編集用の目安で、専用の公的価格統計ではありません。一般的な業務システムの公開相場、設計・テスト工数、リサーチノートの案件レンジを組み合わせています。会社の体制や技術、対象業務、既存資産の状態で変わるため、予算計画の初期値として使います。
- 診断・基本設計：50万〜150万円程度、2〜6週間。現行コード分析やPoCが含まれることもあります。
- 小規模な新規業務システム：500万〜1,000万円程度、3〜6か月。想定は1〜2業務、画面またはAPI、RDB、認証、単体・結合テストです。
- 部門横断の中規模システム：1,000万〜3,000万円程度、6〜12か月。複数業務、ERP・会計・在庫連携、権限、監査ログ、運用設計が含まれます。
- レガシー刷新・段階移行：対象領域あたり800万〜3,000万円程度、6〜18か月。現行解析、変換アダプター、並行稼働、データ整合性検証、切替が対象です。
- 全社基幹・高可用性システム：3,000万円〜1億円以上、12〜24か月以上。複数拠点、リアルタイム連携などを含む場合のレンジです。
全社基幹では、性能試験や災害対策、24時間運用も対象に含む場合があります。費用と期間は比例するとは限りません。たとえば、短期間のPoCでも、外部決済や在庫連携の信頼性検証には専門人員が必要です。
仕様が分からない既存システムを段階移行する場合は、調査とデータ整備に時間がかかります。そのため、見積書では期間だけでなく、含まれる工程と成果物を確認します。
費用・コストの内訳
「ヘキサゴナル対応一式」とだけ書かれた見積もりでは、総額が妥当かどうかを判断しにくくなります。そこで、通常の開発費と採用に伴う費用を分け、機能、連携先、環境ごとに分解して見ると比べやすくなります。
将来の変更に備える設計費と、現在の機能を動かす製造費も分けておきます。主な内訳は、要件・ドメイン設計、実装、テスト・移行・運用設計です。
要件定義・ドメイン設計の費用
要件定義では、業務の範囲と境界を決めるとともに、関係者への調査内容を整理します。
- 整理する要件：利用者、業務フロー、ユースケース、入出力、例外、不変条件、権限、監査要件。
- 設計する境界：業務ルールを置くドメインと、入出力ポート。
- 受注の例：REST入力アダプターが入力ポートへ注文を渡し、ドメインが在庫・与信・納期を判定する流れ。
- 出力と資料：出力ポートからRDBや外部在庫への連携、用語が不統一な場合の用語集やイベント一覧。
- 費用と手戻り：ヒアリング回数、現行資料、部門間ルールの数で金額が変わり、省略すると境界変更やルール重複で追加費用が生じやすくなります。
ポート・アダプター・依存性注入の実装費用
実装費は、入出力ポートごとと接続技術ごとに、アダプターを設計して検証する作業量で変わります。
- 入力ポート：受注登録、在庫照会、請求確定などを外部から呼び出す契約。
- 入力アダプター：Web画面、REST API、CLI、バッチ、キュー受信を受け持つ部分。
- 出力ポートと実装：リポジトリ、決済、メール、ERP、ファイル、メッセージ送信の契約を、RDB、NoSQL、SaaS、外部API向けに作り込むこと。
- 接続作業：アダプターごとに、変換、認証、設定、タイムアウト、リトライ、ログ、エラー変換、テストを検討する作業。
- 抽象化の範囲：RDBと外部在庫APIでは型や障害対応が異なります。交換予定のない箇所まで抽象化すると、過剰設計になります。
交換可能な構造は、将来の変更への投資として必要な範囲に絞るのが基本です。
テスト・データ移行・運用設計の費用
テスト、既存データの移行、稼働後の運用は、それぞれ範囲を分けて見積もります。
- 単体テスト：DBや外部サービスを使わず、インメモリやスタブのテスト用アダプターで検証する段階。
- 統合・E2Eテスト：実RDBやAPIとの接続、入出力アダプター間の動作の確認。
- データ移行：抽出、項目変換、重複整理、欠損確認、履歴管理、リハーサル、並行稼働、切替後の照合。
- 段階移行：変換アダプターやアンチコラプション層で初期費用を抑えられる可能性がある一方、二重運用中の設計・監視費用がかかります。
- 運用設計：監視、ログ、バックアップ、復旧目標、リリース、ロールバック、脆弱性、秘密情報、IaC、CI/CD、障害連絡の取り決め。
見積もりには、テストコード、カバレッジ目標、API契約、障害時の再実行テストを明記します。運用設計が見積もりから外れていると、稼働後に追加の改修が必要になる場合があります。
初期費用、クラウド利用料、保守費、追加アダプターの単価は、それぞれ分けて確認します。
ヘキサゴナル採用による費用の上乗せ
上乗せ率を示す公的統計は確認できません。リサーチノートでは、ポート、アダプター、依存性注入を初期から設計する場合を想定しています。テストダブル、CI/CD、監視・ログも初期から組み込む前提で、一般的な業務システム開発費に10〜25%程度を上乗せする仮定です。
この数字は、見積もりの考え方を示す試算で、固定の相場ではありません。一般的な中規模システムの基準費用を500万〜1,000万円とすると、単純計算で550万〜1,250万円程度になります。
全案件に一律に加算するものではありません。外部連携が多く、DB交換や複数チャネルを予定する案件では、初期投資の効果が出やすくなります。一方で、単純なCRUDシステムでは、上乗せが不要な可能性があります。
見積もりでは率そのものより、追加作業の明細を確認するのが基本です。ドメイン設計、ポートとアダプター、テストダブル、契約テストなどの作業と成果物が結び付いていれば、金額を検討できます。
人月単価は、2026年公開のSIA株式会社の費用相場にある60万〜200万円程度の一般的なレンジも参考にします。単価は、スキル、地域、契約形態、作業範囲によっても異なるため、あわせて確認します。
AWS Prescriptive Guidanceのヘキサゴナルアーキテクチャ解説では、複数の入出力に効果があると説明されています。将来のUI・データストア変更にも効果があります。
ただし同解説は、アダプターコードによる保守負担やレイテンシにも注意を促しています。将来の変更を減らす効果と、現在増えるコード・テスト・運用負担を比べて判断します。
費用・価格が変動する主な要因
業務ルールとドメインの複雑さ
受注では、顧客別価格、与信、在庫引当の条件が多いほど、ドメインモデルとテストケースが増えます。納期計算や分割出荷、返品もあります。請求締めや承認も、設計とテストの対象です。
部署ごとに同じ用語の意味が違う場合は、境界を整理するワークショップも必要になります。ルールが頻繁に変わる領域では投資効果を期待しやすい一方で、初期設計費は高くなります。
入力経路・外部連携先・アダプターの数
同じ業務を、Web画面やモバイル、外部APIから使うほか、夜間バッチやメッセージ受信から使うと、入力アダプターが増えます。出力側の連携先は、既存RDBやクラウドDB、ERPです。
会計や決済、メール、ファイル、ブローカーも連携先になります。連携先ごとに認証やデータ変換、エラー処理、契約テストが必要になるため、接続先が増えるほど費用も上がります。
性能・可用性・セキュリティなどの非機能要件
同時利用者数や応答時間、処理件数の要求が高いほど、インフラ設計と試験費用が増えます。稼働率や復旧時間、災害対策、保存期間も、要求が高いほど費用に影響します。
セキュリティでは、閉域接続や暗号化、権限分離を求める度合いが費用に影響します。監査ログの要件も、インフラ設計と試験費用を押し上げます。
ポートで業務ロジックを分離しても、性能やセキュリティは自動的には保証されません。そのため、RDBのクエリ性能や外部APIのタイムアウト、キュー再送を個別に確認します。ログの個人情報マスキングも確かめます。
既存システムの状態と開発チームの習熟度
移行の難しさと、開発チームが設計・保守を担えるかをあわせて確認します。
- 新規開発：境界を最初から決められます。
- 既存システム：依存関係、隠れた業務ルール、データ品質、連携の実態を調べます。
- 段階移行：全面再構築を避けても、機能単位の切替には並行稼働やデータ照合の費用がかかります。
- 習熟度：Fintanの公開事例では技術変更への追従が容易になる一方、依存性注入、インターフェース、複雑なアダプター、学習コストが課題です。
提案時には、設計の説明だけでなく、チーム経験やレビュー方法、テストコード例、引き継ぎ方法も確かめます。
パッケージ・クラウド・スクラッチの選び方
ヘキサゴナルアーキテクチャは、スクラッチ専用の方式ではありません。標準業務はSaaSやパッケージに任せ、独自ルールや外部連携をアダプターで包む構成も可能です。
方式を選ぶ前に、初期費用を抑えるか独自性を優先するか、将来の交換可能性をどこに持たせるかを決めておきます。
パッケージ・SaaSの標準機能の活用
会計や販売、在庫、CRMの標準機能で足りる範囲は、スクラッチより初期費用と期間を抑えやすくなります。独自業務は、API、バッチ、イベント、データ連携のアダプターに切り出します。
パッケージ本体は、過度に改修しないことが重要です。
5年総額で比べる際は、利用料、初期設定、移行を含めます。ユーザー数や権限、追加APIも含め、保守や解約時のデータ返却も見ておきます。
クラウドでのアダプターの運用費の見積もり
クラウドでは、API Gateway、コンテナ、サーバーレス、マネージドDBを組み合わせられます。キュー、ストレージ、監視、秘密情報管理も使えます。その分、初期のサーバー購入費は抑えられます。
月額費用は、アクセス数、データ量、ログ保存期間で変わります。さらに、転送量、冗長化、バックアップも影響します。接続先が増えるほど、監視や認証情報、障害対応の負担が増え、利用料も増えます。
スクラッチ開発の対象となる中核業務
独自業務が競争力であり、既存パッケージで表現しにくい場合は、スクラッチが候補になります。その際は、中核ドメインを技術から独立させ、DBや外部サービスをアダプターに閉じ込めます。
この構成では、長期的な変更を管理できる形になります。一方で、要件やテスト、運用を自社で維持する責任が増えます。セキュリティや開発者の採用・引き継ぎも、自社で担う範囲に入ります。
ヘキサゴナルアーキテクチャのコストを抑えるポイント
適用範囲の絞り込み：変更が多い業務領域
すべての機能を同じ粒度で抽象化する必要はありません。変更頻度と業務価値が高い領域を中心に、抽象化を進めます。
- 適用候補：受注、在庫引当、料金計算、権限判定など、顧客や制度で変わる業務。
- 標準構造でよい範囲：単純な参照画面や、一度だけ使う管理スクリプト。
変更の少ない機能まで抽象化しないことで、短期費用と保守負担を抑えられる場合があります。
最小範囲のPoCによる設計効果の確認
全社へ広げる前に、小さな検証で設計の効果と不確実性を確かめておきます。
- 代表的な一業務を選びます。受注登録なら、入力はREST API、出力はRDBと在庫API、テストはインメモリアダプターで組みます。
- DBなしで業務ルールをテストできるかを確かめます。
- ポート契約やエラー処理、ログ、テスト時間、外部連携の交換手順について、測定可能な合格条件を決めます。
- 採用しない範囲、残す技術、標準化するアダプター、今後の改修単価を判断して、本開発の手戻りを抑えます。
PoCは、機能を追加するためではなく、不確実性を減らすために使います。小さな成功例から対象業務を広げるほうが、全体を一度に設計するより予算を管理しやすくなります。
共通ポートと開発ルールの標準化
複数業務で共通する技術的な横断関心事とポートの規約は、テンプレート化しておきます。一方で、業務ルールまで共通化すると、異なる事情を一つの抽象化に押し込むことになり、変更費用が増える場合があります。
共通化の候補は、認証、監査ログ、エラー形式、ページングです。トレースID、タイムアウト、リトライ、メッセージの冪等性も候補に入ります。業務上の判断は、各ドメインに残します。
ソースコード・テスト・IaCの引き渡し
保守を継続できるよう、引き渡し成果物と契約条件を明確にします。
- 設計・コード：受け取る範囲は、ソースコード、ドメインモデル、ポート・アダプター一覧です。
- 開発・運用資料：テストコードとデータ、CI/CD、IaC、環境変数の管理方法、依存ライブラリ一覧、SBOM、運用手順書。
- 契約条件：コードの権利と二次利用、OSSライセンス、脆弱性対応、保守時間、追加アダプター単価の取り決め。
- 部品管理：クラウドSDK、コンテナイメージ、OSSの脆弱性管理が対象です。
引き渡しがないと、別会社へ保守を移す際に再調査費用が発生します。部品情報と更新責任を契約や運用に組み込めば、短期の開発費は少し増えても、将来の緊急対応費や調査費を抑えられます。
経済産業省は2025年に、サイバーセキュリティのためのSBOMに関する国際的な共有ビジョンへ共同署名しています。
見積もりを比較するときのチェックポイント
相見積もりでは、同じRFPを複数社へ渡します。「ヘキサゴナル対応」とだけ書かれていると、ポート、アダプター、テスト、移行の解釈が会社ごとに変わります。
RFPには、対象業務、利用者数、入力経路、出力先を記載します。さらに、データ量や保存期間、連携頻度、同時実行数も書き添えます。そのうえで、可用性や移行対象、対象外まで明記すると、見積もりの範囲をそろえやすくなります。
範囲がそろったら、各社の見積もりを次の5点で比べます。
- 設計範囲：ドメイン、ユースケース、入出力ポートの対応表が示されているか。
- 入出力：Web・API・バッチ・キュー、RDB・SaaS・ERPなどの費用が分かれているか。
- テストと移行：各種の検証、リハーサル、並行稼働、切替、旧システム停止を含むか。
- 運用：監視、ログ、バックアップ、脆弱性対応、SBOM、CI/CD、IaCの担当が明確か。
- 成果物と契約：コード、設計書、テスト、IaC、ライセンスの引渡しや保守費、SLAが明記されているか。
テスト範囲には、単体、契約、統合、E2Eがあります。性能や障害復旧、セキュリティも含まれるか確かめます。アダプターごとの認証やデータ変換の費用も確認します。
安い見積もりは、対象外の範囲が広い可能性があります。たとえば、現行調査やマスタ整備、データクレンジングが別料金になっていないかを確かめます。外部サービス契約、クラウド初期設定、教育、運用引き継ぎも、別料金かどうか見ます。
設計やテストを過剰に積んだ見積もりもあります。そこで、成果物、合格基準、作業時間、担当者の役割が金額に対応しているかを比べます。
実際の業務シナリオで、簡単なデモを依頼します。確認するのは、受注登録と在庫引当の流れ、在庫APIのタイムアウト時の振る舞いです。さらに、再実行や二重計上防止、監査ログの追跡も見ます。
ポートやアダプターの名称だけでなく、例外処理から障害時の復旧まで説明できる会社を選びます。
ヘキサゴナルアーキテクチャのシステム開発費用に関するFAQ
ヘキサゴナルアーキテクチャなら開発費は必ず高くなりますか？
初期は、ドメイン設計やポート、アダプターの工数が増える可能性があります。テストと依存性注入の工数も増えることがあります。ただし、必ず高くなるとは限りません。
一方で、DBや外部サービスを交換しやすく、業務ロジックを独立してテストできる場合は、将来の改修や環境変更の費用を抑えられることがあります。
反対に、外部連携や機能変更が少ない単純なCRUDでは、追加の抽象化が保守負担になることもあります。
小規模なシステムにも採用した方がよいですか？
採否は、将来の変更や複数チャネル、外部連携、業務ルールの複雑さで判断します。小規模でも、Web、スマートフォン、API、バッチから同じ業務を使うなら候補になります。
将来DBを交換する予定がある場合や、制度変更が多い場合も、適用範囲を絞る価値があります。たとえば、単純な社内ツールなら、変更の多い一業務だけでPoCを行う方法もあります。
レガシーシステムを全部作り直す必要がありますか？
全部を一度に作り直す必要はありません。既存システムの周囲にAPIやイベント、変換アダプター、アンチコラプション層を置き、優先度の高い業務から段階的に切り替える方法もあります。
並行稼働中は、データ整合性や二重登録防止、切替手順の費用が必要です。監視や障害対応にも費用がかかります。また、対象領域あたり800万〜3,000万円程度のレンジも、調査や移行の難しさで大きく変わります。
保守費は初期開発費の何パーセントですか？
一般的な仮置きとして、初期費用の年15〜25%程度を保守費に計画することがあります。これはヘキサゴナル固有の相場ではありません。
保守の範囲は、問い合わせ対応だけか、監視や脆弱性対応まで含むかで変わります。さらに、クラウド運用やOS・ミドルウェア更新、追加アダプターを含むか、法改正や性能改善まで含むかでも差が出ます。
率だけでなく、月間対応時間や受付時間を確認します。あわせて、SLA、対象外作業、追加開発単価も見ます。
開発会社へ何を伝えると見積もりが正確になりますか？
まず、対象業務と利用者、業務フロー、例外処理を伝えます。次に、連携先やデータ量を示し、性能や可用性も添えます。
さらに、セキュリティと移行対象を明らかにします。希望時期と対象外も、あわせて示します。
成果物には、ポート・アダプター設計とテストコードを明記します。加えて、CI/CDやIaCを記載し、SBOMとコードの引き渡しも示します。そのため、業務シナリオと合格基準をそろえたRFPであれば、各社を同じ条件で比べられます。
まとめ
診断・設計は50万〜150万円程度です。小規模な新規業務システムは500万〜1,000万円程度、部門横断の中規模システムは1,000万〜3,000万円程度が、検討の目安になります。
レガシー刷新は対象領域あたり800万〜3,000万円程度、全社基幹や高可用性が必要なシステムは3,000万円〜1億円以上になる可能性があります。いずれも固定価格ではなく、業務範囲や連携、移行、非機能要件、開発体制で変わる概算です。
初期費用に影響するのは、ドメイン設計、ポートとアダプター、依存性注入です。さらに、テストダブルや契約テスト、移行も影響します。加えて、CI/CDや監視、セキュリティ、運用設計も影響します。
10〜25%程度の上乗せは仮定値で、すべての案件に当てはまる相場ではありません。一般的な開発費と追加作業を分け、成果物と金額を対応させて見積もります。
変更頻度と業務価値が高い領域に、適用範囲を絞ります。そのうえで、小さなPoCでDBなしのテスト、アダプター交換、障害追跡を確かめてから拡張します。
候補会社には、同じRFPと業務シナリオを渡します。比べる対象は、設計やテスト、移行、運用です。さらに、コード・IaCの引き渡しや保守費まで見ます。
▼全体ガイドの記事
・ヘキサゴナルアーキテクチャのシステム開発の完全ガイド
▼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を創業。