ヘキサゴナルアーキテクチャのシステム開発は、業務ルールと例外を整理し、設計とテストを経て段階的に稼働させ、運用の指標で定着を確かめる流れで進みます。
採用の判断から6フェーズの進め方、費用相場、見積もりで確認する項目まで、発注側の立場で順に見ていきます。
▼全体ガイドの記事
・ヘキサゴナルアーキテクチャのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ヘキサゴナルアーキテクチャのシステムの全体像
ヘキサゴナルアーキテクチャは、「ポートとアダプター」とも呼ばれる設計パターンです。業務ルールとユースケースを中心に置き、外部との接続をポートと技術別のアダプターに分けます。六角形は、入力と出力を複数の方向から捉えるための図形で、ポートが6つあるという意味ではありません。
中心に置く業務ルールとユースケース
受注管理の業務ルールには、在庫確保後の受注確定、与信超過時の承認、期限後のキャンセル拒否があります。一方で、画面URL、SQL、クラウドSDKは業務ルールではありません。中心のコードから技術要素を参照させないことが基本です。
- 入力ポート：受注登録や在庫照会など、外部から使う契約
- 入力アダプター：REST API、画面、スマートフォン、CLI、夜間バッチ、メッセージ受信の担当
- 出力ポート：注文保存、在庫引当、請求通知など、外部への依頼
- 出力アダプター：RDB、NoSQL、ERP、決済API、メール、メッセージブローカーへの変換
変更頻度・連携数・利用期間で見る採用判断
採用の可否は、適用候補となる条件と費用対効果が下がる条件を分けて見て判断します。
- 複数の入口：Web画面、外部公開API、バッチで同じ業務ルールを使う
- 変更予定：RDBや決済の交換、基幹連携の追加、制度改正が見込まれる
- 単純・短期のツール：画面や連携が少なく、数か月で役割を終えるCRUDでは、負担が効果を上回る可能性がある
AWS Prescriptive Guidanceでも、複数の入力元や出力先があり、UIやデータストアを定期的に更新するシステムが適用候補とされています（出典: AWS Prescriptive Guidance、2026年参照）。
導入前には、今後3〜5年で変更が見込まれる業務ルールや接続先を一覧にします。さらに、利用者数や規制対応も一覧に加えます。発注側が「変更コストを管理したい」と説明できることが、採用判断の出発点です。
ヘキサゴナルアーキテクチャのシステム開発の進め方
開発は6フェーズで進みます。要件整理で業務ルールを洗い出し、選定で会社の設計力を比べてから、設計・開発に入ります。
各段階には完了条件を決めておきます。特に、ドメイン境界とポートの契約は急いで確定させず、業務担当者の言葉や例外処理を先に整理します。
- 要件整理で業務ルールと変更点を洗い出す
- 選定で設計力と引き渡し範囲を比較する
- ドメインからアダプターへ設計・開発する
- ポート単位と業務シナリオでテストする
- 切替・監視・復旧を準備して稼働する
- 設計原則と運用指標を残して定着させる
フェーズ1：要件整理による業務ルールと変更点の洗い出し
画面や機能の一覧を作る前に、業務の目的と判断ルールを整理します。
受注や在庫、請求など、業務ごとに誰が何を入力し、どの条件で何を出すかを確認します。正常系の流れと併せて、例外も聞き取ります。
- 例外の聞き取り：在庫不足、二重送信、承認却下、タイムアウト、部分的な連携失敗、再実行時の重複登録
- 整理する資料：業務用語集、ユースケース、業務ルール、外部システム、データ責任範囲、非機能要件、変更頻度
- 記録事項：各ユースケースの入力、出力、エラー、権限、監査ログ、冪等性の要否
複雑で変わりやすい業務を対象にし、単純なマスタ登録まで一律に抽象化しないことが、費用と納期を守るうえで欠かせません。
業務担当者がユースケース例を読み、「この判断で合っている」と確認できれば、このフェーズは完了です。一方で、画面仕様だけが完成し、業務ルールが曖昧なままでは、選定へ進めません。さらに、例外処理の確認を後回しにすると、ドメインモデルとアダプターを作り直すことになります。
フェーズ2：選定での設計力と引き渡し範囲の比較
候補会社を選ぶ際は、設計力と提案条件を中心に、実績や契約上の責任も確認します。
- 設計力：依存方向、ポートの責務、テストダブルによる単体テストを確認
- 提案条件：同じRFPで業務境界、移行方針、クラウドとオンプレミスの選択理由、監視、障害復旧、CI/CD、セキュリティ、保守体制を比較
- 実績と納品：近い業務経験、外部連携数、既存システムを止めない移行経験、設計書・テストコード・IaC・依存ライブラリ一覧の引き渡し範囲
- 契約条件：著作権、二次利用の範囲、OSSライセンス、脆弱性修正の期限、追加アダプター単価、障害連絡体制
「ヘキサゴナルに対応できます」という営業文句は、判断材料としては不十分です。設計書を見て、ドメイン層がフレームワークやDBクライアントを参照していないかを確かめます。
可能であれば、匿名化したコードや、RDBアダプターをインメモリー実装に差し替えるデモを依頼します。
採用する設計原則と、どこまでを誰が受け持つかは、契約書や提案書に書いておきます。
フェーズ3：ドメインからアダプターへ進める設計・開発
設計・開発では、ドメインモデルとユースケースを定義し、入力・出力ポートの契約を決めてから、アダプターを実装します。
- ドメインモデルとユースケースを定義する
- 入力・出力ポートの契約を決める
- ドメイン、アプリケーションサービス、入力アダプター、DBや外部APIの出力アダプターの順に実装する
たとえば受注登録では、REST入力をアダプターが受けたあと、サービスがポートを介して在庫と与信を確認します。受注の可否はドメインが判定し、そのうえでサービスが出力ポートを通じて、RDB保存や在庫通知を依頼します。
ポートには、データ形式、エラー、タイムアウトを含めます。さらに、リトライやトランザクション境界、再実行時の重複防止も決めておきます。また、API成功後にDB保存が失敗するケースや、メッセージが少なくとも1回届くケースも考慮します。
アダプターは変換と接続に絞り、業務判断は置かないようにします。これが、依存方向を守るうえでの要点です。
Fintanには、Java 8とNablarchを使い、2〜3人で2.5か月かけて行ったマイグレーションの事例があります。この事例では、ビジネスロジックをフレームワークやDBから分離して、要求変更への追従と環境なしのデモを目指しました（出典: Fintan「ヘキサゴナルアーキテクチャ導入事例」、2019年公開）。
規模や技術が違うため、期間をそのまま当てはめることはできません。業務ロジックを先に確かめる進め方は参考になります。
フェーズ4：ポート単位と業務シナリオによるテスト
テストは段階ごとに役割を分けて行い、ドメイン単体では業務ルールを、アダプターや契約では接続部分を、E2Eでは業務の流れ全体を確かめます。
- ドメイン単体：DBやHTTPサーバーを使わず、在庫不足、与信超過、期限切れ、二重登録の判定
- アダプター・契約：DBマッピング、NULL、文字コード、タイムゾーン、APIエラー、認証情報と入出力形式の検証
- E2E：受注から在庫引当、請求連携、監査ログまでの一連の流れと、失敗後の再実行
外部環境の不安定さに左右されないよう、出力ポートはモックやインメモリーアダプターに置き換え、業務ルールのテストを切り離します。
合格基準には、件数以外の観点も含めます。重要な業務ルールを網羅しているか、連携失敗時にどう動くかを確かめ、注文番号の追跡や性能目標の達成も見ます。
CI/CDで単体テストと契約テストを毎回実行し、依存方向を静的解析で検査します。こうした仕組みは、開発者が増えても境界を保つうえで役立ちます。
フェーズ5：稼働に向けた切替・監視・復旧の準備
稼働前には、データ移行と権限、バックアップの扱いを決めておきます。障害連絡やロールバック、外部連携の切替時刻も、あわせて定めます。
- 切替準備：データ移行、権限、バックアップ、障害連絡、ロールバック、外部連携時刻の決定
- 段階移行：レガシー刷新では全機能を一度に切り替えず、対象業務を選び、既存システムの周囲に変換アダプターやAPIを置いて機能単位で移す
- 監視と追跡：呼び出し数、失敗率、リトライ、処理時間、キュー、業務エラー、監査ログを記録し、相関IDで追う
並行稼働中は、件数や金額、在庫残高を照合し、更新日時も確かめます。照合で差異が出た場合に備えて、その責任者を決めておきます。
CPU使用率に加えて、ポートごとの呼び出し数や外部API失敗率、リトライ回数を監視します。さらに、処理時間やキュー滞留も見ます。また、監査ログの欠落も記録の対象にします。
個人情報をログに出しすぎない設計にします。本番切替では、バックアップから復元できることも確認します。
ロールバック手順を演習し、想定利用者が業務を最後まで終えられるかも確かめます。障害連絡の受付時間と復旧目標については、関係者の合意を取っておきます。
フェーズ6：定着に向けた設計原則と運用指標の記録
稼働後は、新機能を追加するたびに、業務ルールはドメインに置き、技術固有の処理はアダプターに閉じ込めます。
- 設計記録：ADR、ポート契約、アダプター一覧、テスト方針、依存ライブラリ一覧の更新
- 運用指標：変更リードタイム、リリース後の障害件数、単体テスト時間、連携失敗率、アダプター追加工数、手戻り箇所の計測
- セキュリティ：認証・認可、秘密情報、脆弱性、OSSライセンス、監査ログの責任者の明確化
完璧な分離を一度に目指す必要はなく、変更が多い業務から順に改善します。四半期ごとに、依存方向とテストの状態をレビューします。
経済産業省などは2025年に、SBOM活用の国際ガイダンスへ共同署名しています（出典: 経済産業省「SBOMの共有ビジョンに関する国際ガイダンス」、2025年）。また、2026年時点の調達では、アダプターが使うライブラリやコンテナイメージを一覧にします。脆弱性が見つかったときの更新担当者と配布期間は、RFPや運用契約に含めます。
ヘキサゴナルアーキテクチャのシステム開発の費用相場とコストの内訳
ヘキサゴナルアーキテクチャに限った公的な価格統計はありません。そのため、ここに示すのは、2026年公開の一般的な開発費用、公開事例、ポート・アダプター・テスト・移行の工数をもとにした編集上の概算です。
費用は、業務の複雑さや利用者数、外部連携で大きく変わります。既存資産や非機能要件、発注先の体制も影響します。予算計画の初期レンジとして使ってください。
規模別の初期費用の幅：500万円から1億円以上
規模別の初期費用は、対象範囲をそろえて比べる必要があります。
- 診断・基本設計：現行コード分析、業務境界、移行優先順位、PoCを含め50万〜150万円程度
- 小規模新規：1〜2業務、画面またはREST API、RDB、認証、基本テストを含め500万〜1,000万円程度
- 中規模部門横断：複数入力経路、ERP・会計連携、権限、監査ログ、移行を含め1,000万〜3,000万円程度
- レガシー刷新：対象領域ごとに800万〜3,000万円程度
- 全社基幹など：高可用性、複数拠点、災害対策、24時間運用まで含む場合、3,000万円〜1億円以上になることがある
SIA株式会社の2026年公開情報では、初級エンジニアの人月単価が60万〜200万円以上になることがあります。さらに、簡易ツールから基幹システムまで費用幅が大きいとも説明されています（出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年参照）。
単価だけでなく、必要な人月と成果物を比べます。ヘキサゴナルを採用すると、ドメイン境界やポート、アダプターの設計工数が加わります。加えて、依存性注入やテストダブルの作成、CI/CDと監視・ログの設計も工数に入ります。
一般的な費用に10〜25％程度を上乗せする仮定では、500万〜1,000万円の案件は550万〜1,250万円程度の試算になります。
この比率は固定の相場ではありません。外部連携が多いほど比率は増え、将来の変更が少ないほど投資対効果は下がります。
設計・連携・テスト・運用で分ける費用の見積もり
見積書では、初期費用と運用費を分け、作業と連携の範囲を明示します。
- 初期費用：要件、設計、入出力アダプター、画面・API、移行、テスト、インフラ、運用設計
- 連携ごとの工数：接続方式、認証、データ変換、エラー処理、再送、監視
- 運用費：クラウド、監視、バックアップ、ログ、脆弱性スキャン、ライセンス、保守、追加アダプター、法改正
「開発一式」とだけ書かれた見積もりでは、ポートやテストダブルの作成範囲を判断できません。また、初期開発費の年15〜25％程度を保守費の仮置きにする場合もあります。
保守費は、SLAや対応時間によって変わります。月次の改善工数や障害修正の範囲も、保守費を左右します。標準的なクラウドやSaaSを使い、独自ルールと連携だけを包むようにすると、スクラッチの範囲を抑えられます。
費用を抑えるには、変更が多く事業への影響が大きいユースケースから、PoCを作ります。なお、全機能を最初から抽象化する必要はありません。
たとえば受注登録では、一つの流れとしてDBなしのドメインテストから監視まで動かします。その際、実DBのアダプターと外部APIのスタブも組み合わせ、設計の妥当性を確かめます。
ヘキサゴナルアーキテクチャのシステムで見積もりを取る際のポイント
見積もりの精度は、RFPの内容で決まります。業務ルールやポート契約、アダプターの範囲を明記します。さらに、テストや移行の方法、運用の条件、引き渡し物も書きます。
複数社に同じ資料を渡すと、金額の差が要件の読み違いによるものか、体制や品質保証の差によるものかを比べられます。
一式見積もりを避けるための要件と成果物の具体化
RFPでは、要件と成果物を具体的に示すことで、一式見積もりを避けられます。
- 業務・利用条件：対象業務、利用者と権限、ユースケース、ルール、例外、画面・API・バッチの入口、連携先、データ量、ピーク時の処理件数
- 運用・変更条件：可用性、復旧目標、監査ログ、個人情報、移行、将来のDB変更、スマートフォンや外部APIの追加可能性、並行稼働期間
- 設計物：ドメインモデル、ポート、アダプター、API仕様、データマッピング
- 運用・品質物：テストコードと結果、CI/CD、IaC、運用手順、監視項目、SBOM、OSS一覧
条件を明記すると、ポートやアダプターの設計工数を見積もりに反映できます。成果物は、基本設計書に限りません。
テストコードや構築定義が発注先に残ったままだと、会社を変えたり内製化したりする際に、追加費用が生じる場合があります。
公開根拠と設計レビューの体制による開発会社の選定
開発会社は、実績、設計、実装の三つの面から見ます。
- 公開実績：採用事例の有無と、担当チームの説明力
- 設計の証拠：設計書、コードレビュー、テスト自動化、障害対応の実例
- 実装の説明：RESTとバッチの入力、RDBから別データストアへの変更時に中心コードをどう直すか、APIタイムアウト時の再実行を聞く
Fintanには、Nablarchへの依存をアダプター側に閉じ、業務ロジックとDBアクセスを分離した事例があります。クラウド移行やマイクロサービスの実績は、それ単独では実装力の証明になりません。
依存方向やデータ変換、エラーの扱いを一貫して答えられれば、実装後の保守を具体的に思い描けます。さらに、テストや監視、運用まで同じように説明できるかも見ます。
契約前に決めるリスクと追加費用の条件
契約前には、リスクや調査の進め方、追加費用の条件を具体的に決めておきます。
- 洗い出すリスク：データ品質、既存システムの仕様不明、API制限、性能不足、移行期間の延長、法改正、開発者交代
- 決める対応：調査担当、確認期限、予備費の扱い、変更管理の方法
- 設計範囲：変更頻度と将来の交換可能性を根拠に分割対象を定める
現行コードを読まずに移行費を固定してしまうと、解析費や並行稼働費が膨らむおそれがあります。
AWSの公式ガイダンスでは、追加アダプターが保守の負担を増やすことや、接続層によって遅延が生じる可能性も説明されています（出典: AWS Prescriptive Guidance「Hexagonal architecture pattern」、2026年参照）。ポートやアダプターを増やしても、柔軟になるとは限りません。
ヘキサゴナルアーキテクチャのシステム開発でよくある質問
ヘキサゴナルアーキテクチャは、依存方向と接続の責務を管理する設計パターンです。特定の言語やクラウドを選ぶためのものではなく、業務の変化と運用体制を基準に採用を判断します。
ヘキサゴナルアーキテクチャはクリーンアーキテクチャやDDDと同じですか？
ヘキサゴナルは、ポートとアダプターで外部接続を分離する設計パターンです。クリーンアーキテクチャやDDDとは、役割が異なります。
DDDは業務知識をモデル化する開発手法で、クリーンアーキテクチャは依存方向と同心円状の境界を整理する考え方です。これらは組み合わせて使えます。ただし、DDDやマイクロサービスを採用すると、自動的にヘキサゴナルになるわけではありません。
小規模な業務システムにもヘキサゴナルを採用すべきですか？
将来の変更や外部連携、複数の入口があり、長期運用が見込まれるなら、小規模でも業務ルールを分離する価値があります。
利用期間が短く、単純なCRUDで技術の交換予定もない場合は、全体に適用すると実装と学習のコストが先にかかります。
重要な1ユースケースで、ドメイン単体テストとアダプター分離を試し、効果を確かめてから範囲を広げる進め方もあります。
既存の密結合なシステムをすべて作り直す必要がありますか？
すべてを作り直す必要はありません。変更の多い業務を選んだうえで、既存システムとの境界にAPIやイベント、変換アダプターを置く方法があります。アンチコラプション層を置く選択肢もあります。
並行稼働とデータ照合を行いながら、段階的に移行します。現行の仕様が不明な場合は、小さなコード解析と業務確認を先に行い、移行対象と残す機能、廃止する機能を決めます。
ヘキサゴナルアーキテクチャのシステム開発費用を正確に出すにはどうすればよいですか？
費用を正確に出すには、まず対象業務や外部連携、利用者数を整理します。データ量や非機能要件、移行範囲も、あわせて明らかにします。そのうえで、ポートとアダプター、テスト、運用を分けたRFPを作成します。
複数社には、要件整理やPoCを含む概算と、設計・開発から移行、本番後の保守までを分けた内訳を出してもらいます。ただし、相場は予算幅を見るための材料とし、最終金額は業務ルールと連携仕様を確認した見積もりで判断します。
まとめ：6フェーズで定着させるヘキサゴナルアーキテクチャのシステム
業務ルールを中心に置き、外部接続をポートとアダプターに分けることで、変更のしやすさとテストのしやすさを高められます。効果が見込めるのは、複数の入口や外部連携があり、制度や業務要件が変わる長期運用のシステムです。一方で、単純なCRUDに一律に適用すると、コード量と学習コストが増える可能性があります。
要件整理から定着までを通した判断基準
要件整理ではルールと例外を洗い出し、選定では設計の成果物とテストの実績を比べます。次に、設計・開発ではドメイン、ポート、アダプターの責務を定めます。
テストでは単体、契約、結合、E2Eを使い分け、稼働では移行、監視、復旧を確認します。定着後は変更リードタイムや障害件数を測り、6つの完了条件をRFPや計画書、契約、レビューに反映します。
最初の一歩となる、重要なユースケースの診断
最初の診断では、対象を一つに絞り、開発会社への確認事項を具体的にします。
- 対象選び：全社を一度に作り直さず、変更が多く事業影響の大きい受注や在庫を選ぶ
- 小さな設計：業務ルール、ポート、アダプター、テスト、運用を試す
- 会社への質問：DBなしのテスト、API差し替え、障害追跡、テストコードと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を創業。