ヘキサゴナルアーキテクチャのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

ヘキサゴナルアーキテクチャのシステム開発は、業務ルールをデータベースや画面、外部サービスから切り離し、変更が起きても影響範囲を抑えやすくする進め方です。

ただし、六角形の図を描くだけでは成果につながりません。要件整理から設計・開発、テスト、稼働、定着までの各段階で、どの業務を中心に置き、どの接続をポートとアダプターに分け、どの成果物で品質を確認するかを決める必要があります。この記事では、受発注や在庫管理などの業務システムを想定し、採用判断、6フェーズの進め方、費用相場、見積もり時の確認項目を実務向けに解説します。

▼全体ガイドの記事
・ヘキサゴナルアーキテクチャのシステム開発の完全ガイド

ヘキサゴナルアーキテクチャのシステムとは何ですか？全体像を理解する

ヘキサゴナルアーキテクチャは、別名「ポートとアダプター」と呼ばれる設計パターンです。中心に業務ルールとユースケースを置き、外部との接続をインターフェースであるポートと、技術ごとの実装であるアダプターに分離します。六角形はポートが6個あるという意味ではなく、入力と出力を複数の方向から捉えるための図形です。

たとえば受注管理では、「在庫が確保できた場合だけ受注を確定する」「与信限度額を超える注文は承認に回す」「キャンセル可能な期限を過ぎたら取消を受け付けない」といったルールがドメインの中心です。画面のURL、SQLの書き方、利用するクラウドSDKは業務ルールそのものではありません。そのため、中心のコードから技術要素を参照させないことが基本になります。

入力ポートは「受注を登録する」「在庫を照会する」など、外部から利用するユースケースの契約です。入力アダプターはREST API、管理画面、スマートフォン、CLI、夜間バッチ、メッセージ受信などを担当します。出力ポートは「注文を保存する」「在庫を引き当てる」「請求システムへ通知する」といった外部への依頼を表し、出力アダプターがRDB、NoSQL、ERP、決済API、メール、メッセージブローカーなどへ変換します。

採用に向くのは、同じ業務ルールをWeb画面、外部公開API、バッチなど複数の入口から使うシステムです。将来、RDBを交換する、外部決済を変更する、既存基幹との連携を増やす、制度改正で計算ルールを変えるといった予定がある場合も効果を見込みやすくなります。AWS Prescriptive Guidanceも、複数の入力元や出力先があり、UIやデータストアを定期的に更新するシステムを適用候補として説明しています（出典: AWS Prescriptive Guidance、2026年参照）。

一方、画面数が少なく、外部連携もなく、数か月で役割を終える単純なCRUDツールでは、ポートや変換コードの保守負担が効果を上回る可能性があります。導入すると決める前に、今後3〜5年で変更される業務ルール、接続先、利用者数、規制対応を一覧にしてください。導入理由を「流行のアーキテクチャだから」ではなく、「変更コストを管理したいから」と説明できる状態が出発点です。

ヘキサゴナルアーキテクチャのシステム開発の進め方

進め方の軸は、要件整理、方式・開発会社の選定、設計・開発、テスト、稼働、定着の6フェーズです。各フェーズで「次へ進む条件」を決めると、アーキテクチャの議論が抽象論に流れにくくなります。特に、ドメインの境界とポートの契約を急いで確定せず、業務担当者が使う言葉と実際の例外処理を先に整理することが重要です。

最初に、画面や機能のリストではなく、業務の目的と判断ルールを整理します。受注、在庫、請求、配送などの業務単位ごとに、誰が、何を入力し、どの条件で、どの結果を出すのかを確認します。正常系だけでなく、在庫不足、二重送信、承認却下、タイムアウト、部分的な連携失敗、再実行時の重複登録まで業務担当者に聞き取ります。

この段階の成果物は、業務用語集、ユースケース一覧、業務ルール、外部システム一覧、データの責任範囲、非機能要件、変更頻度の見立てです。各ユースケースには入力、出力、エラー、権限、監査ログ、冪等性の要否を記録します。ヘキサゴナル化の対象は、業務ルールが複雑で変更される領域から始め、単純なマスタ登録まで一律に抽象化しないことが費用と納期を守るポイントです。

完了条件は、業務担当者がユースケースの例を読んで「この判断で合っている」と確認できることです。画面仕様だけが完成していて業務ルールが曖昧な場合は、次の選定フェーズへ進めません。例外処理の確認を後回しにすると、後からドメインモデルとアダプターの双方を作り直すことになります。

開発会社や技術を選ぶときは、「ヘキサゴナルに対応できます」という営業文句だけで判断しないでください。過去の設計書で、ドメイン層がフレームワークやDBクライアントを直接参照していないか、入力ポートと出力ポートの責務が分かれているか、テストダブルを使った単体テストがあるかを確認します。可能であれば、匿名化したコード例や、RDBアダプターをインメモリー実装へ差し替えるデモを依頼します。

候補会社には同じRFPを渡し、業務境界、移行方針、クラウドとオンプレミスの選択理由、監視、障害復旧、CI/CD、セキュリティ、保守体制を同じ条件で回答してもらいます。比較対象は価格だけではありません。自社に近い業務ドメインの経験、外部連携の数、既存システムを止めずに移行した経験、設計・テストコード・IaC・依存ライブラリ一覧の引き渡し範囲を評価します。

選定の完了条件は、採用する設計原則と責任分界が契約書や提案書に記載されていることです。ソースコードの著作権、二次利用の範囲、OSSライセンス、脆弱性修正の期限、追加アダプターの単価、障害時の連絡体制まで確認します。

設計では、まずドメインモデルとユースケースを定義し、次に入力ポートと出力ポートの契約を決め、最後に各アダプターを実装します。受注登録なら、RESTのリクエストを受ける入力アダプターが入力ポートを呼び、アプリケーションサービスが在庫確認と与信判定を調整し、ドメインが受注可否を判定します。その後、出力ポートを通じてRDB保存や在庫システムへの通知を行います。

ポートには、データ形式だけでなく、エラー、タイムアウト、リトライ、トランザクション境界、再実行時の重複防止を含めます。外部APIが「成功」と返しても、後続のDB保存に失敗するケースや、メッセージが少なくとも1回配送されるケースを考慮する必要があります。アダプターの責務は変換と接続に絞り、業務判断をアダプター内に書かないことが依存方向を守るコツです。

実装順は、ドメイン、アプリケーションサービス、入力アダプター、DBや外部APIの出力アダプターが基本です。Fintanの公開事例でも、Java 8とNablarchを使う2〜3人、2.5か月のマイグレーション案件で、ビジネスロジックをフレームワークやDBから分離し、要求変更への追従と環境なしのデモを目指していました（出典: Fintan「ヘキサゴナルアーキテクチャ導入事例」、2019年公開）。規模や技術が異なるため自社案件へ期間をそのまま当てはめられませんが、中心の業務ロジックを先に確かめる進め方は参考になります。

テストは、ドメイン単体、アプリケーションサービス、アダプター、契約、結合、E2Eの役割を分けます。ドメイン単体テストではDBやHTTPサーバーを起動せず、在庫不足、与信超過、期限切れ、同一注文の二重登録などの判断を短時間で繰り返し確認します。出力ポートはモックやインメモリーアダプターで置き換え、業務ルールのテストが外部環境の不安定さに左右されないようにします。

アダプターには、実DBとのマッピング、NULLや文字コード、タイムゾーン、APIのエラー変換、認証情報の扱いを確認するテストを用意します。ポートの契約テストでは、入力アダプターが渡すデータと、出力アダプターが返す結果の形式を固定します。E2Eでは、受注登録から在庫引当、請求連携、監査ログまでの業務シナリオを確認し、失敗時に再実行できるかも検証します。

品質の合格基準は、テスト件数だけでなく、重要な業務ルールの網羅、外部連携の失敗時の挙動、ログから注文番号を追跡できること、性能目標を満たすことです。CI/CDで単体・契約テストを毎回実行し、依存方向を静的解析で検査できると、開発者が増えた後もアーキテクチャの境界を維持しやすくなります。

稼働前には、データ移行、権限、バックアップ、監視、障害連絡、ロールバック、外部連携の切替時刻を決めます。レガシーシステムを刷新する場合、全機能を一度に切り替えるのではなく、対象業務を選び、既存システムの周囲に変換アダプターやAPIを置き、機能単位で新システムへ移す方法が現実的です。並行稼働中は、件数、金額、在庫残高、更新日時を照合し、差異が出た場合の責任者を決めておきます。

監視はサーバーのCPU使用率だけでは不十分です。ポートごとの呼び出し数、外部APIの失敗率、リトライ回数、処理時間、キュー滞留、業務エラー、監査ログの欠落を記録します。障害時には入力アダプター、ユースケース、出力アダプターのどこで止まったかを追える相関IDを付与し、個人情報をログへ出し過ぎない設計にします。

本番切替の完了条件は、正常に動くことだけではありません。バックアップから復元できること、ロールバック手順を演習済みであること、想定利用者が業務を完了できること、障害連絡の受付時間と復旧目標が合意されていることまで確認します。

稼働後は、新機能を追加するたびにドメインへ業務ルールを置き、技術固有の処理をアダプターへ閉じ込めるという原則を守ります。設計判断を記録するADR、ポートの契約、アダプター一覧、テスト方針、依存ライブラリ一覧を更新し、担当者が変わっても判断理由を追える状態にします。

定着度は、変更リードタイム、リリース後の障害件数、単体テストの実行時間、外部連携の失敗率、アダプター追加に要した工数、手戻りの発生箇所などで測ります。最初から完璧な分離を目指すのではなく、変更が多い業務から改善し、四半期ごとに依存方向とテストの状態をレビューします。

セキュリティ面では、認証・認可、秘密情報、脆弱性、OSSライセンス、監査ログの責任者を明確にします。経済産業省などが2025年にSBOM活用の国際ガイダンスへ共同署名しているため、2026年時点の調達では、アダプターが利用するライブラリやコンテナイメージを一覧化し、脆弱性発見時に誰が更新し、どの期間で配布するかをRFPと運用契約に含めることが重要です（出典: 経済産業省「SBOMの共有ビジョンに関する国際ガイダンス」、2025年）。

ヘキサゴナルアーキテクチャのシステム開発の費用相場とコストの内訳

ヘキサゴナルアーキテクチャだけの公的な価格統計はありません。以下の金額は、2026年公開の一般的なシステム開発費用、公開事例、ポート・アダプター・テスト・移行の工数をもとにした編集上の概算です。業務の複雑さ、利用者数、外部連携、既存資産、非機能要件、発注先の体制で大きく変わるため、予算計画の初期レンジとして利用してください。

アーキテクチャ診断と基本設計だけなら、現行コードの分析、業務境界の整理、移行優先順位、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ライセンス一覧まで確認します。設計書だけ納品され、テストコードや構築定義が発注先に残ると、将来の会社変更や内製化で追加費用が発生しやすくなります。

開発会社を比較するときは、ヘキサゴナルの採用実績が公開されているか、担当チームが自社案件へ説明できるかを分けて確認します。たとえばFintanには、Nablarchへの依存をアダプター側へ閉じ込め、ビジネスロジックとDBアクセスを分離した事例があります。一方、クラウド移行やマイクロサービスの実績が豊富でも、それだけでヘキサゴナルの実装力が証明されるわけではありません。設計書、コードレビュー、テスト自動化、障害対応の実例を質問してください。

候補先には、受注登録を題材に「RESTとバッチの2つの入力アダプターをどう作るか」「RDBから別のデータストアへ変更するとき中心のコードは何を直すか」「外部APIがタイムアウトしたときどう再実行するか」を聞きます。回答が技術名の羅列ではなく、依存方向、データ変換、エラー、テスト、監視、運用まで一貫していれば、実装後の保守も想像しやすくなります。

見積もり時は、データ品質、既存システムの仕様不明、外部APIの制限、性能不足、移行期間の延長、法改正、開発者の交代をリスクとして一覧化します。各リスクに、調査の担当者、確認期限、予備費の扱い、変更管理の方法を付けます。現行コードを読まずにレガシー移行費用を固定すると、後から解析費や並行稼働費が膨らみやすくなります。

また、ポートやアダプターを増やせば必ず柔軟になるわけではありません。AWSの公式ガイダンスも、追加のアダプターは保守負担を増やし、接続層によっては遅延が生じる可能性があると説明しています（出典: AWS Prescriptive Guidance「Hexagonal architecture pattern」、2026年参照）。外部連携が少ない機能まで同じ粒度で分割せず、変更頻度と将来の交換可能性を根拠に対象範囲を決めてください。

ヘキサゴナルアーキテクチャのシステム開発でよくある質問

最後に、導入前に特に質問されやすい点を整理します。ヘキサゴナルアーキテクチャは特定の言語やクラウドを選ぶ仕組みではなく、依存方向と接続の責務を管理する設計パターンです。そのため、採用可否は技術名ではなく、業務の変化と運用体制を基準に判断します。

同じものではありません。ヘキサゴナルアーキテクチャはポートとアダプターで外部との接続を分離する設計パターンで、DDDは業務知識をモデル化する開発手法、クリーンアーキテクチャは依存方向と同心円状の境界を整理する考え方です。組み合わせて使えますが、DDDやマイクロサービスを採用すれば自動的にヘキサゴナルになるわけではありません。

将来の変更、外部連携、複数の入口、長期運用が見込まれるなら、小規模でも中心の業務ルールだけを分離する価値があります。ただし、利用期間が短く、単純なCRUDで、技術交換の予定がない場合は、全体へ適用すると実装と学習のコストが先行します。まず重要な1ユースケースでドメイン単体テストとアダプター分離を試し、効果を確認してから範囲を広げる方法が安全です。

すべてを作り直す必要はありません。変更が多い業務から対象領域を選び、既存システムとの境界にAPI、イベント、変換アダプター、アンチコラプション層を置き、並行稼働とデータ照合を行いながら段階的に移行できます。現行仕様が不明な場合は、最初にコード解析と業務確認の小さな診断を行い、移行対象、残す機能、廃止する機能を決めてください。

まず対象業務、外部連携、利用者数、データ量、非機能要件、移行範囲を整理し、ポート・アダプター・テスト・運用を分けたRFPを作成します。そのうえで複数社から、要件整理やPoCを含む概算、設計・開発、移行、本番後の保守を分けて提示してもらいます。相場の数字は予算の幅を決める材料であり、最終金額は業務ルールと連携仕様を確認した見積もりで判断してください。

まとめ：6フェーズでヘキサゴナルアーキテクチャのシステムを定着させます

ヘキサゴナルアーキテクチャのシステム開発は、業務ルールを中心に置き、外部との接続をポートとアダプターへ分けることで、変更しやすさとテストのしやすさを高める進め方です。効果が大きいのは、複数の入口や外部連携があり、制度や業務要件が変わり、長期間運用するシステムです。単純なCRUDへ一律に適用すると、コード量と学習コストが増える可能性があります。

要件整理では業務ルールと例外を洗い出し、選定では設計成果物とテスト実績を比較します。設計・開発ではドメインからポート、アダプターの順に責務を決め、テストでは単体、契約、結合、E2Eを使い分けます。稼働では移行、監視、復旧を確認し、定着では変更リードタイムや障害件数を測定します。この6つの完了条件をRFP、計画書、契約、レビューに反映してください。

最初から全社システムを作り直すのではなく、変更が多く事業インパクトも大きい受注や在庫などのユースケースを一つ選び、業務ルール、ポート、アダプター、テスト、運用の小さな設計を作ると判断しやすくなります。開発会社へ相談するときは、DBなしで業務ルールをテストできること、外部APIの差し替え方、障害時の追跡方法、テストコードとIaCの引き渡し範囲を具体的に質問してください。

ヘキサゴナルアーキテクチャは、採用すること自体が目的ではありません。将来の変更をどこへ閉じ込め、業務担当者が安心して改善を続けられるかを基準に、費用と運用体制を含めて選ぶことが成功への近道です。

▼全体ガイドの記事
・ヘキサゴナルアーキテクチャのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。