生成AIのためのGit入門　第4章：ブランチを切るだけでAI開発はかなり安全になる

Claude Codeに作業をお願いするときは、いきなりmainブランチで作業させないほうが安全です。

なぜなら、mainブランチはプロジェクトの本線だからです。

本線に直接AIの変更を入れてしまうと、失敗したときの影響が大きくなります。

そこで使うのが、Gitのブランチです。

ブランチとは、現在のコードから分岐して、別の作業場所を作る仕組みです。

たとえるなら、学校のノートをいきなり本番提出用に書き込むのではなく、下書き用のコピーを作ってから試すようなものです。

下書きなら、失敗しても本番用ノートは汚れませんよね。

Claude Codeに作業させるときのブランチも同じです。

ブランチとは何か

ブランチとは、Gitで作業の流れを分けるための仕組みです。

Git公式ドキュメントでは、git branchはブランチの作成、一覧表示、削除などに使うコマンドとして説明されています。

たとえば、mainブランチに安定したコードがあるとします。

そこからログイン機能を修正したい場合、次のように作業ブランチを作ります。

git switch -c feature/login-fix

git switchは、指定したブランチへ切り替えるコマンドです。Git公式ドキュメントでは、git switchを実行すると作業ツリーとインデックスが対象ブランチに合わせて更新され、以後の新しいコミットはそのブランチの先端に追加されると説明されています。

少し難しいですね。

簡単に言うと、git switchは「作業する場所を切り替えるコマンド」です。

git switch -cは、「新しい作業場所を作って、そこへ移動するコマンド」です。

つまり、次のコマンドはこういう意味になります。

git switch -c feature/login-fix

feature/login-fixという名前の作業ブランチを作って、そのブランチに移動する。

これで、Claude Codeにログイン修正を頼んでも、mainブランチを直接汚さずに済みます。

mainブランチで直接AI作業をしない

新人エンジニアがやりがちなミスは、mainブランチにいる状態でそのままClaude Codeに作業を依頼してしまうことです。

git branch

このコマンドを実行して、次のように表示されたとします。

*が付いているブランチが、現在いるブランチです。

この例ではmainにいます。

この状態でClaude Codeに「ログイン処理を直して」と頼むと、mainブランチに直接変更が入ります。

これは、完成済みの清書ノートに、いきなり下書きを書き込むようなものです。

うまくいけば問題ありません。

でも、失敗したときに面倒です。

AIが想定外のファイルを変更したり、既存機能に影響する修正を入れたりすると、mainブランチの状態が不安定になります。

だからこそ、Claude Codeに作業を任せる前にブランチを切ります。

ブランチを切ると何が安全になるのか

ブランチを切ると、AIの変更を隔離できます。

隔離とは、ほかの場所に影響しないように分けることです。

理科室で実験をするとき、いきなり教室全体で薬品を混ぜたりしませんよね。

実験台の上で、決められた範囲だけで試します。

ブランチも同じです。

Claude Codeの作業を、専用の実験台に閉じ込めるイメージです。

ブランチを切るだけで、Claude Codeの作業はかなり管理しやすくなります。

AIを信じるかどうかではありません。

AIが失敗しても困らない作業場所を用意する、という考え方です。

作業内容ごとにブランチを分ける

Claude Codeを使うと、つい一気にいろいろな作業を頼みたくなります。

たとえば、次のような依頼です。

ログイン機能を修正して、検索機能も追加して、DAOも整理して、テストも書いてください。

気持ちはわかります。

Claude Codeは速いので、まとめて頼みたくなりますよね。

でも、最初のうちは作業を分けたほうが安全です。

ブランチも、作業内容ごとに分けましょう。

ブランチ名を見るだけで、何の作業をしているのかわかる状態が理想です。

featureは機能追加、fixはバグ修正、refactorはリファクタリング、testはテスト追加のように使い分けるとわかりやすくなります。

リファクタリングとは、外から見た動きは変えずに、コードの中身を整理することです。

部屋の住所は変えずに、部屋の中だけ片づけるようなものです。

Claude Codeに頼む前の基本手順

Claude Codeに作業を依頼する前は、次の流れをおすすめします。

git status

まず、現在の変更状態を確認します。

git switch main

mainに移動します。

git pull

最新状態を取り込みます。

git switch -c feature/login-fix

作業用ブランチを作って移動します。

そのあとでClaude Codeに依頼します。

ログイン処理のバグを修正してください。
変更範囲はLoginController、UserDao、LoginDtoに限定してください。
修正後に変更したファイルと理由を説明してください。

ポイントは、作業ブランチを作ってからClaude Codeに依頼することです。

これだけで、AIの作業範囲をかなり管理しやすくなります。

ブランチ名は作業の目的がわかる名前にする

ブランチ名は、あとから見たときに意味がわかる名前にしましょう。

悪い例です。

test
new
work
aaa
claude

このような名前だと、何の作業かわかりません。

あとから自分で見ても困ります。

チームメンバーが見たら、もっと困ります。

良い例です。

feature/user-matching
fix/login-error
refactor/car-dao
test/recommendation-dao

良いブランチ名には、作業の目的が入っています。

ブランチ名は、作業につけるラベルです。

冷蔵庫のタッパーに「カレー」「サラダ」「明日の弁当」と書くのと同じです。

中身が何かわかるラベルを付けましょう。

ブランチを切るとレビューもしやすくなる

ブランチを分けると、レビューもしやすくなります。

レビューとは、コードの変更内容を人間が確認する作業です。

Claude Codeが作ったコードでも、最終確認は人間が行う必要があります。

作業ブランチに変更をまとめておくと、次のような確認がしやすくなります。

ブランチが作業単位で分かれていれば、「このブランチはログイン修正だけを見る」と決められます。

逆に、1つのブランチにログイン、検索、DAO整理、テスト追加が全部入っていると、レビューが大変です。

学校の先生が作文を添削するときに、作文、数学の宿題、英単語ノートが1冊に混ざっていたら大変ですよね。

作業を分けるだけで、確認はかなり楽になります。

失敗したブランチは捨てられる

ブランチを切る最大のメリットは、失敗したら捨てられることです。

Claude Codeに作業を頼んだものの、思った方向と違う修正になったとします。

そんなとき、作業ブランチならやり直しやすいです。

たとえば、feature/login-fixで作業していたとします。

内容がよくなければ、mainに戻ります。

git switch main

そして、不要なブランチを削除します。

git branch -D feature/login-fix

-Dは強制削除です。

使うときは、本当に消してよいブランチか確認してください。

ゴミ箱を空にするようなものです。

ただし、mainには影響していません。

だから安心して試せます。

この「失敗しても捨てられる」という安心感が、Claude Codeの生産性を上げます。

ブランチを切るとClaude Codeへの指示も具体的になる

ブランチを切ると、自分の頭の中でも作業目的が整理されます。

たとえば、ブランチ名をfeature/user-matchingにしたとします。

すると、Claude Codeへの指示も自然と具体的になります。

ユーザーマッチング機能を追加してください。
同じ商品にLIKEしたユーザーを1名取得するDAOを作成してください。
ServiceとREST APIは作成しないでください。
DTOを使用してください。

これは、かなり良い指示です。

目的、条件、作らないもの、必要なものが明確だからです。

一方で、ブランチ名がworkだと、作業目的もあいまいになりがちです。

あいまいな作業場所では、あいまいな指示を出しやすくなります。

Claude Codeに良い仕事をしてもらうには、人間側が作業の目的を整理する必要があります。

ブランチ名は、その整理に役立ちます。

1ブランチ1目的を意識する

新人エンジニアにおすすめしたい考え方は、1ブランチ1目的です。

1つのブランチには、1つの目的だけを入れます。

良い例です。

1ブランチ1目的にすると、Claude Codeへの依頼も小さくなります。

依頼が小さいと、AIの出力も確認しやすくなります。

確認しやすい変更は、安全にマージできます。

マージとは、作業ブランチの変更をmainなどの本線に取り込むことです。

たとえるなら、下書きでうまく書けた内容を、清書ノートに写すようなものです。

Claude Code作業用ブランチのおすすめ運用

Claude Codeを使うときは、次のような運用がわかりやすいです。

コマンドで書くと、次のような流れです。

git switch main
git pull
git switch -c feature/user-matching

ここでClaude Codeに作業を依頼します。

git status
git diff

変更内容を確認します。

git add .
git commit -m "同じ商品にLIKEしたユーザーを1名取得するDAOを追加"

問題なければコミットします。

この流れを守るだけで、AI開発の安全性はかなり上がります。

ブランチを切ることは面倒ではなく、未来の自分を助ける作業

最初は、ブランチを切るのが面倒に感じるかもしれません。

「少しだけ直すならmainでもいいのでは？」

「Claude Codeならすぐ直してくれるし、わざわざブランチを作らなくてもいいのでは？」

そう思う気持ちはわかります。

でも、少しだけの修正だと思っていた作業が、意外と大きくなることはよくあります。

Claude Codeに頼んだら、関連ファイルまで修正されることもあります。

そんなとき、ブランチを切っていれば安心です。

ブランチは、未来の自分を助けるメモ帳です。

「この作業はここで試している」

「mainはまだ安全なまま」

「失敗したらこのブランチを捨てればよい」

この状態を作れるだけで、かなり落ち着いてAIを使えます。

第4章のまとめ

Claude Codeに作業を任せるなら、mainブランチを直接触らせず、作業ブランチを切ることが大切です。

Gitのブランチは、作業の流れを分けるための仕組みです。git switchを使うとブランチを切り替えられ、-cを使うと新しいブランチを作成して移動できます。

一言でまとめるなら、こうです。

ブランチは、Claude Codeに安全に作業させるための実験部屋です。

mainという本番の部屋でいきなり実験するのではなく、作業ブランチという実験部屋で試す。

うまくいったらmainに取り込む。

失敗したらブランチごと捨てる。

この流れを覚えるだけで、Claude Codeをかなり安心して使えるようになります。

次章では、Claude Codeの成果物をgit diffで必ず確認する理由と、差分を見るときの具体的なポイントを解説します。

セイ・コンサルティング・グループでは新人エンジニア研修のアシスタント講師を募集しています。

投稿者プロフィール

山崎講師代表取締役

セイ・コンサルティング・グループ株式会社代表取締役。
岐阜県出身。
2000年創業、2004年会社設立。
IT企業向け人材育成研修歴業界歴20年以上。
すべての無駄を省いた費用対効果の高い「筋肉質」な研修を提供します！
この記事に間違い等ありましたらぜひお知らせください。

学生時代は趣味と実益を兼ねてリゾートバイトにいそしむ。長野県白馬村に始まり、志賀高原でのスキーインストラクター、沖縄石垣島、北海道トマム。高じてオーストラリアのゴールドコーストでツアーガイドなど。現在は野菜作りにはまっている。

最新の投稿

• 新人エンジニア研修講師2026年6月11日Claude Designとは何か？新人エンジニア向けにAI時代のデザイン作成をやさしく解説
• 新人エンジニア研修講師2026年6月11日Claude AIでできることベスト10と苦手なこと｜ChatGPT・Geminiとの違いも初心者向けに解説
• 新人エンジニア研修講師2026年6月11日Claude Coworkに任せると便利なことベスト10｜新人エンジニア向けに実務での使い方を解説
• 新人エンジニア研修講師2026年6月11日Claudeのサービスメニューを新人エンジニア向けに解説｜Claude Cowork・Claude Code・Claude.ai・APIの違い