ヘキサゴナルアーキテクチャのシステム開発でおすすめの開発会社/ベンダー6選と選び方

ヘキサゴナルアーキテクチャのシステム開発では、設計パターンの知識だけでなく、業務理解から運用まで一貫して設計できる会社を選ぶことが大切です。

採用実績を「ヘキサゴナル対応」の一言で判断すると、設計・移行・保守で認識がずれやすくなります。計6社を、公開情報の確度と相談時の確認事項から比べます。

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

  • 業務理解と外部連携の設計
  • テスト・移行・運用を含む6社比較
  • 公開情報と相談時の確認事項

ヘキサゴナルアーキテクチャのシステム会社選びが重要な理由

ヘキサゴナルアーキテクチャの会社選びを検討する担当者

ヘキサゴナルアーキテクチャの導入の成否は、図の描き方よりも、業務ルールと外部技術の境界をどこに置くかで決まります。会社選びでは、ドメインやユースケースの整理からポートの契約、アダプターの実装、テスト、障害時の運用まで、同じチームが説明できるかを確かめてください。

適切なパートナー選定が成否を分ける理由

ヘキサゴナルアーキテクチャでは、中心側のドメイン層やアプリケーション層が、RDBやWebフレームワーク、クラウドSDKなどの具体的な技術に直接依存しないようにします。たとえば受注登録では、REST APIの入力アダプターが入力ポートを呼び出し、ドメインが受注可否や在庫引当を判断します。そのうえで、出力ポートを通じてRDBや在庫サービスのアダプターへ処理を渡します。

担当会社が業務の不変条件を理解しないままインターフェースだけを増やすと、見た目は疎結合でも、重要な判断が外周のアダプターに埋もれてしまいます。また、この設計は1つのアプリケーションをモジュール化したモノリスにも、複数サービスにも適用できます。マイクロサービスそのものとは別の考え方です。

AWSの公式ガイダンスでも、データストアやユーザーインターフェースからアプリケーションを分離し、ポートを介して複数のアダプターを接続する考え方が説明されています。会社選びでは、流行の構成を勧めるかどうかより、業務の変更頻度と連携数に合わせて適用範囲を絞れるかを見極めることが大切です。

発注前に確認すべきポイント

発注側は、提案依頼書に利用者数や画面数だけでなく、業務ルールの変更頻度と外部連携先を記載します。入力経路、許容停止時間、データ移行の対象も盛り込んでおくと、提案の前提がそろいます。

そのうえで、「ドメイン層がDBなしでテストできること」「本番用RDBアダプターとテスト用インメモリアダプターを交換できること」「ポートの契約とエラー処理を設計書に残すこと」を成果物として指定します。さらに、見積もりは一式で受け取らず、工程ごとに分けてもらうことが大切です。特に、アーキテクチャ診断と設計、ポートとアダプターの実装は、別の項目として示してもらってください。

残りは、テストから運用までの工程について、内訳を示してもらいます。

  • 単体・結合・E2Eテスト
  • 移行
  • CI/CD
  • 監視・障害復旧

初期費用だけでなく、追加アダプターの単価やクラウド利用料、脆弱性対応も含めて、同じ前提で比べてください。ソースコード・IaC・テストコードの引き渡し条件も、見落とさないことが大切です。

ポイント

判断の目安は、業務ルールと外部技術の境界をどこに置くかを、設計からテスト、障害時の運用まで同じチームが説明できるかです。

株式会社ripla|コンサルから開発まで一気通貫で支援

株式会社riplaのシステム開発支援

riplaは、コンサルティングから開発まで一気通貫で支援できる企業です。IT事業会社として社内DXを推進してきた経験を活かし、ビジネスへの成果創出とシステムの定着支援に強みがあります。

営業・顧客・生産・販売管理など、幅広い基幹システムの構築・導入実績があり、企業の業務要件に合わせて柔軟に対応できる体制があります。

特徴と強み

riplaの強みは、業務の整理とシステム実装を切り離さずに検討できる点です。業務担当者の言葉をユースケースと不変条件に変換し、画面・API・バッチから同じ業務ロジックを呼び出す構成を相談できます。

ヘキサゴナルアーキテクチャを採用する場合は、最初にすべての機能を抽象化するより、受発注や在庫など変更の影響が大きい領域を優先するほうがよいです。単純なマスタ管理は、適切な粒度にとどめることが大切です。

また、アーキテクチャの選択を目的にせず、利用定着や業務成果まで含めて検討しやすい点も特徴です。現行業務を洗い出したうえで、MVPの範囲や将来追加する入力アダプター、データ連携の受け持ち範囲を先に決めておくと、コード量と保守負担の増加を抑えられます。

得意領域・実績

営業・顧客・生産・販売管理など、複数部門にまたがる基幹業務の構築・導入を検討している企業に向いています。また、既存業務をそのまま再現するだけでなく、どの判断をドメインに置き、どの接続をアダプターに閉じ込めるかを整理したい企業にも、相談先の候補になります。

相談時には「業務ルールをDBやフレームワークから分離する範囲」「テスト用アダプターを含む成果物」「段階導入した場合の切り戻し方法」「ソースコードとテストコードの権利」を確認してください。ヘキサゴナルの採用を前提にしすぎず、業務の複雑さと将来の変更計画から、適用範囲を提案してもらうことが大切です。

株式会社NTTデータ|公開された導入事例をもとに業務システムを設計

NTTデータの業務システム開発

株式会社NTTデータは、大規模な業務システムや金融・公共分野の基幹連携を重視する企業が候補にしやすいSI企業です。

NTTデータは、今回取り上げた他の5社と比べても、Fintanにヘキサゴナルアーキテクチャの導入事例が公開されており、設計の考え方を具体的に確認できる点が特徴です。

特徴と強み

Fintanの事例では、ビジネスロジックを含むアプリケーションサービス層とドメイン層が、特定技術を含むアダプターレイヤーへ依存しない形が説明されています。この事例では、Nablarchへの依存をアダプター側に閉じ込めたことで、RDBアクセスや画面などの変更影響を局所化しました。さらに、モック用アダプターを使ったテストやデモも行いやすくしています。

業務システムでどの依存を外側へ出すかを検討する材料として、この事例は役立ちます。大規模案件では、アーキテクチャそのものに加えて、品質管理や複数ベンダーの統制を、しっかり見る必要があります。セキュリティと長期運用の体制も、欠かせない確認事項になります。

自社案件の担当者が、Fintanの事例と同じ設計判断を説明できるかを確かめてください。設計書に加えて、テストコードやアダプターの責任範囲まで提示できるかも確認します。

得意領域・実績

金融、公共、複数拠点の基幹業務、既存APIやデータベースとの連携など、停止や移行のリスクを抑えながら刷新したい企業に向いています。既存システムの一部から段階的に切り出すなら、アンチコラプション層や並行稼働の設計も含めて相談すると、全面再構築以外の選択肢を比べやすくなります。

相談時には、公開事例のどの部分を自社案件へ適用できるのかを見てもらいます。「ヘキサゴナルを採用します」という答えに加えて、入力ポートと出力ポートの設計例を具体的に説明してもらうことが欠かせません。テストの分担や障害時のログ追跡、引き渡し可能な成果物も、同じように示してもらいます。

ポイント

判断の目安は、公開された導入事例の設計の考え方を、自社案件のどの部分へ当てはめられるかを具体的に説明できるかです。

富士通株式会社|既存業務システムの部分移行と高可用性への対応

富士通の業務システムモダナイゼーション

富士通株式会社は、既存の大規模業務システムを一度に置き換えるのではなく、特性に応じて部分ごとに移行したい企業に向く候補です。

富士通の公開資料では、業務システム全体ではなく部分を抽出し、それぞれの特性に合った形へ移行するアプローチが示されています。これは、レガシー刷新でヘキサゴナルな境界を段階的に設ける際の考え方と相性のよい方法です。

特徴と強み

既存システムの一部を抽出する場合、すべてのコードを新しい構成へ移す必要はありません。受注や在庫など変更が多い領域は新しいドメインとポートへ切り出し、安定した帳票やマスタは既存環境のまま使うなど、対象ごとに移行方式を変えられます。

また、富士通はクラウド上の業務システムの高可用性やモダナイゼーションに対応する製品・サービスを公開しており、基盤や運用まで含めて検討しやすい点も強みです。ただし、公開資料はモダナイゼーションの方向性を示すもので、ヘキサゴナルアーキテクチャの採用実績を案件ごとに保証するものではありません。

提案段階では、ドメインの境界と、アプリケーションとインフラのどこまでを誰が受け持つかを確かめてください。CI/CD、監視、切り戻しの設計も、同じ場で説明してもらいます。

得意領域・実績

公共、金融、製造など、既存の業務資産を活かしながらクラウド化・コンテナ化・段階移行を進めたい企業に適しています。24時間運用や災害対策が必要な場合は、アプリケーションの交換しやすさだけでなく、可用性や復旧時間の要件も検討に入れてください。マルチAZやバックアップ、監視の範囲も、要件に含めます。

相談時には、移行対象を機能単位で分ける基準と、旧システムとのデータ整合性をどう検証するかを聞きます。さらに、段階移行の各フェーズで、ポートとアダプターのテストを誰が作るか、障害時にどのチームが一次対応するかまで決めておくことが大切です。

日本電気株式会社(NEC)|マルチクラウドと業界要件を踏まえた刷新

NECのシステムモダナイゼーション

日本電気株式会社(NEC)は、公共・金融・建設など業界固有の要件が強いシステムや、複数クラウドを組み合わせた刷新を検討する企業の候補になります。

NECは既存ITシステムをクラウドなどの最新技術で作り変えるモダナイゼーションの導入事例を公開しており、ガバナンスやセキュリティを含めて刷新を考えたい場合に検討しやすい会社です。

特徴と強み

NECの公開技術情報には、Google Cloud、AWS、Azureなどを併用するマルチクラウドが紹介されています。既存システムは、Retire、Repurchase、Re-Architect、Replatform、Rehost、Retainの6Rを使って仕分けられています。

ヘキサゴナルアーキテクチャを採用する場合は、すべてを同じ構造へ統一するより、業務の重要度や変更頻度、移行リスクに応じてRe-Architectの対象を選ぶことが大切です。業界規制やセキュリティ基準のある案件では、認証・認可や監査ログを、設計の早い段階で決めておきます。

暗号化や個人情報の保管場所、運用権限も、同じ段階で扱うことになります。中心のドメイン層と外部接続を分けても、アダプターが過剰な権限を持つと、安全性は確保できません。技術構成と運用ルールを一体でレビューできる体制かどうか、確かめてください。

得意領域・実績

既存パッケージや複数クラウドを含む業務システムを、業界のガバナンス要件を守りながら刷新したい企業に向いています。特に、移行先を一つに決めきれない場合や、オンプレミスとクラウドをしばらく併用する場合は、データ連携と運用監視を先に整理しておくと計画を立てやすくなります。

相談時には、ヘキサゴナルアーキテクチャをどの機能に適用するか、既存パッケージとの間にどの変換アダプターを置くかを、図で示してもらいます。クラウド移行後の月額費用、データ転送費、監査ログの保管期間は、開発費とは別に見積もりの対象です。障害時にどこまでを誰が受け持つかも、同じ場で確かめておきましょう。

ポイント

判断の目安は、業界規制やセキュリティの要件を、技術構成と運用ルールを一体で示せるかです。移行先を決めきれない場合は、データ連携と運用監視の整理も併せて見るとよいです。

SCSK株式会社|クラウドネイティブなデータ連携と運用を支援

SCSKのクラウドネイティブ支援

SCSK株式会社は、既存システムに分散したデータやアプリケーションをつなぎ、クラウドネイティブな基盤と運用まで整えたい企業の候補です。

2025年6月に発表した「NebulaShift di」では、クラウドネイティブなデータ統合、リアルタイム性の高い連携、データ活用を支援するサービスを提供しています。

特徴と強み

NebulaShift diは、社内外に散在するデータを収集・加工・蓄積・活用するための基盤を、既存環境に合わせて組み合わせるオファリングです。公式FAQでは、オンプレミスからパブリッククラウドまでを対象にし、Kafkaなどのメッセージング基盤や複数のクラウドサービスを組み合わせられると説明されています。

入力アダプターや出力アダプターが増える業務では、接続仕様、再送、冪等性、データ品質を共通ルールにできます。なお、SCSKの発表が引用したIPA「DX動向2024」では、DXで成果が出ている企業のほうが、出ていない企業より全社的にデータを活用している割合が約14%高いとされています。

データ統合はヘキサゴナルアーキテクチャと同じ設計パターンではありませんが、業務アプリケーションと外部連携を分離し、変化に耐える接続基盤を考える際の補強材料になります。

得意領域・実績

ERP、在庫、顧客管理、分析基盤など複数のデータソースを連携し、オンプレミスとクラウドを併用したい企業に向いています。バッチ中心の連携をリアルタイム処理へ変えたい場合も、業務ルールはアプリケーション側に残し、データ収集や外部接続をアダプターとして管理する方針を相談できます。

ただし、データ統合基盤を導入しただけで、業務ロジックが疎結合になるわけではありません。相談時には、業務アプリケーションのポート設計と、データ基盤との連携をどこまで誰が受け持つかを分けて説明してもらってください。そのうえで、ログ取得、権限管理、障害時の再処理、クラウド利用料を含む運用設計まで確認しましょう。

TIS株式会社|AWS移行とAPI・基盤連携の段階的な進め方

TISのクラウド移行とシステム連携支援

TIS株式会社は、既存のオンプレミス環境をクラウドへ移しながら、業務アプリケーションのモダナイゼーションやAPI連携を進めたい企業の候補です。

TISは2025年10月、AWSとの戦略的協業契約を発表し、既存環境のアセスメントから移行、運用まで支援する取り組みを公開しています。また、公式発表ではAWS導入実績が500件以上と説明されており、移行方式を複数比べたい案件で確認しやすい材料です。

特徴と強み

TISは、IaaSへ移すだけでなく、コンテナ化やサーバーレス化など複数の移行シナリオを、システム特性に応じて選べることを公式に示しています。API連携やクラウド基盤、セキュリティ、マネージドサービスを組み合わせる場合は、外部サービスを出力アダプターに閉じ込め、中心の業務ロジックをクラウド製品の変更から守る設計を検討できます。

ただし、ヘキサゴナルアーキテクチャの採用実績を、公開情報だけでTISの全案件に当てはめることはできません。提案時には、APIや外部サービスのタイムアウトと再送、認証情報の管理、テスト用スタブ、IaCの引き渡しを、具体的な成果物として確認してください。その際、単なるマイクロサービス化と業務ロジックの分離を混同しないことが大切です。

得意領域・実績

VMware環境など既存基盤の移行、AWSを含むクラウド活用、外部APIやデータ連携を同時に進めたい企業に向いています。段階移行では、現行システムを一時的に残す方法や、機能単位で切り替える方法、クラウドネイティブへ作り替える方法を比べ、業務を止めない計画を組むことが重要です。

相談時には、AWSやコンテナを使う理由を業務要件と結び付けて説明してもらいます。また、見積もりを比べるときは、可用性やコストだけでなく、データ移行の検証、運用担当者への引き継ぎ、障害時の復旧目標、OSSの脆弱性管理まで含めて見てください。

ポイント

判断の目安は、移行方式を機能単位で比べ、業務を止めない計画と、APIや外部サービスの障害対応を具体的な成果物で示せるかです。

ヘキサゴナルアーキテクチャのシステムパートナー選びのポイント

システム開発会社を比較するポイント

6社を比べるときは、会社の規模や見積総額だけでなく、自社の業務をどの境界に置くかという条件をそろえて確認します。

特に、ヘキサゴナルアーキテクチャは、ポートやアダプターを作ること自体が目的ではありません。そのため、変更のしやすさをどう測るかまで提案に含めてもらうと、比べやすくなります。

実績と経験の確認方法

実績を確かめるなら、「ヘキサゴナルを使ったことがありますか」と聞くだけでは不十分で、中身を示してもらうことが大切です。匿名化された設計図やクラス構成、入力ポートと出力ポートの例を示してもらいます。さらに、ドメインの単体テスト、外部APIのスタブ、実DBを使う統合テストの分担も確かめてください。

公開事例がない場合は、契約前に小さな受注登録や在庫引当のPoCを実施し、DBなしでルールを検証できるかを確かめる方法もあります。

技術力と専門性の評価

技術選定は、ヘキサゴナルだからJava、クラウドだからコンテナといった決め方を避けます。Java/SpringやNablarchは既存の大規模業務チームの資産を活かしやすく、.NETはMicrosoft基盤との統合で候補になります。Kotlin・TypeScript・Goはサービス単位の開発、Pythonはデータ処理やAI連携の場面で候補になります。

重要なのは言語そのものより、中心のコードがフレームワーク、DB、クラウドSDKを直接参照しない依存方向になっているかです。見積書では、アーキテクチャ設計やポート・アダプターの実装、テストダブルを別項目にしてもらいます。CI/CD、監視、移行も同じように分けてもらうことが大切です。

SIA株式会社の2026年版の解説では、エンジニアの人月単価はスキルや地域により60万〜200万円以上になることがあり、簡易ツールから基幹システムまで費用の幅が大きいと説明されています。また、ヘキサゴナル採用の追加分だけを切り出せない案件もあるため、工数と成果物の関係を確認してください。

プロジェクト管理体制の確認

ヘキサゴナルアーキテクチャは、設計者だけが理解していても運用は回りません。業務担当者、プロダクト責任者、アプリケーション開発者、インフラ・セキュリティ担当者が、ポートの変更やアダプター障害の影響を共有できる体制かを確認します。提案書には、会議体や意思決定者、レビュー方法を明記してもらいます。

さらに、テスト環境やリリース判定、障害時の連絡先も書いてもらうと、体制の中身を確かめる材料になります。契約面では、ソースコード、IaC、テストコード、設計書の引き渡しを確かめます。加えて、依存ライブラリ一覧やOSSライセンス、著作権、脆弱性対応、SLAも確認します。

経済産業省が2025年に公表したSBOMの共有ビジョンに関する国際ガイダンスでも、ソフトウェア部品の透明性と、開発・調達・運用者間での脆弱性情報の共有が重視されています。外部アダプターを多く使う案件ほど、SBOMを納品物と保守手順に含めることが大切です。

ポイント

判断の目安は、会社の規模や見積総額だけでなく、業務の境界をそろえた条件で比べたうえで、実績をテストの分担まで示せるかです。

よくある質問

ヘキサゴナルアーキテクチャに関するよくある質問

ヘキサゴナルアーキテクチャのシステム会社を選ぶ際は、採用の可否だけでなく、費用、既存システムとの共存、技術選定、運用の受け持ち範囲を同時に確かめます。発注前によくある質問として、向いている業務、費用、マイクロサービスとの違い、既存システムの扱いの4点を取り上げます。

ヘキサゴナルアーキテクチャはどのようなシステムに向いていますか?

受発注、在庫、請求、権限、基幹連携など、業務ルールが複雑で変更頻度も高いシステムに向いています。Web画面、外部API、バッチなど複数の入口から同じ業務処理を呼び出す場合や、将来RDB・決済・外部サービスを交換する可能性がある場合にも、効果を発揮しやすいです。

外部連携が少ない単純なCRUDや短期利用の小規模ツールでは、抽象化の費用がメリットを上回る場合があります。

ヘキサゴナルアーキテクチャのシステム開発費用はいくらですか?

公的に統一された専用の相場はありません。目安として、アーキテクチャ診断・設計は50万〜150万円、小規模な新規業務システムは500万〜1,000万円です。中規模の部門横断システムは1,000万〜3,000万円、レガシー刷新は対象領域ごとに800万〜3,000万円程度です。

これらは、要件や体制、連携数によって変わる概算です。ポート、アダプター、テスト、移行を初期から設計する分、単純なCRUDより工数が増える可能性があります。そのため、見積もりの内訳を必ず確認してください。

ヘキサゴナルアーキテクチャとマイクロサービスは同じですか?

別の考え方です。ヘキサゴナルアーキテクチャは、中心の業務ロジックと外部技術の依存方向を整理する設計パターンで、マイクロサービスは、システムをどの単位で分割・デプロイするかという構成の考え方です。

ヘキサゴナルなモジュール化モノリスから始め、必要になった業務境界だけをサービスへ分けることもできます。

既存システムをすべて作り直す必要がありますか?

全体を一度に作り直さなくても、変更頻度が高い業務から進められます。既存システムの周囲にAPI、イベント、変換アダプターを置き、機能単位で新システムへ切り替える段階移行が現実的です。

並行稼働の間は、データ整合性や二重登録、切り戻し、監査ログを検証します。そのうえで、移行対象を増やす条件を先に決めておいてください。

まとめ

ヘキサゴナルアーキテクチャのシステム開発会社まとめ

ヘキサゴナルアーキテクチャのシステム開発会社を選ぶ際は、採用実績の有無だけでなく、業務ルールを中心に置く設計力や外部連携の実装力、段階移行、テスト・CI/CD・監視まで確認してください。

公開情報でヘキサゴナル導入事例を確認できるNTTデータと、モダナイゼーションやクラウド・データ連携に強みを持つ富士通、NEC、SCSK、TISは、要件に応じて比べたい候補です。業務成果まで一気通貫で支援するriplaも、比べたい候補の一つです。

同じRFPによる3社以上の比較

発注前には、利用者数や対象業務、外部連携数をそろえたRFPを、3社以上へ渡します。閉域・高可用性の要否、移行対象、許容停止時間も、同じ条件として記載します。

ポート設計やアダプターの交換デモ、単体テスト、契約テストを、同じ基準で評価します。障害時のログ追跡や、ソースコード・IaC・テストコードの引き渡しも評価項目に入れると、価格だけでは見えない差を比べられます。

採用範囲を小さく始めるときの効果測定

ヘキサゴナルアーキテクチャは、六角形の図を作れば完成するものではありません。業務ロジックがDBやフレームワークなしでテストできるか、外部APIの交換が局所変更で済むか、リリースのリードタイムや障害復旧時間を測定できるかを、成功条件にします。

まず変更頻度の高い受注・在庫などでPoCを行い、自社のチームが継続して設計とテストを運用できることを確かめてから、適用範囲を広げてください。

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

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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