SOA（サービス指向アーキテクチャ）（Service Oriented Architecture）
業務上の機能をサービスという部品にし、組み合わせてシステムを作る考え方。部品を他でも使い回せる。
もう少し詳しい説明
SOA（Service Oriented Architecture、サービス指向アーキテクチャ）は、業務上の機能を「サービス」という部品にし、組み合わせてシステムを作る考え方です。
どこで切るか
部品に分けること自体は、昔から行われてきました。SOAが新しかったのは、切る位置です。
| 切り方 | 例 | |
|---|---|---|
| 従来の部品化 | 技術の都合で切る | 日付を変換する関数、ファイルを読む関数 |
| SOA | 業務の意味で切る | 与信を確認する、在庫を引き当てる |
ここで出した2つは、通販や卸売の現場で使われている言葉です。中身はこうなっています。
| 言葉 | 何をすることか |
|---|---|
| 与信を確認する | 代金をあとから払ってもらってよい相手かを調べること。通販で「後払い」を選んだとき、これまでの支払いが滞っていないか、今回の金額がその人に認めている上限を超えていないかを見ます。「与信」は信用を与えると書きます |
| 在庫を引き当てる | 倉庫にある品物を、その注文のぶんとして取り置くこと。押さえておかないと、同じ1個を2人に売ってしまいます |
どちらも、その仕事をしている人なら説明なしで通じる言葉です。 「日付を変換する」や「ファイルを読む」とは、言葉の出どころが違います。
ここが肝心なところです。業務の言葉で切ってあれば、業務が変わったときに、どの部品を直せばよいかが分かります。「後払いの上限を変える」と言われたら、直すのは「与信を確認する」です。技術の都合で切ってあると、業務の変更がどこに当たるのか追えません。
サービスの条件
ここでいう「サービス」は、業務そのものではありません。 業務は人がする仕事のことで、サービスはその仕事の1つぶんを引き受ける、呼び出せるプログラムを指します。
| 何を指すか | 例 | |
|---|---|---|
| 業務 | 会社の中でしている仕事 | 注文を受けて、後払いでよいか判断して、品物を押さえて、出荷する |
| サービス（SOAでいう） | その仕事の1区切りを引き受けるプログラムの部品 | 「与信を確認する」を担当するプログラム |
業務を区切って、1区切りずつプログラムの部品にしたものがサービスです。区切り方が業務に沿っているので、名前も業務の言葉になります。
そのサービスが満たすべき条件は4つです。
| 条件 | 中身 |
|---|---|
| 独立している | 単体で動く。ほかのサービスの中身を知らない |
| 窓口が決まっている | 呼び方（どんな名前で、何を渡すと、何が返ってくるか）が公開されている。中の作りは見せない |
| 業務の単位 | 業務上の意味を持つまとまり |
| 使い回せる | ほかのシステムからも同じように呼べる |
この「窓口」は、プログラムの呼び出し口のことです。自動販売機にたとえると、お金を入れてボタンを押せば品物が出てくる、という決まったやりとりの形が窓口です。中でどう冷やしているか、どう取り出しているかは、買う側には見えませんし、知る必要もありません。
中の作りを見せないことが、使い回しの条件です。中身に合わせて呼び出す側を作ると、中身を変えたときに呼び出す側も直すことになります。
どこが利点なのか
| 中身 | |
|---|---|
| 作り直しが減る | 「与信を確認する」を各システムで作らなくてよい |
| 変えやすい | 業務が変わったとき、そのサービスだけ直す |
| 組み替えやすい | 新しい業務を、既存のサービスの組合せで作れる |
| 作り方を問わない | 窓口さえ合っていれば、中は何で作ってもよい |
最後の1つが、実務では大きいところです。 古い言語で動いている仕組みも、窓口をかぶせればサービスとして使えます。
「窓口をかぶせる」は、古い仕組みを書き直すのではなく、その手前に小さなプログラムを1つ置くことです。この小さなプログラムが、決まった呼び方で注文を受け取り、古い仕組みに合わせた形に直して渡し、返ってきたものを決まった形に整えて返します。受付の人を1人立てるようなもので、建物の中は何も変えません。
こうすると、全部を作り直さずに、新しい仕組みから呼べます。 何十年も動いている仕組みを止められない、という場面で効きます。
何でつなぐのか
サービスどうしをつなぐ手段は、SOAそのものとは別の話です。
| 時期 | 使われたもの |
|---|---|
| 2000年代 | SOAP・WSDL・UDDI、ESB（サービスをつなぐ中継役） |
| いま | REST（Web API）が中心 |
SOAは考え方で、SOAPは規約です。 名前が似ていますが、別の層の話になります。SOAを実現するのにSOAPを使わなければならない、ということはありません。
マイクロサービスとの関係
よく並べて問われます。考え方は地続きです。
| 部品の大きさ | つなぎ方 | データ | |
|---|---|---|---|
| SOA | 業務単位（やや大きい） | ESBのような中継役を置くことが多い | 共有することもある |
| マイクロサービス | もっと小さい | 軽い仕組み（HTTP）で直接 | サービスごとに持つ |
マイクロサービスは、SOAをさらに細かく、軽くした形と考えると、理解しやすくなります。
中継役を置くと、そこに機能が集まって、かえって変えにくくなることがありました。マイクロサービスは中継役を薄くし、サービスごとにデータまで分けます。
うまくいかないとき
考え方としては筋が通っていますが、導入が難しいとも言われます。
| 問題 | 中身 |
|---|---|
| 切り方が決まらない | どこまでを1つのサービスにするか、業務を理解していないと決まらない |
| つなぎ目が増える | ネットワーク越しの呼び出しが増え、遅くなる |
| 全体が見えにくい | どのサービスがどれを呼んでいるのか追いにくい |
1つめが本体です。 技術の問題ではなく、業務をどう切るかという設計の問題になります。
試験ではこう出る
科目A（旧・午前）では、SOAの説明がそのまま問われます。「業務上の機能をサービスとして独立させ、組み合わせる」が答えです。
SOAPとの区別も出ます。SOAは考え方、SOAPはメッセージの規約です。
マイクロサービスとの比較も、近年の出題で扱われます。粒度の細かさとデータの持ち方が軸です。
応用情報では、既存システムを活かす方法として出ます。作り直さずに窓口をかぶせて使う、という点です。
関連する用語
- CORBA・DCOM・SOAP
- サービスどうしをつなぐ決まりごと。SOAを実現する手段のひとつ
- クライアントサーバシステム
- どこに処理を置くかの話。SOAは機能をどう切るかの話
- SaaS・PaaS・IaaS
- サービスとして使う形。SOAの考え方が外部提供まで広がったもの
- BPR
- 業務の手順を作り直す。SOAは変えやすい作りで、それを支える
ミニクイズ
SOA（サービス指向アーキテクチャ）の説明として、適切なものはどれか。
正解は 3番：業務上の機能をサービスという部品として独立させ、組み合わせてシステムを構築する
SOAは、業務上の意味を持つ単位で機能をサービスとして独立させ、それらを組み合わせてシステムを作る考え方です。サービスは決められた窓口を通じて呼び出され、中の作りは外から見えません。クライアントとサーバの2層に分けるのはクライアントサーバシステムで、処理をどこに置くかの話です。上流から下流へ順に進めるのはウォータフォールモデルという開発の進め方、データを表の形で持つのは関係データベースで、どれもSOAとは別の話です。
この分野をまとめて解く → システム構成要素とソフトウェアのミニテスト（全28問）
最終更新：2026-10-20