目次

Claude Code Desktopへ移行してから、普段の使い勝手を少しずつ整えている。

Agent Skills自体は前から知っていた。フォルダにSKILL.mdという指示書を置いておくと、Claude Codeが必要な作業のときだけそれを読んで従う、という仕組みだ。ブラウザ確認用のPlaywright CLIのSkillも以前入れて、いまも使っている。

ただ、自分でSkillを書いて環境を育てるところまではやっていなかった。移行を機にそこも見直すことにして、外部の様子も調べてみると、自作Skillの実践例や「おすすめSkill○選」のような発信、多数のSkillを集めたrepositoryが複数見つかる。試す材料には困らない。

結果としてできたSkillは2つ。もう1つは検討した末に作らないことにした。この記事はその記録だ。

Skillの前に引っかかっていたのは、ログの見え方

Skillを考える前に手を付けたのは、普段の作業ログの見え方だった。Claude Codeに長めの作業を任せると、調査から実装、検証まで進むうちにログが伸びて、肝心の完了報告がどこから始まるのか探すことになる。

そこで共通ルールのほうに、完了報告は必ず

🟨 ── 完了報告 ──

という見出しで始める、という形式を足した。スクロールしていても、黄色い🟨が目印になって完了位置を見つけやすい。同じ理由で、僕の判断が必要で止まっている場面には🟥 ── 要確認 ──、外部調査を勧めて止まる場面には🔎のブロックと、目印を分けてある。地味な変更だが、長いログの中で「いま自分は何を読めばいいのか」がすぐ分かる。

これらはSkillにしていない。僕の環境では、全プロジェクト共通のルールをAGENTS.mdというファイルにまとめて、CLAUDE.mdからそれを読み込ませている。この形なら、どのプロジェクトで作業していても同じルールが常に効く。完了報告の形式は特定の作業だけの話ではないので、置き場所としてはここが自然だった。

そしてここで、あとから効いてくる区別がひとつできた。いつでも守ってほしいことは常設のルール。特定の作業のときだけ必要な手順や基準は、そのときだけ読まれるSkill。何でもSkillに入れればいいわけではない。

web-verify――Web確認を「基準」に変える

1つ目に作ったのは、Web画面の確認基準だ。

Claude Codeの「できました」をそのまま信じない話は前に書いた。中でもWeb/UIの変更は、「コード上は正しそう」「buildが通った」あたりで表示OK扱いになりやすい。ひどいときには、スクリーンショットを撮ったのにその画像を開かないまま「確認しました」になる。ファイルが生成されただけで、誰も見ていない。

web-verifyの中身は手順書ではなく、Web/UIを変更したあとに何を確認できたら「表示・操作OK」と言っていいか、という基準の一覧になっている。

  • コードを読んだだけで判断せず、実際にレンダリングされた画面を見る
  • それも、今回変更したページを見る。無関係なトップページだけ見て全体OKにしない
  • PCとスマホの両方で、実際にその状態で描画されたことを確認する
  • 意図しない横スクロールが出ていないか
  • 変更後に新しいconsoleエラーが増えていないか
  • ボタンやフォームを変更したなら、実際に操作して結果を見る
  • スクリーンショットを撮ったら、開いて見る。見ていないものを「確認済み」と報告しない

並べてみると当たり前のことばかりだが、この当たり前が飛ばされた実績は自分の記録に残っている。だから基準として明文化する意味があった。

もうひとつ決めたのが役割の分担で、web-verifyは「何を見るか」だけを定義して、「どうブラウザを操作するか」は既存のplaywright-cli Skillに任せている。確認のために新しいブラウザ自動化の仕組みを足すことはしていない。

natural-japanese――自然さより、まず事実

2つ目は日本語の文章まわり。

記事やREADMEの説明文をClaudeに書かせたり直させたりしていると、自分が気になるパターンが繰り返し出てくる。文の長さが妙に揃った均一なリズム、段落の頭に機械的に置かれる「また」「さらに」、「今後ますます重要になるでしょう」のように内容を増やさない締めの一文、「単なるAではなくB」という対比構文の連発。

natural-japaneseはこれを減らすためのSkillだが、設計で一番気をつけたのは、削る項目のリストではなく逆方向の禁止事項だった。

AI文体を消した結果、別の「人間っぽさテンプレ」に変換するSkillにしない。

「〜なんですよね」を散りばめる、「正直」「個人的には」を機械的に足す、それらしい体験談や感情を作る。そういう方向で人間っぽく見せ始めると、元の文章になかった中身が混ざってしまう。そういう書き換えは、Skill側で明確に禁止した。存在しない体験・感情・因果・数字は足さないし、不明なものを断定に変えることもしない。

優先順位もSkill本文に書いてある。上から事実、意味、確度で、自然な日本語は一番下。自然にするために上を壊さない、という順番だ。すでに自然な文章はそのままでいい、とも明記した。Skillを使ったからには何か直さないと、という書き換えが一番いらない。

人間っぽくするのではなく、AIっぽさを減らすだけ。その線だけは動かさないようにしている。

公開作業までSkillにするか

3つ目の候補は、このサイトの公開作業だった。

記事を公開するときの流れは、commit、push、deploy、本番確認と進む。ここまでの2つと同じ調子でpublish-siteのようなSkillにまとめれば、毎回の指示はかなり短くできそうだった。便利そうではある。

引っかかったのは、前の2つと失敗したときの景色が違うところだ。web-verifyの確認がうまくいかなければ、確認をやり直せばいい。natural-japaneseの直しが気に入らなければ、元の文章に戻せばいい。どちらも失敗がローカルに閉じている。これがpublish-siteだと、対象を誤ったときにGitHubのリポジトリや本番のサイトへ実際の変更が出る可能性がある。戻す手段が無いわけではないにしても、「戻せるか」の質はかなり違う。

それで、これは作らないことにした。危険だから自動化はやめよう、という話にしたいわけではない。今回選ばなかったのは、commitからpush、deploy、本番確認までをひとまとめにして任せる運用そのもので、公開作業は今までどおり自分が指示して、段階ごとに確認しながら進めている。

公式仕様にある「自動で動かさない」選択肢

整理のついでに、Claude CodeのSkillsドキュメントも読み直した。面白かったのは、deployのような副作用のあるSkillの扱いだ。

公式にはdisable-model-invocationという設定があって、これを立てるとClaude側の判断ではSkillが発動しなくなる。動くのは、ユーザーが自分でコマンドとして打ったときだけ。ドキュメントのdeployの例には、コードが良さそうに見えたからといってClaudeにdeployを決めさせたくないだろう、という趣旨の説明が付いている。

つまり「publish-siteを作って、自動では発動しない手動専用のSkillにする」という道も、仕様上は用意されていた。それでも今回は作っていない。仕組みの問題ではなく、公開の手順をひとまとめにするかどうかという、自分の運用の話だからだ。

いまはこう分けている

現時点の環境は、こう分かれている。

  • 共通AGENTS.md(CLAUDE.mdから読み込ませている): 常に守るルール(完了報告の形式など)
  • Skill: 特定の作業のときだけ読まれる手順・判断基準
  • Hook: 決まった処理を確実に実行したいもの(通知など)
  • 🟥: 人間の判断へ戻す境界

そして今回のSkillは、

  • web-verify: 作った
  • natural-japanese: 作った
  • publish-site: 検討して、作らなかった

という結果になった。

MCPを調べたときも、増やせば便利になるわけではない、という結論だった。Skillでも同じで、作れそうなものと作って良かったものは一致しない。

振り返って言葉にするなら、僕は今のところ「失敗しても戻しやすい範囲を中心に自動化する」くらいがちょうどよさそうだと思っている。これが正解という話ではなく、自分の環境を整理したら今回はそうなった、というだけの記録だ。この分け方もまた変わるかもしれないが、しばらくはこのまま使ってみる。