← Reports へ戻る

AIコーディング時代のGit運用ルール

Published 2026年6月22日
Author AI Media Lab
Category ai-technology

AI開発では、コードを書く力だけでなく、変更を追跡し差分を理解し戻せる状態を保つGit運用が重要です。実務的なルールと指示パターンを解説。

AIコーディング時代のGit運用ルール

はじめに

Claude Codeなどのコーディングアシスタントを使うと、コード生成速度は劇的に向上します。しかし速度が上がるほど、差分管理の重要性が高まるというのは、多くの開発者が見落とします。

AIが複数ファイルを短時間で変更するからこそ、「何が変わったのか」「どうやって戻すのか」を明確にするGit運用が必須になります。Claude Codeの基本ガイドでは安全なプロンプト作成を紹介しました。本記事では、その次のレイヤー——Git運用の実務的なルール——を解説します。

AI時代ほどGit運用が重要になる理由

変更のスピードと複雑さの増加

従来の開発では、1つのタスクに1時間かかっていたかもしれません。結果、人間の目で次のファイルへ移る前に現在のファイルの変更を確認できました。

AIアシスタントは、その1時間を5分で完了させます。複数ファイル、複数モジュール、設定変更を一度に行うことが珍しくなくなります。

従来の開発：　変更1 → (人間確認) → 変更2 → (人間確認) → ...
AI支援開発：　変更1,2,3,4,5が一気に出来上がり → (大量確認)

「戻す」の重要性

変更が多いほど、失敗時の影響が大きくなります。Gitなしに、手作業で5個の変更を戻すことは、ほぼ不可能です。

Gitがあれば、git revert か git restore の1コマンドで、確実に戻せます。この「戻せる安心感」こそが、AIアシスタントを効果的に活用するための前提条件です。

ルール1: 1タスク1ブランチにする

タスクごとに独立したブランチを作ります。

# ❌ 悪い例：mainで直接作業
git checkout main
# ... Claude Codeで複数の変更

# ✅ 良い例：タスクごとにブランチ作成
git checkout -b feature/add-user-auth
# Claude Codeで変更
git checkout -b fix/optimize-database-query
# Claude Codeで変更

理由：ブランチを分けると、1つのタスクの全変更が視覚的に明確になり、失敗時も該当ブランチだけを破棄できます。

ルール2: AIに触らせる前にgit statusを見る

AIに指示を出す前に、現在の状態を記録します。

git status --short

出力例：

M  src/auth.py
?? tests/temp.log

この出力を指示に含めることで、「AIがこの状態から何を変更するのか」が明確になります。

「現在のgit statusは上記の通りです。
tests/temp.logは無視してください。
src/auth.pyのみ変更してください。」

ルール3: 変更前に方針をコミットやメモで残す

Claude Codeに指示を出す前に、自分の変更方針を明文化してcommitしておきます。

# 変更前の状態を記録
echo "Task: Refactor database access layer
Plan:
  1. Extract connection pooling
  2. Simplify query builder
  3. Add connection timeout" > .task-memo

git add .task-memo
git commit -m "Task memo: Database refactoring plan"

理由：後で「何を意図していたのか」を思い出すときに、このメモが役立ちます。実装を確認するときの基準になります。

ルール4: 1回の変更を小さくする

「全部作ってください」ではなく、小さなステップで進めます。

❌ 「ユーザー認証システム全体を実装してください」

✅ 「ステップ1：ユーザー登録フォームだけ実装してください」
   (確認 → コミット)

✅ 「ステップ2：パスワード検証ロジックを追加してください」
   (確認 → コミット)

✅ 「ステップ3：ログイン機能を追加してください」
   (確認 → コミット)

小さい変更ほど、レビューが簡単で、何か間違っていても対象範囲が小さく、戻すのも簡単です。

ルール5: git diffを読んでから次へ進む

Claude Codeが変更を完了したら、絶対に実装を確認します。

# 全体の変更を確認
git diff

# ファイル別統計を確認
git diff --stat

# 変更されたファイル名のみ確認
git diff --name-only

# 特定ファイルだけ詳しく確認
git diff src/specific-file.py

確認チェックリスト：

ルール6: AI生成コードをすぐmainへ入れない

変更をテストしてから、mainにマージします。

# ブランチで変更実装
git checkout -b feature/new-endpoint
# Claude Codeで実装
git commit -m "Add new API endpoint"

# テスト実行
npm test

# 全て確認できたら、mainにマージ
git checkout main
git merge feature/new-endpoint

理由：万が一問題が見つかっても、ブランチを削除すれば、mainは影響を受けません。

ルール7: 戻し方を決めてから進める

変更を進める前に「失敗時はどう戻すか」を知っておきます。

# ステージ前の状態に戻す
git restore <file>

# ステージ後の状態に戻す
git restore --staged <file>

# コミット後の状態に戻す
git revert <commit-hash>

重要：git reset --hard や git clean -fd などの破壊的コマンドは、個人開発でも習慣づけない。習慣づくと、チーム開発で誤ったときに、大きな問題になります。

個人開発でのおすすめGit運用フロー

8ステップ推奨ワークフロー

1. タスク定義
   └─ Issue や TODO コメントに「何をするのか」を書く

2. ブランチ作成
   └─ git checkout -b feature/clear-name

3. Claude Codeに変更計画を出させる
   └─ 「変更計画だけ出してください。実装はまだ」

4. 計画を確認
   └─ 対象ファイル、変更順序が自分の意図通りか

5. 実装をさせる
   └─ 「この計画で実装してください」

6. git diff をレビュー
   └─ 想定外の変更がないか確認

7. テスト実行
   └─ npm test など、確認コマンド実行

8. コミット
   └─ 確認完了後、git commit

そのまま使えるClaude Code指示例

危険な指示（変更範囲不明確）

❌ 「この機能を全部作って」
❌ 「エラーを直して」
❌ 「テストが通るように全部修正して」
❌ 「いい感じに整理して」

これらの指示では、AIが「何をどこまで変更すべきか」を判断する必要があり、あなたの意図と異なる変更になる可能性が高いです。

より安全な指示

✅ 「まず変更計画だけ出してください。まだ実装しないでください。
対象ファイルと各ステップを明確に説明してください。」

✅ 「変更対象ファイル：src/foo.py のみです。
他のファイルは触らないでください。
実装前に対象範囲を確認してください。」

✅ 「修正後に以下を実行してください：
  - git diff --stat （統計を出力）
  - git diff --name-only （変更ファイル一覧を出力）

変更ファイルリストを確認してから、テストを実行してください。」

✅ 「修正前に、変更が必要なファイルをリストアップしてください。
実装は、そのリストを確認してからお願いします。」

よくある落とし穴と対策

落とし穴1: テストが通った = 完璧

テストが成功しても、次の問題がある可能性があります：

対策：git diff で視覚的に確認する。テストだけに頼らない。

落とし穴2: ブランチなしで作業

mainブランチで直接AIに変更させると、失敗時に戻すのが困難になります。

対策：常にブランチを作る。確認後にマージする。

落とし穴3: 複数タスクを同時実行

❌ 「ユーザー認証とメール送信を全部実装して」

✅ 「ステップ1：ユーザー認証を実装」
✅ 「ステップ2：メール送信を実装」

同時実行すると、どの変更がどのタスク用か、追跡が困難になります。

まとめ

AIコーディングの時代では、「コードを速く書く力」だけでなく、「変更を追跡し、差分を理解し、戻せる状態を保つ力」が競争力になります。

Git運用の基本：

Claude Codeの使い方と組み合わせることで、個人開発から小規模チーム開発まで、安全で効率的なAI支援開発を実現できます。

GitAI開発Claude Code開発ワークフロー