シャドーイングって何のこと?
シャドーイング(shadowing)は、直訳すると「影を落とすこと」です。プログラミングやツールの設定の世界では、同じ名前のものが複数の場所に存在するとき、優先度の高い方が低い方を隠してしまう現象を指します。隠された側は消えたわけではないのに、実際には使われなくなる。まさに影に入って見えなくなるイメージです。
Claude Codeを触っていると、設定ファイルやカスタムコマンド、サブエージェントなどを「プロジェクトごと」と「自分のユーザー全体」の両方に置けます。そこで同じ名前のものを両方に用意してしまうと、片方だけが効いて、もう片方は無視される。「あれ、さっき書いた設定が反映されないぞ?」というときの犯人が、このシャドーイングであることは結構あります。
身近な例え:社則と部署のルール
会社を思い浮かべてください。全社共通の就業規則に「会議は30分まで」と書いてあるとします。ところが、あなたの所属する部署のローカルルールにも「会議は15分まで」と書いてある。この場合、日々の仕事で従うのは部署のルールですよね。全社の規則が消えたわけではないけれど、より身近なルールが上に乗っかって、実質的にそちらが優先される。
これがまさにシャドーイングです。「近い方が勝つ」——この一言でだいたい理解できます。逆に、部署のルールに何も書かれていない項目については、全社の規則がそのまま適用されます。つまり全部が上書きされるのではなく、名前がぶつかったものだけが隠れる、という点が大事です。
どういうときに起きるのか
典型的なのは、次のように「同じ役割のものを置ける場所が複数ある」ケースです。
ユーザー全体に置いたもの
自分のホームディレクトリ配下など、どのプロジェクトで作業していても共通で効く場所。汎用的な設定やよく使うコマンドを置きます。
プロジェクトに置いたもの
作業中のリポジトリの中に置く場所。そのプロジェクト専用の事情を反映させたいときに使います。こちらの方が「近い」ので優先されます。
同じ名前のカスタムコマンドを両方に作ってしまうと、プロジェクト側だけが呼び出され、ユーザー側は影に隠れます。設定値の場合も同様で、両方で同じキーを指定していれば、より限定的な方の値が採用されます。
「効かない」と思ったときの確認手順
設定をいじったのに挙動が変わらない、という場面で疑う順番はだいたい決まっています。
- そもそもファイルの置き場所は合っているか(パスのタイプミスは本当によくあります)
- 同じ名前のものを、別の場所にも作っていないか
- 作っていた場合、どちらが優先されるルールになっているか
2番目で心当たりが出てきたら、シャドーイングの可能性が高いです。片方の名前を変えてみると、隠れていた方が急に動き出して「なるほど、こっちが効いてたのか」と分かります。
悪者ではなく、便利な仕組み
シャドーイングと聞くとトラブルの原因のように感じるかもしれませんが、本来は意図して使うと便利な仕組みです。「基本はいつもの自分のやり方でいいけれど、このプロジェクトだけは事情が違うから差し替えたい」というとき、共通側を書き換えずにプロジェクト側だけ用意すれば済みます。共通設定は共通設定のまま残しておけるので、そのプロジェクトから離れれば元の挙動に戻ります。
問題になるのは、上書きしているつもりがない場合だけ。裏を返せば、「どこに何を置いたか」を自分で把握できていれば怖くありません。プロジェクト固有のものには、あえて名前にプロジェクト名を含めておくといった小さな工夫でも、うっかり衝突はかなり減ります。
変数のシャドーイングも同じ考え方
ちなみにこの言葉は、プログラミング言語の変数についても使われます。関数の外側に count という変数があるとき、関数の中でもう一度 count を宣言すると、その関数の中では内側の count しか見えなくなる。外側の変数は影に隠れます。
let count = 10;
function f() {
let count = 1; // 外側の count をシャドーイング
console.log(count); // 1
}
f();
console.log(count); // 10(外側は無傷)
「内側が外側を隠す」「隠されただけで壊れてはいない」という性質は、設定ファイルの話とまったく同じです。片方を理解すればもう片方もすぐ飲み込めるはずです。
このページは役に立ちましたか?