【Claude Codeスキル入門 第5回】スクリプトとallowed-tools ― スクリプトは読まずに実行、事前承認の効き方、権限ルールとの関係、筆者の実測

「スクリプトをスキルのフォルダーに置いたら、Claude は毎回その中身を読んで、トークンを使うのですか」
「allowed-tools を書いたのに、確認の画面が出ました。効いていないのですか」

第4回（複数のファイルに分ける）では、SKILL.md を目次にして、詳しい資料を別のファイルに分けました。分けるものには、文書のほかに、実行するコード（スクリプト）があります。スクリプトは、文書とは扱いが違います。読まずに実行できるからです。

もう1つ、スキルには allowed-tools という frontmatter の項目があり、スキルが使うコマンドの確認を省けます。ただし、どこまで・いつまで効くのかは、公式の文書の記述と、筆者が実際に試した結果とで、分けて見る必要がありました。

第5回では、スクリプトを読まずに実行させる書き方、allowed-tools による事前承認、権限ルール（allow・ask・deny）との関係、そして筆者が CLI の claude -p で試した結果を扱います。数値・仕様は2026年10月時点です。

---

スクリプトは読まずに実行させる

スキルのフォルダーに置いたスクリプトは、中身をコンテキストに読み込まずに実行できます。会話に入るのは実行した出力だけなので、トークンを使うのは出力の分だけです。

向いているのは、次のような操作です。

• 環境の確認
• 決まった変換
• Claude がその場で書いたコードより、テスト済みのコードのほうが信頼できる操作

SKILL.md に書く大事な一言は、スクリプトを「読むのではなく実行する」ことです。「このスクリプトを実行する」と書けば、Claude は中身を開かずに走らせ、出力だけを受け取ります。Platform のベストプラクティスは、スクリプトを実行させるのか（最も一般的）、複雑なロジックの参考として読ませるのかを、指示にはっきり書くよう求めています。

公式の文書も、同じことを書いています。

• Platform（Anthropic の API ドキュメント）のスキルの説明：スクリプトは bash で実行され、出力だけがコンテキストに入る
• Platform のベストプラクティス：多くのユーティリティのスクリプトでは、読むより実行のほうが確実で効率的。指示も「analyze_form.py を実行してフィールドを取り出す」（実行）と「抽出のアルゴリズムは analyze_form.py を見る」（参考として読む）のように、どちらかが分かる書き方にする
• Claude Code の公式の文書の例：補助のスクリプト（helper.py）は「実行する。読み込まない」と注釈が付いている

Academy の講座「Introduction to agent skills」の言い方も同じで、スクリプトが実行され、出力のみがトークンを消費する、SKILL.md に含めるべき大事な指示は、Claude にスクリプトを読むのではなく実行するよう伝えること、としています。

環境の癖も、スクリプトの中へ（案）

連載「Claude Code実践入門」の演習では、Ansible のコマンドを Claude Code から実行すると、次のエラーで止まることがありました。

ERROR: Ansible requires blocking IO on stdin/stdout/stderr. Non-blocking file handles detected: …

コマンドに 2>&1 | cat を付けるか、出力をファイルにリダイレクトすると動きます。ただし、| cat を付けると、終了コードが cat の0になるので、成否は PLAY RECAP などで判断する必要があります（連載「Claude Code実践入門」第4回の「書くこと・書かないこと」、第7回の「Ansibleでの検証の型」）。

この 2>&1 | cat と終了コードの癖を、スクリプトの中に閉じ込めるのが、この連載の案です。Claude は毎回この癖を思い出さなくてよく、スクリプトが最後に結果を1行にまとめて返します。作り方は第7回の「scripts/verify.sh（案）」で扱い、効くかどうかは第11回の手順5・6で確かめます。

補足：エラー文の全文は、ansible-core のソース（check_blocking_io()、v2.20.1 と devel）にあります。ドキュメントではなくソースの文言です。

• 実行すると、トークンを使うのは出力だけ
• SKILL.md に「読まずに実行する」と書く
• 2>&1 | cat の癖もスクリプトの中へ（案）

---

allowed-tools で事前承認する

allowed-tools は、スキルの frontmatter に書く項目です。公式の文書の説明に沿って、働きを整理します。

• 働き：スキルを呼んだターンの残りの間、書いたツールを確認なしで使える。次のメッセージを送るとクリアされる（スキルをもう一度呼べば、そのターンにまた効く）
• 制限ではない：書いていないツールも、通常の権限設定で使える。使えなくするのは disallowed-tools（スキルが有効な間、リストしたツールを Claude が使えるものから外す。これも次のメッセージでクリアされる）
• 書き方：allowed-tools: Bash(git status *) Bash(git diff *) のように、ツールとパターンを並べる
• Bash だけは書かない：一般のシェルコマンドを事前承認してしまう。Bash(git status *) のように絞る。ansible-verify は、verify.sh の呼び方だけ（第6回の「SKILL.md（案）」）
• 省略したとき：何も事前承認されず、通常の権限のまま

公式の文書の例は、allowed-tools: Bash(git add *) Bash(git commit *) Bash(git status *) のように、ツールとパターンを空白で区切って並べる形です。

同じ文書には、スキルに同梱したスクリプトを確認なしで動かす書き方もあります。${CLAUDE_SKILL_DIR}（スキルのフォルダー）と ${CLAUDE_PROJECT_DIR}（プロジェクトのフォルダー）は、スキルの本文と、allowed-tools の Bash のルールの2か所で置き換えられます。同じ変数を両方に使うと、同梱のスクリプトを確認なしで実行できる、という例です。

---
name: render-chart
description: Render a chart from a CSV file
allowed-tools: Bash(${CLAUDE_SKILL_DIR}/scripts/render.sh *)
---

Run `${CLAUDE_SKILL_DIR}/scripts/render.sh <csv-file>` to render the chart.

（公式の文書の例）筆者は、この ${CLAUDE_SKILL_DIR} の形は試していません。次の「筆者が試したら」は、リポジトリ直下からの相対パス（bash .claude/skills/ansible-verify/scripts/verify.sh …）の形です。

Code タブの「手動」で、確認が出なくなるか、次のメッセージで戻るかは、筆者は Code タブでは確かめていません。CLI の claude -p で確かめたことは、「筆者が試したら」の節に載せます。

補足：出典は https://code.claude.com/docs/ja/skills （Pre-approve tools for a skill）と、Academy の講座「Introduction to agent skills」のレッスン3です。講座の紹介文は allowed-tools を「制限」と書きますが、レッスンの本文と公式の文書は、制限ではなく事前承認としています。

組織のプランの補足

Team・Enterprise などの組織のプランでは、管理者が管理設定（managed settings）で allowManagedPermissionRulesOnly を設定できます。公式の文書によると、これが設定されていると、プロジェクトと個人のスキルの allowed-tools は無視され、スキルが挙げたツールは、組織の管理ルールと通常の確認の画面を通ります。個人の Pro・Max で管理設定が使われているかどうかは、筆者は確かめていません。

---

allowed-tools と権限ルールの関係

権限ルール（allow・ask・deny）と allowed-tools は、どちらも「確認の有無」に関わりますが、書く場所と効く時間が違います。

項目	権限ルール	allowed-tools
書く場所と効く時間	.claude/settings.json。いつも効く	スキルの frontmatter。呼んだターンの間だけ
働き	allow・ask・deny で決める（連載「Claude Code実践入門」第6回の「allow・ask・denyルールの書き方」）	確認を省く（事前承認）
管理設定との関係	管理設定のルールが最優先。deny は他の階層で許可できない（公式）	組織が allowManagedPermissionRulesOnly を設定すると無効（公式）
ask・deny と重なるとき	一致すれば確認・拒否。評価の順は deny、ask、allow で、最初に一致したもので決まる（公式）	どちらが勝つかを直接書いた公式の記述は、筆者は見つけられていない。筆者は確かめていない
スクリプトの中のコマンド	Claude が実行するコマンドの文字列に前方一致で調べる（連載「Claude Code実践入門」第6回の「前方一致の落とし穴と、denyの限界」）	verify.sh の中のコマンドは個別には調べられない前提にする。この趣旨の公式の記述は、筆者は見つけられていない
筆者の書き方（案）	prod・Vault は ask・deny で守る	verify.sh の呼び方だけ書く。ask・deny で守るものは書かない

補足：出典は https://code.claude.com/docs/ja/skills と https://code.claude.com/docs/ja/permissions です。スキル自体の許可・拒否は Skill(名前) の形で書きます。Skill(名前) は完全一致、Skill(名前 *) は前方一致で、たとえば Skill(deploy *) は前方一致です。CLI では /permissions でルールを見られますが、Code タブでは /permissions が使えないので、.claude/settings.json に書きます（連載「Claude Code実践入門」第5回の「Code タブでの権限の操作」）。

表のうち、次の3点を補います。

• 管理設定との関係：公式の文書は、権限ルールは他の設定と同じ優先順位に従い、管理設定が最も高く、コマンドライン引数を含めて、どの階層も管理設定の権限ルールを上書きできない、と書いています。どこかの階層で deny されたものは、ほかの階層では許可できません
• ask・deny と重なるとき：権限ルール同士の評価の順は、deny、ask、allow です。最初に一致したものが結果を決め、ルールの具体性は順番を変えません。広い deny は、より狭い allow と同時に一致しても、そのコマンドを止めます。ask と allow の間も同じで、一致する ask は、より具体的な allow があっても確認を出します。allowed-tools がこの流れにどう乗るかは、公式の文書に直接の記述が見つからないため、筆者は断定しません。だから筆者の書き方（案）では、ask・deny で守りたいものは allowed-tools に書かず、権限ルールのほうで守ります
• スクリプトの中のコマンド：公式の文書は、Bash のルールは、Claude Code が複合コマンドを分け、ラッパーを外したあとの、Claude が書いたコマンドの文字列に一致するものと説明しています。スクリプトの中で動くコマンドが個別に調べられるとは書かれていないので、筆者は「調べられない前提」で設計します。危ない操作は、スクリプト自身で止めるようにします（verify.sh が prod を含む inventory を拒む形は、第7回の「呼び方と、スクリプトの中のコマンド」で扱います）

---

筆者が試したら：allowed-tools はいつ効いたか

公式の文書の説明は、「呼んだターンの間、書いたツールが確認なしで使える」です。この説明と、筆者が試した結果を、分けて見てください。

筆者の環境ではこうなった（CLI の claude -p）
2026-10-18、筆者の PC（Ubuntu 26.04.1、ansible-core 2.20.1、ansible-lint 26.1.1）で、Claude Code の CLI を、対話の画面ではなく、非対話の claude -p で試しました。モデルは既定（Opus 5.5）、権限モードは「手動」に当たる --permission-mode default です。フォルダーは、連載「Claude Code実践入門」の演習で作った練習用のリポジトリ（.claude/settings.json の allow・ask・deny を引き継いだもの）です。最初は 2.1.289 で試し、その後 CLI を 2.1.302 に上げて、確かめ直しました。
確認の画面が出る操作は、-p では「承認が要る」として実行されずに終わります（対話の画面なら、確認が出る所です）。以下の「承認待ち」は、この意味です。

筆者が試した順に、ansible-verify（第6回・第7回で作るスキル。第6回の「SKILL.md（案）」、第7回の「scripts/verify.sh（案）」）の allowed-tools を使って見たものです。

状況	2.1.289	2.1.302
allowed-tools を書く前に、スキルを呼ぶ	確認なしで発動した	試していない
allowed-tools: Bash(bash .claude/skills/ansible-verify/scripts/verify.sh *) を書いたスキルを呼ぶ	スキルの呼び出しそのものが承認待ちになった（記録にあった文言は「Execute skill: ansible-verify」）	同じ。Skill(ansible-verify) の allow が無いと、スキルの呼び出しが承認待ちだった
Skill(ansible-verify) を .claude/settings.local.json の allow に入れて呼ぶ（画面で「常に許可」を選ぶのに当たる）	スキルは確認なしで発動した。ただし verify.sh の実行は承認待ちのままだった	スキルは確認なしで発動し、verify.sh も確認なしで実行された

2.1.289 では、承認待ちになるたびに、Claude は verify.sh を使わず、許可済みの個別のコマンド（ansible-lint など）に切り替えて検証しました。2.1.302 では、Claude が git diff roles/ntp/tasks/main.yml; bash .claude/skills/ansible-verify/scripts/verify.sh inventory/stg/hosts.ini site.yml のように、2つをつないで実行し、確認なしで通りました。出力の最後は、次のとおりです。

RESULT lint=0 syntax=0 check=4

check=4 は、練習用リポジトリの stg のホスト（192.0.2.11。文書用のアドレス）に届かず、unreachable になったためです（ansible-playbook の終了コード4）。

この結果から、筆者は次のように読んでいます。

• 呼ぶ時点で承認が要る：allowed-tools を書いたスキルは、呼び出しの時点で承認を求める。「常に許可」（Skill(名前) の allow）なら次からは確認が出ない。この動きを説明した公式の記述は、筆者は見つけていません（筆者の実測、2.1.289・2.1.302）
• 呼んだ後は事前承認される（2.1.302）：書いた呼び方の verify.sh は、確認なしで動いた。2.1.289 の -p では動かなかった。公式の変更履歴（CHANGELOG）の 2.1.295 に、「Fixed a skill’s allowed-tools and effort being dropped when the Skill tool finished before the response stream ended, which denied the skill’s Bash commands in -p runs」という修正があります。2.1.289 の結果の原因がこの修正かどうかは、筆者は確かめていません
• Code タブでの見え方は未確認：ここまでは CLI の -p の結果です。Code タブで、確認の画面が出るかどうかは、筆者は確かめていません

この結果は、版で変わりえます。allowed-tools を書いたのに確認が出たときは、まず、スキルの呼び出しの確認なのか、スキルが中で使うコマンドの確認なのかを、確認の画面の文言で見分けてください。

---

考えてみよう

1. allowed-tools: Bash と書くと何が事前承認されますか。Bash(bash .claude/skills/ansible-verify/scripts/verify.sh *) のように絞るのは、なぜですか
2. allowed-tools を書いたスキルを呼んだら、確認の画面が出ました。何の確認かを、画面の文言から見分けるには、どこを見ますか。見分けたあと、確認を減らすには何を設定しますか
3. prod への ansible-playbook を、確認が必ず出るように守りたいとします。allowed-tools に書きますか。書かないなら、どこで守りますか

ヒント：1は「allowed-tools で事前承認する」、2は「筆者が試したら：allowed-tools はいつ効いたか」、3は「allowed-tools と権限ルールの関係」の節を見直してください。

---

まとめ

• スキルに置いたスクリプトは、中身を読まずに実行できる。トークンを使うのは出力の分だけ。SKILL.md に「読むのではなく実行する」と書く。2>&1 | cat の癖もスクリプトの中へ閉じ込める案
• allowed-tools は、公式の説明では、スキルを呼んだターンの間だけ、書いたツールを確認なしで使えるようにするもの。次のメッセージでクリアされる。制限ではない（使えなくするのは disallowed-tools）。Bash だけは書かず、Bash(git status *) のように絞る
• 権限ルールは .claude/settings.json でいつも効き、allowed-tools は呼んだターンだけ。管理設定のルールが最優先で、どこかの階層の deny は、ほかの階層では許可できない。ask・deny で守るものは allowed-tools に書かない
• スクリプトの中のコマンドは、権限ルールで個別に調べられない前提にして、危ない操作はスクリプト自身で止める
• 筆者の実測（CLI の claude -p）：allowed-tools を書いたスキルは、呼ぶ時点で承認を求めた（「常に許可」なら次からは確認なし）。呼んだ後は、書いた呼び方の verify.sh が事前承認された（2.1.302。2.1.289 では動かなかった）。Code タブは未確認

次回は、検証スキルを実際に作ります。検証の6段階のうちスキルが受け持つ範囲、フォルダーの構成、SKILL.md の案を扱います。

---

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

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

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