AI Today
ホーム > 考察記事 > 🐙 GitHubが落ちるたびにヒヤッとしてない?|SpaceX傘下Cursorが放った新参ホスティング「Origin」の話

🐙 GitHubが落ちるたびにヒヤッとしてない?|SpaceX傘下Cursorが放った新参ホスティング「Origin」の話

アイ

アイ

目次


GitHubが落ちるたびにヒヤッとするの、わたしだけじゃないよね?

いきなりだけど、「GitHubが落ちてPRがマージできない」ってなった経験、ない?わたしは正直、何回もある。

2026年8月18日、SpaceX傘下のAIコーディング企業Cursorが、新しいコードホスティングプラットフォーム「Origin」を発表したの。

リポジトリの保存、コードの閲覧・編集、プルリクエストの管理までできる、いわば「GitHubの代わりになれる場所」って感じの製品なんだよね。

しかもGitHubとの相互運用性もちゃんと用意されてて、GitHubのリポジトリをCursorに接続して、同期する対象を選びながら両方を並行して使えるようになってるの。

正直、最初にこのニュースを見たとき「え、Cursorってエディタの会社じゃなかったっけ」ってちょっと驚いたんだよね。

でも背景を知ると、なんとも言えない偶然が重なったタイミングでの発表だったんだなって思ったの。

というのも、Origin発表と同じ日に、GitHubで世界規模の障害が発生して、エラー率がほぼ20%まで達したんだって。

わたしたちが毎日当たり前みたいに使ってるGitHubが、実は結構ギリギリのところで動いてるのかもって考えると、他人事じゃない気がしてきたんだよね。

しかもCursorは発表時点ですでにSpaceXの傘下で、2026年8月15日に買収が完了したばかり。発表からわずか3日後っていうタイミングも含めて、今回のOriginはかなり本気度の高い一手なんじゃないかって、わたしは見てるの。

考えてみたら、GitHubってPull Requestの管理だけじゃなくて、CI/CDのトリガーだったりIssue管理だったり、開発チームの作業のかなりの部分が乗っかってるサービスだよね。

そこが止まるってことは、単に「コードが見れない」だけじゃなくて、チーム全体の作業が一斉にストップするってことなんだよね。

わたしも過去にGitHubの調子が悪くて、レビュー待ちのPRがどんどん積み上がっていくのを見ながら、ただ復旧を待つしかなかった経験があるから、この手のニュースはついつい自分ごととして読んじゃうの。

今日はこのOrigin発表のニュースを、4つの理由に分けて深掘りしていくね🐙。


そう考える4つの理由

理由1:この1年で257回、っていう数字がもう笑えない

世間では「GitHubってたまに落ちるよね〜」くらいの、割と軽いノリで受け止められてる印象があるんだよね。

わたしも正直、少し前までは「まあ大きいシステムだし、たまには落ちるでしょ」くらいにしか思ってなかったの。

でも今回改めて数字を見て、これはさすがに看過できないレベルだなって思っちゃった。

なぜなら、この1年でGitHubは257回も障害を起こしてるから。

単純計算すると、だいたい1.4日に1回のペースでなにかしらの障害が起きてる計算になるんだよね。

毎日コードをpushしたりPRをレビューしたりしてる身からすると、これって「今日は大丈夫かな」ってちょっと身構えながら仕事するレベルの頻度だと思う。

しかもわたしたちが目にするのは「障害が起きました」っていう報告そのものだけで、その裏でチームの作業がどれだけ止まったのか、締切がどれだけ後ろ倒しになったのかまでは、なかなか表に出てこないよね。

257回っていう数字の後ろには、きっとその何倍もの「地味に困った」っていう瞬間が積み重なってるはずなんだよね。

だからこそ、こういう頻度のデータを見たら、自分のチームが依存してるインフラがどれくらい安定してるのか、一度ちゃんと数字で確認しておいた方がいいなって、わたしは思うんだよね。

普段「なんかGitHub重いな」で流しちゃってる違和感も、実は積み重なると結構なリスクになってるのかもしれないよ。

さらに月換算すると、257回ってだいたい月21回くらいのペースになるんだよね。これって、平日ほぼ毎日どこかで何かしらの不具合が起きてる計算に近いと思う。

もちろん障害の規模はいろいろで、全部が全部業務に響くレベルじゃないと思うんだけど、それでも「今日は大丈夫か」って気にする回数がこれだけ多いっていうのは、地味にストレスだよね。

わたしだったら、こういう数字を見た時点で、一度チームのSlackとかで「最近GitHubの調子どう?」って聞いてみると思う。案外みんな似たようなモヤモヤを抱えてたりするんだよね。

しかも257回っていう数字は、あくまで表に出てきた障害の件数だよね。実際には報告されない小さな遅延とか、ちょっとした同期のズレみたいなものも含めたら、体感の不安定さはもっと大きいんじゃないかなって、わたしは思ってるの。

こうやって数字にしてもらえると、感覚だけで「まあこんなもんか」って流してたことが、実は結構深刻な話だったんだって気づけるよね。今回のニュースの一番の価値は、そこにあると思う。

理由2:発表と同じ日に世界規模の障害って、タイミングが良すぎる

世間では「Origin発表の日にたまたまGitHubが落ちただけでしょ、偶然だよ」っていう見方もあると思う。

でもわたしは、これはもう偶然として片付けるにはできすぎてるタイミングだなって感じちゃったの。

なぜなら、Origin発表と同じ日に世界規模の障害が発生して、エラー率がほぼ20%に達したっていう事実があるから。

考えてみて、5回に1回のリクエストがエラーになるって、体感でいうとかなりの頻度で「あれ、動かない」ってなるレベルだよね。

しかもこれが単発の小さい不具合じゃなくて「世界規模」って言われるくらいの障害だったっていうのが、余計に説得力を持たせちゃってると思うの。

Cursorとしては狙ったわけじゃないかもしれないけど、結果的に「ほら、こういうことが起きるでしょ」っていう最高のデモになっちゃったんだよね。広告代理店がどれだけ頑張って企画しても、こんなタイミングは狙って作れないと思う。

だから、もしあなたのチームがGitHubに全部乗っかってるなら、こういう障害の日にどれくらい業務が止まるのか、一度シミュレーションしておいて損はないと思うよ。

正直わたしも、今回のニュースを見て初めて「うちのチーム、GitHubが半日止まったらどうなるんだろう」って考えるきっかけになったんだよね。

エラー率20%っていう数字、改めて考えると結構ヤバいよね。5回に1回失敗するツールを毎日仕事で使うって、普通に考えたらけっこうしんどいと思う。

しかもこれが特定の地域だけの話じゃなくて「世界規模」の障害だったってことは、時差関係なく世界中の開発者が同時にこの不便さを味わったってことだよね。

Origin発表のタイミングでこれが起きたっていうのは、Cursorにとっては何もしなくても最高の説得材料になっちゃった格好だと思うの。皮肉というか、GitHub側からすると相当タイミングが悪かったとしか言いようがないよね。

理由3:GitHubを切り捨てなくていい「相互運用性」が乗り換えの心理的ハードルを下げてる

世間では「新しいホスティングサービスに乗り換えるなんて、リポジトリ移行が面倒すぎて現実的じゃない」って思ってる人、多いんじゃないかな。

わたしも最初はそう思ってた。長年GitHubに積み上げたリポジトリとか設定とか、全部引っ越すのって想像するだけでちょっと気が重いよね。

でも今回のOriginの設計を見て、その心配は結構的外れかもって思い直したの。

なぜなら、OriginはGitHubのリポジトリをCursorに接続して、同期する対象を選びながら両方を並行して使えるようになってるから。

つまり「GitHubを今すぐ全部やめてOriginに引っ越す」んじゃなくて、「気になる一部のリポジトリだけ試しにOriginでも触ってみる」っていう使い方ができるんだよね。

これって心理的なハードルがめちゃくちゃ下がる設計だと思うの。全部か無かの二択じゃなくて、少しずつ試せるから。

わたしだったら、まずは個人的に触ってる小さいリポジトリとか、影響範囲が限定的なものから試してみるかな。いきなり本番のメインリポジトリを移すのはさすがに怖いもんね。

だから、GitHubの障害に不安を感じてる人は、いきなり全面移行を考えるんじゃなくて、まずは並行運用できる部分から試してみるっていう選択肢を持っておくといいと思うよ。

こういう「全部乗り換えなくていい」設計って、地味だけどユーザー目線ではすごく大事なポイントだと思うの。移行のハードルが高いサービスほど、どれだけ不満があっても「まあ今のままでいいか」ってなりがちだもんね。

チームでインフラを決める立場の人からすると、いきなり大きな意思決定を迫られるより、小さく試して判断材料を集められる方が、社内での説明もしやすいはずだよね。

だからこそ今回のOriginは、GitHubに強い不満を持ってる少数の人だけじゃなくて、「なんとなく気になってる」くらいの温度感の人にも刺さる設計になってるんじゃないかなって、わたしは思ってるよ。

理由4:Originはホスティングだけで終わらない、次は「エージェントネイティブ」を狙ってる

世間では「結局リポジトリの保存場所が増えるだけでしょ、GitHubの劣化コピーなんじゃないの」っていう見方もあると思う。

でもわたしは、Originを単なる「もう1つのGitHub」として見るのは、たぶん早計だと思ってるんだよね。

なぜなら、Cursor側は今後「エージェントネイティブ」な機能や、コーディング作業向けのアプリエコシステムの追加も予定してるって発表してるから。

これはリポジトリを保存するだけの場所じゃなくて、AIエージェントが最初からリポジトリの中身を理解して動き回れるように設計された基盤を作りたいってことだと思うの。

考えてみたら、Cursorって元々AIコーディングエディタとしてAIエージェントの機能に強い会社だったよね。そのCursorが自前のホスティング基盤まで持つっていうのは、単なる保存場所の話じゃなくて、AIエージェントとインフラの距離を縮める動きなんじゃないかなって、わたしは見てるよ。

しかもCursorは発表時点ですでにSpaceX傘下で、2026年8月15日に買収が完了したばかりなんだよね。SpaceXレベルの資本を背景にインフラ勝負を仕掛けてきてるって考えると、単発のキャンペーンじゃなくて長期戦のつもりで作ってきてるんだと思う。

今の時点ではリポジトリ保存とPR管理っていう「まずGitHubに追いつく」機能が中心だけど、そこにエージェントネイティブな機能とアプリエコシステムが乗ってくると、開発の作業場所そのものが変わっていく可能性もあるよね。この先の追加機能、わたしは結構ワクワクしながら見てるの。

「エージェントネイティブ」って言葉、まだピンと来ない人もいるかもしれないけど、要はAIエージェントが人間と同じようにリポジトリを読んで、コードを書いて、PRを出すところまでを前提にした作りってことだと思うの。

わたしたちがふだんAIコーディングツールにお願いしてる作業も、これからどんどん複雑になっていくはずだよね。そのときに土台となるインフラがAIエージェントを想定して作られてるかどうかって、意外と大きな差になってくると思うの。

今のGitHubも自動化の仕組みはいろいろあるけど、あくまで「人間が使う場所にAIが後から入ってきた」感じだよね。Originがもし本当にエージェント前提で設計されるなら、そこの土台からして違ってくるはずなの。

アプリエコシステムの追加っていう話も、単体のホスティングサービスで終わらせずに、コーディング作業まわりの色んなツールを取り込んでいこうっていう野心を感じるんだよね。Cursorがもともとエディタとして培ってきたAI機能の強みと、このOriginのインフラがどう組み合わさっていくのか、正直続報が楽しみだよ。


まとめ:GitHubの「当たり前」が崩れた今、選択肢を持っておいた方がいい

今回のニュースをまとめると、SpaceX傘下のAIコーディング企業Cursorが2026年8月18日、コードホスティングプラットフォーム「Origin」を発表したという話だったよ。

ポイントは4つ。

1つ目、GitHubはこの1年で257回もの障害を起こしてるということ。

2つ目、Origin発表と同じ日に世界規模の障害が発生してエラー率がほぼ20%に達したということ。

3つ目、GitHubとの相互運用性のおかげで、全面移行じゃなく並行運用から試せる設計になってるということ。

4つ目、Originはホスティングで終わらず、エージェントネイティブな機能やアプリエコシステムまで見据えてるということ。

正直、わたしはこのニュースを見て、「GitHubが絶対に落ちない前提」で仕事のスケジュールを組むのは、そろそろ見直した方がいいのかもって思ったんだよね。

著名なユーザーの間でもGitHubからの離脱が目立ち始めてるっていうのも、単なる噂話じゃなくて、実際に不便を感じてる人が増えてる証拠だと思うの。

影響力のある開発者が声を上げると、そこに続く人も出てくるよね。今はまだ一部の動きかもしれないけど、こういう離脱の流れって一度加速し始めると意外と早いんじゃないかなって、わたしは思ってる。

だからといって今すぐ全部Originに移行しろって話じゃなくて、まずは相互運用性を使って一部のリポジトリだけ試してみるとか、そういう小さい一歩から始めるのがちょうどいいと思う。

わたし自身も、普段からGitHub一本で作業してるから、こういう選択肢が増えるのは正直ありがたいなって感じてる🐙。

これまでコードホスティングって「GitHub一強で他に選択肢がない」みたいな空気があったと思うんだけど、SpaceXっていう資本力のある企業が本気で対抗馬を出してきたことで、その前提が少しずつ揺らぎ始めてる気がするんだよね。

競争相手が出てくること自体は、使う側のわたしたちにとって基本的にプラスだと思うの。GitHub側も今回の障害を機に、これまで以上に安定性の改善に力を入れてくれるかもしれないしね。

大事なのは、どっちが勝つかを今すぐ予想することじゃなくて、選択肢が増えたこの状況をちゃんと自分の目で確認して、必要なら試してみる姿勢を持っておくことだと思うんだよね。

今回みたいに、普段当たり前に使ってるインフラの裏側で大きな地殻変動が起きてるニュースって、忙しいと見逃しがちだと思うの。でもコードホスティングは開発の土台そのものだから、ここでの変化はじわじわと働き方にも影響してくるはずだよね。

わたしもこれから、CursorのOriginがどんな風に育っていくのか、GitHub側がどう反応してくるのか、続報をちゃんと追いかけていこうと思ってる。動きがあったらまた記事にまとめるね。

AIコーディングツール全体の勢力図が気になる人は、Cursor、Claude Code、Copilotを3つとも使い比べてわかったことも読んでみてね。CursorがOriginみたいなインフラ勝負まで仕掛けてきてる背景が、より立体的に見えてくると思う。

インフラの安定性は、便利さと同じくらい大事な判断基準になってきてるなって、今回のニュースで改めて感じたよ。GitHubに依存しきってる自覚がある人ほど、一度この動きをチェックしてみてね。

関連記事: Cursor、Claude Code、Copilotを3つとも使い比べてわかったこと

ソース: