クレジットカード決済システムは、厳格なセキュリティが求められるのはもとより、膨大なトランザクションや複雑な業務要件といった「制約」が極めて多い。そんななか、PayPayカード株式会社はこのような状況下でもエンジニア主導で「スピード」と「信頼性」を追求してきた。

本イベントでは、PayPayカードのエンジニアが、「制約のある環境でいかに意思決定を下し、技術を具体化してきたのか」について、その取り組みと創意工夫が明かされた。

アーカイブ動画

カード発行開始から5年で有効会員数1,500万人を突破

PayPayカード株式会社
テクノロジー統括本部 グロースプロダクト本部
グロースプロダクト開発部 部長
吉田 拓也（よしだ・たくや）氏

最初に登壇したのは、吉田 拓也氏。2018年にヤフー株式会社（現LINEヤフー株式会社）に中途入社後、PayPayカードの前身である「Yahoo! JAPANカード」の入会フォームや会員サイトの開発に従事。その後、「会員数を伸ばすポテンシャルがあること」や「ユーザーに寄り添った新しい決済体験を作れること」を理由に、2023年にヤフーからPayPayカードへ転籍した。

現在は主にミニアプリやWebアプリなど、フロントエンド領域を中心としたシステム開発全般のマネジメントを担う。

「圧倒的No.1のサービスをすべてのお客さまに！」をビジョンに掲げるPayPayカードは、ユーザー数7,200万人を超えるPayPayの巨大な基盤を軸にしたPayPay銀行やPayPay証券のほか、ソフトバンクやLINEヤフーといった各社とのグループシナジーに注力している。

お客さまの「払う」を自由自在に、サービス同士をシームレスにつなぎ、日本で圧倒的なスタンダードとなるキャッシュレスサービスの創出を目指している。

PayPayカードの事業状況については、Yahoo! JAPANカードの会員を引き継ぎ、現在までに有効会員数は1,500万人を超えるまでに成長した。その一方で、PayPayからのカード送客を考えると、まだまだ成長余地は大きく、ユーザーにとって本当に使いやすく、価値のある体験の提供が求められている。

Yahoo! JAPANカード時代の基幹システムをAWSに移行

次に、吉田氏はプロダクトチームのアップデートについて説明した。

2021年にPayPayカードをローンチし、そこからYahoo! JAPANカード時代の基幹システムのリプレイスに着手。自社データセンターのオンプレミス環境をAWSの環境に移行し、システムの8割ほどはAWS環境で動く形になった。さらにはCOBOLからJavaへとリライトを行い、2023年にリプレイスを完了させた。

2024年以降は「次のフェーズ」として、アジャイル開発の導入やグローバルメンバーと協働した開発、AI活用など新たな取り組みも進めている。

また、カード会員数の増加で決済回数も大きく伸長しており、Yahoo! JAPANカードの時は年間約2.8億回だった決済回数が、現在では7.6億回まで拡大。PayPay上で利用可能な「PayPayクレジット」やタッチ決済が決済回数の伸長に寄与している。

2日に1回のリリースでスピード感と柔軟性を両立

クレジットカード事業は、法規制や高度な品質要件から「リリースまでの壁が高く、開発サイクルが長期化しやすい」という課題があるなか、アジャイル開発を推進している。

具体例として、PayPayアプリからスムーズにPayPayカードの決済機能を利用できる「ミニアプリ」の開発では、2022年2月のローンチから2024年までの期間で、実に約615回のリリース回数に及んだ。

大規模な機能実装から細やかなUI改善に至るまで、圧倒的な頻度でリリースを重ねており、スピード感と柔軟性を両立させた開発を実現している。

そして、PayPayカードは物理カードに加え、先述のPayPayクレジットやカードを複数枚持てる「複数枚発行」機能の提供を開始。さらにPayPayのコード決済に対応している加盟店であれば、PayPayカードを実質的にコード決済として使える環境を提供している。

2025年5月には、審査や年会費なしで、PayPayの残高から支払えるバーチャルカード「PayPay残高カード」をリリース。Google Payとの連携など、日常使いでの利便性を高める機能の開発にも着手している。

アプリにリアルタイムでプッシュ通知が届く仕組みになっており、不正利用があった場合でもすぐに気づくことができる。このようにPayPayカードでは、「安心安全や利便性を追求した機能開発を進めている」と吉田氏は強調した。

自社に最適化したAI-DLCで開発スタイルの刷新を目指す

開発体制はプロダクトラインで組織を分けており、「グロースプロダクト本部」と「決済プロダクト本部」がユーザー向けプロダクトを担当し、「システム本部」と「DX推進本部」は社内の業務関連システムに携わっている。

開発組織では、「最適な「支払い」をいつでも。おトクで安心なPayPayライフを。」というプロダクトビジョンをもとにOKRを設定し、PayPayカードのユーザーに提供している機能を「獲得」「ライフサイクル」「収益」の三つの領域に分類。

これらの各領域で成果指標（KR）を定め、四半期ごとのロードマップに沿ってどういう開発をしていくかを決めていく。

直近では、コード品質向上のために「Instruction.md」を用意し、GitHub Copilotを活用してプルリクエストのレビューを行ったり、GitHub CopilotやCodexを積極的に取り入れたりとAI活用に注力しているという。

加えて、組織文化とチーム力の底上げにも力を入れており、例えば「AIエージェントデー」というものを定期的に開催し、開発現場にAIを浸透させていく取り組みも行っている。

「今後はAWSが提唱する『AI-DLC（AI駆動開発ライフサイクル）』を自社向けにアレンジし、開発全体に適用していきたい」と吉田氏は抱負を述べた。

「オーソリ」と「売上」のステータス管理をUI上で統合

PayPayカード株式会社
テクノロジー統括本部 決済プロダクト開発部
ミニアプリ2グループ マネージャー
佐藤 宏哉（さとう・ひろや）氏

2人目の登壇者は、佐藤 宏哉氏。2018年にソフトバンク株式会社に入社後、ブロックチェーンを活用した国際決済プロジェクトの立ち上げに関わり、2023年よりPayPayカードに出向した。

佐藤氏は、PayPayカードの支払い情報がPayPayアプリの「取引履歴」からリアルタイムで確認可能な機能のリリースに関わってきた。設計・開発・テストの期間を経て、全体でおよそ5か月という短期間でサービスリリースを実現。

これまでもPayPayカード利用時の通知サービスは存在していたが、ユーザー体験には大きな制限があった。従来の仕組みでは、決済通知が届いても詳細を確認するにはミニアプリを経由する必要があり、表示される履歴も「過去3日分・最大20件まで」という制約が存在した。

今回のプロジェクトでは、これらを抜本的に改善した。PayPayアプリの「取引履歴」画面上でリアルタイムに内容を確認できる体制を整備した。

さらに、通知の対象を従来の「300円以上の決済」から「3円以上の決済」へと大幅に拡大した。決済の成功時だけでなく、失敗や取消の際にも通知が届くようになり、さらにはキャンペーンと連動した「スクラッチチャンス」への即時アクセスも可能にするなど、安心感とお得さを同時に提供するUXを実現するに至った。

このリアルタイム連携を実現するため、佐藤氏のチームはクレジットカード業界特有の処理プロセスである「オーソリ（支払い受付）」と「売上（支払い完了）」のステータス管理をUI上で統合することに注力した。

システム構成としては、カード利用時に発生するオーソリ情報を、中間システムである「クッション」が受け取り、ID変換やフィルタリングを実行した上でプッシュ通知やメール配信へと繋げる。一方、後日発生する売上確定プロセスでは、基幹システムが受信した売上データを情報系システム経由で再び「クッション」へ戻し、PayPayのバックエンドに直接連携する構成をとっている。

以上のようなシステム変更を加えたことで、特定のオーソリに対してどの売上が紐付いたかという相関関係を正確に把握できるようになり、アプリ上では一連の流れが一つの取引として統合的に表示することが可能となった。

カード業界特有の「壁」を乗り越えた開発の舞台裏

しかし、実装にあたってはカード業界特有の「仕様の複雑さ」が大きな壁として立ちはだかった。オーソリ一つをとっても、通常の承認、失敗、取消、さらには通信障害時に行われる特殊な処理など、無数のパターンが存在する。

売上についても同様で、キャンセル（赤売上）や再計上などがあり、これらの組み合わせは多岐にわたる。そのほか、実際の利用シーンを想定すれば、カード決済の全額キャンセルや一部キャンセル、支払い方法の変更など、あらゆるパターンに対して厳密に対応するロジックの考慮が求められた。

これに対し、佐藤氏は「すべてのパターンを可視化し、一つひとつ地道に整理を重ねた」と語る。また、エンジニアが自分の担当外の領域まで深く理解し、全体像を把握することで、「どのレイヤーで処理すべきか」を即座に判断できる体制を整えたのである。

他にも、PayPay側のナレッジを活用したペアプログラミングなどを通じて、社内に高度な知見を蓄積していった。

しかし、1,500万人を超えるユーザーを抱えるPayPayカードにおいて、通知の不備や二重決済の懸念は決して許されない。安全な切り替えを実現するため、「ベータテスト」「カナリアリリース」「フィーチャーフラグ」を駆使した慎重な手順を採用した。

まず、データは新旧両システムに流した状態で、社内の特定ユーザーのみに機能を開放して検証を実施。その後、フィーチャーフラグを使って公開タイミングを制御し、ユーザー単位で段階的に新システムへ移行した。

万が一インシデントが発生した場合でも、すぐに元に戻せる状態を維持することで、安全かつ確実なリリースを実現した。

「銀の弾丸はない」。ベストプラクティスの積み上げが重要

リリースの具体的な手順は以下の通りである。

まず、オンプレミスの決済処理システムから、オーソリデータをマイクロバッチ形式で内部のデータベースに取り込む。最初のステップとして、データ連携は行わずに新システムのアプリケーションのみを先行リリースした。

次に、旧システムと新システムの両方に流す構成に切り替えを行った。この時点で新システム側では、PayPayバックエンドへのデータ連携も開始し、あわせてフィーチャーフラグをオフにすることで、通知は従来どおり旧システムからのみ配信されるように制御した。

その後、社内の特定ユーザーに限定して新システムからの通知を有効化し、複雑なオーソリ仕様を含む本番データを用いたベータテストを実施。最後に、パブリックローンチのタイミングでフィーチャーフラグをオンに切り替え、通知の配信元を新システムへ完全移行した。

チーム運営においても課題が存在した。プロジェクト開始直前に新設されたチームは発足当初、メンバーの経験値にばらつきがあり、特定の個人に負荷が集中する状況だった。さらに少数精鋭で開発していたため、個々のタスクを進めることに精一杯となり、レビューがどうしても後回しになる状態だったという。

そこで、アジャイル開発におけるKPT（振り返り）を継続的に行い、毎日1時間の「レビュー会」を設けるなど、仕組みによってチーム力を底上げした。またPayPay側の英語話者との連携では、生成AIが普及する前だったということもあり、口頭でのコミュニケーションだけでなく「図やフローへの書き起こし」による視覚的な認識共有を徹底した。

佐藤氏は、システム面・チーム面の課題解決に「銀の弾丸は存在しない」と強調する。世の中にあるベストプラクティスを一つひとつ着実に取り込み、地道な改善を積み上げていくこと。その姿勢こそが、カード業界特有の複雑な制約の中で、ユーザーに新しい価値を届ける「品質」と「スピード」の両立につながったのである。

ドメイン駆動設計（DDD）で挑んだ「膨大な複雑性」の解消

PayPayカード株式会社
テクノロジー統括本部 決済プロダクト開発部
決済バックエンドグループ
Abhishek Jain氏

3人目の登壇者であるAbhishek氏は、ドメイン駆動設計（DDD）を用いて決済処理アーキテクチャを再構築した事例を紹介した。

PayPayカードにおける決済処理の根幹的な課題は、統合システムの肥大化であった。単一のリポジトリにあまりにも多くのコンテキストが詰め込まれたモノリシックな構造は、軽微な改修であっても広範囲な影響調査と大規模なテストを強いられる状況だった。結果として、開発リードタイムは著しく低下し、「膨大な複雑性」こそが最大のボトルネックになっていたわけだ。

システムの刷新にあたり、機能要件としては「既存機能の完全な維持」が絶対条件とされた。決済インフラとしての信頼性を損なうことは許されないからだ。一方、非機能要件では「新機能追加の容易性」が最優先課題となった。具体的には、テスト自動化の徹底によるカバレッジ90％以上の確保、および1,500万人規模のユーザーを支える99.99％の稼働率と、膨大なトランザクションに耐えうるスケーラビリティの構築が求められた。

Abhishek氏は、これらの要件を実現するうえで「開発者の視点」と「ドメインエキスパートの視点」が合致することが大事になると述べた。

例えば「リボ払い」の実装において、開発者が単に「シーケンス番号による条件分岐」としてコードを記述すれば、ビジネスチームが考える「ユーザーがお金を借り、利息を付けて返済する」という本質的な仕組みとの間に乖離が生じる。

これがまさに、ドメインエキスパートの意図がコードに反映されてない“断絶”だとAbhishek氏は語った。

モノリシックなシステムを再構築し、マイクロサービスへと分割していくのにあたって重要なのは、単にシステムを分けることではない。コードを理解しながら、その構造自体が「サービスの意味」を正しく表現している必要があるわけだ。

そこで肝になるのが、ドメイン駆動設計（DDD）における「ユビキタス言語」である。ビジネスチームとの議論を通じて、Abhishek氏は「取引とは単なるデータの記録ではなく、ユーザーとの『契約』に基づく法的拘束力を持つイベントである」という本質を導き出した。

単にテーブルへデータを入力するのではなく、現実のビジネスロジックをシステムが正しく理解できる「メンタルモデル」を構築することで、コード構造そのものがサービスの意味を表現する状態を目指したのである。

各サービスの自律性と独立性を担保するための取り組み

ただ、物理的にシステムを分けるだけでは、依存関係が複雑に絡み合う「分散されたモノリス（巨大な泥団子）」の状態に陥るリスクがある。

これを回避するため、Abhishek氏は「境界づけられたコンテキスト」の導入を徹底した。特定のルールが一貫して適用される範囲を明確に定義し、チーム内でアーキテクチャや設計方針、プロセスについての合意形成を図った。

さらに、クレジットカードの開発・決済処理という複雑なドメインを整理し、「システムの保守性維持」と「スケーラブルな基盤構築」を図るために、DDDの構成要素を厳密に適用した。

決済処理の中のコンテキストにおいては、「1つのマイクロサービス＝1つのアグリゲート」という原則を徹底することで、各サービスの自律性と独立性を担保したとAbhishek氏は説明した。

アーキテクチャの最適化には、カード管理側の「書き込みモデル」と決済処理側の「読み取りモデル」を分離する「CQRS（コマンド・クエリ責任分離）」を採用し、さらにイベントソーシングを組み合わせることで、システムの負荷耐性と柔軟性を高めた。

また、カード管理領域（Card, Contract, Customerの3C）との連携においては、状態の変化をイベントとして受け取るデカップリングを実現。各サービスが互いの詳細なロジックを知ることなく独立して進化できる構造を作り上げた。

ACLでレガシーシステムとの依存関係を分離

刷新プロジェクトにおいて避けて通れないのが、既存のレガシーシステムとの共存である。Abhishek氏は、レガシー特有の不透明な仕様が新システムを侵食しないように「腐敗防止層（ACL）」を活用した。データをACLで変換してから受け入れることで、依存関係を切り離し、新システムが独自のコンテキスト内でクリーンに動作することを可能にした。

このように、DDDの概念を正しく適用し、ビジネスの本質をコードへと昇華させたことで、PayPayカードはレガシーからの脱却と、将来の成長に耐えうる強固な決済基盤の構築に成功したのである。

【Q&Aセッション】

Q&Aセッションでは、PayPayカード株式会社のメンバーがイベント参加者からの質問に回答した。

Q. 現在はAWSが8割とのことだが、最終的には全システムをAWSへ移行するのか

吉田氏：最終的には、システム全体をフルクラウド化することを目標としていて、現時点で残っている約2割の部分も、順次AWSなどのパブリッククラウド上に移行していく予定です。この残りの2割は、PayPayカード固有の課題だけでなく、審査を行うシステムや「FEP（Front-End Processor）」と呼ばれる決済処理システムなど、クレジットカード業界全体に共通するものが該当します。

これらのシステムは、外部ベンダーが提供するパッケージソリューションに依存しており、まだ完全なクラウド化には至っていません。外部ベンダーに発注して開発するプロセスだとどうしても時間がかかってしまうので、現在は審査システムや決済システムの内製化を進めることで、開発スピードの向上に取り組んでいます。

Q.「支払い情報リアルタイム確認機能」のプロジェクトは、開発途中でウォーターフォールからアジャイルへ開発手法を変更したのか

佐藤氏：最初からアジャイル開発を前提に進めていましたが、PayPayや基幹システムなど複数社が関わる大規模な案件でしたので、全体のタイムラインとしてはウォーターフォール的に合流点を設定する部分もありました。一方で、内部の開発自体はアジャイルで進めるという形を取り、両者を併用してプロジェクトを進行していました。

Q.モノリスからマイクロサービスへの段階的な移行をスムーズに行うには

Abhishek氏：移行にあたっては「何をテストすべきか」の定義と、共通チェック項目の洗い出しを徹底しました。統合テストやエンドツーエンドのテストのほか、QA環境でもマイクロサービス単位のテストを実施したのです。さらにモノリシックからの結果を見たうえでレイヤーアダプターを作成し、システム内で旧システムの結果と一致するかを検証しました。

また、移行をスムーズに進めるため、開発中のシステムに対しても複数の課題解決が必要でした。オンプレミスからAWSへの移行は大半が完了しており、アーキテクチャ自体への影響は小さかったものの、非機能要件は厳守することが絶対条件となりました。そのため、移行戦略はアダプター層の設計やデータの正確な復元、ACLの作成など、既存業務や業界ルールを破壊しないための対応が求められました。

Q.ドメインイベントの設計定義は誰が行うべきか

Abhishek氏：基本的にパブリッシャー側で管理されます。ドメイン駆動のイベントは、アグリゲートのライフサイクルに沿って発生するため、ライフサイクルに変化があれば、対応するドメインイベントがパブリッシュされます。サブスクライバー側にも影響は及びますが、最終的なドメインイベントの公開はパブリッシャー側で行われます。

Q.マイクロサービスの1つの規模感が知りたい

Abhishek氏：詳細な分析はあまり行っていませんが、システムを構築する際には3000TPSをサポートできる構造となっています。トランザクションの処理時間については各サービスのSLAが定められており、例えば30ms程度で処理するサービスも存在しますので、マイクロサービスを設計する際にはこうした数値を考慮することが大事です。

また、99.99％のアップタイムを達成するにはマネージドリソースを利用するのか、同期型のプロセスを設計するのかといった点も含めて必要なリソースをすべて特定する必要があります。

Q.素早い開発・リリースでネックになるのが「上位者の合意」だが、何か工夫していることはあるのか

吉田氏：UI/UXの方針については上司や関係者との合意形成のフローが整備されています。例えば、UI/UXの承認に関しては週に2回「UI/UX承認会」が開催され、CXOが出席してUI案やUX上の問題点を確認・承認します。さらに、定期的に経営層にも進捗や新しい取り組みを共有し、意見をもらうことで、方向性や軸がぶれないようにしています。

佐藤氏：現場レベルでも、承認プロセスを単なるルールの積み重ねとしてではなく、「いかに短期間でリリースできるか」を意識して、必要なプロセスを定期的に見直しています。こうした継続的な改善により、スピード感のあるリリースが可能になっています。

Q.開発は内製が中心か、それとも外部ベンダーを活用しているのか

吉田氏：PayPayカードの開発は、主に外部の業務委託を中心に進めていましたが、ここ数年で状況は大きく変わり、現在は社員の開発者が多くを占めています。そのため、開発は基本的に内製化され、社員主体で進めていくのを前提に、社員だけでは対応しきれない部分については、業務委託と協力して開発を行う形を取っています。

文＝古田島 大介

※所属組織および取材内容は2025年12月時点の情報です。

PayPayカード株式会社
https://www.paypay-card.co.jp/company/

PayPayカード株式会社の採用情報
https://www.paypay-card.co.jp/recruit/