AIスキルは入れた瞬間から腐る｜バージョン1.1.0のまま、中身だけ書き換わっていた
Claude Codeのスキル（特定の作業のやり方をまとめて渡す仕組み）は、入れると分かりやすく効きます。実際、デザイン審査用のスキルを1本入れただけで、自分では気づいていなかったアクセシビリティ違反が7種類出てきました。
ただ、運用してみて一番効いた学びは選び方ではありませんでした。入れた後に何をするかです。スキルは配置した時点のファイルのコピーで、上流が更新されても手元は変わりません。 しかも、変わったことを教えてくれる印がありませんでした。
仕様や配布物は変わるため、個々のスキルの中身は必ず自分で確認してください。
結論：スキルは「入れて終わり」にならない
📌 先に結論 ① スキルの価値は自分では見えない違反を検出することにある ② ただし権威ではなく第2レビュアーとして扱う。全部従うと没個性になる ③ versionは上がらないまま中身が変わる。見出しの比較では検出できない
1本入れたら、実際のA11y違反が7種類出た
導入したのは、AIが作りがちな没個性なデザインを検出するタイプの審査スキル（Hallmark）です。当時のこのサイトは「まあ見られる状態」だと思っていました。実際に指摘されたのは次の7つです。
| 指摘 | 何が起きるか |
|---|---|
:focus-visible の定義がゼロ | キーボード操作時に、いま自分がどこにいるか見えない |
prefers-reduced-motion 未対応 | アニメーションを減らす設定が無視される |
overflow-x 未設定 | 横スクロールが発生する可能性が残る |
グリッドが 1.15fr 1fr の bare fr | スマホ幅で中身が枠から溢れる |
| ホバー効果を4つ同時がけ（浮き＋影＋枠色＋画像ズーム） | 効果が競合して安っぽく見える |
| カードのアイコンに絵文字を使用 | AIが作った見た目である最も分かりやすい印 |
:root の外に生のhex（色コード）が50個 | 色を1か所で変えられない |
上の3つは目で見ても分かりません。キーボードだけでサイトを操作してみるまで、:focus-visible が無いことに気づけませんでした。
4番目の 1.15fr 1fr は、数字を微調整したくなって書いた自分のコードです。fr に minmax(0, ...) を添えないと、中身の最小幅がグリッドを押し広げます。これも実機で細い幅にするまで見えませんでした。
いちばん効いたのは「AIが直前に自分で足したもの」を撤回させたこと
導入して最初の審査で、こういう検出がありました。
見出しにグラデーションを掛けている箇所がある。装飾の必然性が説明できない。
これは、同じセッションでAI自身が「見栄えが良くなるので」と足したばかりの装飾でした。足した本人に「これは要りますか」と聞いても、たいてい「効果的です」と返ってきます。
📌 独立した審査を挟む意味 書いた本人に自己採点させても、直前の判断は肯定されます。別の基準を持った審査を後から通すと、直前の判断が撤回されます。
ただし、スキルを「決定権者」にしてはいけない
ここは実際に間違えかけたところです。指摘が的確だったので、全部従いたくなりました。
しかし導入したスキルは、汎用のWebランディングページ向けの評価基準を持っています。このサイト固有の意図的な判断——たとえば読者が最後まで読まない前提で中盤にCTAを置く設計——と衝突する指摘も混ざります。
⚠ 全部従うと何が起きるか 自分のサイトではなく、そのスキルが想定するテンプレートの一種になります。「AIっぽさ」を消すために入れたのに、別の均質化が起きます。
そこで運用ルールをこう決めました。
| ルール | 理由 |
|---|---|
| スキルは第2レビュアー。採否は自分が決める | 汎用の基準は、個別の意図を知らない |
| 同じ領域にスコアラーを2つ入れない | 点数が食い違ったとき、どちらに従うか決められない |
| 採用しなかった指摘は、なぜ採用しないかを書いて残す | 次の審査で同じ指摘が出たときに毎回悩まない |
2番目は具体的に効きました。デザイン審査を追加する候補として897スターの別スキルを検討しましたが、見送っています。理由は2つです。
- 既に入れているスキルと評価の権威が二重になる（どちらの点数を信じるのか決められない）
- 既定の配色がインディゴ系で、このサイトのブランドカラー（暖色系）の決定と衝突する
代わりにやったのは、そのスキルにしか書かれていない言い回しだけを、既存スキルの基準に文章として取り込むことでした。丸ごと入れずに差分だけ借りる形です。現在はデザインはスキル1本、文章もスキル1本に固定しています。
本題：バージョンは1.1.0のまま、中身が変わっていた
ここが一番の落とし穴でした。
導入から時間が経ったので更新確認をしたところ、上流の配布物は version 1.1.0 のままでした。手元も 1.1.0 です。普通ならここで「最新です」と判断します。
実際には中身が変わっていました。
| 変わっていた箇所 | 手元 | 上流 |
|---|---|---|
| 収録テーマ数 | 20 | 21（1つ追加されていた） |
| レイアウト指針 | 記載なし | Grid（グリッドレイアウト）の項目が追加 |
| ナビゲーションの表記 | 旧表記 | 変更後の表記 |
⚠ バージョン番号は更新の証拠にならない 配布側がバージョンを上げずに中身を差し替えることがあります。番号が同じ＝中身が同じ、ではありません。
さらに厄介なのは、見出しの一覧を比べても検出できなかったことです。テーマが1つ増えたことは目次を見れば分かりますが、レイアウト指針の追記や表記変更は本文の中にあります。
検出方法：tarballを落として全ファイルを実際に差分にとる
結局、確実だったのはこれだけでした。
上流の main ブランチを丸ごと取得します。
curl -L "https://codeload.github.com/<owner>/<repo>/tar.gz/refs/heads/main" -o upstream.tar.gz
tar xzf upstream.tar.gz
そのうえで、手元のスキルフォルダと全ファイルを1つずつ差分にかけます。「代表的なファイルだけ見る」では、上の3件のうち2件を見落とします。
Windowsで必ず引っかかる改行コードの罠
手元のファイルはCRLF（Windowsの改行）、配布物はLFです。そのまま比較すると全行が差分になって使い物になりません。
比較するときは、手元側の改行を落としてから渡します。
diff <(tr -d '\r' < local/SKILL.md) upstream/SKILL.md
逆に、更新内容を手元へ書き戻すときはCRLFに戻します。
sed 's/$/\r/' upstream/SKILL.md > local/SKILL.md
これを飛ばすと、中身は正しいのに全ファイルが変更扱いになるか、手元だけ改行が混ざった状態になります。
更新後は「差分0」を実測して閉じる
更新したら、同じ手順をもう一度回して差分が0であることを確認します。実際にやった結果がこれです。
- 更新後の再比較で、全107ファイルの差分が0
- 別に入れていた2本のスキル（テスト駆動開発用・デバッグ手順用）は、上流とバイト単位で一致していた＝作業不要
2つ目が地味に重要でした。**「更新確認をした」の中身が「全部更新した」ではなく「変わっていないことを確認した」**であるほうが、次回の判断が速くなります。何も変わっていないという結果も、実測した記録として残します。
選ぶときに見るもの（スター数は当てにならなかった）
紹介記事を頼りに候補を絞っていたとき、実際に起きた食い違いです。
ある紹介記事が、公式のスキル集を 「157k スター」 と書いていた。同日に実際のリポジトリを開いて数えたら 169.6k だった。
紹介記事は書かれた時点の数字で止まります。しかもどの時点かが書かれていないことがほとんどでした。数字を判断材料にするなら、必ず本体を開いて自分で見るしかありません。
そのうえで、実際に候補を落とした基準がこれです。
| 見るもの | 落ちた例 |
|---|---|
| ライセンス | プロジェクト管理系のスキルは非商用（NC）ライセンスが多い。収益化するサイトの作業に使えない |
| 既存スキルとの役割の重複 | 同じ領域のスコアラーが2つになる（前述の897スターの件） |
| 自分の決定と衝突する既定値 | 既定の配色がブランドの決定と衝突する |
📌 スター数より先にライセンスを見る 人気があっても、非商用ライセンスなら収益化する作業には使えません。 落とす理由になるものから先に確認したほうが、検討の時間が短くなります。
そして、入れる前にもう1つやることがあります。スキルは他人の書いたコードを自分の環境で動かすことなので、配置前に中身を検査しています。その手順はAIスキルを入れる前の検査にまとめました。
現在固定している運用
- 新規スキルは配置前に検査（静的解析＋本文の全文レビュー）
- 同一領域にスコアラーは1本まで（デザイン1本・文章1本）
- 指摘は採否を自分が決める。不採用の理由は書いて残す
- 更新確認は tarball の全ファイル差分。バージョン番号は見ない
- 差分0だったことも記録に残す（次回の判断が速くなる）
4番目は隔週の作業として日付を決めています。「気づいたときにやる」では、気づく手がかりがそもそも無いからです。
まとめ
スキルで得たものと、失いかけたものを並べます。
- 得たもの：自分では見えない違反7種（
:focus-visibleゼロ、絵文字アイコン、生hex50個ほか）と、直前に自分で足した装飾を撤回できる独立審査 - 失いかけたもの：全部従った結果の没個性。スキルは第2レビュアーであって決定権者ではない
- 一番の落とし穴：version 1.1.0 のまま中身が変わっていた。見出し比較では検出できず、全ファイル差分で初めて分かった
なお、この「書いてある内容が古くなる」問題は、スキルに限りません。プロジェクトの指示ファイルでも同じことが起きます → CLAUDE.mdは書いた瞬間から劣化する
- スキルを入れる前の安全確認 → AIスキルは他人のコードを自分のPCで動かすこと
- 「良さそうに見える」を数字で潰す方法 → AIの成果物は目視でなく実測で検証する
- 学んだことを次のセッションに残す設計 → AIにAIを引き継ぐブリーフとメモリ設計
Claude Code自体の位置づけはClaude Codeとは何か、実務での回し方はClaude Codeの実務での使い方にまとめています。