kickflow Tech Blog

株式会社kickflowのプロダクト開発本部によるブログ

kickflowのE2E・APIテストの全体像と今後の展望（2026年1月版）

AI Autify Claude Code E2Eテスト Postman QA 自動テスト Cypress Playwright

クモは目的に応じて最大7種類の異なる糸を使い分ける
クモは目的に応じて最大7種類の異なる糸を使い分ける

こんにちは、kickflow QAチームの川村です。

kickflowでは、約800のUIテストシナリオと5,000以上のAPIアサーションでプロダクトの品質を担保しています。
本記事では、E2E・APIテストの全体像と、現在進行中のAutifyからPlaywrightへの移行について紹介します。

UIのE2Eテスト構成

まず、UIのE2Eテストで使用しているツールとシナリオ数の内訳を紹介します。

ツール シナリオ数 備考
Autify 196 Playwrightに移行中
Autify Nexus 58 一旦そのまま運用
Cypress 378 安定稼働中、後々Playwrightへ
Playwright 160 E2E 152 + パフォーマンス 8
合計 792

このように、kickflowでは複数のE2Eテストツールを併用しています。
それぞれのツールには特性があり、適材適所で使い分けることで、テストの安定性と保守性を両立させています。

Autify

Autifyは、ブラウザ操作を記録するだけでテストシナリオを作成できる、ノーコードのE2Eテスト自動化プラットフォームです。
kickflowでは初期からメインツールとして採用しており、以下のような特徴を活かしています。

  • GUIベースで直感的にシナリオを作成・編集できるため、プログラミング経験が少ないメンバーでも参加しやすい
  • メール通知の確認や外部連携のテストなど、コードベースでは実装コストが高い機能もAutifyでは容易に実装できる
  • AIによる自己修復機能で、UIの軽微な変更に対してメンテナンスコストを抑えられる

Autify Nexus

Autify Nexusは、Autify社が提供するコードベースのテストツールです。
Autifyからの移行先として検討し、一部のシナリオを移行しましたが、期待した効果が得られなかったため、現在は58シナリオをそのまま運用しています。

Cypress

Cypressは、Autifyで実装が難しいテストや不安定になるテストの補完ツールとして導入しました。
現在378シナリオが安定稼働しており、以下の点で優れています。

  • Time Travel機能により、テスト実行の各ステップをスナップショットで確認でき、失敗原因の特定が直感的に行える
  • カスタムコマンドで業務固有の操作を抽象化でき、テストコードの重複を削減できる

Cypressの活用については、以下の記事で詳しく紹介しています。

tech.kickflow.co.jp

Playwright

Playwrightは、現在最も注力しているE2Eテストツールです。
152シナリオを運用中で、以下の理由からAutifyやCypressからの移行先として採用しています。

  • AI開発との親和性が高い: Playwright MCPに対応しており、Claude Codeなどのツールと組み合わせてテスト作成を効率化できる
  • Page Object Model（POM）対応: UI変更時の修正箇所を1箇所に集約できる
  • 並列実行が標準機能: 追加コストなしで並列数をコントロールでき、テスト実行時間を短縮できる

パフォーマンステスト

Playwrightを使って、内部APIのパフォーマンステストを定期実行しています。
チケット作成・更新・検索など主要機能のレスポンスタイムを監視し、パフォーマンス劣化を早期に検知できる体制を整えています。

// パフォーマンステストの閾値設定例
const THRESHOLDS = {
  ticketCreate: 5000,           // チケット作成: 5秒以内
  ticketUpdateApplicant: 4000,  // チケット更新（申請者）: 4秒以内
  ticketUpdateApprover: 3000,   // チケット更新（承認者）: 3秒以内
  ticketSearch: 1500,           // チケット検索: 1.5秒以内
}

APIテスト

APIテストにはPostmanを使用しています。
REST APIの単体テストと結合テストを実装しており、安定運用フェーズに入っています。

テスト実績

ジョブ リクエスト数 アサーション数 実行時間
unit-test 1,573 2,845 57分45秒
integration-test 1,002 2,279 50分24秒
合計 2,575 5,124 約58分（並列実行）

単体テストでは、さまざまなパラメータでデータの取得・登録・更新・削除ができるかや、認証やバリデーションに関するエラーをチェックしています。

結合テストでは、ユーザー情報やワークフロー情報を取得後にその内容を使ってチケットを作成し、承認や差し戻しができるかなど、ユースケースを実現できるかを確認しています。

新機能リリース時に必要であれば拡張しており、現在は安定運用フェーズです。

テスト実行環境

E2E・APIテストはすべてSandbox環境に対して実行しています。
GitHub Actionsで定期実行を設定し、結果はSlackチャンネルに通知しています。

flowchart TB
    subgraph Triggers["トリガー"]
        Schedule["スケジュール実行<br/>毎朝"]
        Manual["手動トリガー"]
    end

    subgraph GitHubActions["GitHub Actions"]
        E2EJob["E2Eテスト<br/>（Autify/Cypress/Playwright）"]
        APIJob["APIテスト<br/>（Postman）"]
        PerfJob["パフォーマンステスト<br/>（Playwright）"]
    end

    Sandbox["Sandbox環境"]
    Slack["Slack通知"]

    Schedule --> GitHubActions
    Manual --> GitHubActions
    E2EJob --> Sandbox
    APIJob --> Sandbox
    PerfJob --> Sandbox
    GitHubActions --> Slack

Autify→Playwright移行の背景

現在、Autifyのテストシナリオを段階的にPlaywrightへ移行しています。
移行の理由は主に3つあります。

1. コスト削減

Playwrightはオープンソースで無料のため、Autifyによる運用と比べて大幅なコスト削減を実現できます。
SaaSツールのライセンス費用を抑えつつ、同等以上のテストカバレッジを維持できる点が魅力です。

2. UIが変更された時の保守性

Autifyでは対象画面が絡む全てのシナリオを個別に修正する必要があります。
ステップグループで共通化することも可能ですが、現実的にはログインやクリーンアップ処理くらいしか共通化できません。

一方、PlaywrightでPage Object Model（POM）化すれば、UI変更時の修正箇所を1箇所に集約できます。

// helpers/ui.ts - Vuetifyコンポーネント操作のヘルパー関数例
export async function clickSideMenuLink(page: Page, linkName: string): Promise<void> {
  await page.getByRole('group').getByRole('link', { name: linkName }).click()
}

export async function waitForToast(page: Page): Promise<void> {
  await page.locator('.v-snackbar').waitFor({ state: 'visible' })
}

3. 並列化

AutifyやAutify Nexusでは並列実行するために追加料金が発生しますが、Playwrightなどのコードベースツールでは比較的安価に並列数をコントロールできます。
テスト実行時間を短縮することで、開発完了からリリースまでのリードタイムを短縮できます。

移行方法

AutifyからエクスポートしたテストシナリオをTypeScriptにリファクタリングし、CI運用に載せています。
移行手順を標準化したClaude Codeのコマンド playwright-migrate.md を用意し、AIを活用して効率的に移行作業を進めています。

複数のQAメンバーが並列で移行作業を行えるよう、ブランチ命名規則も整備しています。

# ブランチ名の例
chore/migrate-playwright-batch-kawamura-20260122

CypressとPlaywrightの比較

現在、CypressとPlaywrightの両方を運用していますが、将来的にはPlaywrightに集約する予定です。
それぞれの特徴を比較します。

機能比較表

観点 Cypress (v14.x) Playwright (v1.50.x)
デバッグ Time Travel機能が優秀 Trace Viewerで対応可能
AI開発との親和性 標準的 高い（MCP対応）
並列実行 Cypress Cloud利用で追加コスト 標準機能で無料
Safari対応 実験的（Experimental） 完全対応（WebKitエンジン同梱）
モバイル対応 ビューポート変更のみ デバイスエミュレーション機能が強力
複数タブ・ウィンドウ 1つのタブ内での操作に限定 複数タブ・複数ウィンドウを操作可能
ブラウザ管理 ローカルにインストール済みのブラウザを検出 専用バイナリを自動ダウンロード・管理

対応ブラウザ

Cypressは基本的にChromium系ブラウザに強く、Safari対応は実験的な位置付けです。

  • Chromium系: Google Chrome, Microsoft Edge, Electron（標準搭載）
  • Firefox系: Mozilla Firefox
  • WebKit系: Safari（Experimental）

Playwrightは主要な3つのブラウザエンジンをネイティブサポートしており、Safari（WebKit）の再現性が非常に高いのが特徴です。

  • Chromium系: Google Chrome, Microsoft Edge, Chromium
  • Firefox系: Mozilla Firefox
  • WebKit系: Safari（macOS, iOSのレンダリングエンジン）
  • モバイル: Android（Chrome）、iOS（Safari）のエミュレーション

ブラウザ管理方法の違い

両ツールには、ブラウザの管理方法に大きな違いがあります。

Playwrightは、テスト実行時に特定のバージョンのブラウザバイナリ（Chromium, WebKit, Firefox）を自動でダウンロードして使用します。
これにより、「開発者のPCでは動くが、CI環境では動かない」というバージョン不一致の問題が起きにくく、非常に安定しています。

Cypressは、PCにインストールされているChromeやEdgeを自動検出してテストを実行します（Electronのみ内蔵）。
手軽ですが、CI環境構築時にはインストールされているブラウザのバージョン管理に気を使う必要があります。

kickflowでの使い分け

CypressはTime Travel機能によるデバッグのしやすさが大きな魅力です。
テスト実行の各ステップをスナップショットで確認でき、失敗原因を直感的に特定できます。
現在378シナリオが安定稼働しているため、急いで移行する必要はないと判断しています。

一方、PlaywrightはAI開発との親和性の高さと並列実行のコストメリットが特徴です。
Playwright MCPに対応しているため、Claude Codeなどのツールと組み合わせてテスト作成を効率化できます。
また、追加コストなしで並列実行数をコントロールできるため、テスト実行時間の短縮が容易です。

今後の展望

Autify→Playwright移行の完了

移行可能なシナリオについては、2026年前半に移行完了を目指しています。
ただし、メール通知確認など、Playwrightでは実装が難しいシナリオについては、引き続きAutifyで運用する予定です。

Cypress→Playwright移行

Cypressは現在安定稼働しているため、優先度は低めですが、将来的にはPlaywrightに統合する予定です。
AIツールとの親和性や並列実行のコストメリットを考慮し、順次移行を進めていきます。

ローカル環境でのテスト実行

現在はSandbox環境に対してテストを実行していますが、将来的には開発リポジトリでローカル環境に対してテストを実行する仕組みをPlaywrightで構築したいと考えています。
開発者がローカルで手軽にE2Eテストを実行できるようになれば、品質向上と開発効率の両立が実現できます。

おまけ: Claude Codeの活用

kickflowのQAエンジニアは全員がClaude Codeを使っています。
E2Eテストの実装だけでなく、以下のような業務にも活用しています。

  • E2Eテストの実装: 新機能のテストシナリオ作成やリファクタリング
  • 実装仕様の把握: プロダクトのソースコードを読ませてドキュメントを作成
  • テスト設計: テスト観点の洗い出しや網羅性の確認
  • バグチケットの作成: 不具合の原因特定や再現手順の整理

Claude Codeのおかげで、コードベースのE2Eテスト実装のハードルが大幅に下がりました。
プログラミング経験が浅いメンバーでも、AIのサポートを受けながらPlaywrightテストを書けるようになっています。

まとめ

kickflowのE2E・APIテスト構成を紹介しました。

  • UIのE2Eテスト: Autify、Autify Nexus、Cypress、Playwrightの4ツールで792シナリオを運用
  • APIテスト: Postmanで2,575リクエスト、5,124アサーションを安定運用
  • 移行戦略: Autify→Playwrightへの移行を2026年前半に完了予定

重要なのは、特定のツールに固執するのではなく、目的やチームのスキルセットに合わせて最適なツールを適材適所で組み合わせることだと思います。
私たちはこれからも新しい技術やツールを積極的に取り入れながら、お客様に最高のプロダクトを届けられるよう品質向上に努めていきます。

kickflowでは、一緒にプロダクトを創り上げてくれる仲間を募集しています!
少しでもご興味をお持ちいただけた方は、ぜひ採用サイトをご覧ください。

careers.kickflow.co.jp