テストスイートがパスし続ける場合にのみ役立ちます。今日のチェックアウトフローは機能していますが、依存関係が午前2時に破壊的な変更を出荷したり、週末に証明書の有効期限が切れたり、設定のずれによって日曜日に決済エンドポイントが停止したりする可能性があります。テスト実行ではなく、怒った顧客からそのことを知ることになります。解決策は退屈で信頼性の高いものです。APIテストをスケジュールに基づいて、人間がボタンをクリックすることなく実行し、問題が発生した瞬間に通知を受け取ることです。
Apidog には、まさにこのための組み込みの「スケジュール済みタスク」機能があります。すでに構築済みのテストシナリオを指定し、実行頻度を設定し、実行するマシンを選択し、アラートを連携させます。このガイドでは、現在の制限事項を含め、そのすべてを正直に説明します。ライブエンドポイントに対する無人チェックの実行が初めての方のために、API監視に関する入門記事がより広いコンテキストを提供し、Apidogスケジュール済みタスクのドキュメントはUIの公式情報源です。
始める前に一つ簡単な注意点があります。「スケジュール済みタスク」機能は現在ベータ版とされており、アカウントが実行できるスケジュール済み実行の正確な数は、お使いのプランによって異なります。読み進める際には、この両方を念頭に置いてください。
スケジュール済みタスクとは何か（およびスケジュール済みスクレーパーとの違い）
Apidogのスケジュール済みタスクは、1つ以上の保存済みテストシナリオを繰り返し実行します。コアAPI全体に対する夜間回帰テスト、ステージング環境に対する数時間ごとの簡易チェック、または週末の健全性スキャンを想像してください。このタスクは、どのシナリオを実行するか、どの環境を対象とするか、どれくらいの頻度で起動するか、どのマシンが作業を実行するか、そして失敗した場合に誰に通知するかを記憶します。
ウェブスクレイピングやデータ収集に関連して「スケジュール済みタスク」というフレーズを目にしたことがあるなら、それは別のものです。この機能は、タイマーでページをクロールすることではありません。これはテストモジュール内に存在し、アサーション、連鎖リクエスト、抽出された変数など、APIテストシナリオを駆動します。出力は、スクレイピングされたデータセットではなく、API契約の合否レポートです。
この区別が重要であるのは、設定内容が変わるためです。セレクターやクロールルールを作成するのではなく、既存のテストシナリオを選択し、いつどこで実行するかをApidogに指示するのです。
始める前に：セルフホスト型Runnerを構成する
ここに人々がつまずきがちな前提条件があります。スケジュール済みタスクを実行するには、まずセルフホスト型Runnerを構成する必要があります。ドキュメントには明確に記載されています。
Runnerはテストスイートを実行するマシンです。スケジュール済みタスクが起動しても、Apidogはデスクトップクライアントでリクエストを実行しません。選択したRunnerにジョブを渡し、スイート内のすべてのリクエストはそのマシンから送信されます。CIボックス、小型の常時稼働サーバー、または専用VMのいずれもがうまく機能します。選択したものが、希望するスケジュールで常に稼働し、到達可能であることを確認してください。
Runnerターゲットフィールドには、「近日公開」と表示されているApidog Cloudか、セルフホスト型Runnerの2つの選択肢があります。Apidog Cloudはまだ利用できないため、現状ではセルフホスト型Runnerが唯一の選択肢です。Apidog Cloudが出荷されるまで、クラウド実行を計画しないでください。
リクエストはRunnerのマシンから発信されるため、そのネットワーク環境が結果を左右します。企業のVPNの背後、異なる地域、またはファイアウォールで保護されたサブネットにあるRunnerは、ラップトップとは異なる応答を見る可能性があります。これは通常、現実的な監視にとって望ましいことですが、スケジュールされた実行がローカル実行と一致しない場合に知っておく価値はあります。
ステップバイステップ：スケジュール済みタスクを作成する
Runnerが登録されていれば、残りはクライアントで行われます。以下の実行例は、ユーザー登録、商品リスト、カート、そしてStripeによってバックアップされたチェックアウトをカバーするEコマースAPIの夜間回帰スイートです。
1. テストモジュールでスケジュール済みタスクを開く
Apidogクライアントで「テスト」モジュールを開きます。テストフォルダツリーで「スケジュール済みタスク」をクリックすると、プロジェクト内のすべてのスケジュール済みタスクを表示および管理できます。プロジェクト全体のすべてのタスクは「スケジュール済みタスク」セクションに表示されるため、これは何がいつ実行されているかを確認する唯一の場所です。
2. タスクを作成する
「+新規」をクリックして、新しいスケジュール済みタスクを作成します。また、ここでフォルダを作成して関連するタスクをグループ化することもできます。これは、ステージングと本番環境、または異なるサービス用に個別のスイートがある場合に便利です。
タスクに明確なタスク名と説明を付けます。これらはタスクを区別し、その目的を説明するために存在するため、将来のあなたが「夜間回帰、本番環境」が実際に何をカバーしているかを、開かずに知ることができます。各タスクには有効/無効のトグルもあり、ツリー内のタスクはいつでも有効または無効にできます。
3. 実行するテストシナリオを選択する
「テストシナリオ」の下で、含めるシナリオを1つ以上選択します。Eコマースの例では、「サインアップとログイン」、「閲覧とカートに追加」、「Stripeテストカードでのチェックアウト」を選択して、1つのタスクでクリティカルパス全体をカバーすることができます。
各シナリオは、環境、テストデータ、イテレーション、遅延、リクエストとレスポンスを保存するかどうかなど、独自の実行設定を持つことができます。それぞれを調整したくない場合は、「同じ実行設定を使用」をオンにして、選択したすべてのシナリオに一度に1つの実行時設定を適用します。これにより、大規模なスイートの一貫性を保ち、設定を迅速に行うことができます。
環境選択は、人々が最も気にする設定です。夜間の本番環境監視を本番環境に向け、リリース前のスモークテストをステージング環境に向けます。各シナリオは独自の環境を指定できるため、必要であれば1つのタスクで複数のターゲットを混在させることもできますが、1つのタスクを単一の環境に保つ方が理解しやすくなります。
4. 実行サイクルを設定する
「実行スケジュール」フィールドに希望の頻度を設定します。表示されている画面によっては、このフィールドは「実行サイクル」または「実行モード」と表示されますが、同じ設定であり、UIによって表示される文言が異なります。ドキュメントには、毎週日曜日午後11時、6時間ごと、または8時間ごとなど、具体的な例が挙げられています。
夜間回帰テストの場合、毎晩深夜に実行することで、ノイズを低く抑え、業務時間前に問題を捉えることができます。ステージング環境のスモークテストの場合、6時間ごとに実行することで、環境に負荷をかけずに迅速なフィードバックが得られます。
5. どこで実行するかを選択する
「runner」フィールドにセルフホスト型Runnerを設定します。このフィールドもスケジュールフィールドと同様に、画面によって「Runs on」、「Run On」、「Runs On」と一貫性がありませんが、すべてスイートを実行するマシンを意味します。Apidog Cloudもここに表示されますが、これは「近日公開」なので、セルフホスト型Runnerを選択してください。複数の汎用Runnerを登録している場合は、APIと同じVPC内にあるRunnerなど、特定のRunnerを選択してください。
テストスイートで開始されたすべてのリクエストは、ここで指定されたマシンから送信されることを忘れないでください。したがって、実際のトラフィックがAPIを見る方法と同様に、そのネットワークがAPIを見るRunnerを選択してください。
6. 通知をオンにする
「通知」を有効にすると、タスクに問題が発生した際に通知が届きます。ドキュメントではスケジュール済みタスクにこれを推奨しており、無人実行の目的はまさにこれです。サイレンスは成功を意味し、失敗は迅速に通知されるべきです。
Apidogは、Slack、Teams、Webhook、Jenkins、Emailという名前でこれらのチャンネルをサポートしています。Emailの場合、プロジェクトメンバーのアドレスは自動補完され、オンコール担当者や共有受信トレイのために、非メンバーのアドレスを手動で入力することもできます。Slackは失敗をチームチャンネルに直接送信します。Webhookオプションを使用すると、PagerDutyからカスタムエンドポイントまで、実行している他のあらゆるものに情報を拡散できます。
アラートが発火するタイミングも選択できます。毎回実行後、または失敗時のみ、です。健全な夜間スイートの場合、失敗時のみに設定することで、問題が発生するまでチャンネルを静かに保つことができます。不安定なロールアウト中に、毎回実行すると、ジョブが実際に実行されていることを確認するためのハートビートが得られます。
7. 保存して有効にする
タスクのトグルを切り替えて有効にすると、設定した頻度で実行が開始されます。計画的な停止や移行期間中には、削除せずに後で無効にすることができます。これは便利です。
8. 実行履歴を読む
各実行後、結果はRunnerからサーバーへ自動的にアップロードされます。クライアントの「スケジュール済みタスク - 実行履歴」セクションを開くと、これらを確認できます。これはあなたの監査証跡です。どの実行が成功し、どの実行が失敗し、どのアサーションが壊れたか、そしていつか、です。Slackにアラートが届いた場合、その詳細を確認するには実行履歴を見ます。
詳細設定とバリエーション
基本的なタスクが実行されたら、いくつかのオプションでそれをより堅牢にすることができます。
変数のスコープ。シナリオ間でデータを渡す場合、Apidogは最小から最大まで3つの共有レベルを提供します。現在のテストシナリオ内でのみ共有（そのシナリオ専用のファイルに変数を保持）、現在のスケジュール済みタスク内のすべてのテストシナリオ間で共有（同じタスク内のシナリオが互いの値を読み取れるようにする）、現在のスケジュール済みタスクフォルダ内のすべてのスケジュール済みタスク間で共有（最も広いスコープ）です。データが流れる最小のスコープを選択し、あるシナリオからの認証トークンが関係ないシナリオに漏洩しないようにします。
変数の永続性。テストシナリオデザインページで「変数の値を保持」オプションが有効になっている場合にのみ、値は次の実行に引き継がれます。夜間実行で前日取得した注文IDや更新されたトークンが必要な場合は、これをオンにしてください。これがなければ、各実行はクリーンに開始され、実行間のあらゆる前提がひっそりと破綻します。
フォルダによるグループ化。スイートが成長するにつれて、「スケジュール済みタスク」の下にフォルダを作成して、たとえば本番環境の監視とリリース前チェックを分離します。フォルダレベルの変数スコープにより、関連するタスクのグループがクリーンに設定を共有できるようになります。
プランの制限。利用可能なスケジュール実行の数は、サブスクリプションによって異なります。ドキュメントは正確な数値についてApidogの料金ページを参照しているため、積極的な毎時実行頻度を設定する前にプランを確認してください。グループ化とより重いスケジューリングパターンについてさらに深く掘り下げる必要がある場合は、高度なスケジュール済みタスクのウォークスルーがさらに詳しく、またAPIテストシナリオにおける条件ロジックに関する姉妹ガイドが、そもそもスケジュールに値するシナリオを構築するのに役立ちます。初めて無人チェックを設定するチーム向けには、CIにおける夜間APIテスト実行の記事がこの内容とよく合います。
Apidog CLIでワークフローを自動化する
スケジュール済みタスクのUIは一つの方法です。Apidog CLIは三番目の方法であり、これは本格的なものです。保存されたシナリオをヘッドレスで実行し、cronまたはCIプロバイダーに実行頻度を処理させます。はっきりさせておくと、CLIにはネイティブのスケジュールコマンドはありません。スケジューリングは、Apidogの外側にある、cronで既に信頼しているツールで行われます。
インストールして認証した後、選択した環境に対してIDでシナリオを実行します。Apidog CLIインストールガイドでは、トークン設定について詳しく説明しています。
npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run --access-token $APIDOG_ACCESS_TOKEN -t <SCENARIO_ID> -e <ENV_ID> -r cli,junit
ここで、-t はテストシナリオID、-e は環境ID、-r はレポーター（cli、html、または junit、複数指定する場合はカンマ区切り）です。これをcronで毎晩実行するには、次の1行を追加します。
0 2 * * * cd /srv/api-tests && apidog run --access-token $APIDOG_ACCESS_TOKEN -t 4471 -e 88 -r junit >> run.log 2>&1
または、スケジュールされたGitHub Actionsジョブからトリガーすることもできます。いずれの方法でも、JUnitレポートは既存のパイプラインダッシュボードにドロップされます。cronやGitHub Actionsのスケジュールトリガーを含む完全な設定については、CI/CDパイプラインでのApidog CLIを参照してください。
FAQ
現在、Apidog Cloudでスケジュール済みテストを実行できますか？ まだできません。RunnerターゲットにはApidog Cloudが「近日公開」と表示されているため、現時点ではセルフホスト型Runnerが唯一動作する実行マシンです。まずRunnerを登録し、その後タスクで選択してください。
スケジュール済みタスクはどのくらいの頻度で実行できますか？ お使いのプランで許可されている頻度で実行できます。実行頻度自体は柔軟で、6時間ごとや毎週日曜日午後11時などの例がドキュメントに記載されていますが、スケジュール済み実行の回数はサブスクリプションによって制限されます。数を推測するのではなく、お使いのプランの正確な制限についてはApidogの料金ページを確認してください。
テストが失敗した場合のみ通知を受け取るにはどうすればよいですか？ タスクの通知設定で、「すべての実行」ではなく「失敗時のみ」オプションを選択し、その後Slack、Teams、Webhook、Jenkins、またはEmailのチャンネルを追加します。これにより、問題がない夜間はチャンネルが静かに保たれ、問題が発生した場合は通知されます。これを軽量なAPI健全性チェックと組み合わせることで、より詳細な回帰スイートと並行して、迅速な生存シグナルが得られます。
スケジュール済み結果がローカルテスト実行と異なるのはなぜですか？ リクエストはあなたのラップトップからではなく、Runnerのマシンから送信されるためです。そのネットワーク、地域、およびVPNやファイアウォールが応答を形成します。これは予想されることであり、多くの場合、ユーザーが遭遇する状況をより現実的に反映しています。
実行ごとに変数がリセットされます。何を見落としていますか？ テストシナリオデザインページの「変数の値を保持」オプションです。これを有効にすると、取得された値が次の実行にわたって保持されます。これがないと、各スケジュール済み実行は新しく開始され、実行間の依存関係はすべて失敗します。
まとめ
スケジュール済みテストは、「APIは機能しているだろう」という考えを「APIが機能していることを知っている。もし機能していなければ、今頃耳にしているはずだ」という確信に変えます。シナリオを一度構築し、セルフホスト型Runnerを登録し、実行サイクルを設定し、失敗時にSlackやメールを連携させ、あなたが寝ている間に実行させましょう。パイプライン内で同じチェックが必要な場合は、CLIとcronを組み合わせることで、追加のツールなしで第三の道が提供されます。Apidogをダウンロードして、最初のスケジュール済み回帰スイートを設定してください。無料で開始でき、クレジットカードは不要です。