ヘキサゴナルアーキテクチャとは？ポート＆アダプター設計を最新動向と実践から理解する

2025年5月27日2026年8月31日

ヘキサゴナルアーキテクチャ（ポート＆アダプター）の本質を、DDD、マイクロサービス、クラウドネイティブ、AIエージェント開発など2026年のソフトウェア開発事情とともに解説。メリット・デメリットから実践時の設計ポイントまで、現場で役立つ知識を整理します。

はじめに：なぜ今、ヘキサゴナルアーキテクチャなのか？

ソフトウェア開発では、クラウド、マイクロサービス、API、イベント駆動、AIなど、多様な技術を組み合わせることが当たり前になりました。一方で、技術が増えるほど「データベースを変更したら業務ロジックまで修正が必要」「外部APIの仕様変更がアプリケーション全体に波及する」といった問題も起こりやすくなります。

そこで重要になるのが、ビジネス上の判断と、技術的な実装を分離する考え方です。

ヘキサゴナルアーキテクチャ（Hexagonal Architecture）は、Alistair Cockburn氏が提唱した「ポート＆アダプター（Ports and Adapters）」という設計パターンです。2005年に公開された原論文では、UIやデータベースがなくてもアプリケーションを動作・テストできる構造を目指すことが示されています。(alistair.cockburn.us)

現在ではDDDやクリーンアーキテクチャ、マイクロサービスなどと組み合わせながら、長期的に変更しやすいシステムを設計するための重要な考え方として利用されています。

1. ヘキサゴナルアーキテクチャの「本当の意味」を紐解く

1-1. 「六角形」より重要なのは依存関係

ヘキサゴナルアーキテクチャでは、中央にアプリケーションやドメインのコアを置き、その周囲にポートとアダプターを配置します。

ただし、重要なのは「六角形」であることではありません。Cockburn氏自身も、六角形は接続点を図の上で表現しやすくするための視覚的な表現であり、「6」という数字自体に特別な意味はないと説明しています。

本質は、アプリケーションの内側が、外側の技術に依存しないようにすることです。

たとえばECサイトなら、「商品を注文する」「在庫を確認する」「決済する」といったビジネス上のルールは、MySQLを使うかPostgreSQLを使うか、REST APIを使うかメッセージングを使うかとは本来別の問題です。

そこで、業務ロジックと技術実装の間に「ポート」を設けます。

1-2. ポートとアダプターとは？

ポートは、アプリケーションが外部とやり取りするための目的志向のインターフェースです。一方、アダプターは、そのポートを特定の技術で実装する役割を担います。AWSの公式ガイダンスでも、ポートを技術非依存の接続点、アダプターをREST APIやデータベースなど具体的な技術との橋渡しとして説明しています。

たとえば「注文を保存する」というポートに対して、PostgreSQL用アダプター、DynamoDB用アダプター、テスト用のインメモリアダプターを用意できます。

この構造なら、データベースを変更しても、注文処理そのものを大きく書き換える必要がありません。

2. 現代の開発で注目される理由

2-1. テストしやすい

ヘキサゴナルアーキテクチャの大きなメリットは、外部環境から業務ロジックを切り離せることです。

データベースや外部APIを直接呼び出すコードとビジネスルールが混在していると、テストのたびにデータベースや外部サービスを用意しなければならない場合があります。

一方、ポートを介して依存関係を分離しておけば、テスト時にはモックやスタブ、インメモリー実装などに差し替えられます。AWSも、インフラストラクチャへの依存を減らすことでコンポーネント単位のテストが容易になる点をヘキサゴナルアーキテクチャの利点として挙げています。

2-2. DDDやマイクロサービスと相性が良い

ヘキサゴナルアーキテクチャは、DDDの「ドメインを中心に設計する」という考え方とも親和性があります。

特にマイクロサービスでは、サービスごとに異なるデータベース、API、メッセージブローカー、クラウドサービスを利用するケースがあります。その際、各サービスのドメインロジックとインフラを分離しておくと、技術選択の変更による影響を局所化できます。

AWSのガイダンスでも、ヘキサゴナルアーキテクチャのコアをDDDのBounded Contextとして扱うアプローチが紹介されています。(AWS ドキュメント)

3. 実際に設計するときの考え方

ヘキサゴナルアーキテクチャを導入するとき、最初から大量のインターフェースを作ることが重要なのではありません。

まず、「このシステムにとって変更されにくいものは何か」を考えることが重要です。

たとえば注文管理システムなら、「注文金額を計算する」「注文可能か判断する」「割引条件を適用する」といった業務ルールを中心に据えます。

次に、そのロジックが必要とする外部との接点をポートとして定義します。

外部から処理を開始する側には、HTTP API、CLI、バッチ、メッセージイベントなどのアダプターがあります。内部から外部サービスを利用する側には、データベース、決済API、メールサービス、オブジェクトストレージなどのアダプターがあります。

つまり、「何をするか」を内側に、「どうやって実現するか」を外側に置くことが基本です。

4.クリーンアーキテクチャとの違い

ヘキサゴナルアーキテクチャとクリーンアーキテクチャは別物ですが、目指している方向には大きな共通点があります。

ヘキサゴナルアーキテクチャは、ポートとアダプターによって外部との境界を明確にすることに重点を置きます。

一方、クリーンアーキテクチャは、同心円状の構造などを使いながら、依存関係が内側へ向かうというルールをより明確に表現します。

どちらを採用するかは「どちらが優れているか」ではなく、プロジェクトに必要な設計上の制約をどこまで明示したいかで判断するとよいでしょう。

実際には、DDD、依存性逆転、クリーンアーキテクチャ、ヘキサゴナルアーキテクチャを組み合わせて利用するケースも珍しくありません。

5. クラウドネイティブ・イベント駆動との組み合わせ

ヘキサゴナルアーキテクチャは、特定のクラウドサービスに依存する設計ではありません。そのため、AWS、Azure、Google Cloudなどのクラウド環境にも適用できます。

AWSの実践例では、API GatewayやEventBridge、SQSなどを外部との接点として利用し、Lambda、ECS、EKSなどをアプリケーションの実行環境として組み合わせる構成が紹介されています。また、DynamoDBからRDSへ変更する場合でも、アダプターを差し替えることでドメインへの影響を抑えられる例が示されています。(AWS ドキュメント)

イベント駆動システムでも同様です。注文完了イベントを受信するアダプターと、業務ルールそのものを分離しておけば、メッセージブローカーを変更した場合でもコアロジックへの影響を限定できます。

重要なのは、「クラウドサービスを抽象化すること」自体を目的にしないことです。変更される可能性が高く、ビジネスロジックから分離する価値がある部分にだけ境界を設けることが大切です。

6. AI時代における新しい価値

2026年現在、ソフトウェア設計を考えるうえで無視できないのが生成AIやAIコーディングエージェントです。

AIはコード生成だけでなく、フレームワーク選択、インフラ構築、サービス間連携など、従来は人間の設計者が担っていた判断にも関与するようになっています。2026年のソフトウェアアーキテクチャ研究では、AIコーディングエージェントがプロンプトに応じて異なる構造を生み出すことから、AIによって暗黙的にアーキテクチャが決定されるリスクも指摘されています。(Syddansk Universitet)

この環境では、ポートによって「このドメインが外部に何を要求するのか」を明確にしておくことが、これまで以上に重要になります。

AIに実装を任せる場合でも、ポートやドメイン境界が明確なら、生成されたコードがどこに属するのか、どの依存関係が許されるのかをレビューしやすくなります。

つまり、AI時代のヘキサゴナルアーキテクチャは、単なる保守性向上の技法ではなく、AIが高速に生成するコードを安全に組み込むための設計上のガードレールとしても価値を持ちます。