LabHub

ブログ

EAI（Enterprise Application Integration）完全ガイド：企業システム統合のすべて

2026-03-23 · 37 分で読めます · #eai#enterprise-integration#middleware#esb#api-gateway#mulesoft#kafka#microservices#soa#integration-patterns#2026-03

한국어English日本語

はじめに

ほとんどの企業（きぎょう）は、一（ひと）つのシステムだけで全（すべ）ての業務（ぎょうむ）を処理（しょり）しているわけではありません。ERP、CRM、WMS、HR、会計（かいけい）システムなど、数十（すうじゅう）から数百（すうひゃく）のアプリケーションが同時（どうじ）に運用（うんよう）されています。問題（もんだい）は、これらのシステムが異（こと）なるベンダー、異なる技術（ぎじゅつ）スタック、異なるデータフォーマットを使用（しよう）していることです。EAI（Enterprise Application Integration）は、このような異質（いしつ）なシステムを一つの有機的（ゆうきてき）なエコシステムにまとめる技術であり戦略（せんりゃく）です。

この記事（きじ）では、EAIの歴史（れきし）と核心概念（かくしんがいねん）、4つの統合（とうごう）トポロジー、Gregor HohpeのEnterprise Integration Patterns、主要（しゅよう）プラットフォーム比較（ひかく）、そして実践（じっせん）プロジェクトまで -- EAIのAからZまでを解説（かいせつ）します。

1. EAIとは何（なに）か

1-1. 企業システム統合の必要性：サイロ問題

企業が成長（せいちょう）すると、自然（しぜん）とデータサイロ（Data Silo）問題が発生（はっせい）します。

各（かく）システムが独立（どくりつ）して運用されると、次（つぎ）のような問題が発生します。

  1. データ不整合（ふせいごう）：顧客の住所がCRMでは更新（こうしん）されたが、ERPには反映（はんえい）されていない
  2. 手作業（てさぎょう）の増加（ぞうか）：CSVダウンロード後（ご）、別のシステムに手動（しゅどう）でアップロード
  3. リアルタイム性の不足（ふそく）：在庫状況（じょうきょう）を確認（かくにん）するにはWMSに別途ログインが必要（ひつよう）
  4. コストの無駄（むだ）：同一（どういつ）データを複数（ふくすう）のシステムに重複（ちょうふく）入力（にゅうりょく）

EAIはこれらのサイロを取（と）り壊（こわ）し、システム間のデータとプロセスを自動的（じどうてき）に、リアルタイムで、安定的（あんていてき）に統合します。

1-2. EAIの歴史

EAIの進化（しんか）は、企業のITインフラの発展（はってん）と共（とも）にあります。

時代（じだい）統合方式（ほうしき）代表技術特徴（とくちょう）
1990年代前半Point-to-Pointカスタムコード、FTP個別接続、スパゲッティ
1990年代後半Hub-and-SpokeTIBCO、IBM MQ中央ハブ管理
2000年代ESBMuleSoft ESB、Oracle ESB、IBM IIB分散バス、SOA
2010年代API-LedREST API、API Gatewayマイクロサービス時代
2020年代Event-Driven + iPaaSKafka、Workato、MuleSoft Anypointイベント駆動、クラウドネイティブ

1-3. EAI vs SOA vs Microservices vs API Management

この4つの概念（がいねん）はよく混同（こんどう）されます。関係（かんけい）を明確（めいかく）にしましょう。

EAI (統合戦略)
├── SOA (アーキテクチャスタイル)
│   └── Microservices (SOA発展形)
├── API Management (API管理レイヤー)
├── Message Broker (非同期統合)
└── iPaaS (クラウド統合プラットフォーム)

1-4. 統合市場規模（しじょうきぼ）

EAI/統合市場は着実（ちゃくじつ）に成長しています。

2. 4つのEAI統合トポロジー

2-1. Point-to-Point（ポイント・トゥ・ポイント）

最（もっと）も原始的（げんしてき）な統合方式です。システムAとBを直接（ちょくせつ）接続します。

システムA ←→ システムB
システムA ←→ システムC
システムB ←→ システムC
システムA ←→ システムD
システムB ←→ システムD
システムC ←→ システムD

接続数（すう）の公式（こうしき）：Nシステムの場合、N*(N-1)/2の接続が必要

これをスパゲッティアーキテクチャと呼（よ）びます。保守（ほしゅ）が悪夢（あくむ）になります。

いつ許容（きょよう）されるか？

2-2. Hub-and-Spoke（ハブ・アンド・スポーク）

すべてのシステムが中央（ちゅうおう）のハブ（Hub）を介（かい）して接続されます。

         システムA
            |
システムD ── HUB ── システムB
            |
         システムC

メリット：

デメリット：

代表製品： IBM WebSphere Message Broker、TIBCO BusinessWorks

2-3. ESB（Enterprise Service Bus）

ESBはHub-and-Spokeの単一障害点問題を解決（かいけつ）するために登場（とうじょう）しました。分散（ぶんさん）バスアーキテクチャを使用します。

システムA ── アダプタ ──┐
                       │
システムB ── アダプタ ──┼── ESB（分散メッセージバス）──┼── アダプタ ── システムE
                       │                              │
システムC ── アダプタ ──┘                              └── アダプタ ── システムF

ESBの中核（ちゅうかく）機能（きのう）：

  1. メッセージルーティング：メッセージを適切（てきせつ）な宛先（あてさき）に配信（はいしん）
  2. プロトコル変換：SOAP/REST/JMS/FTP等のプロトコル間変換
  3. データ変換：XML/JSON/CSV等のデータフォーマット変換
  4. オーケストレーション：複数サービス呼（よ）び出（だ）しを順序（じゅんじょ）どおりに組（く）み合（あ）わせ
  5. セキュリティ：認証（にんしょう）・認可（にんか）、メッセージ暗号化（あんごうか）
  6. モニタリング：メッセージ追跡（ついせき）、パフォーマンスモニタリング

主要ESB製品：

ESBが衰退（すいたい）している理由（りゆう）：

2-4. API-Led Connectivity（現代的アプローチ）

MuleSoftが提案（ていあん）した現代的な統合方法論（ほうほうろん）です。3階層（かいそう）APIアーキテクチャを使用します。

[モバイル/ウェブ/パートナー]
       │
  Experience API（チャネル別カスタマイズ）
       │
   Process API（ビジネスロジック合成）
       │
   System API（バックエンドシステム抽象化）
       │
[SAP / Salesforce / DB / レガシー]

3階層の説明（せつめい）：

現代的ハイブリッド：API Gateway + Event Mesh

[クライアント]
    │
API Gateway（同期リクエスト）
    │                    Event Mesh（非同期イベント）
    ├── REST API ───────── Kafka / EventBridge
    └── GraphQL             │
                     ┌──────┼──────┐
                  サービスA  サービスB  サービスC

比較表：4つのトポロジー

項目（こうもく）Point-to-PointHub-and-SpokeESBAPI-Led
複雑度（ふくざつど）システム数に応じて急増中間（ちゅうかん）高い中間
拡張性（かくちょうせい）非常（ひじょう）に低い低い中間高い
障害影響個別接続のみハブダウン時は全体部分（ぶぶん）的階層別隔離（かくり）
保守性非常に困難中間困難容易（ようい）
クラウド適合性低い低い低い高い
コスト初期低、長期高中間高い中間
推奨（すいしょう）シナリオ小規模一時的中規模オンプレミスレガシーSOA現代クラウド/MSA

3. Enterprise Integration Patterns（EIP）- Gregor Hohpeのバイブル

2003年にGregor HohpeとBobby Woolfが著述（ちょじゅつ）したEnterprise Integration Patternsは、EAIのバイブルと呼ばれています。65のメッセージングパターンを体系的（たいけいてき）に整理（せいり）したこの書籍（しょせき）は、20年以上経（た）った今もApache Camel、Spring Integration、MuleSoftなどほぼすべての統合フレームワークの理論的（りろんてき）基盤（きばん）です。

3-1. メッセージチャネル（Message Channel）

アプリケーション間でデータを伝達（でんたつ）するパイプラインです。

// Apache Camel - メッセージチャネル定義
from("jms:queue:orders")       // 入力チャネル
    .to("jms:queue:validated"); // 出力チャネル

チャネルの種類（しゅるい）：

3-2. メッセージルーター（Message Router）

条件（じょうけん）に従（したが）ってメッセージを適切なチャネルに送（おく）ります。

Content-Based Router（コンテンツベースルーター）

メッセージの内容（ないよう）を分析（ぶんせき）してルーティングします。

// Apache Camel - Content-Based Router
from("jms:queue:orders")
    .choice()
        .when(xpath("/order/country = 'JP'"))
            .to("jms:queue:orders-jp")
        .when(xpath("/order/country = 'US'"))
            .to("jms:queue:orders-us")
        .when(xpath("/order/country = 'KR'"))
            .to("jms:queue:orders-kr")
        .otherwise()
            .to("jms:queue:orders-other")
    .end();

Message Filter（メッセージフィルター）

条件に合（あ）うメッセージだけを通過（つうか）させます。

// Apache Camel - Message Filter
from("jms:queue:orders")
    .filter(xpath("/order/amount > 100000"))
    .to("jms:queue:high-value-orders");

3-3. メッセージトランスレーター（Message Translator）

異なるデータフォーマットを変換します。

// Apache Camel - XMLからJSONへの変換
from("jms:queue:orders-xml")
    .unmarshal().jacksonXml(Order.class)
    .marshal().json(JsonLibrary.Jackson)
    .to("jms:queue:orders-json");

3-4. Splitter（スプリッター）とAggregator（アグリゲーター）

Splitter：一つのメッセージを複数に分割（ぶんかつ）します。

// Apache Camel - Splitter
from("jms:queue:batch-orders")
    .split(xpath("/orders/order"))
    .to("jms:queue:single-order");

Aggregator：複数のメッセージを一つに集約（しゅうやく）します。

// Apache Camel - Aggregator
from("jms:queue:single-order-result")
    .aggregate(header("batchId"), new OrderAggregationStrategy())
    .completionSize(10)
    .completionTimeout(5000)
    .to("jms:queue:batch-result");

3-5. Dead Letter Channel（デッドレターチャネル）

処理に失敗したメッセージを別途保管します。

// Apache Camel - Dead Letter Channel
errorHandler(deadLetterChannel("jms:queue:dead-letters")
    .maximumRedeliveries(3)
    .redeliveryDelay(1000)
    .retryAttemptedLogLevel(LoggingLevel.WARN));

from("jms:queue:orders")
    .process(exchange -> {
        // 処理ロジック - 失敗時は自動的にDLCへ移動
        Order order = exchange.getIn().getBody(Order.class);
        orderService.process(order);
    })
    .to("jms:queue:processed-orders");

3-6. Idempotent Consumer（冪等コンシューマー）

同じメッセージを複数回受け取っても結果（けっか）が同一であることを保証（ほしょう）します。ネットワーク再送（さいそう）やシステム再起動（さいきどう）時の重複処理を防止（ぼうし）します。

// Apache Camel - Idempotent Consumer（メモリベース）
from("jms:queue:orders")
    .idempotentConsumer(
        header("orderId"),
        MemoryIdempotentRepository.memoryIdempotentRepository(200)
    )
    .to("jms:queue:unique-orders");

// Redisベースの冪等性（プロダクション推奨）
from("jms:queue:orders")
    .idempotentConsumer(
        header("orderId"),
        new RedisIdempotentRepository(redisTemplate, "processed-orders")
    )
    .to("jms:queue:unique-orders");

3-7. Wire Tap（ワイヤータップ）

メッセージフローを妨（さまた）げることなくメッセージを複製（ふくせい）して別途転送（てんそう）します。ロギング、監査（かんさ）、モニタリングに使用されます。

// Apache Camel - Wire Tap
from("jms:queue:orders")
    .wireTap("jms:queue:order-audit")    // 監査用複製
    .to("jms:queue:order-processing");   // 元のフロー継続

3-8. EIPパターン要約表（ようやくひょう）

パターン目的（もくてき）使用事例（じれい）
Content-Based Router内容ベースルーティング国別注文分類
Message Filter条件フィルタリング高額注文のみ処理
Splitterメッセージ分割バッチを個別件に
Aggregatorメッセージ集約個別結果をまとめて応答（おうとう）
Dead Letter Channel失敗メッセージ保管再処理・分析用
Idempotent Consumer重複防止同一注文の重複処理防止
Wire Tap非侵襲的（ひしんしゅうてき）複製監査ロギング
Publish-Subscribe1:N配信イベントブロードキャスト
Message Translatorフォーマット変換XMLからJSONへ
Routing Slip動的（どうてき）ルーティング注文タイプ別多段階処理

4. データ統合パターン

4-1. Canonical Data Model（CDM）- 標準データモデル

Nシステム間でデータを交換（こうかん）する際（さい）、すべてのシステムが互（たが）いのフォーマットを知（し）る必要なく、一つの標準フォーマット（CDM）に変換します。

CDMなし（N:Nマッピング）：
SAP (IDOC) <-> Salesforce (SOQL)
SAP (IDOC) <-> WMS (CSV)
Salesforce (SOQL) <-> WMS (CSV)
= 3マッピング（3システム基準）

CDM適用（N:1マッピング）：
SAP (IDOC) -> CDM (JSON) -> Salesforce
WMS (CSV) -> CDM (JSON) -> Salesforce
SAP (IDOC) -> CDM (JSON) -> WMS
= 各システムからCDMへの1マッピングのみ実装

CDM設計原則（げんそく）：

  1. 中立性（ちゅうりつせい）：特定システムに偏（かたよ）らないスキーマ
  2. 拡張性：新しいシステム追加時にCDMを拡張可能
  3. バージョン管理：CDMのスキーマバージョン管理が必須（ひっす）
  4. 文書化（ぶんしょか）：フィールドの意味（いみ）、データタイプ、制約（せいやく）条件を明示（めいじ）
{
  "canonicalOrder": {
    "orderId": "ORD-2026-001",
    "orderDate": "2026-03-23T10:30:00Z",
    "customer": {
      "customerId": "CUST-001",
      "name": "田中太郎",
      "email": "tanaka@example.com"
    },
    "items": [
      {
        "productId": "PROD-100",
        "productName": "ノートパソコン",
        "quantity": 2,
        "unitPrice": 180000,
        "currency": "JPY"
      }
    ],
    "totalAmount": 360000,
    "status": "CREATED"
  }
}

4-2. データフォーマット比較

フォーマット用途（ようと）メリットデメリット
XMLエンタープライズ（SOAP、ESB）スキーマ検証（けんしょう）（XSD）、成熟したエコシステム冗長（じょうちょう）、パース遅い
JSONREST API、ウェブ軽量（けいりょう）、可読性（かどくせい）、パース速いスキーマ検証弱い
CSVバッチデータ、レポートシンプル、汎用（はんよう）構造化限界、型なし
EDIB2B電子商取引（でんししょうとりひき）業界標準（ぎょうかいひょうじゅん）（EDIFACT、X12）複雑、レガシー
ProtobufgRPC、高性能（こうせいのう）非常に小さく速い、スキーマ強制人間が読みにくい
AvroKafka、ビッグデータスキーマ進化、Kafka最適エコシステム限定

4-3. データマッピングツール

XSLT（XML変換）

<!-- SAP IDOCをCDMに変換するXSLT -->
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/ORDERS05">
    <canonicalOrder>
      <orderId><xsl:value-of select="IDOC/E1EDK01/BELNR"/></orderId>
      <orderDate><xsl:value-of select="IDOC/E1EDK01/DATUM"/></orderDate>
      <customer>
        <customerId><xsl:value-of select="IDOC/E1EDKA1/PARVW"/></customerId>
        <name><xsl:value-of select="IDOC/E1EDKA1/NAME1"/></name>
      </customer>
    </canonicalOrder>
  </xsl:template>
</xsl:stylesheet>

DataWeave（MuleSoft）

%dw 2.0
output application/json
---
{
  canonicalOrder: {
    orderId: payload.ORDERS05.IDOC.E1EDK01.BELNR,
    orderDate: payload.ORDERS05.IDOC.E1EDK01.DATUM as Date,
    customer: {
      customerId: payload.ORDERS05.IDOC.E1EDKA1.PARVW,
      name: payload.ORDERS05.IDOC.E1EDKA1.NAME1
    },
    items: payload.ORDERS05.IDOC.E1EDP01 map ((item) -> {
      productId: item.MATNR,
      quantity: item.MENGE as Number,
      unitPrice: item.NETPR as Number
    })
  }
}

JSONata（軽量JSON変換）

{
  "canonicalOrder": {
    "orderId": sapOrder.BELNR,
    "orderDate": sapOrder.DATUM,
    "customer": {
      "customerId": sapOrder.PARVW,
      "name": sapOrder.NAME1
    },
    "totalAmount": $sum(sapOrder.items.(MENGE * NETPR))
  }
}

4-4. マスターデータ管理（MDM）

MDMは、企業全体でコアデータ（顧客、商品、組織）の単一ソース（Single Source of Truth）を維持（いじ）する戦略です。

MDMがEAIに重要（じゅうよう）な理由：

4-5. CDC（Change Data Capture）- Debezium

CDCはデータベースの変更（へんこう）をリアルタイムで検知（けんち）し、他のシステムに伝播（でんぱ）する技術です。Debeziumは代表的なオープンソースCDCソリューションです。

# Debeziumコネクタ設定（MySQL）
name: mysql-connector
config:
  connector.class: io.debezium.connector.mysql.MySqlConnector
  database.hostname: mysql-server
  database.port: 3306
  database.user: debezium
  database.password: secret
  database.server.id: 1
  topic.prefix: myapp
  database.include.list: ecommerce
  table.include.list: ecommerce.orders,ecommerce.customers
  schema.history.internal.kafka.bootstrap.servers: kafka:9092
  schema.history.internal.kafka.topic: schema-changes

[MySQL DB] -> [Debezium Connector] -> [Kafka Topic] -> [Consumer App]
                                                      -> [Elasticsearch]
                                                      -> [Data Warehouse]

CDCの利点（りてん）：

5. EAIプラットフォーム比較（2025年）

5-1. MuleSoft Anypoint Platform

Salesforceが買収（ばいしゅう）したエンタープライズ統合の絶対的（ぜったいてき）リーダーです。

中核（ちゅうかく）コンポーネント：

メリット：

デメリット：

5-2. Apache Camel + Spring Boot

オープンソース統合フレームワークの代名詞（だいめいし）です。Gregor HohpeのEIPをコードで完全実装しています。

// Spring Boot + Apache Camelの例
@Component
public class OrderIntegrationRoute extends RouteBuilder {

    @Override
    public void configure() throws Exception {
        // エラーハンドリング
        errorHandler(deadLetterChannel("kafka:dead-letters")
            .maximumRedeliveries(3)
            .redeliveryDelay(2000));

        // SAPから注文受信 -> 変換 -> CRMへ送信
        from("sap-idoc:ORDERS05")
            .routeId("sap-to-crm-orders")
            .log("SAP注文受信: orderId=${header.orderId}")
            .unmarshal().jacksonXml(SapOrder.class)
            .bean(OrderTransformer.class, "toCanonical")
            .marshal().json(JsonLibrary.Jackson)
            .choice()
                .when(simple("${body[totalAmount]} > 10000000"))
                    .to("kafka:high-value-orders")
                .otherwise()
                    .to("kafka:standard-orders")
            .end()
            .to("salesforce:upsert:Order__c?sObjectIdName=SAP_Order_Id__c");
    }
}

主要特徴：

メリット：

デメリット：

5-3. Dell Boomi

クラウドネイティブiPaaSの先駆者（せんくしゃ）です。

主要特徴：

メリット：

デメリット：

5-4. Workato / Tray.io

ビジネスユーザーフレンドリーなiPaaSです。

主要特徴：

メリット：

デメリット：

プラットフォーム比較表

項目MuleSoftApache CamelDell BoomiWorkato
タイプiPaaS + オンプレOSSフレームワークiPaaSiPaaS
価格非常に高い（年50K−50K-500K+）無料（インフラ費のみ）高い（年$50K+）中間（年$10K+）
学習曲線中〜高高い（開発者）低い非常に低い
拡張性非常に高い非常に高い高い中間
クラウドハイブリッドすべてクラウド優先クラウド専用
コミュニティ大規模非常に大規模中間中間
レガシー統合強い非常に強い中間弱い
SaaS統合強い中間強い非常に強い
対象ユーザー開発者 + アーキテクト開発者開発者 + 非開発者非開発者 + 開発者

6. 実践プロジェクト：ERP-CRM-WMS連携

6-1. シナリオ

中堅（ちゅうけん）ECサイト企業が次の3つのシステムを統合しようとしています。

統合要件（ようけん）：

  1. ウェブサイトで注文（ちゅうもん）作成時にSAP ERPに注文登録
  2. SAPで在庫確認後、WMSに出荷（しゅっか）指示
  3. WMSで配送開始時にSalesforceにステータス更新
  4. すべてのプロセスは非同期、リアルタイム、障害耐性（たいせい）が必要

6-2. アーキテクチャ設計

[ウェブサイト] -> REST API -> [API Gateway]
                                 │
                          [Apache Camel Hub]
                          ┌──────┼──────────┐
                          │      │          │
                       [Kafka]  [Kafka]   [Kafka]
                       orders   inventory  shipping
                          │      │          │
                     [SAP ERP] [WMS]  [Salesforce CRM]
                          │      │          │
                          └──────┼──────────┘
                                 │
                          [Monitoring]
                       Prometheus + Grafana

6-3. Camelルートコード（Java DSL）

@Component
public class EcommerceIntegrationRoutes extends RouteBuilder {

    @Override
    public void configure() throws Exception {

        // ===== グローバルエラーハンドリング =====
        errorHandler(deadLetterChannel("kafka:dead-letter-queue")
            .maximumRedeliveries(3)
            .redeliveryDelay(2000)
            .backOffMultiplier(2)
            .useExponentialBackOff()
            .retryAttemptedLogLevel(LoggingLevel.WARN)
            .logRetryStackTrace(true));

        // ===== 第1段階：注文受信 -> SAP ERP登録 =====
        from("rest:post:/api/orders")
            .routeId("order-intake")
            .log("新規注文受信: ${body}")
            .unmarshal().json(JsonLibrary.Jackson, OrderRequest.class)
            .bean(OrderValidator.class, "validate")
            .bean(OrderTransformer.class, "toCanonical")
            .marshal().json(JsonLibrary.Jackson)
            .to("kafka:orders?brokers=localhost:9092")
            .setBody(simple("注文が受け付けられました。注文番号: ${header.orderId}"));

        // SAP ERP注文登録
        from("kafka:orders?brokers=localhost:9092&groupId=sap-consumer")
            .routeId("sap-order-registration")
            .idempotentConsumer(
                header("orderId"),
                new RedisIdempotentRepository(redisTemplate, "sap-orders")
            )
            .unmarshal().json(JsonLibrary.Jackson, CanonicalOrder.class)
            .bean(SapOrderTransformer.class, "toSapIdoc")
            .to("sap-idoc:ORDERS05")
            .log("SAP注文登録完了: ${header.orderId}")
            .to("kafka:inventory-check?brokers=localhost:9092");

        // ===== 第2段階：在庫確認 -> WMS出荷指示 =====
        from("kafka:inventory-check?brokers=localhost:9092&groupId=wms-consumer")
            .routeId("inventory-check-and-ship")
            .unmarshal().json(JsonLibrary.Jackson, CanonicalOrder.class)
            .bean(InventoryService.class, "checkAvailability")
            .choice()
                .when(simple("${header.inventoryAvailable} == true"))
                    .log("在庫確保: ${header.orderId}")
                    .bean(WmsTransformer.class, "toShipmentRequest")
                    .to("http://wms-api.internal:8080/api/shipments")
                    .to("kafka:shipping-started?brokers=localhost:9092")
                .otherwise()
                    .log("在庫不足: ${header.orderId}")
                    .to("kafka:backorder-queue?brokers=localhost:9092")
            .end();

        // ===== 第3段階：配送開始 -> Salesforceステータス更新 =====
        from("kafka:shipping-started?brokers=localhost:9092&groupId=crm-consumer")
            .routeId("crm-status-update")
            .unmarshal().json(JsonLibrary.Jackson, ShipmentEvent.class)
            .bean(SalesforceTransformer.class, "toOpportunityUpdate")
            .to("salesforce:upsert:Opportunity?sObjectIdName=Order_Id__c")
            .log("Salesforceステータス更新完了: ${header.orderId}");

        // ===== サーキットブレーカー =====
        from("kafka:critical-orders?brokers=localhost:9092")
            .routeId("circuit-breaker-route")
            .circuitBreaker()
                .resilience4jConfiguration()
                    .failureRateThreshold(50)
                    .waitDurationInOpenState(30000)
                    .slidingWindowSize(10)
                .end()
                .to("http://payment-service:8080/api/process")
            .onFallback()
                .log("決済サービス障害 - フォールバック処理")
                .to("kafka:payment-retry-queue?brokers=localhost:9092")
            .end();
    }
}

6-4. モニタリング構成

# docker-compose-monitoring.yml
version: '3.8'
services:
  prometheus:
    image: prom/prometheus:latest
    ports:
      - '9090:9090'
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml

  grafana:
    image: grafana/grafana:latest
    ports:
      - '3000:3000'
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin

  # Camelメトリクス公開
  camel-app:
    build: .
    ports:
      - '8080:8080'
      - '8081:8081' # Actuator/Prometheusメトリクス
    environment:
      - MANAGEMENT_ENDPOINTS_WEB_EXPOSURE_INCLUDE=health,prometheus
      - MANAGEMENT_METRICS_EXPORT_PROMETHEUS_ENABLED=true

主要モニタリングメトリクス：

7. EAIと現代アーキテクチャの融合（ゆうごう）

7-1. EAI + マイクロサービス

マイクロサービス環境でEAIは消（き）えません。むしろサービスメッシュ（Service Mesh）とイベントメッシュ（Event Mesh）に進化します。

[マイクロサービスA] ──── API Gateway（同期）──── [マイクロサービスB]
        │                                              │
        └──── Event Mesh (Kafka/EventBridge) ──────────┘
                          │
                   [レガシーERP]  <- Apache Camelアダプタ

キーパターン：

7-2. EAI + クラウド

クラウド環境ではEAIはiPaaSとサーバーレスに進化します。

オンプレミスEAIクラウドEAI
ESBサーバー管理iPaaS（マネージド）
自前メッセージキューAmazon SQS / Azure Service Bus
自前モニタリングCloudWatch / Datadog
手動スケーリングオートスケーリング
CAPEX中心OPEX（従量課金）

AWSベースのサーバーレスEAIアーキテクチャ：

[外部システム] -> API Gateway -> Lambda（変換）-> EventBridge -> Step Functions
                                                                     │
                                                          ┌──────────┼──────────┐
                                                       Lambda A   Lambda B   Lambda C
                                                       (SAP)     (SF)       (WMS)
                                                          │         │         │
                                                          └─────────┼─────────┘
                                                                    │
                                                              DynamoDB（状態）
                                                                    │
                                                          CloudWatch（モニタリング）

7-3. EAI + AI

AIがEAIにもたらす革新（かくしん）：

  1. 自動データマッピング：AIがソース-ターゲットフィールドを自動マッピング提案
  2. 異常検知（いじょうけんち）：統合パイプラインの異常パターンを自動検出
  3. 自己修復（じこしゅうふく）：障害発生時にAIが自動復旧（ふっきゅう）戦略を実行
  4. 自然言語統合：「SAPの注文をSalesforceに同期して」と言えばパイプラインを自動生成

7-4. EAI + MCP（Model Context Protocol）

2025年に登場したMCPは、AIエージェントが外部ツールと標準化された方法で通信するプロトコルです。EAIとMCPが結合すると、AIエージェントがEAIパイプラインを直接オーケストレーションできます。

[AIエージェント (Claude, GPT)]
        │
    MCP Protocol
        │
[MCPサーバー：EAIオーケストレーター]
    ├── Tool: createIntegrationFlow
    ├── Tool: monitorPipeline
    ├── Tool: triggerDataSync
    └── Tool: debugFailedMessages
        │
[Apache Camel / MuleSoft / AWS Step Functions]

未来（みらい）のシナリオ：

8. 韓国企業のEAI現況（げんきょう）

8-1. 主要韓国EAIソリューション

韓国（かんこく）企業はグローバルソリューションと国産（こくさん）ソリューションを併用（へいよう）しています。

ソリューション開発会社主要顧客特徴
NexledgerSamsung SDSサムスングループブロックチェーン連携、サムスン生態系最適化
LG CNS EAILG CNSLGグループLGグループ内部標準
SK C&C EAISK C&CSKグループSKグループインフラ統合
X-PlatformTOBESOFT金融、公共UI/UX強み、レガシー接続
AnyLinkBizFlow金融、製造韓国金融圏でのシェア高い

8-2. 電子政府フレームワークとESB

韓国の公共機関（こうきょうきかん）は電子政府フレームワーク（eGovFrame）をベースにシステムを構築しています。

8-3. 金融圏（きんゆうけん）のEAI

韓国金融圏のEAIは特殊（とくしゅ）な構造（こうぞう）を持（も）っています。

[インターネットバンキング] ──┐
[モバイルバンキング]     ───┤── MCI ── EAI ── コアバンキング
[ATM]                    ───┤                   │
[テラーシステム]          ───┘              ├── CRM
                                           ├── リスク
                                           └── FEP -> KFTC/カード会社/保険会社

金融EAIの特殊要件：

8-4. 公共機関の連携

実践クイズ

Q1. Point-to-Pointの接続数

10個のシステムをPoint-to-Pointですべて接続するとき、必要な接続数は？

回答を見る

45個

公式：N _ (N-1) / 2 = 10 _ 9 / 2 = 45

これがPoint-to-Pointが大規模システムに不適切な理由です。Hub-and-Spokeなら10個の接続だけで済みます。

Q2. ESBが衰退する核心的理由

ESB（Enterprise Service Bus）が現代アーキテクチャで衰退している最も核心的な理由は？

回答を見る

ESB自体がモノリシックなボトルネックになるためです。

すべての統合ロジックがESBに集中することで、ESBが巨大なモノリスになります。一つの統合フローを変更すると他のフローに影響を与える可能性があり、デプロイも困難になります。これは独立デプロイと分散自律性を強調するマイクロサービスの哲学と正面から衝突します。

現代的な代替案はAPI-Led Connectivity + Event Meshの組み合わせです。

Q3. Idempotent Consumerパターン

メッセージブローカーから同じ注文メッセージが3回配信されたとき、重複処理を防止するEIPパターンの名前と実装の核心は？

回答を見る

Idempotent Consumer（冪等コンシューマー）パターン

実装の核心：

  1. メッセージの一意識別子（例：orderId）を基準に、すでに処理済みのメッセージか確認
  2. 処理済みメッセージIDをストレージ（Redis、DB、メモリ）に保管
  3. 同一IDのメッセージが来たらスキップ

Apache CamelではidempotentConsumer() DSLで簡単に実装できます。プロダクションでは分散環境を考慮してRedisやDBベースのストレージを使用する必要があります。

Q4. CDM（Canonical Data Model）の利点

5つのシステム間でデータを交換するとき、CDMなしで必要なマッピング数とCDM適用後のマッピング数を比較してください。

回答を見る

CDMなし：各システムが他のすべてのシステムのフォーマットを知る必要があるため、N _ (N-1) = 5 _ 4 = 20マッピング（双方向）

CDM適用後：各システムがCDMへの変換とCDMからの変換だけ実装すればよいため、N _ 2 = 5 _ 2 = 10マッピング（システムからCDM、CDMからシステム）

CDMを使用すると、新しいシステム追加時にも2つのマッピング（CDMへ、CDMから）を追加するだけで済みます。

Q5. MuleSoft vs Apache Camelの選択

スタートアップ（開発者3名、予算制限）がSAPとShopifyを連携させたいと考えています。MuleSoftとApache Camelのどちらをお勧めしますか？

回答を見る

Apache Camel + Spring Bootをお勧めします。

理由：

  1. コスト：MuleSoftは年間5万ドル以上。スタートアップには過度なコスト。Apache Camelは無料
  2. 開発者フレンドリー：開発者3名ならコードベースのCamelの方が迅速に学習・実装可能
  3. コネクタ：CamelにSAPコンポーネント（camel-sap）とShopify REST API連携コンポーネントが存在
  4. 拡張性：後でシステムが増えてもCamel Routeを追加するだけ
  5. クラウド：Camel KでKubernetesデプロイも容易

ただし、非開発者が統合を管理する必要がある場合やSalesforceエコシステムが中心の場合は、MuleSoftがより適切な選択かもしれません。

参考資料（さんこうしりょう）

書籍（しょせき）

公式ドキュメント

EIP参考

クラウド統合

市場分析

韓国EAI

コミュニティ

原文を読む: https://www.youngju.dev/blog/culture/2026-03-23-eai-enterprise-application-integration-complete-guide.ja

コメント

まだコメントはありません。

ログインするとコメントできます