GitHub ActionsでPlaywrightを毎日実行する方法|スケジュール実行(cron)で本番監視・回帰テストを自動化する

GitHub Actions で Playwright を動かす記事の多くは「コードをpushしたら実行する」push/pull_requestトリガーを扱いますが、実務では「毎日決まった時間に本番環境の健全性をチェックしたい」「夜間に回帰テストを流しておきたい」というニーズも少なくありません。この記事では、GitHub Actionsのschedule(cron)トリガーを使ってPlaywrightを毎日自動実行する方法を、通知設定・本番テストの注意点も含めて解説します。

push/PRトリガーとschedule(毎日実行)トリガーは、似ているようで運用の考え方が異なります。無人で実行される前提だからこそ気をつけるべきポイントがあります。

📌 この記事はこんな方におすすめ

  • Playwrightのテストをpush/PR時だけでなく、定期的にも実行したい方
  • 本番環境の健全性を毎朝自動でチェックする仕組みを作りたい方
  • テスト失敗時にSlackなどへ自動通知したい方
  • 無人実行特有のFlaky Test対策に悩んでいる方

✅ この記事を読むと得られること

  • GitHub Actionsのcron構文とタイムゾーンの注意点がわかる
  • 失敗時にSlack通知を送る設定が実装できる
  • 本番環境を安全にテストするための考え方がわかる

👤 この記事を書いた人

QAエンジニア・テスト自動化エンジニアとして15年以上の実務経験を持つ Yoshi が執筆。Playwright × GitHub Actions での定期監視・回帰テストの仕組みを複数プロジェクトで構築してきました。

📌 結論

  • GitHub ActionsのscheduleトリガーはUTC基準で動くため、JSTとの時差変換を忘れずに設定する
  • 失敗を人が気づける仕組み(Slack通知など)とセットで導入しないと、定期実行の意味が薄れる
  • 本番環境をテストする場合は、読み取り専用の操作に絞るなど安全設計が欠かせない

push/PRトリガーのCIは「コード変更を検証する」ことが目的ですが、毎日実行するスケジュール型のテストは目的が異なります。

  • コードは変わっていなくても、外部APIやインフラ側の変化で本番環境が壊れていないかを確認したい
  • 夜間などトラフィックが少ない時間帯に、時間のかかる回帰テストを流したい
  • 誰もPRを見ていない時間帯に失敗しても、後から気づけるようにしたい

この記事では、こうしたニーズに対応するための実装ポイントを順番に解説します。

① schedule(cron)トリガーの基本

GitHub Actionsでは、on.scheduleにcron構文を指定することで、決まった時刻にワークフローを自動実行できます。

# .github/workflows/daily-playwright.yml
name: Daily Playwright Tests

on:
  schedule:
    - cron: "0 0 * * *"  # 毎日 UTC 0:00 = JST 9:00 に実行

jobs:
  test:
    timeout-minutes: 30
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install dependencies
        run: |
          pip install -r requirements.txt --break-system-packages
          playwright install --with-deps

      - name: Run Playwright tests
        run: pytest tests/ --alluredir=allure-results

      - name: Upload results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: allure-results
          path: allure-results/
⚠️ 注意:cron はUTC基準
GitHub ActionsのscheduleはUTC(協定世界時)で評価されます。日本時間(JST)で「毎朝9時に実行したい」場合は、UTC 0:00(0 0 * * *)を指定する必要があります。JSTはUTCより9時間進んでいるため、変換を間違えると意図しない時間に実行されてしまいます。
実行したいJST時刻→対応するUTC cron
毎朝9:000 0 * * *
毎日深夜3:000 18 * * *(前日18:00 UTC)
平日のみ朝9:000 0 * * 1-5
💡 実務Tip:GitHub Actionsのスケジュール実行は、システム負荷が高い時間帯に数分〜十数分程度遅延することがあると公式に案内されています。「必ずその時刻ちょうどに実行される」ことを前提にした設計は避け、多少の遅延が起きても問題ない形で運用しましょう。

② workflow_dispatch を併用して手動実行も可能にする

スケジュール実行だけでは、「今すぐ結果を確認したい」というときに次の実行時刻まで待つ必要があります。workflow_dispatchを併用すると、GitHubのUIから手動でも同じワークフローを実行できるようになります。

on:
  schedule:
    - cron: "0 0 * * *"
  workflow_dispatch:  # ← 手動実行ボタンが追加される
🔍 実務あるある:スケジュール実行だけのワークフローだと、「昨夜のテストが失敗していたので、修正後にすぐ確認したい」という場面で次の日まで待つしかなくなります。workflow_dispatchを併用しておくだけで、こうしたもどかしさをほぼ解消できます。

③ 失敗時にSlack通知を送る

毎日実行されるテストは、push/PRトリガーと違って**誰も結果を見に行かない**ことが多いです。失敗した場合に自動で通知される仕組みがないと、定期実行の意味が薄れてしまいます。

jobs:
  test:
    timeout-minutes: 30
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # ... セットアップ・テスト実行ステップ ...

      - name: Run Playwright tests
        id: run_tests
        run: pytest tests/

      - name: Notify Slack on failure
        if: failure()
        run: |
          curl -X POST -H 'Content-type: application/json' \
            --data "{\"text\":\"❌ Daily Playwright tests failed. Run: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}\"}" \
            "${{ secrets.SLACK_WEBHOOK_URL }}"
⚠️ 注意:SLACK_WEBHOOK_URLのような機密情報は、ワークフローファイルに直書きせず、必ずGitHub Secretsに登録してsecrets.経由で参照してください。誤ってリポジトリにコミットしてしまうリスクを避けられます。

④ 本番環境をテストする際の注意点

「毎日実行」の目的の一つが本番環境の監視である場合、テスト対象が実際のユーザーが使っているサービスになります。ステージング環境とは異なる注意が必要です。

観点対応方針
破壊的操作を避ける注文確定・退会処理など、実データに影響する操作はテスト対象から外すか、専用のテストアカウントで完結させる
専用テストアカウントを用意する実際の顧客データと混ざらないよう、監視専用のテストアカウント・テストデータを分離する
実行頻度を絞る本番環境への負荷やGitHub Actionsの実行時間(無料枠)を考慮し、必要以上に高頻度で実行しない
機密情報の管理本番の認証情報はGitHub Secretsで管理し、ログに出力されないよう注意する
💡 実務Tip:本番監視の目的であれば、すべての機能をテストする必要はありません。「ログインできる」「トップページが表示される」「決済ページが開ける」といった、サービス全体に影響する重要な導線に絞ったスモークテストにすることで、リスクと実行時間の両方を抑えられます。

⑤ 無人実行特有のFlaky Test対策

push/PRトリガーであれば、テストが失敗した際にすぐ再実行ボタンを押せますが、夜間のスケジュール実行では人が即座に対応できません。無人実行では、Flaky Testによる誤検知が朝の通知への信頼性を下げてしまいます。

- name: Run Playwright tests with retry
  run: pytest tests/ --reruns 2 --reruns-delay 3
⚠️ 注意:--rerunsはpytest-rerunfailuresプラグインが提供するオプションで、pytest標準機能ではありません。使用する場合はpip install pytest-rerunfailuresが必要です。またリトライは根本原因を隠す応急処置なので、頻繁にリトライで通過しているテストは別途原因調査することをおすすめします。
🔍 実務あるある:無人実行のFlaky Testを放置すると、「またいつものやつだろう」と朝の通知が徐々に無視されるようになります。この状態になると、本当に重大な障害が起きたときの検知が遅れる原因になるため、Flaky Testの解消は監視の仕組みそのものの信頼性に直結します。

実務でよくある失敗パターン

① UTCとJSTを取り違えて意図しない時間に実行される

「毎朝9時に実行したいから cron: "0 9 * * *"」と書いてしまうと、実際にはUTC 9:00=JST 18:00に実行されてしまいます。cron設定後は、実際の実行ログのタイムスタンプで意図通りの時刻か確認しましょう。

② 実行頻度が高すぎてActionsの無料枠を圧迫する

「念のため1時間ごとに実行」のように高頻度で設定すると、GitHub Actionsの無料利用枠(プランにより異なる)をすぐに使い切ってしまうことがあります。本当にその頻度が必要か、目的に立ち返って検討しましょう。

③ 通知の仕組みがなく、失敗に何日も気づかない

スケジュール実行を設定しただけで満足してしまい、通知設定を後回しにするケースです。GitHub Actionsのタブを毎日自主的に確認する運用は長続きしないため、Slack通知などは初期段階から組み込んでおくことをおすすめします。

④ リポジトリが一定期間更新されず、スケジュール実行が停止する

GitHub Actionsのscheduleは、デフォルトブランチで長期間更新がないリポジトリでは自動的に無効化される仕様があります。長期間コードを変更しない監視専用リポジトリの場合、この挙動によって知らないうちに監視が止まっていることがあるため、最新の条件はGitHub公式ドキュメントを確認しておきましょう。

FAQ

Q. GitHub Actionsの無料枠でも毎日実行できますか?

プラン・リポジトリの公開設定(パブリック/プライベート)によって無料枠の実行時間が異なります。1日1回・数分程度のテストであれば多くの場合は無料枠内に収まりますが、テスト数や実行頻度が増えると超過する可能性があるため、GitHubの公式料金ページで最新の枠を確認することをおすすめします。

Q. cron の実行時刻はどのくらい正確ですか?

GitHub Actionsのスケジュール実行は、システムの混雑状況によって数分〜十数分程度遅延することがあると公式に案内されています。秒単位の正確さが求められる用途には向いていません。

Q. Slack以外の通知方法はありますか?

Slack以外にも、Discord・メール(GitHub Actionsの通知設定)・Microsoft Teamsなど、Webhookに対応したサービスであれば同様の仕組みで通知できます。基本的な考え方は「失敗時にHTTPリクエストを送る」という点で共通しています。

Q. push/PRトリガーとschedule(毎日実行)トリガーは同じワークフローファイルで併用できますか?

併用できます。onの下にpush・pull_request・schedule・workflow_dispatchを並べて記述すれば、それぞれの条件で同じワークフローが実行されます。ただし、テスト内容や本番/ステージングの向き先を条件分岐させたい場合は、ワークフローを分けた方が管理しやすいこともあります。

Q. 本番環境のテストで注文や決済のような重要な機能を確認したい場合はどうすればいいですか?

サンドボックス環境が用意されている決済サービス(テストモードのカード番号など)を活用し、実際の課金が発生しない形でテストするのが基本です。サンドボックスがない場合は、決済確認画面の手前まで進めて表示内容を確認するなど、実データへの影響が出ない範囲にテストを限定する判断も必要です。

📋 まとめ

  • schedule(cron)トリガーはUTC基準で動くため、JSTとの時差変換を必ず確認する
  • workflow_dispatchを併用すると、スケジュール実行と手動実行の両方に対応できる
  • 失敗通知(Slackなど)とセットで導入しないと、定期実行の効果が発揮されない
  • 本番環境のテストは破壊的操作を避け、専用アカウント・限定的な範囲で安全に設計する

毎日実行の仕組みは、一度作ってしまえば「気づいたら壊れていた」を防ぐ強力な安全網になります。まずは重要な導線に絞ったスモークテストから始めて、通知の仕組みとセットで運用に乗せてみてください。

タイトルとURLをコピーしました