Factory Automationsレビュー：Slack、GitHub、Webhook

Factory Automationsを使うと、スケジュール、Slackのトップレベルメッセージ、GitHubイベント、外部からのHTTPリクエストをきっかけにDroidセッションを起動できます。ただし、WebhookトリガーはまだPrivate Previewです。スケジュールも固定されたUTC時刻で動作し、夏時間への自動追従はありません。現時点では、無条件に本番展開する機能というより、範囲を限定したパイロット導入に向いた仕上がりです。

Factory Automationsで実行できること

各オートメーションは、トリガー、指示、実行時のID、実行先を組み合わせて構成します（Factoryのドキュメント）。

オートメーションは非公開にも、組織内で共有することもできます。一方、セッションのプライバシー設定は、実行によって作成されたセッションを誰が開けるかを個別に制御します。

トリガーの選択で運用方法が変わる

スケジュール実行：最初に試しやすい選択肢

スケジュールには「every Monday at 9am PST」のような自然言語や、0 9 * * 1のようなcronを指定できます。Factoryは実行時刻をプレビュー表示しますが、cronはUTCで解釈されます。タイムゾーンを含む時刻を指定した場合も、固定されたUTCスケジュールに変換されるだけで、夏時間の変更に合わせて自動調整されることはありません（Factoryのドキュメント）。

最初の用途としては、毎日のステータスダイジェスト、依存関係の監査、古いドキュメントのチェック、コードをマージせず証拠をまとめるPRレビュー担当などが適しています。

Slackメッセージ：便利だが、対象はトップレベルの通知

Slackオートメーションは、アクセス可能なチャンネルに条件一致するトップレベルメッセージが投稿されたときに起動します。スレッドへの返信だけでは、個別に実行は始まりません。チャンネル名のパターン、送信者の種類、キーワード、除外キーワード、除外する送信者などでフィルタリングできます。

実行結果は、トリガーになったメッセージのスレッドに返信されます。複数のオートメーションが一致した場合、そこに返信するのは最初の1つだけです。それ以外は、元のメッセージへのリンクを付けた別メッセージを投稿します。Factoryは、プライベートチャンネルへのアクセスルールを含め、これらの挙動をドキュメント化しています（Factoryのドキュメント）。管理されたインシデント用チャンネルには向いていますが、後続の返信をすべて処理するワークフローには適しません。

GitHubイベント：明確なセットアップ手順を経れば強力

カスタムGitHubオートメーションでは、プルリクエスト、プッシュ、コメント、ラベル変更、チェック完了、スケジュールをきっかけに処理を実行できます。実行基盤はGitHub Actionsで、作成時には選択した各リポジトリにセットアップ用のプルリクエストが作成されます。

ワークフローを有効にするには、そのセットアップ用プルリクエストをマージしなければなりません。ワークフローがデフォルトブランチに入る前に開始された実行は失敗します。また、それまではコメントの投稿、コミットのプッシュ、プルリクエストの作成もできません。定期的な作業がすでにリポジトリイベントと結び付いていて、通常のプルリクエストレビューをリリースの境界として維持したいなら、GitHubは最も強力なトリガーです。

Webhook：実用性はあるが、利用には制限

FactoryはWebhookオートメーションをPrivate Previewとして案内しており、有効化にはサポートへの問い合わせが必要です。外部からのHTTP POSTで実行を開始できますが、ユーザーのローカルマシン上で動かすことはできません。Droid Computerまたは実行テンプレートが必要です。

FactoryはWebhook URL、X-Webhook-Secretヘッダーの利用方法、そしてヘッダーを設定できない送信元向けにURLへシークレットを含める形式を提供します。URLに含めたシークレットはログに残る可能性があるため、ドキュメントではヘッダー方式を推奨しています。シークレットは一度しか表示されず、ローテーションすると古い値は無効になります（FactoryのWebhookドキュメント）。

同じドキュメントでは、リクエストボディの上限を200 KiB、受け付けるリクエスト数を毎分60件、配信記録の保持期間を30日、同一ボディの重複排除期間を10分、実行数の上限を1時間あたり10回と定めています。アラート対応のテストには十分な制御ですが、Private Previewである以上、アクセスが常に保証される必要のある本番環境の基盤にするにはまだ早いでしょう。

自動化の安全性を左右する制御ポイント

スケジュール、Slack、Webhookのオートメーションは、ユーザー本人として実行することも、共有サービスアカウントとして実行することもできます。IDの選択は、コネクターへのアクセス権、課金、Slack上での表示に影響します。実行先に関するルールはFactoryのドキュメントにまとめられています。

プロンプトは狭く具体的にし、取り消し可能な認証情報を使い、専用の実行先を選びましょう。デプロイやマージの権限は、既存のリポジトリ側の制御に残しておくべきです。FactoryのSlack Marketplace掲載情報にも、アプリが間違える可能性があること、コードや回答を必ず再確認することが明記されています。

あるユーザーは、Linuxデスクトップアプリがないことや、コンピューター間の同期に対応していないことを含む監督上のギャップを指摘しています（X上の@JoelDeTevesによる投稿）。デスクから離れた場所で長時間動く自動処理を監督したいチームにとっては、見過ごせない点です。

Factory Automationsと単純なGitHub Actionの違い

毎日のPRダイジェストのように、決まったAPI処理を行うだけならGitHub Actionを使いましょう。調査、リポジトリの文脈理解、コード変更案の作成、人が読めるセッションの生成まで必要ならFactoryが向いています。短いスクリプトを書く手間を省くためだけに、エージェントプラットフォームを選ぶべきではありません。

権限拡大につなげる低リスクなパイロット

1. 新しいプルリクエストのレビューや生成ファイルのチェックなど、入力範囲を限定できる定期タスクを1つ選ぶ。
2. Webhookではなく、まずはスケジュールオートメーションから始める。プレビュー機能へのアクセスが不要で、実行頻度も確認しやすい。
3. 出力はデプロイやマージではなく、レポートまたはプルリクエストにする。
4. 失敗した実行、処理できなかった作業、変更されたファイル、人が加えた修正を記録する。マージされたPRの数だけでは十分な証拠にならない。
5. 拡張するときは、一度に1つの要素だけを増やす。タスクの種類、リポジトリ、トリガーのいずれか1つに限定する。

Factoryのワークフローに関するガイダンスでは、元の失敗を再現し、クリーンな環境で修正をテストし、隣接するケースでも確認してから、再利用可能な指示として残すことを推奨しています。Automationのパイロットでも、これを評価基準にするのが妥当です。

FAQ

Factory AutomationsはWebhookに対応していますか？

対応しています。ただし、WebhookトリガーはPrivate Previewで、組織単位での有効化が必要になる場合があります。実行にはDroid Computerまたは実行テンプレートが必要です。詳しくは上記のWebhookセクションを参照してください。

Slackのスレッド返信でオートメーションは起動しますか？

起動しません。実行を開始できるのは条件に一致するトップレベルメッセージだけです。詳しくはSlackメッセージを参照してください。

スケジュールは夏時間に追従しますか？

追従しません。Factoryは固定されたUTCスケジュールを保存するため、現地の夏時間ルールが変わったときは見直しが必要です。詳しくはスケジュール実行を参照してください。

セットアップ用プルリクエストをマージする前に、GitHubオートメーションは実行されますか？

実行されません。まずセットアップ用プルリクエストをデフォルトブランチに取り込む必要があり、それより前の実行は失敗します。詳しくはGitHubイベントを参照してください。

Webhookの配信が重複した場合はどうなりますか？

同一のボディが10分以内に再び届くと、Dedupedとして記録され、新しい実行は開始されません。Factoryは、フィルタリング、レート制限、スキップ、失敗となった配信も記録します。

見落としてはいけないトレードオフ

成果物をプルリクエストのレビューループ内に収められるなら、スケジュール実行やGitHubトリガーのパイロット導入から始めるとよいでしょう。Slackはトップレベルメッセージを使う運用ルールと相性がよく、Webhookもテストできる程度の機能は備えています。ただし、Private Previewである以上、本番インシデント対応システムの土台として使うのはまだ避けるべきです。