Cursorは、コードを書くだけでなく、ホストすることも望んでいます。2026年8月17日、同社はすべての有料プランで、自社製gitホスティングサービス「Origin」の早期ベータ版の提供を開始しました。リポジトリ、プルリクエスト、コード閲覧、双方向GitHub同期が初日から提供され、これらすべてがエディター内の新しい「コードベース」タブに統合されました。
その主張は明確です。Gitフォージは、人間が1日に数回コミットをプッシュするために設計されました。そしてCursorは、次の10年間のバージョン管理が、エージェントがブランチを開き、PRを更新し、24時間体制で作業をマージすることによって形作られると賭けています。Originは、この仮定に基づいて最初から設計された最初のホスティングプラットフォームです。
チームがAPIを構築している場合、これは思ったよりも早くあなたに影響を与えます。OpenAPI仕様、CI駆動の契約テスト、レビューワークフローのすべては、Gitリモートが指す場所に存在します。ここでは、Originが現在できること、不足していること、そして試用する場合にAPIワークフロー（Apidogテスト自動化を含む）を維持する方法を説明します。
Originとは
OriginはCursorが運営するクラウドGitフォージです。初期ベータ版には以下のものが含まれます。
- ホストされたリポジトリ：コードベースタブから、ウェブサイト
cursor.com/codebaseから、またはタスク実行中のCursorエージェントから作成できます。リモートはhttps://cursor.com/codebase/{owner}/{repo}のパターンに従い、標準的なgit clone、push、pullが機能します。 - プルリクエスト：タイムライン、コミット、チェック、差分、コメント、マージなど、期待される機能が含まれており、エディター内またはブラウザでレビュー可能です。
- ウェブでのコード閲覧と検索：リポジトリレベルおよびコードベースレベルの設定が可能です。
- 専用CLI：エディターとは別のターミナルワークフロー用です。
- エージェント統合：これが実際のポイントです。エージェントはコードベースを読み取り、それに関する質問に答え、変更を加え、PRを更新し、ブランチをプッシュできます。これは、あなたがエージェントの作業をレビューするのと同じ画面で行われます。変更ログによると、さらに多くの「エージェントネイティブ機能が近日中に提供される」とのことです。
利用可能状況：Pro、Teams、Enterpriseプランのみ。無料プランのユーザーはOriginリポジトリを作成できません。また、エンタープライズ組織は完全にオプトアウトできます。ストレージクォータ、パブリックAPI、Webhookなどの詳細はまだ文書化されていません。重要なものを移行する前にこれを覚えておく価値があります。CursorのOriginドキュメントで現在の状態を確認してください。
Originの登場は、同社にとって多忙な月の締めくくりとなりました。SiliconANGLEのレポートを含む報道では、このローンチがSpaceXによるCursor買収完了の数日後に行われたことも指摘されています。製品のエディター側の復習については、当社のCursorガイド（知っておくべきことすべて）で基本をカバーしています。
GitHub同期が賢い部分
週末に企業がGitHubから移行することはありませんし、Cursorもそれを知っています。そのため、Originのベータ版は移行ではなく、双方向同期に重点を置いています。
- GitHubリポジトリをOriginにミラーリングすると、同期されたリポジトリはリアルタイムで更新されます。
- PRコメントとリアクションは数秒以内に双方向で同期されます。Cursorに残されたコメントはGitHubに投稿され、GitHubの返信はCursorに表示されます。
- GitHubは真実の情報源であり続けます。元のリポジトリがGitHubに存在する場合、プッシュはGitHubに流れ続け、Originはより優れたエージェントストーリーを持つライブミラーであり、代替のリモートではありません。
- アクセス権限はGitHubの読み書き設定をミラーリングするため、同期によってリポジトリに触れることができる人が密かに増えることはありません。
これは、CursorがVS Codeに対して成功したのと同じ、低コミットメントの採用パターンです。誰も去るように求めず、既存のものと並んで存在し、新しいワークフローが利便性で勝つようにします。GitHubの設定が何も変わらないため、プラットフォームチームに知られることなく、月曜日にOriginのPRレビューUIを試すことができます。
戦略的な裏事情は無視できません。GitHubは15年間コードのデフォルトの拠点であり続けており、そのAIストーリーはCopilotを通して展開されていますが、これはCursorと直接競合します。私たちはCursor対GitHub Copilotで両者を比較しました。Cursorが独自のフォージを構築することは、エージェントのロードマップが競合他社のプラットフォームによって制限されることをもはや望まないという意思表明です。
不足しているもの（現時点では多い）
ベータ版はフォージであり、完全なDevOpsプラットフォームではありません。リリース時点でのOriginには以下のものがありません。
- ネイティブCI/CDなし。 代わりに、DepotとBuildkiteはリポジトリの「アプリ」タブから接続し、Originリポジトリに対して既存のGitHub Actionsワークフローファイルを実行できます。これは実用的な橋渡しですが、GitHubに組み込み製品があるのに対し、サードパーティの依存関係です。
- イシュー、議論、Wikiなし。 コードレビューのみがコラボレーションのプリミティブです。
- セルフホスティングなし、文書化されたパブリックAPIなし、Webhookなし、ストレージ制限の明示なし。
- 注目すべきローンチパートナーが1つ： 「アプリ」タブからVercelを接続すると、すべてのPRがプレビューデプロイメントを取得し、マージ時に本番環境にデプロイされます。これはVercelがGitHubリポジトリで実行しているのと同じフローです。（Vercelは最近急速に進化しており、GPT-5.6 Sol割引を実行しているのと同じGatewayです）。
GitHubが同期の背後にある真実の情報源であり続ける限り、これらのギャップの多くは問題になりません。しかし、チームがOriginを主たるものと見なし始める日には、これらは非常に重要になります。ベータ版はレビューおよびエージェントレイヤーとして扱い、インフラストラクチャとして扱わないでください。
APIチームにとっての具体的な意味
APIワークフローは、おそらく3つの点でフォージに触れています。仕様はリポジトリに存在し、契約テストは各PRでCIで実行され、レビュアーは両方の変更を承認します。Originでは、それぞれが現在どのように対応しているかを説明します。
仕様と設計レビュー。 デザインファーストのワークフローに従う場合、OpenAPIファイルはリポジトリ内で最も多くレビューされる成果物です。OriginのPR差分はYAMLを他のテキストと同様に扱い、双方向コメント同期により、GitHubを使用しているAPIレビュアーとCursorを使用しているエージェントオペレーターが同じスレッドを見ることができます。何も壊れませんが、今のところ何も改善されません。興味深い部分は、エージェントが仕様変更をPRとして提案し始める時です。これこそOriginが構築されたループです。当社のCursor内でApidog CLIを実行する方法に関するガイドでは、コミットする前にエディターのエージェントが仕様を検証できるようにする方法をすでにカバーしています。
CI契約テスト。 Apidog CLIは、あらゆるCIシステムでステップとして実行されます。OriginのCIに対する回答は「DepotまたはBuildkiteを介してGitHub Actionsワークフローを持ち込む」ことです。実際には、apidog run --scenario smoke-testsのような既存のワークフローステップは、ワークフローファイル形式が同じであるため、変更なしで引き継がれるはずです。正直な注意点としては、DepotのActions互換レイヤーが、広く使われているすべてのアクションに対して検証されているわけではなく、今週中に誰も検証していません。リリースブランチに信頼する前に、ミラーリングされた使い捨てリポジトリに対してパイプラインを実行してください。
エージェント駆動の変更には、エージェント耐性のあるゲートが必要です。 Originの前提は、より多くのコードがエージェントからより速く提供されることです。これにより、各PRでの自動化された決定的なチェックの価値が高まります。なぜなら、人間によるレビューがボトルネックになるからです。レスポンススキーマがずれた場合にビルドを失敗させる契約テストスイートは、エージェントのスループットに合わせて拡張できるまさにその種のゲートであり、Apidogでは5分で設定できます。一度仕様に対してアサーションを定義し、OriginのPRを実行するCIでCLIから実行します。Apidogをダウンロードして、エージェントがプッシュアクセスを得る前にそのゲートを設置し、より広範なテストループについては、当社のCursorでのQAテストウォークスルーをご覧ください。
試すべきか？
意思決定のショートカット：
- Cursor有料プランのソロ開発者および小規模チーム： はい、リスクは低いです。リポジトリをミラーリングし、PRビューを使用し、GitHubを真実の情報源として維持します。Originが定着しなくても何も失うことはありません。
- GitHub Actionsに多大な投資をしているチーム： まずはサイドプロジェクトで試してみてください。ワークフローは理論的にはDepotまたはBuildkiteを介して移植可能ですが、「理論的に移植可能」は移行計画ではありません。
- コンプライアンス要件でGitHubを指定しているユーザー： 待ってください。セルフホスティングなし、文書化されたAPIなし、そして早期ベータ版というラベルは、規制されたコードにとってOriginを現状では不適格にします。
- すでにCursorエージェントを積極的に使用しているチーム： これがOriginのターゲットです。もしあなたがCursorのエージェント機能を日常的に使用しているなら、エージェントがファーストクラスのユーザーとして扱われるフォージでPRを開いたり更新したりすることは、今すぐ本当のワークフローの改善になります。
フォージはエージェントのインターフェースになりつつある
本当のストーリーは、GitHubに新しい競合が現れたということではありません。Cursorは、リポジトリ自体が主にエージェントのインターフェースになりつつあり、人間がほとんどの変更を作成するのではなく、レビューするようになるだろうと考えています。Originが勝つかどうかにかかわらず、すべてのフォージはその方向へと引っ張られていくでしょう。そして、APIチームがそれを最初に感じるでしょう。なぜなら、仕様と契約テストはソフトウェアにおいて最も自動化可能なレビューゲートだからです。
いずれにせよ、準備は同じです。APIチェックをスクリプト化可能でフォージに依存しないものにしてください。Apidogは、仕様、モック、テストシナリオを1か所にまとめ、CLIから実行します。これは、PRがGitHubの人間から来たものか、Originのエージェントから来たものかを問いません。無料で試して、フォージ戦争で誰が勝っても、レビューゲートがあなたと共に移動するようにしてください。
FAQ
Cursor Originは無料ですか？ いいえ。Originのコードストレージには、有料のCursorプラン（Pro、Teams、またはEnterprise）が必要です。無料プランのユーザーはOriginリポジトリを作成できません。また、エンタープライズ組織はOriginから完全にオプトアウトできます。
使用するためにGitHubを離れる必要がありますか？ いいえ。ローンチ時の設計では、そうする必要がないとされています。GitHubリポジトリをOriginにミラーリングすると、GitHubは真実の情報源であり続け、プッシュ、PRコメント、リアクションはほぼリアルタイムで双方向に同期されます。
OriginにはCI/CDがありますか？ ネイティブにはありません。DepotとBuildkiteは「アプリ」タブを介して接続し、既存のGitHub Actionsワークフローファイルを実行します。VercelもPRプレビューデプロイメント用に統合されています。
エージェントはOriginを直接使用できますか？ はい、それがコア機能です。Cursorエージェントはリポジトリを作成し、コードベースに関する質問に答え、プルリクエストを更新し、ブランチをプッシュできます。Cursorは、さらに多くのエージェントネイティブ機能が近日中に提供されると述べています。当社のCursorエージェントモードガイドでは、エージェントがエディターで現在できることをカバーしています。
OriginのプルリクエストでAPIテストを実行するにはどうすればよいですか？ GitHubで行うのと同じ方法です。CIステップとしてApidog CLIを実行します。Originでは、DepotまたはBuildkiteをリポジトリに接続し、既存のActionsワークフローを再利用することになります。その際、apidog runコマンドは変更されません。