Cursor Originが公開 GitHubが落ちた日に出たコードの置き場

昨日の夜、このブログの記事が本番サイトに出ませんでした。書き終えて、ビルドも通って、pushもできている。なのに公開されない。

原因は、自分たちのミスではありませんでした。GitHubの大規模障害です。

そしてちょうど同じ日、CursorがOriginというコードホスティングのサービスを公開しています。ざっくり言えば、GitHubの代わりになる場所です。

出来すぎたタイミングでした。

エディタの会社が、コードの置き場まで取りに来た

2026年8月17日(米国時間)、CursorがOriginを公開しました。

Cursorは、AIがコードを書くエディタです。使用制限を2倍にした話を7月に書きました。そのCursorが今回出したのは、エディタではなくコードの置き場そのものです。

コードホスティングという言葉が出てきたので、先にかみ砕いておきます。ソフトウェアを作る会社は、コードをGitHubのような場所に預けます。全員が同じ最新版を見られて、誰がいつ何を変えたかが残り、変更を本番に出す前にレビューできる。この置き場のことです。GitHubは事実上の世界標準で、ほとんどの開発現場が使っています。

Originは、そこにCursorが自前で入ってきたということ。公式サイトが掲げているのは A git forge for the agentic era、エージェント時代のコード置き場、といった意味になります。

現時点でできることは、公式ドキュメントにこう書かれています。

• リポジトリの作成と、標準のGitでのクローン・プッシュ・プル
• GitHubリポジトリのミラーリング
• Pull Requestsの作成・確認・マージ
• ブラウザでのコードの閲覧と検索
• Vercel、Depot、Buildkiteとの連携
• ターミナル向けのOrigin CLI

提供条件は押さえておいてください。Originは有料プラン向けで、無料のHobbyプランでは利用できません。しかも早期ベータの段階的な提供です。自分のプランが対象でも、すぐ画面に出ないことがあると公式が明記しています。

企業で使っている場合、管理者はダッシュボードからいつでもチームのOriginを無効にできます。逆に、レガシー版プライバシーモードを使っているチームは、そのままでは有効化できません。

GitHubが7時間半落ちた日に出た

ここが今回いちばん話題になったところです。

GitHubの公式ステータス履歴を見ると、8月17日13時40分(UTC)から21時15分まで、影響度がCriticalと記録された障害があります。約7時間35分。日本時間なら、8月17日の22時40分から18日の6時15分までです。

影響はGitのやり取りだけにとどまりませんでした。API、Issues、Webhooks、Actions、Pull Requests、Pages、そしてCopilotまで、公式が影響を受けたコンポーネントとして並べています。

言葉は正確に使っておきます。公式の記録に並ぶのは、サービスごとの性能低下や可用性低下です。全部が完全に使えなくなった、という書き方はされていません。ただ、Pull RequestsやIssuesを含む広い範囲で20%前後のエラー率が出ていた、とも記録されています。

Originの公開は、その真っ最中でした。公式Xの投稿は日本時間8月18日の午前2時8分。障害が始まってから3時間半後です。

Xの反応も、そこに集中しました。「GitHubが落ちた日に出すとは」「タイミングが完璧すぎる」。300万回以上表示されたこの投稿には、その手の声が並んでいます。

ただ、冷静に見ておきたい点があります。この規模の製品公開は、数週間前から日程が決まっているのが普通です。ブログもドキュメントも段階提供の設定も、当日に用意できるものではありません。狙ったというより、偶然が重なったと見るほうが自然でしょう。

反応も、手放しの称賛だけではありませんでした。「早期ベータで、結局はCursorユーザー向けの機能に留まっている」「GitHubの本当の強さはホスティングそのものではなく、積み上がったエコシステムと開発者の習慣のほうだ」という指摘も、同じくらい目につきます。技術的に良いものを作れても、乗り換えのコストは別の話だ、と。

もっともな話だと思います。

AIが書く量に、既存の置き場が追いついていない

では、なぜいまコードの置き場を作り直すのか。

Cursorの説明には、エージェント規模という言葉が繰り返し出てきます。

これまでのコード置き場は、人が使う前提で設計されていました。ひとりの開発者が1日に数回コミットして、レビューをお願いして、翌日マージする。その規模なら、いまの仕組みで十分に回ります。

AIエージェントが書くようになると、前提が崩れます。何十本ものエージェントが同時にブランチを切り、大量のファイルを一度に変更し、機械の速度でクローンとプッシュを繰り返す。人が1日にやる量を、数分でやってしまう。Xでは、GitHubは1日に1回コミットする人間のために作られたものだ、という言い方も見かけました。

AIに任せて書かせる開発が当たり前になるほど、この量の問題は効いてきます。

この流れは、急に始まったものではありません。Cursorは2025年12月19日に、コードレビュー企業Graphiteの買収合意を発表しています。発表時点では、Graphiteは同じチーム・同じ製品のまま独立して運営を続ける、という説明でした。エディタ、クラウドのエージェント、レビュー、そして今回のホスティング。コードが生まれてから本番に出るまでの全部を、自社で持とうとしているということです。

日本の中小企業の現場から見ると、まだ少し先の話に感じるかもしれません。ただ、開発をAIに任せる比率が上がるほど、他人事ではなくなります。

「うちには関係ない」会社ほど、止まったとき気づく

ここからは実務の話です。

冒頭に書いたとおり、昨日うちが困ったのは、まさにこの障害でした。

記事を書き終えて、ビルドが通ることを確認して、pushまで済ませた。あとは自動でデプロイされるのを待つだけ、のはずでした。ところが本番に出ない。調べてみると、pushしたコミットに対してデプロイ側が何も反応していない。GitHubから通知が飛ばない状態でした。

こちらからできることは、何もありませんでした。復旧を待つしかない。

GitHubが悪い、という話ではありません。この規模のサービスでも落ちるときは落ちる、というだけです。問題は、うちがGitHubに依存していることを、止まって初めて具体的に意識したことのほうです。

社内に開発チームがなくても、次のどれかに当てはまるなら、GitHubはすでに業務の一部になっています。

• 外注先が自社のシステムをGitHubで管理している
• サイトやサービスの更新が、自動デプロイの仕組みに乗っている
• 社内ツールやスクリプトをGitHubに置いている
• AIコーディングツールを使っていて、その連携先がGitHubになっている

止まって困る範囲は、たいてい思っているより広い。うちの場合、止まったのは記事の公開でした。開発でもシステム障害でもない、ただの更新作業です。

乗り換えではなく、まず「読める写し」を持つ

では、Originに移すべきか。

現時点では、そうは思いません。早期ベータですし、実質的にCursorの有料ユーザー向けの機能です。本番の資産をまるごと預ける段階ではないでしょう。

おもしろいのは、Origin自身がそういう設計になっていないことです。

公式チェンジログのGitHub同期の説明には、こう書かれています。同期したリポジトリはリアルタイムで更新され、Originにあるコピーを確認・検索・プルできる。ただしプッシュは引き続きGitHubに送られ、GitHubで始めた作業についてはGitHubが信頼できる情報源のままである、と。

つまりGitHubから同期したリポジトリについては、乗り換えではなく、読める写しを1本持つという設計です。

ここから先は、はっきり書いておきます。これは障害対策のバックアップではありません。

GitHubから同期したリポジトリは、Origin側から閲覧・検索・プルできます。ただしプッシュ先は引き続きGitHubです。GitHubが止まったときにOriginへ切り替えて、開発とデプロイを続けられる仕組みではない、ということです。

昨日のうちの状況に当てはめると、はっきりします。困ったのは、pushそのものではありませんでした。pushは通っていて、そこから先の通知が届かなかった。この形の障害では、Originにミラーがあっても何も解決しません。コードは読めても、出口が塞がっているからです。

写しは、写しとしては有効です。中身を確認できる、手元に引ける、状況を把握できる。何も見えないよりは、はるかにましです。ただ、写しと代替経路は別物。ここを混同すると、備えたつもりで備えていないことになります。

止まったときの逃げ道まで用意するなら、書き込みができる別のリポジトリと、そこから先のデプロイ経路の両方が要ります。Origin自体は新規リポジトリを直接ホストでき、標準のGitでクローン・プッシュ・プルができ、Vercel・Depot・Buildkiteも接続できます。GitHubから独立した経路を作ること自体は、仕組みのうえでは可能です。早期ベータのいま、そこまで踏み込むかは別の判断ですが。

同じ考え方は、Origin以外にも当てはまります。使っているツールについて、止まったら何ができなくなるかを1回書き出しておく。それだけでも、次に落ちたときの動き方が変わります。

預け先が3日前に変わったことも、一緒に見る

最後に、見落としやすい点を1つ。

Originが公開される3日前、CursorはSpaceXに買収され、その一員になっています。2026年8月14日の発表です。4月に公表されたSpaceXAIとのパートナーシップから続いていた買収プロセスが完了した、という位置づけになっています。

Cursor側の説明は、世界最大のGPUフリートを使えるようになり、より高性能なモデルをより低コストで提供できる、というもの。7月にGrokとの共同訓練の話を書いたときから、この方向は見えていました。

良い悪いの話をしたいのではありません。コードを預ける先を選ぶときは、機能だけでなく、その会社が誰のものかも一緒に見るということです。自社のソースコードは、事業そのものと言っていい資産ですから。

判断材料として、いま公式に確認できるのはこのあたりです。

項目	現状
提供段階	早期ベータ。段階的な提供
対象プラン	有料プラン。無料のHobbyプランは対象外
プライバシー	名前空間の所有者のプライバシーモードに従う
管理者の制御	ダッシュボードからいつでも無効にできる
資本	2026年8月14日にSpaceXの一員に

急いで結論を出す必要はないと思います。ベータのあいだにどこまで機能が埋まるか、エージェント向けの機能がどう出てくるか。見てから決めても遅くありません。

まとめ 落ちてから考えるか、落ちる前に書き出すか

要点を並べます。

• Cursorが2026年8月17日、コードホスティングのOriginを公開。早期ベータで段階提供
• 対象は有料プラン。無料のHobbyプランは対象外
• 同じ日、GitHubが約7時間35分の障害。影響度はCriticalで、Actions・PR・Pages・Copilotなど広範囲に影響
• Xでは「タイミングが完璧」という声が集まったが、公開準備は数週間前から進むのが普通。偶然と見るのが自然
• GitHubから同期したリポジトリは、プッシュ先はGitHubのまま、Originは読める写し。障害時の代替経路にはならない
• Cursorは3日前の8月14日にSpaceXの一員になっている

すぐ動くなら、Originを触るより先にやることがあります。自社が止まったら困る外部サービスを、紙1枚に書き出してみてください。GitHub、決済、メール、チャット、クラウド。それぞれについて、止まったら何ができなくなるのか。

うちは昨日、記事1本が出せませんでした。それだけです。ただ、書き出してあれば、待つしかないと判断するまでの時間はもっと短くて済んだはずです。