CursorがAIエージェントのフリートからのコードをホストするOriginを構築し、本日ローンチ

Why it matters

Origin would give Cursor control of the repository layer beneath its editor, cloud agents and code review, turning a coding tool into an integrated software-production stack.

Michael Truell (@mntruell), Cursorの共同創業者兼CEOは6月16日にOriginを紹介した。OriginはAIエージェントのチームが生成したコードを扱うように設計されたGitプラットフォームだ。Cursorは当初プロダクトを業務用メールのウェイトリストに限定していたが、8月11日にOriginをローンチする予定だ。

このローンチにより、Cursorはエージェントへの作業割り当てから、コードの作成、テスト、レビュー、保存、マージに至る一連の流れ全体にわたる存在感を拡大する。Originは、エージェント優先のエディタ、クラウド実行、プルリクエストの自動レビュー、ワークフロー自動化、カスタムエージェント構築用のSDKを既に含む製品ラインにリポジトリホスティングを追加する。

Tomas Reimers、code-review開発者Graphiteの共同創業者は、Cursor内でOriginを率いている。Cursorは2025年12月にagreed to acquire Graphiteと発表しており、より高速なコード生成によって生じる次のボトルネックがレビューと安全なマージだと判断したためだ。Reimersは当初、Merrill LutskyとGreg FosterとともにGraphiteをエンジニアのブロッキングを防ぐ内部ツールとして作り、後にコードレビュー製品に転用していた。

CursorのCompile conferenceでReimersはチームとエージェント向けの新しいGitプラットフォームとしてOriginを発表した。デモの報道は、エージェント向けAPI、Model Context Protocol対応、マージコンフリクトやCI失敗への自動応答、および多くのエージェントが並行して変更をプッシュすることを想定したインフラを備えたGit互換サービスを報告した。Cursorのデモは1リポジトリあたり22.6コミット／秒のスループットを主張したが、その数値に関するベンチマーク手法や本番実績はCursorから公表されていない。

その数字はリポジトリの取り込み量を示しているのであって、ソフトウェアの品質を示すものではない。フォージは何千ものエージェントコミットを受け入れることはできても、それらの変更が正しいか、安全か、マージに値するかを確立するわけではない。Cursorのより大きな製品戦略は、コードを生成するエージェントの周囲に自動レビューとポリシー制御を配置することでそのギャップに対処している。

Origin is a Git host, not a replacement for Git

Originは最も適切にはフォージとして理解される：リポジトリを格納し、コラボレーション、プルリクエスト、権限、チェック、マージを管理するGitの周辺サービスだ。基盤となるバージョン管理システムは依然としてGitである。OriginはGitHubやGitLabが占めるリポジトリとコラボレーションのレイヤーに位置づけられている。

この区別は移植性にとって重要だ。標準的なGit履歴、ブランチ、タグは一般に互換性のあるホスト間で移動できる。プルリクエストの議論、イシュートラッカー、アクセスポリシー、CI構成、アプリケーション統合はホスト固有である。したがって、Originを真剣に評価するには、Cursorのインポートツール、ID管理、既存の開発パイプラインとの互換性が判断材料になるだろう。

8月11日のローンチを前に、CursorはOriginの価格、セキュリティアーキテクチャ、データ処理条件、移行ツールを公表しておらず、パブリックな製品ページは引き続き業務用メールのウェイトリストのみを提供していた。Cursorは6月の発表時点でOriginは2026年秋に予定されているとしており、8月のローンチは当初の公開スケジュールより早いものとなった。

What an agentic Cursor team can use today

Originは、Cursorが2026年を通じて組み立ててきたスタックの一層に過ぎない。チームは並列でエージェントを動かし始めるためにOriginを必要としないが、リポジトリとプルリクエストは既存のホストに残しておくことができる。

Cursor 3、4月2日リリースは、ローカルとクラウドのエージェントを1つのインターフェースに配置するワークスペースを導入した。デスクトップ、ウェブ、モバイル、Slack、GitHub、Linearから開始したエージェントが一緒に表示され、タスクはローカルマシンとCursorのクラウド間で移動できる。Worktreesは別々のブランチでの同時変更を分離し、マルチルートワークスペースは1つのセッションで複数のリポジトリを1つのエージェントが変更することを可能にする。

Cursorはまたasynchronous subagentsをサポートしている。親エージェントは作業をより狭いジョブに分割し、各ジョブに別個のコンテキスト、モデル、ツール権限を与えられる。/multitask ワークフローは大きな要求を並列ストリームに分割でき、ネストされたサブエージェントはさらに委任を行える。これが現在のCursorにおけるエージェントチームの最も近い実装である：人間や親エージェントが作業を分解し、専門化されたエージェントが実行し、そのアウトプットが統合とレビューのために戻される。

Cloud agentsは専用の仮想マシンで実行され、それぞれが依存関係とネットワークアクセスを持つ。開発者がノートパソコンを閉じても処理を継続でき、ログ、スクリーンショット、デモなどのアーティファクトを返すことができる。これによりオペレーターの仕事はすべてのツール呼び出しを監視することから、タスクの指定、受け入れ基準の定義、結果の確認へと変わる。

Truellは2月に、Cursor内部でマージされたプルリクエストの35%がクラウド仮想マシンで自律的に実行されるエージェントによって作成されたと記している。これはCursorが報告する内部指標だが、Originのタイミングを説明する：Cursorはすでに、エージェントの出力が本番作業の重要な割合を占めるようになったときに現れるレビュー、環境、調整の問題を経験している。

Rules, automations and custom agents form the operating layer

Cursorのチーム製品は、個々のプロンプト運用習慣を共有インフラに変える。現在のTeams planはユーザーあたり月額40ドルからで、ルール、スキル、プラグインを配布するためのプライベートなチームマーケットプレイスを含む。チームはリポジトリの慣習、テスト要件、定期的なワークフローをエンコードし、各エンジニアが個別にエージェントを設定する代わりに共有できる。

Automationsは、スケジュールやGitHub、Linear、Slack、PagerDuty、Webhookなどのサービスからのイベントによってトリガーされる常時稼働のエージェントを作成する。各実行はクラウドサンドボックスを開始し、設定された指示、モデル選択、MCP接続に従う。適切なジョブには、バグ報告のトリアージ、失敗ビルドの調査、依存関係の更新、定期的なプルリクエストの準備などが含まれる。

アプリケーションロジックを必要とするワークフロー向けに、パブリックベータのCursor SDKは、Cursorのデスクトップ、CLI、ウェブ製品全体で使用されるのと同じエージェントランタイムを公開する。開発者はTypeScriptやPythonからローカルまたはクラウドエージェントを起動し、その作業をストリームし、CIシステムや社内ツールに組み込むことができる。6月のアップデートではカスタムツール、設定可能な状態ストア、ネストされたサブエージェント、リスクのあるツール呼び出しを承認待ちにできる自動レビュー層が追加された。

レビュー層はBugbotで、Cursorの利用量課金型プルリクエストレビュワーだ。チームはレビューの労力を設定し、MCPを通じて追加のコンテキストを接続できる。CursorによればBugbotはリアクションや人間のコメントからレビュー規則を学習し、チームの基準と将来の自動レビューとの間にフィードバックループを作り出すという。これらの性能と解決指標は依然としてCursor自身の計測である。

Governance becomes the limiting factor

複数のエージェントを運用すること自体は比較的簡単だ。問題は彼らに本番用資格情報、ネットワークアクセス、コードをマージする権限を与えるかどうかという組織的な判断のほうが難しい。

Cursor Enterpriseは現在、異なる予算、承認済みモデル、エージェント権限を持つorganizations, teams and groupsをサポートしている。管理者は実験的なユーザーを本番チームから分離し、リポジトリとMCPアクセスを制限し、ネットワークポリシーを適用し、コマンド実行を制御し、使用状況を検査できる。Cursorの自動レビュー方式は、不確実なシェル、MCP、fetch操作を分類器経由でルーティングし、実行を許可するか人間の承認を求める前に処理することもある。

したがって実用的なエージェント主体のチームには明確な境界が必要だ：分離されたブランチやworktrees、再現可能な環境、文書化された受け入れ基準、制限された資格情報、決定論的なテスト、最終マージの人間による所有など。並列エージェントはアウトプットを増やすが、同時にフラッキーなテスト、競合する変更、不必要なプルリクエストを倍増させる可能性もある。

Originはそのようなアウトプットによって生じる調整圧力に対するCursorの提案される回答だ。その戦略的価値は生のコミットスループットではなく、レビューの質、ポリシー施行、移行サポートに依存するだろう。8月11日のローンチにより、差し迫った問いは「Originはいつ到着するか」から「Cursorがエンジニアリングチームがシステム・オブ・レコードを移行する前に必要とする運用上の詳細と互換性を提供できるかどうか」へと移った。