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

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

まず、用語の簡単な区別から

「コンポーザブル」という言葉は、3つの全く異なる文脈で使われます。このガイドの残りの部分を理解するために、ここで整理しておきましょう。

• コンポーザブル・アーキテクチャ（本記事）は、ソフトウェア設計のアプローチです。個々のビジネスコンポーネントをAPI経由で統合し、アプリケーションを組み立てます。
• コンポーザブル・インフラストラクチャは、ハードウェアおよびデータセンターの概念です。コンピューティング、ストレージ、ネットワーキングがプールされ、オンデマンドでワークロードに割り当てられます。これはアプリケーションコードではなく、オペレーティングシステムの下で機能します。
• DeFiコンポーザビリティは、ブロックチェーンの概念であり、「マネーレゴ」と称されることもあります。レンディングやスワッププロトコルなどのスマートコントラクトが積み重なり、新しい金融商品を生成します。

同じ語源を持つ言葉ですが、3つの関連性のないレイヤーです。以降、「コンポーザブル」はソフトウェアアーキテクチャの意味で使用します。

コンポーザブル・アーキテクチャが実際に意味するもの

コンポーザブルシステムは、それぞれが完全なビジネス機能を担うモジュール式の自己完結型ユニットから構築されます。各タスクに最適なツールを選択し、APIを通じてそれらを接続し、後で周辺の全てを再構築することなく、いずれかのツールを入れ替えることができます。

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

PBCを箱に入ったビジネスドメイン全体と考えると良いでしょう。「決済」PBCは、決済方法、不正チェック、払い戻し、紛争を担います。「検索」PBCは、インデックス作成、ランキング、クエリ処理を担います。それぞれが生のデータベーステーブルではなく、ビジネスレベルのAPIを公開しており、ベンダーから調達することも、自社で構築することもできます。キットの部品を組み立てるように、これらのブロックから製品を構成するのです。

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

モノリスは、全ての機能を共有データベースを持つ1つのデプロイ可能なアプリケーションにまとめます。これは最初はシンプルですが、成長するにつれて変更が難しくなります。コンポーザブル・アーキテクチャはこれらの機能を分離し、それぞれが独立して進化できるようにします。モノリスとマイクロサービスの分割について読んだことがあるなら、コンポーザブルは同じ変化をビジネス能力の観点から捉えたものです。マイクロサービスは技術的な分解であり、PBCはビジネスドメインの分解です。

その対比を一覧で示します。

トレードオフは現実です。コンポーザブルは柔軟性と交換可能性をもたらしますが、統合、監視、契約維持のためのより多くの稼働部品も生み出します。

MACH: 多くの人が意味する標準

チームが「コンポーザブル」と言うとき、通常はMACH原則に従うスタックを意味します。MACHは頭字語であり、MACH Alliance（2020年設立）は、オープンでコンポーザブルなシステムのアーキテクチャとしてこれを推進しています。

• M, Microservices（マイクロサービス）。機能は単一のブロックではなく、小さく独立してデプロイ可能なサービスとして構築されます。
• A, API-first（APIファースト）。すべての機能はAPIを通じて公開されます。UIはAPIの単なる利用者の1つであり、唯一の入り口ではありません。
• C, Cloud-native（クラウドネイティブ）。コンポーネントは、弾力的なスケーリングとマネージドサービスを利用して、クラウド向けに構築されます。
• H, Headless（ヘッドレス）。フロントエンドはバックエンドから分離されており、同じAPIからウェブ、モバイル、キオスク、その他あらゆるものに配信できます。

コンポーザブル、ヘッドレス、MACHは同義語ではないことに注意してください。ヘッドレスはMACHの1つの要素です。MACHはコンポーザブルシステムを構築するための具体的で独断的な方法であり、コンポーザブルはその全てを包含する上位概念です。

APIファーストの基盤

これらのどの点に注目しても、同じ結論にたどり着きます。APIは、コンポーザブルシステムを統合する結合レイヤーであるということです。コンポーネントが独立しており、それぞれが自身のデータを所有している場合、それらを接続する唯一のものは、それらの間の契約です。

だからこそ、APIファースト開発は不可欠な柱なのです。モノリスでは、2つのモジュールが同じデータベースに直接アクセスし、互いの関数を呼び出すことができます。コンポーザブルシステムでは、そのショートカットはなくなります。機能は、それが公開するAPIと同じくらいしか有用ではなく、システムは、その部品間の契約と同じくらいしか安定しません。

これはまた、APIが「サイドドア」であることをやめ、製品そのものになる瞬間でもあります。フロントエンドがヘッドレスで、機能が交換可能になると、他のチームやパートナーが実際に利用するAPIこそが製品となります。いい加減に設計すれば、ダウンストリームのすべての利用者がその影響を感じるでしょう。

メリットとトレードオフ

コンポーザブルの利点を簡潔にまとめると以下の通りです。

• ベスト・オブ・ブリード。1つのベンダーの最も弱いモジュールで我慢するのではなく、各機能に最適なツールを使用できます。
• 独立した変更。他の部分に手を加えることなく、1つのPBCを交換またはアップグレードできます。
• ロックインの軽減。交換可能なコンポーネントにより、単一のプラットフォームに縛られることがなくなります。
• 並行チーム。デカップリングされた機能により、チームは独自のスケジュールでリリースできます。
• マルチチャネル。ヘッドレスのフロントエンドにより、1セットのAPIで多くのインターフェースに対応できます。

そして、率直なコストは以下の通りです。

• 統合のオーバーヘッド。コンポーネントが増えるほど、接続の配線と監視が増えます。
• 契約の厳守。1つのAPIにおける破壊的な変更は、それを呼び出すすべてのものに波及する可能性があります。
• 運用の複雑さ。監視、認証、バージョン管理が多くのサービスにまたがり、単一ではありません。
• 事前の設計。リリース前に境界と契約に多くの時間を費やします。

コンポーザブルは、柔軟性、拡張性、複数のチャネルが必要な場合に非常に適しています。うまく構築された単一のモノリスで十分な場合には、やりすぎとなります。

Apidogの役割：APIファーストという柱

Apidogはあなたのアーキテクチャをコンポーザブルにするものではありません。CMS、コマースエンジン、APIゲートウェイ、MACHプラットフォームでもなく、それらのいずれかを置き換えるものでもありません。Apidogが担うのは、MACHの「A」、すなわちAPIファーストという柱であり、コンポーザブルシステムにおける他のすべての要素が依存するレイヤーです。

APIが独立したコンポーネント間の唯一のインターフェースであるため、契約が正しくあることが重要です。Apidogは、その契約を設計、テスト、モック、ドキュメント化する場所です。

• デザインファーストの契約。実装を書き始める前に、各機能のAPIをOpenAPI契約として定義し、消費者と提供者が事前にその形態に合意できるようにします。
• モックサーバー。独立したチームは互いを待つ必要はありません。モックサーバーにより、バックエンドのPBCがまだ構築中であっても、フロントエンドやパートナーは契約に基づいて構築を進めることができます。
• ヘッドレスなテスト実行。Apidog CLIは、GUIなしでAPIテストをCIで直接実行します。これは「ヘッドレス」という概念と真に一致しており、テストは画面を通さず、契約に基づいて実行されます。
• ツールからの管理。MCPを通じて、AIエージェントやIDEからAPIプロジェクトを推進できます。

あなたのシステムがAPIを製品とするモデルに従う場合、Apidogは契約の整合性を保つ品質レイヤーとなります。バックエンドが存在する前に契約を設計し、モックするためにはApidogをダウンロードしてください。

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

以下の条件が複数当てはまる場合、コンポーザブルを検討してください。

• 共有ロジックから複数のチャネル（ウェブ、モバイル、店舗、音声）にサービスを提供する必要がある。
• 異なる機能が非常に異なる速度で変更され、小さな修正のためにすべてを再デプロイするのにうんざりしている。
• 1つのスイートではなく、機能ごとに最適なベンダーを望む。
• ベンダーロックインがあなたのビジネスにとって真のリスクである。
• API契約と統合を長期的に管理するためのチームと規律がある。

もしあなたが小規模なチームで、限られた期間内に単一の製品をリリースする場合、クリーンなモノリスの方が賢明な選択となることが多いでしょう。コンポーザブルはその複雑性を大規模な環境で発揮します。

よくある質問

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

いいえ、同じではありませんが、重複する部分があります。マイクロサービスは、システムを小さなデプロイ可能なサービスに分解する技術的な方法です。コンポーザブル・アーキテクチャは、ビジネス機能（PBC）に沿って分解し、APIで接続されたベスト・オブ・ブリードの交換可能なコンポーネントという概念を追加します。マイクロサービスは通常、コンポーザブルシステムのバックエンドを構築する方法です。より広範な分割については、モノリスとマイクロサービスを参照してください。

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

ヘッドレスとは、フロントエンドがバックエンドから分離されており、どのクライアントでも同じAPIを利用できることを意味します。コンポーザブルは、独立したAPI接続された機能からシステム全体を組み立てる、より広範なアプローチです。ヘッドレスは、コンポーザブルシステムが従う傾向のある原則の1つ（MACHの「H」）です。スタック全体で完全にコンポーザブルでなくても、1つの機能でヘッドレスにすることは可能です。

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

PBCは、データ、ロジック、APIを含む完全なビジネス機能を所有する自己完結型ユニットです。ガートナーはPBCを、APIやイベントチャネルを通じて他のアプリケーションと連携する、独立してデプロイ可能な機能と定義しています。「検索」、「決済」、「在庫」などのコンポーネントがビジネスレベルのAPIを公開しているものが典型的なPBCです。

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

独立したコンポーネントを結合する唯一のものがAPI契約であるため、API契約を設計、テストし、安定性を保つ方法が必要です。これは個別のツールのセットでも、設計、モック、テスト、ドキュメントを1箇所でカバーする単一のプラットフォームでも構いません。重要なのは契約の厳守であり、特定の製品ではありません。

まとめ

コンポーザブル・アーキテクチャは上位概念であり、ヘッドレス、MACH、マイクロサービスはその中に含まれる種です。共通する点はシンプルです。それは、独立した機能、ベスト・オブ・ブリードの選択、そして結合組織としてのAPIです。最後の部分にほとんどのリスクが存在します。なぜなら、契約がシステムそのものだからです。Apidogのようなツールを使ってAPIの設計、モック、テスト、ドキュメントを正しく行えば、コンポーザブルが持つ残りの約束（交換可能、マルチチャネル、ロックインフリー）は確固たる基盤を持つことになります。