HashiCorp創業者のミッチェル・ハシモト氏「GitHubはもはや真剣に仕事に取り組める場所ではなくなった」 “決別”宣言に大きな反響：「バイブコーディング」時代に露呈したGitHubの可用性リスク GitHubは謝罪・釈明

HashiCorpの創業者として知られるミッチェル・ハシモト氏が、連日発生している不具合を理由に主要プロジェクトを「GitHub」から完全に移行させると発表した。この発表が開発者コミュニティーの間で大きな反響を呼んでいる。

[石川俊明，＠IT]

　「Vagrant」や「Terraform」の生みの親であり、HashiCorpの創業者として知られる個人開発者のミッチェル・ハシモト氏は2026年4月、自身のブログで「GitHubはもはや真剣に仕事に取り組める場所ではない」との認識を示した上で、数カ月間に及ぶ検討の末、自身の最新プロジェクト「Ghostty」をGitHubから完全に撤退させる“決別”宣言をした。この宣言が開発者コミュニティーの間で大きな話題となっている。

　ハシモト氏は、GitHubが一般公開された2008年から18年にわたりGitHubを利用してきた初期ユーザーであり、GitHubの熱狂的なファンの一人でもある。そんな同氏が「ブログ記事を書きながら、キーボードに涙がこぼれた」と海外掲示板「Hacker News」で明かすほどの宣言に至った背景には、毎日のように頻発する「GitHub Actions」やPull Request機能を巡るインシデントがある。

　同氏のブログ記事によると、ここ1カ月間、GitHubの障害によって仕事に悪影響が出る事態が日常茶飯事のように起きていたという。自身の作業がブロックされた日に日記へ「X」印を付けるようにしたところ、ほぼ毎日「X」が付く結果になった。記事の執筆時にもGitHub Actionsの障害で約2時間Pull Requestのレビューができない状態に陥っていたという。

　「私はソフトウェアをリリースしたいのに、GitHubがそれをさせてくれない。もはやここは真剣に仕事をする場所ではなくなってしまった」

　ハシモト氏の不満は、GitHub公式のステータスページにも事実として表れている。2026年4月後半の記録を確認しただけでも、「Disruption with some GitHub services（一部サービスの障害）」「Incomplete pull request results in repositories（リポジトリのPR結果不完全）」「GitHub search is degraded（GitHub検索のパフォーマンス低下）」といった大小さまざまなインシデントが連日記録されており、GitHub側がその都度、修正に追われている姿が見て取れる。

GitHubのステータスページのスクリーンショット　2026年4月には27件のインシデントが発生した

　GitHubは公式ブログで、2026年4月後半に発生した一連のインシデントについて、「エージェント型開発ワークフローの急激な加速」が一因になっているとの認識を示した上で、ユーザーに対して謝罪した。

Pull Request数は9000万に急成長　「バイブコーディング」時代に露呈したGitHubの可用性リスク

　2026年に入り、AIエージェントが自律的にコードを書き、Pull Requestを作成し、テストを回すという開発スタイルが加速した。GitHubが公開したデータによると、直近のトラフィックは文字通り右肩上がりで上昇している。

マージされたPull Request数は9000万件、コミット数は14億件、月間新規リポジトリ作成数は2000万件と急激に成長（提供：GitHub）

　GitHubは2025年10月の時点で「10倍」のインフラキャパシティー増強に向けて取り組んでいたものの、2026年2月の段階で「現在の30倍が必要」と、抜本的な計画の見直しを迫られていたという。「可用性第一」でインフラの再構築を急いでいるものの、開発者によるAIエージェントの活用がもたらす未曾有の負荷にインフラの増強が追い付いていないGitHub側の“悲鳴”が垣間見える。

「GitHub一極集中」リスクの顕在化

　GitHubが急激な負荷の増大に伴うインシデント対応に追われる一方、プラットフォーム側の不安定な状況が常態化すれば、GitHubを利用する開発組織や企業側も「GitHub一極集中」のリスクを再考せざるを得なくなる可能性がある。プラットフォーム側で発生するインシデントを理由に、自社のビジネスに直結するリリース頻度を低下させるわけにはいかないためだ。

　事実、ハシモト氏の発表や直近のGitHubのトラフィック爆発に先んじて、デリバリー基盤の「主導権」を取り戻そうとした動きがある。その事例の一つといえるのが、イギリスの新聞大手「The Guardian」のエンジニアリングチームが2025年12月に詳細を公開した移行プロジェクトだ。

　同社のエンジニアリングチームは長年、GitHub Actionsのホステッドランナーを利用してきたが、iOSアプリ開発における「macOSランナー」のコストの高さや、「予測不可能な上流の環境変更」によるビルド遅延に悩まされてきた。特にGitHub側のイメージ更新による予期せぬパフォーマンス低下も、リリースの大きな阻害要因となっていた。

　そこで同チームは、オフィスで未使用だった「Mac mini」を活用したセルフホステッドランナーへの移行を断行。クリーンアップ処理の自動化や物理ハードウェアの維持といった運用負荷は増大したものの、全ワークフローの平均実行速度を120％以上向上させ、コスト削減と安定稼働を両立したという。

　とはいえ、ハシモト氏の声明やThe Guardianの移行事例をもってしても「今すぐ全ての企業がGitHubへの一極集中を見直すべきか」と問われれば、現実的には大半の開発組織にとってその答えは「否」となるかもしれない。

　開発者がこれまでGitHubを活用してきた理由は、単なるコードベースの置き場だからではない。洗練されたUI（ユーザーインタフェース）でのPull RequestやIssueの管理、GitHub ActionsによるCI/CD（継続的インテグレーション／継続的デリバリー）の統合、サードパーティー製ツールとのシームレスな連携といったメリットを享受できるためだ。プラットフォーム側の不安定さを理由にこれら全てを手放し、一から代替環境を構築・維持することは、多くの組織にとってROI（投資対効果）や学習コストの面で見合わないと捉えられる可能性がある。

　そして、GitHubで現在起きているインシデントの波は、AIエージェントの爆発的普及という過渡期に伴う「一時的な成長痛」という可能性もある。実際のところ、日々のインシデントに対して「休憩の時間ができた」「いずれ直るだろう」と、そこまで深刻に捉えていない開発者や開発現場も少なくないかもしれない。

　そして、それは決して間違った姿勢でもないだろう。自社のリリース頻度やビジネス要件と照らし合わせたとき、GitHubの不安定さが「許容範囲内」に収まっているのなら、利便性を享受し続けることも、合理的判断といえるためだ。

　重要なのは、GitHubで起きている可用性の問題を自社の開発基盤のリスクとしてどこまで捉えるかということだ。可用性の問題を許容し、このままGitHubを利用し続けるか。それとも「自社のリリース頻度に対して、GitHubの可用性がボトルネックになり始めている」と捉え、開発基盤の一部を見直すか――ハシモト氏の“決別”宣言は、GitHubを利用する企業や開発組織が開発基盤の「集中」と「分離」のバランスを再点検する契機となりそうだ。