メルカリのグローバル展開を支える決済プラットフォームの進化
メルカリはグローバル展開（100カ国）に向けた決済・会計システムの刷新を宣言し、PSP 接続の柔軟性向上とデータ整合性の確保を技術的課題として解決する方針を示した。
キーポイント
グローバル展開のための新ミッション定義
3 年以内に 100 カ国へ展開するため、決済基盤と会計基盤を明確に分離し、通貨・言語の多様性や各国ごとの税務・リスク対応を独立して進める目標を設定した。
既存アーキテクチャの課題と密結合問題
従来の Payment Service は PSP 接続ロジックと Source リソースが密結合しており、新規決済手段や PSP の追加ごとにシステム全体への影響が大きくなるボトルネックが存在した。
拡張性とスピードを重視したアーキテクチャ進化
展開コストとスピードを最適化するため、PSP や決済手段の追加を最小限の変更で可能にする構成へ移行し、各国ごとの最適化を独立して実行できる設計を目指す。
会計データの整合性と外部連携の強化
通貨・国ごとの正確な集計、PSP 入金データとの照合、および在庫変動や税務イベントの外部システムとの適切な粒度での連携を確保する基盤整備が求められている。
影響分析・編集コメントを表示
影響分析
この記事は、メルカリが単なる国内サービスの海外展開にとどまらず、決済インフラそのものをグローバル規模に耐えうる設計へ再構築していることを示しています。特に、PSP や決済手段の追加を柔軟に行えるアーキテクチャへの転換は、急激な市場拡大期における開発スピードと安定性の両立において重要な教訓を提供します。
編集コメント
AI 技術そのものの進展を報じる記事ではありませんが、大規模グローバル展開における決済システムのアーキテクチャ設計思想は、FinTech 分野の実務家にとって非常に示唆に富む内容です。
こんにちは。メルペイ Payment & Customer Platform（PCP）チームの Backend Engineer を務める @ryuyama です。この記事は「Merpay & Mercoin Tech Openness Month 2026」の1日目の記事です。
はじめに
メルカリでは、2025 年 9 月 30 日にグローバル版のメルカリアプリをリリースしました。このアプリは台湾・US をはじめとして、3 年以内に 100 カ国へ展開することを目指しており、メルカリのグローバル展開を加速させるための重要なマイルストーンとなりました。
この記事では、メルカリ グローバルアプリ（以下、グローバルアプリ）のリリースに向けて、Payment Platform がどのような課題に向き合い、どのようにアーキテクチャを進化させてきたのかを紹介します。
Payment Platform に課せられたミッション
グローバルアプリ対応プロジェクトが立ち上がった際に、Payment Platform に課せられたミッションは、「3 年以内に 100 カ国展開できる決済・会計システムを作ること」でした。
そこで、Payment Platform のシステムを大きく「決済」と「会計」のドメインに分け、達成すべきゴールを整理しました。
決済基盤としては、主に以下のような対応が求められました。
- 100 カ国の通貨・決済手段への対応
- 決済画面の多言語対応
- 複数の PSP（決済事業者）との接続
- 為替レートを考慮した金額計算
- 不正利用やチャージバックのリスクへの対応
会計基盤としては、以下のような状態をゴールと置きました。
- 通貨ごと、国・地域ごとの売上、返金、決済手数料を正しく集計できること
- PSP（決済事業者）からの入金と、メルカリ側の取引データを照合できること
- 在庫変動や税務関連の会計イベントを、外部システムから会計システムへ正しい粒度・タイミングで連携できること
- 既存の国内向け会計システムとの整合性を保ちながら、新しい会計基盤へ移行できること
また、これらを一度きりのゴールとして実装するのではなく、グローバル展開のコストとスピードを強く意識する必要がありました。例えば、通貨や決済手段の追加をできるだけ迅速に行い、展開国を早く増やせること。不正対策、税務、会計などの各国・地域ごとの最適化を、それぞれ独立して進められることが求められました。
Payment Platform の進化
既存の Payment Platform
先ほど掲げたミッションを達成するために、現在のアーキテクチャにある課題洗い出しを行いました。Payment Platform は、日本のメルカリアプリの決済基盤をベースにして誕生し、メルペイの成長とともに進化してきました。
決済のレイヤーでは、Payment Service というマイクロサービスが存在します。Payment Service では、メルカリで商品を購入し、取引が完了するとお金が移動するという一連の取引を表現した Escrow というリソースや、お金の動きに注目した Charge、さらに 3D セキュアの普及や高度化する決済手段への対応のために Source というリソースが開発されてきました。
会計のレイヤーでは、Balance Service（残高サービス）や Accounting Service（会計サービス）といったサービスが存在します。Balance Service はお客さまの残高や加盟店の売上残高の管理を、Accounting Service は会計イベントの保存と経理向けのレポーティングを責務としています。
これらはいずれも、これまでのメルカリグループ全体の成長を支えてきた重要なサービスです。
一方で、グローバル対応に向けて、特に「展開コスト」と「展開スピード」という観点において、いくつかの課題がありました。
グローバル展開に向けた課題
PSP や決済手段の追加に Payment Service が必要
1 つ目の課題は、Payment Service において、PSP（決済事業者）との接続ロジックと Source リソースが密結合していたことです。
グローバル展開では、国や地域によって利用される決済手段が異なります。また、接続すべき PSP も国や地域ごとに変わる可能性があります。
そのため、新しい PSP や決済手段を追加するたびに Payment Service のロジックへ変更が入る状態では、展開国が増えるほど開発・運用コストが増大してしまいます。
また、Source が特定の決済手段と密結合していたため、新しい決済手段を追加する際には、新しいリソース定義や既存リソースへの影響を慎重に検討する必要がありました。
国内向けの決済基盤としては十分に機能していた設計でも、100 カ国展開を前提にすると、決済手段や PSP の追加をより小さな変更範囲で実現できる構成が必要でした。
残高と会計イベントの整合性がアーキテクチャで保証できていない
2 つ目の課題は、残高管理と会計イベントの整合性です。
既存の構成では、Balance Service が残高を管理し、Accounting Service が会計イベントを保存していました。しかし、両者の整合性は会計レイヤー自体で保証されているわけではなく、Payment Service 側のサービス間トランザクション管理に依存していました。
グローバル展開では、通貨ごと、国・地域ごと、PSP ごとの売上、返金、決済手数料を正しく集計できることが求められます。また、PSP からの入金とメルカリ側の取引データを照合できることや、在庫変動・税務関連の会計イベントを外部システムから会計システムへ正しい粒度・タイミングで連携できることも必要になります。
そのため、単に決済処理の結果を保存するだけではなく、後続の照合やレポーティング、既存の国内向け会計システムとの整合性を見据えた会計基盤が必要でした。
この課題は、グローバル対応が始まる以前から、メルカリのグローバルなマーケットプレイスの実現というビジョンに向けての課題だと認識されていました。これらの課題は次世代の会計システムであるBalance V2やBookkeeperとして、メルコインやメルカリ ハロの立ち上げに合わせて導入され、実運用の中で磨き上げられていました。一方で、メルカリのマーケットプレイスに関連する領域では既存システムからの移行コストが高く、導入の機会を待っている状況でした。
現在のアーキテクチャ
Payment Platformでは、グローバル対応に合わせて2つの大きな意思決定を行いました。
1つ目は、PSP（決済事業者）と接続するための処理をPayment ServiceからPSPとの接続を責務とするPayment Provider Serviceに切り出し、PSPとの接続ロジックや決済手段に関するロジックを決済リソース管理から分離することです。
2つ目は、会計システムにBalance V2とBookkeeperを利用し、Payment Serviceのトランザクション管理による整合性の管理から、残高と会計イベントが整合したモデルで扱われるアーキテクチャへ移行することです。
Payment Serviceが決済リソースのライフサイクル管理に集中する
新しいアーキテクチャでは、Payment Serviceの責務をより明確にしました。
Payment Serviceは注文や取引に紐づく決済リソースのライフサイクル管理に集中し、決済の作成、オーソリ、キャプチャ、キャンセルなどといった状態遷移を管理します。
一方で、どのPSPのAPIをどのように呼び出すか、各決済手段にどのようなパラメータが必要でPSPから返ってくるレスポンスやWebhookをどのように処理するかといった詳細はPayment Provider Serviceに切り出しました。
これにより、Payment Serviceは特定のPSPや決済手段に強く依存せず、より安定した決済リソース管理の責務に集中できるようになりました。
Balance V2 / Bookkeeperで残高と会計イベントの一貫性を担保する
会計基盤には、Balance V2とBookkeeperを利用しました。
Balance V2 と Bookkeeper では、残高の変動と会計イベントを一貫したモデルとして扱います。これにより、残高更新と会計イベントの記録が別々のデータとして管理されるのではなく、複式簿記のように、「現在の残高（ストック）」と「残高が変化した理由（フロー）」を対応づけて保存されるようになりました。
このアーキテクチャにより、Payment Service 側で残高と会計イベント間の整合性を保つ複雑なサービス間トランザクション管理を担う必要が減り、Payment Service は決済リソースの管理により集中できるようになりました。
終わりに
今回のプロジェクトでは、グローバル展開に必要な決済・会計基盤の土台を作ることができました。
記事執筆時点では台湾・US へのローンチが完了し、クレジットカード決済・Apple Pay・Google Pay などの決済手段にも対応しています。
また、Payment Platform で実現した抽象化を利用して、カートを使ったまとめ買い機能などの新しい購入体験も日本国内に先立ってグローバルアプリで提供することができました。
一方で、今後取り組むべき課題もまだ残っています。
例えば、日本のメルカリで日本円で売られている商品を海外通貨で販売する時の為替変換の仕組みは、現時点ではグローバルアプリ専用の実装に近く、社内の Payment Platform を利用しているチームにとって十分になめらかな体験になっているとは言えません。また、グローバルアプリ内でのポイントや残高の利用サポートも、今後進めていく必要があります。
そして、より長期的には、今回整備した基盤を日本国内のメルカリにも適用するプロジェクトも進行しています。今回整備したグローバル向けの基盤や設計を国内向けの基盤にも還元することで、Payment Platform 全体をより柔軟で拡張しやすい基盤へ進化させていきたいと考えています。
次の記事は mattsuu さんです。引き続きお楽しみください。
原文を表示
こんにちは。メルペイ Payment & Customer Platform（PCP）チームでBackend Engineerをしている @ryuyama です。この記事は「Merpay & Mercoin Tech Openness Month 2026」の1日目の記事です。
はじめに
メルカリでは、2025年9月30日にグローバル版のメルカリアプリをリリースしました。このアプリは台湾・USをはじめとして、3年以内に100カ国へ展開することを目指しており、メルカリのグローバル展開を加速させるための重要なマイルストーンとなりました。
この記事では、メルカリ グローバルアプリ（以下、グローバルアプリ）のリリースに向けて、Payment Platformがどのような課題に向き合い、どのようにアーキテクチャを進化させてきたのかを紹介します。
Payment Platformに課せられたミッション
グローバルアプリ対応プロジェクトが立ち上がった際に、Payment Platformに課せられたミッションは、「3年以内に100カ国展開できる決済・会計システムを作ること」でした。
そこで、Payment Platformのシステムを大きく「決済」と「会計」のドメインに分け、達成すべきゴールを整理しました。
決済基盤としては、主に以下のような対応が求められました。
- 100カ国の通貨・決済手段への対応
- 決済画面の多言語対応
- 複数のPSP（決済事業者）との接続
- 為替レートを考慮した金額計算
- 不正利用やチャージバックのリスクへの対応
会計基盤としては、以下のような状態をゴールと置きました。
- 通貨ごと、国・地域ごとの売上、返金、決済手数料を正しく集計できること
- PSP（決済事業者）からの入金と、メルカリ側の取引データを照合できること
- 在庫変動や税務関連の会計イベントを、外部システムから会計システムへ正しい粒度・タイミングで連携できること
- 既存の国内向け会計システムとの整合性を保ちながら、新しい会計基盤へ移行できること
また、これらを一度きりのゴールとして実装するのではなく、グローバル展開のコストとスピードを強く意識する必要がありました。例えば、通貨や決済手段の追加をできるだけ迅速に行い、展開国を早く増やせること。不正対策、税務、会計などの各国・地域ごとの最適化を、それぞれ独立して進められることが求められました。
Payment Platformの進化
既存のPayment Platform
先ほど掲げたミッションを達成するために、現在のアーキテクチャにある課題洗い出しを行いました。Payment Platformは、日本のメルカリアプリの決済基盤をベースにして誕生し、メルペイの成長とともに進化してきました。
決済のレイヤーでは、Payment Serviceというマイクロサービスが存在します。Payment Serviceでは、メルカリで商品を購入し、取引が完了するとお金が移動するという一連の取引を表現した Escrow というリソースや、お金の動きに注目した Charge、さらに3Dセキュアの普及や高度化する決済手段への対応のために Source というリソースが開発されてきました。
会計のレイヤーでは、Balance Service（残高サービス）やAccounting Service（会計サービス）といったサービスが存在します。Balance Serviceはお客さまの残高や加盟店の売上残高の管理を、Accounting Serviceは会計イベントの保存と経理向けのレポーティングを責務としています。
これらはいずれも、これまでのメルカリグループ全体の成長を支えてきた重要なサービスです。
一方で、グローバル対応に向けて、特に「展開コスト」と「展開スピード」という観点において、いくつかの課題がありました。
グローバル展開に向けた課題
PSPや決済手段の追加にPayment Serviceが必要
1つ目の課題は、Payment Serviceにおいて、PSP（決済事業者）との接続ロジックと Source リソースが密結合していたことです。
グローバル展開では、国や地域によって利用される決済手段が異なります。また、接続すべきPSPも国や地域ごとに変わる可能性があります。
そのため、新しいPSPや決済手段を追加するたびにPayment Serviceのロジックへ変更が入る状態では、展開国が増えるほど開発・運用コストが増大してしまいます。
また、Source が特定の決済手段と密結合していたため、新しい決済手段を追加する際には、新しいリソース定義や既存リソースへの影響を慎重に検討する必要がありました。
国内向けの決済基盤としては十分に機能していた設計でも、100カ国展開を前提にすると、決済手段やPSPの追加をより小さな変更範囲で実現できる構成が必要でした。
残高と会計イベントの整合性がアーキテクチャで保証できていない
2つ目の課題は、残高管理と会計イベントの整合性です。
既存の構成では、Balance Serviceが残高を管理し、Accounting Serviceが会計イベントを保存していました。しかし、両者の整合性は会計レイヤー自体で保証されているわけではなく、Payment Service側のサービス間トランザクション管理に依存していました。
グローバル展開では、通貨ごと、国・地域ごと、PSPごとの売上、返金、決済手数料を正しく集計できることが求められます。また、PSPからの入金とメルカリ側の取引データを照合できることや、在庫変動・税務関連の会計イベントを外部システムから会計システムへ正しい粒度・タイミングで連携できることも必要になります。
そのため、単に決済処理の結果を保存するだけではなく、後続の照合やレポーティング、既存の国内向け会計システムとの整合性を見据えた会計基盤が必要でした。
この課題は、グローバル対応が始まる以前から、メルカリのグローバルなマーケットプレイスの実現というビジョンに向けての課題だと認識されていました。これらの課題は次世代の会計システムであるBalance V2やBookkeeperとして、メルコインやメルカリ ハロの立ち上げに合わせて導入され、実運用の中で磨き上げられていました。一方で、メルカリのマーケットプレイスに関連する領域では既存システムからの移行コストが高く、導入の機会を待っている状況でした。
現在のアーキテクチャ
Payment Platformでは、グローバル対応に合わせて2つの大きな意思決定を行いました。
1つ目は、PSP（決済事業者）と接続するための処理をPayment ServiceからPSPとの接続を責務とするPayment Provider Serviceに切り出し、PSPとの接続ロジックや決済手段に関するロジックを決済リソース管理から分離することです。
2つ目は、会計システムにBalance V2とBookkeeperを利用し、Payment Serviceのトランザクション管理による整合性の管理から、残高と会計イベントが整合したモデルで扱われるアーキテクチャへ移行することです。
Payment Serviceが決済リソースのライフサイクル管理に集中する
新しいアーキテクチャでは、Payment Serviceの責務をより明確にしました。
Payment Serviceは注文や取引に紐づく決済リソースのライフサイクル管理に集中し、決済の作成、オーソリ、キャプチャ、キャンセルなどといった状態遷移を管理します。
一方で、どのPSPのAPIをどのように呼び出すか、各決済手段にどのようなパラメータが必要でPSPから返ってくるレスポンスやWebhookをどのように処理するかといった詳細はPayment Provider Serviceに切り出しました。
これにより、Payment Serviceは特定のPSPや決済手段に強く依存せず、より安定した決済リソース管理の責務に集中できるようになりました。
Balance V2 / Bookkeeperで残高と会計イベントの一貫性を担保する
会計基盤には、Balance V2とBookkeeperを利用しました。
Balance V2とBookkeeperでは、残高の変動と会計イベントを一貫したモデルとして扱います。これにより、残高更新と会計イベントの記録が別々のデータとして管理されるのではなく、複式簿記のように、「現在の残高（ストック）」と「残高が変化した理由（フロー）」を対応づけて保存されるようになりました。
このアーキテクチャにより、Payment Service側で残高と会計イベント間の整合性を保つ複雑なサービス間トランザクション管理を担う必要が減り、Payment Serviceは決済リソースの管理により集中できるようになりました。
終わりに
今回のプロジェクトでは、グローバル展開に必要な決済・会計基盤の土台を作ることができました。
記事執筆時点では台湾・USへのローンチが完了し、クレジットカード決済・Apple Pay・Google Payなどの決済手段にも対応しています。
また、Payment Platformで実現した抽象化を利用して、カートを使ったまとめ買い機能などの新しい購入体験も日本国内に先立ってグローバルアプリで提供することができました。
一方で、今後取り組むべき課題もまだ残っています。
例えば、日本のメルカリで日本円で売られている商品を海外通貨で販売する時の為替変換の仕組みは、現時点ではグローバルアプリ専用の実装に近く、社内のPayment Platformを利用しているチームにとって十分になめらかな体験になっているとは言えません。また、グローバルアプリ内でのポイントや残高の利用サポートも、今後進めていく必要があります。
そして、より長期的には、今回整備した基盤を日本国内のメルカリにも適用するプロジェクトも進行しています。今回整備したグローバル向けの基盤や設計を国内向けの基盤にも還元することで、Payment Platform全体をより柔軟で拡張しやすい基盤へ進化させていきたいと考えています。
次の記事は mattsuuさんです。引き続きお楽しみください。
関連記事
メルペイが事業者向け後払い決済の与信管理マイクロサービス設計を公開
メルペイ Payment & Customer Platform チームのエンジニアが、事業者向け後払い決済における立替リスクを管理する与信管理マイクロサービスの設計手法について発表した。
クラウドネイティブ会議に出展しました
メルカリの DBRE チームと IDP チームは、2026 年 5 月 14 日から 15 日に開催されたクラウドネイティブ会議にスポンサーとして出展し、認証やマイクロサービス規模に関する議論を交わした。
ロビンフッドの 10% 削減発表、AI への責任転嫁が通用しないことを示す
ロビンフッドは従業員 10% の削減を発表したが、その理由を AI 導入に求める姿勢は効果的ではないと指摘されている。同社は技術革新よりも経営判断の誤りを認める必要がある。
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み