自動化処理

自動化処理は、誰からの指示もなく毎回作業を開始します。スケジュールに従って実行されるか、何らかの事象が発生した際に動作します：pull requestが開かれたり、課題が登録されたり、チェックやデプロイが失敗したりします。

すべての自動化処理はファクトリー内の「Automations」セクションに一覧表示され、どのきっかけで起動し、何を実行するかが記載されています。「新規作業」から自動化処理を作成できます：自動化処理を選択し、実行タイミングと実行内容を自分の言葉で指定します。

2種類のトリガー#

トリガーが時間に関連する場合、または監視対象のシステムがSentryやJiraのようなCoroidイベントを送信しない場合はスケジュールを利用します。スケジュール機能は該当システムに問い合わせます。MCPサーバーを見つけたら作業を開始します。詳細はスケジュール。

Coroidが事象発生の瞬間を検知できる場合はイベントを利用します。これにより、繰り返し問い合わせるスケジュールよりも無駄な作業が減ります。

「新規作業」で選択可能なイベント#

GitHubからの情報で、これが必要ですGitHubアプリ：

• pull requestが開かれたり、更新されたり、マージされたりした場合
• 課題が開かれた場合
• Coroidがコメントに言及された場合：リポジトリへの書き込み権限を持つユーザーによるコメントのみが対象となります。

Coroidからの情報：

• 課題、計画、品質チェック、デプロイ、またはデプロイヘルスチェックが失敗した場合
• デプロイが成功した場合
• リリースがロールバックされた場合

自社システムが発火させるイベントにはサービスアカウントが必要で、Slack、Telegram、Jiraのイベントにはフィルターが必要です：自動化処理のエディタでイベント設定を変更してください。詳細はフック。

実行内容#

エージェントは指定された指示に従います。プロジェクトのコードを読み取り、課題を作成することはできますが、直接変更を行うことはありません。エージェントが作成した作業は他の作業と同様に仕様策定、計画、ビルド、検証、レビューのプロセスを経て、最終的にあなたが承認するpull requestとなります。

スケジュールに従う自動化処理では、代わりにテスト環境でブラウザテストを実行することもできます。

Coroidが作成した常駐型の自動化処理は品質管理内のスイッチとして機能し、「新規作業」で作成するものではありません：

• プルリクエストのレビュー品質管理の プルリクエストグループが各pull requestでプロジェクトのチェックを実行し（Coroid品質管理）、そこにCoroidレビューコメントが付与されます。
• メッセージや課題をリクエストに変換するSlackやTelegramのメッセージ、GitHubでCoroidが言及されたコメント、新規のJira課題は、品質管理の「作業開始前」で対応ソースが有効になっている場合にリクエストに変換されます。詳細は 課題追跡ツールJira用
• 障害への対応失敗した課題、デプロイ失敗、ロールバックされたリリースにはそれぞれ下記のスイッチがあります 何かが壊れた場合。
• 既存の技術的負債の整理プロジェクトの 週次の技術的負債整理はAnti-slop行にあるスイッチです。

スイッチが管理する自動化処理は、ファクトリーのページに記載され、該当スイッチへのリンクが示されます。そこで一時停止したりオフにしたりできます。指示を変更すれば、確認後に自分専用の自動化処理になります。

以前に作成されリクエストを作成していた自動化処理は引き続き実行され、Automationsセクションに一覧表示されます。プルリクエストをレビューしていた自動化処理は、品質管理がCoroidレビューを引き継いだ際に一時停止されました。

「新規作業」のテンプレート#

「新規作業」では以前テンプレートが提供されていました。その機能は上記のスイッチに移行され、Slackに投稿する2つのテンプレートは自分の言葉でチャンネル名を指定してカスタマイズできます。これらはMCPサーバーを通じて投稿されます。このサーバーは「設定」の「接続」セクションで接続します：スケジュール処理でも利用可能で、イベント型自動化処理でもファクトリーのエディタでMCPツールを有効にすれば利用できます。テンプレートから作成された自動化処理はそのまま実行され続けます。古いテンプレートへのリンクは、それに置き換わったスイッチ、または「新規作業」に遷移します。

自動化処理の監視#

ファクトリーで自動化処理を開くと、各実行履歴を確認できます：実行時刻、コスト、作成された作業、実行が完了しなかった理由などです。そこから所有者や管理者は自動化処理を一時停止、テスト、編集、削除できます。組織内の全員が自動化処理とその実行履歴を閲覧できます。

自動化処理を有効に保つ#

自動化処理が作成する作業は、他の作業と同じエージェントスロットを争います。頻繁に起動する自動化処理は、気づかないうちに処理能力を使い果たしてしまう可能性があります。

1. 人が依頼した作業よりも低い優先度を設定してください。 P2またはP3。
2. トリガーを具体的に指定してください。「チェックに失敗しました」という通知は、アクティブなリポジトリで頻繁に発報されます。一方、「ベースブランチでこのチェックが失敗しました」という通知は、実際に問題が発生した場合にのみ発報されます。
3. その結果をご覧ください。自動化処理が20件のタスクを作成しても、そのうち2件しかマージされない場合、それは価値ではなく無駄な作業とコストを生み出しているだけです。

自動化処理の真の評価基準は、作成された作業のうちどれだけがマージされるかであり、発報頻度ではありません。

Sentinel#

以前のバージョンのドキュメントでは、条件を監視するモニターであるSentinelについて説明していました。これは別個の機能ではありません。条件とは、自動化処理が実行できるイベントか、スケジュールでチェックされる項目のいずれかです。

関連項目#

• スケジュール
• フック
• 作業を開始する方法
• ソフトウェア製造プラットフォーム