多様なシステムが複雑に絡み合うPayPayカードの決済基盤において、QAチームはどのような技術的チャレンジに向き合っているのでしょうか。本記事では、バックエンド自動化フレームワークCSAEの設計思想から、AIを活用したテスト生成プラットフォームATLASの取り組みまで、QAエンジニアの枠を超えて開発プロセス全体を支えるQA Platform Teamの挑戦と知見をAmitが紹介します。
Amit Srivastava
PayPayカード QA Platformチーム エンジニアリングマネージャー
10年以上にわたるソフトウェアエンジニアリングの経験を持ち、現在はカード発行・サービス関連システム全体の自動化戦略を推進するQA Platformチームをリード。エンタープライズレベルのテスト基盤構築、SDETチームのスケーリング、高スループットな決済システムにおけるAI活用型Quality Engineeringの加速を専門としています。
はじめに
フィンテックの世界では、信頼性は「あればよいもの」ではありません。サービスを支えるための土台そのものです。PayPay Cardでは、レガシーな基幹システム、モダンなサービス、バッチ処理、そしてお客さま向けアプリケーションまで、多様なシステムをまたいで日々何百万件ものトランザクションが処理されています。こうした環境で安心してリリースを続けるためには、個々の自動テストだけでは十分ではありません。異なるシステムに対しても、一貫した方法でテストを定義し、実行し、保守できるプラットフォームが必要です。私たちQA Platformチームが取り組んでいるのは、まさにその基盤づくりです。私たちは、開発が完了した後に回帰テストを実行するだけのチームではありません。決済フローを検証し、不具合の原因を分析し、組織全体でテストをスケールさせるために、他のエンジニアが利用する社内向け自動化プラットフォームを開発しています。
QA Platform Teamが構築しているもの
私たちの仕事を最もシンプルに表現するなら、「決済システムに携わるエンジニアのための共通自動化基盤をつくること」です。対象となるのは、コアとなる決済フローを支えるバックエンドの自動化だけではありません。お客さま向け・社内向けWebアプリケーションのブラウザ自動化や、テストの設計・運用に必要な手作業を減らすための社内ツールも開発しています。これらのプラットフォームを利用するのはQAエンジニアだけではありません。開発者や、CI/CDの中で信頼できるフィードバックを必要とする各開発チームも日常的に活用しています。
実際に、私たちのプラットフォームは、さまざまなニーズに応えるための取り組みを支えています：
- 重要な決済フロー全体をカバーするエンドツーエンドの自動化
- 単一の技術スタックでは完結しないシステムに対する、複数のプロトコルをまたいだ検証
- GitHub Actionsや連携するデリバリーフローを通じて繰り返し実行できる、セルフサービス型の自動化
- 要件から実用的なテスト資産を作成するまでにかかる時間を短縮する、AIを活用したワークフロー
私たちはPlatform EngineeringとQuality Engineeringのちょうど中間に位置しています。目指しているのは、自動化率を高めることだけではありません。エンジニア組織全体で、「信頼できるテスト」をより簡単に活用できる環境をつくることです。
Core System Automation ― なぜCSAEが必要だったのか
私たちの取り組みの中核となるのが、バックエンド自動化フレームワーク「Core System Automation Engine（CSAE）」です。CSAEはSpring Bootをベースに構築したフレームワークで、決済システムのテストの中でも、特に標準化が難しい領域―複数のプロトコルが混在するシステム、長時間実行されるジョブ、そして共有されたデータ状態を扱うために設計しました。
こうした領域では、一般的なAPIテストフレームワークだけでは十分ではありません。実際のE2Eシナリオでは、バッチジョブを起動し、内部プロトコルでメッセージを送信し、下流システムの処理完了を待ち、データベースの状態を検証したうえで、APIやバックオフィス画面の結果を確認する必要があります。決済システムでは、これら一連の処理が、それぞれ異なる時代や異なる目的で構築された技術基盤をまたいで実行されることが珍しくありません。
だからこそ私たちは、CSAEを単なるテストスクリプトの集合ではなく、プラットフォームとして設計しました。異なるインターフェースをひとつのシナリオの中でオーケストレーションしながら、システムが進化しても保守し続けられること。それが、私たちがCSAEに求めた役割です。
フレームワーク設計を形づくった3つの技術的な課題
CSAEを設計するにあたり、私たちが最初から向き合わなければならなかった技術的な制約は、大きく3つありました。
1つ目は、非同期処理です。多くの決済フローは、1回のリクエストとレスポンスだけで完結しません。バッチ処理やスケジュール実行、下流システムでの後続処理などがあるため、フレームワーク側で待機やポーリング、検証のタイミングを適切に制御する必要があります。
2つ目は、プロトコルの多様性です。1つの業務フローの中で、独自のサービスインターフェースを通じた連携、セキュアな経路で転送されるファイル、Kafkaイベント、RESTやgRPCサービス、さらにISO 8583による金融メッセージまで扱うことがあります。こうした異なるインターフェースを、それぞれ個別に扱うのではなく、ひとつの業務フローとして実行できるテストエンジンが必要でした。
※注：一部の連携インターフェースは以前のシステム世代から引き継いだものであり、プラットフォームの継続的な進化の一環として段階的にモダナイズを進めています。
そして3つ目は、データの整合性です。テストを高速に実行するためには並列実行が有効ですが、共有のQA環境では、Oracleをはじめとする永続データの競合が発生することがあります。こうした状態を適切に制御できなければ、自動テストは不安定になり、やがてチームから信頼されなくなってしまいます。
Executorベースのアーキテクチャを採用した理由
こうした課題に対応するため、CSAEではStrategy Patternを採用し、Executorベースのアーキテクチャを設計しました。すべてのプロトコル処理をひとつの巨大なテストエンジンに組み込むのではなく、それぞれのインターフェースごとにExecutorとして責務を分離しています。そして実行時には、シナリオの各ステップに応じて適切なExecutorが呼び出される仕組みです。
この設計を採用した理由は、保守性を高めるためです。新しいシステム連携が追加された場合でも、オーケストレーション全体を書き換える必要はありません。必要なのは、そのインターフェースに対応するExecutorを追加・拡張することだけです。その結果、技術的な実装が変わっても、ビジネスシナリオはできるだけ変更せずに維持できるようになりました。
また、シナリオはYAMLで宣言的に記述できるようにしています。これは単に読みやすさを意識したわけではありません。テスト作成者が、フレームワークのコードを変更することなく業務フローを記述できるようにするためです。
この設計によって、より多くのエンジニアがプラットフォームに貢献しやすくなり、新しい決済シナリオが増えても、比較的低いコストで自動化の対象を広げられるようになりました。
CSAEはどのように動いているのか
CSAEには、私たちが日常的に扱うさまざまなインターフェースに対応する専用のExecutorが用意されています。
この設計で目指したのは、モジュール化されたフレームワークを作ること自体ではありません。ビジネスシナリオはあくまで業務の流れに集中して記述し、それぞれのプロトコル固有の処理は再利用可能な部品としてカプセル化すること。それが、このアーキテクチャの考え方です。
プラットフォームの規模と開発者への価値
現在、このフレームワークは、コアとなるバッチ処理だけで数百規模のE2E自動化シナリオをサポートしており、プラットフォーム全体ではさらに数千に及ぶAPIおよびUIシナリオを網羅しています。これらは、カードのライフサイクル全体に加え、顧客向けのユーザージャーニーや社内サービス間のインテグレーションテストまで幅広くカバーしています。
これらのシナリオはGitHub Actionsを通じて毎日実行され、システムを開発・運用する各チームへ継続的な回帰テストの結果を提供しています。開発者にとってのメリットは非常にシンプルです。コードの一部分だけではなく、「実際の決済フロー全体」が変更によって壊れていないかを、より早い段階で把握できます。
決済システムでは、障害が複数のシステムにまたがって発生することも珍しくありません。だからこそ、実際の業務フローに対する継続的な回帰テストを実行できることには、大きな価値があると考えています。
プラットフォームの信頼性を高めるために重視した設計
プラットフォームが成熟していく中で、特に重要になった設計上の判断がいくつかあります。まず必要だったのが、冪等性を考慮した並列実行の制御です。共有環境でテストを並列実行すると、データの競合が起きやすくなります。自動化を高速化しても、その結果が不安定になってしまっては意味がありません。そのため私たちは、ロック機構や実行制御を導入し、スピードと安定性を両立できるようにしました。
次に重要だったのが、Observability（可観測性）です。自動化基盤が日々の開発プロセスに組み込まれると、フレームワーク自体も1つのプラットフォームとして振る舞います。障害が発生した際には、それがアプリケーションの問題なのか、実行環境の問題なのか、それともフレームワークのオーケストレーション層の問題なのかを切り分けられなければなりません。そのため、計測やモニタリングを取り入れ、単なるテストスイートではなく「システム」としてプラットフォームをデバッグできるようにしています。
また、YAMLベースのシナリオ設計も、スケールさせるための重要な判断でした。新しいシナリオを追加するたびにフレームワーク開発が必要になるのではなく、より多くのメンバーが自動化に参加できるようにすること。そして、新しい決済シナリオにも柔軟に対応できることを重視しています。
さらに、同じ業務フローを複数の接続環境で実行するために、マルチプロファイルによる環境切り替えにも対応しています。再利用可能なプラットフォームである以上、環境ごとの差異を吸収しながら、シナリオを重複して管理しなくて済むことが重要だと考えています。
Payment-autoqa-PlaywrightによるWeb自動化
バックエンドの自動化だけでは十分ではありません。ユーザーや運用担当者が実際に利用するWeb画面も含めて、決済体験全体を検証する必要があります。
そこで私たちは、「Payment-autoqa-Playwright」というPlaywrightベースの自動化基盤も開発しています。Node.js、Playwright、Cucumberを活用し、ブラウザ操作を自動化するとともに、テスト管理やCI/CDプロセスと連携しています。これは、UI、バックエンド、そして周辺システムがすべて正しく連携して初めて、決済フローが完成すると考えているからです。このリポジトリの価値は、単に画面操作を自動化することではありません。ユーザー視点での振る舞いを自然なシナリオとして記述し、それを継続的に実行し、定義されたテストケースと結び付けられることにあります。言い換えれば、ブラウザ自動化もバックエンド自動化と同じ「プラットフォーム」という考え方の中で扱い、別々の仕組みとして分断しないことを目指しています。
AIを活用したテストエンジニアリング「ATLAS」
現在、私たちが力を入れて開発しているもう1つの取り組みが、AIを活用したテスト作成プラットフォーム「ATLAS（AI Testing Lifecycle as a Service）」です。ATLASが目指しているのは、プロダクト要件や技術要件を、実行可能なテスト資産へ変換するまでに必要な手作業を減らすことです。
この課題に取り組む価値があると考えているのは、テスト作成のプロセスでは、繰り返しの作業や受け渡しが多く発生するからです。PRDを読み込み、テスト計画へ落とし込み、個々のテストケースに分解し、必要なデータを作成し、最終的に自動化資産へ変換する。ATLASは、この一連のプロセスをより短く、効率的にすることを目指しています。ATLASの役割は、エンジニアの判断をAIに置き換えることではありません。テスト作成に伴う機械的な作業を減らすことで、エンジニアがテストの意図やカバレッジ、エッジケースのレビューなど、本来人が判断すべき部分により多くの時間を使えるようにすることです。
ATLASは、専門的な役割を持つ複数のAIエージェントが、それぞれ異なる工程を順番に担当するマルチエージェント・パイプラインとして構成されています。
- 要件分析（Requirements analysis）
PRD、既存の仕様書、ビジネス上の参照資料などを取り込み、構造化された日英バイリンガルのビジネスサマリーを生成します。 - システム設計の生成（System design generation）
要件をインターフェースやデータベーススキーマにマッピングし、分岐ごとの実行経路まで含めて、処理フローをステップ単位で分析します。 - テストカバレッジ／テスト計画の設計（Test coverage / Plan design）
テスト観点となる要素に基づいたカバレッジ戦略を提案します。ここには人による承認プロセスが設けられており、承認されるまでパイプラインは次の工程へ進みません。 - 自動化資産の生成（Automation asset generation）
承認されたテストケースを、私たちのCSAEフレームワークで実行可能なスクリプトへ変換します。生成はリクエストに応じて、1ケースずつ行います。
ATLASのアーキテクチャにおいて、特に重要な設計判断の一つが、この承認ゲート（Approval Gate）です。ATLASはカバレッジ戦略を提案した段階で一度処理を停止し、エンジニアによる承認を得た後にのみ、次の工程へ進みます。AIにすべてを任せて自動的に処理を進めるのではなく、AIが生成する成果物を常にエンジニアの判断に基づいたものにするための仕組みです。また、パイプラインにはフィードバックを処理する仕組みも組み込んでいます。構造化されたレビュー内容を受け取り、そのフィードバックに基づいて、生成済みの成果物の必要な箇所を修正できるようにしています。
開発者体験を支える取り組み
QA Platform Teamが支えているのは、自動化フレームワークだけではありません。CI/CDのオーケストレーション、自動実行やレポーティングの仕組み、社内ドキュメントの整備、さらに自動化をより見つけやすく、利用しやすくするための各種プラットフォーム連携も私たちの役割です。
こうした取り組みは、個々のテストシナリオやAI機能ほど目立つものではありません。しかし、フレームワークを「実際に使われるプラットフォーム」へ育てるためには欠かせない要素だと考えています。
モバイル自動化について
また最近では、バックエンドやWebでの取り組みと同じプラットフォーム思想に基づき、モバイルアプリのテスト自動化基盤の構築にも着手しています。共通のコアフレームワークと、各プロジェクト向けのスキャフォールディングを組み合わせる構成です。
技術スタックはJavaをベースとし、自動化エンジンとしてAppium（AndroidではUIAutomator2、iOSではXCUITest）、BDDスタイルのシナリオ作成にはCucumber、実行管理にはTestNG、複数デバイスでのクラウド実行にはBrowserStackを使用しています。
アーキテクチャは、主に以下のリポジトリで構成されています。
- 再利用可能な機能を提供するコアライブラリ：Screen Objectパターン、ジェスチャーやタッチの抽象化（MobileActions、Direction）、プラットフォームを考慮したドライバー管理（AndroidDriverFactory / IosDriverFactory）、ローカルのAppium環境とBrowserStack環境の両方に対応するCapabilityの解決、データベースユーティリティ、Allureレポートとの統合、フローオーケストレーションレイヤーなど、再利用可能な機能を提供します。
- プロジェクト固有のテストリポジトリ：チームがドメインごとに整理してCucumberのFeatureファイルを作成。コアアプリのフロー、金融サービス、請求書払い、ミニアプリのジャーニー、オンラインチャネルなどをカバーしています。
この取り組みは、バックエンドやWebのプラットフォームと比べると、まだ発展途上にあります。そのため、現時点で完成されたプラットフォームとしての位置づけではなく、現在進行形で拡張・成熟させているケイパビリティとして捉えています。
これから目指すこと
これからも私たちが目指す方向は変わりません。テスト基盤を開発ライフサイクルのより早い段階へ取り込み、さまざまなシステムでより使いやすいものへ進化させていくことです。そのために、PRDや技術設計の段階から品質を考えるシフトレフトをさらに推進し、バックエンドとブラウザ自動化の両方を強化するとともに、AIによるテスト作成と実行可能な自動化資産との連携も深めていきます。目指しているのは、個別のツールを増やすことではありません。さまざまな仕組みをつなぐ1つのプラットフォームを通じて、チームがより少ない手間で、より信頼性の高い決済体験を届けられる環境を実現したいと考えています。
おわりに
私がこの仕事で最もやりがいを感じているのは、自動化の役割そのものを変えられることです。テストを開発の最後に追加するものではなく、チームが設計し、開発し、リリースするプロセス全体を支える共通基盤として捉えています。私たちは、個々のテストではなく、プラットフォームをつくっています。その結果として、エンジニアリングチームが、大規模な決済システムにおいても信頼性の高いサービスを届けられるよう支えています。もし、こうしたPlatform Engineeringに興味をお持ちでしたら、ぜひお話ししましょう。
