最終更新日:2026年7月18日
fe fe-technology system-architecture soa
まず結論
SOA(Service-Oriented Architecture:サービス指向アーキテクチャ)は、ソフトウェアの機能を独立したサービスとして分け、それらを組み合わせてシステムを構築する設計思想です。
ソフトウェア機能をサービス化する
+
必要なサービスを組み合わせる
↓
一つのシステムを構築する
基本情報技術者試験では、次の一文を判断軸にします。
機能をサービスという部品に分け、組み合わせてシステムを作るならSOA。
似た略語は、対象を見ると切り分けやすくなります。
営業活動をITで支援
→ SFA
業務を外部へ委託
→ BPO
業務プロセスを抜本的に再設計
→ BPR
ソフトウェア機能をサービス化
→ SOA
直感的な説明
SOAは、機械を機能別のユニットで構成するイメージに近い考え方です。
搬送ユニット
+
位置決めユニット
+
検査ユニット
↓
一つの生産設備
各ユニットが独立していれば、検査ユニットだけを交換したり、別の設備で再利用したりできます。
SOAでも同じように、業務機能を独立したサービスとして用意します。
例えば、オンラインショップなら次のように分けられます。
商品検索サービス
+
在庫確認サービス
+
注文登録サービス
+
決済サービス
+
配送サービス
↓
オンラインショップ
一つの巨大なプログラムとして作るのではなく、役割ごとのサービスを連携させます。
定義・仕組み
SOAにおけるサービス
ここでいうサービスは、接客サービスという意味ではありません。
SOAのサービスは、特定の業務機能を提供する独立したソフトウェア部品です。
例えば、次のような機能がサービスになります。
- 顧客情報を取得する
- 注文を登録する
- 在庫数を確認する
- 支払いを処理する
- 配送状況を取得する
利用側は、サービスが内部でどのように処理しているかを詳しく知らなくても、決められたインターフェースを通じて利用できます。
利用側
↓ 共通インターフェース
サービス
↓
必要な処理を実行
疎結合
SOAでは、サービス同士の依存関係を小さくすることが重視されます。
これを疎結合といいます。
サービスAを変更
↓
サービスBへの影響を抑える
サービスの入出力や呼び出し方法が明確であれば、内部の実装を変更しても、他のサービスへの影響を小さくできます。
再利用
一度作成したサービスを、複数のシステムで利用できることもSOAの特徴です。
顧客情報サービス
├─ 営業支援システムで利用
├─ 問合せ管理システムで利用
└─ ECサイトで利用
同じ機能をシステムごとに作り直す必要が減るため、開発効率や保守性の向上が期待できます。
主なメリット
SOAには、次のようなメリットがあります。
- サービスを個別に開発・変更しやすい
- 既存機能を再利用しやすい
- 必要なサービスを組み替えやすい
- 異なるシステムを連携しやすい
- 特定の言語やプラットフォームへの依存を減らしやすい
ただし、サービスが増えすぎると、通信管理や障害箇所の特定が複雑になる点には注意が必要です。
科目Aでどう出る?
科目Aでは、SOAと別の略語を並べ、説明に合うものを選ばせる問題が出ます。
4用語の比較
| 用語 | 何をする? | 判断の合図 |
|---|---|---|
| SOA | サービスを組み合わせてシステムを作る | 独立機能、再利用、疎結合 |
| SFA | 営業活動をITで支援する | 商談、営業、顧客管理 |
| BPO | 業務を外部へ委託する | 外部委託、業務プロセス |
| BPR | 業務プロセスを抜本的に見直す | 再設計、改革、抜本的 |
選択肢の読み方
営業活動の効率や品質を高める
→ SFA
コア業務以外を外部へ委託する
→ BPO
コスト・品質・サービス・スピードを
抜本的に改善する
→ BPR
機能をサービスとみなし、
組み合わせてシステムを構築する
→ SOA
SOAを示すキーワード
次の語が複数含まれていれば、SOAを疑います。
- サービス
- 独立した機能
- 組み合わせる
- 再利用
- 疎結合
- 共通インターフェース
- システム連携
「サービス」という語だけで決めず、ソフトウェア機能を部品として扱っているかを確認します。
どんな場面で使う?
複数システムで共通機能を使う
顧客情報、認証、決済などを複数のシステムで共通利用したい場合に向いています。
共通機能をサービスとして一つ用意
↓
複数システムから利用
既存システムを連携する
部門ごとに別々に作られたシステムを連携させる場合にも使われます。
販売システム
+
在庫システム
+
会計システム
↓
サービスを介して連携
機能を段階的に追加・交換する
サービス単位で分かれていれば、一部の機能だけを追加・交換しやすくなります。
旧決済サービス
↓ 交換
新決済サービス
システム全体を作り直さずに変更できる可能性が高まります。
よくある誤解・混同
SOAとSFAは同じ種類の用語
誤りです。
SOA
→ システムの設計思想
SFA
→ 営業活動を支援する仕組み
略語は似ていますが、対象が異なります。
SOAとBPOはどちらもサービスを外部へ任せる
誤りです。
SOAの「サービス」は、ソフトウェア機能の単位です。
BPOは、業務プロセスを外部の専門業者へ委託することです。
SOA
→ ソフトウェア機能をサービス化
BPO
→ 業務を外部へ委託
BPOについては、BPOとは?SaaS・ホスティングとの違いで詳しく整理しています。
SOAとBPRはどちらもシステムを作り直す考え方
対象が違います。
SOA
→ ソフトウェアの構造を考える
BPR
→ 業務プロセスを抜本的に見直す
BPRを行った結果、新しい業務を支える仕組みとしてSOAを採用することはありますが、同じ概念ではありません。
SOAとSaaSは同じ
誤りです。
SOA
→ システムをどのように構成するかという設計思想
SaaS
→ ソフトウェアをネット経由で利用する提供形態
SaaSは利用者から見た提供方法、SOAは開発・設計側の構成の考え方です。
SOAなら必ずWebサービスを使う
SOAは設計思想であり、特定の技術だけに限定されません。
WebサービスやAPIは、SOAを実現するために使われる代表的な手段ですが、SOAそのものと同義ではありません。
SOA
→ 考え方
Webサービス・API
→ 実現手段の例
サービスを細かく分けるほどよい
必ずしもそうではありません。
細かく分けすぎると、サービス間の通信回数や管理対象が増え、全体が複雑になることがあります。
業務上まとまりのある機能単位で分割することが大切です。
まとめ(試験直前用)
- SOAは、ソフトウェア機能を独立したサービスとして分ける設計思想
- 必要なサービスを組み合わせてシステムを構築する
- 疎結合により、変更の影響を小さくしやすい
- サービスは複数のシステムで再利用できる
- 営業活動をITで支援するのはSFA
- 業務を外部へ委託するのはBPO
- 業務プロセスを抜本的に再設計するのはBPR
- SaaSはソフトウェアの提供形態であり、SOAとは異なる
- WebサービスやAPIはSOAの実現手段になり得る
営業ならSFA、外注ならBPO、業務改革ならBPR、サービスを組み合わせる設計ならSOA。