ヘキサゴナルアーキテクチャは、業務ルール、ポートとアダプター、テストを分けて設計する方式で、技術の変更による影響を抑えやすくします。
仕組みや他方式との違いから、導入の進め方、費用、開発会社の選び方までを、発注する側の目線で押さえます。詳しくは関連記事もご覧ください。
▼関連記事一覧
・ヘキサゴナルアーキテクチャのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・ヘキサゴナルアーキテクチャのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・ヘキサゴナルアーキテクチャのシステム開発の見積相場や費用/コスト/値段について
・ヘキサゴナルアーキテクチャのシステム開発の発注/外注/依頼/委託方法について
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ヘキサゴナルアーキテクチャの仕組み
ヘキサゴナルアーキテクチャは、Ports and Adapters（ポートとアダプター）とも呼ばれる設計パターンです。
中心に業務ルールを置き、外側に技術的な接続を配置します。そうすると、依存関係が整理され、変更やテストがしやすくなります。
六角形は、中心のアプリケーションと外部との接続点を見やすくするための図形です。ポートの数を表すものではありません。
中心に業務ルールとユースケースを置く設計
中心に置く業務ルールは、受注や在庫引当の条件、請求額の計算、権限の判定などです。技術が変わっても守りたい内容を、ここに集めます。
- 業務ルール：受注条件、在庫引当、請求額、権限を扱います。
- ユースケース：「受注を登録する」「在庫を照会する」といった処理を実行します。
- 依存方向：中心から特定のDBやフレームワークを呼び出さない形にします。
アプリケーション層は、処理の順番やトランザクションを調整します。一方で、具体的なデータベース、Webフレームワーク、クラウドSDKへの依存は外側に置きます。
ポートは接続契約、アダプターは技術実装
ポートは、中心のアプリケーションが外部とやり取りするための、技術に依存しない契約です。入力側と出力側では役割が異なり、次のように分かれます。
- 入力ポート：ユースケースを呼び出す契約です。
- 入力アダプター：REST API、画面、CLI、バッチ、メッセージ受信が該当します。
- 出力ポート：保存、通知、決済、在庫照会、ERP連携に関する契約です。
- 出力アダプター：RDB、NoSQL、ファイル、外部API、メッセージブローカーで実装します。
受注登録での入力から保存までの分離
受注登録では、画面やREST APIが入力アダプターになります。処理は次のように分かれます。
- 入力の変換：受信したJSONや画面入力を、入力ポートの形式に整えます。
- 業務ルールの検証：ユースケースが顧客、商品、在庫を確認します。
- 出力の実行：在庫引当と受注保存を行い、必要に応じて通知します。
RDBを別のデータストアへ交換する場合、変更の中心は出力アダプターと設定になります。そのため、業務ルールの変更は小さく抑えられます。
マイクロサービスやクラウドとの違い
ヘキサゴナルアーキテクチャは、システムの配置・運用単位を決めるマイクロサービスとは別の概念です。
- 配置単位：モジュール化した1アプリにも、複数サービスにも適用できます。
- 実行環境：クラウド、オンプレミス、コンテナ、サーバーレスから選べます。
公式の設計ガイダンスでは、データストアやUIから分離し、技術交換と独立したテストを行いやすくする考え方として説明されています（出典: クラウド事業者の公式設計ガイダンス、2026年確認）。
ヘキサゴナルアーキテクチャと他の設計方式との違い
検討の際は、似た言葉を同じものとして扱わないことが大切です。ただし、実際の開発では、複数の考え方を一部組み合わせる場合もあります。
- レイヤード：責務を層に分ける構造です。
- クリーン・オニオン：依存方向を内側へ向ける考え方です。
- DDD：業務領域をモデル化する方法です。
- マイクロサービス：配置、組織、運用の単位です。
レイヤードアーキテクチャとの依存方向の違い
典型的なレイヤードでは、画面層、業務層、データアクセス層を上から下へ呼び出します。業務層がデータアクセスの具体クラスへ依存すると、DBの都合が業務ルールへ入り込みます。
一方、ヘキサゴナルでは、中心側が出力ポートを定義し、外側のアダプターがそれを実装します。このように依存関係を内側へ向けることが、変更範囲を小さくする要点です。
クリーン・オニオン・DDDとの重なり
クリーンやオニオンも、業務の中心を外部の詳細から守り、依存を内側へ向けます。一方、ヘキサゴナルは、入力と出力をポート・アダプターで捉え、UIとDBを対称的な外部要素として扱います。
DDDは、ドメインの境界、用語、モデルを設計する方法です。なお、ヘキサゴナルを採用しても、DDDを全面的に導入する必要はありません。
モジュール化モノリスからの出発
外部連携が多くても、最初からサービスを細かく分ける必要はありません。たとえば、受注、在庫、請求などをモジュールに分け、1つのデプロイ単位から始められます。
ポートとアダプターを明確にすると、運用監視、障害対応、データ整合性の負担を抑えつつ、将来分割できる境界を検証できます。サービスへの分割は、チーム構成、リリース頻度、障害分離の必要性を見て、後から判断します。
ヘキサゴナルアーキテクチャのシステム開発の進め方
フォルダを分けただけでは、設計は完成しません。まず、業務境界、変更頻度、外部連携、品質要件を確認し、技術から独立させる範囲を決めてから実装に進みます。
新規開発でも既存システムの刷新でも、設計判断と検証結果は段階的に記録します。
要件定義での業務の変化点と境界の洗い出し
受注、在庫、請求、配送、顧客、権限などを現場の言葉で整理します。そのうえで、ルールの変更頻度、利用する入力経路、連携先も確認します。
- 変更と利用期間：複数の入出力先があり、変更が多く5年以上使う領域で効果を検討します。
- 入力経路：Web、スマートフォン、外部API、夜間バッチの各経路です。
- 成果物：用語集、ユースケース、業務ルール、不変条件などです。
- データと情報保護：保存・削除の手順を決めます。
成果物には、外部連携一覧も含めます。また、個人情報や決済情報を扱う場合は、保存場所、マスキング、アクセス権、監査ログ、削除・訂正の手順を決めておきます。これらが曖昧なまま技術を選ぶと、ポートが技術名の言い換えになりやすいため、注意が必要です。
設計でのポートの契約と依存方向
ポートの契約には、正常時の入出力だけでなく、失敗時の扱いも含めます。また、設計書では依存関係とアダプターの切り替え方を明示します。
- 入力ポート：コマンド、検索条件、結果、業務エラーを定義します。
- 出力ポート：保存、外部照会、通知、ファイル、メッセージに関する契約です。
- 失敗時の契約：タイムアウト、リトライ、再実行、冪等性を決めます。
- 依存の管理：中心のドメインが外周の具体クラスを参照しない形にします。
順序性や部分失敗時の扱いも決めておくと、アダプターごとの差が業務ルールへ漏れにくくなります。あわせて、本番用RDBとテスト用インメモリーアダプターの切り替え構成も明記します。
フレームワークの便利な機能についても、中心のコードへ直接注入せず、外側に閉じ込める方針を決めておきます。
テスト用アダプターの先行準備
業務ロジックを外部環境から切り離して検証できることが、ヘキサゴナルの価値です。実DBや外部APIを毎回起動しなくてもテストできます。
- 中心のテスト：受注可否や在庫引当を、インメモリー実装やスタブで確認します。
- 統合テスト：アダプターと実際の接続先を検証します。
- E2Eテスト：実際の画面からの処理の流れを確認します。
- CI/CD：単体テスト、静的解析、統合テストなどを段階的に実行します。
合格条件は、テストの件数よりも中身で判断します。具体的には、DBなしで業務ルールを再現でき、APIの失敗、遅延、重複通知を検証できるかを確かめます。
また、アダプターを交換しても中心のテストが壊れないことも確認します。リリース前には、統合テスト、脆弱性スキャン、マイグレーション検証を行います。
リリース後の変更容易性の測定
導入効果は、設計図の完成度より、変更や障害対応が実際に速くなったかで確かめます。そこで、業務ロジックを変更した行数やテスト時間などを継続して測定します。
- 変更の影響：API交換で中心の業務ロジックを変更した行数を記録します。
- 開発と運用：テスト時間、改修から本番反映までの期間を測ります。
- 障害対応：原因特定時間やアダプター単位の変更件数を確認します。
運用設計には、相関ID付きログ、メトリクス、トレースを含めます。そのうえで、再処理やデッドレターの扱い、バックアップと復旧目標も決めておきます。
アダプターが増えるほど、障害の起きる箇所も増えます。そのため、監視や復旧手順を後回しにすると、疎結合でも運用上の切り分けに時間がかかります。
ヘキサゴナルアーキテクチャのシステム開発費用の相場
ヘキサゴナル単独の公的な価格統計はありません。ここで示すのは、2026年公開の国内開発費情報、一般的な工数、設計・テスト・移行の追加作業をもとにした概算です。
費用は、要件、既存資産、利用者数、外部連携、可用性によって変わります。そのため、固定の価格としてではなく、見積もりの初期仮説として使ってください。
▶ 詳細はこちら：ヘキサゴナルアーキテクチャのシステム開発の見積相場や費用/コスト/値段について
規模別の初期費用と期間の目安
診断から全社基幹まで、対象規模や移行範囲によって費用と期間に幅があります。
- 診断・基本設計：50万〜150万円、2〜6週間。分析やPoC設計を含みます。
- 小規模新規：500万〜1,000万円、3〜6か月。1〜2業務などを想定します。
- 中規模：1,000万〜3,000万円、6〜12か月。連携や移行で工数が増えます。
- 機能単位の刷新：対象領域ごとに800万〜3,000万円、6〜18か月の場合があります。
- 全社基幹・高可用性：3,000万〜1億円以上、12〜24か月以上の場合もあります。
診断は、現行コードの分析と業務境界、移行優先順位の整理に加えて、PoC用ポート設計まで含みます。また、小規模新規は、画面またはREST API、RDB、認証を含みます。単体・結合テストまで想定しています。
中規模では、複数の入力経路や会計・在庫連携、データ移行が工数に影響します。また、権限や監査ログも工数に影響します。
人月単価はスキルや地域により60万〜200万円以上です（出典: 2026年公開の国内システム開発費用調査、2026年）。業務分析、アーキテクト、セキュリティの担当は、誰が何人月を担うかも確認してください。テスト、移行、運用設計も、担当と人月を確かめてください。
ポートとテストによる追加費用
追加費用と改修効果は、案件の条件によって異なります。
- 追加作業：境界、ポート、アダプター、テスト、運用設計を行います。
- 費用試算：通常費用に10〜25％を加える仮定があります。
- 変更が多い案件：将来の変更範囲を抑えられる可能性があります。
- 単純・短命な案件：追加費用が効果を上回る可能性があります。
初期費用が増えても、将来の改修費が下がるとは限りません。通常費用に10〜25％程度を加える仮定を置くと、500万〜1,000万円の案件は550万〜1,250万円程度になります。この割合は公的な基準ではなく、外部連携数と変更頻度を踏まえた編集上の試算です。
追加作業には、ドメイン境界、ポート、アダプターの設計と実装が含まれます。さらに、依存性注入やテストダブル、CI/CD、監視・ログも対象になります。
具体的には、DB交換、複数チャネルの追加、制度変更、段階的なクラウド移行が該当します。反対に、外部連携が少ない単純なCRUDや短命な試作では、抽象化や変換コードの費用に対して効果が見合いにくくなります。
保守・クラウド・セキュリティの費用
保守費用は、初期開発費の年15〜25％程度を仮置きできます。一方、クラウド利用料や監視、バックアップなどは、別に見積もります。
- 継続運用：脆弱性対応、OS・ライブラリ更新を含めます。
- 変更対応：追加アダプターや法改正への対応を見積もります。
- 契約範囲：連携先ごとの保守範囲と対応時間を定めます。
アダプターが増えると、外部サービスの仕様変更や認証更新への対応も増えます。
見積書で、設計、実装、各種テスト、データ移行、運用設計を一式にまとめると、内訳が見えにくくなります。そこで、成果物と検収条件を機能や連携先ごとに分けておくと、費用の内訳や要件変更の波及先を判断できます。
ヘキサゴナルアーキテクチャを採用すべき企業と避けるべきケース
採用は、業務の性質と将来の変更から判断します。複雑なルールや複数の画面・API、外部サービスの交換、長期の運用がある場合は、候補になります。
一方で、短期間だけ使う単機能ツールや、登録・検索が中心の画面では、導入コストとの釣り合いを慎重に見ます。
変更と連携が多い業務での採用効果
変更や連携が多い業務では、次のような場面で効果を検討できます。
- 複数の入力経路：受発注・在庫をWeb、スマホ、外部公開API、夜間バッチから使う場合に分けます。
- 複数の外部連携：会計、決済、配送、顧客管理の変換やエラーを外側へ置きます。
- 基幹システム刷新：旧連携を一時アダプターにし、機能単位で切り替えます。
- PoC対象：4項目を各1〜5点で評価し、合計点の高い領域から始めます。
単純なCRUDや短命な試作での過剰設計
単純な業務では、追加レイヤーの負担に注意します。
- 適用を慎重にする条件：入力1種類、単一DB、少ない業務ルール。
- 追加レイヤーの負担：保守コストや理解時間が増える場合があります。
- 避けたい抽象化：交換予定のない処理へ形式だけを導入します。
- 採用範囲の判断：変更・テスト・外部境界の理由を確認します。
公式ガイダンスでも、入力元や出力先が少なく将来変更しない場合は、追加レイヤーの保守コストを考慮するよう示されています。
変換コードやインターフェース、依存性注入の設定が増えると、処理の流れをたどるだけでも手間がかかります。特に、すべてのクラスにインターフェースを作るとコード量が増え、設計意図が見えにくくなります。変更の可能性、テストの必要性、外部との境界を説明できない抽象化は、採用範囲から外します。
パッケージ・クラウド・スクラッチの組み合わせ
方式ごとに、既製の機能と独自の領域の境界を決めます。
- パッケージ・SaaS：標準機能を使い、独自ルールを包みます。
- クラウド：APIやマネージド機能を外側へ配置します。
- スクラッチ：独自性の高い中核領域へ絞ります。
標準機能を使えば作り直す範囲が減り、導入期間と費用を抑えられます。一方で、パッケージの制約や更新方針は、出力ポートの契約に反映します。
クラウドでは、コンテナやマネージドDB、メッセージング、監視も外側へ置けます。また、サーバーレスでは、関数の粒度、コールドスタート、再実行、分散トランザクションを検討します。
独自性が高く、長期的に変更を制御したい中核領域では、スクラッチの設計コストを活かせます。
ヘキサゴナルアーキテクチャのシステム開発会社/ベンダーの選び方
「ヘキサゴナル対応」と掲げているかよりも、対応の中身で開発会社を比べることが大切です。同じRFPで、設計、テスト、運用、移行への対応力を見ます。知名度や総額に加えて、設計成果物と検証方法も確認してください。
設計書とテストコードで見る実績
導入経験の有無に加え、設計とテストの実物で対応力を確かめます。
- 設計実績：匿名化した設計書や構成図を確認します。
- 動作デモ：DBなしの実行やAPIスタブ交換を見ます。
- テスト計画：単体、契約、統合、E2Eの分け方を聞きます。
- 納品と保守：テストコードや再現環境の担当を確認します。
設計書や構成図では、業務ルールをドメインへ切り出す方法、入出力ポート、フレームワークやDB依存の置き場所を確認します。カバレッジの解釈も確かめてください。テストがないまま、フレームワークの自動生成に頼る提案は、慎重に評価します。
既存連携・移行・運用の担当範囲
既存連携の移行計画と、稼働後の運用・引き渡し範囲を確認します。
- 段階移行：旧システム連携と切替条件を設計できるかを確かめます。
- 運用体制：監視、復旧、脆弱性、連携先変更への対応を見ます。
- 引き渡し：納品する範囲を確認します。
旧システムとのAPI、イベント、データ変換アダプターを確認します。加えて、並行稼働と整合性検証、切り戻し、旧機能の停止条件を決めておきます。ストラングラーフィグやアンチコラプション層を使う場合は、残す期間も計画します。
引き渡し対象には、ソースコードやIaC、CI/CD設定があります。さらに、テストコード、依存ライブラリ一覧、運用手順書も含まれます。
2025年公表のSBOM国際ガイダンスは、部品の透明性と脆弱性管理の共有を重視しています。そこで、SBOMの作成、更新、共有もRFPに含めます（出典: 経済産業省・国家サイバー統括室、2025年）。
同じRFPでの3社程度の比較
相見積もりでは、条件をそろえて提示します。利用者数や業務領域、連携数に加え、稼働時間と可用性も示します。移行対象とセキュリティ要件も、同じ条件として伝えます。
- 設計：採用理由、対象範囲、ドメイン境界、ポートとアダプター。
- 品質と運用：テスト戦略、CI/CD、監視、障害時の切り戻し。
- 移行：対象機能と具体的な移行手順。
同じ情報を3社程度へ渡せば、価格だけでなく、設計の前提やリスクも比べられます。
契約では、成果物の権利、ソースコード・IaC・テストコードの扱いを明記します。OSSライセンスやSBOM、脆弱性対応期限、SLA、追加アダプターの単価も、あわせて定めます。
自社で業務ルールを変更する場合は、設計意図の文書と引き継ぎ期間も見積もりに含めます。「何を交換でき、何を交換しないか」を説明できることが、選定の基準になります。
▶ 詳細はこちら：ヘキサゴナルアーキテクチャのシステム開発でおすすめの開発会社/ベンダー6選と選び方
▶ 詳細はこちら：ヘキサゴナルアーキテクチャのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
▶ 詳細はこちら：ヘキサゴナルアーキテクチャのシステム開発の発注/外注/依頼/委託方法について
ヘキサゴナルアーキテクチャのシステムに関するよくある質問
導入前の疑問は、技術の流行よりも、自社の業務ルール、変更予定、連携数、チームの保守力に照らして判断してください。
ヘキサゴナルアーキテクチャにすると費用は必ず高くなりますか？
初期費用は上がる可能性があります。ポート、アダプター、テスト、設計書が増えるためです。
一方、変更や外部連携が多ければ、将来の改修範囲を抑えられることがあります。単純なCRUDや短命な試作では追加費用が効果を上回る場合があるため、範囲を絞ってください。
既存の密結合なシステムにも適用できますか？
密結合なシステムにも適用できます。全体を一度に作り直さず、変更頻度が高く業務影響の大きい機能から境界を切り出します。
旧システムとの連携をアダプターとして扱い、並行稼働、データ整合性、切り戻し条件、旧機能の停止時期を決めて段階移行します。
特定のプログラミング言語やクラウドが必要ですか？
Java、.NET、Kotlin、TypeScript、Go、Pythonなど、複数の言語で実装できます。そのため、特定の言語やクラウドは必須ではありません。
中心のコードが、フレームワーク、DB、クラウドSDKへ直接依存しない状態を保つことが大切です。習熟度、既存資産、採用しやすさ、運用体制を踏まえて選びます。さらに、交換可能なアダプターを継続して保守できる技術かどうかも、判断材料になります。
DDDやマイクロサービスも同時に導入すべきですか？
DDDは業務モデルを整理する方法で、マイクロサービスは配置と運用の単位です。両者は別の概念のため、同時に導入する必要はありません。
業務の複雑さ、チーム体制、障害分離の必要性を確認します。そのうえで、モジュール化モノリスで境界とポートを検証し、必要な領域だけ分割する方法もあります。
まとめ
業務ルールと変更可能性の整理
採用を迷ったら、対象業務の変更頻度、入力経路、出力先、利用期間を確認します。全機能に一律で適用するのではなく、変更や連携が多く、テスト失敗の影響が大きい領域から始めます。
同じ条件での提案比較
発注前に条件と確認項目をRFPへまとめ、同じ条件で複数社の提案を比べます。
- 設計範囲：業務境界、ポート、アダプター、テストを整理します。
- 採用判断：複雑さ、変更頻度、連携数、利用期間を確認します。
- 費用比較：診断50万〜150万円、小規模500万〜1,000万円、中規模1,000万〜3,000万円が概算です。
- 提案比較：設計成果物、移行・運用、引き渡し条件を確認します。
業務ルールを中心に置き、ポートを介して画面、API、DB、外部サービス、メッセージ基盤などのアダプターを接続します。要は、六角形の形やマイクロサービス化そのものではなく、技術変更の波及を抑え、外部環境なしで重要なルールをテストできる設計にあります。
発注時には、交換デモやCI/CD、監視と復旧を確認します。さらに、IaC、SBOM、OSSライセンス、ソースコードの権利も確かめます。
チームの保守力も採用判断に含めます。自社の変化に耐えられる範囲に適用し、品質指標を置くと、長期運用に活かせます。
▼関連記事一覧
・ヘキサゴナルアーキテクチャのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・ヘキサゴナルアーキテクチャのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・ヘキサゴナルアーキテクチャのシステム開発の見積相場や費用/コスト/値段について
・ヘキサゴナルアーキテクチャのシステム開発の発注/外注/依頼/委託方法について
▼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を創業。