embedded iPaaSとは？自社SaaSへの連携機能の組み込みと内製・調達の判断【2026年8月時点】

embedded iPaaS（組み込み型iPaaS）は、SaaSを提供する側の企業が、自社プロダクトの中に他サービスとの連携機能を持たせるための基盤です。顧客は自分のSaaS管理画面から会計や名刺管理やチャットとつなぎ、提供側の開発チームはコネクタを1本ずつ手で作る作業から降ります。この記事では、通常のiPaaSとの構造上の違い、外部基盤が肩代わりする4つの構成要素、内製した場合に持ち続けることになる保守、主要4製品の立ち位置と価格の見え方、そして採用と見送りの分岐点を実装者の粒度で扱います。

まとめ｜embedded iPaaSを買う条件と内製で持つ条件

結論から言うと、買いに寄せるべきなのは「つなぐ相手が増え続ける」構造を抱えたプロダクトです。顧客ごとに接続先SaaSが違い、商談のたびに新しい連携要望が条件として乗ってくるなら、コネクタの本数は青天井に伸びます。この形では、OAuthのトークン更新やAPI仕様変更の追随といった定型の面倒を外部基盤に預けたほうが、開発チームの手を製品そのものへ戻せます。

逆に内製で持つべきなのは、連携先が数本で固定され、しかもその接続が製品の競争力そのものになっている場合でした。独自プロトコルや社内網の内側にある基幹システムが相手なら、汎用コネクタの守備範囲から外れるため外部基盤の恩恵が薄くなります。iPaaSという分類自体の定義や利用企業側から見た使いどころはiPaaSとは？仕組み・RPAとの違い・主要ツールと導入判断をわかりやすく解説で整理しました。本記事は、買い手が利用企業ではなく製品を作る側である点に絞って進めます。

embedded iPaaSの定義｜通常のiPaaSとは使う人も置き場所も違う

名前が似ているせいで通常のiPaaSと混同されやすいのですが、この2つは想定する利用者も、機能が置かれる場所も別物です。まず構造の差を確定させます。

通常のiPaaSは利用企業のIT部門が使い組み込み型はSaaS提供側が使う

通常のiPaaSは、SaaSを使う側の企業が契約し、自社が持つ複数のクラウドサービスをつなぐために独立したプラットフォームとして操作します。連携フローを作るのは利用企業の情報システム部門や業務部門の担当者で、画面もベンダーのものをそのまま使う形です。

embedded iPaaSは契約者が入れ替わります。契約するのはSaaSを提供する側の企業で、その企業の顧客が、提供されているプロダクトの画面の中から連携を設定します。つまり連携機能はプロダクトの一機能として顧客に見え、裏側で動いている基盤の名前は表に出ません。9製品を横並びで比べたい利用企業側の話はiPaaSの比較9製品｜料金と課金単位・接続数で選ぶ判断軸と規模別の結論に委ねます。

自社プロダクトの画面の中に連携設定のUIが埋め込まれる構造になる

実装から見ると、embedded iPaaSの中核は「自社アプリに埋め込む連携設定UI」と「その裏で回るワークフロー実行基盤」の2層です。埋め込みUIは自社のブランドに合わせた見た目で提供され、顧客は接続したいSaaSを選び、認証画面へ飛び、権限を許可して戻ってきます。この一連の往復を自前で書くと、対応SaaSの数だけ実装が増えていきます。

もう一方のワークフロー実行基盤は、顧客ごと（テナントごと）に別々の設定値と認証情報を保持したまま同じ処理を回す仕組みです。同じ「Salesforceへ商談を作る」処理でも、A社とB社では接続先の組織もフィールドの対応関係も違います。この差分をテナント単位の設定として持たせられるかどうかが、通常のiPaaSとの決定的な設計差でした。

SaaSベンダー側の課題として浮上した背景は連携要望の受注条件化にある

この方式が広がった理由は単純で、連携の有無が商談の可否を左右するようになったからです。国内企業が使うSaaSの本数は増え続けており、新しい製品を入れるときには既存の会計や勤怠やチャットとつながるかどうかが評価項目に入ります。

SaaS提供側から見ると、これは終わりのない開発要求という形で表面化する問題です。要望の順にコネクタを作っていけば、製品の差別化に使える開発リソースが連携の保守に食われていく構図です。embedded iPaaSは、この構造的な赤字を外部へ移す選択肢として位置づけられています。

embedded iPaaSが肩代わりする4つの構成要素を実装目線で見る

製品を比べる前に、そもそも何を代わりにやってくれるのかを分解します。ここが曖昧なまま商談に入ると、見積の妥当性を判断できません。

マルチテナントの認証情報管理とトークン更新を丸ごと預けられる

最初の要素が認証です。OAuth 2.0の認可フローを回し、アクセストークンとリフレッシュトークンをテナントごとに分離して保管し、期限切れの前に更新し、顧客が連携を解除したらそのテナントの資格情報だけを失効させる——この一式が標準機能として提供されます。

ここで確かめるべき評価軸が1つあります。あるテナントの認証が壊れたときに、他のテナントの実行まで巻き込まれないかどうかです。トークン更新の失敗が共有のリトライキューを詰まらせる作りだと、1社の設定ミスが全顧客への障害に化けます。商談では「テナント単位で隔離されているか」を機能一覧ではなく障害時の挙動として質問してください。

事前構築コネクタと自社固有コネクタの作り分けが選定の分かれ目になる

次がコネクタです。各社とも数百本規模の事前構築コネクタを持ちますが、選定でコネクタ総数を見ても意味は薄いと考えています。自社の顧客が実際につなぐ先は多くて十数本に収まるからです。

見るべきは深さのほうでした。たとえば「Salesforce対応」と書かれていても、標準オブジェクトの作成しかできないのか、カスタムオブジェクトとカスタムフィールドまで扱えるのか、一括更新のAPIに対応しているのかで実装の可否が変わります。事前構築コネクタの一覧をもらったら、自社が呼ぶ予定のエンドポイントを列挙して照合する作業を必ず挟んでください。足りない分は独自コネクタとして自作することになり、その作りやすさが次の評価軸になります。

埋め込みUIと実行ログの提供範囲で問い合わせ対応の重さが決まる

3つ目が顧客に見える部分です。ホワイトラベルの設定画面、接続状態の表示、失敗したときの通知先——これらを基盤側が持つのか自社で作るのかで、サポート部門の負荷が変わります。

運用に入ってから効くのが実行ログと再実行の機能でした。顧客から「昨日の受注データが連携されていない」と連絡が来たとき、どのテナントのどのフローがいつ失敗し、相手のAPIが何を返したのかを追える画面があれば一次切り分けが数分で済みます。ログの保持期間と、失敗したジョブをデータごと再実行できるかは商談前に確かめてください。

Webhook受信とレート制限やページネーションの吸収も基盤側が担う

4つ目が、外部APIと付き合ううえでの定型処理です。相手からのWebhookを受け取る口を用意し、署名を検証し、レート制限に当たったら待ってから再送し、大量データはページ単位でたどる。どれも難しくはないものの、接続先ごとに作法が違うため本数に比例して実装量が積み上がります。

この層はタスク課金の考え方にも直結します。1回の同期が何ステップとして数えられるのかは製品ごとに規則が違い、ステップ数の多いフローほど消費が伸びる点は通常のiPaaSと共通でした。数え方の実例はZapierとは？読み方・できること・料金とタスク課金の仕組み【2026年版】で扱っています。

内製すると何を持ち続けるのかを実装と保守のコストから確かめる

ここからが受託開発の現場で実際に見えている景色です。内製の判断は初期の実装量ではなく、5年間の保守で決まります。

初期実装より重いのは相手先APIの仕様変更に追随し続ける作業になる

コネクタを1本書くこと自体は難しくありません。OAuthの実装とエンドポイントの呼び出しを書けば、数日で動くものはできます。問題は、そのAPIが自社の都合とは無関係に変わり続ける点でした。

認証方式の移行、旧バージョンの提供終了、フィールドの追加や仕様変更、レート制限の変更——連携先が20本あれば、年に何度かはどこかから変更告知が届く状態です。追随に失敗すると、その顧客だけ連携が止まり、障害として自社に返ってくる事態です。内製を選ぶなら、コネクタ本数×年間の変更頻度を掛けた工数を、恒常的な運用費として最初から予算に載せておく必要があります。

テナント単位の障害切り分けと権限設計は初期設計を誤ると作り直しになる

もう1つの負債が設計です。テナントごとに認証情報を隔離し、テナントごとに実行状況を追え、片方の障害が他方へ波及しない構造は、後から入れると影響範囲が全体に及びます。

とくに厄介なのが、暗号化した資格情報の鍵管理と失効の設計でした。顧客が解約したときにそのテナントのトークンだけを確実に消せるか、逆に誤って他テナントの資格情報へアクセスできる経路が残っていないか。ここは監査の対象にもなるため、後付けの改修では説明責任を果たしにくくなります。連携基盤の内部構造そのものはWorkatoとは？レシピとタスク課金・環境分離を実装視点で解説【2026年8月時点】で扱った企業統合型の作りが参考になります。

取引先の求めるセキュリティ証跡を自前基盤で示す負担も見込んでおく

連携機能は顧客の他システムの資格情報を預かる機能です。そのためエンタープライズ顧客との商談では、暗号化の方式、アクセス制御、証跡の保存期間、第三者監査の有無が質問票として飛んできます。外部基盤なら説明の一部を基盤ベンダーの認証取得状況に寄せられますが、内製では自社で証跡を整え毎回答える体制が要ります。開発工数の比較だけで内製を選ぶと、この営業側のコストが抜け落ちがちでした。

主要なembedded iPaaS4製品の立ち位置と価格の見え方を整理する

ここでは代表的な4製品の性格を、機能一覧ではなく「誰が書くか」と「いくらか見えるか」の2軸で整理します。単一製品の詳細な深掘りは別記事に譲ります。

Prismaticはコードで書く方式を前面に出しエンジニア主導の製品に向く

Prismaticは、TypeScriptで統合そのものを記述するcode-native integrationsという方式を掲げています。コネクタや統合を書くためのTypeScriptライブラリ（spectral）と、自社アプリへ埋め込むためのライブラリ（embedded）が公開されており、開発者が普段のIDEと既存のCI/CDの中で連携を書ける構成です。

この方式が刺さるのは、連携ロジックにレビューとテストとバージョン管理を効かせたい開発組織でした。逆に、ビジネス側の担当者が画面上で連携を組み替える運用を想定しているなら、コード前提の作りは日常運用の担い手を狭めます。

ParagonはAI連携基盤としての位置づけを広げる方向に舵を切っている

Paragonは、従来の埋め込み型連携に加えて、AI製品向けの統合基盤という位置づけを打ち出しています。外部SaaSからのデータ取り込みや、AIエージェントが外部ツールを呼び出す経路を同じ基盤で扱う方向です。

自社プロダクトにAI機能を載せ、その回答根拠として顧客のSaaSデータを参照させたいなら、この方向性は検討材料になります。ただし判断軸はあくまで自社の要件で、AI機能があること自体が採用理由にはなりません。AIから外部SaaSを操作する経路についてはZapier MCPとは？AIから9,000超アプリを動かす仕組みとタスク消費・権限設計を解説も併せて見てください。

Workato Embeddedは企業統合型の基盤をそのまま外販する形を取る

Workato Embeddedは、企業統合型iPaaSとして作られた基盤をSaaSベンダー向けに提供する形です。母体側が持つ1,200超の事前構築コネクタと統制機能をそのまま受け取れる反面、規模と価格帯も母体に準じます。

自社プロダクトの顧客に大企業が多く、権限管理や監査ログの水準を商談で問われる立場なら候補に入ります。レシピとジョブという母体の実行モデルはWorkatoとは？レシピとタスク課金・環境分離を実装視点で解説【2026年8月時点】で詳しく扱いました。

Cyclrは公開価格を掲示しており年額の当たりを早い段階で付けられる

4社のうち金額が表に出ているのがCyclrです。公式の価格ページには、自社プロダクトへ組み込むNative Embedded iPaaSとしてPAYGが月額1,595ドルから（API呼び出し10万回・コネクタ10本を含む）、Growthが月額2,595ドルから（100万回・追加コネクタ1本あたり月100ドル・ステージング環境）、Scaleが月額7,195ドルから（500万回・独自コネクタ作成ツールキット）と記載がありました（2026年8月12日実測・いずれも下限表示）。ほかにService Embedded iPaaSのSharedが月額1,495ドルから、MCPサーバを提供するMCP PaaSのShared構成が月額999ドルからと示されています。

実務上の価値は金額そのものより、社内稟議の初動が早く回る点にありました。残る3社は同日時点で公式サイトに金額の掲示がなく、いずれも問い合わせによる見積です。

独自章｜内製コネクタと外部調達の分岐点を具体的な条件で言い切る

ここまでの整理を、受託開発の立場から判断として言い切ります。曖昧に両論併記しても発注の役に立ちません。

買いに寄せてよいのは接続先が増え続け顧客ごとに設定が割れる場合

外部基盤を買う判断が正しくなる条件は3つです。第1に、接続先SaaSの本数が今後も増える見込みがあること。第2に、同じ接続先でも顧客ごとにフィールドの対応関係や同期の向きが違い、テナント単位の設定を持たせる必要があること。第3に、連携の設定を顧客自身に任せたい（サポート部門が代行しない）こと。

この3つが揃うと、内製した場合に作るものは事実上embedded iPaaSそのものです。同じ基盤を自社で作って保守する合理性は、よほど特殊な要件がない限り出てきません。

内製に寄せてよいのは接続先が固定で独自プロトコルが絡む場合に限る

反対に内製が有利になるのは、接続先が数本で固定されており、しかも汎用コネクタが存在しない相手を含む場合でした。全銀手順のような業界固有のプロトコル、社内網の内側にしかない基幹データベース、取引先ごとに仕様が違う受発注のファイル連携などが該当します。

もう1つの条件が、連携そのものが製品の差別化要素になっている場合です。つなぐ処理の中に自社独自の名寄せロジックや業務判断が入り込んでいるなら、それは連携ではなくアプリケーション機能として自社の資産に置くべきでした。汎用基盤に載せると、かえって表現しにくくなります。

現実解はハイブリッド方式で中核だけ内製し周辺は外部基盤に載せる

受託の現場でまとまりやすいのは、この2択のあいだにある分割案です。業務ロジックと整合の担保が要る中核だけを自社APIとして切り出し、そこへつなぐ汎用SaaS側の口をembedded iPaaSに載せます。境界の引き方は「片方が失敗したらもう片方を取り消す必要があるか」で判断すると迷いません。取り消しが要る範囲は自社実装、要らない範囲は外部基盤という切り分けです。

一創ではiPaaS導入支援（Zapier／Make／Workato／Yoom）として、連携要件の棚卸しからこの境界線の設計、自社実装が必要な範囲の開発までを扱っています。既存プロダクトへ後から連携機能を足す案件では、まず現行の顧客別要望を一覧化し、汎用基盤に載せられる比率を数えるところから始めると判断の精度が上がりました。

導入前に実測すべき検証項目とPoCの具体的な設計を先に決めておく

製品を絞ったら、機能一覧の比較ではなく実測へ移ります。ここで測る対象を間違えると、契約後に想定と違う結果になります。

コネクタ深度は自社が呼ぶエンドポイントを列挙してから検証する

PoCの第1項目はコネクタの深さです。自社の顧客が実際に使う接続先を上位5本ほど選び、そのうえで呼ぶ予定の操作（作成・更新・検索・一括処理・削除）を列挙してから、標準コネクタで到達できるかを1つずつ確かめてください。

到達できない操作が見つかった場合の対処も同時に測ります。独自コネクタを書く手順と本番へ配る流れまで通しで試せば、運用開始後の追加要望に自社が対応できるかを判断できます。

課金単位を自社の顧客数モデルに当てて3年分の年額を具体的に試算する

第2項目が費用の試算です。製品によって課金の単位が違い、接続した顧客数で数える方式、実行回数で数える方式、統合の本数で数える方式が混在します。自社の成長計画に当てはめて、顧客が現在の3倍になったときの年額まで出しておいてください。

あわせて、超過したときの扱いも確認しておきたい項目です。上限で停止するのか、従量で加算されるのかで、想定外の同期が走ったときの結果が変わります。国産iPaaSの課金単位の考え方はYoomとは？国産iPaaSの仕組み・料金・kintone連携の実装と採用判断【2026年版】が参考になります。

乗り換えるときに何が自社に残るのかを必ず契約前に確かめておく

第3項目が撤退の条件です。embedded iPaaSは顧客の資格情報と連携設定を預ける基盤なので、乗り換えるときには顧客全員に再認証を依頼する事態になり得ます。

契約前に、統合の定義をエクスポートできるか、資格情報の移行に何が必要か、解約後のデータ保持期間はどうなるかを文書で確認してください。ここを飛ばすと、価格改定の交渉力を失った状態で更新を迎えます。

よくある質問

embedded iPaaSの検討でよく挙がる質問に、公開情報と実装の経験から答えます。

通常のiPaaSを自社プロダクトの裏側で動かす方法では代用できませんか？

小規模なら動きますが、顧客数が増えると破綻しやすい構成です。通常のiPaaSはテナントという概念を前提にしておらず、顧客ごとの設定を別々のフローとして複製する運用になります。10社なら回っても、100社では同じ修正を100回反映する作業が発生します。

embedded iPaaSを入れるとコネクタの内製は完全に不要になりますか？

不要にはなりません。自社プロダクト自身のAPIを基盤へ登録する作業は必ず残りますし、事前構築コネクタが自社の要件を満たさない接続先も出てきます。減るのは、汎用SaaS側の認証・再送・仕様変更追随といった定型部分です。作業がゼロになる前提で見積を組むと、導入後に不足が出ます。

日本国内のSaaSとの接続は海外製の基盤でも足りますか？

接続先の顔ぶれ次第です。会計や勤怠や電子帳票など国内でシェアの高い製品は、海外製基盤の事前構築コネクタに含まれないことがあります。上位の接続先を列挙して照合し、不足分を独自コネクタで埋める工数を含めて比較してください。国内SaaS中心の構成なら、国産の連携基盤を候補に入れる判断もあり得ます。

料金はどのくらいを見ておけばよいですか？

公開価格を持つCyclrで月額1,000ドル台からという水準が1つの目安になります（2026年8月12日時点の下限表示）。ほかの主要製品は公式サイトに金額の掲示がなく見積制のため、金額の推測は避けたほうが安全です。商談前に、接続する顧客数・月間の同期回数・接続先の本数を概算しておくと、各社の課金単位に当てはめた比較ができます。

既存プロダクトに後から組み込むことはできますか？

できます。ただし既存の顧客が使っている連携がある場合は移行の設計が要ります。旧実装と新基盤を並行稼働させ、接続先ごとに切り替える段階移行が現実的でした。顧客への再認証依頼が発生する範囲を先に洗い出してください。

関連記事

• iPaaSとは？仕組み・RPAとの違い・主要ツールと導入判断をわかりやすく解説：embedded iPaaSの母体となるiPaaSという分類の定義と、RPA・ETLとの役割の違いを整理しています
• iPaaSの比較9製品｜料金と課金単位・接続数で選ぶ判断軸と規模別の結論：利用企業として通常のiPaaSを選ぶ場合の横並び比較と規模別の結論をまとめています
• Workatoとは？レシピとタスク課金・環境分離を実装視点で解説【2026年8月時点】：Workato Embeddedの母体にあたる企業統合型iPaaSの実行モデルと統制機能を確認できます
• Zapierとは？読み方・できること・料金とタスク課金の仕組み【2026年版】：1回の同期を何タスクとして数えるかという課金の考え方を公開価格の製品側から確認できます
• Yoomとは？国産iPaaSの仕組み・料金・kintone連携の実装と採用判断【2026年版】：国内SaaS中心の構成で連携基盤を選ぶ場合の判断材料になります
• Zapier MCPとは？AIから9,000超アプリを動かす仕組みとタスク消費・権限設計を解説：AIエージェントから外部SaaSを操作する経路と権限設計の考え方を扱っています