自動化
Cherri Code Automations は、Cloud Agents をバックグラウンドで実行します。スケジュールに従って実行できるほか、GitHub、GitLab、Slack、Webhook、Linear などからのイベントに応じて実行することもできます。
自動化を使用すると、最近の PR コミットのバグ確認、脆弱性の詳細な確認、Slack でのバグのトリアージ、コードベースの変更の定期的な要約などのタスクを自動化できます。
はじめに
新しい自動化は、Agents Window、cursor.com/automations、ローカルエージェントセッションの /automate スキル、または Cherri Code Marketplace のテンプレートから作成できます。
/automate スキルを使うと、実行したいワークフローを自然言語で記述できます。Cherri Code が自動化のトリガー、指示、ツールを設定します。
どの方法でも、以下の手順で作成します。
- トリガーを選択します。たとえば、毎時実行する、またはプルリクエストが作成されたときに実行するよう設定できます。
- 自動化への指示を含むプロンプトを作成します。
- Slack に送信、プルリクエストにコメントする、MCP のツールなど、エージェントが使用できる任意のツールを選択します。
- 自動化にリポジトリが必要か、複数のリポジトリが必要か、まったく不要かを選択します。
- 自動化を保存して有効化します。
自動化ページには、Cherri Code が管理するエージェントも 3 つあります。
- Bugbot は、プルリクエストのバグやコード品質の問題を確認します。
- セキュリティエージェント は、プルリクエストを確認し、コードベースをスキャンして脆弱性を検出します。
- PR のルーティングと承認 は、プルリクエストを確認者に振り分け、低リスクの変更を承認できます。
請求
自動化ではCloud Agentsが作成され、Cloud Agentsの利用量に応じて請求されます。詳細はCloud Agentの料金を参照してください。
自動化はCloud Agentsとして実行されるため、各モデルでサポートされる最大のコンテキストウィンドウを使用します。コンテキストウィンドウを切り替えることはできません。
利用料金の請求先は、共有の実行者の設定によって異なります。
- 自分: 利用料金はあなたに請求されます。他のメンバーには、このオプションは作成者と表示されます。
- サービスアカウント: 利用料金はチームの利用プールに請求されます。自動化は専用のサービスアカウントで実行されるため、メンバー個人の利用量は消費されません。
個人アカウントでは、利用料金は常にあなたに請求されます。個人アカウントには共有メニューはありません。
トリガー
トリガーは、自動化をいつ実行するかを決定します。自動化には複数のトリガーを設定でき、いずれかのトリガーが発火すると実行されます。
Slack や cron スケジュールなど一部のトリガーでは、Cherri Code はデフォルトでリポジトリを使用しません。自動化でコード変更を行う場合は、エージェントが作業するリポジトリを指定してください。ソース管理トリガーでは、1 つ以上のリポジトリの指定が必須です。
スケジュールトリガー
スケジュールトリガーは、設定した間隔で実行されます。プリセットから選択するか、cron式を入力して実行時刻を細かく指定できます。
スケジュールトリガーは遅れて実行される場合がありますが、指定時刻より前に開始されることはありません。
ソース管理トリガー
ソース管理トリガーは、接続した Git プロバイダ (GitHub、GitLab、Bitbucket Cloud) からのプルリクエストやプッシュのイベントに応答します。自動化は、1 つのリポジトリまたはマルチリポジトリ環境に接続できます。
接続されたすべてのプロバイダで、主要なプルリクエストおよびプッシュトリガーがサポートされています。
- 下書きのプルリクエストを作成 - 下書きのプルリクエストが作成されたとき。
- プルリクエストを作成 - 下書きではない PR が作成されたとき、または下書きがレビュー可能としてマークされたとき。
- プルリクエストにプッシュ - 既存の PR に新しいコミットがプッシュされたとき。
- プルリクエストをマージ - PR がマージされたとき。
- ブランチにプッシュ - プルリクエスト以外で、特定のブランチにコミットがプッシュされたとき。
- コメントが追加 - 誰かがプルリクエストにトップレベルのコメントを投稿したとき。
GitHub は最も多くのトリガーをサポートしています。GitLab と Bitbucket は、上記の主要なトリガーに加え、以下の各セクションに記載されている追加トリガーもいくつかサポートしています。
GitHub トリガー
GitHub はリファレンスプロバイダーであり、すべてのソースコントロールトリガーをサポートしています。コアトリガーに加え、次のトリガーも利用できます。
- プルリクエストのラベル変更 - 特定のラベル、または任意のラベルがプルリクエストに追加または削除されたとき。
- Issue のラベル変更 - PR 以外の Issue にラベルが追加または削除されたとき。
- CI 完了 - プルリクエストまたはブランチで GitHub チェックが完了したとき。
- Issue コメント - PR 以外の Issue にコメントが投稿されたとき。
- PR レビューコメント - プルリクエストの差分にインラインコメントが付けられたとき。
- PR レビュー送信 - 承認、変更リクエスト、またはコメントとしてレビューが送信されたとき。
- レビュースレッド更新 - プルリクエストのレビュースレッドが解決済みまたは未解決としてマークされたとき。
- ワークフロー実行完了 - プルリクエストまたはブランチで GitHub Actions ワークフローの実行が完了したとき。
Cherri Code Marketplace には、失敗した GitHub Actions のトリアージとプルリクエストレビューコメントの修正用のテンプレートが含まれています。
GitLab トリガー
コアトリガーに加えて、GitLab では以下のトリガーが利用できます。
- プルリクエストのラベルが変更された - マージリクエストにラベルが追加または削除されたとき。
- プルリクエストが承認された - マージリクエストが承認されたとき。
Bitbucket トリガー
Bitbucket は Bitbucket Cloud (bitbucket.org) のみをサポートしています。Bitbucket Server と Data Center はサポートされていません。コアトリガーに加えて、以下が追加されます。
- プルリクエストが承認された - プルリクエストが承認されたとき。
Bitbucket Cloud には、プルリクエストのラベルやインラインの確認コメントに対するトリガーはありません。
プルリクエストのトリガーは、フォークから作成された PR では実行されません。ブランチがフォークにしか存在せず、リポジトリの権限で外部コードを実行するのは安全ではないため、これらの実行は「Fork pull requests not supported」エラーで失敗します。例外は Pull request merged トリガーで、マージコミットから開始されるため実行されます。これを回避するには、ブランチをリポジトリ自体にプッシュし、そこから PR を作成してください。
Slack トリガー
Slack トリガーは、Cherri Code Slack 連携のイベントに応答します。
現時点で Slack トリガーに表示されるのは、パブリック Slack チャンネルのみです。
- チャンネル内の新規メッセージ - 接続済みの Slack チャンネルにメッセージが送信されたとき。メッセージフィルターを設定しない場合、トリガーが実行されるのはトップレベルのチャンネルメッセージのみです。スレッド内の返信でも実行するには、キーワードまたは正規表現フィルターを追加します。
- 絵文字リアクション - 誰かが Slack メッセージに特定の絵文字でリアクションしたとき。
- チャンネルの作成 - ワークスペースに新しいパブリック Slack チャンネルが作成されたとき。
Webhook トリガー
Webhook トリガーは、自動化用のプライベート HTTP エンドポイントを作成します。エンドポイントに POST すると、実行が開始されます。Webhook を使用して、自動化を社内システム、CI パイプライン、監視ツールなどと連携できます。
Webhook URL を取得するには、まず自動化を保存する必要があります。保存すると、呼び出し用の Webhook URL と認証用の API キーが生成されます。
Linear トリガー
Linear トリガーは、Cherri Code Linear 連携のイベントに応答します。
- Issue created - 新しいIssueが作成されたとき。
- Status changed - Issueのステータスが変更されたとき。
- End of cycle - Linearのサイクルが完了したとき。
Sentry トリガー
Sentry トリガーは、Sentry プロジェクトでエラーや issue に関するイベントが発生したときに実行されます。エラーを自動的に調査し、根本原因を特定して修正案を提案できます。すぐに使える例については、マーケットプレイスのテンプレート Sentry issue の調査 を参照してください。
- Issue created - Sentry で新しい issue が作成されたとき。
- Issue updated - ステータスや割り当ての更新など、既存の issue が変更されたとき。
- Any issue event - すべての issue イベントタイプに一致します。
PagerDuty トリガー
PagerDuty トリガーはインシデントイベントをきっかけに実行され、インシデントの自動トリアージや解決に役立ちます。
- インシデントが発生した - 新しいインシデントが作成されたとき。
- インシデントが確認された - インシデントが確認されたとき。
- インシデントが解決された - インシデントが解決されたとき。
- 任意のインシデントイベント - すべてのインシデントイベントタイプに一致します。
ツール
Cherri Code 自動化では、GitHub、Slack、メモリ、MCP などに関する機能を拡張するためのツールを有効にできます。自動化には、他のCloud Agentsと同じ基本ツールセットも含まれています。詳細は、Cloud Agent の機能を参照してください。
プルリクエストの作成
リポジトリ連携の自動化では、自動化プロンプトで指示されたコード変更を行った後にプルリクエストを作成できます。このツールは、すべての自動化でデフォルトで有効になっています。
プルリクエストは、ソース管理トリガーで指定されたリポジトリに対して作成されます。その他のトリガーでは、環境で指定されたリポジトリが使用されます。
プルリクエストにコメントする
指定したプルリクエストにコメントを投稿します。トップレベルのレビューコメントとインラインのコードコメントをサポートします。
承認を有効にすると、エージェントは承認、変更リクエスト、レビューの却下も行えます。無効の場合は、コメントの投稿のみ行えます。
レビュアーを依頼
指定したプルリクエストのレビュアーを依頼します。エージェントは git、メモリ、その他のツールを使用して、該当分野の専門家を特定できます。
Slack に送信
Slack チャンネルにメッセージを送信します。特定のチャンネルを指定することも、エージェントが任意のチャンネルを動的に選択するようにすることもできます。
任意のチャンネルを許可すると、Cherri Code はエージェントが利用可能な公開チャンネルを検出するために必要な読み取り権限も付与します。
エージェントには、メッセージを送信できる公開チャンネルの読み取り権限が付与されます。
Slackチャンネルを読み取る
エージェントに、公開Slackチャンネルのメッセージを一覧表示・閲覧するための参照専用アクセスを付与します。
エージェントが返信やプルリクエストの作成前に、さらにコンテキストが必要な場合に使用します。
MCP サーバー
エージェントが外部ツールやデータソースを使用できるよう、MCP (Model Context Protocol) サーバーに接続します。
MCP サーバーに接続すると、エージェントはそのサーバーが公開するすべてのツールにアクセスできるようになります。自動化に必要な権限を持つ、信頼できるサーバーにのみ接続してください。
Memories
Memories を使用すると、エージェントは同じ自動化の複数の実行にわたって永続的なメモを読み書きできます。時間の経過とともに記憶し、改善していくエージェントを作るために使用します。各メモリは、エージェントの作業用ファイルシステムの外部にある名前付きエントリ (デフォルトでは MEMORIES.md) として保存されます。
Memories はデフォルトで有効ですが、無効にすることもできます。Memories はツール設定 UI で表示・編集できます。
エージェントは、自動化の実行中に古くなったメモリファイルを削除できます。ツール設定 UI からメモリファイルを削除することもできます。
Memories は複数の実行にわたって保持されるため、自動化で信頼できない入力を扱う場合は注意して使用してください。入力によって、将来の自動化の実行に意図せず影響を及ぼす、誤解を招くメモリや悪意のあるメモリが作成される可能性があります。
コンピュータ操作
コンピュータ操作を使うと、自動化によって起動されたCloud Agentが、開発者と同じようにコンピュータを操作できます。つまり、自動化でブラウザを操作したり、スクリーンショットや録画を作成したり、内部サービスを使用したりできます。コンピュータ操作は、すべての自動化でデフォルトで利用できます。
コンピュータ操作を効果的に使用するには、自動化用の開発環境が設定されていることを確認してください。エージェントに作業内容を示させたい場合は、自動化の指示でデモを求めることができます。たとえば、ユーザー向けフローを変更した後に短い画面録画を含めるよう、エージェントに指示します。
自動化の設定
モデル
自動化でCloud Agentが使用するモデルを選択できます。
リポジトリ
自動化でリポジトリを使用しないか、単一のリポジトリを使用するか、マルチリポジトリ環境を使用するかを選択します。
リポジトリ設定は、実行ごとのコードベースのコンテキストを決定します。
- リポジトリなし: エージェントはコードをクローンしません。Slack、MCP、Webhook、Linear、PagerDuty のみを使用するワークフローに適しています。コードの編集やプルリクエストの作成はできません。
- 単一リポジトリ: エージェントは 1 つのリポジトリとブランチで作業します。自動化で 1 つのコードベース内のコードを読み取り、確認、変更する場合に使用します。
- マルチリポジトリ環境: エージェントは環境内の複数のリポジトリにまたがって作業します。タスクが複数のコードベースにまたがる場合に使用します。
Slack や cron スケジュールなどの一部のトリガーでは、Cherri Code はデフォルトでリポジトリを使用しません。自動化でコードを変更する場合は、エージェントが作業するリポジトリを指定してください。
ソース管理トリガーでは、1 つ以上のリポジトリの指定が必須です。
単一リポジトリの自動化
デフォルトでは、自動化は1つのリポジトリとブランチを対象に実行されます。エージェントが単一のコードベース内のコードを読み取り、確認、または変更する場合に適しています。
ソース管理トリガーでは、プルリクエストからリポジトリが推測されます。その他のトリガーでは、自動化の設定でリポジトリとブランチを選択してください。
マルチリポジトリ自動化
自動化で複数のリポジトリにまたがる作業が必要な場合は、マルチリポジトリ環境を使用します。環境の設定時に複数のリポジトリを選択するか、Cloud Agents ダッシュボードから既存の環境を選択します。
共有
チームアカウントでは、自動化の詳細ヘッダーにある 共有 から公開範囲とIDを設定します。個人アカウントにこのメニューはありません。
実行者
- 自分: 自動化はあなたの認証情報で実行され、利用料金はあなたに請求されます。他のメンバーには、このオプションは 作成者 と表示されます。
- サービスアカウント: 自動化は専用のサービスアカウントで実行され、利用料金はチームの利用プールに請求されます。このオプションを選択できるのはチーム管理者のみです。
アクセス
- Private: 他のチームメンバーにはこの自動化が表示されません。管理できるのは自分だけです。チーム管理者は閲覧と無効化ができます。
- Members can view: チームメンバーはこの自動化を閲覧できます。自分として実行される場合は自分が、サービスアカウントとして実行される場合はチーム管理者が管理します。どちらの場合も、管理者は無効化できます。
- Members can edit: チームメンバーはこの自動化を閲覧・編集できます。
メニューには Copy link もあります。
実行者 を サービスアカウント に変更すると、自動化が使用する ID が変わります。自分の認証情報の代わりに、その自動化専用のサービスアカウントが使用されるようになります。自動化で webhook トリガーを使用している場合は、変更後に webhook の API キーを再生成してください。個人の OAuth 認証情報に依存する MCP やその他の連携を使用している場合は、それらがチームのサービスアカウント向けに設定されていることを確認してください。自動化をサービスアカウントに切り替えられるのはチーム管理者だけです。
自動化用のサービスアカウント
実行者: サービスアカウント に設定された自動化には、それぞれ専用のサービスアカウントが割り当てられます。サービスアカウントは、その設定で自動化を初めて保存したときに Cherri Code によって作成されます。保存方法 (自動化エディター、API、Terraform provider) は問いません。
Enterprise チームでは、これらのアカウントは ダッシュボード → 設定 → API キー → サービスアカウント に automation-<id> のような名前で表示されます。名前に含まれる ID とサービスアカウント ID (sa_...) は、どちらも自動化の ID とは異なります。
一部の古い自動化は、automations という名前のチーム共通のサービスアカウントを共有しています。これらの自動化は、次に保存したときに専用のサービスアカウントへ移行します。
サービスアカウントで実行される自動化は、そのサービスアカウントがアーカイブまたは削除されると実行されなくなります。automation- サービスアカウントをアーカイブする前に、そのアカウントを使用している自動化が残っていないことを必ず確認してください。
ID
自動化が外部サービスで操作を行う際は、以下の ID を使用します。
- GitHub のコメント、レビューの承認、レビュー担当者のリクエストは
cursorとして行われます。 - あなたとして実行される自動化は、あなたの GitHub アカウントとしてプルリクエストを作成します。
- サービスアカウントとして実行される自動化は、
cursorとしてプルリクエストを作成します。 - Slack メッセージは Cherri Code bot として送信されます。
プロンプトの作成
プロンプトでは、エージェントに実行してほしい内容を指定します。Cloud Agent の実行に指示を書く場合と同じように記述してください。
ヒント:
- エージェントに確認、変更、または生成してほしい内容を具体的に指定します。
- 有効にしたアクションを参照します。ツールは @メンションするか、名前をそのまま記載できます。
- ケースごとに何をすべきかの判断ルールを含めます。
- エージェントがプルリクエストを作成する、コメントする、または何もしない判断の品質基準を設定します。
- 必要な出力形式を記述します。