レッスン7：iPaaS・API 連携と SaaS Ops

このレッスンで学ぶこと

iPaaS 3 大選択肢（Zapier・Workato・Boomi）と MuleSoft・n8n の位置づけを持てる
API 連携の設計原則（データ整合性・冪等性）を持つ
SaaS Ops（ライセンス最適化・利用モニタリング）の型を組み立てられる
SaaS 棚卸ツール（Zylo・Torii・Josys）の使い分けを扱える

前レッスンでは社内浸透とチェンジマネジメントを扱いました。本レッスンでは、単独 SaaS の運用から一歩進んで、複数 SaaS を繋いで価値を跳ねさせる iPaaS・API 連携と、常時運用としての SaaS Ops を扱います。「SaaS は繋いで価値が跳ねる——iPaaS で点から線へ」が本レッスンの中核メッセージです。

なぜ SaaS を繋ぐ必要があるか

企業が導入している SaaS の数は、平均的な中堅企業で 30〜 100 個、大企業では 200〜 500 個と言われています（Zylo「SaaS Management Report 2024」の業界統計）。これらの SaaS が別々に運用されると、次の問題が発生します。

データの分断：同じ顧客・従業員・案件データが複数 SaaS に別々に存在
二重入力：営業が受注管理 SaaS に入力し、経理が会計 SaaS に再入力
ミスと遅延：手作業のコピー・ペーストによるミスと処理遅延
意思決定の遅れ：複数 SaaS のデータを集約するのに時間がかかる

SaaS を API または iPaaS で繋ぐことで、これらの問題が解消し、業務の生産性が跳ねます。

API 連携の 2 パターン

SaaS 同士を繋ぐには、次の 2 パターンがあります。

パターン 1：ポイント・ツー・ポイント連携

SaaS A と SaaS B を直接 API で繋ぐ
連携数が少ない場合はシンプル
SaaS 数が増えると連携数が n×(n−1)/2 の組み合わせ的に増え、管理が破綻する

パターン 2：iPaaS を経由するハブ連携

全 SaaS を iPaaS（Integration Platform as a Service）に繋ぐ
iPaaS が各 SaaS 間のデータ変換とルーティングを担う
SaaS が増えても管理コストが線形的にしか増えない

中堅企業以上では、iPaaS を経由するハブ連携が実務標準になっています。

iPaaS 3 大選択肢と位置づけ

主要な iPaaS プラットフォームは次のとおりです。

Zapier（ザピアー）

2011 年設立、小規模〜中堅企業向けの代表的 iPaaS
6,000 種類以上の SaaS に対応
ノーコードで連携フロー（Zap）を作成
個人・小規模チーム利用に最適
大規模データ連携やエンタープライズ用途では機能不足

Workato（ワーカート）

2013 年設立、中堅〜大企業向けの iPaaS
Zapier より複雑な連携ロジックに対応
業務プロセス自動化（Recipe と呼ぶ）が強力
エンタープライズ機能（監査ログ・ガバナンス）が充実

Boomi（ブーミー）

2000 年設立、2010 年 Dell が買収、2021 年に独立
大企業向けのエンタープライズ iPaaS
複雑なデータ変換・多システム連携に強い
SAP・Oracle・Salesforce との連携実績が豊富

そのほかの選択肢

MuleSoft（ミュールソフト）：2006 年設立、2018 年 Salesforce が買収。Anypoint Platform として提供、API 管理と iPaaS の統合基盤
n8n（エヌエイトエヌ）：2019 年公開のオープンソース iPaaS。セルフホスト可能、コストを抑えたい会社に人気

選定の 3 軸

対応 SaaS 数（自社が導入している SaaS がカバーされているか）
複雑な連携ロジックの必要性（分岐・繰り返し・変換）
予算（Zapier は個人向け無料プラン〜、Workato・Boomi は年間 100 万円〜 1,000 万円規模）

API 連携の設計原則

iPaaS を使う場合も、直接 API を使う場合も、次の設計原則を守ります。

原則 1：データ整合性

どちらのシステムが「マスタ」かを明確にする
マスタが更新されたら、他システムに反映される
両方向で同時更新が起きた場合の衝突ルールを事前に定義

原則 2：冪等性

同じ処理を何度実行しても結果が同じ状態に収束するように設計
障害復旧時に再実行しても、二重登録が起きないようにする
リトライ処理が安全に行える構造

原則 3：エラーハンドリング

API 通信失敗時のリトライ設計（回数・間隔）
リトライしても失敗した場合のアラート通知
手動介入が必要な場合のエスカレーションフロー

原則 4：監査ログ

全連携イベントの記録
データ変更の追跡可能性
監査対応・障害調査への活用

SaaS Ops——常時運用としてのライセンス最適化

SaaS Ops（SaaS Operations）は、複数 SaaS を常時運用する新しい役割です。従来の情シスがハードウェア・ネットワークを運用してきたのと同じように、SaaS を継続的に管理する専門職として広がっています。

SaaS Ops の主要業務

ライセンス台帳管理：全 SaaS のライセンス数・利用状況・契約更新期日を一元管理
ライセンス最適化：未使用ライセンスの削減、ダウングレード可能ユーザーの検出
契約更新交渉：契約更新時のディスカウント交渉・プラン見直し
シャドー IT 検出：会社が把握していない SaaS 契約の発見（従業員が個人で契約したもの）
セキュリティモニタリング：SaaS のセキュリティイベント監視・改正個情法対応

ライセンス最適化の 3 パターン

未使用ライセンス削減：90 日以上ログインしていないユーザーのライセンス回収
ダウングレード：Pro プランの機能を使っていないユーザーを Basic プランへ変更
プラン最適化：契約更新時に、実際の利用状況に合わせてプランを変更

中堅企業でも、SaaS Ops を意識的に運用することで、年間 SaaS 費用の 20〜 30 % を削減できるケースが珍しくありません。

SaaS 棚卸ツールの位置づけ

SaaS Ops を効率化するために、専用の SaaS 棚卸ツールが登場しています。

Zylo（ザイロ）

2016 年設立、SaaS 管理プラットフォームの草分け
全 SaaS の可視化・支出分析・ライセンス最適化
中大企業向け

Torii（トーリー）

2017 年設立、SaaS 発見と自動化に強い
シャドー IT の検出が得意
中大企業向け

Josys（ジョーシス）

2021 年公開、日本発の SaaS 管理プラットフォーム
情シス業務全般（PC 管理・アカウント管理・SaaS 管理）を統合
中堅企業向けに強い

選定の考え方

SaaS 数が 30 個以下なら、Excel + SSO ログでも管理可能
SaaS 数が 50 個以上になると、専用ツールの費用対効果が出る
情シス業務全般を統合したい場合は Josys、SaaS 特化なら Zylo・Torii

SaaS Ops の年間サイクル

SaaS Ops は、年間サイクルで運用します。

四半期業務

全 SaaS の利用状況レビュー
ライセンス最適化の実施
ベンダー別のパフォーマンス評価

契約更新時業務

更新 3 か月前：利用状況分析・プラン見直し検討
更新 2 か月前：ベンダーとの交渉開始
更新 1 か月前：新契約条件の合意
更新後：契約情報の台帳更新

年次業務

SaaS ポートフォリオの俯瞰レビュー
経営会議・取締役会への年次報告（SaaS 総費用・重複投資の解消状況）
翌年度の SaaS 投資計画策定

次のステップ

本レッスンでは iPaaS・API 連携と SaaS Ops を扱いました。次の最終レッスンでは、SaaS ライフサイクルの終盤である解約・リプレース判断と、SaaS 導入 PM のキャリア・修了後の学び方をまとめて本コースの締めとします。

確認クイズ

このレッスンで学んだ内容を確認しましょう。