UPSIDERのカード基盤を「外部提供できる形」にするまで——マイクロサービス化とマルチブランドアーキテクチャ

EMのmitsuiです。UPSIDERは2025年7月、法人カード基盤の外部提供を発表しました。自社ブランドのカードを立ち上げられるこのプラットフォームは、どのように設計・構築されたのか。マイクロサービスへの分割と、マルチブランド対応のアーキテクチャを、実装に携わったエンジニアの視点で解説します。

はじめに

UPSIDERは「挑戦者を支える世界的な金融プラットフォームを創る」を掲げ、AI与信モデルを活用した法人カード「UPSIDER」を提供しています。累計決済額は8,500億円*に達しており、サービスを通じて企業の多様な資金ニーズに応えてきました。

※法人カード「UPSIDER」リリースから、法人カード「UPSIDER」で決済された額の合計。2025年11月時点。

2025年7月、私たちはこの法人カード基盤の外部提供を開始しました。

prtimes.jp

金融機関やパートナー企業が、自社ブランドの法人カードを立ち上げられるようにするため、既存のシステムを根本から作り変える必要がありました。

この記事では、UPSIDERのカードシステムがどのように進化してきたか、その技術的な全体像をお伝えします。

法人カード基盤の外部提供の全体像についてはこちらの記事をご覧ください。

note.com

1. Before：すべてが混ざっていた時代

カードシステムに詰め込まれた「すべて」

UPSIDERカードは、2020年にリリースして以来、持続的な成長を遂げてきました。その過程で、カード管理のバックエンド領域には、広範なドメイン知識が混ざり込んでいきました。請求・債権管理：月次の請求書生成、口座振替、入金消込、債権管理法人審査：法人のeKYC、審査情報の管理カード情報：カードのステータス、その他詳細情報

これらが同じコードベース、同じデータベースに同居していました。

何が問題だったか

UPSIDERカード単体を提供する上では、このアーキテクチャは機能していました。しかし、カード基盤を外部に提供しようとしたとき、根本的な課題に直面しました。

1. このままではマルチテナント対応ができない

UPSIDERカードを提供しはじめたタイミングでは他社に展開することは考えていませんでした。そのためすべてのデータが単一のデータベースに格納されており、パートナーA社のデータとパートナーB社のデータを物理的に隔離する手段がありませんでした。法人カード基盤を外部提供する以上、パートナー企業間のデータ隔離は必須です。

2. ドメインの密結合

決済のロジックを変更したら請求処理に影響が出る。与信モデルを改善したらカード発行のフローが壊れる。ドメイン間の境界が曖昧なため、変更の影響範囲を制御できない状態でした。

3. 独立したスケーリングが不可能

請求処理の長時間化に対応するためにスケールすると、関係ないカード管理UIまで一緒にスケールしてしまう。一方で、与信審査のバッチ処理が重いとカード発行APIのレイテンシに影響し、リソースの最適化ができませんでした。

2. After：ドメインごとにサービスを分ける

4つのドメイン、4つのサービス

混ざり合っていた責務を、ドメイン境界に沿って独立したサービスに分割しました。

社内サービス名	ドメイン	責務
Iris	お客様向け管理画面	BFF + Web UI。カード発行、利用明細、メンバー管理、権限制御の操作ができるお客様向けの画面
Solaris	カード管理基盤	VISA決済処理、口座ライフサイクル、利用枠管理、不正検知連携
Hermes	請求基盤	月次請求生成、入金処理、口座振替、債権管理
Hestia	法人審査基盤	法人eKYC、コンプライアンススクリーニング

技術スタック

サービス	言語	フレームワーク	DB
Iris	TypeScript	Hono（Backend）, React + TanStack Router（Frontend）	PostgreSQL（Prisma）
Solaris	Go	gRPC	PostgreSQL
Hermes	Go	Connect RPC + Temporal	MySQL
Hestia	TypeScript	Hono（Backend）, React + TanStack Router（Frontend）	PostgreSQL（Prisma）

サービスごとに独立してスケール・デプロイできます。

3. 各サービスの設計

Iris：お客様向け管理画面（BFF + UI）

Irisは、パートナー企業のカード管理者が日常的に使うWebアプリケーションです。カード発行、利用明細の確認、メンバーの招待・権限管理、利用制限の設定——こうした操作のUIとAPIを提供します。

Iris自身はビジネスロジックの「オーケストレーター」です。カード発行ならSolarisを、請求情報の表示ならHermesを、審査状況の確認ならHestiaを呼び出す。各ドメインの知識はそれぞれの基盤サービスが持ち、Irisは画面に必要なデータを集約して返す役割に徹しています。

Solaris：カード管理基盤

Solarisはカードの発行やカード番号の照会といった基本機能を提供するサービスです。これまで自社のプロダクトで培ってきたプロセッシング基盤や不正利用対策機能をSolarisがファサードとして集約しIrisに提供することで、外部提供に適切なアクセスコントロールを実現します。

また、PCI DSS監査領域となるシステムコンポーネントをSolarisに分離することによって、ブランド別環境の構築やパートナー企業の監査対応などのコストと時間を節約し迅速に新たな法人カードブランドを立ち上げることを可能にすることに貢献します。

Hermes：請求基盤

Hermesは、月次請求の生成から入金の消込、口座振替、債権管理までを担うサービスです。

請求処理は複数のステップにまたがる長いフローです。月次の決済集計が完了したら請求書を生成し、口座振替を予約し、入金を確認し、未入金があれば督促する——こうしたワークフローをTemporalで管理しています。各ステップが独立したアクティビティとして定義されており、途中で失敗しても途中から再開できます。

tech.up-sider.com

Hestia：法人審査基盤

Hestiaは、法人の審査とUPSIDERにおける法人の情報を専門的に扱うサービスです。

eKYCのワークフロー管理、コンプライアンススクリーニングなどを他のサービスに影響を与えずに進められるようになりました。

また、金融サービスを提供するうえで、法人審査は避けて通れない重要な領域です。 Hestiaは、カード基盤に閉じた仕組みではなく、今後UPSIDERが展開していくさまざまなサービスで共通して利用される法人審査の基盤となります。法人審査という重要な責務をサービス横断で支えることで、UPSIDER全体の事業展開と開発スピードを後押ししていきます。

4. サービス間の連携

通信方式の使い分け

パターン	用途	例
REST	同期・サービス間通信	Iris → Solaris / Hermes / Hestia
Webhook	イベント通知	Solaris → Iris（月次集計完了）、Hermes → Iris（請求ステータス変更）、Hestia → Iris（法人審査完了）

典型的なフロー

アカウント開設

ユーザーが Hestia に法人情報を提出して申込を作成
Hestia が申込受付を Webhook で Iris に通知
Hestia で審査が完了すると、承認を Webhook で Iris に通知
Iris が組織を確定し、Solaris に組織アカウント、Hermes に請求口座を作成
Hestia が決定した与信枠を Webhook で Iris に通知すると、Iris が Solaris に反映。あわせて Iris が Hermes に振込口座を登録
Iris が組織をアクティブ化し、ユーザーにアカウント開設完了を通知

月次請求

Solaris が月次の決済データを集計し、完了をWebhookでIrisに通知
Iris がWebhookを受信し、Solarisから請求用データを取得
Iris がHermesに請求書の生成を依頼
Hermes が請求書を生成し、請求スケジュールを登録
入金が完了したら Hermes がWebhookでIrisに通知
Iris がユーザーに請求ステータスの更新を通知

各サービスが自分のドメインの責務だけを果たし、イベントで緩やかに連携する。Hermesの請求ロジックを変更してもIrisには影響せず、Solarisの集計方法を改善してもHermesには影響しない、これがドメイン分割の効果です。

5. マルチブランドの設計：コードは共有、境界は分ける

外部提供に向けて避けたかったのは、ブランドごとにコードベースが増えていく状態です。

ブランドごとにコードをフォークすると、立ち上げは早く見えるかもしれません。しかし、共通機能の改善や不具合修正のたびに、同じ変更を複数のコードベースへ反映し続ける必要があります。これでは、ブランドが増えるほど開発速度も品質も落ちていきます。

そこで、基本方針は「コードは共有する。ただし、ブランドごとの境界は曖昧にしない」としました。

ポイントは、すべてのサービスを同じ方式で分離しなかったことです。Iris と、Solaris / Hermes / Hestia では、システム上の役割が違います。そのため、ブランドの境界の引き方も、サービスごとに異なります。

Iris：提供単位として分ける

Iris は、ブランドごとに独立したアプリケーションとして提供できる構成にしています。
共通化できる業務ロジックや UI は共有しつつ、実際のデプロイ単位はブランドごとに分けます。テーマ、外部連携、ブランド固有の設定などは、それぞれのブランド側に閉じ込めます。
また、Iris ではインフラもブランドごとに分離しています。コードは共有しながらも、データや実行環境はブランドごとに独立させることで、パートナー間の境界を明確にしています。
つまり Iris は、「共通プロダクトを、ブランドごとに独立した形で提供する」ための分離です。

Solaris / Hermes / Hestia：共通基盤としてブランドを扱う

一方で、Solaris / Hermes / Hestia は、ブランドごとに別々の基盤を持つのではなく、共通のドメイン基盤として設計しています。
Iris がブランドごとの入り口になるのに対して、これらのサービスはその裏側で、決済・請求・審査といった各ドメインの責務を受け持ちます。そのため、サービス自体をブランドごとに分けるのではなく、処理の中で「どのブランドの文脈なのか」を扱えるようにしています。
特に Solaris では、ブランド境界をアプリケーションコードだけに任せず、データアクセスの層でも守る設計にしています。単にクエリに条件を付けるのではなく、ブランドをまたいだデータアクセスが起きないよう、基盤側で制約を持たせています。
Hermes や Hestia も、Iris から呼び出される独立したドメイン基盤として、ブランドの文脈を受け取りながら、それぞれの責務を実行します。これにより、カード管理画面の提供単位と、決済・請求・審査の基盤を切り離して進化させられます。

6. これから

法人カード基盤の外部提供という挑戦は始まったばかりです。

現時点で、複数のブランドが同一コードベースから独立してデプロイ・運用されています。新しいパートナーのカード基盤を立ち上げるために必要な期間は、大幅に短縮されました。

今後は、新ブランドのオンボーディングの更なる自動化、数万社の利用データを活用した与信モデルの強化なども進めていきます。

UPSIDERが目指すのは、単なるカード発行会社ではなく、挑戦する企業を支える金融インフラです。このリアーキテクチャは、その構想を技術で実現するための土台です。

法人カード基盤の外部提供の挑戦技術ブログバトンリレー

各エンジニア組織が法人カード基盤の外部提供の挑戦の中で得た知見を順次公開していきます！技術、開発設計や思想、Tipsなど、幅広くお伝えします。

▼公開予定表（各記事公開後、リンク集になります）

タイトル	チーム	執筆者
UPSIDERのカード基盤を「外部提供できる形」にするまで——マイクロサービス化とマルチブランドアーキテクチャ	法人カード基盤の外部提供全体構想	Mitsui
Spanner Change Streams を自前で読む ― 決済データを欠損なく取り込む	カード管理基盤チーム（Solaris）	Ohsako
1年動き続けるワークフローを壊さずにデプロイする ― Temporal Worker Versioning 導入記	請求基盤チーム（Hermes）	nishiwaki
GCP Error Reportingで「最低限の異常検知」を低コストに実現する	法人審査基盤チーム（Hestia）	Mitomi
複数の銀行データソースを1つに束ねる ― マルチブランド法人カードを支える銀行連携基盤	銀行連携基盤	terry
仮説駆動で取り組む負荷試験計画	processor	Kinsho
AIが実装しレビューする時代に、プロダクトエンジニアは何をするのか	お客様向け管理画面チーム（Iris）	Akari
法人カード基盤の外部提供にも耐えうる不正利用対策基盤の構築	Anti-fraudチーム	Ryutaro
法人カード基盤の外部提供という挑戦決済基盤を「他社にまるごと使ってもらう」QAの話	QAチーム	Naoki