Claude Code に同梱された claude-api スキルの prompt-audit を、社内標準のスキルとエージェント一式に当てました。指摘は十数件出ましたが、手順・ゲート・「ここではこのツールを使う」の類は1件も削除対象になっていません。消えたのは、古いモデル向けに言い方を強くしていた大文字のほうだけです。
前回の記事は、公式の監査ツールを知らずに書いていた
モデルを提供している側が削れと言っているのは禁止形や思考手順のほうで、ヒントやゲートや道しるべは足す側だ、という整理を前に書きました。締めに置いたのは、監査せよという助言は対象の一覧が無いと実行できない、という但し書きです。
ブログ削れと言われたのは、道しるべではなかった「規定的な作り込みを削れ」という助言は、禁止形や思考手順のことを指しています。ヒントやフックやワークフローまで削れと読むと、裁量を渡したのに黙るエージェントが残ります。制約と整備を分けた上で、依存していた挙動を数え直した記録です。公開したあとで、友人から「公式の監査ツールがあるよ」と教わりました。一覧が無いなら約80本を頭から読み直すしかない、と書いた当人が、その読み直しを助ける道具を知らなかったことになります。
知ってからも、すぐには当てませんでした。うちのスキルには、レビュアー2体の承認を通らないと先へ進めないゲートや、翻訳の検証スクリプトを飛ばさせない指示が入っています。どれも失敗を踏んでから足したもので、Fable 5 のガイドが言う「規定的すぎる」を額面どおり受け取れば真っ先に消える側です。半年かけて積んだ手順が一斉に剥がされる絵しか浮かびませんでした。
監査手順は、消してはいけないものを先に並べている
Claude Code 2.1.221 で claude-api スキルに prompt-audit が入りました。プロンプトとして読まれるテキストを洗い出し、1行ずつ「これはモデルが既に知っていることか」で分類し、4つのアンチパターン群を走査して、報告書と適用案の差分を出すところまでをやります。適用はしません。
手順書を読んで、警戒がずれていたことが分かりました。最初に置かれているのは削除の指示ではなく、監査が最も壊しやすいものへの歯止めです（以下、訳は筆者）。
文脈が不要な記述になることはない。読み手、プロダクト、環境の事実、品質の基準、制約、そしてその理由 — 書いた本人しか知らないこと
不要な記述と長さは別。害は特定の古い指示から来るのであって、量から来るのではない。文字数だけを根拠に削除を正当化してはならない
壊れやすい操作は正確なスクリプトのままにする。安全な手順が1つしかない場所では、自由度の低い規定的な文章が正しい
削る対象として名指しされているのは、モデルが訓練で既に持っている振る舞いの言い直し、提供が終わったモデルの回避策、そして根拠を言えない禁止です。手順やゲートはむしろ守られる側に置かれていました。
3分の2のファイルからは1件も出なかった
対象は約80本のマークダウンで、監査した時点で26のスキルと9体のエージェントがありました。対象モデルは Fable 5、報告のみで適用はさせませんでした。結果はこうなります。
| 分類 | 件数 |
|---|---|
| 言い方が強すぎる文 | 6 |
| 過剰な規定（検索回数のノルマなど） | 2 |
| 消えたものへの参照が残っている | 3 |
| スキルファイル固有（設計判断として残す） | 2 |
| トリガー文（同上） | 1 |
| リクエストの組み立て | 0 |
合計14件で、確度が高いものが4件、中が6件、残る4件は指摘のみで書き換え案なしです。Swift 系のスキル、文書規約、ブランドガイドなど、全体の3分の2からは1件も出ませんでした。「監査して何も出なければ何も変えない」と手順書自体が書いているとおり、そのまま残しています。
スキルを消して、参照を消し忘れていた
高い確度で出た4件のうち3件は、存在しないスキルの名前でした。パフォーマンス監視のエージェントは Issue を起票する段で「/github-workflow スキルを使って」と指示されていますが、そのスキルはリポジトリにありません。書かれたのは2月で、以後一度も触られていない一方、同じファイルの報告セクションは8月に書き直されています。スキル作成用の参照ファイルにも、廃止済みの名前が例として2箇所残っていました。作り方を教える文書が、既に無い名前を教えている状態です。
検索回数の要求と、その配分の指示が同じファイルで食い違っていた
高い確度で出た4件のうち、残る1件が調査スキルの検索ノルマでした。冒頭で「7件以上の並列検索を行うこと」と大文字の見出しで要求し、末尾のチェックリストで同じ数値を繰り返し、「1つでもチェックが埋まっていなければ GO BACK して埋めろ」で締めています。ところが、そのブロックの中には8月に足したばかりの一文が混ざっています。WebSearch にはセッションあたりの上限があるので、サブ課題ごとに7件の検索を回し直さず、セッション全体で配分すること。数値の要求と配分の指示が、同じファイルで真っ向から食い違っていました。重複が害になるのは、重複した内容が実際に食い違っているときだけです。ちょうどその条件に当たっていました。
「GO BACK」のほうには別の問題があります。停止条件も上限回数もありません。うちのスキル作成用の参照には、リトライには必ず回数の上限と停滞時の停止条件を置くと書いてあるので、自分の規約に自分で違反していたことになります。
強調のつもりが、4回目の言い直しだった
中程度の確度で出たものは、傾向がそろっていました。ASO レビューの **CRITICAL:** Each agent MUST review EVERY detected locale independently.、つまり各エージェントは検出した全ロケールを個別にレビューすること、という一文は、同じファイルの別の3箇所が既に強調なしの地の文で同じことを書いています。強調ではなく、4回目の言い直しでした。LP レビューの「開始時に各フェーズのタスクを作成すること」に付いた MUST は、別の形で同じ問題を抱えています。タスク管理のツールは現行モデルでは任意で、そもそも使えない環境もあります。ハーネスの都合で実行できないことがある MUST を置くと、MUST という書き方そのものが軽く扱われる、と監査は指摘しています。6件はどれも大文字を落として、理由を添えた一度の言い直しに変えました。消したのではなく、語気を弱めて根拠を足した形です。
理由を言えないから提案しない、と監査は書いてきた
面白かったのは、タスク管理ツールの filter: 'all' を FORBIDDEN と書いた1行の扱いです。監査はこれを指摘しつつ、書き換え案を出しませんでした。理由を正直に述べられないから提案しない、と明記したうえで、理由が判明した場合の文の形だけを添えてあります。
実際の理由は、全件取得がバックログを丸ごと返してコンテキストを食いつぶすことでした。禁止そのものは正しかったので、大文字をやめて理由を書き足す形に直しています。誰も理由を言えない禁止は、後から外されるか、効かない場所にまで広げられるかのどちらかになります。
意図して残したものと、監査が消さなかったもの
意図して残した判断が3つあります。スキルの when_to_use に並べたトリガー語句は、振る舞いの指示ではなく呼び出しの経路なので、一覧の文字数上限に収まっている限り残します。Claude Code のバージョン、Issue 番号、確認日を根拠として書いてある行も残しました。監査が狙うのは、日付も出典もないまま残った「既知の不具合」のほうで、あとから追える形で書いてあるものは同じ手順書が推奨する形そのものです。エージェントの禁止事項セクションも、人格設計の要素として意図的に置いているので触っていません。
そして消えなかったものが、いちばん確認したかったところです。翻訳スキルの「検証スクリプトの実行は必須であり、飛ばすことは許容されない」という一文には、明示的に残すという判断が書き添えられていました。副作用のある書き込みで、安全な手順が1つしかない経路 — つまり手順を1つずつ指定した文章のほうが正しい場所だと、監査自身が判定しています。レビュアー2体の承認ゲートのほうは、ゲートの行自体に指摘が付きませんでした。
長い作業を投げるところまでは、まだ確かめていない
手順書の最後の段には、削除の前後で小さな挙動確認を回せと書かれています。適用したあとは各スキルを実際に呼んで、何がどう変わったか、意図した動きになっているかを見ました。そこまでは確かめてあります。
やっていないのは、前後を並べた比較と、長い作業や大きなタスクを投げることです。制約が効くかどうかが問われるのは後者なので、そこはまだ分かりません。調査が浅くなったり、レビュアーがロケールを飛ばしたりしたら、元の大文字ではなく、必要最小限の書き方で制約を戻します。
監査がどこまで拾えているかも測っていません。調査スキルからは書き換え案が2件出ていますが、同じファイルの別の行に残っている **CRITICAL: Execute ALL searches in a single message with multiple tool calls.** は指摘されていません。同じ種類の大文字が、同じファイルの中で片方だけ報告されています。網羅性を確かめるには、監査そのものを別の走らせ方でもう一度当てるしかありません。
再監査をいつやるかも、手順書が決めています。プロンプトはモデルに合わせて書くものなので、モデルが更新されるたびに当て直す、というのが締めの一文です。うちの場合は Claude Code のバージョンが上がったときが同じきっかけになります。
ただし、これを運用に乗せるにはまだ足りません。当て直すと決めても、どの記述がどの挙動に依存しているかを控えていないので、次も今回と同じ読み直しを1周やることになります。バージョンか Issue 番号を根拠に書いた行を、監査は約20行拾って残す側に置きました。リポジトリ全体では約30行あります。一覧を作るならここが起点になります。ただし起点であって一覧ではありません。根拠を書かずに済ませた記述が何本あるかは、数えていないので分かりません。バージョンが上がったことに気づく手立ても、今はありません。
一覧はまだありませんが、そこに載るはずの1行だけは先に片付いています。参照ファイルについて、読めと書いた指示を消して、本文への注入に替えた回です。残りは手つかずのままです。スキル定義の現物は公開しているので、監査の前後で何がどう変わったかは履歴から追えます。
ブログSKILL.md に必須の参照ファイルを注入するSKILL.md に「この参照を読むこと」と書いても、読むかどうかはモデルの裁量です。毎回必要な参照は動的コンテキスト注入で本文に埋め込む形へ切り替えました。公式ドキュメントの記述、報告されている類似の症状、プラグインで配ったときの挙動を並べます。