埋め込み型金融（エンベデッドファイナンス）とは？

ECサイトでの決済時に発生する「16桁のクレジットカード番号の手動入力」や「外部ローン審査サイトへの遷移」といった手続きは、カゴ落ち（購入離脱）率を平均22%以上上昇させる要因となります。このコンテキストの分断を解消し、日常的なサービス利用プロセスの中に決済・融資・保険などの機能をシームレスに組み込む技術・サービスモデルが「エンベデッドファイナンス（埋め込み型金融）」です。顧客接点を持つ非金融事業者がこの機能を自社サービス内に内包することで、ユーザー体験の劇的な向上、顧客生涯価値（LTV）の極大化、そして新たな手数料収入（テイクレート）の獲得が可能になります。

エンベデッドファイナンス（埋め込み型金融）の定義とBaaSとの構造的違い

顧客体験（UX）起点で整理する「埋め込み型金融」の基本概念

従来の金融機関が提供するオンラインバンキングや決済サービスでは、ユーザーが能動的に「金融アクション」を個別に起こす必要がありました。例えば、ECサイトで高額な商品を購入する際、これまでは決済手段としてクレジットカード番号の16桁を手動入力したり、分割払い（ローン）審査のために外部の信販会社サイトへ遷移して個人情報を再入力したりする「コンテキストの分断」が発生していました。この分断は、EC事業者にとって「カゴ落ち（離脱）」の最大の要因であり、コンバージョン率（CVR）を低下させる深刻なボトルネックとなっていました。

これに対し、エンベデッドファイナンス（埋め込み型金融）は、ユーザーの日常的な購買行動や業務フローの中に、決済・融資・保険などの金融機能が摩擦なく溶け込んでいる状態を指します。ユーザーは「金融サービスを利用している」という意識を持つことなく、シームレスに決済や融資の恩恵を受けられます。

非金融サービスに金融機能が溶け込むことの真の意味は、金融が独立した目的ではなく、顧客のペインポイントを解消するための「構成要素（コンポーネント）」へと再定義される点にあります。非金融事業者が得られる組込型金融 メリットは、顧客接点の囲い込みによるLTV（顧客生涯価値）の最大化と、決済や金融仲介から得られるテイクレート（取扱高に対する手数料収入比率）を通じた新規収益源の確保です。この具体的な仕組みについては、後半のケーススタディやビジネスモデルのセクションで詳細に検証します。

技術とライセンスの観点から紐解く「BaaS プラットフォーム」とのレイヤー構造の違い

実務において「BaaS 埋め込み型金融 違い」は混同されがちですが、これらは対立する概念ではなく、金融サービスを構成する「フロントエンド（表舞台）」と「バックエンド（裏方）」の補完関係にあります。

エンベデッドファイナンスは、顧客が直接触れる「フロントエンドの体験（アプリケーション層）」を指します。一方で、BaaS（Banking as a Service）は、銀行や決済事業者が持つ預金、為替、融資などの金融ライセンスや勘定系システムを、APIを通じて非金融事業者に提供する「バックエンドの基盤（プラットフォーム層）」を指します。

このシステム境界と役割の違いを以下のレイヤー構造にまとめます。

レイヤー	主要な構成要素	主なプレイヤー	準拠する主な法規制
フロントエンド層（エンベデッドファイナンス）	顧客接点（UI/UX）、独自のロイヤルティプログラム、非金融サービスとのシームレスな統合	非金融事業者（Shopify、Uber、SaaSベンダーなど）	個人情報保護法、特定商取引法など
仲介・APIインテグレーション層	金融APIのオーケストレーション、開発者向けSDK、トランザクションデータの標準化	FinTechプロバイダー（Stripe、Marqetaなど）	金融ライセンス非保有時の委託先管理基準など
バックエンド・ライセンス層（BaaS プラットフォーム）	銀行勘定系システム、決済ネットワーク接続、預金・融資・為替のコア機能、API提供	パートナー金融機関（住信SBIネット銀行、みんなの銀行など）	銀行法、資金決済法、犯罪収益移転防止法（KYC）

このレイヤー構造において、非金融事業者がBaaS プラットフォームとAPI連携を行う際、法的な責任境界の画定が極めて重要になります。例えば、日本国内において口座開設や送金機能を自社サービスに組み込む場合、事業者自身が資金決済法に基づく「資金移動業者」や銀行法に基づく「電子決済等代行業者」としてのライセンスを直接取得するか、あるいはBaaS提供元の金融機関の「所属一代理店（銀行代理業）」や「業務委託先」として運営するかという実務判断が必要となります。

実例として、住信SBIネット銀行が展開するBaaSサービス「NEOBANK」を日本航空（JAL）やヤマダデンキが自社アプリに導入しているケースが挙げられます。フロントの顧客接点（エンベデッドファイナンス）は各事業者が提供しつつ、裏側の金融口座管理やライセンス担保（BaaS）は同行が全面的に引き受けることで、非金融事業者は法規制の重い参入障壁やシステム構築コストを直接負うことなく、自社ブランドの金融サービスを展開しています。これにより、ユーザーはアプリから離脱することなく、マイルが貯まる銀行口座や独自の決済機能を日常的に利用できるようになります。

非金融企業が「組込型金融 メリット」を最大化しLTVを向上させるビジネスモデル

決済・融資・保険機能の統合がもたらす顧客LTVの極大化と離脱防止

非金融企業が自社のサービスに金融機能を直接組み込む「組込型金融 メリット」の本質は、ユーザー体験の摩擦（フリクション）を極限まで排除し、顧客生涯価値（LTV）を最大化することにあります。従来の決済や融資、保険の申し込みは、ユーザーを外部の金融機関のWebサイトやアプリへ遷移させる必要があり、この「画面遷移」が顧客の離脱を招く大きな要因となっていました。米国のリサーチ企業Baymard InstituteによるECカート放棄率の調査では、チェックアウトプロセスの複雑さを理由に離脱するユーザーが約22%に上ることが示されています。前述したレイヤー構造に基づき、金融機能をシステム内に「API連携」でシームレスに埋め込むことで、この離脱率を劇的に引き下げることが可能になります。

すでに国内外では、プラットフォーム型ビジネスにおけるエンベデッドファイナンスの統合が進んでいます。例えばプラットフォーマーが加盟店向けに決済機能を提供するだけでなく、プラットフォーム上の取引データや売上推移をリアルタイムに分析し、数ステップで運転資金を自動融資するレンディングサービスが実用化されています。従来の銀行融資のように煩雑な書類提出や数週間の審査待ちを必要とせず、使い慣れた管理画面上で融資手続きが完結する利便性により、ユーザーの成長を支援しつつプラットフォームへの固着性（リテンション）を高めています。このように、金融機能がプロダクトの利用頻度と継続率を向上させ、最終的にLTVを底上げする強力な装置として機能します。

自社プロダクトによるテイクレート（手数料収入）の獲得と新規収益源の確立メカニズム

埋め込み型金融の導入は、顧客体験の改善に留まらず、従来のビジネスモデル（物販やSaaSの月額課金など）に加えて、決済やファイナンスの取引量に連動して発生する「テイクレート（手数料収入）」という新たな収益源を確立します。ユーザーが自社のプラットフォーム上で決済、融資、保険などの取引を行うたびに、決済手数料や提携手数料の一部が自社のマージンとして還元される仕組みです。

月間の総取扱高（GMV）が10億円規模に達するプラットフォーム企業をモデルケースとした場合、金融機能を統合することで獲得できる想定テイクレートと新規収益のシミュレーションは以下の通りです。

統合する金融機能	想定されるテイクレート	適用対象となる月間取扱高	月間の想定新規収益
自社ブランド決済	0.3% 〜 0.8%	10億円（プラットフォーム全体の決済）	300万 〜 800万円
埋め込み型少額融資（BNPL等）	1.5% 〜 3.0%	5,000万円（融資・分割利用枠）	75万 〜 150万円
埋め込み型保険（Embedded Insurance）	10.0% 〜 20.0%	1,000万円（購入時の保険加入額）	100万 〜 200万円

この手数料ビジネスを自社単独で構築する場合、金融ライセンスの取得や膨大なシステム投資が障壁となります。しかし、既存のBaaS プラットフォームと協業することで、非金融企業はライセンス保有者である金融機関の機能をAPI経由で調達し、初期投資を抑えてスピーディにサービスを立ち上げることができます。例えば、国内での決済や送金機能を実装する際には、資金決済法に基づく事業者登録（資金移動業者など）や、それに準ずる規制への対応が必要となりますが、BaaS提供パートナーが仲介プロセスを巻き取ることで、法的なハードルを最小化しつつテイクレートビジネスを展開することが可能になります。

【国内外の実証事例】先行企業によるエンベデッドファイナンス 事例の構造分析

エンベデッドファイナンスの真価は、非金融サービスが金融機能を内包することで、顧客体験（UX）を劇的に向上させ、既存事業の収益性を高める点にあります。具体的な財務数値と構造分析から、そのメカニズムを解き明かします。

Shopify Balanceが実現する加盟店向け決済・金融エコシステムの財務データ分析

Shopify（ショピファイ）は、単なるECサイト構築プラットフォームから、決済や融資、口座機能を包含する「エンベデッドファイナンス 事例」の代表格へと変貌を遂げています。同社の収益構造は、定額のシステム利用料である「Subscription Solutions」と、決済手数料や金融サービスからなる「Merchant Solutions（マーチャントソリューション）」の2つに大別されます。

公開された財務データによると、総売上高に対するMerchant Solutionsの比率は約74%に達しています。この偏重とも言える収益構造を支えているのが、GMV（総流通取引高）に対する決済・金融サービスの売上比率を示す「テイクレート」の高さです。同社のテイクレートは約2.8%で推移しており、決済サービス「Shopify Payments」に加えて、加盟店向けビジネスカウント「Shopify Balance」、さらには融資サービス「Shopify Capital」がこの高い収益性を牽引しています。

これら高度な金融サービスは、米国の代表的なBaaSプロバイダーであるStripe（Stripe Treasury）やEvolve Bank & TrustとのシームレスなAPI連携によって実現しています。Shopifyは銀行ライセンスを自社で保有せず、BaaS プラットフォームを裏側に組み込むことで、加盟店に対して以下の金融価値を提供し、LTV（顧客生涯価値）の最大化に成功しています。

サービス名	金融機能の実態	提供する顧客価値	ビジネスへの直接的効果
Shopify Payments	クレジットカード決済の統合	離脱のないスムーズな購入手続き	決済手数料（テイクレート）の獲得
Shopify Balance	BaaS連携によるビジネス口座	売上金の即日回収とキャッシュバック	エコシステム内への資金滞留と解約防止
Shopify Capital	売掛債権ファクタリング・融資	煩雑な審査なしでの迅速な資金調達	加盟店の成長によるGMV拡大・LTV最大化

加盟店は、Shopifyの管理画面から離脱することなく日々の資金管理や調達を完結できるため、プラットフォームへの依存度が極めて高くなります。これが非金融企業が目指すべき「組込型金融 メリット」の最たる好例です。

Uberや国内先行企業におけるドライバー向け即時決済・融資スキームの構造

もう一つの強力なユースケースは、ギグワーカーや個人事業主を対象とした、即時決済と融資の組み込みスキームです。米国のUber Technologies（ウーバー・テクノロジーズ）が提供する「Uber Pro Card」は、ドライバー向けのエンベデッドファイナンスとして有名です。

UberはFinTech企業のBranchやMastercardとAPI連携し、ドライバー専用のデビットカードとビジネス口座を提供しています。従来の週次での報酬支払いではなく、乗車完了直後に手数料無料で報酬がデビットカード口座に振り込まれる「即時支払い（Instant Pay）」を実現しました。これにより、ドライバーの資金繰りは劇的に改善し、他社プラットフォームへの乗り換えを防ぐ強力なロイヤリティプログラムとして機能しています。ドライバーの稼働率維持とプラットフォームへの定着（LTVの向上）に直結しているのです。

このスキームは国内の先行企業でも急速に広がっています。例えば、単発バイトアプリを展開する「タイミー（Timee）」では、就業後にアプリ内で申請すると、24時間365日いつでも即時に給与相当額が指定口座に振り込まれるシステムを提供しています。これはセブン銀行などのBaaS機能をAPI連携させることで、ユーザーの手間を排除したシームレスなUXを実現した事例です。

さらに、国内の会計SaaSベンダー（freeeや弥生など）も、日々の取引・会計データを審査に活用した「オルタナティブ・データによる即時融資（ファクタリング）」を組み込んでいます。従来の銀行のように決算書や担保を必要とせず、会計データからリアルタイムで返済能力を予測し、即座に資金を提供するモデルです。

ただし、日本国内でこうした決済や融資のスキームを実装するにあたっては、法的な規制への適応が大きな障壁となります。特に「資金決済法」が定める資金移動業のライセンス要件や、貸金業法による金利・審査の規制、さらには二重譲渡防止や債権保全のための高度な法的手続きが必要です。

自社でこれらのライセンスをゼロから取得し、システムを構築するには、億単位のコストと数年規模の開発期間がかかります。そのため、国内の多くの先行企業は、あらかじめライセンスを保有している国内銀行（住信SBIネット銀行、GMOあおぞらネット銀行など）や決済代行業者をパートナーとし、彼らが提供するBaaS プラットフォームを活用して「組込型金融 メリット」を早期に享受するアプローチを選択しています。これにより、法制度への適合コストを最小化しつつ、コア事業へのリソース集中を可能にしています。

実装を阻む「技術・法制度」の壁と具体的なクリア手法

非金融企業が自社サービスに金融機能を組み込み、顧客のLTV（顧客生涯価値）最大化や、決済手数料（テイクレート）の最適化といった「組込型金融 メリット」を享受するためには、技術（システム連携）と法規制という2つの巨大な壁を乗り越える必要があります。これらを適切にクリアするための具体的な手法を解説します。

APIゲートウェイ連携とセキュリティ要件から見たシステムインテグレーションの解決策

金融機関が提供するBaaS プラットフォームと非金融企業のサービスを接続する際、最も高いハードルとなるのが、勘定系システムのレガシーなセキュリティ基準と、Webサービスが求めるモダンなAPI連携のギャップです。金融業界 of データ連携では、一般的なWeb APIよりも遥かに厳格な認可プロトコルや暗号化標準が求められます。

このシステム連携をセキュアに実現するためのデファクトスタンダードが、金融グレードのAPIセキュリティ規格である「FAPI（Financial-grade API）」の導入です。具体的には、GMOあおぞらネット銀行や住信SBIネット銀行が展開するBaaS プラットフォームを自社サービスと接続する際、認可プロトコルとしてOAuth 2.0およびOIDC（OpenID Connect）の拡張プロファイルであるFAPI 1.0 Advanced（またはFAPI 2.0）に準拠した設計が要求されます。

実装においては、自社システムと金融機関のAPIの間に「APIゲートウェイ」を配置する構成が不可欠です。APIゲートウェイ（例：ApigeeやKong、AWS API Gatewayなど）を構築し、以下の技術要件を満たす必要があります。

• mTLS（相互トランスポート層セキュリティ）の導入: 接続元（非金融企業）と接続先（金融機関）の双方が電子証明書を用いて互いを認証し、通信経路全体を暗号化します。
• トークンバインディング（Holder-of-Key）: アクセストークンの盗難・悪用を防ぐため、特定のクライアント証明書と紐づいたトークンのみを有効化します。
• リクエストの署名検証（JWS/JWE）: 改ざんを防ぐため、APIリクエストおよびレスポンスにデジタル署名を付与し、ペイロードを暗号化します。

これらのセキュリティ処理をアプリケーションレイヤーから切り離し、APIゲートウェイ側で集中的に実行することで、開発負荷を軽減しつつ、FISC（金融情報システムセンター）安全対策基準に準拠した堅牢なAPI連携を構築できます。結果として、トランザクションの遅延を抑えながら、シームレスな決済や融資といったユーザー体験（UX）を提供し、顧客離脱を防ぐことでLTV向上へと繋げることが可能になります。

国内金融法規制（資金決済法・銀行代理業等）をクリアする金融機関との適正な責任分界

日本国内で金融サービスを提供する場合、「銀行法」「資金決済法」「割賦販売法」などの厳格な法規制を遵守する必要があります。非金融企業が自社単独で金融ライセンスを取得するには、数億円規模の純資産要件や専任のコンプライアンス体制、監督官庁への登録・免許申請など膨大なコストと期間が必要となり、新規参入の現実的なアプローチとは言えません。

そのため、非金融企業が金融ライセンスを持たずに適法に運営するアプローチとして、第1セクションで整理した「フロントエンド」と「バックエンド」の役割分担を徹底し、提携金融機関との間で「適正な責任分界（業務範囲の切り分け）」を定義することが重要です。非金融企業は「UI/UXの提供者（媒介・取次）」に徹し、実際の資金移動や与信、預金の預かりといった重い法的責任を伴う領域は、ライセンスを持つ金融機関（BaaS提供元）が引き受ける構造を作ります。

例えば、代表的な「エンベデッドファイナンス 事例」として、特定のバーティカルSaaSが提供するオンライン融資（レンディング）サービスが挙げられます。この場合、SaaS企業は自社プラットフォーム上で顧客の承諾を得て財務データを取得・連携する機能（UI）のみを担い、実際の融資審査、資金の実行、および債権回収は提携先の銀行がライセンスに基づいて行います。これにより、SaaS企業は銀行代理業のライセンスを取得することなく、適法に融資機能を自社サービス内に組み込んでいます。

以下は、非金融企業がBaaSを活用して金融機能を組み込む際の、一般的な責任分界点を示したものです。

業務領域	非金融企業（自社）の役割	BaaS提供金融機関の役割	該当する主な法規制
顧客接点・UI提供	サービスの提供、申込データの入力支援、UI/UXの設計	APIを介した機能提供、バックエンド処理の実行	個人情報保護法
預金・口座開設	口座開設プロセスのUI提供、確認書類のアップロード媒介	口座開設の最終審査、預金の管理・運用	銀行法、犯罪収益移転防止法
決済・送金処理	購入・送金指示のAPI送信（トリガーの発生）	実際の資金移動処理、決済ネットワークへの接続、清算	資金決済法、銀行法
AML/CFT・不正監視	不審なユーザー行動の一次検知、金融機関への報告	取引フィルタリング、疑わしい取引の届出、最終判断責任	犯罪収益移転防止法

このように、非金融企業は「金融取引を成立させるための『媒介』や『情報転送』を行っているに過ぎない」という適法な建付けを維持することで、コンプライアンス違反のリスクを回避できます。資金決済法や銀行法における規制対象（ライセンス保有者）が常に金融機関側であることを利用規約およびシステムシーケンスの両面で担保することが、埋め込み型金融の実装を成功させる鍵となります。

事業参入を成功に導くパートナー選定基準と実務導入プロセスチェックリスト

技術力とコンプライアンスから判断する最適な「BaaS プラットフォーム」選定の3軸

非金融事業者がエンベデッドファイナンスの導入メリットを享受し、持続可能な収益源を確保するためには、裏側の金融インフラとなる最適なBaaSパートナーの選定が不可欠です。選定にあたっては、以下の「APIの技術柔軟性」「ライセンスのカバー範囲」「初期・ランニングコスト」の3軸で、提携先プロバイダーを多角的に評価・比較する必要があります。

評価軸	具体的な評価項目	金融機関・BaaSプロバイダーの確認項目	事業への実質的インパクト
APIの技術柔軟性	開発ドキュメントの公開度、Sandbox環境、SDKの提供状況	RESTful APIの仕様、OAuth 2.0などのセキュリティ認証のサポート有無。	API連携の開発期間を短縮し、自社ネイティブアプリのUI/UX改修スピードを向上。
ライセンスのカバー範囲	資金決済法などの法規制をクリアするための認可連携・代行範囲	資金移動業、前払式支払手段、割賦販売法などに該当するライセンスの適用範囲。	自社での新規ライセンス登録（数千万円以上の保証金や数年の申請期間）を回避。
初期・ランニングコスト	初期導入費用、月額固定費、トランザクションあたりのテイクレート	1トランザクションごとの手数料率（%）およびAPIコールあたりの従量課金。	ビジネスモデルの早期黒字化と、持続可能な収益分配（レベニューシェア）の実現。

API의技術柔軟性において、例えば日本国内でAPI連携をオープンに進めているGMOあおぞらネット銀行や住信SBIネット銀行（NEOBANKサービス）などは、開発者向けの充実したポータルとSandbox環境を常に公開しており、開発開始までの初期コンタクトを数カ月短縮する仕組みを整えています。一方、ライセンスのカバー範囲に関しては、例えば自社で「前払式支払手段（ハウスプリペイド）」や「資金移動サービス」を提供する場合、資金決済法に基づく最低1,000万円の履行保証金の供託、あるいは財務局への四半期報告などの重いコンプライアンス業務が生じます。これに対し、インフキュリオンの「Wallet Station」のように、プラットフォーム側がすでにセキュリティ（PCI DSSなど）や法的な登録要件の一部をバックアップ・代行するサービススキームを活用することで、自社で取得するライセンスの要件を大きく緩和し、法務コストを最小化できます。テイクレートの観点でも、トランザクションのボリュームに応じた段階的ディスカウントが用意されているプロバイダーを選定することで、事業成長期の利益率低下を抑えることができます。

新規事業開発チームがPoCから本格実装に臨むための実務適合性チェックリスト

国内外における代表的なエンベデッドファイナンスの成功事例を分析すると、成功を収めている非金融事業者は、法的なクリアランスとシステム開発の段階的なゲート（判断基準）を極めて緻密に設計していることが分かります。以下に、非金融企業の新規事業開発担当者がプロジェクトを進めるためのToDoチェックリストを提示します。

• フェーズ1：ビジネスモデル策定と規制関係の検証（1〜2ヶ月目）
  • [ ] 提供機能の優先順位付け：自社サービスの顧客行動データを分析し、LTVを最大化するために最も必要な機能が「決済（後払いなど）」か、「融資」か、「保険」かを明確にする。
  • [ ] 関係法令の判定：資金決済法（資金移動業、前払式支払手段）、割賦販売法、貸金業法、保険業法のうち、自社がどの規制対象に該当するかを法務・外部弁護士とともに特定する。
  • [ ] KYC（本人確認）要件の定義：口座開設や送金機能を実装する際、eKYC（オンライン本人確認）が必要となるか、また外部のeKYC事業者（LIQUID eKYCなど）とのAPI接続が必要かを確認する。
• フェーズ2：BaaSパートナー選定と技術検証（3〜4ヶ月目）
  • [ ] RFP（提案依頼書）の提示：API仕様、サーバーの許容トランザクション数（TPS）、SLA（サービス品質保証、稼働率99.9%以上など）、初期費用・月額費用・テイクレート料率を盛り込んだRFPをBaaS事業者に送付する。
  • [ ] Sandbox環境での技術検証：選定したBaaSプラットフォームのテスト環境にエンジニアが接続し、APIのレスポンスタイムが自社基準（例：200ミリ秒以内）を満たしているか、例外エラー時の挙動を確認する。
  • [ ] セキュリティ監査：自社システム側でクレジットカード情報を保持しない「非保持化」要件、あるいはPCI DSS準拠の必要性を、BaaS側との接続構成図を元に精査する。
• フェーズ3：PoC（概念実証）と本番リリース（5〜8ヶ月目）
  • [ ] クローズドβテスト（PoC）の実施：自社従業員や一部のロイヤルカスタマー（数百名程度）を対象にクローズドベータテストを実施し、決済決済エラーの有無やUI/UXのボトルネック（離脱率）を測定する。
  • [ ] 24時間365日の運用・サポート体制構築：金融トラブル（決済失敗、二重課金、アカウント乗っ取りなど）に対応するためのカスタマーサポートフローと、BaaS事業者・金融機関へのエスカレーションルートを確立する。
  • [ ] 本番ローンチとKPI計測：テイクレート収益、アクティブユーザーあたりのARPU、および金融機能追加に伴う既存コアサービスの継続率（チャーンレート）改善幅を定量的かつリアルタイムに追跡するダッシュボードを本番稼働させる。

このプロセスを実行することで、開発の差し戻しや法律違反のリスクを抑えつつ、スムーズに自社のプラットフォームに金融価値を組み込むことが可能となります。

よくある質問（FAQ）