KDOTハンドブックお問合せ

システム構成

SOAとは

えすおーえー / サービス指向アーキテクチャ / Service-Oriented Architecture

業務の機能を他のシステムから呼び出せるサービスとして切り出し、組み合わせて全社のシステムを構築する設計の考え方です。ESBと呼ばれる連携製品を中央に配置する構成は変更のたびに中央の作業が必要になる問題を抱え、考え方はAPIに引き継がれました。既存の連携基盤は変更にかかる期間と担い手で評価します。

公開
2026.10.21
更新
2026.10.22
SOA

SOAとは

SOA（Service-Oriented Architecture）はサービス指向アーキテクチャと訳されます。受注、在庫照会、顧客情報の取得といった業務の機能を、他のシステムから決まった形式で呼び出せるサービスとして切り出し、それらを組み合わせてシステム全体を構築する考え方です。

API（Application Programming Interface）は1つの機能の呼び出し口を指します。SOAはそれと異なり、全社のシステムをどの単位のサービスに分割し、どうつなぐかという全体の設計を指します。

何を解決するために生まれたか

1990年代までの企業システムは販売、会計、生産、人事といった業務ごとに別のシステムとして構築されていました。1990年代後半にはEAI（Enterprise Application Integration）と呼ばれるハブ型の連携製品も登場しましたが、多くのシステムは個別の連携プログラムでつながれていました。

この作り方には次の困りごとがありました。

  • システムが増えるほど連携の数が掛け算で増え、どこがどこにつながっているか誰も把握できなくなる
  • 同じ顧客情報や商品情報を各システムが別々に保持し、たとえば住所を変更したシステムと変更していないシステムで内容が一致しなくなる
  • 1つのシステムを変更すると、つながっている先の連携プログラムをすべて修正する必要がある
  • 新しい業務を開始するたびに既存システムの機能を再利用できず、一から開発する

SOAはこれに対し業務の機能をサービスとして公開し、共通の約束事で呼び出す形にそろえました。狙いは機能の再利用と組み替えをしやすくすることでした。

5つのシステムが個別の連携で接続する網と、1本の共通の連携基盤に集約した構成の比較

いまの位置づけ

SOAは2000年代半ばに大企業のIT刷新の名目として普及し、日本でも大手ベンダーがSOAを掲げた製品や提案を発表しました。

実際の導入ではESB（Enterprise Service Bus）と呼ばれる連携製品を中央に置き、各システムをそこにつなぐ構成が主流になりました。ESBは各システムの間に置いて、データの変換と受け渡しをまとめて行う中継の製品で、EAIの考え方を標準技術で発展させたものと位置づけられます。社内資料ではESBという語より、製品名や、連携基盤、ハブといった呼び方で記載されていることが多いです。

ESBを中心にした結果として連携の処理や業務ルールがESBに集中し、変更のたびに中央のチームを経由する必要が生じました。数年がかりで成果の見えない計画も目立ち、2009年にはSOAは終わったという論調も出ました。

一方で考え方は廃れておらず、次のように形を変えて受け継がれています。

  • 機能を決まった形式で外から呼び出せるようにする部分は、WebのAPIとして一般化した
  • サービスを小さく分割し、それぞれを独立して変更・リリースする方向は、マイクロサービスとして発展した

EAI・SOAとESB・API・マイクロサービスへと連携の考え方が継承されてきた順序

マイクロサービスは中継の仕組みを単純な受け渡しにとどめ、変換や業務ルールといった処理は各サービスに持たせます。SOAとの大きな違いはこの点にあります。

SOA型の基盤を持ち続ける効果とコスト・リスク

2000年代から2010年代前半に構築した基幹システムにはSOAの考え方やESB製品を使った連携基盤が残っていることがよくあります。主な効果とコスト・リスクは次のとおりです。

今ある効果

  • システム間の連携が1か所に集約されており、どのシステムが何を呼び出しているかを把握しやすい
  • 顧客や商品といった共通の情報を、サービス経由で1つの出どころから参照できている場合がある
  • 新しいシステムを追加するとき、既存のサービスを呼び出すだけで済む範囲がある

抱えているコストとリスク

  • ESB製品のライセンスと保守契約の費用が毎年かかる。商用製品では規模によるが目安として年間で数百万円から数千万円規模が多く、製品のサポート終了が刷新のきっかけになる
  • 連携の変更にはESBを扱える限られた担当者やベンダーの作業が必要で、小さな変更でも数週間かかることがある
  • 連携の中に業務ルールが埋め込まれ、仕様が文書に残っていない
  • 当時主流だったSOAPなどのXML（Extensible Markup Language）ベースの連携形式は、対応するクラウドサービスや扱える技術者が減少しており、変換や改修の手間が増加している。SOAPは当初Simple Object Access Protocolの略だったが、現行の1.2では略語として扱わない

よくある誤解

SOAはESBという製品を導入すること

SOAは設計の考え方で、ESBはその実現手段の1つにすぎません。ESBを導入せずにAPIでサービスをつなぐ形もSOAの考え方に沿っています。

SOAは失敗した考え方なので関係する仕組みはすべて捨てるべき

うまくいかなかった多くは中央の製品に何でも集める進め方でした。機能をサービスとして切り出して再利用するという考え方は、APIやマイクロサービスに生きています。稼働している連携まで一度に廃止すると、埋め込まれた業務ルールを失うおそれがあります。

マイクロサービスはSOAと無関係の新しい発明

マイクロサービスはESBを中心にしたSOAへの反省から生まれた面があります。マイクロサービスをSOAの一形態と見る立場もありますが、SOAという言葉は意味が広すぎるため、別の名前で区別して呼ばれています。