機能
コンピューター操作
各 cloud agent は、完全なデスクトップ環境を備えた専用の隔離された VM で実行されます。エージェントはマウスとキーボードを使ってデスクトップやブラウザを操作できるため、自分が構築したソフトウェアと、人間の開発者のように対話できます。
そのため、エージェントは開発サーバーを起動し、ブラウザでアプリを開き、UI フローをクリックしてたどり、PR を作成・送信する前に変更が正しく動作するか確認できます。詳しくはアナウンスのブログ記事をご覧ください。
セルフホスト型マシンでは、--computer-use を付けてワーカーを起動すると、エージェントがそのマシンのデスクトップを操作できるようになります。macOS のワーカーは Cherri Code Computer Use ヘルパーアプリを使用し、Linux のワーカーは X11 ディスプレイを使用します。コンピュータの使用とデスクトップ共有を参照してください。
デモとアーティファクト
エージェントは、作業内容を示すために、スクリーンショットや動画、ログへの参照などのアーティファクトを作成します。これらのアーティファクトは PR に添付されるため、ブランチをローカルにチェックアウトしなくても、変更をすばやく検証できます。
GitHub でのアーティファクト
Cloud Agents ダッシュボードで GitHub へのアーティファクトの投稿を許可する 設定を有効にすると、Cloud Agents がアーティファクトを GitHub のプルリクエストの説明に直接埋め込めるようになります。
GitHub の画像プロキシでは公開 URL が必要なため、PR の説明に含まれるアーティファクトには、認証なしで閲覧できる、長く推測されにくい URL が使用されます。参考までに、GitHub では 2023 年 5 月まで、すべての issue と PR の添付ファイルに公開 URL が使われていました。
リモートデスクトップの操作
エージェントが作成中のソフトウェアを操作できるよう、エージェントのリモートデスクトップを引き継いで操作できます。いつでも操作をエージェントに戻して、そのまま作業を続けさせることができます。
クラウドエージェント は、リポジトリ、依存関係、ツール類、セットアップスクリプトを備えたリモート VM 上で実行されます。これにより、ローカルマシンでブランチをチェックアウトしなくても、エージェントの VM 上で変更を直接テストできます。
MCP ツール
Cloud Agentsは、チーム向けに設定された MCP (Model Context Protocol) サーバーを利用できます。これにより、エージェントは実行中にデータベースや API、サードパーティサービスなどの外部ツールやデータソースにアクセスできます。
個人用の MCP サーバーの追加と有効化は、cursor.com/agents の MCP ドロップダウンから行えます。共有サーバーは、チーム管理者が ダッシュボード -> Plugins & MCPs で設定します。
管理者は、共有の Team MCP サーバーを Default team marketplace にリンクできます。リンクすると、サーバーは Cloud Agents で引き続き利用できるほか、チームメイトが Agent Window、IDE、CLI でインストールして設定できるようになります。
Cloud Agentsは、必要とする MCP サーバーに対して OAuth をサポートしています。OAuth はユーザー単位で行われ、チームレベルで共有されている MCP サーバーにも適用されます。
カスタム MCP サーバー
HTTP または stdio のトランスポート方式を使って、カスタム MCP サーバーを追加できます。SSE と mcp-remote には対応していません。
MCP の設定は保存データが暗号化されます。機密性の高いフィールドはマスクされ、保存後はユーザーは誰も再度閲覧できません：
env— stdio サーバー用の環境変数headers— HTTP サーバー用のリクエストヘッダーCLIENT_SECRET— HTTP サーバー用の OAuth クライアントシークレット
HTTP と stdio
- HTTP (推奨) — サーバーの設定が Cloud Agents の VM 環境に存在することはありません。エージェントはリフレッシュトークン、ヘッダー、そのほかの認証情報にアクセスできません。ツール呼び出しはバックエンド経由でプロキシされます。
- Stdio — サーバーは Cloud Agents の VM 内で実行されるため、エージェントはサーバーの設定や環境変数にアクセスできます。これは Cherri Code IDE で stdio MCP がどのように動作するかに似ています。
Stdio サーバーは実行に VM 環境を必要とします。stdio サーバーが正常に動作することは、Cloud Agents が起動されるまで確認できません。可能であれば HTTP MCP を使用し、stdio サーバーを使用する場合は environment setup を正しく設定することを推奨します。
Cherri Code Cloud MCP
Cherri Code Cloud MCP は、Cloud Agent の実行中に利用できる組み込みの診断サーバーです。エージェントは現在の実行内容を確認し、同じ環境内の関連する実行をブラウズして、リンクやファイルを手動で集めることなく、トランスクリプト、diff のメタデータ、環境の詳細、実行イベント、セットアップログを取得できます。
チーム管理者は、チーム設定 の MCP Configuration から、チームの Cherri Code Cloud MCP を無効にできます。MCP の管理コントロールについて詳しくは、チームダッシュボードを参照してください。
アクセスと権限
Cloud Agent の会話には、プロンプト、コード、ツールの出力、シークレットが含まれる場合があります。すべてのツールは、リクエストごとにアクセスチェックを行います。
| 役割 | アクセスできるもの |
|---|---|
| チーム管理者 | すでにアクセス権を持っているリポジトリおよび環境について、チーム全体の Cloud Agent 実行の一覧表示と詳細の取得 (トランスクリプトを含む) が可能 |
| 非管理者 | 自分自身の実行とトランスクリプトのみ。この MCP を通じて他のチームメンバーのチャットは表示できません |
共有環境で実行を一覧表示する場合でも、非管理者に表示されるのは、自分で開始したか自分が所有するエージェントのみです。サービスアカウントにも、実行時のユーザーまたはチームのコンテキストと同じルールが適用されます。
確認できる項目
| Category | Examples |
|---|---|
| 現在の実行 | Run ID、URL、repo、ブランチ、モデル、オーナー、ライフサイクルのステータス、実行の開始元 (Cherri Code、Slack、GitHub、API など) |
| イベント | 実行ダッシュボードに表示されるセットアップ、プルリクエスト、アーティファクト、MCP 認証の結果。現在の実行には get-events を使用し、他の実行には include_events を指定した batch-fetch-details を使用します。ツールのイベントの種類を参照してください。 |
| 関連する実行 | 同じ環境内の他の Cloud Agents、または保存済み環境が関連付けられていない場合は同じリポジトリ上の他の実行 |
| 環境 | 環境バージョン、環境設定の全内容、ダッシュボード URL、実際に適用されるエグレスネットワークポリシー |
| トランスクリプト | ユーザーとエージェントの完全な会話 (利用可能な場合はツール呼び出しを含む) |
| diff のメタデータ | エージェントがコードを変更したかどうか、変更量、PR を開いたかどうか |
| セットアップログ | 環境のセットアップとイメージビルド手順の生ログ |
ツール
使用する MCP クライアントによっては、ツール名にサーバーのプレフィックスが付く場合があります (例: cursor-cloud-run-info) 。利用できるツールは次のとおりです。
| ツール | 用途 |
|---|---|
run-info | 現在の 実行 の ID、メタデータ、URL を取得します。まずはこちらを使用してください。 |
environment-info | 現在の 実行 の環境バージョン、設定、ダッシュボード URL、実際に適用される エグレスポリシー を取得します。 |
get-events | 現在の 実行 のダッシュボードイベントを、古い順に一覧表示します。 |
list-cloud-agents | この環境で表示可能な Cloud Agent の 実行 をブラウズします。ソース、ステータス、日付、コード変更、PR 作成、アーカイブ状態で絞り込めます。 |
batch-fetch-details | 特定の Run ID (bcIds) の詳細を取得します。必要に応じて、トランスクリプト、diff のメタデータ、セットアップログ、環境情報、include_events による実行イベントを含められます (実行ごとに events.json を書き込み、1 バッチあたり最大 50 実行) 。 |
get-automation | 自動化の詳細を ID から取得します。name や owner などの情報が含まれます。 |
list-environment-builds | 現在の環境の最近の ビルド を一覧表示し、ステータスを確認します。 |
environment-build-logs | ビルドのインストールログとセットアップログをダウンロードします。 |
trigger-environment-build | 現在の設定、または提案されたインストールコマンドと開始コマンドでテストビルドを実行します。 |
propose-environment-json | 環境を保存する前に、確認用のインストールコマンドと開始コマンドを提示します。 |
take-environment-snapshot | エージェントが環境のセットアップを確認した後、マシンのスナップショットを作成します。 |
check-environment-snapshot | 環境スナップショットの準備ができているかを確認します。 |
request-environment-setup-actions | シークレットの追加など、環境のセットアップを妨げるユーザー操作をリクエストします。 |
get-events と include_events を指定した batch-fetch-details から取得できるダッシュボードイベントの kind 値は次のとおりです。
kind | 意味 |
|---|---|
setup_started | 環境のセットアップが開始されました。 |
setup_completed | 環境のセットアップが完了しました。 |
setup_failed | 環境のセットアップに失敗しました。 |
pr_created | プルリクエストが作成されました。 |
pr_creation_failed | プルリクエストの作成に失敗しました。 |
artifact_created | ウォークスルーのアーティファクトがアップロードされました。 |
mcp_auth_error | MCP サーバーの認証に失敗したため、そのツールはスキップされ、実行は継続されました。 |
一般的な診断フローは run-info → get-events → environment-info → list-cloud-agents → batch-fetch-details です (他の実行のダッシュボードイベントが必要な場合は include_events を設定します) 。
サブスクリプション
エージェントのタスクが最後のコミットで終わることはほとんどありません。CI を通す必要があり、レビュー担当者からコメントが寄せられ、チームメイトが Slack の質問に回答する必要もあります。サブスクリプションを使用すると、Cloud Agent はこうしたイベントを待機し、発生時にプロンプトを再入力しなくても作業を続けられます。
エージェントはイベントソースを購読してターンを終了し、一致するイベントが届くと再開します。イベントは同じ会話内にフォローアップとして届くため、エージェントは完全なコンテキストを維持したまま作業を続けます。
- PR を作成し、レビューコメントや CI の失敗に対応する
- Slack で質問し、誰かから返信があったら続ける
- タイマーを使って長時間実行されるジョブの状況を確認する
購読するには、プロンプトで何を待つかを指定します。たとえば、「PR を作成し、CI を成功状態に保つ」や「#releases で質問し、承認を待つ」と指定します。組み込みの /subscribe スキルを呼び出すこともできます。これは同じように機能します。監視する対象を指定すると、エージェントが適切なサブスクリプションを選択します。
エージェントは、以下の連携からのイベントを購読できます。
サブスクリプションの仕組み
- サブスクリプションは1つのエージェント会話に紐づきます。イベントを受け取ると、そのエージェントはフォローアップメッセージとして起動します。
- イベントが短時間に集中した場合はまとめて処理されます。複数のイベントが連続して到着しても、エージェントは1回だけ起動し、処理前に情報源 (PR、スレッド、issue) を再確認します。
- サブスクリプションの期間は最長180日です。待機が終わると、エージェントも自ら購読を解除します。
GitHub CI サブスクリプション
CI サブスクリプションは、コミットに対するすべてのチェックが完了するまで待機し、その後コミット全体の結果を 1 件だけ配信します。結果は成功、または失敗したチェック名を含む失敗のいずれかです。
チェックによっては、人が承認するまでの間など、長時間にわたって保留のままになるものがあります。保留中のチェックが 1 つでもあると結果全体が滞り、エージェントは待機し続けます。
そうしたチェックは、保留のままにせず、GitHub の action_required を結論として完了させてください。チェックは完了扱いになりつつ、引き続き操作が必要であることを示し、必須チェックであればマージもブロックしたままになります。そのため、マージを保護したまま CI サブスクリプションを配信できます。
CI 失敗の修正
Cloud Agents は、自身が作成した PR で発生した CI の失敗を自動的に修正しようとします。現在サポートされているのは GitHub Actions のみです。
Cloud Agents は、次の場合は CI の自動フォローアップをスキップします:
- ブランチに新しいコミットをプッシュした場合。Cloud Agents は、人間が行ったコミットの CI 失敗は自動修正しません。
- エージェントにフォローアップメッセージを送信した場合。
- 同じチェックが、PR のベースコミットですでに失敗している場合。
- その PR で、CI 失敗に対するフォローアップがすでに 10 回行われている場合。
個人のすべての Cloud Agents でこの機能を無効にするには、Cherri Code Dashboard → Cloud Agents → My Settings に移動し、「Automatically fix CI Failures」オプションを無効にしてください。
特定の Cloud Agents PR でこの機能を無効にするには、その PR に @cursor autofix off とコメントします。再度有効にするには、@cursor autofix on とコメントします。
Cloud Agents に自分自身の PR の CI 失敗も修正してほしい場合は、通常どおりコメントで Cherri Code をメンションして依頼できます。たとえば、@cursor please fix the CI failures や @cursor fix the CI lint check failure のようにコメントします。
CI 失敗の自動修正は現在 Teams でのみ利用可能で、Teams 以外のアカウントへの対応は近日中に追加される予定です。それまでの間、同様の動作を望む場合は、その PR の CI 失敗を監視して修正するよう Cloud Agents に明示的に依頼してください。
OIDC ID トークン
Cherri Code 管理の Cloud Agent の VM では、ローカルソケット経由で短期間有効な OIDC JWT を発行できます。エージェントは、長期間有効なキーを保存することなく、クラウドのロールを引き受けたり、内部 API を呼び出したりできます。OIDC トークンを参照してください。
エージェント メタデータ
同じソケットからは、エージェント メタデータも利用できます。エージェント、フック、スクリプトは、エージェント ID、所有者、現在のターン、ワークスペースをプレーンテキストとして読み取れます。