「作ったスキルを、同僚にも同じように使わせたい。どうすれば全員に届きますか」
「同じ名前のスキルが、自分用の場所とプロジェクトの両方にあったら、どちらが動くのですか」
第7回までで、検証スキル ansible-verify が一通りできました。スキルの値打ちは、同じ手順をチームの全員が同じように使えることにあります。ただし、共有するということは、他人が書いた指示とスクリプトを、自分の権限で動かすことでもあります。置き場所と名前の決まり、レビューの手順を先に決めておかないと、思わぬものが動きます。
第8回では、共有の3つの方法、.claude/ フォルダーのうち Git に入れるものと入れないもの、同じ名前のスキルがあるときの優先順位、共有の手順、運用ルール（筆者の例）、そして「チームで使うなら決めておくこと」を扱います。冒頭の1つ目の相談は「共有の3つの方法」と「共有の手順」、2つ目は「優先順位と名前の付け方」の節で答えます。数値・仕様は2026年10月時点です。
共有の3つの方法と、この連載の選択
スキルをチームに配る方法は3つあります。
| 方法 | 特徴 | この連載での扱い |
|---|---|---|
リポジトリにコミット（.claude/skills） | clone すれば届く。追加のインストール不要 | この連載で扱うのはこれ |
| プラグイン（マーケットプレイス） | リポジトリをまたいで配る。名前に plugin名: が付く | 連載「Claude Codeチーム活用入門」第6回の「Git での共有とプラグインの違い」で扱う |
| 管理設定（Enterprise） | 管理設定のフォルダーに置き、組織が機器に配る | 組織（機器の管理者）が配る。組織のプラン（Team・Enterprise）の補足 |
公式の置き場所の表では、リポジトリの .claude/skills は「コミットすればチームにも届く」、管理設定は「組織が配った機器の全ユーザー」です（https://code.claude.com/docs/ja/skills ）。「更新は pull で届く」は、Academy の講座「Introduction to agent skills」（日本語版は「Agent Skills入門」）のレッスン5「Sharing skills」の言い方です（公式のスキルのページでは、「更新は pull」という語は見つかっていません）。
組織のプラン（Team・Enterprise）の補足：管理設定で配るスキルは、管理設定のフォルダーの .claude/skills/<skill-name>/SKILL.md に置きます（公式の表の記述。公式のスキルのページの削除の例には、Linux の /etc/claude-code/.claude/skills/<skill-name>/ が出てきます）。組織は、管理設定の allowManagedPermissionRulesOnly で、管理設定を権限ルールの唯一の出どころにできます。また strictPluginOnlyCustomization で、ユーザー・プロジェクトのスキルを止められます（公式の管理設定のページの表）。管理設定の扱いは、連載「Claude Code実践入門」第6回の「組織のプランの補足：管理された設定の配り方」と同じ考え方です。個人の Pro・Max の Claude Code に、管理設定が配られているかどうかは、筆者は確かめていません。
.claude/ フォルダーの全体
リポジトリの .claude/ には、使うほど増えるものが入ります。
settings.json：権限とフックの設定。連載「Claude Code実践入門」第6回の「Ansibleの作業での設定例（筆者の例）」の allow・ask・deny が入っています。フックの設定もここに書くので、連載「Claude Codeフック入門」第2回の「設定の形」で足していきますskills/：この連載で作るスキルagents/：サブエージェント。次の連載「Claude Codeサブエージェント入門」第3回の「ファイルの形」で作ります
これらと、リポジトリの直下の CLAUDE.md は、Git に入れてチームで共有します。一方、自分だけの設定を書く settings.local.json と CLAUDE.local.md は共有しません。確認の画面で、コマンドなどに「常に許可」を選んだときのルールも settings.local.json に入ります（ファイルの変更の承認は保存されず、そのセッションの間だけ有効です。連載「Claude Code実践入門」第5回の「Code タブでの権限の操作」）。
- Git に入れる：skills・agents・settings.json
- 入れない：settings.local.json など
- 使うほど増える：設定 → skills → agents
settings.local.json は、Claude Code が作るときは Git の対象から外されますが、手で作ったときは .gitignore に自分で書きます。公式の説明では、Claude Code は、このファイルを最初に書くときに、グローバルの git の除外（global git excludes）に追加します。リポジトリの .gitignore に自動で書くとは書かれていません。手で作ったファイルは、.gitignore に自分で書かないと、コミットされます。公式の権限のページには、ファイルが git で追跡されていると、Claude Code はそれを「リポジトリから来たもの」として扱い、そのフォルダーを信頼するまでルールを保留する、という趣旨の記述があります。
筆者の ~/practice は、前の連載の演習の準備で .gitignore の3行目に .claude/settings.local.json を書いてあり、スキルを git add -A でコミットしても、settings.local.json は入りませんでした（Claude Code 2.1.289、2026-10-18）。
出典は https://code.claude.com/docs/ja/settings 、https://code.claude.com/docs/ja/sub-agents 、https://code.claude.com/docs/ja/memory 、https://code.claude.com/docs/ja/permissions です。.claude/ の中身は、公式の「Explore the .claude directory」（https://code.claude.com/docs/ja/claude-directory ）にも、コミットするかどうかの列が付いた一覧があります（settings.local.json だけは、Claude Code が設定を書いたときに Git の対象から外される、とあります）。
優先順位と名前の付け方
2つ目の相談に答えます。同じ名前のスキルが複数の場所にあると、1つが勝ちます。公式の表では、管理設定・個人・プロジェクトのうち2つに同じ名前があるときは、管理設定が個人に、個人がプロジェクトに優先します。公式の例は、deploy が ~/.claude/skills/ とプロジェクトの .claude/skills/ の両方にあれば、/deploy は個人のほうを動かす、というものです。
| 同じ名前が | どうなるか | チームでの対応 |
|---|---|---|
| 管理設定・個人・プロジェクトに複数 | 管理設定→個人→プロジェクトの順で1つが勝つ | 個人に同名があるとチームのものが隠れる。名前は具体的に |
| プラグインと、ほかの場所 | plugin名:スキル名 になるので両方読み込まれる | この連載はプラグインを扱わないので、名前の衝突は気にしない |
| 同梱のスキルと同名 | 自分のスキルが置き換える（組み込みの /verify など） | verify だけにしない。ansible-verify にする（第3回の「似たスキルを分ける・名前を具体的に」） |
サブフォルダーの .claude/skills | ルートのスキルと両方読み込まれる。名前にフォルダーの道筋が付く（apps/web の deploy は /apps/web:deploy） | そのフォルダーのファイルに触るときに読み込まれる |
Academy のレッスン5・6は、エンタープライズ→個人→プロジェクト→プラグインの順で、上が下を上書きすると説明しています。この連載は、公式の表に合わせました（https://code.claude.com/docs/ja/skills ）。プラグインのスキルは、公式では名前空間が付くので、ほかの場所のスキルと両方読み込まれます。
なお、担当（サブエージェント）と settings.json などの設定ファイルでは、プロジェクトが個人に優先し、スキルとは向きが逆です（連載「Claude Codeサブエージェント入門」第2回の「担当の置き場所と優先順位」、連載「Claude Code実践入門」第6回の「設定ファイルの階層」）。
verify という名前を避ける理由は、第3回の「似たスキルを分ける・名前を具体的に」のとおりです。自分の verify スキルは組み込みの /verify を置き換え（公式の表）、コミットの直前に実行する指示の対象にもなります（公式のスキルのページに、verify か simplify という名前のスキルがあると、Claude Code のコミットの指示が、ドキュメントとテストの変更を除くコミットの直前にそれを実行させる、という記述があります。この指示は Claude Code v2.1.286 以降です。組み込みの /verify・/simplify、プラグインのスキル、claude.ai のアカウントのスキルは対象に入りません）。
サブフォルダーの .claude/skills は、公式の説明では、起動したフォルダーから、リポジトリのルートまでの各フォルダーの .claude/skills/ が読み込まれます。起動したフォルダーより下にある .claude/skills/ は、起動時には読み込まれず、Claude がそのサブフォルダーのファイルを初めて読むか編集するときに読み込まれます。
共有の手順
1つ目の相談に答えます。スキルは「手順のコード」として扱い、普通のコードと同じように、ブランチ → レビュー → マージで共有します。
| 手順 | やること | 見ること |
|---|---|---|
| 1 作る | 自分のブランチに .claude/skills/<名前>/ を作る | name がフォルダー名と同じか |
| 2 試す | 第3回の「普段の言い回しを入れる」の言い回しで頼む。発動してほしくない依頼も | 発動したか。しなかったか |
| 3 レビュー | PR を出す。description・allowed-tools・scripts を読む | 事前承認が広すぎないか |
| 4 マージ | オーナーが承認してマージする | 運用ルール（次の節）に合うか |
| 5 各自 pull | git pull。一覧に出なければ新しいセッション（第9回の「症状別チェックリスト」） | 同じ言い回しで発動するか |
| 更新 | 同じ流れで PR を出す | 直した理由が PR に書かれているか |
レビューが要るのは、スキルが自分で広い権限を与えられるからです。公式は、リポジトリにコミットされたスキルは自分で広いツールの権限を与えられるので、その場所で Claude Code を動かす前に allowed-tools を読むよう注意しています（原文は「A skill can grant itself broad tool access, so review the allowed-tools of skills checked into a repository before you run Claude Code there.」。https://code.claude.com/docs/ja/skills ）。
clone した直後は、スキルも allow も止まる（筆者の記録）
上の表の手順5「各自 pull」の前に、新しく clone したフォルダーではどうなるかを、筆者が試しました（第12回の手順7と同じ試しです。Ubuntu 26.04.1、Claude Code 2.1.289 の CLI、非対話の claude -p。-p は確認の画面が出せないので、承認が要る操作は実行されずに止まります）。~/practice に ansible-verify をコミットし、git clone ~/practice ~/practice-clone した先で「検証して」と頼みました。
- clone 直後：「Ignoring 6 permissions.allow entries from .claude/settings.json: this workspace has not been trusted.」と出て、プロジェクトの allow が無視された。スキルの呼び出しも、
ansible-lintなどのコマンドも、承認待ちだった - clone 先を信頼した後：プロジェクトの allow は効いた。しかしスキルの呼び出しは承認待ちのままだった。
Skill(ansible-verify)の許可は、元のフォルダーの.claude/settings.local.jsonに書いてあり、clone 先には来ないため
つまり、共有されるのはスキルのファイル（SKILL.md・scripts/・reference/）で、各自が「常に許可」で作った許可は共有されません。clone した人は、自分の環境で確認の画面を選び直します。
公式の権限のページ（「What runs before you trust a folder」の表）は、claude -p や SDK では信頼の画面が出ないこと、信頼していないフォルダーでは .claude/settings.json の permissions.allow が使われないこと、スキルの allowed-tools は、ワークスペースの信頼では止まらず、どのセッションでも使われることを書いています。筆者の記録の「スキルの呼び出しそのものが承認待ち」は、この allowed-tools とは別の話です。未信頼のフォルダーで、プロジェクトのスキルが読み込まれるかどうかについて、公式の記述は見つけられていません。
チームで使うときの運用ルール（筆者の例）
共有するなら、次のような決まりを置くと役に立ちます。これは筆者の例で、公式の推奨ではありません。
- 置き場所：各 Ansible リポジトリの
.claude/skills/。複数のリポジトリで使うスキルの置き場所は論点（次の節の①） - 補助のフォルダー名：
reference/（単数）にそろえる。標準（agentskills.io）の提案はreferences/ですが、名前は SKILL.md からのリンクで決まるので、チームで決めてよい（第4回の「フォルダーの構成」） - 名前：対象-動作（
ansible-verify）。verify・reviewだけにしない（上の「優先順位と名前の付け方」）。nameはフォルダー名と同じにする（筆者の決まり。公式ではnameは省略でき、省略するとフォルダー名になります） - description：何をするかといつ使うか。日本語の言い回しを含める（第3回の「普段の言い回しを入れる」）
- 書かないもの：パスワード、ホスト名や IP アドレスの一覧、個人の環境のパス（IP アドレスの一覧は、連載「Claude Code実践入門」第4回の「書くこと・書かないこと」の「よく変わる情報」）
allowed-tools：狭く書く（ansible-verify はverify.shの呼び方だけ）。deny・ask で守っているものは書かない（第5回の「allowed-tools で事前承認する」）- レビュー：変更は PR で。scripts に危ない操作を入れない（ask・deny はスクリプトの中のコマンドまでは確かめられない前提。第7回の「呼び方と、スクリプトの中のコマンド」）。他人のスキルは、中身を読んでから使う
- オーナー：スキルごとにオーナーとレビュー担当を決める
信頼できるスキルだけを使う、という注意は公式にもあります。同僚から共有されたものも、有効にする前に確認します（https://support.claude.com/en/articles/12512180-use-skills-in-claude ）。
チームで使うなら決めておくこと
ここまでの内容を、チームで運用するときに決めておくと役に立つ点にまとめます。連載「Claude Code実践入門」第7回の「チームで使うなら決めておくこと」の④「共通のスキルにしたい手順」と、連載「Claude活用入門」第6回の「チームで使うなら決めておきたいこと」と合わせて使ってください。
- ①チーム共通のスキルの1本目：
ansible-verifyでよいか。名前と、置き場所（各リポジトリか、共通の場所か） - ②CLAUDE.md のひな形：連載「Claude Code実践入門」第4回のひな形から、何をスキルへ移すか（第7回の「CLAUDE.md を短くする」）
- ③
allowed-toolsをどこまで書くか：.claude/settings.jsonの allow と重ねるか。deny・ask との関係をどう扱うか - ④次の候補：playbook のレビュー、手順書の書式、コミットメッセージ。担当に分けたいもの（次の連載「Claude Codeサブエージェント入門」の題材）は何か
- ⑤運用：スキルのオーナーとレビュー担当を誰にするか（運用ルールの最後の項目）
考えてみよう
- 自分の
~/.claude/skills/にansible-verifyという同名のスキルを置いていたら、チームのリポジトリのansible-verifyは動くでしょうか。避けるにはどうしますか - 同僚が PR で出したスキルをレビューするとき、最初に読むべき3つは何でしょうか
- clone した直後の同僚から「スキルが承認待ちで進まない」と言われました。何を確かめますか
ヒント：1は「優先順位と名前の付け方」、2は「共有の手順」の表の3行目、3は「clone した直後は、スキルも allow も止まる（筆者の記録）」を見直してください。
まとめ
- スキルの共有は3つ：リポジトリにコミット（clone すれば届く）、プラグイン（リポジトリをまたぐ）、管理設定（組織が配る。組織のプランの補足）。この連載はリポジトリにコミットする方法
.claude/のうち、skills・agents・settings.json と CLAUDE.md は Git に入れ、settings.local.json・CLAUDE.local.mdは入れない。手で作ったファイルは.gitignoreに自分で書く- 同じ名前は、管理設定→個人→プロジェクトの順で1つが勝つ。個人に同名があるとチームのものが隠れるので、名前は具体的に（
verifyだけにしない） - 共有は、ブランチ → 試す → PR でレビュー → マージ → 各自 pull。レビューでは description・allowed-tools・scripts を読む
- 新しく clone したフォルダーでは、信頼するまでプロジェクトの allow が効かず、スキルの呼び出しも承認待ちになる（筆者の記録）。「常に許可」は共有されない
- 運用ルール（筆者の例）：名前は対象-動作、書かないもの、
allowed-toolsは狭く、変更は PR、オーナーを決める
次回の第9回は、スキルがうまく動かないときの症状別チェックリストと確かめ方、Windows と Linux の注意、そして連載の早見表と持ち帰りを扱います。
連載「Claude Codeスキル入門」全12回
全回の目次と、読む順番・目的別の読み方は、Claude Codeスキル入門の入口のページにまとめています。
- スキルとは何か
- SKILL.mdを書く
- 発動する説明を書く
- 複数のファイルに分ける
- スクリプトとallowed-tools
- 検証スキルを作る（前編）
- 検証スキルを作る（後編）
- Gitでチームに共有する（この記事）
- うまく動かないとき
- 演習（前編）：作る・確かめる・発動させる
- 演習（中編）：分ける・事前承認
- 演習（後編）：共有と振り返り
コメント