KDOT

ビジネスサイドのための IT 用語集/システム構成

SOAとは

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

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

SOA

SOAとは

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

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

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

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

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

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

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

いまの位置づけ

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

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

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

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

  • 機能を決まった形式で外から呼び出せるようにする部分は、Webの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という言葉は意味が広すぎるため、別の名前で区別して呼ばれています。

判断の問い

既存システムの連携基盤が保守終了を迎える。作り替えるべきか？

保守終了を理由にすべてを一度に作り替える必要はありません。まず連携を棚卸しし、変更の頻度と変更できる人の数で残し方を決定します。自社に連携基盤があるかは保守契約の一覧に連携製品の保守が含まれているかで分かります。分からなければ保守を委託している会社に、システム間のデータが何を経由して受け渡されているかを質問します。

つないでいるシステムが数個で連携の変更が年に数回程度なら、後継の製品やクラウド型の連携サービスへ移行するだけで十分です。作り替えの効果がその費用を上回るとは限らないためです。クラウド型の連携サービスも連携を中央に置く点は同じです。問題は中央に置くこと自体ではなく、業務ルールや変換処理が中央に集中し、変更のたびにそこを経由する必要が生じることにあります。連携が少なく変更も少ないうちは、この問題は発覚しにくいです。

作り替えを検討すべきなのは、目安として小さな連携の変更に数週間かかっている場合や、連携を扱える人が社内外で1〜2人に限られている場合です。この状態を放置すると次の保守期限でも同じ問題が発生します。変更回数の多い連携から順に、各システムがAPIで直接やり取りする形へ移行していきます。業務ルールは中央ではなく各システムの側に持たせます。移行先は今の各システムのままでよく、マイクロサービスに分け直す必要はありません。機能をサービスとして呼び出す考え方は残るため、これもSOAの考え方から外れるわけではありません。

棚卸しでは連携ごとに次を一覧にします。

  • つないでいるシステムと、連携の中に記述された業務ルール
  • 年間の変更回数と1回の変更にかかった期間
  • 変更できる担当者とベンダー
  • 製品の年間費用と残りの保守期間

既存の連携基盤はSOAという言葉が使われているかではなく、連携の変更に何週間かかり誰の作業が必要かで評価します。残すべき連携はAPIとして整備し直し、作り替えは保守期限や業務の変化に合わせて段階的に進めます。

提案書にSOAとある。何を確認すればよいか？

SOAという言葉よりシステム同士をどうつなぐ構成かを確認します。中央に大きな連携製品を置く構成か、各システムがAPIで直接やり取りする構成かで、導入後の費用と変更の手間が大きく変化します。

中央に連携製品を置く構成なら次の3点を提案側に示してもらいます。連携を1つ変更するときに誰がどれくらいの期間で作業するのか、製品の年間費用と保守期限はいつまでか、その製品を扱える技術者を社内で育成できるかです。

iPaaS（Integration Platform as a Service）と呼ばれるクラウド型の連携サービスを利用する提案も、連携を中央に集約する点では同じ構成です。変更を誰が担うかを同じ基準で確認します。

公開日
2026.10.21
更新日
2026.10.21

お問合せ

事業の課題や技術的な悩みなどどんなことでもお聞かせください

お問合せ