2026年4月28日、ミッチェル・ハシモトは、自身のオープンソースのターミナルエミュレーターであるGhosttyがGitHubから離れることを発表しました。彼はGitHubユーザー1299番で、2008年2月に参加しました。彼は18年以上にわたり、ほぼ毎日プラットフォームを使用してきました。彼がその投稿を書いた日には、それらのことは何の意味もありませんでした。彼はすでに「ほぼ毎日X（障害）がある」という日誌を付けており、発表当日に発生したGitHub Actionsの障害により、彼のPRレビューが2時間ブロックされました。彼の評決は直接的でした。「毎日、数時間にわたって作業をブロックされるようでは、ここは真剣な仕事をする場所ではなくなりました。」
もしあなたが開発者ツールを開発しているなら、この発表は二度読むべきものです。ハシモトはカジュアルなGitHubユーザーではありません。彼はGitHub上でHashiCorpを共同設立し、Terraform、Vagrant、Vault、Consul、Boundaryをそれを通じてリリースしてきました。そして彼はGitHubユーザー1299番です。地球上で最も支配的な開発者プラットフォームから、そのようなプロフィールのユーザーが離れるとき、その話は、あるターミナルエミュレーターが新しい本拠地を選ぶという以上の意味を持ちます。それは信頼性、ロックイン、そして他の開発者が毎日依存するツールを構築するためにかかる費用についてのシグナルです。この記事では、ハシモトが何を言ったのか、それが開発者ツールをリリースするすべての人にとって何を意味するのか、そしてあなた自身のスタックを同じ罠から守るパターンを解き明かします。
AI時代の開発者ツールがGitHubネイティブのワークフローをどのように変えているかについてのより広い文脈については、AGENTS.mdファイルの書き方およびチーム向けGitHub Copilotの使用状況と課金APIを参照してください。GitHubの信頼性ギャップを自動化するあるチームの取り組みについては、Clawsweeperトリアージボットの解説を参照してください。
要点
- ミッチェル・ハシモトは2026年4月28日、GhosttyがGitHubを離れ、まだ名前が公表されていないフォージに移転すると発表しました。
- その理由は、彼が個人的な日誌で「ほぼ毎日X（障害）がある」と記録していた、GitHub Actionsとプラットフォームの慢性的な障害です。発表当日には、PRレビューを2時間ブロックするActionsの障害が発生しました。
- 彼はGitHub上に読み取り専用のGhosttyミラーを維持し、段階的にアクティブな開発を移行しています。彼の他のプロジェクトは今のところGitHubに残ります。
- この話が重要であるのは、Ghosttyがどこに落ち着くかよりも、GitHubユーザー1299番であるハシモトが、機能面ではなく信頼性の理由で離脱したからです。
- 開発者ツールを構築する人々にとっての教訓は、あなたのツールが誰かの重要なパス上に置かれると、信頼性が機能に勝るということです。ステータスページのお芝居や「調査中です」というツイートでは、信頼を取り戻すことはできません。
- 特にAPIチームにとっての戦略は、デカップリングです。プロバイダーに依存しないクライアント、障害時のモックされた依存関係、そして必要になる前に実行しておく移行パスです。Apidogはこのパターンに基づいて構築されています。
ハシモトが投稿で述べたこと
この発表投稿は短く、それがメッセージの一部でもあります。マニフェストも、Microsoftへの皮肉も、代替フォージの宣伝もありません。ハシモトは淡々とタイムラインを語っています。彼はGitHubの障害日誌をつけ始め、日誌は予想以上に早く埋まり、投稿を書いた朝にはGitHub Actionsの障害により2時間PRレビューができませんでした。彼は、このプラットフォームがGhosttyで行うような仕事にはもはや十分に信頼できないと結論付けました。
発表に関する数字は押さえておく価値があります。ハシモトの投稿の前日である2026年4月27日には、Actions、パッケージ、API表面に影響を与える大規模なGitHub障害が発生しました。彼が投稿で言及している日誌は、その障害以前から存在しており、彼は数ヶ月間そのパターンを追跡していました。彼はこの動きを、単一の悪い日への反応ではなく、静かに計画されてきたものとして位置付けています。4月27日の障害はタイミングを早めただけで、決定そのものではありませんでした。
彼はまた、境界についても明言しています。Ghosttyは離れますが、彼の他のプロジェクトは今のところGitHubに残ります。Ghosttyリポジトリは現在のURLで読み取り専用ミラーとして残ります。新しいフォージが、イシュー、プルリクエスト、CIを含むアクティブな開発をホストします。彼は複数のプロバイダー（商用とFOSSの両方）と話し合っており、まだ最終的な移行先は決まっていません。移行は段階的に行われ、一斉移行ではありません。
言葉と同じくらい、省略された情報も雄弁です。ハシモトは機能、価格設定、製品の方向性には言及していません。彼の不満は、彼が依存していたサービスが数時間にわたって応答しなくなることであり、ソフトウェアを出荷するプロジェクトは、動かない基盤の上では実行できないということです。
移行よりも信頼性の側面が重要な理由
この発表に関するほとんどの報道は、間違った質問をしています。興味深い質問は、Ghosttyがどこに落ち着くかではありません。興味深い質問は、GitHubほどの技術的深さを持つプラットフォームが、その二番目に著名な古参ユーザーが信頼性の理由で離脱する事態にまで至った経緯です。二番目に興味深い質問は、それが私たち他の開発者が構築しているツールについて何を物語っているかです。
この発表が通常の「Xを辞めます」という投稿と異なる点が3つあります。
ユーザー。ハシモトは新しい開発者ではありません。彼はFortune 500企業で利用されるインフラツールを構築してきました。彼がGitHubは信頼できないと言うとき、そのメッセージを受け取る聴衆には、自社のソースコードをどこに置くかを決定する人々も含まれます。4月29日の朝までに、CTOのメーリングリストはすでにこの投稿でいっぱいでした。
理由。彼はCopilot、Microsoft、AIトレーニング、ICE契約、価格設定、あるいは通常の離脱理由のいずれでもありませんでした。彼はサービスが繰り返し機能停止したために離脱しました。これにより、誰もが重要だと認める唯一の軸に話が収束します。つまり、「必要なときにツールは機能するか？」ということです。
トーン。怒りは一切ありません。投稿は、一生懸命残ろうとした人物が書いた事後分析のように読めます。ドラマの欠如が、どんなに声高な投稿よりも強く響く理由です。人々は彼を信じています。
開発者ツールを運営している人にとって、この組み合わせは最悪のシナリオの音です。長年のベテランユーザーであり、政治的な意図もなく、公の場での論争もなく、「今日は機能しなかった」という記録が静かに積み重なり、最終的に計算が合わなくなったのです。日誌に対するPR対応はありません。
開発者ツールを構築する場合、これが何を意味するか
あなたの製品が開発者の重要なパス上に位置する場合、ハシモトの発表はストレステストのプロンプトです。あなた自身のサービスに対して実行してみてください。
質問1：あなたのユーザーの何割が、あなたについても同じ日誌を書く可能性がありますか？
あなたのステータスページの過去90日間のインシデントと、あなたのチームは知っているがステータスページには報告されていない劣化を抽出してください。それらをあなたのトップ20顧客の勤務時間と照らし合わせてください。あなたを待つために費やされた時間を数えてください。もし答えが「ヘビーユーザー一人あたり週にゼロ時間以上」であるならば、あなたは同じ軌道に乗っています。
質問2：あなたの信頼性の二次導関数はどうですか？
信頼性が横ばいであれば問題ありません。静かに劣化している信頼性は罠です。ハシモトの日誌は、単一のイベントではなくパターンを記録していました。もしあなたが、毎週月曜の朝に誰かが読むようなコンポーネントごとのエラーバジェットを持っていないなら、あなたの数字がどちらの方向に動いているかを判断することはできません。
質問3：ユーザーが日誌をつける必要がないほど十分に公開していますか？
日誌が存在するのは、ユーザーが公開情報を信頼していないからです。あなたのステータスページは「熱く」、つまり頻繁に更新されるべきであり、「冷たく」あってはなりません。機能が劣化していればそれを明記してください。リージョンが遅ければそれを明記してください。バックグラウンドキューが30分遅れていればそれを明記してください。リアルタイムで真実を見ることができるユーザーは日誌をつけ始めません。
質問4：あなたは真剣な仕事に対して信頼性がありますか、それともデモに対して信頼性がありますか？
稼働時間99.95%であっても、すべてのダウンタイムが開発者の勤務時間に集中している場合、稼働時間99.9%が均等に分散しているよりも悪いかもしれません。もしあなたのワークロードが4時間のPRレビューセッションだとすると、任意の2時間の障害は無関係ですが、そのセッション中に2時間の障害が発生すれば、セッション全体が無駄になります。可用性は、顧客の実際の使用曲線に対して測定すべきであり、あなたの曲線に対してではありません。
ロックインと「常時GitHub」のコスト
ハシモトが自身について使った言葉は、この投稿の中で最も引用されるべきセリフです。「プロジェクトをどこに置くかについて、私にとっては疑問の余地はありませんでした。常にGitHubでした。」これは習慣のコストであり、ほとんどの開発者が適切に評価していないコストです。
単一のプラットフォームがリポジトリ、イシュー、PR、CI、パッケージ配布、リリース、そしてアイデンティティのデフォルトである場合、「ロックイン」の表面積は「Gitの履歴」の表面積よりもはるかに大きくなります。Gitリポジトリはどこにでもクローンできますが、イシュー管理システム、PRレビュー履歴、ディスカッションスレッド、GitHub Actionsのシークレットストア、またはCODEOWNERSに紐付けられたレビューワークフローを単一のコマンドでクローンすることはできません。移行コストは氷山のような形をしています。
このコストはツール開発者にとってさらに増大します。あなたの開発者ツールがGitHub Actions内で動作し、マーケットプレイスを通じて配布され、GitHub OAuthに対して認証を行い、GitHub Packagesを通じてリリースを出荷する場合、あなたのツールの信頼性はGitHubの信頼性の派生物となります。あなたのエラーバジェットは彼らのものの一部です。顧客はあなたのツールにアクセスするときにあなたのダウンタイムを経験しますが、GitHubがダウンしてあなたのツールが応答しなくなったときにもあなたのダウンタイムを経験します。責任の帰属は常に正確ではありませんが、顧客体験はそうです。
デカップリング作業は地味であり、それが仕事です。すべての依存関係を置き換え可能にしてください。GitHubをインフラとしてではなく、複数のプロバイダーの一つとして扱ってください。代替パスを四半期ごとにテストしてください。別のフォージの方が適している部分は移行し、そうでない部分は残してください。ハシモトの「段階的な移行」という言葉は、彼一人だけでなく、すべての人にとって適切な形です。
フォージの代替案、手短に
Ghosttyの移行先候補は、名前こそ明らかではないものの、その形状は公に知られています。2026年4月下旬時点での信頼できる選択肢は以下の通りです。
- Forgejo。Giteaのハードフォークで、完全にFOSS、Codeberg e.V.非営利団体によって維持されています。ActivityPubを介したフェデレーションはロードマップにあり、部分的に出荷されています。FOSSに準拠したプロジェクトのデフォルトオプションです。
- Codeberg。非営利団体として運営されるホスト型Forgejoインスタンス。オープンソース向けには無料で、GitHub規模のActionsに相当する機能はまだありません。
- GitLab。強力なCI/CD、ほとんどのワークフローでGitHubと完全な機能同等性、商業的な支援があります。最近のライセンス変更により、FOSSコミュニティにとっては議論の的となる選択肢です。
- Sourcehut。メール駆動型ワークフロー、ミニマリスト、高速。ニッチな層向けですが、利用する層は熱狂的です。ドリュー・デヴォルトの政治的スタンスは、あなたの事前の認識によって特徴とも欠点ともなります。
- ベアメタルでのセルフホスト型ForgejoまたはGitea。最大限のコントロール、最大限の運用責任。「ゴーダーク」オプションです。
- Radicle。ピアツーピア、中央ホストなし。まだ初期段階ですが、フェデレーションの議論が最も強いです。公に公開するプロジェクトにはまだ早すぎるかもしれません。
ハシモトは明示的にどれか一つにコミットしませんでした。この沈黙が示すシグナルは、GitHubが提供するすべてを完全に代替できるオプションはどれも明らかではないということです。これは肝心な点であり、一つのプラットフォームがスタック全体を吸収している場合、それをきれいに置き換えることは構造的に困難です。
APIチームへの教訓
ターミナルエミュレーターではなくAPIまたはAPIツールを構築する場合でも、同じパターンが名前を変えて適用されます。「GitHub Actions」を「あなたの製品が依存するアップストリームAPI」に置き換えてください。「イシューとPR」を「顧客が問題があることを伝える受信箱」に置き換えてください。構造的な質問は同じです。顧客の仕事のどれだけが、あなたが制御できないサービスに依存しており、そのサービスがダウンしたときにどのように役立ち続けるか、ということです。
現実との接触に耐える3つのパターン。
依存するすべてをモックする。アップストリームAPIがダウンしても、顧客は構築を続けられるべきです。これは、テストスイート、ローカル開発ループ、CIパイプラインのすべてが、ネットワーク呼び出しなしで現実的な応答を返すモックサーバーを必要とすることを意味します。Apidogはこれを第一級の機能として提供しており、ライブAPIをテストするために使用するのと同じデータ定義がモックを生成します。このパターンは単純で、コストは一度支払えば済みます。マルチプロバイダーモッキングが実際にどのように機能するかについては、GPT-5.5 APIの使用方法に関するOpenAI型エコシステムとの比較を参照してください。
複数のプロバイダーに対してテストする。OpenAI、Anthropic、Mistral、DeepSeek、Google、xAIはすべて、重複する形状のチャット補完エンドポイントを公開しています。もしあなたの製品がそれらのいずれかをラップしている場合、「OpenAIがダウンしているため、私たちはダウンしています」と「バックアッププロバイダーに透過的にルーティングしました」との違いは、2日間の統合作業に相当します。サポートするすべてのプロバイダーに対してテストスイートを実行し、主要なプロバイダーだけではありません。Apidogの環境変数を使用すると、スワップは1行の構成変更で済みます。
リリースパイプラインをホスティングプラットフォームから切り離す。CIが完全にGitHub Actions上で動作し、GitHub Actionsが悪い午後を迎えた場合、リリースはどこにも行きません。CIをセカンダリランナーにミラーリングするか、少なくとも重要なパスをセルフホストすることで、単一障害点を取り除きます。コストはかかりますが、そうでなければ主要プロバイダーのステータスページの色が変わる間、出荷できないことになります。
レジリエントなAPI作業のためのApidogスタイルのワークフロー
具体的には、アップストリームのプロバイダー障害から身を守るためにほとんどのチームが使用するパターンを以下に示します。
- Apidogをダウンロードし、依存するアップストリームAPI表面ごとにプロジェクトを一つ作成します。
- リクエストとレスポンスのスキーマを一度定義します。Apidogはスキーマからモックサーバーを生成するため、開発ループがアップストリームサービスにブロックされることはありません。
- 認証情報は環境スコープのシークレットとして保存します。同じリクエスト形状が、環境を切り替えることで
dev（モック）、staging（サンドボックス）、prod（ライブ）に対して実行されます。 - すべてのリリースで実行される契約テストを作成します。同じテストがサポートするすべてのプロバイダーに対して実行されるため、プロバイダーAでの回帰は顧客が目にする前に表面化します。
- アップストリームAPIが劣化した場合、環境をモックに切り替えて作業を続行します。アップストリームが動作しなくても、製品は出荷されます。
このパターンはGhostty固有でもAI固有でもありません。これは、必要になる前に採用したすべてのチームにとって効果的であった、レジリエントなAPIパターンです。ハシモトの投稿は、必要になった後ではなく、必要になる前にそれを採用すべきだという最新のリマインダーです。
開発者たちがこの発表から読み取っていること
最初の48時間の反応は、いくつかのバケツに分類されます。
「彼のためには良かった」派。何ヶ月も静かに不満を抱いていた長年のGitHubパワーユーザーたちは、この投稿を自分たちの不満を公にする許可だと捉えました。彼らの多くはすでにセカンダリフォージにミラーリングしており、この投稿はミラーを主要なものにする方向へと彼らを傾けさせました。
「たった一度の障害だ」と懐疑的な派。GitHubの全体的な稼働時間は業界標準と競合しており、どの大規模プラットフォームにも悪い日はあると指摘する人々。彼らはマクロな数値については間違っていませんが、二次導関数の点を見落としています。ハシモトを動かしたのは、絶対値ではなくトレンドなのです。
「プラットフォームからの離脱は難しい、半年後にまた会おう」と現実的な派。フォージ移行を経験し、イシュートラッカー、PR履歴、CIの表面積が移行コストの源であることを知っているエンジニアたち。彼らは正しく、ハシモトの「読み取り専用ミラーを用いた段階的な」計画はその制約に対して適切な形です。
「私のリポジトリはどうなる」と心配する派。彼らのプロジェクトが同じリスクにさらされるのかと疑問に思う小規模なメンテナーたち。答えは、形は同じだが規模は違う、です。ハシモトがHashiCorpで有償の1日を失うような障害も、週末プロジェクトにとっては些細な不便です。あなたの移行計算は異なります。
重要な反応はソーシャルメディア上にはありません。それらは、出荷するすべてのものの基盤としてGitHubを選んだエンジニアリング組織内部にあります。現在、Slackで議論が交わされています。「これをどのようにリスク回避するか、セカンダリフォージへのミラーリングに関する内部ポリシーはどうあるべきか、そして離脱戦略はどうするか」と。
あなた自身のスタックのための実践的な教訓
短く、意見を込めたチェックリスト：
- アクティブなリポジトリを毎週セカンダリフォージにミラーリングしてください。ForgejoとCodebergはオープンソース向けには無料です。コストはCIジョブ1つ分ですが、その価値は次の4時間障害時に安心して眠れることです。
- 依存関係を固定してください。GitHub APIを呼び出す開発者ツールをリリースする場合、GitHubクライアントを固定インポートとしてではなく、交換可能なアダプターとして扱ってください。同じインターフェースの背後にForgejoまたはGitLabアダプターを追加してください。
- 手動フォールバックを文書化してください。自動リリースパイプラインが実行できない場合、手動パスはどうなりますか？文書化されていない場合、答えは「リリースできません」であり、これは有料顧客を持つツールにとっては受け入れられない答えです。
- 依存するものを監査してください。重要なパスにあるすべての外部サービスをリストアップしてください。それぞれについて、「これが4時間ダウンした場合、どうしますか？」という質問への答えを書き留めてください。ギャップをリーダーシップに提示してください。
- 二次導関数を監視してください。SLAを満たしているサービスであっても、インシデント頻度が月ごとに増加している場合、強制される前に移行を計画してください。
APIツール固有の実例として、プロバイダー障害に耐える耐久性のあるワークフローを構築する方法に関する投稿は、DeepSeekとOpenAIをデュアルプロバイダーの例として使用し、コードとともに同じパターンを解説しています。形は変わっても、原則は変わりません。
よくある質問
Ghosttyはどこへ移動するのですか？ハシモトは発表投稿で移行先を明言しませんでした。彼は、複数のプロバイダー（商用とFOSSの両方）との協議が進行中であり、移行は単一の切り替えではなく段階的に行われると述べました。現在のGhostty GitHubリポジトリは、既存のクローン、リンク、参照が引き続き機能するように、読み取り専用ミラーとして残ります。
GitHubはそれほど信頼できないのですか？GitHubの公表されている稼働時間は、同等のプラットフォームと競合していますが、2025年と2026年にはActions、Packages、API表面に影響を与えるいくつかの長時間の障害が発生しています。ハシモトの不満は、部分的な障害のパターンが、たとえそれぞれが短時間であっても、重要なパス上にいるユーザーにとっては毎週数時間の作業時間の損失に積み重なることです。
今すぐリポジトリをGitHubから移動すべきですか？ミラーリングはほぼ確実に価値があります。毎週CIジョブでセカンダリフォージにプッシュすることは、ほとんどコストがかからず、次にGitHub Actionsが数時間ダウンしたときに機能するバックアップを提供します。セカンダリフォージを主要なものにするかどうかは、イシュー、PR履歴、CI構成に関する移行コストへの許容度によります。ほとんどのチームにとって、そのコストはまだ信頼性のギャップによって正当化されていません。
これはGitHub CopilotまたはGitHub Actionsの使用に影響しますか？ハシモトの投稿は、特定の製品名を挙げていませんが、投稿当日のActionsの障害が直接の引き金となりました。Copilotはプラットフォームとは別の製品表面であり、その信頼性は別途追跡されます。もしあなたのチームがGitHub Copilotを使用している場合、関連する課金変更はチーム向けGitHub Copilotの使用状況と課金APIに記載されています。
GitHub APIに依存するAI時代の開発者ツールにとって、これは何を意味しますか？GitHub APIをラップするツール（レビューボット、イシュートリアージ、MCPサーバーなど）は、構造的にGitHubの信頼性プロファイルを継承します。その緩和策は、他のサードパーティ依存関係と同じです。積極的にキャッシュし、オープンに失敗し、テストスイートでアップストリームをモックします。Apidogのモックサーバーパターンは、これを行う安価な方法の一つです。Clawsweeperトリアージボットの解説には、実例が示されています。
これは「GitHub離脱」のトレンドですか、それとも単発的なものですか？おそらくトレンドの始まりですが、ゆっくりとしたものです。些細ではないプロジェクトをGitHubから移行するには数週間かかるため、楽しんで行うチームはほとんどいません。ハシモトの投稿が示すシグナルは、トレードオフが十分に変化し、プラットフォームの最も古参のユーザーの一人が移行コストを支払う価値があると判断したことです。他の注目度の高いプロジェクトも、今後12ヶ月で追随する可能性があります。
この文脈における「開発者ツール開発者」とは何を意味しますか？他の開発者が日常のワークフローの一部として使用するソフトウェアを出荷するすべての人です。これには、ターミナル、エディター、CIランナーなどの明白なケースが含まれます。また、APIクライアント、監視ツール、パッケージレジストリ、AIコーディングアシスタントも含まれます。顧客が開発者であり、あなたのツールが彼らと出荷の間に位置する場合、あなたは開発者ツール開発者であり、ハシモトの投稿からの信頼性に関する教訓は直接適用されます。