【ITニュース解説】Part 16: Same tool, two platforms: MuleSoft vs Boomi side by side

この記事は、システム間の連携を担う統合プラットフォームであるMuleSoftとBoomiを比較し、特定の「入庫情報取得（get_goods_receipt）」ツールを両プラットフォーム上で実装する際の相違点を詳細に分析している。システムエンジニアにとって、異なるプラットフォームが提供する開発手法や機能の違いを理解することは、適切な技術選択と効率的な開発を進める上で不可欠である。この比較は、エージェントと呼ばれる連携システムがツールを利用するシナリオを想定し、その具体的な実装方法について多角的な視点から検討している。

まず、ツールの定義方法に関して、MuleSoftでは「Tool Listener」という機能を用いて、ツールの名前、詳細な説明、必須の入力データ構造（Parameters Schema）、および任意の出力データ構造（Output Schema）を明示的に宣言する。これにより、ツールの機能が独立した成果物として明確に定義される。対照的に、Boomiでは「API Control Plane」におけるAPI定義から、ツールが自動的に生成される。つまり、「get_goods_receipt」のようなAPIエンドポイントが、そのままツールとして認識される仕組みだ。この違いは実務上重要で、MuleSoftでは開発者がツールの詳細を自由に記述できる一方、BoomiではAPIのOpenAPI仕様がツールの品質、特にツールの説明の適切さに直結するため、設計段階での慎重な考慮が必要となる。

次に、ツールが扱うデータ構造（スキーマ）の管理方法にも違いがある。MuleSoftでは、入力スキーマはMuleアプリケーション内にJSON形式で直接記述され、出力スキーマはインラインで記述するか、外部ファイルをMuleアプリケーションの隣に配置して参照する。これらはMuleアプリケーションのコンテキスト内で管理される。一方、Boomiでは、APIのOpenAPI定義にスキーマが記述され、これはAPI Control Planeで管理される。複数のプラットフォーム間で同じ契約書に準拠したデータ形式を維持するためには、常に信頼できる情報源（シングルソースオブトゥルース）を一つ持つことが肝要だ。この記事では、契約書で定義されたデータ形式を、MuleSoftではTool Listenerに、BoomiではOpenAPI仕様にそれぞれコピーして使用し、公開されたツールのスキーマと契約書を比較することで整合性を確認している。

エラー処理のメカニズムも重要な比較点だ。今回のツールでは、入庫がない場合に「GR_MISSING」という特定のエラーを返す必要がある。MuleSoftのTool Listenerには「On Error Responses」という機能があり、フローがエラーで終了した際に返すべきJSON形式のエラーボディを定義できる。これを定義しない場合、一般的なテキスト形式のエラーが生成され、特定のエラー情報が失われる可能性がある。Boomiでは、APIがエラー発生時にJSONボディを含むレスポンスを返す。しかし、この記事の時点では、どちらのプラットフォームも、エラーがエージェントに対して「isError: true」のようなフラグとともに明確に「ビジネスエラー」として伝達されるかどうかは未確認であると指摘されている。エージェントがエラーの種類を正確に判断し、適切な対応（この場合は再試行不可で保留）を取るためには、このエラー通知の明瞭さが非常に重要となる。

誰がツールを呼び出せるか、というアクセス制御の側面も比較されている。MuleSoftの「Omni Gateway」には「MCP Global Access」ポリシーがあり、ツールリスト全体をフィルタリングしたり、「MCP Attribute-Based Access Control」ポリシーでクライアントの属性や情報に基づいて、利用可能なツールを個別に割り当てたりすることが可能だ。これは、きめ細やかなアクセス制御をポリシーとして提供する。一方、Boomiでは、各サブスクリプションに専用のエージェントキーが与えられ、「API Product」がどのツールが存在するかを決定する。Boomiの「MCP Gateway」もアクセス制御機能を持つとされているが、そのルール構文は現時点では文書化されていない。したがって、MuleSoftではクライアントごとのツールフィルタリングがポリシーとして明示的に提供されているのに対し、BoomiではAPI Productの設計や未確認のMCP Gatewayポリシーに依存する可能性が指摘されている。

最後に、実装されたツールが正しく機能するかを確認するテスト方法にも違いがある。MuleSoftでは「MUnit」というテストフレームワークを使用し、フローのテスト、モック（仮想的な応答）の利用、呼び出しの検証、コードカバレッジの測定などを行う。これにより、例えば入庫がない場合の応答をモックして、「GR_MISSING」エラーボディが正確に返されることを確認できる。Boomiには「Test mode」があり、デプロイせずにプロセスを実行し、ステップごとのログを確認できる。しかし、このモードは実際にデータに触れるため、実データへの影響を考慮する必要がある点や、APIによってトリガーされるリスナープロセスのテスト方法にはさらなる確認が必要とされている。最終的な確認として、両プラットフォームに共通して、プラットフォームに依存しない形で、公開されているツールリストやツールの呼び出し結果を契約書の内容と照合するテストが有効であると述べられている。

総じて、MuleSoftとBoomiのアプローチは一長一短であり、どちらか一方が常に優れているとは言えない。MuleSoftでは、ツール定義を明示的に記述するため、記述量は増えるものの、すべての設定を開発者が詳細に制御できる。一方、BoomiではAPI定義からツールが自動生成されるため記述量は減るが、その品質はAPIのOpenAPI仕様の記述精度に大きく依存する。この記事で特に重要な相違点として挙げられているのは、エラー情報が「名前付きエラー」として明確にエージェントに伝わるか、そして「isError: true」のようなフラグが付与されるかという点だ。これはエージェントがエラーを認識し、適切なアクションを取る上で不可欠な情報だが、現時点では両プラットフォームで未確認の課題である。もう一つは、エージェントごとにツールへのアクセス権を細かく制御できるかという点で、MuleSoftではポリシーとして明確に文書化されているのに対し、Boomiでは設計上の考慮事項としてさらなる確認が必要とされている。システム開発を行う上で、これらのプラットフォーム固有の特性を理解し、プロジェクトの要件や開発チームの慣習に合わせて適切なプラットフォームを選択することが重要だ。