なぜコマンドの一番前や一番後ろに*を置くのは通常問題ないのに、真ん中(サブコマンドの前)に置くと特に間違いやすいのか?
鍵となるのはサブコマンドの位置だ。Bash(npm run )という書き方を例に取ると、は最後に置かれており、その前のnpm runというサブコマンドを含む部分は完全に固定されて書かれている。そのためこのルールは「npm runの後に何が続いても」という範囲に明確に限定されており、npm installのようなまったく別のサブコマンドを誤って許可してしまうことはない。同様に、を一番前に置く場合(公式例にあるBash( --version)など)も似た状況で、固定部分が反対側にあるため、実際の範囲を一目で読み取りやすい。
本当に間違いやすいのは、サブコマンド自体がのマッチング範囲に含まれてしまう書き方だ——git * mainのように、サブコマンド(log、merge、pushいずれも該当する)が2つの固定テキストの間に挟まれており、は任意のテキストにマッチできるため、サブコマンドも当然置き換え可能な範囲に含まれてしまう。この書き方は見た目上、両端が制限されているように「見える」ため、真ん中もある程度制限されているという誤解を招きやすいが、実際には真ん中こそが完全に開放された、そのコマンドが具体的に何をするかを決定する重要な部分なのだ。
この問題は実際にどんなセキュリティリスクをもたらすのか、単に「ルールの書き方を間違えた」というだけの話ではないのか?
実際のリスクは、サブコマンドが*のマッチング範囲に一度落ちてしまうと、そもそも許可するつもりのなかったgit操作まで連鎖的に許可してしまうという点にある。公式ドキュメントが挙げている例で見ると、Bash(git * main)は-cフラグを持つgit -c core.fsmonitor=<スクリプト> diff mainのようなコマンドを許可してしまう。-cフラグは、実行中にgitが指定した外部プログラムを実行できるようにするもので、これはもはや「gitの範囲が広く書かれすぎている」という問題にとどまらない。git logか、それに類似した操作にしか関係しないと思っていたルールが、実際には任意の外部コマンドを実行できる入り口を開いてしまっているということだ。
これが、公式ドキュメントがこの警告をわざわざ独立して取り上げている理由でもある。単純な「ルールが緩すぎて、多くのgitサブコマンドをカバーしてしまっている」という問題と比べて、この書き方の追加のリスクは、危険なフラグ(-cなど)を伴うバリエーションまで許可してしまう点にあり、しかもそうしたバリエーションは表面上は依然として「mainブランチに関連するgitコマンド」に見えるため、ルールレビューの際に異常として気づかれにくい。
もし自分のプロジェクトに既にこのような書き方のルールが存在する場合、実際にどう確認し、修正すればよいのか?
第一段階は、2.1.246にアップグレードした後、Claude Codeを起動した際にこの警告が表示されるかどうかに注意することだ——この警告自体が最も直接的な確認方法であり、自分で設定ファイルを手作業で調べてこの書き方がないか探す必要はない。もし古いバージョンの設定を手元に持っている場合は、settings.json内でBash(で始まり、途中に*があり、その後にワイルドカードでない文字が続くルールを直接検索することもできる。特に「特定のブランチに限定している」あるいは「特定のサブコマンドのバリエーションに限定している」ように見えるルールに注意を払うとよい。
第二段階は、見つけた各ルールについて、元々の意図が何だったかを振り返って確認することだ。もし意図が「特定のサブコマンドに限定し、引数は問わない」というものであれば、正しい修正方法は*をサブコマンドの後ろに移動させることだ(例えばgit * mainをgit log * mainに変更する)。もし意図が本当に「これらのgit操作を、対象がmainブランチである限りすべて許可する」というものだったなら、そのルール自体が存在すべきかどうかを再検討する必要があるかもしれない。サブコマンドを制限しないということ自体が、許可される範囲が一般的な直感よりもはるかに広いことを意味するからだ。
第三段階は、修正後に実際に、許可されると想定しているコマンドと、許可されるべきではないと想定しているコマンドをいくつか使ってテストし、修正後のルールの挙動が本来の意図と一致しているかを確認することだ。構文が正しく変更されたかを見るだけでは不十分だ。
gitに限らず、この「*をサブコマンドの前に置く」問題は、他のよく使われるコマンドでも起きるのか?
起きる。この問題は本質的にgit自体とは無関係で、「プログラム名+サブコマンド+引数」という構造を持つあらゆるコマンドで起こりうるマッチングの落とし穴だ。あるツールの挙動がサブコマンドによって決まる(単なるフラグ引数ではなく)限り、*をサブコマンドの前に置くことで、サブコマンド自体が置き換え可能な範囲に含まれてしまう。よくある例としてはdocker(docker runとdocker execではサブコマンドの挙動が大きく異なる)、npm(npm installとnpm runはまったく意味が違う)、あるいは自分のプロジェクトで使っているサブコマンド構造を持つあらゆるCLIツールが挙げられる。
実務上より安全な確認習慣は、Bashの許可ルールを書くたびに、「このコマンドのどの部分が、それが何をするかを実際に決定するキーワードなのか」を自問することだ。そのキーワード(通常はサブコマンド)がの前に固定して書かれており、がマッチできる範囲に含まれていないことを確認する。この原則はgit専用のものではなく、サブコマンド構造を持つすべてのCLIツールに適用できる汎用的な確認方法だ。
Claude Code 2.1.246(2026年8月のアップデート群の一つ)は、見落とされやすいが、実際には権限ルールが本当に意図通りの意味を持っているかどうかに影響する起動時警告を追加した。Bashの許可ルールにおいて、ワイルドカード(*)がサブコマンドの前に配置されている場合——例えばBash(git * main)——起動時に警告が表示される。なぜなら、この種のパターンは直感が示唆するよりもはるかに広い範囲にマッチするからだ。この記事では、この警告が何を示しているのか、そしてその背後のマッチングロジックが実際どう動作するのかを説明する。
公式ドキュメントはこの点について率直に述べている。Bashルールは「コマンド全体のテキスト」を比較するものであり、*はスペースを含む任意のテキストを表す。Claude Codeは*の前に書かれた固定部分を、そのままこのルールの制約範囲として扱う——つまり*をどこに配置するかが、このルールが実際に何を制限しているかを直接決定する。
git log --oneline mainというコマンドを例に見てみよう。gitはプログラム自体であり、logはサブコマンドだ——そのプログラムが何をするかを実際に決定しているのはサブコマンドであって、プログラム名ではない。もしBash(git * main)と書いた場合、意図としては「最後にmainが付く限り、log関連の様々な引数を許可する」ということかもしれない。しかしClaude Codeの実際のマッチングロジックは、*の前のgitを一つの制約、*の後のmainを別の制約として扱い、間の*はサブコマンド自体を含む任意のテキストにマッチできる。実際の結果はこうなる。このルールはgit merge main、git push origin main、さらには-cフラグを持ち、指定したプログラムをgitに実行させられるgit -c core.fsmonitor=<スクリプト> diff mainのようなコマンドまで許可してしまう——なぜなら-cも*がマッチする範囲に含まれるからだ。逆に、単純なgit log main(間に何もない)は、実はこのルールにマッチしない。
「引数を問わずlog関連のコマンドのみを許可する」という本来の意図を実現するには、正しい書き方はサブコマンドを*の前に置くことだ。Bash(git log * main)。こうすることで、gitとlogを合わせたものが固定の制約となり、*はlogとmainの間の引数のみにマッチする。そのためgit log --oneline mainやgit log -5 mainは正しくマッチするが、単純なgit log main(間に何もないバージョン)はこのルールにマッチせず、git push origin mainのようなまったく別のサブコマンドにもマッチしない。
この種のルールがもたらすリスクは、「まったく制限がない」というほど明白ではない——もしあるルールがまったく何の制限も持たなければ、問題は一目でわかりやすい。本当のリスクは、Bash(git * main)という書き方が表面上は制限があるように「見える」(結局のところgitもmainも書かれている)が、実際のマッチング範囲は文字通りの見た目よりもはるかに広く、このギャップはルールレビューの際に目視では気づきにくいという点だ。2.1.246のこの起動時警告が対処しているのは、まさにこの「ルールが妥当に見えるが、実際には想定よりも緩い」というギャップだ。もし過去にサブコマンドの前にワイルドカードを置いた許可ルールを書いたことがあるなら、アップグレード後に起動時にこの警告が表示されるかを確認し、そのルールの実際のマッチング範囲が本来の意図と一致しているかを再確認する価値がある。