EAIとESB(エンタープライズアプリケーション統合)
1. 概要
EAI(Enterprise Application Integration, エンタープライズアプリケーション統合)とは、企業内部に散在する異機種のアプリケーション・データ・プロセスを標準化された連携基盤の上で相互接続し、あたかも一つのシステムのようにデータをやり取りし業務フローをつなぐ統合技術であり戦略である。そしてESB(Enterprise Service Bus, エンタープライズサービスバス)は、このEAIをサービス指向(SOA)の観点から実装した標準メッセージバス型ミドルウェアであり、ルーティング・変換・プロトコル中継・オーケストレーションといった連携機能を中央バスに集め、疎結合なサービス間通信を仲介する。
EAIが登場した背景には、企業情報化が「部門別最適化」の結果として残したサイロ(silo)とスパゲッティインターフェースの問題がある。1980〜1990年代の企業は会計・人事・営業・生産・物流の領域ごとにパッケージや自社開発システムを別々に導入し、その結果ERP・CRM・SCM・レガシーメインフレームが互いに異なるDB・プロトコル・データフォーマットで乱立することになった。これらを接続しようとシステムごとに1:1インターフェースを作るうちに、n個のシステムをすべて接続するには理論上n(n−1)/2本の接続線が必要になった。例えばシステム10個を完全接続すると45本のポイントツーポイント(point-to-point)インターフェースが生じ、一つが変わると接続されたすべての相手が影響を受け、保守コストが指数的に増加した。この「スパゲッティ統合」の限界を中央集中型連携ハブで解こうというのがEAIの出発点である。
ESBは、EAIが成熟しながらSOA(サービス指向アーキテクチャ)と出会った結果物である。2000年代初頭に企業は統合の単位を単なる「データ連携」から再利用可能な「サービス」へ引き上げようとし、このときサービスどうしが互いの位置・プロトコル・フォーマットを知らなくても通信できるようバス(bus)という媒介が必要になった。ESBはまさにこの役割を担い、メッセージを受け取って適切なサービスへルーティングし、異なるフォーマットを変換し、SOAP・REST・JMS・FTPといった異質なプロトコルを中継する。すなわちEAIが「何をなぜ統合するか」という目標であれば、ESBは「どう標準化されたバスで統合するか」という代表的な実装方式である。
EAI/ESBの必要性は三つの軸で明確になる。第一は保守性であり、連携ロジックを各アプリケーションから切り離して中央に集めれば変更の波及範囲が減る。第二は俊敏性であり、新規システムを付けるとき既存のn個すべてと接続する代わりにハブ・バスに一度だけ接続すればよいため、ビジネス要求の変化に素早く対応できる。第三はデータ整合性とガバナンスであり、連携地点を一箇所で観測・統制することで、どのデータがどこへ流れるかを追跡し、セキュリティ・監査ポリシーを一貫して適用できる。近年はクラウド・SaaS・モバイルが増え、接続対象が社内を越えて外部へ拡張され、それに伴いEAIの重心が従来のESBからAPI管理・iPaaS・イベント基盤統合へ移りつつある。
EAIが扱う統合の層位は、しばしばデータ・アプリケーション・プロセス・ユーザーインターフェースの四つの水準に区分される。最も低いデータ水準統合はDB間のデータを直接同期する方式で実装が単純だが、アプリケーションのビジネスルールを迂回するため整合性リスクがある。アプリケーション(API)水準統合は各システムが公開したインターフェースを通じて機能を呼び出すためルールが保たれ、今日の統合の主流である。プロセス水準統合は複数システムにまたがる業務フローを一つのプロセスに編むもので、ESBのオーケストレーションが担う。このように統合は「どの層位で束ねるか」によってコストとリスクが変わるため、目的に合った層位を選ぶことがEAI設計の最初の決定となる。
EAI/ESBを他の連携方式と区別づける特徴は、疎結合(loose coupling)・仲介(mediation)・宣言的連携に要約される。送信者と受信者が互いを直接知る必要なくバスが仲介するため一方の変更が他方に隠され、ルーティング・変換ルールをコードではなく設定として宣言して変更コストを下げる。これらの特徴は、なぜESBが一時SOAの中枢として脚光を浴びたのか、そしてなぜ後で扱う「中央バスのボトルネック・単一障害点」の問題で批判されるようになったのかを同時に説明する。
一方、EAI/ESBは単なる技術導入ではなく全社アーキテクチャガバナンスの一部であるという点も最初から明確にしなければならない。連携基盤を中央に置くと「誰が連携ルールを定め変更を承認するか」「共通フォーマットの標準を誰が管理するか」といった組織的な問いが伴うからである。技術的にいかに優れたバスを構築しても、このガバナンスがなければ各チームが思い思いに連携を作り、結局は中央バスの上にまた別のスパゲッティが積み上がる。すなわちEAIはミドルウェア選択の前に、標準・責任・変更手続きを定める統合ガバナンス設計から出発すべきである。
2. EAI統合の類型とアーキテクチャ
EAIを理解する核心は、「接続トポロジー」が統合のコストと拡張性を左右するという点である。同じシステムどうしを接続しても、ポイントツーポイントか、ハブ&スポークか、メッセージバスかによって保守の難易度と障害伝播の様相がまったく異なる。以下の全体構造図は三つのトポロジーの接続形態を対比して示す。
flowchart LR
subgraph P2P["ポイントツーポイント(Point-to-Point)"]
A1["ERP"] --- A2["CRM"]
A1 --- A3["SCM"]
A2 --- A3
A1 --- A4["レガシー"]
A2 --- A4
A3 --- A4
end
subgraph HUB["ハブ&スポーク(Hub & Spoke, EAI)"]
H(("統合ハブ"))
B1["ERP"] --> H
B2["CRM"] --> H
B3["SCM"] --> H
B4["レガシー"] --> H
end
subgraph BUS["メッセージバス(ESB)"]
BUSLINE["サービスバス"]
C1["ERP"] --> BUSLINE
C2["CRM"] --> BUSLINE
C3["SCM"] --> BUSLINE
C4["レガシー"] --> BUSLINE
end
三つのトポロジーは統合の歴史で順次登場したが、今日では一つの企業の中でも領域に応じて共存するという点をまず押さえておく必要がある。レガシーコアは依然ポイントツーポイントで束ねられ、全社共通データはハブやバスを経由し、新規クラウドサービスはAPI・イベントで接続される、といった具合である。したがってトポロジーの選択は「何が正しいか」の問題というより、「どの領域に、どのような変更頻度と性能要求に合わせて何を使うか」という領域別適合性の問題である。
ポイントツーポイント(Point-to-Point)方式は最も単純だが最も危険なトポロジーである。二つのシステムを直接接続するため初期は実装が速く直観的だが、システム数が増えると接続線がn(n−1)/2へ急増し、先に述べたスパゲッティ構造になる。各接続が相手のフォーマット・プロトコルに強く結合し、一つのシステムのスキーマが変わるとそれに接続されたすべてのインターフェースを手直ししなければならない。実務では「連携担当者が退職すると誰も手を付けられない」ブラックボックスインターフェースが積み上がる典型的なアンチパターンとして現れる。少数システムの単発的連携には依然合理的だが、全社統合戦略としては不適である。
ハブ&スポーク(Hub & Spoke)方式は従来のEAIの核心的形態で、中央に統合ハブ(ブローカー)を置きすべてのシステムがハブにのみ接続される構造である。各システムは相手が誰かを知らなくてもハブにメッセージを送れば、ハブが変換・ルーティングを経て目的地へ伝達する。接続数がn個へ線形化され新規システム追加コストが急減し、変換・ルーティングロジックがハブに集中してガバナンスが容易になる。ただしハブがすべてのトラフィックを通すため性能ボトルネックと単一障害点(SPOF)のリスクがあり、ハブ自体が巨大化すると保守が難しくなる。ある製造企業が15個のシステムをポイントツーポイントで接続し100本を超えるインターフェースを運用していたのを、ハブ&スポークEAIへ転換して接続管理ポイントを15個に減らした事例は、この方式の効果を典型的に示す。
メッセージバス(Message Bus)方式、すなわちESBは、ハブの集中を緩和するために統合機能を分散したバスへ再構成した形態である。各システムはバスに接続されたアダプタを通じて標準メッセージをやり取りし、ルーティング・変換はバス上の分散した連携ノードが処理する。ハブ&スポークが「中央の大きな脳」なら、ESBは「複数の停留所をつなぐ路線」に近く、特定ノードの障害が全体へ広がるリスクを減らし水平拡張を図る。実際にはハブ&スポークとバスの境界は明確でなく、商用ESB製品の多くが内部にハブ要素を抱えているため、両者を統合ミドルウェアの進化段階とみなすほうが実務に近い。
| 区分 | ポイントツーポイント | ハブ&スポーク(EAI) | メッセージバス(ESB) |
|---|---|---|---|
| 接続数(nシステム) | n(n−1)/2 | n | n |
| 結合度 | 強結合 | 中間(ハブ依存) | 疎 |
| 拡張性 | 非常に低い | 中間 | 高い |
| 障害伝播 | 局所的 | ハブSPOF | 相対的に分散 |
| ガバナンス | 分散・不透明 | 中央集中 | 中央ポリシー+分散実行 |
表は三つのトポロジーを一目で比較するが、核心は「接続数が二乗から線形へ減る地点」で統合投資の回収が発生するという点である。システムが少ないときはポイントツーポイントが安いが、臨界数を超えると中央連携基盤の初期構築費を相殺してなお余る保守削減が生じる。したがってEAI導入の決定は「今いくつ接続するか」ではなく、「今後いくつへ、どれだけ頻繁に変わり増えるか」という成長見通しに基づくべきである。
3. ESBの構造と中核機能
ESBの価値は単に「メッセージを伝達する」ことではなく、送・受信サービスが互いの差異を知らなくても通信できるよう仲介(mediation)層がその差異を吸収する点にある。互いに異なるフォーマット・プロトコル・アドレスを持つサービスがバスを通じて結合されるため、一方を交換しても他方は影響を受けない。以下のアーキテクチャ詳細図は、メッセージがESBを通過しながら経る仲介パイプラインを表す。
flowchart TB
SRC["送信サービス(例: 注文システム)"] --> IN["インバウンドアダプタ(プロトコル受信)"]
IN --> ROUTE["ルーティング(内容ベースルーティング)"]
ROUTE --> TRANS["メッセージ変換(フォーマット/スキーママッピング)"]
TRANS --> ORCH["オーケストレーション(複数サービス組合せ)"]
ORCH --> SEC["セキュリティ/ポリシー(認証・監査)"]
SEC --> OUT["アウトバウンドアダプタ(プロトコル送信)"]
OUT --> DST1["受信サービスA(配送)"]
OUT --> DST2["受信サービスB(在庫)"]
MON["監視・ロギング"] -.-> ROUTE
MON -.-> TRANS
MON -.-> ORCH
アダプタとプロトコル中継はESBの最も外側の関門である。レガシーメインフレームはMQやファイル(FTP)で、最新サービスはREST/JSONで、金融コアは専用TCP電文で通信するといった具合にプロトコルがまちまちだが、アダプタはこの異質なプロトコルを受け取りバス内部の標準メッセージ形式(canonical message)へ正規化する。こうすることでバス内部ロジックは外部プロトコルの変化から隔離される。例えばある受信システムがSOAPからRESTへ変わっても、アダプタだけ交換すればルーティング・変換ルールはそのまま再利用される。この「プロトコル独立性」がESBを単なるメッセージキューと区別づける第一の能力である。
ルーティング(routing)はメッセージを内容・ヘッダ・ルールに従って適切な目的地へ送る機能である。最も強力な形態は内容ベースルーティング(content-based routing)で、メッセージ本文の値(例: 注文金額が1,000万ウォン以上なら承認サービスへ)を見て分岐する。送信者は受信者が誰かをまったく知らなくてよく、ルーティングルールが変わっても送信コードはそのままである。このように「誰が受け取るか」の決定を送信者からバスへ移すことが疎結合の核心的メカニズムであり、受信者の追加・交換を設定変更だけで処理できるようにする。
メッセージ変換(transformation)は互いに異なるデータスキーマをマッピングする機能で、統合現場で最も工数のかかる部分である。送信システムが顧客をcustNo、受信システムがcustomer_idと呼ぶなら、バスがこれを変換して双方が各自のモデルを保てるようにする。大規模統合ではすべてのシステムが互いのフォーマットを知る必要なく標準共通フォーマット(canonical data model)へのみ変換するよう設計するが、こうするとn個のシステム間の変換ルールがn×nではなくn×1(各システム↔共通フォーマット)へ減り、保守が大きく単純化される。この共通データモデルの設計品質がEAIプロジェクトの成否を左右すると言っても過言ではない。ただし共通フォーマットを過度に大きく包括的に設計すると、どのシステムも完全には使わない「巨大な共通モデル」になり変換ルールがかえって複雑になる逆効果があるため、実際には領域別に適正範囲の共通モデルを分けて管理するのが望ましい。
オーケストレーション(orchestration)は複数のサービスを一つのビジネスフローに編む機能である。例えば「注文受付 → 在庫確認 → 決済 → 配送指示」という業務をバスが中央で順に呼び出し・調整する。これは各サービスが自律的にイベントへ反応するコレオグラフィ(choreography)と対比され、オーケストレーションはフローが一箇所に集まり可視性と統制が容易な反面、中央調整者にロジックが集中して結合度が上がる。逆にコレオグラフィは疎だが全体フローを一目で見にくい。ESB時代は中央オーケストレーションが主流だったが、マイクロサービス時代へ移るにつれコレオグラフィ・イベント基盤へ重心が移ったのは、このトレードオフの再調整である。
セキュリティと監視はESBが全社データの通り道であるという事実から生じる必須機能である。すべてのメッセージがバスを通過するため、認証・認可・暗号化をバスで一括適用すれば、各システムが個別にセキュリティを実装するときよりポリシーの一貫性と監査追跡性が大きく高まる。またバスはメッセージフローを中央で観測するのに有利な地点であるため、スループット・遅延・エラー率といった指標を収集し連携障害を早期に検知し影響範囲を分析できる。ただしこの中央観測の利点はバスが過負荷なく安定して動作するときのみ有効であるため、監視自体がバス性能を削がないよう、サンプリング・非同期ロギングといった設計配慮が併せて必要である。
| 中核機能 | 役割 | 疎結合への寄与 |
|---|---|---|
| アダプタ・プロトコル中継 | 異機種プロトコルの正規化 | プロトコル変化の隔離 |
| ルーティング | 内容ベースの目的地決定 | 送信者・受信者の分離 |
| 変換 | スキーマ/フォーマットのマッピング | 各自のデータモデル維持 |
| オーケストレーション | 複数サービスのフロー組合せ | プロセスロジックの中央化 |
| セキュリティ・監視 | 認証・監査・追跡 | ポリシーの一貫適用 |
4. 比較と事例: EAI/ESB · API Gateway · MOM · マイクロサービス
EAI/ESBをめぐるありがちな混同は「ESB・API Gateway・メッセージキューは皆似た中間層ではないか」という問いである。結論から言えば三つは設計意図と結合モデルが異なる。 ESBは「異機種システムを中央バスで仲介・変換・オーケストレーション」するヘビーウェイト統合に焦点があり、API Gatewayは「外部にAPIを公開し認証・レート制限・ルーティングで保護する」軽量入口に焦点があり、MOM(メッセージ指向ミドルウェア, 例: Kafka・RabbitMQ)は「非同期メッセージの安定した伝達・バッファリング」に特化した伝送基盤である。ESBが変換・オーケストレーションまで含む「知能型バス」なら、Kafkaはそれより薄いがスループット・耐久性で圧倒的な「太いパイプ」である。
三つの手段の結合モデルの違いは、障害が広がる様相にも現れる。ESBは同期呼び出しと中央オーケストレーションの比重が高く、ある受信サービスの遅延がバススレッドを占有し他のフローまで遅くする連鎖遅延が生じやすい。一方Kafkaのようなイベントストリームは発行と消費が分離されているため、受信側が遅くてもメッセージがバッファに積まれるだけで発行側は影響を受けにくい。API Gatewayはその間でレート制限・タイムアウト・サーキットブレーカーにより障害を局所化する。したがって「どの手段がより良いか」は平常時のスループットだけでなく障害時の伝播様相まで併せて見て判断すべきであり、即時性の要らないフローをわざわざ同期ESB呼び出しで束ねて障害脆弱性を高める設計は避けるべきである。
この違いが実務に与える含意は明確である。ESBに過度に多くのビジネスロジックを入れるとバスが巨大なモノリシックボトルネックになり、「ESBアンチパターン」と呼ばれる状況、すなわちすべての変更が中央チームを経なければならない組織的ボトルネックが生じる。実際多くの企業が2010年代半ばにマイクロサービスへ転換しながら、ロジックをバスから取り除き各サービスへ分散し、通信は軽量なAPI・イベントストリームへ置き換えた。これが「Smart endpoints, dumb pipes(賢い端点、間抜けなパイプ)」というマイクロサービスの原則で、変換・オーケストレーションを中央バスではなく各サービスが担うようにする。ある金融会社は全社ESBで数百本の連携を運用していたがリリース周期が四半期単位へ遅くなると、中核フローをAPI Gateway + Kafka基盤へ再編し配備頻度を週単位へ引き上げた。
規模の観点で見れば選択の分岐点は数値で測れる。例えば連携対象が5個前後で変更がまれなら、ポイントツーポイント15本以下のインターフェースでも管理が可能だが、対象が20個へ増え要求が四半期ごとに変わる環境ではポイントツーポイントが理論上190本の接続へ急増し、事実上保守が不可能になる。まさにこの区間で中央連携基盤の初期投資が回収され、統合手段の選定は現在の規模ではなく今後2〜3年の連携増加・変更頻度の見通しに基づくべきである。ある公共機関が対民サービスチャネル(ウェブ・アプリ・コールセンター・窓口)を増やしバックエンド連携が数十本へ膨らむと、チャネル別の重複連携をExperience/Process API層へ再編し新規チャネル追加時の再利用率を70%以上へ引き上げた事例は、この見通しに基づく判断の効果を示す。
とはいえESBが廃棄されたわけではない。数十年もののレガシー、専用プロトコル、複雑なフォーマット変換が絡む環境では、ESBのアダプタ・変換資産が依然最も現実的な解である。要点は「ESBかマイクロサービスか」の二分法ではなく、連携の複雑度と変更頻度に合わせて適正な重みの統合手段を選ぶことである。変換が複雑でレガシーが多ければESBが、変更が頻繁で拡張が重要ならAPI・イベント基盤が有利だ、といった具合の状況適合性が判断基準となるべきである。
5. 深化: 統合アーキテクチャの現代化 — iPaaSとAPI-led・イベント基盤
従来のESBが社内(on-premise)中心だったとすれば、今日の統合の戦場はクラウドとSaaSへ移った。企業が数十のSaaS(セールス・メッセンジャー・会計など)を使いながら、これらを社内システム・クラウドと編む需要が急増し、これを狙ったのがiPaaS(Integration Platform as a Service)である。iPaaSはESBのルーティング・変換・コネクタ機能をクラウドマネージドサービスとして提供し、サーバ設置なしに数百種の事前製作コネクタでSaaS・DB・APIを引き寄せて接続する。MuleSoft Anypoint、Dell Boomi、Microsoft Azure Logic Apps・Integration Services、SAP Integration Suiteなどが代表的で、ノーコード・ローコードで連携フローを構成する点で開発者以外の人員の参加も広げる。
同時に統合の設計思想も変わった。MuleSoftが提示し広く普及したAPI-led Connectivityは、APIをSystem API(レガシー・DBアクセス)・Process API(ビジネスロジック組合せ)・Experience API(チャネル別公開)の3層に分け、再利用可能なAPI資産を積み上げる方式である。これは過去にESBが行っていた仲介・オーケストレーションを「再利用可能なAPIの階層的組立て」として再解釈したもので、中央バスの代わりにAPI管理プラットフォームがガバナンスの中心となる。もう一つの流れはイベント基盤統合で、Kafkaのようなイベントストリーミングを中枢に据えてシステムがイベントを発行・購読し疎に反応する構造である。これは実時間性・拡張性で従来のESBを凌駕し、注文・決済・物流のように即時性が重要な領域で急速に拡散している。
この現代化が実際の数値に現れる地点は配備の俊敏性である。全社ESBにすべての変更が集中していた時代にリリースが四半期単位にとどまっていた組織が、API・イベント基盤へロジックを分散した後、週単位あるいは日単位の配備へ転換する事例が報告される。これは統合層がもはやすべてのチームが共有する単一資源ではなく、各領域チームが独立して所有・変更できる資産へ変わったからである。ただし分散が万能ではなく、連携が数十のサービスへ散らばると全体フローの可視性とデータ整合性の管理がかえって難しくなるため、分散トレーシング(distributed tracing)・スキーマレジストリ・契約テストといった補完装置を併せて備えてこそ現代化の利点が保たれる。
近年は生成AI・LLMが統合層と出会う流れも現れている。自然言語で連携要件を記述するとマッピング・変換ルールの草案を生成したり、エージェントが複数のSaaS APIを組み合わせて業務を遂行するようにしたりする試みがそれである。特にAIエージェントが外部ツール・データと標準的な方式で接続されるようにするプロトコルの議論が活発になるにつれ、「アプリケーション統合」の概念が人が設計した静的連携からエージェントが動的に組み合わせる連携へ拡張される兆しが見える。ただしこの領域は標準・セキュリティ・信頼性がなお確立中であるため、技術士の観点では「方向性は明確だが適用には慎重な検証が必要な段階」と理解するのが適切である。
整理すると統合アーキテクチャはポイントツーポイント → ハブ&スポークEAI → ESB → API管理・iPaaS・イベント基盤へ進化してきており、これは技術の置き換えというより「中央集中の仲介」から「分散・再利用・実時間」へ重心が移る連続的変遷である。企業は通常これらの段階が共存するハイブリッド状態にあるため、現代化は断絶的な転換ではなく、ストラングラー(strangler)パターンのようにレガシー連携を漸進的に新方式へ置き換えていく戦略が現実的である。
6. 考慮事項および示唆点
第一に、適正な重み(right-weight)の統合手段の選択が核心である。 ESB・iPaaS・API Gateway・イベントストリームは競合財ではなく、状況別の最適解が異なる補完財である。レガシー・複雑変換が多ければESB/iPaaSのアダプタ・変換資産が、外部API公開・保護が重要ならAPI Gatewayが、実時間・高拡張が重要ならイベントストリームが有利である。技術士は「流行のアーキテクチャ」ではなく連携の複雑度・変更頻度・実時間性要求を定量的に評価して手段を組み合わせるべきである。
第二に、中央集中のトレードオフを警戒すべきである。 中央バスはガバナンス・可視性で有利だが、過度なロジック集中は性能ボトルネック・単一障害点・組織的ボトルネック(すべての変更が中央チームを経由)を生む。「Smart endpoints, dumb pipes」の原則に従いビジネスロジックは可能な限り端点サービスへ分散し、バスは仲介・伝達という本来の役割に集中させるのが持続可能である。併せて中央要素には必ず多重化・障害隔離(サーキットブレーカー・バルクヘッド)を設計すべきである。
第三に、共通データモデルと連携ガバナンスに投資すべきである。 統合の実際のコストの大半はスキーマ変換と意味の不一致から生じるため、標準共通フォーマット(canonical model)・データ辞書・連携カタログを先制的に整備してこそn×nの複雑度をn×1へ下げられる。またどのデータがどこへ流れるかについてのデータ系譜(lineage)・監査追跡を統合層で確保し、個人情報・規制遵守と障害影響度分析を可能にすべきである。
第四に、漸進的な現代化戦略を取るべきである。 大規模なEAI/ESBは数百本の連携が絡んでおり一括置き換え(big-bang)はリスクが大きい。ストラングラーパターンで価値が高く変更が頻繁なフローからAPI・イベント基盤へ移管し、レガシー専用連携は安定して保ち共存させるハイブリッドアプローチが現実的である。この過程で連携資産の可視化(インベントリ)・テスト自動化・漸進的トラフィック切替(カナリア)がリスクを管理する中核ツールとなる。
第五に、セキュリティ・信頼性を統合層の一級要求として扱うべきである。 統合地点は全社データが集まる通り道であるため、認証・認可・暗号化・レート制限・冪等性(idempotency)の保証が必須である。特に非同期・イベント基盤では重複伝達・順序逆転・部分障害に備えた再処理・補償トランザクション(サガ)の設計がデータ整合性を守る鍵である。
第六に、組織と運用モデルも併せて設計すべきである。 中央統合チームがすべての連携を所有すると組織的ボトルネックになり、各領域チームに全面的に任せると標準が崩れやすい。プラットフォームエンジニアリングの観点で、中央はコネクタ・共通フォーマット・セキュリティポリシーといった「セルフサービス統合プラットフォーム」を提供し、実際の連携構成と変更は領域チームが遂行する連合型(federated)ガバナンスが現代統合の目指す先である。技術だけ現代化し組織モデルをそのままにすると、アーキテクチャは分散されても変更速度は依然中央に縛られる逆説が生じる。
参考資料
- Martin Fowler, "Microservices" — Smart endpoints and dumb pipes: https://martinfowler.com/articles/microservices.html
- MuleSoft, "What is API-led connectivity?": https://www.mulesoft.com/resources/api/what-is-api-led-connectivity
- Gartner, "Integration Platform as a Service (iPaaS)" 用語説明: https://www.gartner.com/en/information-technology/glossary/information-platform-as-a-service-ipaas
- Enterprise Integration Patterns (Hohpe & Woolf): https://www.enterpriseintegrationpatterns.com/
一言まとめ: EAIは異機種システムを中央連携基盤で束ねポイントツーポイントのスパゲッティを線形構造へ変える統合戦略であり、ESBはそのSOA式実装(バス型の仲介・変換・オーケストレーション)であって、今日の統合の重心は中央バスからAPI管理・iPaaS・イベント基盤へ移り、「適正な重みの手段を状況に合わせて組み合わせ漸進的に現代化する」ことが技術士の観点の核心である。