TITLE

Cursor が「Origin」を発表 — コードホスティングまで内製化するAI IDEの意味

投稿日：2026.08.19

Origin とは何か — コード・PR・エージェントが同じ場所に集まる新機能

Origin は、Cursor の新しい「Codebase」タブから使うコードホスティング機能です。リポジトリの作成・管理に加えて、GitHub リポジトリとの同期表示と双方向の更新、プルリクエストの作成・コメント・マージ(GitHub 側とも同期)ができます。

GitHub とCursor がホストするリポジトリが双方向に同期する様子を、2つの棚とベルトコンベアで表したイラスト。

公式チェンジログの説明を借りると、"Your code, PRs, and agents are now in the same place"(コード・PR・エージェントが、いま同じ場所にある)という一文がこの機能の核心です。AI エージェントがリポジトリについての質問に答えたり、変更やブランチの push を直接行ったりする操作が、コードとプルリクエストと地続きの画面で完結するようになります。これまでは「エディタでコードを書く」「ブラウザで GitHub の PR を見る」「別画面でエージェントに指示する」という3つの場所を往復していた作業が、1つのタブに集約される形です。

統合パートナーとして Vercel(プレビュー展開)、Depot、Buildkite(CI/CD)の名前も挙がっており、単なるリポジトリのミラーではなく、デプロイや CI までを見据えた設計であることがうかがえます。

GitHub は今も「唯一の真実」— 併用設計という選択

Origin は GitHub の置き換えではなく、併用として設計されています。公式チェンジログは "Your GitHub repos can sit alongside the ones Cursor hosts"(GitHub のリポジトリは、Cursor がホストするリポジトリと並んで存在できる)と明記しており、push は引き続き GitHub に対して行われ、GitHub が "source of truth"(唯一の正とするデータ源)であり続けるとしています。

つまり、今日から GitHub を捨てて Origin に移行する話ではありません。むしろ「GitHub を正としながら、Cursor 側でコード・PR・エージェントを一体化した操作画面を持つ」という二重構成です。エンタープライズ組織については管理者側でオプトアウトできる設計になっており、全社一律の強制ではないことも公式チェンジログに明記されています。

なぜ「コードの置き場所」まで手を伸ばすのか

Origin の発表は、Anysphere が SpaceX による約600億ドルの買収を完了した(2026年8月14日付け)わずか3日後に来ました。買収の規模そのものはこの記事の主題ではありませんが、大型の資本イベント直後に主力製品の領域を広げる発表を打ってきたという時期の一致は、記録しておく価値があります。

判断材料になるのは時期よりも設計そのものです。エディタ・エージェント・CI 連携パートナー(Vercel / Depot / Buildkite)・そして今回のコードホスティングと並べると、Cursor は「AI エージェントが動く場所」をエディタの外側にまで揃えてきています。GitHub が長年占めてきた「コードの置き場所」という領域に、AI コーディングツールの側から手が伸びてきた、というのがこの発表の位置づけです。

開発チームが今考えておくべき3つの論点

Origin がまだ早期ベータで、GitHub併用の設計である以上、今すぐ何かを変える必要はありません。ただし、この種の機能はいずれ「便利だから標準にする」という現場判断で静かに広がっていきます。広がってから考えるのではなく、今のうちに3つの論点を整理しておく価値があります。

GitHub 依存の中身を棚卸しする。自分たちの開発フローのどこが GitHub に直接依存しているかを言語化できているかどうかです。私たちが運用しているプロダクト群でも、複数のリポジトリで GitHub の main ブランチへの push をそのままデプロイの引き金にしています。コードホスティングの選択肢が増えるなら、まず「今、何が GitHub の存在を前提に組まれているか」を洗い出すところから始まります。

ベンダーロックインの評価軸を持つ。Origin のような統合機能は、便利であるほど「エディタとホスティングが同じベンダー」という状態に自然と寄っていきます。導入するかどうかより先に、「どこまで統合されたら乗り換えコストが無視できなくなるか」という自分たちなりの線引きを持っておくことが、判断を先送りにしない備えになります。

2本の配管が1本に合流する様子を、既存ワークフローとの併存戦略の比喩として表したイラスト。

既存ワークフローとの併存戦略を決めておく。CI/CD・コードレビュー体制・権限管理は、すでに GitHub を前提に組まれているチームが大半です。Origin は Buildkite との連携を持つとはいえ、自分たちの CI/CD パイプラインやレビュー体制をどちらのホスティングに正として合わせるのか、混在をどこまで許容するのかは、機能を試す前に決めておくべき運用ルールです。

まとめ: 導入判断より先に、依存の地図を描く

Origin のような統合機能はこの先も増えていきます。そのたびに必要なのは依存の棚卸しそのものより、洗い出した依存のうち「どれが最も切り離しにくいか」の優先順位をつけておくことです。デプロイトリガーとレビュー承認の仕組みでは、乗り換えコストの重さがまったく違います。すべてを同列に並べただけでは、いざという時の判断材料になりません。

今日からできる一歩は、洗い出した依存の中から1つだけ選んで「もし来月ここが GitHub から切り離せなくなったら、何が一番困るか」を書き出してみることです。この問いに具体的に答えられる依存ほど、あなたのチームにとって乗り換えコストの高い箇所だということになります。