Cloud Agents の実行先に、自社のマシンを選べる
Cursor は 2026 年 9 月 2 日、Self-Hosted Machines を発表しました。Cloud Agents からのツール呼び出しを、自社のネットワーク内にあるマシンで実行できる機能です。個人の端末をつなぐ My Machines と、共有ワーカーを管理する Team Pools が用意されています。公式の発表 に概要が掲載されています。
たとえば、手元の Mac にしかないビルド環境や、社内の開発用サービスへ接続する VM を、エージェントの作業場所として使うことが考えられます。環境を作り直す前に、既存の端末で実行できるかを検討できるようになります。
一方、「Self-Hosted」という名前から、モデルの推論まで社内へ移ると考えるのは誤りです。この記事では実行場所とデータ送信を分けて説明し、個人で試す手順と、共有基盤へ移す前の確認事項を紹介します。手順は公式資料に基づくもので、FIXIT の実機検証結果ではありません。
社内に置くものと、Cursor へ送るもの
Self-Hosted Machines の公式資料 では、Cursor がエージェントの処理の進行、推論、計画を担当し、自社のワーカーがファイル編集やコマンド実行を担当すると説明されています。
チェックアウト全体、ビルドキャッシュ、マシン内の認証情報は自社マシンに置きます。ただし、エージェントの処理に必要なファイル内容、コマンド出力、差分、スクリーンショット、ローカル MCP の結果などは Cursor へ送信されます。画像や動画などの成果物も、PR やダッシュボードに表示するためにアップロードされます。
FIXIT社内の Mac で実行するなら、ファイルの中身も外には出ない？
Hayate必要な内容や実行結果は Cursor に送るよ。実行場所と送信先は別に確認しよう。
導入時は「コードの置き場所」だけを申請書に書くと、送信される情報の確認が抜けます。検証用の作業を 1 つ選び、次のように記録すると話を進めやすくなります。
| 作業中の情報 | 検証で確認すること |
|---|---|
| 読み込むソースファイル | 外部の AI サービスへ送ってよい内容か |
| テストやビルドのログ | 認証情報や個人情報を出力していないか |
| 画面のスクリーンショット | 別のアプリや関係のない資料が写らないか |
| ローカル MCP の応答 | 必要以上の社内情報を返していないか |
この表は、FIXIT が提案する確認項目です。マシンを社内に置くだけで、出力される情報の分類まで自動で変わるわけではありません。ネットワークの接続可否と、データを送信してよいかを担当者と分けて確認してください。
既存の Cloud Agents の全体像やリポジトリ管理との関係は、Cursor Origin と Cloud Agents で紹介しています。
My Machines と Team Pools を選ぶ
個人で既存環境を試すなら My Machines、組織で実行環境を管理するなら Team Pools が候補になります。
| 項目 | My Machines | Team Pools |
|---|---|---|
| 主な用途 | 個人の端末や VM で作業する | 組織の共有マシンへ作業を割り当てる |
| 認証 | 個人のログインや個人用認証情報 | サービスアカウントの API キー |
| 実行先の管理 | 利用者が自分の端末を接続する | 管理者がプールとワーカーを運用する |
| 導入の規模 | 既存環境での試行や個人の作業 | 共通イメージや台数管理を伴う運用 |
My Machines の資料 と Team Pools の資料 に、それぞれの手順が分かれています。Team Pools には Cursor Enterprise プランが必要です。「チームで使う機能」という名前だけで、手元の契約で利用できると判断しないでください。
個人で試すなら My Machines
My Machines は、すでにリポジトリや開発ツールが揃っている端末を接続する構成です。最初の試験では、いつもの仕事用ディレクトリをそのまま渡すより、検証用のチェックアウトを用意すると結果を確認しやすくなります。
Cursor CLI を公式手順でインストール済みなら、検証用のリポジトリで次のコマンドを実行します。
agent --version
agent login
agent worker startワーカーのプロセスを起動したまま、Cloud Agents の画面 で実行先を選びます。環境の選択欄に接続したマシンが表示されたら、検証用の作業を送ります。終了時はワーカーのプロセスを停止します。
最初の依頼は、結果を人が短時間で確かめられるものにします。たとえば次の依頼です。テストコマンドは、そのリポジトリで使っているものへ置き換えてください。
この検証用リポジトリの README を読み、テストの実行方法を確認してください。
確認したコマンドでテストを実行し、成功・失敗と理由を報告してください。
ファイルの編集やコミットは、今回は行わないでください。これは通信の制限を保証する設定ではなく、初回の作業範囲を小さくするための依頼文です。期待したディレクトリで実行したか、必要なツールが見つかったか、ログに意図しない情報が含まれないかを確認してから、編集を伴う作業へ進みます。
共有基盤なら Team Pools
Team Pools は、名前を付けたプールで要求を受け付け、利用可能なワーカーへ割り当てる構成です。公式資料では、GPU 向けや iOS 開発向けなど、実行環境に合わせてプールを分ける例が紹介されています。ワーカーの台数を需要に合わせて変える場合は、コントローラーを運用します。
プールを用意するだけで、必要な開発ツールや権限まで揃うわけではありません。共有するイメージ、依存パッケージ、社内サービスへの接続、認証情報の渡し方を管理する担当者が必要です。
最初は同じ用途の作業だけを 1 つのプールへ送る方法を勧めます。異なる開発環境をまとめて入れると、あるワーカーでは成功し、別のワーカーでは依存関係が足りず失敗する原因を追いにくくなります。
需要に応じた増減を試すときは、処理時間に加えて待機時間と起動時間を記録します。たとえば実行が 5 分でも、マシンの起動を 10 分待つなら、利用者が待つ時間は別に評価します。この数値は説明用の例で、Cursor の性能値ではありません。
Mac の画面操作と、デスクトップ共有は別機能
Computer use の公式資料 では、macOS と Linux のワーカーが画面操作に対応しています。機能は明示的に有効化する方式です。Mac ではログイン中の GUI セッションと、Cursor Computer Use へのアクセシビリティ・画面収録の許可が必要になります。
画面操作を試す場合のコマンドは次のとおりです。--computer-use は start より前に置きます。
agent worker --computer-use startブラウザを操作させる場合は、ワーカーに Chrome または Chromium が必要です。日常業務の画面と試験用の画面が混ざらないよう、検証用アカウントや専用のデスクトップを用意すると確認しやすくなります。
ここで区別したいのが、エージェントが画面を操作する Computer use と、人が遠隔から画面を見たり操作したりするデスクトップ共有です。公式資料では、--share-desktop による共有は Linux のみです。Mac の画面操作に対応したことから、共有も同じ条件で使えるとは判断できません。
FIXIT画面操作まで使うなら、最初に何を試せばいい？
Hayate検証用ページを開いて、スクリーンショットを撮ってもらおう。権限と表示を確認できるよ。
自社で管理する費用と手間も比較する
公式の概要資料では、Self-Hosted Machines を利用しても選択したモデルの料金に従い、さらに自社のマシンやコンテナなどの費用と運用が加わると説明されています。自社マシンで動かすことだけを理由に、総額が下がるとは判断できません。
試験中は、次の 3 つを一緒に記録する方法を勧めます。
- 作業を依頼してから結果を受け取るまでの時間
- マシンの稼働時間とモデルの利用量
- 環境の準備、更新、障害対応に使った人の時間
既存環境を再利用できれば準備を減らせる可能性があります。一方、共有基盤を維持する作業が増える場合もあります。普段の作業をいくつか試し、どこで時間が増減したかを見て判断してください。
まず 1 台で実行場所と送信内容を確かめる
Self-Hosted Machines は、すでにある開発環境を Cloud Agents の実行先に選びたい場合の候補になります。最初は My Machines で小さな作業を試し、実行結果とデータ送信の条件を確認します。共有が必要になった段階で、Team Pools の契約要件と運用担当を検討する順序が分かりやすいでしょう。
編集したコードを誰が確認するかも、環境の準備と合わせて決めてください。AI コードレビューの設計 で、AI と人の役割分担を紹介しています。自社環境での試験計画やチームへの展開は、AI 開発ツール定着支援 でご相談いただけます。