「本番でバグ出てるんだけど、今のdevelopブランチ出せないんだが…」
金曜日の夕方、Slackに「本番で決済エラーが出ています」と報告が入る。すぐ直したい。でもdevelopブランチには来週リリース予定の未検証機能がごっそり入っている。このままdevelopをデプロイしたら、バグ修正と一緒に未完成の機能まで本番に出てしまう。
こういう時に使うのがhotfix（ホットフィックス）です。本記事では、hotfixの基本概念からGitでの具体的な運用フロー、守るべきルールまでを解説します。
hotfixとは？ ― 本番の緊急バグを即修正するフロー
hotfix（ホットフィックス）は、「hot（熱い＝緊急の）」+「fix（修正）」で、本番環境で発生した緊急バグを、通常のリリースフローを飛ばして即座に修正・デプロイする手法です。
【通常リリース】
feature → develop → staging → テスト → main → デプロイ
（数日〜数週間かかる）
【hotfix】
main → hotfix/xxx → 修正 → main → 即デプロイ → developにも反映
（数分〜数時間で完了）ポイントは、hotfixブランチはdevelopからではなくmain（本番）から切るということ。developに混ざった未検証コードを巻き込まずに、本番のコードに対してピンポイントで修正を入れられます。
通常リリースとhotfixの違い
| 項目 | 通常リリース | hotfix |
|---|---|---|
| ブランチの起点 | develop |
main（本番） |
| 含まれる変更 | 複数機能・改善をまとめて | 緊急バグの修正のみ |
| テスト範囲 | フル回帰テスト | 修正箇所＋影響範囲の最小テスト |
| 所要時間 | 数日〜数週間 | 数分〜数時間 |
| マージ先 | main |
main＋develop（両方） |
特に重要なのが最後の行。hotfixはmainにマージした後、developにも必ずマージします。これを忘れると、次の通常リリースで修正が巻き戻るという最悪の事態が起きます。
Git Flowでのhotfix運用
実際のGitコマンドで流れを見ていきます。
Step 1：mainからhotfixブランチを切る
# mainブランチを最新に
git checkout main
git pull origin main
# hotfixブランチを作成（命名規則: hotfix/簡潔な説明）
git checkout -b hotfix/fix-payment-errorStep 2：最小限の修正をコミット
# 修正を加えてコミット
git add src/payment/checkout.ts
git commit -m "fix: 税込計算で小数点切り捨てが抜けていた問題を修正"
# リモートにpush
git push origin hotfix/fix-payment-errorコミットメッセージは「何を直したか」を明確に。hotfixは後から振り返ることが多いので、雑なメッセージは避けましょう。
Step 3：mainにマージしてデプロイ
# PRを作成してレビュー → マージ（GitHub上で実施するのが一般的）
# またはCLIでマージする場合
git checkout main
git merge --no-ff hotfix/fix-payment-error
git tag -a v1.2.1 -m "hotfix: 税込計算の修正"
git push origin main --tags
# デプロイ実行（CI/CDが自動で走る場合はpushだけでOK）--no-ff（no fast-forward）でマージすると、hotfixのマージコミットが履歴に残り、「いつhotfixが入ったか」が後から追いやすくなります。タグを打っておくのもおすすめです。
Step 4：developにもマージ（忘れがち！）
# developにもhotfixの修正を反映
git checkout develop
git pull origin develop
git merge --no-ff hotfix/fix-payment-error
git push origin develop
# hotfixブランチを削除
git branch -d hotfix/fix-payment-error
git push origin --delete hotfix/fix-payment-errorこの Step 4 を忘れるチームが本当に多いです。developにマージしないと、次の通常リリースでhotfixの修正が消えて同じバグが復活します。
hotfix運用で守るべき3つのルール
ルール1：修正は最小限に絞る
hotfixの最中に「ついでにこのリファクタもやっておこう」は厳禁です。変更量が増えるほどデグレ（意図しない副作用）のリスクが上がります。バグの原因となっている1箇所だけを直す。それ以外は通常リリースで対応しましょう。
ルール2：レビューを省略しない
「緊急だからレビューなしで」は事故のもとです。焦っている時ほどミスは起きます。最低1人にPRを見てもらう。レビュアーが捕まらない深夜なら、翌朝に事後レビューを入れることをルール化しておきましょう。
ルール3：hotfixの基準を事前に定義する
「何をhotfix対象とするか」が曖昧だと、些細なUI崩れまでhotfixになって運用が荒れます。事前に基準を決めておきましょう。
- hotfix対象：決済エラー、ログインできない、データ不整合、セキュリティ脆弱性
- 通常リリースで対応：軽微なUI崩れ、文言修正、パフォーマンス改善
この基準をチームのREADMEやWikiに明文化しておけば、「これhotfixですか？」という判断の迷いがなくなります。
Git運用をさらに強化する関連記事
hotfixの運用を理解したら、Gitやチーム開発の周辺知識もあわせて固めておきましょう。
Git・GitHub
- 「それ、上げちゃダメ！」GitHub管理で絶対守るべきセキュリティルールと対処法 – hotfixで慌てている時こそ、認証情報のハードコードやforce pushに注意
- システム開発を成功させるために知っておきたい「GitHub」の基本 – ブランチ戦略やPRの仕組みなど、hotfix運用の土台となるGitHubの基礎知識
CI/CD・デプロイ
- AWS CLIで開発が爆速になる！セットアップからCloudWatch・Lambda活用まで実用コマンド付き – hotfix後のデプロイ確認やCloudWatchでのエラー監視に
- リリース前に必ず確認！バイブコーディング＆非エンジニア向けWebアプリ安全チェックリスト – hotfixであっても最低限のリリース前チェックは必須
- Claude Codeとは？AI搭載のコーディングアシスタントを徹底解説 – 緊急対応時にAIにバグの原因特定を手伝ってもらう活用法
まとめ：hotfixは「最速で・最小限に・両方にマージ」
本記事のポイントを整理します。
- hotfixとは、本番環境の緊急バグを通常リリースを飛ばして即座に修正・デプロイするフロー
- mainから切るのが鉄則。developの未検証コードを巻き込まない
- mainとdevelopの両方にマージ。developへのマージ忘れで修正が消えるのが最も多い事故
- 修正は最小限。「ついでに」は通常リリースで
- レビューは省略しない。深夜対応なら事後レビューをルール化
- hotfixの基準を事前に定義して、チームの判断を統一する
本番障害は誰にとってもストレスフルな状況です。だからこそ、「hotfixのフローは決まっている」という安心感がチームを救います。焦っている時に手順を考えるのではなく、平常時にフローを決めて、READMEに書いて、一度は練習しておく。それがhotfix運用の本質です。
