【Claude Codeスキル入門 第10回】演習（前編）― 準備プロンプト、スキルを作らせる、一覧に出るか、言い回しで発動するか

「スキルの書き方は分かりましたが、自分の環境で本当に発動するのか、試してみないと不安です」
「description を書いたのに、「lint 通る？」と頼んだときだけ発動しません。どの言い回しなら発動するのか、どうやって確かめればよいのでしょうか」

スキルは、読んだだけでは身につきません。書いたスキルが一覧に出るか、どの頼み方で発動するか、発動したあとに何を確認されるかは、実際に頼んでみないと分かりません。

第10〜12回は、この連載の演習です。連載「Claude Code実践入門」の演習で作った練習用のリポジトリ（~/practice）に、検証スキル ansible-verify を作らせ、発動させ、スクリプトに分け、事前承認を試し、Git で別のフォルダーへ取り出します。全体で約30分です。前編の第10回では、準備（モデルとモード・準備プロンプトの全文）と、手順1〜4（作る・確かめる・発動させる）を扱います。手順5・6（分ける・事前承認）は中編の第11回、手順7、早く終わった人、4D での振り返り、自己点検、次に学ぶなら、連載の結びは、後編の第12回です。各手順の後には、「筆者の環境ではこうなった」の囲みを載せます。

---

この回でやること

演習は、前の連載で作った ~/practice を使います。流れは次の図のとおりです。

演習の画面は、Claude デスクトップアプリの Code タブを前提に書きます。CLI の操作は「CLI では」と添えます。数値と仕様は2026年10月時点です。

---

筆者の記録の読み方

各手順の後に、「筆者の環境ではこうなった」の囲みを付けます。筆者が試した記録は、次の環境のものです。

• 2026-10-18、筆者の PC（Ubuntu 26.04.1）、ansible-core 2.20.1、ansible-lint 26.1.1、個人のアカウント。Claude Code 2.1.289 の CLI を、対話の画面ではなく非対話の claude -p で試しました。モデルは指定せず既定の Opus 5.5、モードは --permission-mode default（「手動」）です。~/practice は、連載「Claude Code実践入門」の演習の後の状態（NTP の参照先は3台、.ansible-lint で name[casing] を外してある、CLAUDE.md は英語で22行）を引き継ぎました
• そのあと CLI を 2.1.302 に上げ、事前承認（allowed-tools）の結果だけ確かめ直しました。囲みには、どちらの版の結果かを書きます。確かめ直した分は、中編の第11回で載せます

確認の画面が出る操作は、-p では「承認が要る」として実行されずに終わります（Code タブなら確認の画面が出る所です）。囲みで「承認が要って止まった」とあるのは、この意味です。-p は毎回新しい会話なので、手順の「/clear を挟む」「新しいセッションで頼む」は、囲みでは「新しいセッションで」と書きます。

Code タブと CLI の操作の対応は、次のとおりです。

操作	Code タブ	CLI（対話）	-p（筆者の記録）
一覧に出るかを聞く	「利用可能なスキルは？」と聞く	同じ。/skills でも見られる	「利用可能なスキルは？」と聞く。/skills は使えない（手順2の囲み）
会話を切り替える	/clear	/clear	毎回新しい会話になる
確認の画面	確認の画面が出る	確認の画面が出る	承認が要るものは拒否される

Code タブで /skills や /reload-skills が使えるかは、公式の文書に提供の注記が見つからず、筆者は確かめていません。

費用の目安は、-p が表示する値（API の定価で換算した値）で、1回あたり 0.12〜0.25 ドルでした。Pro・Max では、この金額が請求されるのではなく、使用量の枠から引かれます。

---

準備

用意するもの

• ~/practice：連載「Claude Code実践入門」第8回の「準備」で作った、練習用のリポジトリ（自分専用の検証用 Linux ホスト、または「ローカル」。ansible-core と git が入っていて、できれば ansible-lint も入っている）。無い人は、第8回の「準備プロンプト」で先に作ります（環境の選び方は「環境を選ぶ」）。本番や共用のホストは使いません
• モデルとモード：最初のプロンプトを送る前に、入力欄の下を「手動」・既定のモデル（Opus 5.5）・Effort は中にします。うまくいかなければ、モデルを替えずに Effort を high に上げて比べます（連載「Claude Code実践入門」第8回の「モデルとモード」、第1回の「モデルとEffortの選び方（公式の推奨）」）。v2.1.283 以降、CLI と VS Code では新しいセッションが「自動」（auto mode）から始まるので、演習では確認の画面を見るために「手動」に切り替えます
• スキル用の準備：下の準備プロンプトを、~/practice を開いたセッションで送ります。.claude/skills が無い状態に整います（前に自分でスキルを作っていた人は、.claude/skills.bak に退避されます）
• 進め方：手順1〜4（この回）、手順5・6（第11回）、手順7（第12回）を順に進めます。足した言い回し、発動しなかった依頼、詰まったところを控えておくと、第12回の自己点検で使えます

ホストの中は、Claude があなたのユーザーの権限で操作します。自分専用の検証用ホストで行い、ほかの人と共用しているホストや本番のホストでは行わないでください。Ansible のコマンドを Claude に直接実行させるときは 2>&1 | cat を付けさせ、成否は PLAY RECAP で見ます（連載「Claude Code実践入門」第8回の準備プロンプトの「読者向けの注意」）。

想定される結果

• ホストは文書用アドレス（192.0.2.x）なので、--check は unreachable になります（ansible-playbook の終了コードは4）。RESULT 行の check が 0 にならないのは想定内です。見るのは、スキルが発動し、証拠を出して止まるところです
• ansible-lint は、前の連載で .ansible-lint の skip_list に name[casing] を入れていれば通ります。入れていない場合は name[casing] の指摘が1件出て、ansible-lint が入っていない場合も、lint は 0 になりません。どちらも、スキルの動きは確かめられるので、そのまま進めてかまいません

準備プロンプト

~/practice を、スキルがまだ無い状態に整えます。新しいファイルは作りません。

使い方

1. 自分の環境（登録した SSH ホスト、または「ローカル」）で、~/practice を開いた新しいセッションを作る
2. 最初のプロンプトを送る前に、入力欄の下を「手動」・既定のモデル（Opus 5.5）・Effort は中にする
3. 下のプロンプトをそのまま送る。確認が出たら、内容を見てから「一度だけ許可」を選ぶ
4. 報告を見て、.claude/skills が無いこと、作業ツリーがきれいなことを確かめる（git status --short に変更が出て止まったら、前の連載「Claude Code実践入門」の演習の変更です。中身を確かめてからコミットし（筆者のコミットは実践入門 第9回の「最後の状態」）、新しいセッションでもう一度送ります）
5. /clear してから、手順1を始める

送るプロンプト

スキルの演習の準備をしてください。書いてあること以外はしないでください。コマンドの前後に何も付け足さないでください。終了コードは報告しなくてよいです。
1. git status --short を実行し、結果をそのまま報告する。何か出ていたら、ここで止まって私に聞く
2. .claude/skills があるかを ls -d .claude/skills で確かめる。無ければ手順4へ進む
3. .claude/skills があれば、git mv .claude/skills .claude/skills.bak を実行し、git commit -m "スキルの演習の前にスキルを退避" を実行する
4. ls -a .claude と git log --oneline -3 を実行し、結果をそのまま報告する
5. 最後に、ansible-playbook --version 2>&1 | cat の1行目と、ansible-lint --version 2>&1 | cat の1行目を報告する（見つからないときは、見つからないと報告する）

読者向けの注意

• ~/practice をそのまま使います。.claude/settings.json の allow・ask・deny（inventory/prod を指す実行は ask、ansible-vault view は deny）は、第11回の手順6で allowed-tools との関係を見るのに使うので、変えないでください（連載「Claude Code実践入門」第6回の「Ansibleの作業での設定例（筆者の例）」と同じ設定です）
• ansible-lint の name[casing] は、英小文字で始まるタスク名（chronyの…）だけが指摘され、日本語の文字で始まる名前は指摘されません（筆者の実測、ansible-lint 26.1.1。連載「Claude Code実践入門」第4回の「補足：日本語のタスク名と ansible-lint の name[casing]」）。前の連載で .ansible-lint に skip_list を入れた ~/practice（連載「Claude Code実践入門」第9回の「早く終わったら」）なら lint は通ります

筆者の環境ではこうなった（2.1.289：準備）
準備プロンプト（筆者が送った版。回の呼び方と退避先の名前だけが上の全文と違う）を「手動」で送った。手順1の git status --short は何も出なかった。手順2の .claude/skills は無かったので、手順3は飛ばした。
手順4：ls -a .claude には settings.json だけがあり、git log --oneline -3 は「5667c29 name[casing] を外す」「b141158 NTPの参照先を3台にする」「2612102 CLAUDE.md を追加」だった。
手順5：ansible-lint --version 2>&1 | cat は ansible-lint 26.1.1 using ansible-core:2.20.1 … と出た。ansible-playbook --version 2>&1 | cat は allow に無いので承認待ちになり、実行されなかった。Claude は「見つからなかったわけではない。承認すれば実行する」と報告した。

---

手順1〜4

手順1〜4の表と、各手順の後の筆者の記録です。手順5・6は第11回、手順7と「早く終わった人」は第12回で扱います。

手順	やること	確認すること
1	Claude に、ansible-lint・--syntax-check・stg への --check --diff の3つ（連載「Claude Code実践入門」第7回の「Ansibleでの検証の型」の①〜③）を .claude/skills/ansible-verify/SKILL.md にするよう頼む。出来上がりの frontmatter と本文を読む	第3回の「発動しない説明と発動する説明」の description の例と比べる（verify.sh・allowed-tools は手順5・6（第11回）で足す）。.claude/ への書き込みで確認が出たか。どの選択肢が出たか
2	同じセッションで「利用可能なスキルは？」と聞く。出なければ /reload-skills（候補に無ければ飛ばす）、次に新しいセッションで聞く。/skills も試す	どの段階で一覧に出たか。名前・説明・場所が見えたか
3	/clear を挟みながら、「検証して」「lint 通る？」「stg で差分を見て」と1つずつ頼む。「本番に流して」も試す（確認が出たら「拒否」）	どれで発動したか。画面にスキル名が出たか。確認の画面の文言。「本番に流して」で発動しないか
4	発動しなかった言い回しを description に足し、/clear して頼み直す	発動するようになったか。足した言い回しの控え

手順1：スキルを作らせ、出来上がりを読む

Claude に、検証の3つの手順を .claude/skills/ansible-verify/SKILL.md のスキルにするよう頼みます。頼み方の例は次のとおりです。Claude は連載の回を知らないので、①〜③はコマンドで書きます。

次の検証の手順を、.claude/skills/ansible-verify/SKILL.md のスキルにして。①ansible-lint ②ansible-playbook --syntax-check -i inventory/stg/hosts.ini site.yml ③ansible-playbook --check --diff -i inventory/stg/hosts.ini site.yml。各コマンドには 2>&1 | cat を付ける。③の結果を見せたら止まり、本実行と inventory/prod への実行は書かない。description には、何をするかといつ使うかを書く。

.claude/ の下への書き込みで確認が出たか、どの選択肢が出たかも控えておきます。.claude は保護されたパスで、公式の文書では、「手動」でも「編集を受け入れる」でも確認になります。確認の画面には、そのセッションの間だけ .claude フォルダーの編集を許す選択肢（公式の英語の文言は「Yes, and allow Claude to edit files in this project’s .claude folder for this session」）が出るとあります（https://code.claude.com/docs/en/permission-modes ）。設定ファイルの permissions.allow のルールは、保護されたパスへの書き込みを事前承認しません（同じページの「Protected paths」）。保護されたパスは、連載「Claude Code実践入門」第5回の「6つの権限モード」の「モードごとの補足」にもあります。

筆者の環境ではこうなった（2.1.289：手順1）
.claude/skills/…/SKILL.md への書き込みは、「手動」でも「編集を受け入れる」でも承認待ちになった（.claude は保護されたフォルダー）。Claude は書く予定の中身を示して「許可してもらえれば書き込む」と報告した。-p には確認の画面が無いので、筆者はその中身をそのまま置いた（画面で「一度だけ許可」を選ぶのと同じ）。
出来上がりは31行。本文は3つのコマンド（2>&1 | cat 付き）と、「途中のステップが失敗したら、そこで止めて結果を報告する」「③の結果をユーザーに見せたら、ここで止まる」だった。「手動」の1回目は、頼んでいない「途中で失敗したら止める」「本実行と prod を禁止事項として書く」の2点を足した、と Claude が自分から報告した。
出来上がりの frontmatter は次のとおり。

---
name: ansible-verify
description: ansible-lint、構文チェック、stg への --check --diff を順に実行し、変更内容を検証する。playbook・role・inventory などの Ansible の変更を作ったあと、本実行や prod への実行を提案する前に使う。
---

この description は、何をするか（lint・構文チェック・stg への --check --diff）と、いつ使うか（Ansible の変更を作ったあと、本実行や prod の前）は書けています。一方、第3回の「発動しない説明と発動する説明」にある良い例の頼み方の言い回し（「検証して」など）は入っていません。手順3で「lint 通る？」が発動しなかった理由の1つと見られます（筆者の見方で、確かめてはいません）。

手順2：一覧に出るかを確かめる

表のとおり、一覧に出るかを見ます。どの段階で一覧に出たか、名前・説明・場所が見えたかを控えます。

公式の文書には、スキルの追加・編集は同じセッションの中で再起動なしに拾われるとあります。ただし、セッションを始めたときに無かったトップレベルの skills フォルダー（この演習の .claude/skills がそれに当たります）を作ったときは、/reload-skills で拾わせるとあります（https://code.claude.com/docs/ja/skills の「Edit a skill during a session」）。

筆者の環境ではこうなった（2.1.289：手順2）
新しいセッション（-p は毎回新しい）で「利用可能なスキルは？」と聞くと、「このプロジェクト専用」の見出しの下に ansible-verify が名前と説明つきで出た（ほかの組み込みのスキルと並んで）。
/skills は -p では「/skills isn’t available in this environment.」と出て使えなかった。同じセッションの中での反映（/reload-skills）は、筆者は試していない。

手順3：言い回しを変えて発動させる

表のとおり、4つの頼み方を1つずつ試します（確認が出たら「拒否」）。どれで発動したか、画面にスキル名が出たか、確認の画面の文言、「本番に流して」で発動しないかを控えます。

筆者の環境ではこうなった（2.1.289：手順3）
依頼ごとに新しいセッションで試した。発動したかは、Skill ツールの呼び出しが記録に出たかで見た。Code タブでの表示は、筆者は確かめていない。

依頼	発動	起きたこと
検証して	した	Skill を呼び、lint・syntax-check・--check --diff（2>&1 | cat 付き）を実行した。lint は通過、syntax は通過、check は 192.0.2.11 への SSH がタイムアウト（unreachable）。「stg で確認できていないので、prod はまだ提案できない」と報告した
lint 通る？	しなかった	ansible-lint 2>&1 | tail -40 を直接実行し、.ansible-lint の skip_list も読んで「はい、通ります」と答えた
stg で差分を見て	した	上と同じ3段。check は unreachable だった
本番に流して	した（想定と違った）	description の「本実行や prod への実行を提案する前に使う」に一致したと見られる。stg の3段を実行して止まり、「CLAUDE.md で本番の前に stg の --check --diff を通すと決まっている。stg を直してから確認し直すか、了承があれば prod に --check --diff を流す」と2択を返した。本番には流さなかった

「本番に流して」でも、スキルの本文に「③の結果を見せたら止まる」と書いてあったので、発動したあとは本番に進まず、証拠を見せて止まった。発動してほしくない依頼に発動するかどうかは、description の「いつ使うか」の書き方しだいで変わる。第12回の「4Dで振り返る」の「評価」で、もう一度振り返る。

手順4：発動しなかった言い回しを足す

発動するようになったか、足した言い回しの控えを残します。

筆者の環境ではこうなった（2.1.289：手順4）
description の末尾に、「「lint 通る？」「構文を確かめて」のように、lint や構文の確認だけを頼まれたときにも使う。」を足した。新しいセッションで「lint 通る？」と頼むと、発動した（lint・syntax-check・--check --diff の3段とも実行された）。
「lint 通る？」には lint だけで足りるが、3段とも実行された。スキルの本文が3段を順に実行する形だからと見られる。

---

考えてみよう

1. 手順1で .claude/skills/ansible-verify/SKILL.md の書き込みに確認が出たのは、なぜでしょうか。「編集を受け入れる」に切り替えても出るのは、なぜでしょうか。
2. 手順3で、「lint 通る？」は発動せず、「検証して」は発動しました。description に何が書いてあれば、「lint 通る？」でも発動したでしょうか。
3. 「本番に流して」で発動してしまいました。これを防ぎたいときは、description と SKILL.md の本文のどちらに何を書きますか。

ヒント：1つ目は手順1の「保護されたパス」の説明、2つ目は手順4の足した言い回し、3つ目は手順3の囲みと、第3回の「普段の言い回しを入れる」を見直してください。

---

まとめ

• 準備：~/practice を、「手動」・既定のモデル・Effort 中で開き、準備プロンプトで .claude/skills が無い状態に整える。ホストは文書用アドレス（192.0.2.x）なので、--check は unreachable になるのが想定内
• 手順1：.claude/ への書き込みは保護されたパスで、「手動」でも「編集を受け入れる」でも確認が出る。allow のルールでも自動では通らない
• 手順2：筆者の記録では、新しいセッションで「利用可能なスキルは？」と聞くと、名前と説明つきで一覧に出た
• 手順3：「検証して」「stg で差分を見て」は発動し、「lint 通る？」は発動しなかった。「本番に流して」は発動したが、本番には進まず止まった
• 手順4：発動しなかった言い回しを description に足すと、発動した

次回の第11回は、演習の中編として、手順5・6（スクリプトと参照ファイルに分ける・allowed-tools で事前承認する）を扱います。

---

連載「Claude Codeスキル入門」全12回

全回の目次と、読む順番・目的別の読み方は、Claude Codeスキル入門の入口のページにまとめています。

1. スキルとは何か
2. SKILL.mdを書く
3. 発動する説明を書く
4. 複数のファイルに分ける
5. スクリプトとallowed-tools
6. 検証スキルを作る（前編）
7. 検証スキルを作る（後編）
8. Gitでチームに共有する
9. うまく動かないとき
10. 演習（前編）：作る・確かめる・発動させる（この記事）
11. 演習（中編）：分ける・事前承認
12. 演習（後編）：共有と振り返り