コンポーザブルMESは何を分解したのか──6社の製品戦略を比較する

「コンポーザブル」は3つの別々のものを指している

2026年のベンダー発表を並べると、同じ「コンポーザブル」という語が、少なくとも3つの異なる分解を指していることが分かります。

1. アプリケーション層の分解：業務単位の小さなアプリを組み合わせて現場業務を組み立てる。UIとロジックが分解の対象
2. データ層の分離：MESが持っていたデータを、MESの外側の共通基盤へ発行する。データの所有権が分解の対象
3. デプロイ単位の分解：モジュールごとに購入・展開・更新できるようにする。ライセンスとリリースサイクルが分解の対象

この3つは技術的にも商業的にも別物です。1だけを実現している製品を「コンポーザブルだからデータ連携も柔軟なはず」と読むと、要件定義の後半で破綻します。

6社が実際に分解しているもの

各社の直近の公式発表から、どの軸で分解しているかを整理します。

なお、この6社のうちTulipには2026年1月に三菱電機がリード投資家として資本参加しています。日本のFA大手がアプリ層分解の筆頭企業に賭けた意味は、三菱電機はなぜTulipにリード投資したのかで別途扱います。

この表で読み取るべきは優劣ではありません。「コンポーザブル」を名乗る2社の製品でも、実際に分解されている場所が違えば、導入プロジェクトの工数配分がまるで変わるという点です。①だけを分解した製品はアプリ開発の内製比率が上がり、③だけを分解した製品は年次の契約交渉負荷が上がります。

分解された責任は、買い手に移る

コンポーザブル化には、あまり語られない代償があります。モノリシックなMESでベンダーが引き受けていた「全体が整合していることの保証」が、分解に比例して買い手側へ移ることです。

• アプリ層を分解すると、アプリ間のデータ整合とバージョン管理を誰かが持たなければならない
• データ層を分離すると、MESの中の実績と共通基盤上の実績が乖離したときの正本がどちらかを決める必要が出る
• デプロイ単位を分解すると、モジュールAだけ更新してモジュールBを据え置いたときの互換性検証が発生する

RFPで分解の位置を特定する5つの質問

「御社の製品はコンポーザブルですか」と聞いても意味のある答えは返ってきません。分解の位置を特定する質問に置き換えます。

1. アプリの作成主体：標準機能で足りない業務は、誰がどのツールで作りますか。作ったものはバージョン管理・差分比較できますか
2. データの正本：工程実績の正本はMESの中ですか、外側のデータ基盤ですか。両方に存在する場合、不整合の検出手段は何ですか
3. モジュール間の互換性保証：モジュールごとに更新できるとして、組み合わせのどこまでがベンダーの動作保証範囲ですか
4. ライセンスの分解単位：モジュール単位・ユーザー単位・リソース単位のどれですか。単位が変わるときの遡及適用条件は何ですか
5. 取り出しの経路：契約終了時、内製したアプリの定義と蓄積データを、どの形式で取り出せますか

よくある質問

コンポーザブルMESは、ローコード／ノーコードMESと同じものですか？

重なりますが同じではありません。ローコード／ノーコードは「作り方」の話で、コンポーザブルは「分解の単位」の話です。ノーコードでアプリを作れてもデータ層が閉じていればデータ面ではコンポーザブルではありませんし、逆にモジュール単位で買えてもアプリの改変にコードが必要な製品もあります。詳細はローコード／ノーコードMESの実力と限界で整理しています。

モノリシックなMESはもう選ぶべきではないのですか？

そうは言えません。工程が安定していて変更頻度が低く、規制対応で変更管理の厳格さが最優先される現場では、全体整合をベンダーが保証するモノリシックな構成のほうが総コストは低くなります。コンポーザブル化が効くのは、製品ライフサイクルが短い、拠点ごとに工程が違う、改善サイクルを自社で回したいという条件がそろう場合です。

「コンポーザブル」と「マイクロサービス」はどう違いますか？

マイクロサービスは実装アーキテクチャの用語で、サービス単位で独立してデプロイできることを指します。コンポーザブルはそれより上位の、業務機能を組み替えられるという業務側の概念です。内部がマイクロサービスでも、購入単位が一括ライセンスなら、買い手から見た体験はモノリシックのままです。内部実装ではなく、購入単位・変更単位・データ単位で判断してください。