このガイドでは、v3 API を使用したスケジュール済み自動化の管理について説明します。これはInfrastructure as Codeワークフローに役立ちます。APIの設定なしに、自動化ページから直接作成・管理することもできます。
1
APIアクセス用のサービスユーザーをセットアップする
API 経由で作成された自動化には、適切な権限を持つサービスユーザーが必要です。最初に 1 つ設定しておけば、以降のすべての呼び出しでその APIキー を使用できます。このガイドに記載されているコマンドがそのまま動作するように、両方の値をエクスポートしてください:サービスユーザーおよび権限の詳細については、API 認証に関するドキュメントを参照してください。
- app.devin.ai > Settings > Devin API に移動し、Service users タブを開いて Provision service user をクリックします
ManageOrgAutomations権限を含むロールを割り当てます- プロビジョニング後に表示される APIキー を保存しておきます。表示されるのは一度きりで、その後は
Bearerトークンとして使用します
ViewOrganizations を含むロールを持つ Enterprise サービスユーザーは、自身のトークンを使って List Organizations エンドポイントを呼び出すこともできます。2
テスト実行のためのプレイブックを作成します
自動化を作成する前に、E2E スイートをどのように実行し、結果をどのように扱うかを Devin に正確に指示するプレイブックを用意します。Settings > Playbooks に移動して新しいプレイブックを作成するか、テストワークフローの説明から Devin に生成を依頼してください。以下は Playwright スイート向けの例です:保存後はプレイブック ID を控えておいてください。自動化のプロンプト内で参照することになります。プレイブックを表示しているときの URL (
app.devin.ai/.../playbooks/{playbook_id}) から確認できます。3
API でナイトリー自動化を作成する
次に、レスポンスには、この自動化を後で管理する際に使用する
POST /v3/organizations/{org_id}/automations エンドポイントを使って、schedule:recurring トリガーと start_session アクションを持つ自動化を登録します。プロンプト内では @playbook:{id} トークンでプレイブックを参照します。自動化によって開始されたセッションでは、付与したツールのみが利用できるため、tools ブロックで Linear のツールを有効にし、Devin が #qa-results チャンネルに投稿できるようにします (Slack のワークスペース ID とチャンネル ID は自分のものに置き換えてください)。次の例では、毎晩午前 2 時 (UTC) に実行されます。automation_id が含まれています。保存しておいてください:rrule 条件は、UTC で評価される iCalendar の RRULE を受け取ります。以下にいくつか便利な例を示します:なぜ午前 2 時なのでしょうか?テストは、その日の最後のデプロイがステージング環境で安定した後で、かつエンジニアが業務を開始したときに不具合が見えるよう、十分早い時間に実行したいからです。チームのタイムゾーンとデプロイのサイクルに合わせて調整してください。利用可能なすべてのフィールドについては、Create automation エンドポイントのドキュメントを参照してください。
4
初回実行を検証し、プロンプトを最適化する
自動化が最初に実行されたら、セッションを確認して、Devin がテストを正しく実行し、出力が期待どおりになっていることを確かめます。
- 自動化ページで対象の自動化を開き、Activity タブのセッションリンクをたどります
- Playwright のテストスイートは実行されましたか? 実際の不具合 (フレークテストではないもの) に対して Linear チケットが作成されましたか?
#qa-resultsSlack チャンネルでサマリーメッセージを確認します
- Devin がステージングにアクセスできない: ステージング環境変数 (
STAGING_API_KEYやDATABASE_URLなど) を organization secrets として追加し、その自動化が開始するすべてのセッションで利用できるようにします - フレークテストからのチケットが多すぎる: プレイブックにリトライを追加します: 「チケットを起票する前に、失敗したテストはすべて 1 回再実行する。2 回失敗したテストに対してのみチケットを起票する。」
- テストに時間がかかりすぎる: スイートの対象範囲を絞ります — 例: 「
tests/critical/とtests/smoke/のテストだけを実行する」— またはセッションのタイムアウトを延長します
5
自動化をコードで管理する
ナイトリーの実行が安定したら、他の自動化と同様に管理したくなるはずです。デプロイフリーズ中は一時停止したり、テストスイートが変わったらプロンプトを更新したり、別の環境用に 2 つ目の自動化を作成したりできます。デプロイフリーズやメンテナンスウィンドウの間は、自動化を一時停止 します:凍結期間が終わったら、再度有効化してください:稼働中のものを監査するには、すべての自動化を一覧表示します:複数の自動化を管理しているチームは、YAML 設定ファイルから自動化の定義を同期する CLI の作成を Devin に依頼することで、テスト設定と同様に自動化もバージョン管理できます。

