はじめに
これまで、エージェントに渡すスキルをいくつも作ってきましたが、モデルが賢くなったらこれらがどうなるのかは、ちゃんと考えたことがありませんでした。
そこで、自分のスキルを1本読み返して、何が残りそうかを考えてみました。この記事では、その見立てと、要らなくなった記述の扱いについて、今の時点の考えをまとめます。
ここでのスキルは、AI エージェントに渡す手順書やスクリプトのパッケージ（Agent Skills など）を指します。
自作のスキルの読み返し
読み返したのは、私が自分で作って使っている review-blog というスキルです。
review-blog は、Qiita などに投稿する前の記事の下書きを Claude Code にレビューしてもらうためのスキルです。一般的な文章の良し悪しではなく、私の文体ルールと過去の記事を基準にして、指摘を「機械的な修正」と「判断してほしい提案」に分けたレポートを書き出します。記事まわりのスキルをまとめた blog-skills というプラグインに入れて、GitHub で公開しています。
フォルダの中身は次のとおりです。
review-blog/
├── SKILL.md # 手順・出力の形・指摘しないもの
├── criteria.md # 観点ごとのチェックリスト
├── examples.md # 指摘の良い例・悪い例
├── references/my-style.md # 文体ルールのひな形
└── scripts/pick-references.sh # 過去記事の候補をジャンル別に出す
Before（今の書き方）
SKILL.md の手順の部分を抜き出すと、次のようになっています（一部を省略し、言い回しを少し変えています）。
## 手順
1. 対象の下書き（`$ARGUMENTS`）を Read します。引数が無ければ「レビュー対象のファイルパスを指定してください」と伝えて終わります。
2. 文体ルール `${user_config.style_file}` を、ほかの資料より先に読みます。
3. 過去記事の候補をスクリプト（scripts/pick-references.sh）で出し、レビュー対象とジャンルが近い記事を 2〜3 本 Read します。
4. criteria.md の観点と、文体ルールとの整合を確かめます。良い例・悪い例は examples.md にあります。
5. 古い情報やバージョンに依存する記述があれば、WebSearch で最新の情報を確かめます。
6. 下の「出力」のとおりに、レポートを書き出してターミナルに要約を出します。
7. 文体ルールへの追記を 1 行の形で提案します。ファイルを書き換えるのは、承認をもらってからです。
## 指摘しないもの
- Qiita のタグ（投稿時に手で設定するため）
- SEO や話題性を狙った要素
- 書き手の個性
読み返してみると、手順の中に性格の違う記述が混ざっていました。古い情報やバージョンに依存する記述を WebSearch で確かめるというのは、モデルの知識の古さを補うコツです。一方で、文体ルールを基準にすること自体は、私が決めたことです。また、ファイルの書き換えは承認をもらってから、というのはどこまで任せるかの線引きで、過去記事の候補選びはスクリプトに任せています。
モデルが賢くなったときに要らなくなりそうなのはどれなのかを、中身ごとに分けて考えてみます。
記述の4つの中身
review-blog に書いたことは、どれも私が決めたものなので、ある意味では全部が私のルールです。そのうえで分け目は、モデルが賢くなったら言わなくてもそうしてくれそうか、だと考えています。私の見立ては次のとおりです。
| 中身 | 例 | モデルが賢くなったときの見立て |
|---|---|---|
| コツや知識を補う記述 | 手順の段取り・出力のコツ・公開されているベストプラクティス | 減る |
| ユーザー（組織）独自の決めごと | 社内ルール・顧客ごとの制約・完成の基準 | 変わらない |
| スクリプトに任せる処理 | 同梱スクリプトによる変換・検証 | 変わらない |
| 任せる範囲の線引き | 禁止事項・人に確認する場面 | 増える |
コツや知識を補う記述は、モデルが自分でできるようになれば要らなくなっていくと思います。review-blog なら、読む順番や読む本数、WebSearch で確かめること、criteria.md の一般的なチェックリストがここに入ります。学習の時点より新しい情報も、公開されていれば次の世代のモデルが覚えてくれそうです。
ユーザー（組織）独自の決めごとは、組織や人が決めたことなので、モデルがいくら賢くなっても知りようがないはずです。review-blog では、文体ルールを基準にすることや、指摘を2層に分けて番号を振ることがこれに当たります。承認の順番のように手順であっても、組織が決めたものはこちらに含まれると思います。手順の記述を一律に減らすと、こうしたものまで消してしまいそうです。
スクリプトに任せる処理は、毎回同じ結果が要る変換や検証です。review-blog では、過去記事の候補選びをスクリプトに任せています。モデルにできるようになっても、私はスクリプトに任せたいです。
任せる範囲の線引きは、やってはいけないことや、人に確認してほしい場面です。review-blog では、文体ルールの書き換えは承認をもらってから、としています。モデルが賢くなるほど任せる範囲が広がるので、どこで止まってほしいかを書く量はむしろ増えるのかなと思っています。
なので、見直すなら記述ごとがよさそうです。決めごととモデル向けのコツを節やファイルで分けておけば、あとでコツだけを消しやすくなる気はします。
After（中身ごとに分け直した書き方）
review-blog の手順を、中身ごとに分け直すとしたら次のようになると思います。
## 決めごと
- 基準は一般的な良い文章ではなく、書き手の文体ルールと過去記事にする
- 指摘は「機械的な修正」と「判断してほしい提案」に分け、通し番号を付ける
- 詳細は下書きの隣の .review.md に書き、ターミナルには高優先度と件数だけを出す
- Qiita のタグ、SEO、書き手の個性は指摘しない
## 任せる範囲の線引き
- 文体ルールのファイルを書き換えるのは、承認をもらってから
- 判断してほしい提案は、理由を添えて出すだけにして押し付けない
- 下書きのパスが渡されなければ、レビューせずに終わる
## スクリプトに任せる処理
- 過去記事の候補は scripts/pick-references.sh で出す（5KB 以上、ジャンル別、新しい順）
## コツ
- 文体ルールを、ほかの資料より先に読む
- 過去記事はジャンルが近いものを 2〜3 本読む
- 古い情報やバージョンに依存する記述は WebSearch で確かめる
- criteria.md の一般的な観点（1文の長さ、導入・本文・まとめの割合、表記揺れなど）で見る
こうしておけば、モデルが賢くなったときに消せそうなのは、コツの節と criteria.md の一般的なチェックリストかな、と見分けやすくなる気がします。
要らなくなった記述の扱い
ノイズになる古い記述
要らなくなった記述は、残しておくとモデルにとってノイズになることがあります。Claude Opus 5.5 への移行ガイドには、次のように書かれています。
Re-evaluate model-specific prompt instructions. Instructions tuned for Claude Opus 5's behavior might no longer be needed; see Prompting Claude Opus 5.5.
訳すと、モデルに合わせて書いた指示を見直してほしい、Opus 5 のふるまいに合わせた指示はもう要らないかもしれない、とのことです。
前の世代にも似た案内がありました。Opus 4.5 と 4.6 のときは、ツールやスキルが呼ばれないのを防ぐために強く書いた指示（CRITICAL: You MUST use this tool when... など）が呼ばれすぎの原因になりうるので、普通の書き方に和らげるよう書かれています。
また、Claude Code では、スキルの説明文がどのスキルを使うかを決めるためにコンテキストに載ります。使わなくなったスキルを入れたままにすると、そのぶんコンテキストを使います。（この辺りはモデルの進化と共に誤差になっていく気もしますが）
必要ない記述は、確かめたうえで消しておきたいところです。
外して流し直す確かめ方
どの記述が要らなくなったかは、比べるのがいちばん確かだと思います。その記述を外したスキルと外していないスキルで、同じタスクを流します。そのためには、どんな場面で何が効いたかをユースケースとして残しておくとよさそうです。流し直すための入力と合格の基準も一緒に残せば、モデルを替えたときにもう一度比べられます。
review-blog で、コツの節がまだ要るかを確かめるなら、次のような形です。結果は仮のものです。
| 項目 | 内容 |
|---|---|
| 確かめたい記述 | コツの節と criteria.md |
| 流し直す入力 | 以前レビューした下書き1本 |
| 合格の基準 | 前回の高優先度の指摘の再現 |
| コツありの結果 | 合格 |
| コツなしの結果 | 今のモデルでは不合格 |
| 使ったモデル・日付 | モデル名・バージョン・日付 |
モデルを替えたときに同じ下書きを流し直して、コツと criteria.md なしでも同じ指摘が出るようになったら、そこは消してよさそうです。文体ルールを基準にするという決めごとは、外すと一般的な添削に戻ってしまうはずなので、残る側になると思います。
ただ、コツの節の中でも、消せるものと残るものに分かれるかもしれません。例えば、古い情報を WebSearch で確かめるというコツは、個々の知識は次のモデルが覚えても、学習の締め切りは毎回あるので、新しい情報を確かめる習慣としては残りそうです。全部の行を1つずつ外して確かめるのは大変なので、まずは節ごとに外してみて、差が出たら行に分けて絞っていくのが現実的かなと思います。
比べるのは、使うモデルごとがよいと思います。コストを抑えるために小さいモデルも使うなら、大きいモデルでは要らなくなったコツを、小さいモデル用に残すこともできます。
Anthropic の skill-creator（スキルを作って直すためのスキル）には、この比べ方が手順として入っています。テストケースをスキルのフォルダの evals/ に置き、スキルありとなし、または直す前の版と直したあとの版を同時に流して比べます。
Claude Code にも、プラグインなしで流した結果と比べる claude plugin eval があり、ドキュメントには次の一文があります。
A high score on its own doesn't tell you the plugin helped, because Claude might do as well without it.
skill-creator と claude plugin eval の内容は 2026年11月時点のものです。
おわりに
以上、簡単ではありますが考えてみたことを書いてみました。
モデルの性能の向上に伴って1つのスキルの中でも不要になる部分が出てくると想像します（というか今後ずっと付き合っていくことになるでしょう）。その不要な部分を見分けるために、自分たちで判断基準を持っておくことが大事になりそうです。
ただ、正直なところ、モデルを替えたときに誰が流し直すのか、文体のような主観的な基準をどう測るのかは、まだ答えを持っていません。コツの中でもどこまでを消してよいのかも、まだはっきりとは基準を持てていません。実際に自分のスキルで何本か試してみて、固めたいところです。
また、この作業がどこまで重要になってくるかもあまり見えていません。（恐らく現状でもそんなにメンテナンスをしてもしなくても差がわかりにくそう）
この辺りは今後うっすら考えていけるといいのかなと思います。
作ったスキルの扱いに迷っている方の参考になれば幸いです。
ありがとうございました。