ヘキサゴナルアーキテクチャのシステム開発は、まず業務ルールを整理し、契約と責任範囲を決めてから発注します。発注形態や要件整理から委託先選定まで順に進めると、変更に対応しやすいシステムにつながります。
▼全体ガイドの記事
・ヘキサゴナルアーキテクチャのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ヘキサゴナルアーキテクチャのシステム発注の全体像
発注では、まず業務ルールと外部接続を切り分け、将来も変わりにくい業務ルールを中心に置きます。この形にしておくと、DBや外部サービスを入れ替えても業務ルールに手を入れずに済みます。画面やAPI、データベースなどの接続先は、ポートとアダプターを介してつなぎます。
発注対象は技術名ではなく設計上の成果
「ヘキサゴナルアーキテクチャで開発」という書き方では、会社ごとに解釈が変わります。そのため、RFPでは確認できる状態を指定します。
- 業務ルール：受注登録をDBなしでテストできる状態
- 共通利用：REST APIと夜間バッチが同じユースケースを使う構成
- DB交換：RDBを交換しても、ドメイン層は変更しない
発注側は、成果物にコンテキスト境界図や依存方向を示す構成図、ポート定義、アダプター一覧を含めるよう求めます。さらに、テストコード、CI/CD設定、監視設計も発注対象に含めます。
採用に向く案件と向かない案件
業務ルールと外部接続を分ける効果が出やすいのは、次のような案件です。
- 複数の入力経路：同じ業務ロジックを共有する場合
- 外部連携が多い：ERP、決済、在庫などとの接続
- 長期運用：制度変更やサービス交換の想定
一方で、短期利用の小規模なCRUDツールや、画面と単一DBで完結する試作では、ポートや変換コードが保守の負担になる可能性があります。なお、AWS Prescriptive Guidanceも、入力元・出力先や将来の技術変更が複数ある場合に適すると説明しています（出典: AWS Prescriptive Guidance、2026年8月確認）。
接続先が少ない場合は、追加レイヤーの保守負担と遅延に注意する設計としています。
発注形態の選び方
発注形態は、要件の確定度と発注側の管理能力で決まります。全工程を一社に任せる方法もあれば、設計を自社で持ち、実装を外注する方法もあります。さらに、複数社を組み合わせる方法もあり、それぞれ適した条件があります。
要件が固まっている案件に向く一括請負
対象業務や連携先、要件が明確で、納期と受け入れ基準も定まっていれば、要件定義からテストまでを主契約者にまとめる一括請負が候補になります。一括請負なら、窓口を一本にまとめやすく、予算も立てやすくなります。
ただし、設計判断やドメイン境界を委託先に任せきりにすると、納品後に設計意図が分からなくなるリスクがあります。そのため、納品対象には設計書とテストコード、リポジトリを明記してください。CI/CDやIaC、依存ライブラリ一覧も、納品対象に含めてください。
変化が大きい案件に向く準委任と内製併用
要件を検証する新規事業や、既存システムを解析する段階移行では、準委任でアーキテクトや開発チームを一定期間確保する方法が有効です。発注側が業務判断と優先順位を持ち、委託先が設計と実装を支援します。そのため、変更に対応しやすい体制になります。
ただし、この進め方は、自社にプロダクトオーナーや業務責任者、技術責任者を置き、意思決定の期限を決めておくことが前提です。特に、丸投げに近い状態では、準委任でも成果が安定しにくくなります。
複数社発注の責任境界
会社ごとの責任を決めるときは、次の作業ごとに、接続点と担当者を明確にします。
- 設計・実装：ポートの定義とアダプターの実装
- 運用：障害の一次切り分け
- 境界領域：データ移行、認証、外部API、監視、バックアップ
パッケージ導入会社とアプリ開発会社、クラウド運用会社を組み合わせると、中でも境界領域の作業が抜け落ちがちです。そのため、RACI表やシステム境界図を契約の添付資料とし、インターフェース仕様と受け入れテストの責任者を明示しておくと、責任の押し付け合いを避けられます。
RFPと要件整理の決め方
RFPには、機能一覧だけでなく、業務ルールや外部接続を書きます。品質基準、納品物、運用責任も、あわせてまとめます。業務の中心と技術の境界を定義できるかが、品質を左右します。なお、現行資料が不完全なら、開発前に診断やPoCのフェーズを置く選択肢もあります。
ユースケースと不変条件で書く業務要件
業務要件は、誰が、どの条件で、どのデータを入力するかまで記すと、見積もれる粒度になります。たとえば「受注を登録する」という一文では、見積もりの材料が足りません。
- 例外処理：在庫不足や与信超過時の応答、二重送信の扱い
- 業務の流れ：販売担当者が商品・数量・納期を入力し、在庫引当成功後に受注を確定
- ルール：金額計算、権限、状態遷移、監査記録、再実行可否
業務要件を整理すると、中心のドメインに置くべきものが見えてきます。
接続単位で指定するポートとアダプター
RFPでは、入力ポートと出力ポートを分け、接続先や入出力の条件を書きます。
- 入力ポート：Web画面、REST API、バッチ、キュー受信
- 出力ポート：受注リポジトリ、在庫照会、決済、通知、ERP連携
- 各ポートの条件：データ、エラーコード、タイムアウト、リトライ、冪等性、認証、性能目標
アダプターは接続先ごとに実装します。業務ルールがAWS SDKやJDBC、HTTPクライアントを直接呼ばないことは、受け入れ条件に加えます。
AWSのガイダンスでは、ポートを技術に依存しないインターフェース、アダプターを外部とのデータ交換を変換する実装としています（出典: AWS Prescriptive Guidance、2026年8月確認）。
非機能要件と引き渡し条件の数値化
開発会社との認識差を防ぐため、性能目標と完成後の受け入れ基準を、RFPに定めます。
- 数値化：可用性、応答時間、同時利用者数、復旧時間
- 保持・対応期限：バックアップ保持期間、ログ保存期間、脆弱性対応期限
- テスト：ドメイン単体、外部サービスなし、契約、性能、障害追跡
- 完成条件：テスト環境でのアダプター交換、障害ログからの接続追跡
「画面が動く」ことだけを基準にすると、認識の差が残りやすくなります。
ヘキサゴナルアーキテクチャの開発の進め方
開発は、企画と要件定義から始め、方式設計、実装、テスト・移行・運用設計へと進めます。最初から全機能を作らず、重要なユースケースで交換性とテスト容易性を確かめると、設計の誤りを早く見つけられます。
境界と依存方向の初期合意
設計の初期には、受注や在庫、請求、配送などの業務境界と、ドメイン層に置くルールを決めます。
- アプリケーション層：ユースケースの順序やトランザクションを調整
- 入力アダプター：HTTPや画面の形式を変換
- 出力アダプター：DBや外部APIの差異を吸収
依存方向は外側から中心へ向けます。そのうえで、中心のコードが具体的なフレームワークを参照しないことを、構成図とコードレビューで確認します。
重要な業務のPoCと実装の広げ方
PoCでは、受注登録など重要なユースケースを選び、画面またはAPIから入力して、ドメインルールを通します。
- アダプター交換：テスト用と実DB用を切り替えたときの結果
- 単体テスト：外部環境なしでのドメイン実行
- 異常系：外部APIのスタブを使った再現
設計書だけで全体を確定すると、現場で責務が曖昧になりやすくなります。そのため、同じポートに別のアダプターを接続できることも、合格条件に含めます。
開発と並行するテストと移行
テストは、種類ごとに対象を分けて確認します。
- 単体テスト：ドメインの計算や状態遷移
- 契約テスト：ポートの入出力
- 統合テスト：実DB、外部API、メッセージ基盤
刷新では、現行データの意味を解析し、アンチコラプション層や変換アダプターを設けます。そのうえで、機能単位の並行稼働とデータ照合も行います。
なお、富士通のモダナイゼーション資料も、既存業務システムの構造とデータを整理して移行計画につなげる考え方を示しています（出典: 富士通「業務システムのモダナイゼーション」、2025〜2026年公開資料）。特に、全面再構築だけを前提にしないことが大切です。
契約形態の組み合わせ方
契約は、不確実性が高い工程と、完成物を確定しやすい工程を分けて考えます。現行解析やドメイン境界の決定は、不確実性が残りやすい工程です。
初期調査から本開発までを固定価格にしない方法もあり、工程を分けると双方のリスクを管理しやすくなる場合があります。
請負契約の範囲と完成基準
請負では、対象機能や対応ブラウザ、端末、連携先を、契約書や仕様書に結び付けます。性能やセキュリティ、移行データ、検収方法についても、具体的に書き込みます。
- 完成基準：中心層から外部SDKへの直接依存がない
- 受け入れ条件：指定したテストが通ること、設計書とソースコードの引き渡し
- 変更時の扱い：追加変更、前提崩れ、遅延時の協議と責任
完成基準にするには、「ヘキサゴナル対応」という名称を、具体的な条件に置き換える必要があります。
準委任契約の体制と作業範囲
準委任では、一定期間の体制と担当作業を明示します。体制には、アーキテクトやテックリード、開発者、QAなどを含めます。準委任は、成果物の完成を一方的に保証する契約ではないため、この体制と担当作業の中身が特に問われます。
週次レビューや設計判断の記録、リスク一覧は、定例化して進めます。品質指標と次週の予定は、定例の議題にします。
人月や稼働時間だけでなく、ユースケース単位の進捗と未解決の設計課題も、報告の対象にします。そうしないと、ポート定義やテスト設計が後回しになりかねません。
知的財産権と保守の境界
契約では、ソースコードやテストコード、設計書の利用権を定めます。API仕様やIaC、CI/CD設定、コンテナ定義などのほか、依存ライブラリ一覧と運用手順書も、利用権の対象です。
また、既存の汎用部品やOSSと、今回開発する個別部分の権利は分けて扱います。二次利用や改修を妨げない条件も、あわせて確認します。
保守契約では、障害対応時間と脆弱性の修正期限を定めます。クラウド費用や追加アダプターの単価も、別々に示してもらいます。加えて、担当交代時の引き継ぎ方法も記載しておくと、納品後の費用を並べて比べられます。
費用相場とコストの内訳
ヘキサゴナルアーキテクチャ単独の公的な価格統計はありません。そのため、金額は、一般的な業務システムの規模や連携数、移行範囲に加え、非機能要件から見積もります。
次に示すのは、2026年公開の費用情報と業務システムの見積もり観点をもとにした、編集用の概算です。要件定義後に、各社から内訳付きで見積もりを取ってください。
案件規模ごとの概算レンジ
規模別の概算レンジを並べて比べてみます。ただし、これらは固定相場ではありません。
- 診断・設計：50万〜150万円程度
- 小規模新規：500万〜1,000万円程度
- 中規模：1,000万〜3,000万円程度
- 段階移行：対象範囲ごとに800万〜3,000万円程度
- 大規模：全社基幹や高可用性を含むと3,000万円〜1億円以上の場合があります
金額は、利用者数や機能数、外部連携によって変わります。さらに、データ移行や性能、24時間運用の有無でも変わります。
SIA株式会社の2026年版では、小規模業務ツールが100万〜300万円、中規模の部門横断システムが500万〜1,000万円です。
大規模基幹システムは1,000万円〜数千万円以上、人月単価は60万〜200万円程度とされています（出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年確認）。
別の業務システム相場にも幅があるので、記事のレンジを発注額とはせず、同じRFPで比べてください。
設計・テスト・移行の上乗せ
ドメイン境界やポート、アダプターを初期から設計すると、単純なCRUDより工数が増えることがあります。依存性注入やテストダブル、契約テストに加え、CI/CDや監視も初期の設計対象になります。
編集上の試算では、通常費用に10〜25%程度を上乗せすると、中規模の500万〜1,000万円は550万〜1,250万円程度になります。
この10〜25%は、公的統計や固定料金ではなく、案件の複雑度から置いた仮定です。そのため、見積書では設計、ポート・アダプター実装、テストを分け、移行や運用設計も別々に示してもらい、根拠を確認します。
初期費用と分けた運用費と保守費
稼働後は、クラウド利用料や監視、バックアップに加えて、ログの保管も費用になります。さらに、脆弱性や障害への対応、法改正対応、追加アダプターの開発費もかかります。
保守費を初期開発費の年15〜25%程度として仮置きする見積もりもあります。ただし、これは契約内容で変わる目安です。
24時間365日の監視と、平日日中の問い合わせ対応では、費用が異なります。そのため、SLAや対応時間、月次の改修枠に加えて、クラウドの従量課金も分けて提示してもらいます。
委託先選定と見積比較の観点
委託先は、設計判断を成果物とデモで確認して選びます。営業資料にある「ヘキサゴナル対応」という表現は、判断材料の一つにとどめます。
候補会社には同じRFPを渡し、業務理解、ポート、既存連携の順に回答してもらいます。そのあとに、移行やテスト、セキュリティ、運用、引き渡しを続けてもらいます。
価格だけでなく、将来の変更に自社でどこまで対応できるかも比べます。
採用実績と関連実績の区別
実績の種類や相談分野を分けて確認し、候補企業を比べます。
- 実績の区分：採用事例と関連実績を分け、関連実績を採用済みとは断定しない
- 大規模・金融・基幹連携：NTTデータなど。段階移行では富士通やNECが挙がる
- データ連携・クラウド移行：SCSKやTIS。API運用の例ではTISなど
- 社会インフラ刷新：日立製作所など。順位ではなく、相談先の例
- 発注前の確認：担当者の実装経験、設計書・テストコード・IaC、追加費用
公開情報で採用を具体的に確かめられる事例には、FintanのNTTデータ系の事例があります。この事例では、Nablarchへの依存をアダプター側に閉じ込め、ビジネスロジックとDBアクセスを分けています。
モック用アダプターでテストやデモを行う考え方も確認できます（出典: Fintan「ヘキサゴナルアーキテクチャ導入事例」、2026年8月確認）。
見積書の作業単位と前提条件
見積比較では、工程と作業を分け、前提条件をそろえます。
- 作業：要件定義、設計、画面・API、ドメイン、アダプター、移行、テスト、リリース、運用設計
- 規模の前提：外部連携が5本か20本か、移行データが何年分か
- 費用の前提：並行稼働の月数、人月単価、役割、再利用部品、ライセンス、クラウド、旅費、予備費
前提が違う総額は、そのままでは比べられません。そのため、各社に同じ項目で提示してもらいます。
技術評価では、受注登録のサンプルを使い、REST入力アダプターからRDBアダプターまでの依存関係を説明してもらいます。加えて、RDBをインメモリー実装へ交換するデモを見ます。外部API失敗時のリトライとログ、単体テスト、認証・認可の境界も確認します。
図だけで、コードやテストが伴わない提案は、発注後に追加費用が出やすいため注意が必要です。
提案評価に加えるセキュリティとSBOM
個人情報や決済に加え、監査ログや権限、秘密情報を扱う場合は、次の対策と管理を確認します。
- 接続ごとの対策：認証・認可、暗号化、ログのマスキング、権限エラー
- SBOM管理：依存ライブラリやコンテナイメージを一覧化
- 脆弱性対応：通知から再リリースまでの担当
経済産業省は2025年、SBOMの活用と、開発者・調達者・運用者の間での共有を促す国際ガイダンスに共同署名しました（出典: 経済産業省、2025年9月）。
この動きは、SBOMをRFPや保守契約の確認項目に含める根拠になります。
よくある質問
発注や外注のときによくある疑問を取り上げます。費用や契約、既存システムとの関係も、判断の材料にしてください。
ヘキサゴナルアーキテクチャのシステム開発費用はいくらですか？
小規模は500万〜1,000万円程度、中規模は1,000万〜3,000万円程度などの概算があります。ただし、固定相場ではありません。
ポート数や外部連携、移行データの条件をそろえ、設計とテストの費用を分けると比較しやすくなります。テストや可用性、運用要件の前提もそろえます。
既存の密結合なシステムも外注で移行できますか？
移行はできますが、全体を一度に作り直す方法に限りません。業務領域や機能の単位で、現行解析や境界設計、変換アダプターを進めます。
並行稼働とデータ照合も行います。現行の仕様が不明なら、まず診断とPoCを、準委任か小規模な請負で発注します。
そのうえで、診断とPoCの結果を使って本開発の範囲を確定すると安全です。
JavaやAWSなど特定の技術を指定すべきですか？
技術名より、業務ルールをフレームワークやDBから分けて、将来の変更に対応できることを要件にします。
候補技術は、社内スキルや運用体制を踏まえて比べます。そのうえで、セキュリティやライセンス、採用市場も見ます。選定理由と長期保守の担当は、提案書に記載してもらいます。
委託先がヘキサゴナル対応と言うとき何を確認すべきですか？
担当者の実案件や設計書を見て、ドメイン単体テストやポートとアダプターの構成を確認します。
外部API障害時の処理やアダプター交換のデモも見ます。さらに、ソースコードやテスト、IaC、SBOMを引き渡せるか確かめ、監視設定や運用手順も確認してください。
追加改修や保守の担当者と費用も確認すると、発注後の認識違いを減らせます。
まとめ
発注時は、設計パターン自体を目的にせず、変更したい業務ルールと交換したい外部技術を整理します。
要件が固まっていれば請負、変化が大きければ準委任、複数社なら責任境界を文書で明確にする、という考え方で選びます。
発注前の業務ルールと責任範囲
業務ルールはユースケースと不変条件にまとめ、変更や外部連携、長期運用にかかわる領域を特定します。
RFPには、ポートやアダプター、テスト、移行の要件を書きます。さらに、運用やSBOM、ソースコードの要件も書き、請負と準委任の境界を決めます。
初期費用と運用までの見積比較
見積もりと委託先は、費用や成果物、運用条件を合わせて比べます。
- 見積内訳：設計、実装、テスト、移行、運用の条件をそろえる
- 提案・引き渡し：実績、交換デモ、テストコード、コード、運用を確認する
- RFP：ユースケース・不変条件・ポート・アダプター、非機能要件、テスト、移行・監視、SBOM・ソースコードを受入条件にする
- 費用比較：規模別レンジを基準に、設計・テスト・移行の上乗せを仮定として分け、同条件で比べる
- 運用・保守：保守単価や脆弱性対応を含め、自社で理解・変更できる委託先を選ぶ
▼全体ガイドの記事
・ヘキサゴナルアーキテクチャのシステム開発の完全ガイド
▼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を創業。