「スキルをコミットして共有したのに、別の場所へ clone すると、確認がまた出ます。共有できたのは何で、できなかったのは何ですか」
「演習は一通り終わりました。自分のスキルと設定に何を持ち帰り、次に何を学べばよいでしょうか」
スキルを共有するときの難しさは、ファイルは届くのに、各自の許可は届かないことです。そして、演習は、終わったあとに振り返らないと、手元の設定に残りません。
第12回は、演習の後編です。第10回では準備と手順1〜4（作る・確かめる・発動させる）、第11回では手順5・6（スクリプトと参照ファイルに分ける、allowed-tools で事前承認する）を扱いました。この回では、手順7（コミットして別のフォルダーへ取り出す）、早く終わった人、最後の状態、4D での振り返り、自己点検、次に学ぶなら（サブエージェント）、連載の結びを扱います。手順7の後には、「筆者の環境ではこうなった」の囲みを載せます。
この回でやること
全体の流れは、第10回の図のとおりです。この回は手順7以降です。手順7と「早く終わった人」の表は、すぐ下に載せます。
囲みの版は、2.1.289（筆者の PC の CLI を非対話の claude -p で試した記録。確認の画面が出る操作は「承認が要る」として止まる）です。詳しくは第10回の「筆者の記録の読み方」を見てください。数値と仕様は2026年10月時点です。
手順7
手順7と「早く終わった人」の表です。
| 手順 | やること | 確認すること |
|---|---|---|
| 7 | コミットして、git clone ~/practice ~/practice-clone で別のフォルダーに取り出し、そこを開いた新しいセッションで頼む | clone 先でも一覧に出て発動したか。settings.local.json が無いこと（コミットされない） |
| 早く終わった人 | CLAUDE.md の「よく使うコマンド」があれば消してスキルに任せる（第7回の「CLAUDE.md を短くする」）。個人スキル commit-message-ja を作る | 発動したか。個人のスキルは、どこに作ると一覧に出たか |
手順7：コミットして、clone した別のフォルダーで動かす
スキルをコミットし、git clone ~/practice ~/practice-clone で別のフォルダーに取り出して、そこを開いた新しいセッションで「検証して」と頼みます。clone 先でも一覧に出て発動したか、settings.local.json が無いこと（コミットされない）を確かめます。
.claude/settings.local.json は、「常に許可」を選ぶと Claude Code が書き込むファイルです。公式の文書には、初めて書き込むとき Git のグローバルの除外に自動で入れるが、手で作ったファイルは自分で .gitignore に入れる、とあります（https://code.claude.com/docs/ja/settings ）。この演習の ~/practice では、連載「Claude Code実践入門」第8回（演習 前編：準備から実装と検証まで）の準備プロンプトで作った .gitignore に入っています。
筆者の環境ではこうなった（2.1.289：手順7）
git add -Aで、SKILL.md・reference/reading-diff.md・scripts/verify.shの3つがコミットされた（コミット「ansible-verify スキルを追加」）。.claude/settings.local.jsonは.gitignore（3行目）にあるので、コミットされなかった。git clone ~/practice ~/practice-cloneの直後に「検証して」と頼むと、CLI は「Ignoring 6 permissions.allow entries from .claude/settings.json: this workspace has not been trusted.」と出し、スキルの呼び出しも、ansible-lintなどの個別のコマンドも承認待ちになった（未信頼のフォルダーだから。連載「Claude Code実践入門」第6回の「未信頼のフォルダーでは、プロジェクトの allow が効かない」）。
clone 先を信頼した後に「検証して」と頼むと、プロジェクトの allow は効いたが、スキルの呼び出しは承認待ちだった（Skill(ansible-verify)の許可は~/practiceのsettings.local.jsonにあり、clone 先には無い）。Claude は個別のコマンドで検証した。
→ 共有されるのはスキルのファイル（SKILL.md・scripts・reference）で、各自の「常に許可」は共有されない。
公式の permissions のページには、-p では信頼の確認の画面が出ないこと、未信頼のフォルダーでは permissions.allow が使われないこと、手で信頼を記録する方法（~/.claude.json の設定）があります。同じ表に、スキルの allowed-tools はワークスペースの信頼で止められない、ともありますが、筆者の記録ではスキルの呼び出しそのものが承認待ちだったので、この点は確かめられていません（https://code.claude.com/docs/ja/permissions の「What runs before you trust a folder」）。
早く終わった人
- CLAUDE.md の「よく使うコマンド」を消してスキルに任せる：CLAUDE.md に検査・構文確認・差分確認のコマンドが書いてあれば消して、スキルに任せます（第7回の「CLAUDE.md を短くする」）。筆者の
~/practiceの CLAUDE.md は、/initが英語で書いた22行で、コマンドの節の見出しは「Commands」です - 個人のスキル
commit-message-jaを作る：~/.claude/skills/commit-message-ja/SKILL.mdに作ります（個人のスキルの置き場所は第2回の「スキルの置き場所」）。個人のスキルは、そのPCのほかのプロジェクトのセッションにも読まれるので、試したら消すか、試験用と分かる名前にしてください。発動したか、個人のスキルをどこに作ると一覧に出たかを確かめます
筆者は、この2つを試していません。
最後の状態
筆者の練習用リポジトリの最後の状態（2.1.289）です。コミットは筆者が手で行いました。
$ git log --oneline
f257ee5 ansible-verify スキルを追加
5667c29 name[casing] を外す
b141158 NTPの参照先を3台にする
2612102 CLAUDE.md を追加
97c9de3 Initial commit~/practice の .claude/ の下は、次のとおりです。
~/practice/.claude/
├── settings.json allow・ask・deny（コミット済み）
├── settings.local.json 「常に許可」で書かれるルール（コミットされない）
└── skills/
└── ansible-verify/
├── SKILL.md
├── scripts/verify.sh
└── reference/reading-diff.md~/practice-clone（git clone で取り出したフォルダー）には、settings.json と skills/ はありますが、settings.local.json はありません。
最後の SKILL.md の frontmatter は、手順1の出来上がりに、手順4で足した言い回しと、手順6の allowed-tools を加えた形です。
---
name: ansible-verify
description: ansible-lint、構文チェック、stg への --check --diff を順に実行し、変更内容を検証する。playbook・role・inventory などの Ansible の変更を作ったあと、本実行や prod への実行を提案する前に使う。「lint 通る？」「構文を確かめて」のように、lint や構文の確認だけを頼まれたときにも使う。
allowed-tools: Bash(bash .claude/skills/ansible-verify/scripts/verify.sh *)
---
4Dで振り返る
演習を、Anthropic の AI Fluency の4D で振り返ります。4D は、連載「Claude活用入門」第6回の「AI Fluencyの4D」で紹介した、AI と協働するための枠組みです（講座：https://academy.claude.com/ja/courses/ai-fluency-framework-foundations ）。
| AI Fluencyの4D | 演習を振り返る問い |
|---|---|
| 委任（Delegation） | どこまでスキルに任せ、どこで人に返したか。発動しない依頼は、人が頼み直したか |
| 記述（Description） | description は普段の言い回し（チームなら、メンバーの言い回し）で書けたか。止まる条件を SKILL.md に書けたか |
| 評価（Discernment） | RESULT 行と changed で確かめたか。発動しない依頼、発動してほしくない依頼も試したか |
| 責任（Diligence） | 本実行と prod を人の承認に残したか。allowed-tools は狭いか。他人のスキルを読んでから使ったか |
表の日本語の訳語（委任・記述・評価・責任）は、連載「Claude Code実践入門」第9回の「4Dで振り返る」と同じ筆者の訳で、公式の日本語訳は確認できていません。
筆者の記録に当てはめると、次のとおりです。
- 委任・記述：スキルは③（
--check --diff）の結果を見せて止まり、人に返しました。「lint 通る？」は発動せず、人が言い回しを足して頼み直しました - 評価：手順3（2.1.289）の報告は「stg で確認できていないので、prod はまだ提案できない」で、verify.sh の RESULT 行（2.1.302 で確かめ直したとき）は
lint=0 syntax=0 check=4でした。どちらも、unreachable を「通った」とは言いませんでした。「本番に流して」で発動したので、発動してほしくない依頼も試す意味がありました - 責任：stg への本実行も prod への
--check --diffも、承認なしには進みませんでした。他人のスキルは、SKILL.mdとscriptsを読んでから使います（第8回の「チームで使うときの運用ルール（筆者の例）」）
自己点検
一人で振り返る点検です。演習で控えたことを、自分のスキルと設定に反映できたかを確かめます。
- 第10回の手順3・4で足した言い回しと発動しなかった依頼は何でしたか。自分の description に、普段の言い回しとして反映できていますか
- 発動してほしくない依頼（筆者の記録では「本番に流して」）で発動しませんでしたか。発動したあとに、本文が止まる形になっていましたか
- 止まった画面の文言を控えましたか。保護されたパス、
allowed-tools、未信頼のフォルダーのどれか、文言から分かりますか（第9回の「症状別チェックリスト」） allowed-toolsは verify.sh の呼び方だけに絞れていますか。自分の Claude Code の版で、事前承認が効きましたか- clone 先で動かなかったものは、コミットされるファイルで解決できましたか、各自の設定でしたか。他人のスキルは、読んでから使っていますか
- 4D のうち、一番弱かったのはどれでしたか
次に学ぶなら：サブエージェント
今回のスキルは、今の会話に手順と知識を足すものでした。サブエージェントは、別のコンテキストで動く担当で、担当ごとにモデル（model）とツール（tools）を決められます。スキルから担当を呼び分ければ、役割ごとにモデルを分けられます。たとえば、調べる担当は Haiku、書く担当と確かめる担当は Sonnet にして、判断は本体（既定の Opus 5.5）と人に残す、のような分け方です（筆者の例で、公式の推奨ではありません）。公式には、スキルの frontmatter に context: fork と agent を書いて、スキルを別のサブエージェントで動かす設定もあります。サブエージェントの定義の skills: に書いたスキルは、起動時に全文が読み込まれます。詳しくは、次の連載「Claude Codeサブエージェント入門」で扱います。
- スキル：今の会話に手順を足す
- サブエージェント：別のコンテキストで動く
- 担当ごとにモデルを分けられる
スキルの model: は、スキルが動く間のモデルを決める1行です（第2回の「frontmatter のフィールド」）。使い分けは、サブエージェント入門に回します。組み込みのサブエージェントはスキルを事前に読み込みません（https://code.claude.com/docs/ja/sub-agents ）。
公式の言い方（2026年10月時点）では、サブエージェントの model には sonnet・opus・haiku などの別名、完全なモデル ID、inherit を書けます（https://code.claude.com/docs/ja/sub-agents ）。コストのページは、簡単なサブエージェントの作業には model: haiku を勧めています（https://code.claude.com/docs/ja/costs ）。Claude Code v2.1.293 以降は、Anthropic API では haiku が Haiku 5.5 に解決されます（筆者の 2.1.302 で claude-haiku-5-5 を確認。2.1.289 では Haiku 4.5 でした）。モデルを省略したときの決まり方は、連載「Claude Codeサブエージェント入門」第5回の「モデルの決まる順番」にあります。組み込みの Explore は Haiku ではなくメインの会話のモデルで動きます（例外は、メインの会話が Fable のときだけです。連載「Claude Codeサブエージェント入門」第2回の「Explore のモデルは本体のモデル」）。
公式の教材（Claude Academy。講座の題・時間は2026年10月17日に筆者が確かめた値で、変わることがあります。レッスンごとの時間は、連載「Claude Codeサブエージェント入門」第1回の「あわせて読みたい公式の教材」にあります）
- 講座「Introduction to subagents」（サブエージェントの概要）：https://academy.claude.com/ja/courses/introduction-to-subagents 。4レッスン、コースの表示は45分（各レッスンの時間を足すと35分）
- 講座「Claude Code in action」（日本語名は「Claude Codeを実践する」）のレッスン9「プラグイン」：https://academy.claude.com/ja/courses/claude-code-in-action/plugins 。プラグインでスキルを配る話は、連載「Claude Codeチーム活用入門」第6回の「Git での共有とプラグインの違い」で扱います
スキルから担当を呼ぶ手順は、連載「Claude Codeサブエージェント入門」第7回の「スキルと担当の組み合わせ方2つ」で、この演習の ansible-verify を使って扱います。
連載の結び
この連載は、Claude Code のスキルを、同じ指示を2回打ったら作る（第1回の「繰り返す指示は、まだ書かれていないスキル」）、description は何をするかといつ使うかを、普段の言い回しで書く（第2回の「frontmatter のフィールド」、第3回の「説明は2つの問いに答える」「普段の言い回しを入れる」）、SKILL.md は短く、資料は参照ファイルに、決まった処理はスクリプトに分けて読まずに実行する（第4回の「段階的開示：SKILL.md は目次」、第7回の「scripts/verify.sh（案）」）、事前承認は狭く書く（第5回の「allowed-tools で事前承認する」、第6回の「SKILL.md（案）」）、Git で共有し、他人のスキルは読んでから使う（第8回の「共有の手順」）、動かないときは症状から切り分ける（第9回の「症状別チェックリスト」）の順に扱いました。そして、第10〜12回の演習で、検証スキルを作り、発動させ、分け、事前承認し、別のフォルダーへ取り出して、それぞれを一度ずつ手で確かめました。
筆者の記録で目立ったのは、手元で試さないと分からないことが多いという点です。「lint 通る？」は発動せず、「本番に流して」は発動し、allowed-tools の効き方は版で違いました。スキルは、言い回しを変えて試し、版が変わったら確かめ直すものです。そして、スキルは強制ではありません。必ず守らせたいことは ask・deny のルールやフックで守り、スキルは手順と知識を足すものとして使います。
まとめ
- 手順7：clone 先では、スキルのファイルは共有されるが、各自の「常に許可」（
settings.local.json）は共有されない。未信頼のフォルダーでは、プロジェクトの allow が効かない - 最後の状態：
~/practiceにはsettings.local.jsonがあり、~/practice-cloneには無い。共有されるのはSKILL.md・scripts・reference - 4D と自己点検：任せ方・書き方・確かめ方・責任の取り方を振り返り、自分のスキルと設定に反映する
- 次に学ぶなら：スキルは今の会話に手順を足し、サブエージェントは別のコンテキストで動く。次の連載「Claude Codeサブエージェント入門」へ
全12回の「Claude Codeスキル入門」は、これで終わりです。
連載「Claude Codeスキル入門」全12回
全回の目次と、読む順番・目的別の読み方は、Claude Codeスキル入門の入口のページにまとめています。
コメント