includeGitInstructionsでGit指示の自動挿入を止める
settings.jsonのincludeGitInstructionsで組み込みのコミット/PR手順とgitステータスをシステムプロンプトから外す設定と、CLAUDE.mdでの置き換え方をまとめます。
Claude Codeは起動のたびに、コミット作成・PR作成の手順とgitのステータス情報をシステムプロンプトへ自動で組み込みます。includeGitInstructionsはこの挙動そのものを止める設定キーです。既定値はtrueで、falseにすると組み込みのgit手順とgitステータススナップショットの両方がプロンプトから消えます。独自のコミット規約やPRテンプレートをすでに持っているチームが、Claude側の既定動作と衝突させたくないときに使うキーです。既定のままgh pr createまで一連の流れとして任せる場合の手順とつまずきはClaude CodeでPRを作成する手順にまとめています。
includeGitInstructionsで何が変わるか
includeGitInstructionsがtrue(既定)のとき、Claude Codeはコミットメッセージの書き方・PR作成のワークフロー・現在のgitステータスをシステムプロンプトに含めます。ユーザーがCLAUDE.mdで独自の規約を書いていても、この組み込み手順は別枠として常に存在します。
falseに変更すると、組み込みのgit手順とgitステータススナップショットが両方とも取り除かれます。Claude Codeがgitコマンドを実行できなくなるわけではありません。 git commitやgit pushは引き続きBashツール経由で呼び出せます。変わるのは、Claude Codeが自分から差し出す「デフォルトのやり方」の有無だけです。
{
"includeGitInstructions": false
}環境変数との優先順位
同じ挙動を環境変数からも制御できます。CLAUDE_CODE_DISABLE_GIT_INSTRUCTIONSを設定すると、includeGitInstructionsの値より優先されます。
{
"env": {
"CLAUDE_CODE_DISABLE_GIT_INSTRUCTIONS": "1"
}
}CI環境やヘッドレス実行のように、settings.jsonを触らずにセッション単位で切り替えたい場面ではこちらが便利です。settings.json側でincludeGitInstructions: trueのままでも、環境変数が設定されていればgit指示は抑制されます。v2.1.78以前は、この環境変数とincludeGitInstructionsを同時に設定したときにgitステータス部分が消えないバグがありましたが、現行版ではどちらの経路でも両方が確実に外れます。
独自のGitワークフローに置き換える
includeGitInstructions: falseが最も効くのは、Claude Codeの既定手順をただ消すのではなく、自前の手順に置き換えたいときです。CLAUDE.mdは@path/to/fileという記法で外部ファイルをインポートでき、これを使うと組み込みのgit指示をそのまま独自ドキュメントに差し替えられます。
# Additional Instructions
- git workflow @docs/git-instructions.md.claude/settings.jsonでincludeGitInstructions: falseにしつつ、CLAUDE.mdに上記のようなインポート行を置けば、Claude Codeの既定のコミット/PR手順が消え、代わりにチームが管理するdocs/git-instructions.mdの内容だけが読み込まれます。コミットメッセージのプレフィックス規約やブランチ命名ルールが独自にあるチームでは、既定手順と自前ルールが両方読み込まれて混乱する事態を避けられます。docs/git-instructions.mdの中身自体は普通のMarkdownで、たとえば次のように書きます。
# Gitワークフロー規約
- コミットメッセージは `<type>: <日本語で簡潔に>` の形式(type は add/update/fix/refactor/docs から選ぶ)
- 本文2行目以降は箇条書きのみ、署名・フッターは付けない
- ブランチ名は `feat/yymmdd-短い説明` の形式で、必ず main から切るClaude Codeはこのファイルをインポート経由でそのまま読み込み、以後のコミット・PR作成でここに書かれた規約に従います。既定の指示文は完全に置き換わるため、Claude独自の言い回し(絵文字の付与や英語のコミットメッセージなど)と自前規約が混ざる心配がありません。
worktreeとモノレポでの扱い
includeGitInstructionsをプロジェクトの.claude/settings.local.jsonに書いた場合、その設定はリポジトリのworktree構成全体に及びます。Claude Codeはこのファイルをgitリポジトリのルート(メインのチェックアウト)から読み書きするため、同じリポジトリの別worktreeでセッションを開いても、設定は1つのファイルに集約されて共有されます。複数worktreeを行き来しながら作業するスタイルでは、worktreeごとに個別のオン/オフを持たせることはできない、という制約になります。モノレポで一部のパッケージだけ独自のgit運用をしたい場合は、includeGitInstructions自体をディレクトリ単位で切り替えるのではなく、CLAUDE.mdの階層構造(サブディレクトリごとのCLAUDE.md)側でワークフローの説明を書き分ける設計のほうが実情に合います。
ヘッドレス実行やCIでの扱い
-pフラグで動かすヘッドレスセッションやCIパイプラインでは、対話的なコミット手順の説明そのものが不要なことが多く、includeGitInstructions: falseまたはCLAUDE_CODE_DISABLE_GIT_INSTRUCTIONSを使う動機がはっきりしています。CIジョブはコミットメッセージの体裁よりも、決められたコマンドを決められた順序で実行することが優先されるため、Claude Code側の「デフォルトのやり方」を差し込まれる必要がありません。settings.jsonを変更する権限が無いパイプラインでも、ジョブ定義の環境変数にCLAUDE_CODE_DISABLE_GIT_INSTRUCTIONS=1を1行足すだけで同じ効果が得られます。システムプロンプトに含まれる情報が減る分、プロンプトはわずかに軽くなりますが、これを主目的にするほどの効果ではなく、あくまで「要らない指示を減らす」副次的な利点として捉えるのが妥当です。
いつfalseにするか
判断に迷ったときの目安です。
| 状況 | 推奨 | 理由 |
|---|---|---|
| コミット規約・PRテンプレートを独自に持っている | 推奨false + CLAUDE.mdで置き換え | 理由既定手順との重複・矛盾を避けられる |
| Conventional CommitsやAngular規約など外部標準に厳密に従いたい | 推奨false + 規約ドキュメントをインポート | 理由Claude独自の言い回しが規約と食い違うリスクを消せる |
| gitワークフローに特にこだわりがない | 推奨true(既定のまま) | 理由変更コストに見合うメリットが薄い |
| skillやプラグインで独自のgit操作を提供している | 推奨false | 理由既定指示とskillの手順が二重に競合しない |
よくあるつまずき
includeGitInstructions: falseにしたのにコミットメッセージの書き方が変わらない、という相談は、CLAUDE.mdへの置き換えを忘れているケースがほとんどです。既定の指示を消すだけでは「指示が何もない」状態になるだけで、望みの規約が自動で適用されるわけではありません。@docs/git-instructions.mdのようなインポートで明示的に渡す必要があります。
もう一つのつまずきは、includeGitInstructionsをfalseにすればgit関連の権限プロンプトも減ると誤解するケースです。このキーが触るのはシステムプロンプトの内容だけで、permissions.allow/permissions.denyによるBashコマンドの許可判定とは独立しています。git操作の確認プロンプトを減らしたい場合は、permissions側で個別に許可ルールを設計します。
関連設定との違い — attributionとkeep-coding-instructions
includeGitInstructionsとよく混同される設定が2つあります。1つ目はattributionです。役割はまったく別で、attributionはClaude Codeがコミットメッセージの末尾やPR本文に付ける署名(既定では「🤖 Generated with Claude Code」のようなトレーラー)を制御するキーです。commitとprをそれぞれ空文字にすると署名自体を消せます。
{
"attribution": {
"commit": "",
"pr": ""
}
}includeGitInstructions: falseにしても、この署名は自動では消えません。消えるのはシステムプロンプトに含まれる「コミットの書き方・PRの作り方・現在のgitステータス」という指示文のほうで、生成後のコミットに付く署名のフォーマットは別レイヤーのattributionが管轄します。署名だけ消したいのか、指示文ごと止めたいのかで、触るキーが変わる点を覚えておくと設定ミスを防げます。
2つ目はカスタムoutput styleのkeep-coding-instructionsフロントマターです。こちらは変更範囲の絞り方・コメントの書き方・検証手順といった、ソフトウェアエンジニアリング全般の組み込み指示を残すかどうかを切り替えるトグルで、既定はfalse(外す)です。対象にしている指示の範囲がincludeGitInstructions(コミット/PR手順とgitステータスに限定)より広く、両者は別のレイヤーで独立して効きます。カスタムoutput styleに切り替えたからといってgitの組み込み指示が自動で消えるわけではなく、逆にincludeGitInstructions: falseにしてもエンジニアリング全般の指示は残ります。
よくある質問
hooksでgit commit時の処理を自動化している場合、includeGitInstructionsとは役割が重なりますか
重なりません。hooksはBashコマンドの実行前後にスクリプトを挟む仕組みで、includeGitInstructionsはシステムプロンプトに含まれる指示文を制御する仕組みです。層が違うため両方を組み合わせても衝突は起きません。たとえばPreToolUseフックでコミットメッセージの体裁を機械的にチェックしつつ、includeGitInstructions: falseで指示文自体は自前のCLAUDE.mdに任せる、という併用もできます。
managed settingsでincludeGitInstructionsを配布してチーム全体を統一できますか
はい。includeGitInstructionsはセキュリティ関連の特別なキーではなく、通常の優先順位に従う設定なので、managed settingsで配布すればユーザー設定やプロジェクト設定より優先させられます。ただし個人の作業スタイルに近い設定のため、組織全体で強制する必要があるかどうかはチームの合意を取ってから判断するのが安全です。
ホームディレクトリに置いた個人用のGitワークフローファイルを@でインポートしても安全ですか
プロジェクトのCLAUDE.mdから@~/.claude/git-instructions.mdのように作業ディレクトリの外を指すインポートを書くと、それは「外部インポート」として扱われ、Claude Codeは初回に承認ダイアログを1度だけ表示します。承認すると以後は自動で読み込まれます。同じ内容をリポジトリ内のdocs/git-instructions.mdに置いてインポートする場合はこのダイアログは出ません。
過去のコミットメッセージやPRの本文にも影響しますか
影響しません。includeGitInstructionsはセッション開始時にシステムプロンプトへ渡す指示文を制御するだけで、すでに作成済みのコミットやPRの説明文を書き換えることはありません。設定を変更した後にClaude Codeが新しく生成するコミット・PRからだけ挙動が変わります。
まとめ
includeGitInstructionsは既定trueで、falseにすると組み込みのコミット/PR手順とgitステータススナップショットがシステムプロンプトから消えます。git実行そのものは止まりません。環境変数CLAUDE_CODE_DISABLE_GIT_INSTRUCTIONSはこの設定より優先されるため、CI等で一時的に切り替えたいときはそちらを使います。コミットの署名を消したいだけなら、触るキーはincludeGitInstructionsではなくattributionです。独自のgitワークフローを持つチームは、falseにした上でCLAUDE.mdの@インポートで自前ドキュメントを読み込ませると、既定手順との重複を避けられます。settings.jsonの他のキーの全体像はClaude Code設定ガイド、CLAUDE.md自体の設計パターンはClaude CodeのCLAUDE.mdを実用に引き上げる10のパターンを参照してください。