システムの保守を引き継ぐとき、最初に確認するのは「ソースコードがどこにあるか」です。この質問に「GitHub です」と答えが返ってきて、それで話が通じる時代が長く続きました。 事実上の一択だったからです。
その前提が崩れると、同じ質問への答えは「GitHub です」だけでは足りなくなります。どのアカウントの下か、他にどこへ複製されているか、そこは誰の契約か。
2026年8月、その状況が現実になりました。
選択肢が増えた、という事実のほう
Cursor が Origin というコードホスティングを、有料プラン（Pro / Teams / Enterprise）の利用者向けに早期ベータとして公開しました。管理者が明示的に無効化していない限り、対象プランでは使える状態になっています。
機能としては、開発者が GitHub で行っていることをひととおり置き換えるものです。リポジトリの保管、コードの閲覧と編集、プルリクエスト、コードレビュー。Vercel・Depot・Buildkite との連携も初日から用意されています。
設計思想として説明されているのは、「人間が1人で意図を持って出すプルリクエスト」を前提にした従来のホスティングでは、自律エージェントが出すプルリクエストを扱いきれないという点です。Cursor 自身のプルリクエストのうち約3分の1が自律エージェント発である、という数字が背景として挙げられています。
ただし、発注する側にとって重要なのは製品の思想ではありません。「委託先が使うコードホスティングは、こちらが指定しない限り委託先が選ぶ」という当たり前の事実が、初めて選択肢のある状態で表面化したことです。
同期は移行ではなく、複製
Origin は GitHub を置き換えるのではなく、相互運用する形をとっています。既存の GitHub リポジトリを同期して取り込める。この「同期」という言葉が、確認を後回しにさせます。
移行なら、置き場所が変わったことは誰の目にも明らかです。同期は元も残ります。開発の体感は何も変わらず、リポジトリの URL も生きている。しかし実態としては、同じコードが2か所に存在する状態です。
複製先が増えると、次のものがそれぞれ増えます。
- アクセス権の管理点。 退職者や契約終了したメンバーの権限を止める先が2つになります。片方だけ止めると、止めたつもりの状態が残ります
- 監査ログの所在。 誰がいつ何を持ち出したかを追う先が分散します。片方にしか記録がない操作が発生します
- 適用される規約。 データの取り扱い、保持期間、削除の手続きは、サービスごとに別です
いずれも新しい論点ではありません。ただ、GitHub 一択の間は「コードの置き場所」を1つと数えてよかったため、確認する習慣がありませんでした。
委託先のアカウントに残り続ける権限の話は本番環境の権限を必要なときだけ渡す設計で扱っています。今回の話は、その権限が及ぶ範囲そのものが増える、という一段手前の問題です。
6時間42分止まった日に分かること
Origin が公開された同じ日、GitHub が世界規模で6時間42分にわたって障害を起こしました。エラー率は全体で約20%、ファイルのダウンロードでは50%近くに達したと報じられています。
タイミングの偶然としてニュースになりましたが、発注側が読み取るべきなのは競争の構図ではなく、自社の開発と保守が何時間止まったかです。
その日、緊急の修正をデプロイする必要があった会社は、実際に止まりました。CI がリポジトリを取得できなければビルドは走りません。そして多くの場合、この「止まった」は事後に集計されていません。 委託先が困っていただけで、発注側には報告されないためです。
ホスティングを分散させれば解決する、という話ではありません。複製先を増やせば前節の管理点が増えます。判断すべきは「分散するか否か」ではなく、「止まったときに何が待てて、何が待てないか」を先に決めておくことです。 待てないものがあるなら、そこだけ代替経路を用意します。
契約と運用に書いておく3行
大がかりな仕組みは要りません。委託先とのやり取りに次の3点があるかを確認します。
リポジトリの所在と所有者。 「GitHub の どの Organization か」まで書きます。委託先の Organization 配下にある場合、契約終了時の移管手続きも同時に決めておきます。開発中に決めておかないと、関係が終わってから交渉することになります。
複製先を増やすときの通知。 新しいホスティングやミラーを追加する際に、事前に知らせてもらう一行です。禁止する必要はありません。把握していれば、権限停止のチェックリストに足せます。
ホスティング障害時の扱い。 何時間止まったら連絡が来るのか、緊急修正の代替手段があるのか。多くの場合「特に決めていない」が答えになりますが、決めていないと分かること自体に価値があります。
これらは契約書の改定ではなく、キックオフの議事録に3行残しておけば足ります。委託先のビルド環境で使われている資格情報の扱いについては長期トークンで動く委託先のビルド環境にまとめました。あわせて確認しておくと、開発環境まわりの棚卸しが一度で済みます。
次にやること
現在進行中の開発案件を1つ選び、ソースコードが置かれている場所と、その Organization の所有者を確認してください。 委託先の所有であれば、契約終了時にどう移管するかを今のうちに1行決めておきます。
すでに稼働中のシステムについては、リポジトリへのアクセス権を持つアカウントの一覧を出してもらうところから始めるのが現実的です。 退職者や契約終了したメンバーが残っているかどうかは、その一覧を見れば分かります。
開発体制の引き継ぎ、既存システムのソース管理まわりの棚卸し、保守の受け入れ準備については、グリームハブの開発・AI・自動化のご相談で承っています。体制と稼働状況によって進め方が変わるため、個別にご相談ください。お問い合わせからどうぞ。
Sources
- Cursor capitalizes on GitHub frustration, launches rival hosting platform — TechCrunch
- Cursor launches Origin code hosting platform as GitHub outage exposes opening in AI coding race — VentureBeat
- Cursor Launches ‘Origin’ Code Hosting Platform As GitHub Alternative — Slashdot
- AIエージェント時代のGitホスティングサービス「Origin」、Cursorが発表 — Publickey
- Origin code hosting — Cursor Changelog
- Incident with Github.com — GitHub Status
