◀ 10.

SaaS と現代のサービス指向

▶

編集

この記事の要点

Web サービスはネットワーク経由で機能を提供するソフトウェアの総称
広義: SaaS (Stripe / Slack / GitHub) / 狭義: SOAP / REST など API で機能提供するもの
クラウド階層: SaaS (利用) / PaaS (実行環境) / IaaS (仮想インフラ)
アーキテクチャ進化: SOA (2000s) → マイクロサービス (2010s) → Service Mesh (2020s)
代表的な API エコノミー: 決済 (Stripe) / SMS (Twilio) / メール (SendGrid) / 認証 (Auth0)
統合パターン (EIP): メッセージング / パブリッシュサブスクライブ / イベント駆動

Web サービスの定義

Web サービスは文脈によって 2 つの意味があります:

広義: ブラウザや API から利用できるネットワーク経由のソフトウェア全般（Gmail、Slack、GitHub、Stripe など）
狭義（W3C 定義）: ネットワーク経由で機械同士が相互運用する仕組み。SOAP / WSDL / UDDI の三点セットを指す古典的定義

現代では広義の意味で使われることがほとんどです。「Web サービスを開発する」と言えば、ブラウザ・モバイル・API クライアントが叩く SaaS 型アプリケーションのことを指すのが一般的です。

クラウドサービスの階層: SaaS / PaaS / IaaS

層	意味	例	利用者
SaaS	完成済みソフトを利用	Gmail / Salesforce / Slack / Notion	エンドユーザー
PaaS	アプリ実行環境	Heroku / Vercel / Google App Engine	開発者
IaaS	仮想インフラ	AWS EC2 / GCP Compute Engine / Azure VM	インフラ担当
FaaS	関数単位の実行	AWS Lambda / Cloud Functions	開発者
BaaS	バックエンド機能	Firebase / Supabase / Amplify	フロント開発者

SOAP vs REST — Web サービスの 2 大方式

項目	SOAP	REST
プロトコル	HTTP / SMTP / TCP	HTTP のみ
データ形式	XML 必須	JSON 主流（XML も可）
仕様記述	WSDL	OpenAPI (Swagger)
トランザクション	WS-* 群で対応	独自実装
学習コスト	高い	低い
用途	金融・大企業基幹	Web / モバイル / 公開 API

SOAP メッセージの例

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header/>
  <soap:Body>
    <m:GetUser xmlns:m="http://example.com/users">
      <m:UserId>123</m:UserId>
    </m:GetUser>
  </soap:Body>
</soap:Envelope>

<!-- レスポンス -->
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <m:GetUserResponse xmlns:m="http://example.com/users">
      <m:User>
        <m:Id>123</m:Id>
        <m:Name>Taro</m:Name>
      </m:User>
    </m:GetUserResponse>
  </soap:Body>
</soap:Envelope>

API エコノミー — 機能を API で売る

2010 年代以降、特定機能を API で提供する SaaS が爆発的に成長しました。代表例:

サービス	機能	料金モデル
Stripe	クレジットカード決済	取引額の 3.6%（日本の標準料金、2026-10 時点）
Twilio	SMS / 音声通話 API	従量課金（メッセージ毎）
SendGrid	メール送信	月間メール数
Auth0	認証・認可	月間アクティブユーザー数
Algolia	全文検索	レコード数 + 検索数
Cloudinary	画像変換・配信	転送量 + 変換数

アーキテクチャの進化: モノリス → SOA → マイクロサービス → Service Mesh

世代	時期	特徴
モノリス	〜2000s	1 つの大きなアプリ。デプロイは一括
SOA (Service Oriented Architecture)	2000s	業務単位でサービス分割、ESB でつなぐ
マイクロサービス	2010s	細かく分割、各チームが独立デプロイ
Service Mesh	2020s	Istio / Linkerd でサービス間通信を統制

マイクロサービス間通信の例

# Kubernetes 上のマイクロサービス構成例
services:
  user-service:    # ユーザー管理
    api: REST
    db: PostgreSQL

  order-service:   # 注文処理
    api: gRPC
    db: PostgreSQL
    depends_on: [user-service, payment-service]

  payment-service: # 決済
    api: REST
    external: Stripe API

  notification-service: # 通知
    api: イベント駆動
    queue: RabbitMQ / Kafka
    depends_on: [order-service]

# Service Mesh (Istio) でこれらの間通信を:
# - mTLS で暗号化
# - リトライ・サーキットブレーカー
# - 分散トレーシング (Jaeger)
# - メトリクス (Prometheus)

エンタープライズ統合パターン (EIP)

Gregor Hohpe の書籍で体系化された、分散システム間でメッセージをやり取りするためのデザインパターン群:

Message Channel: キューやトピックでメッセージを送る経路
Publish-Subscribe: 1 つのイベントを複数の購読者に配信
Content-Based Router: メッセージ内容で配送先を決定
Message Translator: フォーマット変換（XML→JSON 等）
Dead Letter Channel: 処理失敗メッセージの退避先
Saga パターン: 複数サービスにまたがるトランザクション

FAQ

Q: SOAP は今でも使われている？
A: 銀行・保険・政府系の基幹システムでは現役。新規開発では REST / gRPC が主流です。

Q: SaaS とパッケージソフトの違いは？
A: SaaS は提供者が運用、月額・年額課金、自動アップデート。パッケージは買い切りで自社運用。

Q: マイクロサービスにすればスケールする？
A: 万能ではありません。分割の境界設計・運用コスト（監視・トレース）・データ整合性の難しさが付いてきます。小〜中規模ではモジュラーモノリスが推奨されることも。

ページ一覧

その他