木曜日の午後、開発者が請求画面の機能追加を進めているところへ、「特定条件でログイン後にエラーになる」という緊急連絡が入ったとします。これは架空の例ですが、中小規模の開発チームでは珍しくない場面です。担当者の目的は、本番障害につながる不具合を早く直しながら、途中まで進めた機能開発の状態も壊さずに保つことです。

普段使っている道具は、Gitで管理されたリポジトリ、コードエディタ、ローカルのテスト環境、CI、課題管理票などです。AIを使わない場合、開発者は作業中の変更を確認し、必要に応じて一時退避や途中コミットを行い、緊急修正用のブランチへ切り替えます。修正とテストが終われば元のブランチへ戻り、退避した変更を復元して、どこまで考えていたかを思い出さなければなりません。既存のGit運用として妥当な流れですが、割り込みの前後に細かな確認が集中します。

ここで扱う業務課題は、修正コードをAIに書かせること自体ではありません。焦点は、進行中の機能開発と緊急修正を物理的に分離し、調査、修正候補の作成、テスト、差分レビューを別の作業環境で完結させることです。Claude CodeとGit worktreeを組み合わせ、元の作業状態を残したまま緊急修正用のセッションを開始します。対象読者には、Gitのブランチ運用、テスト実行、コードレビュー、競合解消を自分で判断できる知識が必要です。



Claude Codeは調査や変更案の作成を補助できますが、障害の優先度、修正範囲、受け入れ条件、リリース可否までは自動的に決められません。人が判断すべき境界を先に固定することが、この使い方の土台になります。

従来の流れを分解すると、手間の中心はコーディング以外にもあります。開発者は、編集中のファイルと未追跡ファイルを確認し、現在の変更を残す方法を選びます。そのうえで緊急修正の起点を決め、別ブランチへ切り替え、エラー情報から関連コードを探し、再現条件を整理します。修正後には対象テストと影響範囲のテストを実行し、レビュー可能な差分へ整えます。

| 工程 | AIを使わない場合の主な作業 | 手戻りが起きやすい点 |
|---|---|---|
| 作業中断 | 未完了の変更を退避または途中保存 | 未追跡ファイルや作業メモの漏れ |
| 環境切り替え | 緊急修正用ブランチへ移動 | ローカル状態の混在、依存関係の差異 |
| 調査 | エラー文、ログ、呼び出し元、関連テストを検索 | 読む範囲の広がり、仮説の重複 |
| 修正・テスト | 最小修正を実装し、再現テストを追加 | 症状だけを抑えて原因を残す判断 |
| 元作業への復帰 | 元のブランチと退避内容を復元 | 思考の再構築、競合への対応 |



負荷が高いのは、ブランチを切り替える操作の回数だけではありません。機能開発のために開いていたファイル、未完了のテスト、設計上の仮説が緊急修正の情報で上書きされます。修正後に元の作業へ戻れても、「次に何を確認する予定だったか」を再構成する必要があります。途中コミットを使えば状態は残せますが、レビュー対象ではない未完成の変更を履歴へ置くかどうかという判断も発生します。

また、緊急修正を急ぐほど、調査と実装を同時に進めたくなります。原因の仮説が固まる前に変更すると、差分が広がり、レビュー時に「なぜこのファイルまで変わったのか」を説明しにくくなるでしょう。したがって改善対象は、Git操作の短縮だけではなく、調査、実装、検証、元作業への復帰という工程の境界を明確にすることです。

Claude Codeの公式ドキュメントでは、Git worktreeを利用した並行セッションが案内されています。各worktreeは既存コミットを起点とする別々のチェックアウトで、それぞれ独立したブランチを持つため、並行する編集の衝突を避けやすい構成です。リポジトリには少なくとも一つのコミットが必要で、コミットがない場合は基点となるHEADを解決できず起動に失敗すると説明されています（出典: Claude Code Docs）。

この構成では、元のディレクトリに機能開発中の変更を残し、別のworktreeで緊急修正を進められます。Claude Codeには、障害情報と受け入れ条件を渡し、関連コードの探索、原因候補の整理、変更計画、テスト候補の提示を依頼します。編集前に計画を確認したい場合はplan modeを利用でき、承認するまでファイルを変更させずに調査と提案を進められると案内されています（出典: Claude Code Docs）。



| 従来工程 | worktreeとClaude Codeを使う工程 | 人が残す判断 |
|---|---|---|
| 元作業を退避して切り替え | 元の作業環境を維持し、別環境を用意 | どのコミットを修正の起点にするか |
| 関連箇所を順番に検索 | 読み取り調査と原因候補の整理を依頼 | 仮説が障害事実と一致するか |
| 修正範囲を頭の中で組み立てる | 変更対象と非対象を計画として出させる | 公開仕様や互換性への影響 |
| テストを選定して実行 | 既存形式に沿うテスト候補と実行結果を求める | テストの十分性と結果の妥当性 |
| 元ブランチへ戻って復元 | 元のディレクトリで機能開発を再開 | 緊急修正との論理的な競合 |

AIが省略できるのは、人がファイルを一つずつ探して関連性を要約する反復や、テスト候補を列挙する下書き部分です。修正の責任は移りません。認証、権限、課金、データ更新などの業務ルールが絡む場合、期待動作をコードだけから推測させず、課題票や仕様を根拠として人が確定する必要があります。

準備では、最初にリポジトリにコミットが存在することを確認します。worktreeは既存コミットを起点にするため、緊急修正がどの状態へ適用されるべきかも人が選ばなければなりません。本番相当のブランチ、保守対象のリリース系列、開発中の先行ブランチでは、同じ不具合でも適切な起点が異なる可能性があります。ここをClaude Codeの推測に任せると、正しいコードを誤った系列へ実装する結果になりかねません。

AIへ渡す入力は、障害報告をそのまま貼るのではなく、事実と未確認事項に分けます。最低限用意したいのは、再現条件、期待結果、実際の結果、確認済みのエラー、対象外とする変更、実行すべきテスト、成果物の形式です。顧客名、アクセストークン、実データなどは入力せず、匿名化した値やローカルで再現できるテストデータへ置き換えます。これはClaude Code固有の機能説明ではなく、社外秘や認証情報を扱わないための運用上の提案です。



架空の準備メモは、次のように整理できます。

対象: ログイン後のリダイレクト処理
再現条件: returnToが空文字のときだけエラーになる
期待結果: 既定のダッシュボードへ遷移する
実際の結果: サーバーエラーになる
確認済み情報: 匿名化したスタックトレース、失敗する既存テスト
変更対象外: 認証方式、セッション保存形式、公開API
必須確認: 再現テスト、既存の認証テスト、型検査
成果物: 原因説明、最小差分、テスト結果、未確認事項

成功条件も「エラーを直す」だけでは足りません。失敗を再現するテストが修正前に意図どおり失敗し、修正後に成功すること、既存の関連テストを壊していないこと、変更理由を差分から説明できることまで定めます。依存関係の更新、外部サービスへの書き込み、コミット、プッシュ、デプロイは別承認にするなど、Claude Codeが実施してよい範囲も明記しておくとレビューしやすくなります。

元のターミナルとディレクトリは機能開発用として残し、別のターミナルから緊急修正用のworktreeセッションを開始します。公式資料で案内されているworktree起動方法を、利用中のClaude Codeの構文で確認したうえで、識別しやすい名前を付けます。たとえば、資料で示される形式に沿った実行例は次のとおりです。

claude --worktree hotfix-login-redirect

同じ名前を他用途へ使い回さず、課題番号や症状が分かる名前にするのは運用上の提案です。作成先の詳細やブランチ名を推測せず、起動後に表示された作業場所と現在のブランチを人が確認してください。元の機能開発ディレクトリと緊急修正用ディレクトリが別であることも、編集を許可する前に確かめます。



最初はplan modeで読み取り調査だけを依頼します。コピーして使うお願い文の例です。角括弧内は自分の案件に置き換えてください。

このリポジトリで、[障害の症状]の原因を読み取り専用で調査してください。

事実:
- 再現条件: [条件]
- 期待結果: [期待する動作]
- 実際の結果: [現在の動作]
- 確認済みエラー: [匿名化したエラー]

調査では、関連する実装、呼び出し元、既存テストを確認してください。
まだファイルを編集しないでください。
原因候補ごとに根拠となるファイルと処理の流れを示し、
最小の変更案、追加すべき再現テスト、影響範囲、未確認事項を報告してください。
[変更対象外の範囲]には触れないでください。

人が計画を確認し、原因仮説と修正範囲を承認した後だけ、実装を依頼します。Claude Codeは既存テストを調べ、プロジェクトの形式やアサーションに合わせたテストを生成できると案内されています。ただし、検証したい振る舞いを具体的に指定し、境界値やエラー条件を明示することが推奨されています（出典: Claude Code Docs）。

承認した計画の範囲だけを実装してください。
修正前の不具合を再現する最小のテストを追加し、
必要最小限の実装でそのテストを通してください。

その後、関連する既存テストと[プロジェクトで定めた検証]を実行してください。
想定外の失敗、対象外ファイルへの変更、仕様上の疑問があれば作業を止めて報告してください。
最後に、変更ファイル、変更理由、実行した検証、観測した結果、未確認事項をまとめてください。
コミット、プッシュ、外部サービスへの書き込み、デプロイは行わないでください。

このお願い文は業務への適用例であり、実行結果を保証するものではありません。プロジェクト固有のテストコマンドや禁止事項へ置き換え、Claude Codeが報告した結果ではなく、実際の終了コードやテスト出力を人が確認します。

Claude Codeから受け取る成果物は、コードだけに限定しません。原因の説明、変更したファイル、追加したテスト、実行した検証、観測結果、未確認事項を一組として扱います。次の形式は回答の例ではなく、報告させる項目を固定するための提案です。

原因候補と根拠:
変更ファイルと目的:
追加した再現テスト:
実行した検証と終了結果:
確認できなかった事項:
公開仕様・データ・権限への影響:
元の機能開発と重なり得るファイル:

レビュー担当者は、課題票と差分を対応させ、症状に関係しない変更が混ざっていないかを確認します。テストでは、修正後に成功した事実だけでなく、再現テストが本来の不具合を捉えているかを読みます。条件を反転しただけのテストや、実装の内部構造へ過度に依存するテストでは、将来の回帰を検出できない場合があります。認証や権限の修正なら、正常系だけでなく、未認証、期限切れ、空値など、業務上必要な境界を人が選定してください。

worktreeはチェックアウトと編集場所を分けますが、変更同士の意味上の競合まで解消するわけではありません。これは独立した作業環境という公式説明から導く運用上の注意です。たとえば、機能開発側が同じ関数の引数を増やし、緊急修正側がその関数の既定値を変えていれば、テキスト上の競合がなくても挙動が変わる可能性があります。統合前には、両方で変更したファイル、公開インターフェース、データ形式、依存関係を照合し、適用順序を決めます。

緊急修正を取り込んだ後も、元の機能開発側で関連テストを再実行します。個別のworktreeで成功した結果は、その後に変化した統合先での成功を意味しません。レビュー承認、統合、CI、リリース判断はチームの既存手順に従い、Claude Codeの報告だけを承認根拠にしないことが大切です。

効果を確かめるときは、「AIを使ったので速かった」という感想ではなく、同じ種類の入力、成果物、品質条件で工程を比較します。記録する対象は、緊急修正そのものの時間だけではありません。元作業を退避する準備、関連ファイルの探索、原因仮説の整理、修正、テスト、レビュー修正、統合後の再確認、元作業へ復帰するまでを含めます。Claude Codeへの説明を作る時間や、誤った提案を退ける時間も除外しません。

評価表には、工程ごとの開始と終了、手作業で開いたファイル数、仮説のやり直し、対象外差分の有無、レビューで見つかった問題、再実行したテストを残すとよいでしょう。実測値はチーム自身の案件から取得します。worktreeで元作業の退避と復元が減っても、入力準備やレビューが増える場合があります。障害情報が曖昧な案件や自動テストが不足したリポジトリでは、Claude Codeが探索を補助しても、人の確認負担が下がるとは限りません。



比較時には品質条件を変えないことが欠かせません。従来側では関連テストまで実行し、AI活用側では最小テストだけで済ませる比較は公平ではありません。どちらも同じ受け入れ条件、レビュー基準、検証範囲を適用します。そのうえで、作業中断の回数、調査の重複、差分の広がり、統合後の手戻りがどう変化したかを確認してください。

最初の一歩には、再現条件が明確で、自動テストがあり、外部データを更新しない低リスクの不具合が向いています。機能開発を残した状態で緊急修正用worktreeを一つ作り、読み取り調査、承認、最小修正、テスト、差分レビューまでを一人または小規模なペアで試します。効果が確認できた工程だけをチーム手順へ残せば、AIを前提に業務全体を一度に組み替えずに済むでしょう。

- Common workflows - Claude Code Docs（2026年10月30日取得）