「コミットまでは任せていいと思うんです。ただ、その先が怖くて」。Claude Codeにgitの操作を渡す話をしていると、この言い方をよく聞きます。
差分を読ませて、コミットメッセージを書かせるところまでは、たいていの人が抵抗なく進みます。手が止まるのは、その成果を外へ出す瞬間です。出てしまったものは、あとから気づいても戻りません。
この記事は、コミットと外部共有のあいだに引かれた境界を扱います。素材は2026-08-03時点のClaude Code公式ドキュメントと、WEBMARKS社内の設定ファイル・フックの実物です。
こんなふうに調べていませんか
- gitの操作をAIに渡したいが、どこまで任せてよいかの線が引けない
- 設定ファイルにルールは書いた。ただ、それで止まっているのかを確かめていない
- 止める仕組みが複数あると聞いたが、どれが何を担当しているのか分からない
この記事を読み終えたときに手に入るもの
- コミットまでと外部共有からを、任せる境界として線引きできるようになります
- 許可設定・PreToolUseフック・権限モードのどれが何を止めているかを読み分けられます
- 引いた境界が効いているかを、自分の手で確かめる手順が手に入ります
結論30秒でわかる、この記事の結論
- 境界はコミットと外部共有のあいだにあります。手元に記録するところまでは任せ、外へ出す操作から人が決めます。
- 止める仕組みは許可設定・PreToolUseフック・権限モードの3層で、得意なことと弱点が層ごとに違います。
- 1か所で止めた気になるのが危ういところです。書き方を変えられると、文字の一致で見る網は抜けます。
進行役は3人です。高梨課長が自分の手で動かす側から聞き、大森部長が体制の側から聞き、鈴木さん（本誌監修）が答えます。
01Claude Codeのgitコミットは、AIエージェントにどこまで任せていいんですか？
高梨課長gitの操作をAIに渡すとして、どこまでなら任せてよいのでしょうか。
鈴木さん机の引き出しにしまうところまで、と考えています。しまうだけなら開け直せますが、ポストに投函したあとは取り戻せませんよね。
持ち帰っていただきたいのは3点です。
- 差分の確認とコミットメッセージの作成、そして手元へのコミットまでは任せられます。読み取り専用のgit操作は、確認を挟まずに動きます（出典: Claude Code公式ドキュメント）。
- 外部へ共有する操作は境界の外側です。WEBMARKS社内では、設定ファイルの許可設定とPreToolUseフックという性質の異なる2つの仕組みが、別々の理由でこれを止めています（2026-08-03実測）。
- 境界は1か所ではなく複数箇所に置きます。どれか1つがコマンドの書き方の工夫で素通りしても、別の層が拾えるようにするためです。
Claude Code公式ドキュメントは、ワイルドカードによる制限を「壊れやすい」と明記しています。設定を1行書いたから止まっている、という読み方をしないでください。
たとえに置き直すと、箇条書きでは見えにくいものが1つ見えます。分かれ目は操作の危なさではなく、そのあとに残される選択肢の数だということです。
手元に記録した状態には、まだ選択肢が残っています。書き直す、やめる、まとめ直す。外へ出したあとは、相手の側にも複製が残るため、こちらの都合だけでは選び直せません。任せてよいかどうかは、コマンドの名前ではなく、実行後に自分の手に何が残るかで決まります。
02コミットを任せる前に、AI導入の側で何を見ておくんですか？
Claude Codeがコミットと外部共有をどう扱うかは、3つの独立した仕組みが決めます。設定ファイルの許可設定、PreToolUseフック、権限モードです。3つは重なって効くため、どれか1つだけを見ても全体は分かりません。
| 層 | 効く場所 | 得意なこと | 弱点 |
|---|---|---|---|
| ①許可設定 | .claude/settings.jsonのpermissions | コマンド文字列のパターン一致で即座に判定する | ワイルドカードは変数や別表記で迂回されやすい（出典: Claude Code公式ドキュメント） |
| ②PreToolUseフック | .claude/hooks/配下のスクリプト | 任意のコードでコマンドを再検査できる | 書いたルール以上には賢くならない |
| ③権限モード | defaultMode（plan・bypassPermissions等） | ルールに一致しなかった残りの挙動を一括で決める | bypassPermissionsは.gitへの書き込みも確認なしで通す（出典: 同） |
この記事の検証環境は2つあります。1つはClaude Code公式ドキュメント（2026-08-03時点の記載）です。もう1つはWEBMARKS社内の.claude/settings.jsonとbash-guard.pyで、2026-08-03に中身を確認しました。以降は「公式の仕様」と「WEBMARKSの実装」を区別して示します。
もう1つ、置き場所の話をしておきます。Claude Codeは「今後は聞かない」という承認を.claude/settings.local.jsonへ保存します。この保存先は、git worktree内であっても元のチェックアウトに固定されます（出典: Claude Code公式ドキュメント）。WEBMARKSのフック登録もVaultの絶対パスを使うため、2026-08-03に確認した限り、どのworktreeから起動しても同じ実体が動作します。
積んで描くと、表の並びとは別の関係が見えます。覆う広さと止める強さは逆を向くということです。
権限モードは、ルールに書き漏らした操作まで含めて全体の既定を決めます。ただし個別の判断はできません。フックはいちばん上にあり、覆えるのはツール呼び出しという限られた経路だけです。そのかわり、その経路については実行の直前に割り込めます。だから3層は選ぶものではなく、重ねるものです。
この章のまとめ
3層は択一ではありません。下ほど広く覆い、上ほど強く止まる。重ねて初めて穴がふさがります。
03Claude Codeのgitコミットと共有操作で、AIエージェントはどこで判定されるんですか？
大森部長同じ仕組みを二重に持つのは、体制としてむだではないですか。
鈴木さん別々の理由で置いているので、むだにはなっていません。片方は書式で弾く役、もう片方は書き方を変えられても拾う役です。役どころが違います。
Claude Code公式ドキュメントは、npmとgit commitを許可しつつgit pushを拒否する設定例を示しています（出典: Claude Code公式ドキュメント）。
{
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git commit *)",
"Bash(git * main)"
],
"deny": [
"Bash(git push *)"
]
}
}WEBMARKSの.claude/settings.jsonは、この公式例よりさらに細かく分けています。2026-08-03に確認した実際の抜粋です。
{
"permissions": {
"deny": [
"Bash(git push --force*)",
"Bash(git push -f*)",
"Bash(git reset --hard*)"
],
"ask": [
"Bash(git push*)",
"Bash(git clean*)"
]
}
}宣言の上では、通常のpushはask、force付きのpushとreset --hardはdenyに分かれています。ただし、pushはPreToolUseフックの捕捉網にも掛かっており、許可設定のask評価より先に発火して確認なしで拒否します（出典: Claude Code公式ドキュメント）。そのためpushはforceの有無を問わず確認すら出ずに止まり、settings.jsonのaskルールは、フックが外れた場合の予備として働きます。reset --hardは、外部共有ではなく手元の喪失を止めるという、pushとは別の理由でdenyに置かれています。
04AI社員に渡すgitのコミット周りは、どれが許可でどれが拒否なんですか？
宣言と実際の挙動を、操作ごとに並べたものが次の一覧です。2026-08-03時点のWEBMARKSの分類です。
| Git操作 | WEBMARKSの分類（2026-08-03時点） | 止めている層 |
|---|---|---|
git log git diff git status | 組み込みの読み取り専用として常に許可 | 権限設定（Claude Code標準機能） |
git add <ファイル名> | 許可（個別指定） | 権限設定 |
git add -A git add --all | 拒否 | PreToolUseフック |
git commit -m "..." | 許可 | 権限設定 |
git push | 確認すら出さず拒否 | PreToolUseフック（設定のaskより先に発火するため） |
git push --force git push -f | 確認すら出さず拒否 | 権限設定（deny）＋PreToolUseフックの二重 |
git reset --hard | 確認すら出さず拒否 | 権限設定（deny） |
git clean | 確認を要求 | 権限設定（ask） |
2軸に置き直すと、一覧では並んで見えたものが分かれます。同じ「拒否」でも、止めている理由が2種類あるということです。
外へ出るから止めるものと、手元のものが消えるから止めるものは、別の心配ごとです。前者は相手側に残る複製の話、後者は復元の手立てが絶たれる話でした。理由が違えば、緩めてよいかの判断も別々に下すことになります。一覧の見た目だけで「危険な操作」とひとくくりにすると、この違いが消えます。
この章のまとめ
分類表は「どこで止まるか」を教えます。「なぜ止めているか」は、軸に置き直さないと見えません。
05コミットの先に置いた3層目は、AI社員が回り道しても効くんですか？
高梨課長書き方を変えれば通ってしまうものなのでしょうか。手元で試すときに気になります。
鈴木さん文字の一致だけで見ていると、そうなります。だからうちでは、その先にコードで読み直す層を1つ足しています。
設定ファイルのask・denyは、コマンド文字列のパターン一致で判定します。公式ドキュメントは、この方式の限界をcurlの例で説明しています。Bash(curl http://github.com/ *)というルールは、複数の書き方で素通りします。オプションの位置やプロトコルを変える、URLを変数に入れる、といった書き換えです（出典: Claude Code公式ドキュメント）。
git pushも同じ弱点を持ちます。そこでWEBMARKSは許可設定に加え、.claude/hooks/bash-guard.pyというPreToolUseフックをBash全体に登録し、コマンドをコードで読み直します。フックはツール実行の直前に発火し、標準エラーへ書いた内容がそのままClaudeへのエラーメッセージとして返ります（出典: Claude Code公式ドキュメント）。フックの登録方法そのものはClaude CodeのPreToolUseで危険コマンドを遮断する4つの判定で扱っています。
2026-08-03にこのフックのソースコードを確認したところ、pushの検知は素朴な文字列一致ではありませんでした。直接実行、シェル経由の間接実行、変数へ代入してからの実行という3通りを、別々の正規表現で拾います。最後に、gitという語のあとにpushという語が現れる組み合わせ全体を拾う網も張っています。コード中のコメントは、理由をこう記しています。
pushは方式を問わず人間専権。forceだけを拒否すると通常pushが外部送出の抜け道になる。
経路を並べて分かるのは、この層が「書き方の種類」ではなく「語の並び」を見ているという点です。書き換えの手口を数え上げて塞ぐ設計だと、思いつかなかった手口が残ります。最後の網は、その取りこぼしを引き受けるために置かれています。
06gitコミットより手前の一括ステージングを、生成AIに任せないのはなぜですか？
同じフックは、コミットより手前の段階も制限します。git add -Aとgit add --allは、対象を個別に指定せず一括で拾うという理由で拒否されます（2026-08-03確認）。
外へ出す操作ではないのに止めるのは、コミットの中身が申告と食い違うのを避けるためです。差分を確認してからコミットするという運用は、確認した範囲とコミットした範囲が同じであることを前提にしています。一括で拾う書き方は、その前提を静かに崩します。
対比してみると、違いは手間の多さではないことが分かります。名指しした側は範囲が申告されていて、まとめて拾う側は申告がないという違いです。
範囲が申告されていれば、意図と結果をあとから突き合わせられます。申告がなければ、入れるつもりのなかったものが混ざったかどうかを、コミットの中身からしか判断できません。差分確認からのコミットという運用は、外へ出す手前だけでなく、ステージングの範囲にも境界を持っています。
この章のまとめ
一括ステージングを止めるのは、危ないからではありません。あとで意図と結果を照らし合わせられなくなるからです。
07AIエージェントに任せるとき、gitのコミット操作でつまずくのはどんな場面ですか？
つまずき1：広いallowルールが、外へ出す操作まで拾ってしまう。公式ドキュメントの設定例はgit commit *を許可しgit push *を拒否しますが、git * mainという別の許可ルールも並んでいます。ワイルドカードは空白をまたいで一致します。つまりgit * mainは、git checkout mainだけでなくgit push origin mainにも一致します（出典: 同）。
deny側が先に評価される設計のおかげで実害は出ませんが、順序を無視して「広いallowを書いてあるから安全」と思い込むのは危うい読み方です。許可ルールの評価順序やdefaultModeの全体像はClaude Codeの権限設定｜AIエージェントに任せる範囲と3列の配分が扱います。
08フックの絞り込みは、AIエージェントのコミット運用でどちらを選ぶんですか？
Claude Code公式ドキュメントには、フックをより狭く絞り込むifフィールドという仕組みもあります。
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"if": "Bash(git push*)",
"command": "<フックスクリプトのパス>"
}
]
}ifは権限ルールと同じ書式で絞り込めます（出典: Claude Code公式ドキュメント）。WEBMARKSが正規表現のコードを選んだのは、この書式もパターン一致である以上、迂回の弱点をそのまま引き継ぐと判断したためです。
左右を見比べると、選択の理由が見えてきます。書式で絞る側は、絞り込むほど守備範囲も狭くなるという性質を持っています。
ifで対象を絞れば、フックが呼ばれる回数は減ります。ただし絞り込みの記法自体がパターン一致なので、そこで漏れたコマンドはフックに届きません。速さと網の広さのどちらを取るかという判断になります。
09コミットメッセージの言葉づかいで、AI活用が止まることはあるんですか？
高梨課長止まりすぎて困ることはないのでしょうか。実際に手を動かすと、そこが気になります。
鈴木さんあります。うちの場合は、コミットメッセージの文言だけで止まりました。困る種類の止まり方です。
つまずき2：コミットメッセージに「push」と書くだけでブロックされる。本記事の検証で、実際には外部へ送り出さない次のコマンドを試しました。
git commit --dry-run -m "docs: improve push notification copy in settings"このコマンドはpushを実行しませんが、bash-guard.pyのpushブロックが発火しました（2026-08-03実測）。メッセージから「push」という語を抜いた同じ形のコマンドは、問題なく通りました。
前後で変わったのは、実行される処理ではありません。入れ替わったのは文字列だけで、外へ出ていくものはどちらにも無かったという点です。
gitのあとにpushという語が現れるかどうかで判定する設計は、無害な文言も巻き込みます。これは前章で見た「最後の網」の裏側です。取りこぼしを減らすほど、巻き込みは増えます。どちらを厚くするかは設計の判断であり、WEBMARKSは取りこぼしを減らす側を選んでいます。
この章のまとめ
止め方を強くすると、止めなくてよいものまで止まります。どちらの失敗も、記録して初めて調整できます。
10Claude Codeの権限モードを緩めたら、AIエージェントのgitコミットの先まで通るんですか？
大森部長権限モードを緩めれば、確認の回数は減らせるのですよね。運用としてはそちらが楽です。
鈴木さん減ります。ただ、askに明示した分は減りません。そこは緩めても残る設計になっています。
つまずき3：bypassPermissionsモードなら全部通ると誤解する。このモードは.gitへの書き込みを含む多くの確認を省略しますが、askに明示したルールは省略の対象外です（出典: Claude Code公式ドキュメント）。
WEBMARKSのgit push*はaskに置かれているため、このモードを選んでも確認は残ります。加えて、PreToolUseフックはモードの外側で発火するので、こちらも生きています。緩めたつもりで境界が消えていないのは、緩める対象と、緩まない対象が最初から分かれているからです。
裏を返すと、モードを緩めて確認が消えた操作は、どの層にも明示されていなかった操作です。モードは書き漏らしを一括で拾う受け皿なので、緩めて何が変わったかを見ることは、書き漏らしの一覧を見るのと同じ意味を持ちます。
11gitのコミットと外部共有の境界が効いているか、AI導入の現場ではどう確かめるんですか？
設定を書いたら、実際に動かして境界が機能しているかを確かめます。書いた事実と、動いている事実は別に数えてください。
まず/permissionsを実行し、git関連のルールがdeny・ask・許可のどこに表示されるかを見ます。次に、変更のあるファイルでコミットを指示し、確認を挟まずに手元のコミットが成立するかを見ます。続けてpushを指示し、確認ダイアログ、またはフックのブロックメッセージが出るかを見ます。最後にforce付きのpush相当を指示し、確認すら出ずに拒否されるかを見ます。
4項目とも期待どおりなら、コミットと外部共有の境界は、この記事の内容どおりに機能しています。3番目で確認もブロックも出ない場合は、askルールの記法か、フックの登録先パスがVaultの実体を指しているかを見直してください。
なお、この確認はコミットまでを止める話ではありません。読み取り専用のgit操作と、個別に指定したコミットは、確認なしで通るのが期待どおりです。止まらないことの確認も、同じ回数だけ行ってください。Claude Codeの使い分け全体の地図はClaude Codeの業務活用｜任せる仕事の地図と判断軸4つにまとめています。
12よくある質問
コミットメッセージの作成もAIに任せてよいですか
任せられます。差分を読んでコミットメッセージを作成し、手元へコミットするところまでは境界の内側です。外部への共有に関わる操作からは、人が判断します。メッセージの文面そのものは、あとから書き直せる範囲に残っているという点も、判断材料になります。
force pushでなければ確認なしで通りますか
通りません。設定ファイルのaskルールとは別に、PreToolUseフックがpushをツール実行の直前に検知して、確認なしで拒否します。そのためforce付きでなくても確認は出ません。確認が出ずに止まるのは、forceの有無を問わずpush全般です。
bypassPermissionsモードを使えばpushも自動化できますか
できません。このモードは多くの確認を省略しますが、askに明示したルールは省略されません（出典: Claude Code公式ドキュメント）。pushの確認は残ります。加えて、PreToolUseフックはモードとは別の層で発火するため、こちらも同じように残ります。
コミット前のdiff確認は、AIに何をさせればよいですか
ステージング前にgit diffとgit statusを読ませ、変更したファイルの一覧と差分を人が読める形で示させます。そのうえで、個別のファイル名を指定してコミット対象を絞り込ませます。範囲を無申告で広げないための、実務上のポイントです。
git add -Aまで止めるのは、少しやりすぎではないですか
外へ出す操作ではないので、そう感じるのは自然です。それでも止めているのは、確認した範囲とコミットした範囲を一致させるためです。一括で拾う書き方だと、確認していないものが混ざったかを、あとから区別できなくなります。個別に指定する手間は、その区別を残すための費用です。
13まとめ｜今日やる3つのこと
境界は、コマンドの危なさではなく、実行後に自分の手へ何が残るかで引きました。止め方は択一ではなく、重ねるものでした。そして、書いた設定は発火させるまで、効いているかどうか分からないままです。
今日この順で手をつけます
/permissionsを開いて、git関連のルールがどこに表示されるかを見るいま何が名指しされているかが、線引きの出発点になります
コミットを指示して、確認なしで成立するところまでを確かめる
止まらないことの確認を先に済ませます
そのまま外へ出す操作を指示して、止まる画面を見る
止まった画面を見て、はじめて設定が壁になります
AI検索では、こう聞かれています
Claude Codeのgitコミットは、AIエージェントにどこまで任せていいんですか？
「Claude Codeのgitコミットは、AIエージェントにどこまで任せていいんですか？」の章で線引きを扱っています
コミットは通るのに、その先だけ止まるのはなぜですか？
「Claude Codeのgitコミットと共有操作で、AIエージェントはどこで判定されるんですか？」の章で説明しています
権限モードを緩めれば、gitの操作は全部通るんですか？
「Claude Codeの権限モードを緩めたら、AIエージェントのgitコミットの先まで通るんですか？」の章にあります
引いた境界が効いているか、どう確かめるんですか？
「gitのコミットと外部共有の境界が効いているか、AI導入の現場ではどう確かめるんですか？」の章に手順があります
次に読むなら、この記事です
