自動化

​

基本概念

​

アクションの種類

​

トリガーソース

​

自動化を作成する

​

自動化ページから

1. サイドバーで 自動化 に移動します
2. Create automation をクリックし、Create を選択して空のエディタを開きます (自動化をまだ作成していない場合は、ランディングページで Create manually をクリックします)。同じメニューには Template (テンプレートギャラリーを開きます) と Generate with Devin (Devin と一緒に自動化を作成するセッションを開始します) もあります
3. トリガー、条件、アクションを設定します
4. Create automation をクリックします

​

テンプレートから

1. サイドバーの自動化に移動します
2. Create automation > Templateをクリックするか、/automations/templates に直接アクセスします (自動化がまだない場合は、ランディングページでCreate from templateをクリックします)
3. テンプレートギャラリーを閲覧します — 各テンプレートは、一般的なワークフロー向けに事前設定された自動化です
4. テンプレートをクリックすると、トリガー、アクション、推奨される上限がエディタに事前入力されます
5. 設定をカスタマイズし (Slack チャンネルやリポジトリを選択するなど) 、Create automationをクリックします

​

自然言語を使う

​

トリガーの設定

​

Slack トリガー

• Slack メッセージ: 新しいメッセージが投稿されると作動します。既定ではチャンネル条件が追加されますが、これを削除すれば複数のチャンネルをまたいでメッセージに一致させられます。ただしその場合、各条件グループには少なくとも 1 つ別のフィルターが必要です (例: メッセージ本文や送信者の種類。Include thread replies だけでは不十分です) 。
• ユーザーグループのメンション: Slack のユーザーグループ (例: @oncall) がメンションされると作動します。グループを選択するか、その Slack ID (S で始まる) を入力します。必要に応じて、対象を特定のチャンネルに限定することもできます。
• Slack リアクション: メッセージに特定の絵文字リアクションが追加されると作動します (例: インシデント用の 🚨) 。リアクション名とチャンネルで絞り込めます。

​

GitHub トリガー

• Issue: issue イベント (オープン、クローズ、再オープン、編集、ラベル付け) で発生します。
• issue コメント: GitHub issue にコメントが投稿されると発生します。一般的には starts_with "/devin" 条件と組み合わせて利用し、ユーザーが任意の issue で /devin と入力すると Devin をトリガーできます。
• Pull request: PR イベント (オープン、同期など) で発生します。
• Pull request review: PR にレビューが送信されると発生します。
• Pull request review comment: 個別のレビューコメントで発生します。
• Check run (CI): CI チェックが完了すると発生します。conclusion = failure で絞り込むと、失敗したビルドを自動修正できます。
• Push: ブランチへのプッシュで発生します。

​

GitLab のトリガー

• Merge request: MR のアクション(opened、closed、merged、reopened、approved、updated)で発生します。
• MR コメント: マージリクエストにコメント(ノート)が投稿されたときに発生します。diff のレビュースレッドも対象です。
• Issue: issue のアクション(opened、closed、reopened、updated)で発生します。
• issue コメント: issue にコメントが投稿されたときに発生します。
• Push: ブランチへのプッシュで発生します。
• Pipeline: パイプラインが指定したステータスに達したときに発生します。ステータス(例: failed)でフィルタリングすれば、失敗したパイプラインを自動的に修正できます。

​

Linear のトリガー

• Issue created: 選択したチームで新しい issue が作成されると発生します。
• Label added: issue にラベルが追加されると発生します (例: bug, devin) 。
• Status changed: issue のステータスが変更されると発生します (例: 「In Progress」に移動) 。
• Priority changed: issue の優先度が変更されると発生します。
• Assigned: issue が誰かに割り当てられると発生します。
• Issue moved: issue が別のチームに移動されると発生します。トリガーのチームフィルターは移動先のチームと照合されます。

​

Jira triggers

• Issue created: 新しい issue が作成されたときに発生します。
• Issue updated: issue のフィールドが変更されたときに発生します。
• ラベル: issue に label が付与されたときに発生します。
• Status changed: issue のステータスが変更されたときに発生します。
• Assigned: issue が誰かに割り当てられたときに発生します。
• Comment created or edited: issue にコメントが追加または編集されたときに発生します。

​

スケジュールトリガー

• Recurring: 頻度 (毎時、毎日、毎週) と時刻を設定します。スケジュールは内部的に iCalendar の RRULE 形式を利用しています。Custom schedule を選択すると、カスタムの繰り返し (N 分 / 時間 / 日 / 週 / か月ごとに繰り返す) を作成できます。より複雑な間隔を設定する場合は、生の RRULE 文字列 (例: FREQ=WEEKLY;BYDAY=MO;BYHOUR=9;BYMINUTE=0) を直接入力することもできます。
• Run once: 将来の特定の日時に1回だけ発生し、その後自動的に無効になります。1回限りの遅延実行に便利です。たとえば、「12時間後に Devin を起こしてタスクを実行する」といった使い方です。日付と時刻を選択します (既定では現在から1時間後) 。指定する日時は未来である必要があります。

​

Webhookトリガー

1. Webhookトリガーを使って自動化を作成します
2. トリガー設定に表示されるWebhook URLとシークレットをコピーします
3. このURLにHTTP POSTリクエストを送信するよう、外部システム (PagerDuty、Datadog、Sentry、またはカスタムツール) を設定します
4. 必要に応じてペイロード filterを追加します — これは、自動化が実行される条件として、リクエスト本文が一致する必要のある正規表現パターンです

• X-Webhook-Secret: <secret> ヘッダー
• Authorization: Bearer <secret> ヘッダー
• ?secret=<secret> クエリパラメータ

​

Webhook シークレット

curl -X POST '<webhook-url>' \
  -H 'Content-Type: application/json' \
  -H 'X-Webhook-Secret: <secret>' \
  -d '{"test": true}'

​

プリフライトチェック

​

LLM filter

​

プリフライトスクリプトを設定してテストする

1. 自動化を作成するか既存の自動化を編集し、トリガーと条件を設定します。
2. トリガーセクションの下にある Add a step before the agent runs をクリックし、Before the agent runs カードで Run a script を選択します。
3. Edit script をクリックし、ランタイムセレクターで Python、Node (JavaScript) 、または Bash を選択して、スタータースクリプトを編集します。
4. 必要に応じて、スクリプトエディターの Select secrets から組織のシークレットをアタッチします。環境変数として注入されるのは、選択したシークレットのみです。シークレットをアタッチしたスクリプトを保存またはテストするには、組織のシークレットを管理する権限が必要です。
5. カードで Timeout (seconds) を設定します。デフォルトは 60 秒で、設定可能な範囲は 1～300 秒です。スクリプトはデフォルトで Minimal environment を利用します。マシンスナップショットが利用可能な場合は、Environment セレクターで依存関係を含む組織のスナップショットを選択することもできます。
6. スクリプトエディターで Test against からイベントを選択し、Run をクリックします。未保存のスクリプトを、設定済みトリガーのサンプル、または既存の自動化の最近のイベントに対してテストできます。結果とログを確認し、出力されたアイテムがある場合は、実行・重複・延期となる件数のプレビューも確認します。
7. Save script をクリックしてエディターの変更を適用し、続けて Create automation をクリックするか自動化を保存して、設定を確定します。

​

スクリプトの入力と出力

import json
import os

with open(os.environ["EVENT_FILE"]) as f:
    event = json.load(f)

text = event.get("payload", {}).get("text", "")
should_run = "urgent" in text.lower()

with open(os.environ["OUTPUT_FILE"], "w") as f:
    json.dump({"run": should_run, "reason": "Urgency filter"}, f)

​

スクリプトのアイテム、状態、上限

• 重複防止: アイテムの id は、単なるエンティティではなく、この自動化における作業単位を識別するものです。{"id": "INC-1"} は一度だけ処理されます。同じインシデントが新たに発生した際に処理させるには、上流の更新タイムスタンプなどを version として追加してください。id がない場合、Preflight はアイテムの内容の hash でアイテムを識別するため、内容が変わると再度 run が実行される可能性があります。
• run ごとのアイテム上限: デフォルトでは、1 回の run でディスパッチされる新規アイテムは最大 10 件で、システム上の上限は 50 件です。上限を超えたアイテムは処理されず、自動でスケジュールされることもありません。次回のスクリプト run で改めて出力する必要があります。出力に含めたからといって、保留中の作業を越えて カーソル を進めないでください。
• 過去の結果: LAST_RUN_FILE を利用すると、作業が実行中、成功、失敗、スキップのいずれであるかを区別できます。run が失敗したアイテムは解放されるため、以降のスクリプト run で再度出力できます。
• 永続的な状態: 1 つの自動化に対するスクリプトの本番 run は、一度に 1 つずつ実行されます。スクリプトが失敗した場合、保存された状態は更新されず、アイテムが処理済みとしてマークされることもありません。Clear state を実行すると、保存された JSON 状態と処理済みアイテムの履歴の両方がクリアされます。リセット後は、以前に処理されたアイテムが再度実行される可能性があります。
• サイズ上限: スクリプトのソースと出力はそれぞれ 256 KiB、保存される状態は 64 KiB、取得されるログは 1 MiB までに制限されています。
• 失敗: 0 以外の終了コード、タイムアウト、無効な出力や状態、インフラストラクチャの障害が発生すると、そのイベントはアクションの実行前に停止します。そのイベントについてスクリプトが自動で再試行されることはありませんが、後続のトリガーによって再度実行できます。
• ネットワークアクセス: スクリプトの VM には、自動化のネットワーク制限と、適用されるセキュリティプロファイルが適用されます。たとえば、外部のアラートサービスをポーリングするには、そのホストが許可されている必要があります。シークレットをアタッチしても、ネットワークアクセスの権限は付与されません。

​

アクションの設定

​

セッションを開始

• Prompt: Devin が従う指示です。通常の Devin のプロンプトを書くのと同じように記述してください。
• Playbook (任意) : 追加の指示を含めるには、プロンプト内で @playbook-name を利用して プレイブック を指定します。
• Tags (任意) : この自動化で作成されるセッションにタグを追加すると、簡単に絞り込めます。

​

セッションにメッセージを送信

​

Devinをトリアージ (監視)

​

メール通知

• 常に — 実行のたびに
• 失敗時 — セッションが失敗した場合、またはエラーが発生した場合のみ
• 成功時 — セッションが正常に完了した場合のみ

​

上限と保護機能

​

ACU 上限

​

呼び出し回数の上限

​

キューイング

• Concurrent runs: この自動化で同時に実行できる run の最大数です。上限を超えたイベントはキューで待機します。run のセッションが終了して新しい指示を待つ状態になると、その run は上限のカウント対象から外れます。
• Queue depth: キューで待機できるイベントの最大数です。キューが満杯の状態で到着したイベントは破棄されます。

​

ネットワークポリシー

​

MCP 統合

​

Slackツールへのアクセス

​

アクティビティとモニタリング

• タイムスタンプ付きの最近の実行
• 各実行が成功したか、スキップされたか
• 作成されたDevinセッションへのリンク
• 失敗した実行のエラーメッセージ

​

有効化と無効化

​

Templates