2026年4月28日、ミッチェル・ハシモトは、自身のオープンソースのターミナルエミュレーターであるGhosttyがGitHubから離れることを発表しました。彼はGitHubユーザー1299番で、2008年2月から18年以上にわたり、ほぼ毎日GitHubを使ってきました。しかし発表当日、GitHub Actionsの障害によりPRレビューが2時間ブロックされました。彼の結論は明確です。「毎日、数時間にわたって作業をブロックされるようでは、ここは真剣な仕事をする場所ではなくなりました。」
開発者ツールを作っているなら、この発表は「GitHubからどこへ移るのか」以上の意味があります。ハシモトはHashiCorpを共同設立し、Terraform、Vagrant、Vault、Consul、BoundaryをGitHub経由でリリースしてきた人物です。そのようなユーザーが、機能や価格ではなく「信頼性」を理由に離脱することは、開発者プラットフォームに依存するすべてのチームへの警告です。
AI時代の開発者ツールがGitHubネイティブなワークフローをどう変えているかは、AGENTS.mdファイルの書き方およびチーム向けGitHub Copilotの使用状況と課金APIも参考になります。GitHubの信頼性ギャップを自動化で補う例としては、Clawsweeperトリアージボットの解説があります。
要点
- ミッチェル・ハシモトは2026年4月28日、GhosttyがGitHubを離れ、未発表の別フォージへ移行すると発表しました。
- 理由はGitHub Actionsとプラットフォーム全体の慢性的な障害です。彼は個人的な日誌で「ほぼ毎日X（障害）がある」と記録していました。
- 発表当日もGitHub Actionsの障害により、PRレビューが2時間ブロックされました。
- GhosttyのGitHubリポジトリは読み取り専用ミラーとして残り、アクティブな開発は段階的に新しいフォージへ移されます。
- 重要なのは移行先ではなく、GitHubユーザー1299番のハシモトが「信頼性」を理由に離れたことです。
- 開発者ツールでは、機能よりも「必要なときに動くこと」が優先されます。
- APIチームにとっての実装方針は、プロバイダー非依存の設計、モック、代替CI、移行パスの事前検証です。Apidogはこのパターンを支援します。
ハシモトが投稿で述べたこと
発表投稿は短く、感情的な批判ではありません。Microsoft批判でも、代替フォージの宣伝でもありません。
彼が述べた事実は次の通りです。
- GitHubの障害日誌をつけ始めた。
- その日誌は予想以上に早く埋まった。
- 投稿当日の朝、GitHub Actions障害でPRレビューが2時間止まった。
- Ghosttyの開発には、GitHubが十分に信頼できなくなったと判断した。
2026年4月27日には、Actions、Packages、API表面に影響する大規模障害も発生していました。ただし、ハシモトの判断はその一日だけへの反応ではありません。彼は数ヶ月にわたってパターンを見ており、4月27日の障害は決定を早めただけです。
移行方針も現実的です。
- GhosttyはGitHubを離れる。
- 他のプロジェクトは当面GitHubに残る。
- Ghosttyリポジトリは読み取り専用ミラーとして残る。
- イシュー、プルリクエスト、CIを含むアクティブな開発は新フォージへ移る。
- 移行先はまだ未発表。
- 商用およびFOSSの複数プロバイダーと協議中。
- 移行は一括ではなく段階的に行う。
注目すべきは、彼が機能、価格、UI、製品方針を問題にしていないことです。問題は「開発の重要パス上にあるサービスが、必要なときに止まる」ことでした。
なぜ移行先より信頼性が重要なのか
この話の焦点は「Ghosttyがどのフォージへ移るか」ではありません。重要なのは、GitHubほど支配的な開発者プラットフォームでも、長年のヘビーユーザーに「真剣な仕事には使えない」と判断され得ることです。
この発表が重い理由は3つあります。
1. 発信者の信頼性
ハシモトはGitHubのライトユーザーではありません。HashiCorpの主要プロダクトをGitHub上で育ててきた人物です。彼が「信頼できない」と言うと、ソースコード管理基盤を選定するCTOやエンジニアリングリーダーも反応します。
2. 理由が政治的ではない
離脱理由はCopilot、AIトレーニング、Microsoft、価格、契約問題ではありません。
理由は単純です。
必要なときにサービスが動かなかった。
これはすべての開発者ツールに共通する評価軸です。
3. トーンが冷静
投稿は怒りではなく、事後分析に近い文章です。長く使い続けようとしたユーザーが、障害の記録を積み上げた結果、離脱を決めたように読めます。
開発者ツールの運営者にとって、これは最も厄介なパターンです。炎上ではなく、静かな信頼低下です。PR対応で日誌は消せません。
開発者ツールを作るチームが確認すべき4つの質問
自分のサービスが開発者の重要パス上にあるなら、次の質問を実際にチームで確認してください。
質問1：ユーザーはあなたのサービスについても障害日誌を書けるか？
過去90日分を確認します。
- ステータスページに載せたインシデント
- 載せなかった部分的劣化
- サポートに届いた遅延報告
- CI、API、認証、Webhookの不安定化
- トップ顧客の勤務時間中に発生した影響
ユーザー1人あたり週に数十分でも作業が止まっているなら、同じ軌道に乗っています。
質問2：信頼性は改善しているか、静かに悪化しているか？
単発障害より危険なのは、頻度が増えている障害です。
見るべき指標は次です。
- 月別インシデント数
- コンポーネント別エラーバジェット消費
- 平均復旧時間
- 部分障害の検知遅延
- ステータスページ更新までの時間
- 顧客影響時間
SLAを満たしていても、傾きが悪化しているなら移行検討の対象になります。
質問3：ユーザーが自分で日誌をつけなくて済むほど公開しているか？
ステータスページは「冷たい広報ページ」ではなく、実運用の信頼インターフェースです。
書くべき内容は曖昧な「調査中」だけではありません。
- どの機能が劣化しているか
- どのリージョンが影響を受けているか
- APIの遅延がどの程度か
- キューが何分遅れているか
- 回避策があるか
- 次回更新予定時刻
ユーザーがリアルタイムで状況を把握できれば、個人で障害日誌をつけ始める必要は減ります。
質問4：デモではなく本番作業に耐えられるか？
99.95%の稼働率でも、ダウンタイムが顧客の勤務時間に集中すれば実感値は悪くなります。
たとえば、開発者が4時間のPRレビューセッションを予定していて、そのうち2時間GitHub Actionsが止まれば、そのセッションはほぼ失われます。
可用性は自社都合の月次平均だけでなく、顧客の実際の作業曲線に対して測るべきです。
ロックインと「常にGitHub」のコスト
ハシモトの投稿で重要な一文があります。
プロジェクトをどこに置くかについて、私にとっては疑問の余地はありませんでした。常にGitHubでした。
これは多くの開発者に当てはまります。しかし、単一プラットフォームが次のすべてを担うと、ロックインの範囲はGitリポジトリを超えます。
- リポジトリ
- イシュー
- プルリクエスト
- レビュー履歴
- Discussions
- CI/CD
- Secrets
- Packages
- Releases
- OAuth
- CODEOWNERS
- Bot連携
- Webhook
- 権限管理
Git履歴はcloneできます。しかし、イシュー、PRレビュー、ActionsのSecrets、レビューワークフロー、リリース自動化は単一コマンドでは移行できません。
開発者ツールではこの影響がさらに大きくなります。
たとえば、あなたのツールが次のような構成なら、信頼性はGitHubの信頼性に強く依存します。
- GitHub Actions内で実行される
- GitHub Marketplaceで配布される
- GitHub OAuthで認証する
- GitHub Packagesで成果物を配布する
- GitHub APIでPRやIssueを読む
この場合、あなたのエラーバジェットはGitHubのエラーバジェットの一部になります。ユーザーは原因がGitHubでも、体験としては「あなたのツールが止まった」と感じます。
フォージの代替案
Ghosttyの移行先は未発表ですが、候補になり得る選択肢はあります。
| 選択肢 | 特徴 | 向いているケース |
|---|---|---|
| Forgejo | Giteaのハードフォーク。完全FOSS。Codeberg e.V.が維持 | FOSS重視、セルフホスト可能性を重視 |
| Codeberg | 非営利団体運営のホスト型Forgejo | OSSプロジェクト、低コスト運用 |
| GitLab | 強力なCI/CDと商用サポート | 企業利用、CI統合重視 |
| Sourcehut | メール駆動、軽量、高速 | ミニマルなワークフローを好むチーム |
| セルフホストForgejo/Gitea | 最大限の制御と運用責任 | 運用できるチーム、独立性重視 |
| Radicle | P2P、中央ホストなし | 実験的、分散志向のプロジェクト |
どれもGitHubのすべてを完全に置き換えるわけではありません。だからこそ、段階的移行、ミラーリング、CI分離が重要になります。
APIチームへの教訓
APIやAPIツールを作っている場合も、同じ構造が当てはまります。
- 「GitHub Actions」→「依存するアップストリームAPI」
- 「イシューとPR」→「顧客が問題を報告するチャネル」
- 「フォージ移行」→「プロバイダー切り替え」
- 「読み取り専用ミラー」→「フォールバック環境」
実装すべきパターンは3つです。
1. 依存するAPIをモックする
アップストリームAPIが落ちても、開発、テスト、CIが止まらないようにします。
最低限、次を用意します。
- ローカル開発用のモックサーバー
- CIで使う固定レスポンス
- エラーケースのモック
- レート制限時のレスポンス
- タイムアウト時の挙動
- スキーマに基づく契約テスト
Apidogでは、ライブAPIテストに使うデータ定義からモックを生成できます。モックと実APIの定義を分けないことで、仕様ずれを減らせます。
マルチプロバイダーモッキングの例は、GPT-5.5 APIの使用方法も参考になります。
2. 複数プロバイダーに対してテストする
AI APIのように、似た形のエンドポイントを複数プロバイダーが提供している場合、単一プロバイダーだけでテストすると障害時に詰まります。
例：
- OpenAI
- Anthropic
- Mistral
- DeepSeek
- xAI
実装では、プロバイダーを直接呼ぶのではなくアダプターを挟みます。
interface ChatProvider {
complete(input: ChatRequest): Promise<ChatResponse>;
}
class OpenAIProvider implements ChatProvider {
async complete(input: ChatRequest) {
// OpenAI API call
}
}
class AnthropicProvider implements ChatProvider {
async complete(input: ChatRequest) {
// Anthropic API call
}
}
class FallbackProvider implements ChatProvider {
constructor(
private primary: ChatProvider,
private secondary: ChatProvider
) {}
async complete(input: ChatRequest) {
try {
return await this.primary.complete(input);
} catch (error) {
return await this.secondary.complete(input);
}
}
}
テストは主要プロバイダーだけでなく、サポート対象すべてに対して実行します。Apidogの環境変数を使えば、環境切り替えを設定変更として扱えます。
3. リリースパイプラインをホスティングから切り離す
CIがGitHub Actionsだけに依存している場合、GitHub Actionsが止まるとリリースも止まります。
対策は次です。
- 重要なジョブを別CIにもミラーする
- リリース用の最小パイプラインをセルフホストする
- 手動リリース手順を文書化する
- Secretsを単一プラットフォームだけに閉じ込めない
- 成果物を複数の配布先へ配置する
たとえば、最低限の手動リリース手順を docs/release.md に残しておくだけでも、障害時の復旧時間は短くなります。
# 手動リリース手順
1. mainブランチをpullする
2. テストを実行する
bash
npm ci
npm test
3. バージョンを更新する
bash
npm version patch
4. ビルドする
bash
npm run build
5. パッケージを公開する
bash
npm publish
6. Gitタグをpushする
bash
git push origin main --tags
レジリエントなAPI作業のためのApidogワークフロー
アップストリームAPI障害に備える実装フローは次の通りです。
- Apidogをダウンロードします。
- 依存するアップストリームAPIごとにプロジェクトを作成します。
- リクエストとレスポンスのスキーマを定義します。
- そのスキーマからモックサーバーを生成します。
- 認証情報は環境スコープのシークレットとして保存します。
-
dev、staging、prodなどの環境を分けます。 - 同じリクエストを環境切り替えだけで実行できるようにします。
- 契約テストを作成し、リリースごとに実行します。
- サポートする全プロバイダーに同じテストを流します。
- アップストリーム障害時はモック環境へ切り替え、開発を継続します。
このパターンはGhostty固有でもAI固有でもありません。外部サービスを重要パスに持つすべての開発チームに適用できます。
自分のスタックで今すぐやること
短く、実装寄りのチェックリストです。
リポジトリ
- アクティブなリポジトリを週次でセカンダリフォージにミラーする
- ミラー先でclone、build、testできるか確認する
- GitHub固有の設定を棚卸しする
- イシューとPR履歴のエクスポート方法を調べる
CI/CD
- GitHub Actions以外の実行経路を用意する
- リリースだけは手動でも実行できるようにする
- Secretsのバックアップ配置を決める
- 成果物の配布先を複数持つ
API依存
- 重要な外部APIを一覧化する
- 各APIについて「4時間落ちたらどうするか」を書く
- モックサーバーを用意する
- 契約テストをCIに入れる
- フォールバックプロバイダーを実装する
監視
- コンポーネント別にインシデント頻度を見る
- 月次の悪化傾向を追う
- ステータスページ更新までの時間を測る
- 顧客の作業時間帯に対する影響を測る
APIツール固有の具体例としては、プロバイダー障害に耐えるワークフローを構築する方法も参考になります。DeepSeekとOpenAIをデュアルプロバイダーの例として扱っています。
よくある質問
Ghosttyはどこへ移動するのですか？
ハシモトは移行先を明言していません。商用とFOSSの複数プロバイダーと協議中で、移行は一括ではなく段階的に行うと述べています。現在のGitHubリポジトリは読み取り専用ミラーとして残ります。
GitHubは本当に信頼できないのですか？
GitHubの公表稼働率は同種のプラットフォームと競合しています。ただし、2025年から2026年にかけて、Actions、Packages、API表面に影響する長時間または部分的な障害が複数発生しました。ハシモトが問題視したのは単発障害ではなく、作業時間を繰り返し奪うパターンです。
今すぐGitHubから移行すべきですか？
多くのチームにとって、即時移行より先にミラーリングが現実的です。週次CIでセカンダリフォージへpushするだけならコストは小さく、障害時の保険になります。主要フォージを切り替えるかどうかは、イシュー、PR履歴、CI構成の移行コスト次第です。
GitHub CopilotやGitHub Actionsの利用に影響しますか？
ハシモトの投稿は特定製品を広く批判するものではありません。ただし、投稿当日のActions障害は直接の引き金になりました。Copilotは別の製品表面ですが、利用状況や課金についてはチーム向けGitHub Copilotの使用状況と課金APIを確認してください。
GitHub APIに依存する開発者ツールはどうすべきですか？
GitHub APIをラップするレビューボット、イシュートリアージ、MCPサーバーなどは、GitHubの信頼性を継承します。対策は、キャッシュ、モック、フォールバック、プロバイダー抽象化です。実例としてはClawsweeperトリアージボットの解説があります。
これは「GitHub離脱」トレンドですか？
短期的に大規模な離脱が起きるとは限りません。GitHubからの移行は、イシュー、PR、CI、認証、配布まで含めると高コストです。ただし、ハシモトのような古参ユーザーが移行コストを払う価値があると判断したことは、他のプロジェクトにとっても判断材料になります。
まとめ
Ghosttyの発表から学ぶべきことは、GitHubを使うべきかどうかではありません。
学ぶべきことは次です。
- 開発者の重要パス上にあるツールでは、信頼性が機能に勝る。
- 単一プラットフォーム依存は、障害時に開発速度を止める。
- Git履歴だけでなく、CI、Issue、PR、Secrets、配布まで含めてロックインを評価する。
- ミラーリング、モック、フォールバック、手動リリース手順は事前に用意する。
- 障害が起きてからではなく、平常時に移行パスをテストする。
ハシモトの投稿は、すべての開発者ツール開発者に対する実践的なチェックリストです。ユーザーが障害日誌を書き始める前に、自分たちのスタックを分解し、代替経路を動かしておくべきです。
Top comments (0)