DEV Community

Cover image for コンポーザブルアーキテクチャとは？ MACHとAPIファーストのガイド
Akira
Akira

Posted on • Originally published at apidog.com

コンポーザブルアーキテクチャとは？ MACHとAPIファーストのガイド

コンポーザブル・アーキテクチャとは、1つの大きなオールインワン・プラットフォームではなく、独立して交換可能なコンポーネントをAPIで接続してソフトウェアシステムを構築する手法です。これは、ヘッドレス化の流れを含むより広い概念であり、オープンでコンポーザブルなエンタープライズ技術を推進するベンダーニュートラルな業界団体であるMACH Allianceとも密接に関連しています。

今すぐApidogを試す

まず、用語を切り分ける

「コンポーザブル」は複数の文脈で使われます。実装方針を議論する前に、意味を分けておきます。

  • コンポーザブル・アーキテクチャ

    本記事の対象です。ビジネス機能ごとのコンポーネントをAPIで統合し、アプリケーションを組み立てます。

  • コンポーザブル・インフラストラクチャ

    ハードウェアやデータセンターの概念です。コンピューティング、ストレージ、ネットワークをプールし、ワークロードに応じて割り当てます。

  • DeFiコンポーザビリティ

    ブロックチェーンの概念です。スマートコントラクトを組み合わせて新しい金融機能を作ります。

以降の「コンポーザブル」は、ソフトウェアアーキテクチャの意味で扱います。

コンポーザブル・アーキテクチャで実装するもの

コンポーザブルシステムは、自己完結したモジュールから構成します。各モジュールは特定のビジネス機能を担当し、APIまたはイベントを通じて他のモジュールと連携します。

この構成単位は パッケージ型ビジネスケイパビリティ（PBC） と呼ばれます。ガートナーはPBCを、自己完結したビジネスデータ、ロジック、プロセスを含み、APIやイベントチャネルで他のアプリケーションと連携する、独立してデプロイ可能な能力と定義しています。

たとえば、ECシステムなら次のように分割できます。

PBC 担当する機能 公開するAPI例
決済 支払い、返金、不正チェック POST /payments, POST /refunds
検索 インデックス、ランキング、クエリ処理 GET /search
在庫 在庫数、引当、入出庫 GET /inventory/{sku}
注文 注文作成、注文状態、キャンセル POST /orders, GET /orders/{id}

重要なのは、PBCがデータベーステーブルを直接共有するのではなく、ビジネスレベルのAPIを公開することです。これにより、後から検索エンジンや決済プロバイダーを交換しても、呼び出し側への影響をAPI契約の範囲に抑えられます。

コンポーザブル vs. モノリス

モノリスは、すべての機能を1つのデプロイ可能なアプリケーションにまとめ、共有データベースを使うことが一般的です。初期開発はシンプルですが、機能が増えるほど変更範囲が広がります。

コンポーザブル・アーキテクチャでは、機能をPBC単位に分離し、それぞれを独立して変更・交換できるようにします。モノリスとマイクロサービスの違いを知っているなら、コンポーザブルはその考え方をビジネス能力の単位に寄せたものと捉えられます。

項目 モノリス コンポーザブル・アーキテクチャ
変更単位 アプリケーション全体 単一のPBC
データ 共有データベース 各機能が自身のデータを所有
ベンダー選択 1つのプラットフォームに依存 機能ごとにベスト・オブ・ブリード
フロントエンド バックエンドと密結合 バックエンドから分離
統合 内部関数呼び出し APIとイベント
ロックインリスク 高い 低い。ただし契約設計が必要

ただし、コンポーザブルは万能ではありません。柔軟性が増える一方で、統合、監視、認証、APIバージョン管理の負荷も増えます。

MACHを実装方針として使う

チームが「コンポーザブル」と言うとき、多くの場合はMACH原則に沿ったスタックを指します。MACHは、MACH Alliance（2020年設立）が推進するアーキテクチャ方針です。

  • M: Microservices（マイクロサービス）

    機能を小さく独立してデプロイ可能なサービスとして構築します。

  • A: API-first（APIファースト）

    すべての機能をAPI経由で利用可能にします。UIはAPI利用者の1つにすぎません。

  • C: Cloud-native（クラウドネイティブ）

    クラウド環境でのスケーリング、マネージドサービス、継続的デプロイを前提にします。

  • H: Headless（ヘッドレス）

    フロントエンドをバックエンドから分離し、同じAPIからWeb、モバイル、店舗端末などへ配信します。

ヘッドレス、MACH、コンポーザブルは同義語ではありません。ヘッドレスはMACHの1要素であり、MACHはコンポーザブルシステムを構築するための具体的な方針です。

APIファーストを実装の起点にする

コンポーザブルでは、コンポーネント同士をつなぐ主な手段がAPIです。そのため、APIは後付けではなく、実装前に設計する必要があります。

APIファースト開発では、先にAPI契約を定義し、その契約に基づいてフロントエンド、バックエンド、テスト、ドキュメントを進めます。

実装の流れは次のようになります。

  1. PBCの境界を決める
  2. 各PBCが所有するデータと責務を決める
  3. 外部に公開するAPIをOpenAPIなどで定義する
  4. モックAPIを用意して利用側の開発を先行させる
  5. 契約テストをCIで実行する
  6. 破壊的変更が必要な場合はバージョンを分ける

例として、注文PBCのAPI契約は次のように定義できます。

openapi: 3.0.3
info:
  title: Order API
  version: 1.0.0

paths:
  /orders:
    post:
      summary: 注文を作成する
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required:
                - customerId
                - items
              properties:
                customerId:
                  type: string
                items:
                  type: array
                  items:
                    type: object
                    required:
                      - sku
                      - quantity
                    properties:
                      sku:
                        type: string
                      quantity:
                        type: integer
      responses:
        "201":
          description: 注文作成成功
          content:
            application/json:
              schema:
                type: object
                properties:
                  orderId:
                    type: string
                  status:
                    type: string
Enter fullscreen mode Exit fullscreen mode

この契約があれば、バックエンドが未完成でもフロントエンドはモックに対して開発を進められます。

また、ヘッドレス構成ではAPIが単なる内部インターフェースではなく、他チームやパートナーが利用する製品になります。つまり、APIこそが製品になります。設計が曖昧だと、すべての利用者に影響が出ます。

メリットとトレードオフ

コンポーザブルの主なメリットは次の通りです。

  • ベスト・オブ・ブリードを選べる

    決済、検索、CMSなど、機能ごとに最適なサービスを選択できます。

  • 独立して変更できる

    1つのPBCを更新しても、他の機能への影響をAPI契約の範囲に抑えられます。

  • ロックインを減らせる

    コンポーネントを交換可能にすることで、単一プラットフォーム依存を避けやすくなります。

  • チームが並行して開発できる

    PBC単位で責務を分けることで、チームごとのリリース速度を保ちやすくなります。

  • マルチチャネルに対応しやすい

    同じAPIをWeb、モバイル、店舗端末など複数のUIから利用できます。

一方で、次のコストもあります。

  • 統合のオーバーヘッド

    コンポーネントが増えるほど、接続、認証、監視が増えます。

  • API契約の管理が必須

    1つの破壊的変更が、呼び出し元すべてに影響する可能性があります。

  • 運用が複雑になる

    ログ、メトリクス、トレーシング、アラートを複数サービスにまたがって整備する必要があります。

  • 事前設計が重くなる

    境界、責務、API契約を曖昧にしたまま始めると、後で結合が崩れます。

コンポーザブルは、柔軟性、拡張性、マルチチャネル対応が必要なシステムに向いています。小規模な単一プロダクトなら、クリーンなモノリスの方が適切な場合もあります。

Apidogの役割：APIファーストを運用する

Apidogは、システムを自動的にコンポーザブルにするツールではありません。CMS、コマースエンジン、APIゲートウェイ、MACHプラットフォームの代替でもありません。

Apidogが担うのは、MACHの「A」である API-first の部分です。コンポーザブルシステムでは、API契約がコンポーネント間の接点になります。Apidogは、その契約を設計、テスト、モック、ドキュメント化するための場所です。

実装時には次のように使えます。

  • デザインファーストでAPI契約を定義する

    実装前にOpenAPIベースでエンドポイント、リクエスト、レスポンスを決めます。

  • モックサーバーで並行開発する

    バックエンドPBCが未完成でも、フロントエンドや外部連携側は契約に基づいて開発できます。

  • CIでAPIテストを実行する

    Apidog CLIを使えば、GUIなしでAPIテストをCIに組み込めます。

  • AIエージェントやIDEから管理する

    MCPを通じて、APIプロジェクトを開発環境やAIエージェントから扱えます。

APIを製品とするモデルでは、契約の品質がシステム全体の品質になります。バックエンド実装前に契約を設計し、モックして検証したい場合は、Apidogをダウンロードしてください。

コンポーザブル・アーキテクチャを採用すべき時

次の条件が複数当てはまるなら、コンポーザブルを検討できます。

  • Web、モバイル、店舗、音声など複数チャネルに同じロジックを提供したい
  • 機能ごとに変更速度が大きく異なる
  • 小さな変更のたびにアプリケーション全体を再デプロイしたくない
  • 1つの統合スイートではなく、機能ごとに最適なベンダーを使いたい
  • ベンダーロックインがビジネス上のリスクになっている
  • API契約、テスト、監視を継続的に管理できる体制がある

逆に、小規模チームで単一プロダクトを短期間でリリースするなら、まずは境界が明確なモノリスから始める方が現実的です。コンポーザブルは、複雑性を受け入れる代わりに拡張性と交換可能性を得る設計です。

実装前チェックリスト

コンポーザブル化を始める前に、最低限次を確認します。

  • [ ] PBCごとの責務が明確になっている
  • [ ] 各PBCが所有するデータが決まっている
  • [ ] 他PBCのデータベースを直接参照しない方針になっている
  • [ ] API契約をOpenAPIなどで管理している
  • [ ] モックAPIで利用側の開発を進められる
  • [ ] 破壊的変更に対するバージョニング方針がある
  • [ ] 認証・認可の方式が統一されている
  • [ ] ログ、メトリクス、トレーシングを横断的に追える
  • [ ] CIでAPIテストを実行できる
  • [ ] ドキュメントが実装と乖離しない運用になっている

よくある質問

コンポーザブル・アーキテクチャはマイクロサービスと同じですか？

同じではありませんが、重複します。マイクロサービスは、システムを小さなデプロイ可能サービスに分解する技術的な方法です。コンポーザブル・アーキテクチャは、ビジネス機能（PBC）に沿って分解し、APIで接続された交換可能なコンポーネントとして扱います。より広い比較は、モノリスとマイクロサービスを参照してください。

コンポーザブルとヘッドレスの違いは何ですか？

ヘッドレスは、フロントエンドがバックエンドから分離され、任意のクライアントが同じAPIを利用できる状態を指します。コンポーザブルは、独立したAPI接続済みの機能からシステム全体を組み立てる、より広いアプローチです。ヘッドレスは、コンポーザブルシステムでよく使われる原則の1つです。

パッケージ型ビジネスケイパビリティ（PBC）とは何ですか？

PBCは、データ、ロジック、APIを含む完全なビジネス機能を所有する自己完結型ユニットです。検索、決済、在庫、注文などが典型例です。PBCは内部データベースではなく、ビジネスレベルのAPIやイベントチャネルを通じて他の機能と連携します。

コンポーザブルにするためにAPIプラットフォームは必要ですか？

必要なのは、API契約を設計、テスト、モック、ドキュメント化し、安定して運用する仕組みです。複数ツールを組み合わせても、単一プラットフォームを使っても構いません。重要なのは、契約を破らないこと、変更を追跡できること、利用者が正しい仕様を参照できることです。

まとめ

コンポーザブル・アーキテクチャは、独立したビジネス機能をAPIで接続し、交換可能なシステムとして構築するアプローチです。ヘッドレス、MACH、マイクロサービスは、その中で使われる具体的な原則や実装手段です。

成功の鍵はAPI契約です。契約が曖昧だと、コンポーネントを分けても結合は壊れます。ApidogのようなツールでAPIの設計、モック、テスト、ドキュメントを整備すれば、交換可能性、マルチチャネル対応、ロックイン回避といったコンポーザブルの利点を実装しやすくなります。

Top comments (0)