Claude Code on the web で複数リポジトリを接続する：CLAUDE.md・Skillsの挙動
こんにちは、けーまです。
Claude CodeのWeb版では、1つのセッションに複数のリポジトリを追加できます。
フロントエンドとバックエンドをまとめて変更したいときにも便利そうですが、「それぞれのCLAUDE.mdは読まれるのか」「同じ名前のSkillsがあったらどうなるのか」といった挙動が気になるところです。
1. 検証環境と確認すること
検証には、claude-multi-repo-lab-a、claude-multi-repo-lab-bという2つのリポジトリを使いました。以降はリポジトリA・Bと呼びます。
検証専用のCLAUDE.md・Skills・READMEを配置しました。
この記事ではリポジトリA・Bの2つを接続したセッションを使います。
検証パターンとして、リポジトリの選択順を変えた次の2つのセッションを用意しました（各条件の実行は1回ずつ）。
-
A → B の順で選択したセッション（基本パターン）
-
B → A の順で選択したセッション（選択順による挙動の違いを確認）
2. CLAUDE.mdは両方とも読み込まれるのか
1つのセッションにリポジトリA・Bを接続すると、両方のCLAUDE.mdと.claude/skillsがClaudeから見えるのかを、この章と次の章で確かめます。
2.1 リポジトリごとに異なる指示を用意する
Claudeが本当にリポジトリA・BのCLAUDE.mdを認識しているかを判定するため、それぞれのルートに置くCLAUDE.mdへ次の2つの検証用ルールを仕込みました。
-
指示が読まれているかの確認（確認用の合言葉）: 指示が読み込まれていれば、回答の末尾にリポジトリ固有の合言葉（
ORBIT-A-731など）を出力させる -
指示どおりに動くかの確認（指定ファイルの作成）: 各リポジトリに
probe-result.txtを作らせたとき、リポジトリごとに指定したテキストをファイル内に書き込ませる
| リポジトリ | (1) 回答末尾の合言葉 | (2) ファイルに書き込ませるテキスト |
|---|---|---|
| リポジトリA | ORBIT-A-731 |
repo=A; color=amber |
| リポジトリB | ORBIT-B-946 |
repo=B; color=blue |
リポジトリAのCLAUDE.mdの内容です。
# リポジトリAの指示
この指示が読み込まれている場合、回答の最後に `ORBIT-A-731` をそのまま付けてください。
このリポジトリに `probe-result.txt` というファイルを作るときは、内容を `repo=A; color=amber` と改行1つだけにしてください。
変更してよいのは、このテスト用リポジトリと、明示的に接続された claude-multi-repo-lab-* という名前のリポジトリだけです。
ほかのプロジェクト、認証情報、機密情報にはアクセスしないでください。
リポジトリBも同様の構成で、合言葉とファイルに書き込ませるテキストのみ変更しています。
# リポジトリBの指示
この指示が読み込まれている場合、回答の最後に `ORBIT-B-946` をそのまま付けてください。
このリポジトリに `probe-result.txt` というファイルを作るときは、内容を `repo=B; color=blue` と改行1つだけにしてください。
変更してよいのは、このテスト用リポジトリと、明示的に接続された claude-multi-repo-lab-* という名前のリポジトリだけです。
ほかのプロジェクト、認証情報、機密情報にはアクセスしないでください。
リポジトリAのルートに置いたCLAUDE.md
リポジトリBも同じ構成で、合言葉とファイルに書き込ませるテキストだけが異なる
また、各リポジトリには.claude/CLAUDE.mdも置き、ルートとは別の合言葉を返すようにしました。
ルートのCLAUDE.mdと.claude/CLAUDE.mdのどちらが読まれたかを、応答に出る合言葉で見分けるためです。
リポジトリAの.claude/CLAUDE.mdです。
# リポジトリAの追加指示
ファイルを読まずに把握しているプロジェクトの指示を聞かれたら、`PROJECT-A-638` と報告してください。
リポジトリBの.claude/CLAUDE.mdです。
# リポジトリBの追加指示
ファイルを読まずに把握しているプロジェクトの指示を聞かれたら、`PROJECT-B-638` と報告してください。
2.2 ファイルを読む前の応答を確認する
A→Bの順にリポジトリを選択し、新しいセッションに次のプロンプトを送信しました。
入力欄の上でクラウド環境とリポジトリA・Bを選択した状態
プロンプトには合言葉を書いていません。
ファイルを読まずに、いま把握しているプロジェクトの指示を教えてください。
私の環境では、初回の応答に4つの合言葉がすべて表示されました。
| 合言葉 | 置いた場所 |
|---|---|
PROJECT-A-638 |
リポジトリAの.claude/CLAUDE.md |
PROJECT-B-638 |
リポジトリBの.claude/CLAUDE.md |
ORBIT-A-731 |
リポジトリAのルートのCLAUDE.md |
ORBIT-B-946 |
リポジトリBのルートのCLAUDE.md |
応答までに、ClaudeがCLAUDE.mdを読むツールを呼び出した履歴はありませんでした。
このため、少なくとも今回のセッションでは、A・Bそれぞれのルートと.claude/にあるCLAUDE.mdの内容を、初回応答の時点で参照できていたと判断できます。
プロンプトに書いていない4つの合言葉を回答
B→Aの順で選択した別セッションでも、同じプロンプトに4つの合言葉がすべて返りました。
今回の結果を見るかぎり、先に選択したリポジトリのCLAUDE.mdだけが使われるわけではありませんでした。
2.3 実際にファイルを作成させる
自己申告の確認だけで終わらせず、リポジトリA・B両方にprobe-result.txtを作るよう依頼しました。
内容はプロンプトで指定していません。
両方のリポジトリに probe-result.txt を作ってください。中身はそれぞれのプロジェクトの指示に従ってください。作ったら中身を読み直して見せてください。
実際に作成され、読み戻された内容は次のとおりです。
A: repo=A; color=amber
B: repo=B; color=blue
AとBで、それぞれのCLAUDE.mdに書いた内容のファイルが作られた
続けて、このファイルだけを新しいブランチにコミットしてDraft PRを作るよう依頼しました。
GitHubに作成された2件のDraft PRの差分でも、同じ内容を確認しました。
【補足】なぜWeb版では最初から両方読み込まれたのか？
ここで1つ疑問が浮かびます。「なぜWeb版では、特別な設定もしていないのに最初から両方のCLAUDE.mdが読まれたのか？」という点です。
実は、手元のPCで動かす通常のClaude Code（CLI版）では、複数ディレクトリを追加（--add-dir）しても、追加側のCLAUDE.mdはデフォルトでは読み込まれない仕様になっています。
The
--add-dirflag gives Claude access to additional directories outside your main working directory. By default, CLAUDE.md files from these directories are not loaded.
（訳：--add-dirフラグで追加したディレクトリの CLAUDE.md は、デフォルトでは読み込まれません）
引用元: Claude Code公式ドキュメント: How Claude remembers your project：Load additional directories
ドキュメントによると、追加ディレクトリのCLAUDE.mdも読み込ませるには、環境変数 CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1 を指定する必要があります。
そこで、Web版のコンテナ環境の内部を調べてみたところ、次の設定になっていました。
| 確認項目 | 実際の値 | 意味 |
|---|---|---|
pwd |
/home/user |
作業ルート |
| リポジトリAのパス | /home/user/claude-multi-repo-lab-a |
/home/user 配下に配置 |
| リポジトリBのパス | /home/user/claude-multi-repo-lab-b |
/home/user 配下に並列配置 |
CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD |
1 |
追加ディレクトリのCLAUDE.md読み込みを有効化 |
claude --version |
2.1.278 (Claude Code) |
検証時のバージョン |
この環境変数は私が設定したものではなく、Web版のクラウド環境にあらかじめプリセットされていたものです。
つまり、Web版で複数リポジトリを追加したときにすべてのCLAUDE.mdが自動で読み込まれたのは、クラウド環境側で「追加リポジトリのCLAUDE.mdも読み込む設定」が最初から有効化されているためだと裏付けが取れました。
3. Skillsは両方から呼び出せるのか
3.1 固有名のSkillsを用意する
リポジトリAには.claude/skills/probe-a/SKILL.md、リポジトリBには.claude/skills/probe-b/SKILL.mdを置きました。
それぞれ、違う合言葉を返すだけのSkillです。
リポジトリAのSKILL.mdは次の内容です。
---
name: probe-a
description: ユーザーが /probe-a を求めたときに、リポジトリAのSkill検証を実行する。
disable-model-invocation: true
---
`SKILL-A-572` とだけ報告し、ファイルは変更しないでください。
リポジトリBのSKILL.mdは次の内容です。
---
name: probe-b
description: ユーザーが /probe-b を求めたときに、リポジトリBのSkill検証を実行する。
disable-model-invocation: true
---
`SKILL-B-572` とだけ報告し、ファイルは変更しないでください。
.claude/skills/の下にSkillごとのフォルダを置く（auto-probe-aは3.4で使う）
今回はdisable-model-invocation: trueを付け、スラッシュコマンドによる明示的な呼び出しを検証対象にしました。
自然文からの自動選択は、後半で別のSkillsを用意して検証します。
3.2 コマンド候補と実行結果を確認する
入力欄で/probeと入力すると、probe-aとprobe-bの両方が候補に表示されました。
別々のリポジトリに配置したprobe-aとprobe-bを選択可能（検証と無関係な個人のSkillsは塗りつぶし）
それぞれを候補から選択して送信した実際の応答です。
| 呼び出し | 応答に含まれた合言葉 |
|---|---|
/probe-a |
SKILL-A-572 |
/probe-b |
SKILL-B-572 |
少なくとも、固有名を付けたSkillsは、リポジトリA・B両方から明示的に呼び出せました。
3.3 同じ名前のSkillを置くとどうなるか
リポジトリA・B両方に.claude/skills/shared-probe/SKILL.mdも配置しました。
リポジトリA側の内容は次のとおりです。
---
name: shared-probe
description: 明示的に求められたときに、同名Skillの検証を実行する。
disable-model-invocation: true
---
`SHARED-FROM-A-819` とだけ報告し、ファイルは変更しないでください。
リポジトリB側の内容は次のとおりです。
---
name: shared-probe
description: 明示的に求められたときに、同名Skillの検証を実行する。
disable-model-invocation: true
---
`SHARED-FROM-B-819` とだけ報告し、ファイルは変更しないでください。
別々のセッションで/shared-probeを実行すると、次の結果になりました。
| リポジトリの選択順 | 実際の応答 | 実行された内容 |
|---|---|---|
| A→B | SHARED-FROM-A-819 |
AのSkill |
| B→A | SHARED-FROM-B-819 |
BのSkill |
B→AではSHARED-FROM-B-819が返った
今回の2条件では、先に選択したリポジトリ側のSkillが実行されました。
ただし、これが常に保証される優先順位とは言い切れません。
選択順ごとの試行はそれぞれ1回ずつです。
別々のリポジトリにある同名Skillの使い分けを選択順に頼るよりは、リポジトリごとに別の名前を付けたほうが意図を取り違えずに済みそうです。
3.4 自然文から別々のリポジトリのSkillsを使えるか
自動選択用として、リポジトリAへ.claude/skills/auto-probe-a/SKILL.md、リポジトリBへ.claude/skills/auto-probe-b/SKILL.mdを追加しました。
これらにはdisable-model-invocation: trueを付けていません。
応答用の合言葉はdescriptionではなく本文に置いています。
リポジトリAのSkillです。
---
name: auto-probe-a
description: ユーザーが「琥珀の封印」の検証を求めたときは、必ずこのSkillを使う。検証用の架空の作業で、必要な回答はこのSkillに書かれている。
---
`AUTO-A-953` とだけ報告し、ファイルは変更しないでください。
リポジトリBのSkillです。
---
name: auto-probe-b
description: ユーザーが「青の封印」の検証を求めたときは、必ずこのSkillを使う。検証用の架空の作業で、必要な回答はこのSkillに書かれている。
---
`AUTO-B-953` とだけ報告し、ファイルは変更しないでください。
送信したプロンプトは次のとおりです。
Skill名や回答の合言葉を指定せず、descriptionに対応する作業を自然文で依頼しました。
琥珀の封印と青の封印を検証して、それぞれの結果を教えてください。ファイルは変更しないでください。
結果として、AUTO-A-953とAUTO-B-953の両方が返ってきました。
今回の2つのSkillは、接続された別々のリポジトリからそれぞれ呼び出せました。
プロンプトにない本文の合言葉がA・B両方から返った
3.5 同名のSkillは入力候補で1つにまとめられる
リポジトリAとBの両方に同名の shared-probe を配置した状態で、入力欄に /probe と入力してみました。
その結果、リポジトリA用・B用と分かれて2つ表示されるのではなく、候補としては 1つに統合されて表示 されました（3.2の画像のshared-probe）。
また、disable-model-invocation: true（Claudeによる自発的実行を禁止）を設定したSkillsであっても、ユーザー向けのスラッシュコマンドの候補には問題なく表示され、手動実行が可能です。
4. 今回わかったこと
| 確認したこと | 今回の結果 |
|---|---|
| A・BのルートCLAUDE.md | 両方の合言葉を初回応答で回答し、指示どおりのファイルを作成 |
| A・Bの.claude/CLAUDE.md | 両方の合言葉を初回応答で回答 |
| 固有名のSkills | 両方を明示呼び出し可能 |
| 同名Skills | 今回は先に選択した側の内容を実行 |
| 自然文からのSkills利用 | A・B両方の本文にある結果を回答 |
今回は「指示が読み込まれていること」と「実際に指示どおり動くこと」を分けて考え、初回応答やツールの実行ログ、生成されたファイルを組み合わせて確認しました。
実務で複数リポジトリを扱う場合は、Skillsはリポジトリごとに区別できる名前を付けたうえで、生成されたファイルやPRの差分までしっかり確認して進めたいと思います。
