Cursor Origin：AIエージェントのために構築されたGitフォージを解説

Cursor Originは、CursorのオリジナルGitフォージです。リポジトリのホスティング、プルリクエストのレビュー、コードの閲覧が可能で、Cursorのコーディングエージェントがファーストクラスのアクターとして組み込まれています。2026年8月17日に有料プラン限定で初期ベータとしてリリースされました。このガイドでは、実際にリリースされた内容、GitHubミラーの仕組み、エージェントができること、そして同様に重要な「まだ不足していること」を解説します。ここに記載されている内容はすべて、Cursor公式のドキュメントに基づいています。

Cursor Originとは？

Cursorはoriginを一言で説明しています：エージェント時代のためのGitフォージ。平たく言えば、本物のGitホストです。GitHubのUIスキンではありません。リポジトリはCursor独自のリモートに存在し、標準的なgitでプッシュ・プルが可能です。

エディタで知られる企業がコードのホスティングを始めた理由：リポジトリこそが、エージェントの作業が実際のものとなり、レビュー可能・マージ可能になる場所だからです。Originによって、Cursorはリポジトリ、プルリクエスト、コードブラウジング、エージェントが共存するレイヤーへと進出しています。より大きな賭けは、単に別のGitHubを構築することではなく、フォージ自体をエージェントワークフローの一部にすることです。エディタが連携する外部システムとしてではなく。

Originは、Cursorが買収したスタック差分コードレビュー企業Graphiteのチームによって構築されました。GitHubの大規模障害と同じ週にリリースされたことでローンチが注目を集めましたが、それが目的ではありませんでした。

初期ベータでリリースされた内容

ベータは意図的に控えめな内容です。含まれているものと含まれていないものを整理します。

ベータに含まれるもの：

• 標準git（HTTPS）によるリポジトリホスティング（InternalおよびPrivate公開設定）
• インラインレビュー、チェック、マージ保護を備えたプルリクエスト
• cursor.com/codebases でのコードブラウジング、検索、コミット履歴
• 双方向PRシンクを備えたGitHubミラーリング
• Origin CLI、API、Webhook
• 3つのインテグレーション：Vercel（プレビューデプロイ）、Depot、Buildkite（CI）

ベータに含まれないもの：

• GitHub Issues、プロジェクト、ディスカッション、Wiki
• パブリックリポジトリ（オープンソースの置き場所はまだなし）
• ネイティブCIランナー、パッケージレジストリ、リリース機能
• セキュリティスキャンや依存関係アラートに相当する機能
• ストレージ制限、SLA、ベータ後の料金の公開情報

初日に3つのインテグレーションがリリースされました：Vercelはすべてのプルリクエストにプレビューデプロイを作成し、マージ時に本番環境へデプロイします。DepotとBuildkiteは継続的インテグレーションを実行し、重要なことに、どちらも既存のGitHub Actionsワークフローをそのまま実行できます。この互換性レイヤーが戦略の縮図です：ビルドシステムを書き直すことなくOriginを試せます。

利用できるユーザー

Originのコードストレージは、Pro、Teams、Enterpriseプランで利用可能です（無料プランは対象外）。アクセスは段階的に展開されるため、有料サブスクライバーでもすぐには利用できない場合があります。コードベース名（すべてのリポジトリが属する名前空間）を取得することで有効化できます。慎重に選んでください：ベータ期間中は変更できず、すべてのリポジトリURLに表示されます。

OriginはGitHubを置き換えるのか？ミラーの仕組み

まだそうではありません。Cursorもそれを求めていません。設計されたパスはミラーリングであり、良い意味で保守的です。CursorはGitHubを離れることを求めません：GitHub組織を接続し、リポジトリを選択すると、Origin固有のリポジトリと並んで表示されます。

ミラーリングは完全な履歴、ブランチ、タグをOriginにコピーして同期を維持し、プルリクエストのコメントとレビューが双方向に流れます。重要な詳細：開発者はOriginからクローンしてOriginリモートにプッシュできますが、それらのプッシュはGitHubに転送されます。Cursorは、GitHubで始まったリポジトリについてはGitHubが信頼できる情報源であると明示しています。

ブリッジには制限があります。GitHub Issuesは移行されません。ActionsのシークレットやランタイムConfigも同様です。ミラーリングされたリポジトリはGitHub上でCIを維持します。チームがOriginを権威あるものにすると決めた場合、ミラーをデタッチします：同期が停止し、Originのコピーが独立し、元のGitHubリポジトリはそのまま残ります。このデタッチが実際の移行の瞬間であり、それ以前はすべてワークフローの無料トライアルです。

ファーストクラスのアクターとしてのエージェント

上記の機能リストは、どんな若いフォージにも当てはまるかもしれません。戦略はエージェントの組み込みに表れています。Cursorのクラウドエージェントは、Originリポジトリをエンドツーエンドで作成し、クローン、ブランチ、コミット、プッシュ、プルリクエストのオープンまで行えます。

オートメーションはリポジトリイベント（mainへのプッシュ、PRのオープンや更新、スケジュール）にエージェントを紐付けます。2026年8月19日の変更履歴以降、クラウドエージェントは自分が作成したPRに自動的にサブスクライブします：サブスクライブしたエージェントはCIを監視し、失敗したチェックを修正し、レビューフィードバックに応答し、PRが変更されると起動して、作業が実際に完了するまで目標を追求します。

これにより、サードパーティのフォージがCursorに提供できないループが閉じられます：リポジトリイベント → エージェントが隔離されたVMで実行 → コード変更 → PRの更新 → CI結果 → エージェントが再起動。フォージを所有することで、すべてのホップを所有できます。ただし正確に言えば、PRレビューモデル自体は依然として従来の人間によるレビューです。賭けは、ここからループがどこで締まるかにあります。

正直な制限事項

Cursor自身のドキュメントは率直であり、移行を評価している場合はそのギャップが重要です：

• IssuesやWork Trackingがない。 ミラーリングさえされません。トラッカーは現在の場所に留まります。
• パブリックリポジトリがない。 オープンソースプロジェクトの置き場所はまだありません。
• ネイティブCI、パッケージ、セキュリティツールがない。 CIはパートナーから提供され、シークレットスキャンや依存関係アラートに相当するものはドキュメント化されていません。
• 制限、SLA、ベータ後の料金が公開されていない。 ストレージ、帯域幅、稼働時間のコミットメントはベータ時点では未記載です。
• 展開は段階的でAdmin管理下にある。 レガシープライバシーモードは完全にブロックし、チームAdminは無効化できます。

これはリリースから数日のベータへの批判ではありません。単に、エッジがどこにあるかの正直なマップです。エンタープライズの懸念についてより詳しくは、VentureBeatのローンチ分析がプラットフォームチームが尋ねるべきセキュリティレビューの質問を詳しく説明しています。

今すぐリポジトリを移行すべきか？

リスクの低いパスは設計されたものです：GitHubを権威ある情報源として維持しながらいくつかのリポジトリをミラーリングし、ブラウジング、レビュー、エージェントワークフローにOriginを使用し、CI、アクセス制御、失われるコラボレーション機能を検証した後にのみデタッチを検討してください。ベータは既存のCursorプランを超えるコストがかからないため、エージェント時代のインフラがどのような感触かを安価にプレビューできます。

Cursorがどのようにここに至ったかに興味があれば、Cursor誕生の物語がCADのアイデアから最も使われているAIコーディングツールの一つになるまでの会社の歩みを追っています。なぜ今自社のフォージを構築しているのかを理解するための有用なコンテキストです。

自分の条件で独自のエージェントワークフローを構築する

Originの本当のテーゼは、興味深い作業単位はチャットウィンドウではなく、イベントからマージされたPRまでタスクを所有する常駐エージェントだということです。それはEigentが行う賭けと同じです。ただしEigentは、ベンダーロックインなしに、あなたがコントロールするコードとワークフロー上で、マルチエージェントの労働力をローカルで実行します。エージェントが作成したプルリクエストのレビューがボトルネックになっているなら、GitHub PRsレビューワークフローがそのジョブに直接エージェントを配置します。Eigentをダウンロードして、本物のマルチステップタスクを自分のAI労働力に任せてみてください。