AI Agent に任せていい操作・人間が確認すべき操作の境界
学習目標
このレッスンを終えると、次のことができるようになります。
- AI Agent に任せていい Git/GitHub 操作を 5 つ挙げられる
- 人間が必ず最終確認すべき操作 (破壊的・公開系) を判別できる
- AI に対して「やってはいけない」を明示する方法 (ガードレール) を理解できる
信頼の境界線
AI Agent は速いが、戻せない操作や他人に影響を与える操作で失敗するとダメージが大きい。可逆性 (元に戻せるか) と公開度 (他人に影響するか) で区切るのが分かりやすい。
quadrantChart
title 信頼境界 — AI に任せていい / 人間が見るべき
x-axis 可逆 (取り消せる) --> 不可逆 (戻せない)
y-axis ローカル (自分だけ) --> 公開 (他人に影響)
quadrant-1 "AI 任せ可"
quadrant-2 "人間が確認"
quadrant-3 "AI 任せ可"
quadrant-4 "人間が必須"
"git add": [0.2, 0.2]
"git commit": [0.3, 0.3]
"git branch 作成": [0.2, 0.4]
"git push (新規ブランチ)": [0.4, 0.7]
"git push --force": [0.85, 0.85]
"git reset --hard": [0.85, 0.3]
"main に直接 push": [0.9, 0.9]
"Pull Request 作成": [0.5, 0.7]
"Pull Request の merge": [0.7, 0.9]
"branch 削除": [0.7, 0.5]
AI 任せでよい操作 (低リスク)
これらは AI Agent が自律的にやって OK:
git status— 状態確認 (読み取りのみ)git add— 変更をステージング (まだコミットしてない)git commit— ローカルに変更を保存 (リモートにはまだ反映されない)git branch <名前>— 新しい枝を作る (既存に影響しない)git checkout <既存ブランチ>— ブランチ移動 (未コミット変更がない場合)
人間が確認すべき操作 (中リスク)
実行前に AI が「これでよいか」確認すべき:
| 操作 | なぜ確認必要 | 確認ポイント |
|---|---|---|
git push origin <ブランチ> |
他人が見えるリモートに送信 | ブランチ名は正しいか、機密情報を含まないか |
| Pull Request 作成 | 他人のレビュー対象になる | タイトル・説明・関連 Issue は妥当か |
git merge <ブランチ> |
履歴が結合される | 取り込んでよい変更か、コンフリクトがないか |
git branch -d <ブランチ> |
ブランチ削除 (merge 済みのみ可) | そのブランチの作業が本当に完了しているか |
人間が必須の操作 (高リスク・破壊的)
AI Agent が単独でやってはいけない:
| 操作 | 何が起きるか | 安全な代替 |
|---|---|---|
git push --force |
リモートの履歴を上書き。他人の作業が消える可能性 | --force-with-lease を使うか、人間が手動実行 |
git reset --hard |
未コミットの変更が完全消去。Ctrl+Z 不能 | git stash でいったん退避 |
git branch -D <ブランチ> (大文字) |
未 merge ブランチも強制削除 | merge 確認後に -d (小文字) で |
main ブランチに直接 push |
レビューなしで本番反映の危険 | ブランチを切って Pull Request 経由で |
| 本番タグの削除・付け替え | リリース履歴の改竄 | 新しいタグを作る方を選ぶ |
AI に「やってはいけない」を伝える方法 (ガードレール)
ailms プロジェクトでは ~/.claude/CLAUDE.md (グローバル) と CLAUDE.md (プロジェクト) に AI への指示が書かれている。Git 関連の代表的なルール:
- 破壊的操作 (DELETE/DROP/rm -rf/push --force/本番デプロイ/DB変更) は
人間の承認後に実行
- `git push` も毎回人間の明示承認後に実行
- NEVER skip hooks (--no-verify) 等を使わない
- NEVER 既存コミットを amend しない (新規 commit を作る)
このように「やってはいけない」を文章で明示すると AI が誤操作を避けてくれる。書かないと AI は「やっていい」と判断する。
ガードレールが破られないようにする仕組み
文章のルールは AI が読み飛ばすことがある。機械的に止める仕組み (Hook) を併用するのが ailms の方針:
flowchart LR
AI[AI Agent が<br/>git push --force を発火] --> H[git pre-push Hook<br/>scripts/git-hooks/]
H -->|禁止パターン検出| B[ブロック<br/>+ 警告メッセージ]
H -->|OK| P[push 実行]
参考: ailms の scripts/git-hooks/install.sh を確認すると、実際のフックの中身が読める。
振り返り
- 信頼境界は 「可逆性 × 公開度」 の 4 象限で考える
- 破壊的・公開系は人間が必須。
push --force/reset --hard/main直 push は AI 任せ厳禁 - 「やってはいけない」は CLAUDE.md に文章化 + Hook で機械的にブロック (二重防御)
次のセクションから、Git の基本概念 (リポジトリ・commit・staging) を CLI で実際に動かして学びます。
参考リンク
- Pro Git「サーバ上の Git - フックを使ったポリシーを徹底する」: https://git-scm.com/book/ja/v2/サーバー上の-Git-フックを使ったポリシーを徹底する
- GitHub Docs「ブランチ保護ルール」: https://docs.github.com/ja/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
全 14 レッスンを、登録なしで無料で読めます。