こんにちは、takuです。
Claude Code Skills は、SKILL.md に役割や手順を書いておくことで、Claude Codeから必要なタイミングで呼び出せる仕組みです。
この記事は、その機能の感想ではなく、自分がSkillsをどう運用しているかを書く技術記事です。
先に主張を書くと、Skillsは長い説明文を置く箱というより、CLI / API / MCP / スクリプトの呼び出し方を整理する層として使うとかなり強いです。
特にCLIを中心に回す形にすると、再現性が上がって、長い説明を毎回渡さなくて済むようになります。
自分は、調べる前処理をSkillsに逃がすようにしてから、調査の初速と実装前の確認がかなり安定しました。
1. 公式ドキュメントだけだと、何がうれしいのか少し見えにくい
Claude Codeを触り始めたころ、自分はSkillsを「よく使うプロンプトの保存場所」くらいに見ていました。
でも実際にうれしかったのは、文章を再利用できることではなくて、調査の入口を固定できることでした。
AIって、実装そのものより前に「まず何を見るべきか」で迷いやすいです。
ここでSkillsに、ログを取る、URLを拾う、仕様ページを開く、別リポジトリを確認する、みたいな前処理を持たせると、最初の一歩がかなり安定します。
逆に自分は、最初この設計で失敗しました。
description を検索される前提で書けておらず、せっかく作ったSkillが全然引っかからなかったんです。
AIに雑に書かせたときは、description に使い方そのものが書かれてしまっていました。
でも本当に欲しかったのは使い方ではなく、「何に使えるのか」「どういうときに使えるのか」です。
たとえばSlackログ系なら、「Slackに添付されたログを解析し、実装前のコンテキスト収集に使う」くらいまで書いた方が、その場面でちゃんと引っかかりやすくなりました。
もう一つは、Skill本体に長い説明を最初から全部詰め込んでいたことです。
段階的開示を意識せず、重い情報をいきなり渡していたので、呼ばれても使い方がぶれました。
最初は取得元と見る順番だけ見せて、詳しい解析手順は呼ばれたあとに渡すくらいの分け方にした方が安定しました。
Skillsは、長い知識を置く箱というより、前処理の導線を細く強くするものだと思った方がうまくいく気がしています。
2. CLI / API / MCP を束ねると、Skillsがやっと実戦投入しやすくなる
自分がよく使っているのは、たとえばビルドスキルです。
Unityや周辺ツールのビルドコマンド、失敗時に見るログの場所、再実行手順まで先に決めておくと、毎回説明しなくて済みます。
実装からPR下書きまでつなぐスキルもありますが、今回いちばん効いたのは、やはり調査前のコンテキスト収集を固める使い方でした。
調査系だと、Slackからログを取ってきて解析するスキルや、Slack上からPR URLやチケットURLを拾ってコンテキスト収集するスキルもよく使います。
Slackログ系は、ファイルダウンロード系のSlack APIを叩いてログを取る形にしていて、MCPでは取りにくい部分をSkillで補っています。
解析では重要な情報を先に渡すようにしていて、Error / Failure とサーバーエラーを優先し、Warning は後ろに回します。これだけでも、人間がgrepしたり上から目視で読む手間がだいぶ減りました。
Confluence APIを使ってページを取ってくるスキルもありますし、クライアント開発中にローカルの別リポジトリを読ませて、サーバー仕様や要件を拾う時短スキルも効きました。
MCPとの使い分けも大事です。
リモートMCPは企業側が用意してくれていることもあって、導入がかなり楽な場合があります。
一方で、OAuth認証が失敗したり、広く取りすぎてコンテキストが膨らんだり、API側は進化しているのにMCPの対応待ちになったりもありました。
その点、Skills経由ならCLIやAPIを直接呼べますし、.env 管理や既存スクリプトもそのまま使いやすいです。
MCPが悪いというより、広くつなぐときはMCP、手順を固めたいときはSkills、くらいの使い分けが現実的なんだろうなと思います。
3. スクリプト化すると、再現性と省コンテキストが一気に手に入る
自分は最近、CLI呼び出しをできるだけ固定化して、スクリプトに寄せています。
「このログを集める」「このURL群を開く」「この順番で調べる」を毎回プロンプトで説明するより、スクリプト化してSkillから呼ぶ方が再現しやすいです。
特にCLIやAPIで手順を固定できると、Skillがただの説明文ではなく、毎回同じ入口を切るための実行レイヤーになります。
これをやると、AI特有の迷いが減りますし、毎回長い背景説明を渡さなくてよくなります。
しかもこの設計思想は、Claude Code専用で終わりません。
主役はあくまでClaude Codeなんですが、Claude Codeで育てたSkillの設計思想は、GitHub CopilotやCodexみたいな他のエージェント系ツールでも応用しやすいです。
前処理を分ける、呼び出しを固定する、段階的に情報を出す、という考え方はかなり再利用しやすいからです。
AIに全部を一気に任せるより、迷いやすい入口だけ先に整える。
自分は、Skillsを知識倉庫として使うより、CLIやスクリプトで迷いやすい入口を固定する導線として使った方が効きました。
Skillsを試してみたい人は、まずは大きな自動化より、調査の前処理を1個だけ切り出すところから始めるとよさそうです。
次は、実際にSkillを書くときの description の設計や、段階的開示をどう作るかも掘ってみようと思います。
