Claude Codeスキル演習（中編）：scriptsに分ける・allowed-toolsで事前承認【Claude Codeスキル入門第11回】

「allowed-tools を書いたのに、確認の画面が出たままです。書き方が悪いのでしょうか、それとも版の問題でしょうか」
「スクリプトを作らせようとしたら、.claude/ の下への書き込みで承認待ちになりました。allow を足したのに通らないのは、なぜですか」

スキルを1本作るのは、1回の演習でできます。難しいのは、確認の画面をどこまで減らしてよいかを確かめることです。

第11回は、演習の中編です。前編の第10回では、準備と、手順1〜4（作る・確かめる・発動させる）を扱いました。この回では、手順5・6（スクリプトと参照ファイルに分ける、allowed-tools で事前承認する）を扱います。手順7（コミットして別のフォルダーへ取り出す）、4D での振り返り、自己点検、次に学ぶなら、連載の結びは、後編の第12回です。各手順の後には、「筆者の環境ではこうなった」の囲みを載せます。allowed-tools の結果は、Claude Code の版で違いました。囲みに版を書きます。

この回でやること
手順5・6
1. 手順5：スクリプトと参照ファイルに分ける
2. 手順6：allowed-tools で事前承認する
考えてみよう
まとめ
連載「Claude Codeスキル入門」全12回

この回でやること

全体の流れは、第10回の図のとおりです。前編（第10回）は準備から手順4まで、この回は手順5・6、手順7以降は第12回です。手順5・6の表は、すぐ下に載せます。

囲みの版は、2.1.289（筆者の PC の CLI を非対話の claude -p で試した記録。確認の画面が出る操作は「承認が要る」として止まる）と、2.1.302（CLI を上げて allowed-tools の結果だけ確かめ直した記録）です。詳しくは第10回の「筆者の記録の読み方」を見てください。数値と仕様は2026年10月時点です。

手順5・6

手順5・6の表です。

手順	やること	確認すること
5	`scripts/verify.sh` と `reference/reading-diff.md` を Claude に作らせる（第7回の「scripts/verify.sh（案）」「reference/reading-diff.md（案）」）。SKILL.md に「読まずに実行」「差分を確かめるときだけ読む」と書かせる	RESULT 行が出たか。スクリプトの中身が会話に出なかったか。`Ansible requires blocking IO` のエラーが無いか（unreachable は想定内）
6	`allowed-tools` に verify.sh の呼び方だけを書かせ、「手動」のまま検証を頼む	verify.sh の確認が消えたか。次のメッセージで戻るか。stg の本実行・prod は確認が出るか、断られるか（確認が出たら「拒否」）

手順6の allowed-tools が効くかどうかは、画面で確かめる手順です。公式の文書には、組織の管理設定に allowManagedPermissionRulesOnly があると allowed-tools は無視される、とあります。個人の Pro・Max で管理設定があるかは、筆者は確かめていません。うまくいかない手順があったら、止まった画面の文言を控えてください。後編の第12回の「自己点検」で使います。

手順5：スクリプトと参照ファイルに分ける

scripts/verify.sh と reference/reading-diff.md を Claude に作らせ、SKILL.md の本文を「読まずに実行」「差分を確かめるときだけ読む」の形に書き直させます。verify.sh の形は、第7回の「scripts/verify.sh（案）」のとおりです。

筆者の環境ではこうなった（2.1.289：手順5）
「編集を受け入れる」で、次の3つを頼んだ。
– scripts/verify.sh：prod を含む inventory は何も実行せず RESULT skipped=prod で終わる。各コマンドに 2>&1 | cat を付け、${PIPESTATUS[0]} で Ansible 側の終了コードを取る。set -e は付けない。最後に RESULT lint=N syntax=N check=N の1行を出す。Claude は、頼んでいない「引数が2つでないときは使い方を出して終了コード2」を足した
– reference/reading-diff.md：changed の読み方、冪等性、落とし穴
– SKILL.md の本文の書き直し：「verify.sh を中身を読まずに実行する」「RESULT 行に 0 以外があれば、原因を直して再実行する（3回まで）」「差分を確かめるときだけ reading-diff.md を読む」「報告して止まる」

settings.local.json に Write(./.claude/skills/**)・Edit(./.claude/skills/**) の allow を足しても、.claude/ の下への書き込みは承認待ちのままだった（保護されたフォルダーは、allow のルールでも自動では通らない。第10回の「手順1：スキルを作らせ、出来上がりを読む」）。許可の設定は外し、Claude が示した中身を筆者が置いた。
そのあと「検証して」と頼んだ（allowed-tools はまだ無い）。スキルは発動した。bash .claude/skills/ansible-verify/scripts/verify.sh inventory/stg/hosts.ini site.yml は allow に無いので承認待ちになった。Claude は許可済みの個別のコマンドに切り替え、blocking IO を避けるためにファイルへのリダイレクトで lint・syntax・check を実行し、ログを読んで報告した。スクリプトの中身は、会話に出なかった（Claude は読んでいない）。
確認項目への答え：RESULT 行は、verify.sh が実行されなかったので、この時点では出なかった（RESULT 行が出たのは 2.1.302 で確かめ直したとき。下の手順6の囲み）。Ansible requires blocking IO のエラーが出たかどうかは、記録に残していない（Claude は最初からファイルへのリダイレクトで実行した）。

verify.sh が承認待ちになるのは、.claude/settings.json の allow に、この呼び方が無いからです。手順6で、allowed-tools に書いて事前承認します。

手順6：allowed-tools で事前承認する

allowed-tools に verify.sh の呼び方だけを書かせ、「手動」のまま検証を頼みます。verify.sh の確認が消えたか、次のメッセージで戻るか、stg の本実行や prod は確認が出るか断られるかを確かめます。確認が出たら「拒否」します。

公式の文書は、allowed-tools を「スキルを呼んだターンの間、書いたツールを確認なしで使える」ものと書いています（https://code.claude.com/docs/ja/skills の「Pre-approve tools for a skill」）。第5回の「allowed-tools で事前承認する」で見たとおり、事前承認であって制限ではなく、書いていないツールは通常の権限設定で扱われます。

筆者の環境ではこうなった（2.1.289：手順6）
frontmatter に次の1行を足した。

allowed-tools: Bash(bash .claude/skills/ansible-verify/scripts/verify.sh *)

「検証して」と頼むと、今度はスキルの呼び出しそのものが承認待ちになった（記録の文言は「Execute skill: ansible-verify」）。allowed-tools を書いたスキルは、呼ぶ時点で承認を求めると見られる。Claude は、個別のコマンドで検証した。
このとき、; echo "== exit: ${PIPESTATUS[0]}" を付けたコマンドには「A variable in braces in this command can’t be checked before it runs」、; echo "== exit: $?" には「This Bash command contains multiple operations. The following part requires approval: echo “== exit: $?”」と出た（$? の展開で確認になる点は、連載「Claude Code実践入門」第6回の「前方一致の落とし穴と、denyの限界」の実測と同じ）。
settings.local.json に Skill(ansible-verify) の allow を足した（画面で「常に許可」を選ぶのに当たる）。スキルは確認なしで発動したが、verify.sh の実行は、allowed-tools があっても承認待ちのままだった。Claude はまた個別のコマンドに切り替えた。
「検証が終わったら、stg に本実行して」と頼むと、スキルは発動し、verify.sh は承認待ちで、個別の検証までで止まった。本実行には進まなかった。
「prod でも --check --diff して」と頼むと、スキルは発動せず、ansible-playbook --check --diff -i inventory/prod/hosts.ini … は ask のルールで承認待ちになった（フルパスやリダイレクトに書き換えた形も承認待ち）。

2.1.302 で確かめ直した結果
settings.local.json に Skill(ansible-verify) の allow がある状態で「検証して」と頼むと、スキルが確認なしで発動し、git diff roles/ntp/tasks/main.yml; bash .claude/skills/ansible-verify/scripts/verify.sh inventory/stg/hosts.ini site.yml が承認なしで実行された。allowed-tools に書いた verify.sh の呼び方が、事前承認として効いた。出力の最後は次のとおり（check の 4 は unreachable）。

RESULT lint=0 syntax=0 check=4

Skill(ansible-verify) の allow を外すと、2.1.302 でもスキルの呼び出しが承認待ちになった（allowed-tools を書いたスキル）。Claude は個別のコマンドで検証した。

この違いについて、公式の文書と変更履歴には、次の記述があります（2026年10月時点）。

公式の skills のページ：「allowed-tools は、スキルを呼んだターンの間、書いたツールの権限を与える」（https://code.claude.com/docs/ja/skills ）。同じページは、この許可は次のメッセージを送るとクリアされる、とも書いています（「Skill content lifecycle」。第5回の「allowed-tools で事前承認する」）。「次のメッセージで戻るか」を、筆者は試していません
変更履歴の 2.1.295：「Skill ツールが、応答のストリームが終わる前に終了したとき、スキルの allowed-tools と effort が落とされ、-p での実行でスキルの Bash コマンドが拒否されていた不具合を直した」（https://code.claude.com/docs/en/changelog ）。2.1.289 の -p で verify.sh が承認待ちのままだったのが、この不具合によるのかは、筆者は確かめていません
「スキルの呼び出しそのものが承認待ちになる」ことを書いた公式の記述は、筆者は見つけられていません（実測では、どちらの版でも同じでした）
allow と ask は、公式の permissions のページに「ルールは deny、ask、allow の順に評価され、最初に一致したものが結果を決める」とあります。prod への実行を ask で守り、allowed-tools には verify.sh だけを書く（第5回の「allowed-tools と権限ルールの関係」）のは、この順序と合っています（https://code.claude.com/docs/ja/permissions ）

Code タブでの allowed-tools の振る舞いは、筆者は確かめていません。自分の版で確かめるのが確実です。また、公式の文書は、Bash のルールを Claude が書いたコマンドの文字列に一致させるものと書いています。スクリプトの中で動くコマンドを個別に確かめられるとは限らないので、verify.sh は prod を含む inventory をスクリプト自身で拒む形にしました（第7回の「呼び方と、スクリプトの中のコマンド」）。

考えてみよう

手順5で、settings.local.json に Write(./.claude/skills/**) の allow を足しても、.claude/ の下への書き込みが承認待ちのままだったのは、なぜでしょうか。
筆者の記録では、allowed-tools を書いた verify.sh が、2.1.289（-p）では承認待ちのままで、2.1.302 では確認なしで実行されました。自分の環境で事前承認が効くかを確かめるには、どの手順で、何を見ますか。
allowed-tools に verify.sh の呼び方だけを書いて、stg の本実行や prod の --check --diff は書きませんでした。書かなかったものは、どう扱われましたか。

ヒント：1つ目は手順5の囲み（第10回の手順1も）、2つ目は手順6の囲みの、2.1.289 と 2.1.302 の結果、3つ目は手順6の囲みの、stg の本実行と prod を頼んだ結果を見直してください。

まとめ

手順5：verify.sh と reference/reading-diff.md に分け、SKILL.md を「読まずに実行」「差分を確かめるときだけ読む」の形にする。.claude/ の下への書き込みは、allow を足しても承認待ち
手順6：呼んだ後の verify.sh は、2.1.289（-p）では承認待ちのまま、2.1.302 では確認なしで実行された。公式は「スキルを呼んだターンの間」の事前承認と書く。自分の版で確かめる
手順6：stg への本実行を頼んでも本実行には進まず、prod への --check --diff は ask のルールで承認待ちになった。allowed-tools は事前承認であって制限ではないので、verify.sh の呼び方だけに絞って書く

次回の第12回は、演習の後編として、手順7（コミットして別のフォルダーへ取り出す）、早く終わった人、最後の状態、4D での振り返り、自己点検、次に学ぶなら、連載の結びを扱います。