エンベデッドファイナンスのイネーブラーとは？役割・BaaSとの違い・国内の担い手を解説

自社のアプリやサービスに決済や金融機能を組み込む「エンベデッドファイナンス（組込型金融）」への関心が高まるなかで、その仕組みを解説する記事に必ず登場するのが「イネーブラー」という耳慣れない担い手です。

イネーブラーとは何をする、誰なのか。言葉の輪郭がつかめないまま、自社が金融機能を持つには結局どこに相談すればよいのか分からない、という方も多いのではないでしょうか。

本記事では、エンベデッドファイナンスの登場人物（ブランド・ライセンスホルダー・イネーブラー）の関係のなかで、イネーブラーの役割・BaaSとの違い・金融領域の全体像を解説します。あわせて、国内で実際に当たれる決済領域のイネーブラー（決済API・決済代行サービス）を具体的に紹介し、自社に決済を組み込む際の相談先の入口までを一つの記事で把握できるようにしています。

エンベデッドファイナンスの「イネーブラー」とは

イネーブラーとは、金融ライセンスを持つ金融機関と、顧客との接点を持つ非金融の事業会社の間に立ち、APIやシステム基盤で両者をつなぐ担い手です。事業会社は、イネーブラーが用意した仕組みを利用することで、自前で金融システムを一から作らなくても、自社サービスのなかで決済や融資などの金融機能を提供できるようになります。

エンベデッドファイナンスは、金融以外の事業を営む企業が既存のサービスに金融機能を組み込んで提供する動きを指します。ECサイトでの後払いや、フリマアプリ内の送金、配車アプリでの自動決済などが身近な例です。こうした「金融機関ではない企業が金融サービスを届けられる」状態を裏側で成り立たせているのが、イネーブラーという存在です。

3者構造の中でのイネーブラーの位置

エンベデッドファイナンスは、役割の異なる3者が組み合わさって成り立ちます。それぞれの立場を押さえると、イネーブラーの位置がはっきりします。

• ブランド（事業会社）：顧客との接点を持ち、自社サービスの中で金融機能を届ける非金融の企業。ECや配車アプリなどが該当します。
• ライセンスホルダー：銀行やカード会社など、金融ライセンスを持ち金融機能そのものを提供する金融機関。
• イネーブラー：ブランドとライセンスホルダーの間に立ち、両者をAPIやシステムでつなぐ担い手。事業会社は自前開発なしで金融機能を実装できます。

3者の関係を図にすると、イネーブラーが両者の間に立つ位置づけが見えてきます。

業界の解説でも、このイネーブラーの役割は次のように整理されています。

Marqeta（マルケタ）やAffirm（アファーム）、Galileo（ガリレオ）などが知られ、ライセンスを持つ金融機関と顧客接点を持つブランドとの中間に入りシステムを構築します。ライセンスホルダーとブランドをつなぐ役割があります。イネイブラーがAPIを介して金融機能をブランドに提供することで、他業種の企業も一からシステム構築をせずに金融サービスを実装できます。

出典：NTTデータ「Octo Knot｜Embedded Finance（埋込型金融）とは」（https://8knot.nttdata.com/trend/7871231）

ここで挙げられているMarqetaやGalileoは海外の代表的なイネーブラーで、日本ではまだなじみが薄いかもしれません。国内で実際に当たれる担い手については、後半の「国内の決済イネーブラーの実例と選び方」で決済領域を中心に具体的に紹介します。

イネーブラーが実際に提供するもの

ここからは、イネーブラーが事業会社に対して具体的に何を提供するのかを整理します。役割を「両者をつなぐ」と一言でまとめると抽象的ですが、提供物に分解すると輪郭がつかめます。

APIやSDKによるシステム基盤

イネーブラーの中心的な提供物が、事業会社のシステムから呼び出せる接続口（API）やSDK（アプリ開発用の部品群）です。事業会社は、これらを自社のWebサイトやアプリに組み込むことで、決済や口座機能といった金融処理を自社サービスの中で完結させられます。

決済領域であれば、支払い画面のトークン化（カード番号を別の文字列に置き換える仕組み）、支払い結果を自社システムへ通知する仕組み、本番前に動作を確認できるテスト環境などが含まれます。

金融機能の組成とパッケージ化

イネーブラーは、ライセンスホルダーが持つ金融機能をそのまま横流しするのではなく、事業会社が使いやすい形に組み立て直します。複数のカード会社や決済手段を一つの契約・一つの接続にまとめる、都度課金や継続課金といった課金処理をあらかじめ用意する、といった作り込みがこれにあたります。事業会社は個々の金融機関と交渉・接続する手間を負わずに済みます。

許認可・審査の橋渡し

金融サービスの提供には、法令上の許認可や加盟店審査、セキュリティ基準への対応が伴います。イネーブラーは、ライセンスホルダー側の許認可を前提に、加盟店審査の取次ぎやカード情報を安全に扱う仕組みを整え、事業会社が金融のバックグラウンドを持たなくても金融機能を届けられるようにします。

こうした橋渡しがあるため、事業会社は自前で金融システムやライセンス体制を構築せずに、金融機能を自社サービスへ組み込めるのです。これがイネーブラーを利用する最大の便益といえます。

BaaS・ライセンスホルダーとイネーブラーの違い

イネーブラーは、ライセンスホルダーやBaaS（銀行API）と混同されやすい存在です。ここでは、混同が起きやすい「誰が金融ライセンスを持つのか」「何を提供するのか」という点に絞って違いを整理します。

※上記は一般的な役割の整理です。個別の事業者が実際に担う機能や許認可の範囲は各社の提供内容をご確認ください。

「BaaS（バース、Banking as a Service）」は、銀行が口座開設や入出金といった銀行機能をAPIで外部に開放する提供形態を指します。イネーブラーはこのBaaSを上流として利用することもあり、両者は対立する概念ではありません。銀行機能そのものを持つライセンスホルダー、それをAPIで開くBaaS、両者と事業会社をつなぐイネーブラー、という層の違いと捉えると、役割の混同を避けられます。

金融ライセンス・許認可を持つのは誰か

役割を正確に理解するうえで押さえておきたいのが、金融ライセンス・許認可の所在です。銀行機能を提供するライセンスホルダー側には、法令上の免許や登録が求められます。銀行法（昭和五十六年法律第五十九号）第四条第一項は「銀行業は、内閣総理大臣の免許を受けた者でなければ、営むことができない」と定めています。

銀行以外の事業者が送金・資金移動を業として扱うには、資金決済に関する法律（資金決済法）に基づく資金移動業の登録が必要です。プリペイド型の前払式支払手段（第三者型）の発行にも登録が求められます。

一方で、決済領域のイネーブラー（決済代行）は「金融ライセンスを一切持たない」わけではありません。加盟店とカード番号等を取り扱う契約を結ぶ決済代行は、割賦販売法（昭和三十六年法律第百五十九号）に基づき「クレジットカード番号等取扱契約締結事業者」として登録を受ける必要があります。同法は、カード番号等の適切な管理のために必要な措置を講じる義務も課しています。

このように、銀行免許のような金融機能そのものの許認可はライセンスホルダー側が持ち、決済イネーブラー自身は割賦販売法上の登録とカード情報管理の義務を負う、という切り分けになります。

出典・参考資料（3件）

• 出典：銀行法 第四条・第二条｜e-Gov法令検索（https://laws.e-gov.go.jp/law/356AC0000000059）
• 出典：資金決済に関する法律 第三十七条・第七条｜e-Gov法令検索（https://laws.e-gov.go.jp/law/421AC0000000059）
• 出典：割賦販売法 第三十五条の十七の二・第三十五条の十六｜e-Gov法令検索（https://laws.e-gov.go.jp/law/336AC0000000159）

イネーブラーが担う金融領域の見取り図

イネーブラーが担う金融機能は決済だけではありません。貸付・保険・投資・銀行といった領域ごとに担い手がいて、それぞれ「◯◯ as a Service」と呼ばれる形で提供されています。自社がどの金融機能を組み込みたいかによって、当たるべき担い手が変わります。

※領域の分け方や呼称は各社・各資料により異なる場合があります。

このなかで、事業会社が最初に検討することが多いのが決済領域です。オンラインでの売上を自社サービスの中で受け取れるようにする決済の組み込みは、多くのビジネスに共通する起点になるためです。次章では、この決済領域で国内で実際に当たれるイネーブラーを具体的に見ていきます。

決済の組み込みを具体的に進めたい方は、各社の資料請求から検討を始められます。

国内の決済イネーブラーの実例と選び方

ここからは、決済領域で国内の事業者が実際に利用できるイネーブラー、すなわち決済API・決済代行サービスを紹介します。これらは、カード会社や銀行がもつ決済機能を、事業会社が自前でライセンスや接続基盤を用意せずに自社サービスへ組み込めるようにする担い手であり、その点でエンベデッドファイナンスの決済領域におけるイネーブラーにあたります。いずれも、APIやSDKを通じて自社のWebサイトやアプリに決済処理を組み込める点が共通しています。まずは各社の対応決済手段や組み込み方式、向くケースを一覧で比べてみましょう。

ここからは、各サービスの特徴を個別に紹介します。自社の決済手段や組み込み方式の要件に照らして、候補を絞る参考にしてください。上表は2026年9月時点の各社公式情報にもとづく整理で、最新の対応状況・料金は各社の公式情報をご確認ください。

1. PGマルチペイメントサービス（GMOペイメントゲートウェイ株式会社）

GMOペイメントゲートウェイが提供する総合決済サービスで、クレジットカードを中心にコンビニ決済・キャリア決済・各種ID/QR決済・口座振替・後払いなど、多様な決済手段を一つの契約・一つのシステムで導入できます。豊富なAPIやリンクタイプの接続方式を備え、自社サイトへの組み込みに対応します。中堅から大企業・公的機関まで、営業担当が個別にヒアリングして導入を支援する形態が特徴です。

2. SBペイメントサービス（SBペイメントサービス株式会社）

ソフトバンク株式会社の100%子会社が運営する決済代行サービスで、クレジットカード・キャリア決済・QR/ID決済・コンビニ決済・後払いなど40ブランド以上の決済手段を、単一契約・単一接続で導入できます。開発者向けサイトでAPI連携の情報が公開されており、自社EC・システムへの組み込みに対応します。ソフトバンクグループの決済プラットフォームとしての基盤を持つ点が強みです。

3. ペイジェント（株式会社ペイジェント）

NTTデータと三菱UFJニコスの折半出資という資本背景を持つ決済代行サービスです。クレジットカード決済・コンビニ決済・キャリア決済・QRコード決済など20種類規模の決済手段に対応し、決済種別をまたいだ入金の一本化や、カード情報の非保持化（自社でカード情報を保持しない対応）に対応します。

事業者側の接続方式としてモジュール（API）やトークンを用意しており、自社の購入画面に組み込む形での導入ができます。

4. VeriTrans4G（株式会社DGフィナンシャルテクノロジー）

DGフィナンシャルテクノロジーが提供するマルチ決済サービスで、公式の製品ページではクレジットカード・コンビニ・キャリア・電子マネー・ID決済・銀行決済・後払いに加え、国際決済手段を含む30種類以上の決済手段に対応するとされています。マルチ決済に対応するAPIとカード情報の非保持化を備え、オンライン・実店舗の双方の決済を自社システムに組み込めます。

5. Square（Square株式会社）

Block, Inc.傘下のSquare株式会社が提供するキャッシュレス決済サービスです。オンライン決済向けには、自社サイトやアプリに決済機能を組み込むための開発者向けSDK・APIが公開されており、対面とオンラインの売上を一つのアカウントで統合管理できます。初期費用・月額固定費・振込手数料がかからず、決済時の手数料のみという料金体系も特徴です。

6. PayPal（PayPal Pte. Ltd.）

世界200以上の国・地域、100通貨以上に対応するオンライン決済プラットフォームです。事業者はビジネスアカウントを開設し、決済用のAPIを通じて自社ECサイトにクレジットカード・デビットカード決済を組み込めます。買い手はPayPalアカウントを持っていなくてもカード決済ができ、初期費用・月額費用のない取引従量課金です。越境ECとの相性のよさが強みといえます。

7. fincode byGMO（GMOイプシロン株式会社）

開発者・事業者向けに設計されたAPI型の決済プラットフォームです。加盟店と各決済事業者の間に立つ決済ゲートウェイとして契約・データ伝送・決済処理を担い、REST APIやSDK、テスト環境を即時に発行できる開発者体験を訴求しています。初期費用・月額費用0円で導入でき、スタートアップが素早く決済を組み込みたいケースに向きます。

8. KOMOJU（株式会社KOMOJU）

国内外65以上の決済方法を一つの統合APIで導入できるマルチチャネル決済プラットフォームです。クレジットカード・コンビニ・QR/スマホ決済・銀行振込・後払いに加え、韓国・中国・東南アジア・ヨーロッパなどの現地決済手段に対応します。越境ECや海外向け販売を行う事業者の現地決済対応が主な強みで、統合APIで自社サービスに組み込めます。

9. SP.LINKS（e-SCOTT Smart）（SP.LINKS株式会社）

決済代行プラットフォーム「e-SCOTT Smart」を主力に、クレジットカード決済代行・コンビニ収納代行・口座振替・オンライン収納代行を提供する決済・収納代行サービスです。カード各社との直接接続による決済基盤を持ち、カード情報を事業者側で保持しない「非通過型」の方式として、リンク決済・メールリンク決済・トークン決済などを公式に案内しています。幅広い規模の事業者の代金回収に対応します。

ここで紹介した各社を含め、より多くの決済API・決済代行を対応決済手段・開発のしやすさ・手数料といった観点で腰を据えて比較したい場合は、以下の記事で選び方とあわせて詳しく解説しています。導入を具体的に検討する段階の参考にしてください。

自社にエンベデッドファイナンス（まず決済）を組み込むときの始め方

役割と担い手が把握できたら、実際に自社サービスへ金融機能を組み込む検討に移ります。多くの場合、最初の一歩となるのは決済の組み込みです。次のような流れで進めると、要件と担い手のすり合わせがしやすくなります。

1. 組み込みたい決済手段を洗い出す：クレジットカードだけでよいのか、コンビニ決済やQR/ID決済、海外の決済手段まで必要かを整理しておくとよいでしょう。対応手段の幅は事業者によって差があります。
2. 組み込み方式を確認する：自社の支払い画面をそのまま使いたいのか、提供元の画面へ遷移する方式でよいのかによって、必要なAPI・SDKやカード情報の扱いが変わります。
3. 開発・運用の体制と照らす：テスト環境や開発者向けドキュメントの充実度、サポート体制は、社内に開発リソースがどれだけあるかによって重視度が変わります。
4. 複数社の資料を取り寄せて比べる：対応決済手段・手数料・組み込み方式は各社で異なるため、候補を数社に絞って資料を比較すると、自社に合う担い手が見えてきます。

決済の組み込みは、カード情報を安全に扱う仕組みや加盟店審査への対応など、自社だけで整えるには負担の大きい要素を伴います。イネーブラーである決済代行・決済APIを利用すれば、こうした部分を任せながら段階的に決済機能を組み込めます。

組み込み方式（接続方式）には、自社の支払い画面に直接組み込むAPI型やトークン型、提供元の画面へ遷移するリンク型などがあり、どれを選ぶかで開発の手間やカード情報の扱いが変わります。それぞれの違いと選び方は、以下の記事で詳しく解説しています。

まとめ

エンベデッドファイナンスにおけるイネーブラーは、金融ライセンスを持つライセンスホルダーと、顧客接点を持つ事業会社の間に立ち、APIやシステム基盤で両者をつなぐ担い手です。事業会社は、イネーブラーを利用することで自前で金融システムを構築せずに、自社サービスへ決済などの金融機能を組み込めます。

金融ライセンスそのものはライセンスホルダー側が持ち、決済領域のイネーブラーは割賦販売法上の登録やカード情報の管理義務を担う、という切り分けを押さえると、BaaSやライセンスホルダーとの違いも整理しやすくなります。自社サービスにまず決済を組み込むなら、国内の決済API・決済代行各社の資料を取り寄せて、対応決済手段や組み込み方式を比べるところから始めてください。

よくある質問（FAQ）

Q. エンベデッドファイナンスのイネーブラーとは何ですか？

A. エンベデッドファイナンスのイネーブラーとは、金融ライセンスを持つ金融機関（ライセンスホルダー）と、顧客接点を持つ非金融の事業会社（ブランド）の間に立ち、APIやシステム基盤で両者をつなぐ担い手です。

事業会社は、イネーブラーが用意した仕組みを利用することで、自前で金融システムを一から作らなくても、決済や融資などの金融機能を自社サービスの中で提供できるようになります。海外ではMarqetaやGalileoが代表例で、国内では決済領域の決済代行・決済API事業者が実際に当たれる担い手にあたります。

Q. 決済代行と決済APIは何が違うのですか？

A. 決済代行と決済APIは、明確な線引きがあるわけではなく、どちらも決済領域のイネーブラーとして重なる部分が大きい呼び方です。

決済代行は、加盟店契約の取次ぎや複数の決済手段をまたいだ入金の一本化など「代行」の側面を、決済APIは事業者が自社システムから呼び出せる「接続手段」の側面を強調した表現です。実際には同じ事業者が両方の性格を備えていることが多く、自社の要件（対応させたい決済手段や組み込み方式）に照らして選べば、名称の違いにこだわる必要はありません。

Q. 自社サービスに決済を組み込むには、まず誰に相談すればよいですか？

A. 自社サービスに決済を組み込むなら、まず決済領域のイネーブラーである決済代行・決済API事業者に相談・資料請求するのが入口になります。

これらの事業者は、決済処理を組み込むAPI・SDKだけでなく、カード情報の安全な取り扱いや加盟店審査への対応といった、自社だけで整えるには負担の大きい部分も担います。本記事で紹介した国内各社の資料を取り寄せ、対応決済手段と組み込み方式を並べて比べるところから始めるとよいでしょう。

Q. イネーブラーを利用する事業会社は、自社で金融ライセンスや許認可を取得する必要がありますか？

A. イネーブラーを利用して自社サービスに金融機能を組み込む事業会社は、原則として自社で金融ライセンスや許認可を取得する必要はありません。

金融ライセンスそのものはライセンスホルダー側が持ち、決済領域では決済代行が割賦販売法上の登録やカード情報の管理義務を担います。事業会社はその仕組みを利用する立場のため、金融のバックグラウンドがなくても機能を組み込めます。ただし、提供する金融サービスの内容によっては事業会社側にも登録などが求められる場合があるため、具体的な要件は個別に事業者へ確認することをおすすめします。

Q. 決済のイネーブラー（決済代行・決済API）の導入に費用はかかりますか？

A. 決済のイネーブラーの費用は、事業者や利用する決済手段によって異なり、一般に初期費用・月額費用・決済ごとの手数料で構成されます。

なかには初期費用・月額費用がかからず、決済時の手数料のみで導入できる事業者もあります。料金体系は各社で幅があるため、正確な費用は資料や見積もりで確認したうえで、対応決済手段や組み込み方式とあわせて比較するとよいでしょう。

Q. 決済以外の金融機能（貸付や保険など）を自社サービスに組み込みたい場合はどうすればよいですか？

A. 決済以外の金融機能も、貸付ならCredit／Lending as a Service、保険ならInsurance as a Serviceといった、その領域を担うイネーブラーに当たることで自社サービスに組み込めます。

まず自社が組み込みたい金融機能（決済・貸付・保険・投資・銀行）を定め、そのうえで該当領域の担い手を探すのが順序です。本記事では、多くの事業者が最初に検討する決済領域について、国内で実際に当たれる担い手を具体的に紹介しています。

決済API・決済代行サービスの料金・資料を一括チェック

MCB FinTechカタログでは、自社サービスに決済を組み込める決済API・決済代行サービスの最新資料を無料でまとめて請求できます。対応する決済手段や組み込み方式を並べて比較できます。

MCB FinTechカタログに掲載しませんか？

MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。