Agent Skillsとは？SKILL.mdをフォルダごと渡す仕組み
いつ、誰が公開した仕組みなのか
室谷代表取締役Anthropic が2025年10月16日に出した仕組みなんですよね。ブログのタイトルが「Equipping agents for the real world with Agent Skills」で、要はエージェントを実務で使えるようにする、という話なんですよ。
テキトー教師DotAI 認定講師名前だけ先に広がってるので、現場でよく聞くのは「これって新機能ですか？」なんですよ。実体は機能というより、フォルダの置き方の話なんですね。
室谷代表取締役そうなんです。で、2025年12月18日の追記でオープン標準として公開された、と。
ここは業界構造として地味に大きいんですよね。
ここは業界構造として地味に大きいんですよね。
テキトー教師DotAI 認定講師なるほど、Anthropic の中だけの仕組みじゃなくなった、ということですか。
1つのスキルはSKILL.mdとフォルダがセット
室谷代表取締役中身はどうなってるんです？
テキトー教師DotAI 認定講師1つのスキルは、SKILL.md を必ず含むディレクトリ一式なんですよ。SKILL.md 本体と、scripts/ や references/ や assets/ といった付随ファイルが同じ箱に入ってる形ですね。
室谷代表取締役ファイル単体じゃなくてフォルダごと渡す、と。新人のオンボーディングガイドを作るのに近い、とAnthropicが説明してるのはそういうことか。
テキトー教師DotAI 認定講師そうなんです。だから手順書だけでも、実行スクリプト付きでも同じ形式で扱える。
最初に戸惑うのが、フォルダの中に README.md を入れてしまうパターンで、あれは置き場所が違うんですよね。
最初に戸惑うのが、フォルダの中に README.md を入れてしまうパターンで、あれは置き場所が違うんですよね。
オープン標準になったことで何が変わった？
Agent Skillsの公開とオープン標準化
- 2025年10月16日AnthropicがAgent Skillsを公開ブログ「Equipping agents for the real world with Agent Skills」で発表。エージェントを実務で使えるようにする仕組み。
- 2025年12月18日オープン標準として公開Anthropic内部だけの仕組みではなくなり、同じ形式のスキルがClaude以外のAIプラットフォームやツールでも使えるように設計された。仕様はagentskills.ioに公開、Pythonのリファレンス実装もあり。
室谷代表取締役オープン標準になったことで、同じ形式のスキルが Claude 以外のAIプラットフォームやツールでも使えるように設計された、と。仕様は agentskills.io に公開されていて、Python のリファレンス実装もあるんですよね。
テキトー教師DotAI 認定講師現場感覚で言うと、これは「作った手順書が一社専用の資産じゃなくなる」ということなんですよ。乗り換えコストの話ですよね。
室谷代表取締役経営目線で言うと、そこが一番効くんですよ。手順知識をフォルダで持っておけば、モデルやツールが入れ替わっても資産が残る。
数年で前提が変わる業界だと、この差はかなり大きい・・・
数年で前提が変わる業界だと、この差はかなり大きい・・・
テキトー教師DotAI 認定講師たしかに。ただ実際に使う場所によって挙動は違うので、その辺は別で整理したいですね。
なぜコンテキストを圧迫しない？Progressive Disclosureの3段階
レベル1：常時読まれるのはnameとdescriptionだけ
室谷代表取締役ここが設計の上手いところで・・・起動時にシステムプロンプトへ読み込まれるのは、フロントマターのnameとdescriptionだけなんですよ。1スキルあたり約100トークン。
本文は一切読まれません。
本文は一切読まれません。
テキトー教師DotAI 認定講師初めて触る人が一番びっくりするのがそこですね。「スキルをたくさん入れたら重くなるのでは」と身構えるんですが、常時乗るのは目次だけなんです。
室谷代表取締役目次だけ、というのはしっくりきますね。MYUUUで言えば、業務マニュアルを全部執務室に積むんじゃなく、索引だけ共有しておく感じなんですよ。
テキトー教師DotAI 認定講師全チャットに長い指示を貼るやり方と比べると差がはっきり出ます。あれは毎回全文が乗るので、数が増えるほど息苦しくなっていくんですよ。
レベル2：依頼がマッチしたときだけ本文を読む
室谷代表取締役で、descriptionがユーザーの依頼にマッチしたときだけ、ClaudeがbashでSKILL.mdの本文を読みに行く。推奨は5,000トークン未満とのことです。
テキトー教師DotAI 認定講師つまり呼ばれたときだけ本文が動く構造ですね。全スキルの本文が常に積まれているわけじゃないので、数を持ってもコンテキストが膨らみにくい。
室谷代表取締役これ、コスト目線でもかなり効くんですよね。トークンはそのまま費用に跳ねるので、常時積まない設計は運用費の天井を抑えることになる。
テキトー教師DotAI 認定講師現場感覚で言うと、本文の書き方で発火の精度が変わるのが曲者で。「いつ使うか」を具体的に書かないと、持っているのに呼ばれない状態になります。
レベル3：scriptsとreferencesは必要時のみ
室谷代表取締役さらにその先、referencesの中身やscripts、assetsは必要になるまで読まれない。スクリプトはbashで実行されて、コード自体はコンテキストに入らず出力だけが入るんですよ。
テキトー教師DotAI 認定講師最初に戸惑うのが「コードを読ませずに実行できる」点なんですよ。長い処理を書いてもコンテキストを食わないので、手順書に実行ファイルを同梱できる感覚です。
室谷代表取締役だからAnthropicも、バンドルできる情報量に実質的な上限がないと説明している。参照ファイルは読まれない限り0トークン、というのが効いてるわけです。
テキトー教師DotAI 認定講師たしかに。重い資料をいくつ置いても、普段は名前だけが見えている状態ですね。
この設計が効く場面と、効かない場面
室谷代表取締役効くのは、手順が多くて分岐も多い作業を何種類も抱えるケース。逆に、毎回必ず使う短い前提みたいなものは、スキルではなく常時読み込まれる場所に置いた方が素直なんですよね。
テキトー教師DotAI 認定講師そうですね。あとdescriptionが曖昧だと、3段階の1段目でつまずいて後の2段階に進まない。
仕組みが良いから何でも入る、わけではないところが注意点です。
仕組みが良いから何でも入る、わけではないところが注意点です。
室谷代表取締役構造として無駄が出にくいだけで、設計の質は上のメタデータで決まる。ここは経営の意思決定と同じで、入口の握り方でだいたい決まるんですよ。
テキトー教師DotAI 認定講師なるほど。まず入口の一言を磨くところから、ですね。
SKILL.mdはどう書く？フロントマターとフォルダ構成の必須ルール
フロントマターに書くのは「name」と「description」
室谷代表取締役スキルの実体はSKILL.md 1枚なんですけど、ここで最初に詰まるのがフロントマターなんですよね。必須はnameとdescriptionの2つだけ、と。
テキトー教師DotAI 認定講師そうなんです。ただ名前の制約が細かくて。
64文字以内、小文字の英数字とハイフンだけ、XMLタグは不可。しかも「anthropic」「claude」を含む名前は予約語扱いで使えないんですよ。
64文字以内、小文字の英数字とハイフンだけ、XMLタグは不可。しかも「anthropic」「claude」を含む名前は予約語扱いで使えないんですよ。
室谷代表取締役命名ルールって地味に経営判断で。先に決めておかないと、チームで作ったスキルが後からリネーム地獄になるんですよね。
descriptionは1024文字以内で、空はダメ。
descriptionは1024文字以内で、空はダメ。
テキトー教師DotAI 認定講師任意項目ではlicense、compatibility、metadataがあります。compatibilityは対応製品や必要なパッケージ、ネットワークアクセスの要否を書く枠ですね。
良いdescriptionと悪いdescriptionの差はここ
テキトー教師DotAI 認定講師発火するかどうかは、ほぼdescriptionで決まります。「Helps with projects.」みたいな抽象的な説明だと、いつ出せばいいか判断できないんですよ。
室谷代表取締役逆に良い例は、Figmaのデザインファイルを分析して開発者向けの引き継ぎドキュメントを生成する、という機能に加えて、ユーザーが.figファイルをアップロードしたとき、design specsを求めたときに使う、まで書いてある。
テキトー教師DotAI 認定講師大事なのは「何をするか」と「いつ使うか」の両方。現場でよく聞くのは、機能だけ書いてトリガーフレーズを忘れて、全然発火しないと悩むパターンですね。
室谷代表取締役ユーザーが実際に打ちそうな言葉をそのまま入れる。これ、プロダクトのオンボーディング資料と同じで、作り手の言葉と使い手の言葉はだいたいズレるんですよ。
scripts・references・assetsの役割分担
テキトー教師DotAI 認定講師フォルダの中は、SKILL.mdが必須で、あとは任意の3つに分かれます。scriptsが実行コード、referencesが参照ドキュメント、assetsがテンプレートや画像などです。
室谷代表取締役ここを分けておくと後で効くんですよね。本文に全部詰め込むと、発火のたびに読むトークンが膨らむ。
参照ファイルは読まれない限りゼロトークンなので、重い資料はreferencesに逃がす。
参照ファイルは読まれない限りゼロトークンなので、重い資料はreferencesに逃がす。
テキトー教師DotAI 認定講師スクリプトも同じ理屈で、bashで実行されるぶんコード自体はコンテキストに入らず、出力だけが入るんですよ。定型の計算処理はscriptsに置くのが素直ですね。
やりがちなNG（ファイル名・README混入・フォルダ名）
まとめ
SKILL.md作成の必須ルール
- フロントマターの必須項目はnameとdescriptionの2つだけ
- nameは64文字以内・小文字英数字とハイフンのみ・XMLタグ不可、「anthropic」「claude」を含む名前は予約語で使用不可
- descriptionは1024文字以内・空は不可、「何をするか」と「いつ使うか(トリガーフレーズ)」の両方を書く
- 任意項目はlicense・compatibility・metadata(compatibilityには対応製品・必要パッケージ・ネットワークアクセス要否を書く)
- フォルダ構成はSKILL.mdが必須で、任意でscripts(実行コード)・references(参照ドキュメント)・assets(テンプレートや画像)に分ける
- 重い資料はreferencesへ逃がす(読まれない限りゼロトークン)、定型処理はscriptsへ(コード自体はコンテキストに入らず出力のみ)
- ファイル名は厳密にSKILL.md(大文字小文字を区別、SKILL.MDやskill.mdは不可)
- フォルダ名はkebab-case(スペース・アンダースコア・大文字不可、例:notion-project-setup)
- スキルフォルダ内にREADME.mdを置くのはNG。ドキュメントはSKILL.mdかreferencesに書き、GitHub配布用のREADMEはリポジトリ直下に別途用意する
室谷代表取締役今日いちばん伝えたいのがここで。ファイル名は大文字小文字を区別して厳密にSKILL.md。
SKILL.MDでもskill.mdでも動かないんですよ。
SKILL.MDでもskill.mdでも動かないんですよ。
テキトー教師DotAI 認定講師初めて触る人がまず戸惑うのがそこです。あとフォルダ名はkebab-caseで、スペース・アンダースコア・大文字は不可。
notion-project-setupみたいな形ですね。
notion-project-setupみたいな形ですね。
室谷代表取締役スキルフォルダの中にREADME.mdを置くのもNG。ドキュメントはSKILL.mdかreferencesに書く。
GitHubで配るなら、リポジトリ直下に人間向けのREADMEを別に用意する、と。
GitHubで配るなら、リポジトリ直下に人間向けのREADMEを別に用意する、と。
テキトー教師DotAI 認定講師GitHubの習慣でついREADMEを入れたくなるんですよ。でもスキルの中身はClaudeが読む前提なので、人間向けの慣習は外に出す。
その切り分けができると一気に整理されます。
その切り分けができると一気に整理されます。
Agent Skillsはどこで使える？claude.ai・Claude Code・APIの使い分け
claude.aiはzipアップロード、対応プランとコード実行の条件
室谷代表取締役まず入り口の整理からいきましょうか。claude.aiだと、Anthropic製のビルトインスキル、つまりPowerPoint・Excel・Word・PDF作成あたりはFreeも含めた全プランで最初から使えるんですよね。
ここがまず前提で。
ここがまず前提で。
テキトー教師DotAI 認定講師そこ、最初に戸惑うのがまさにその部分なんです。「無料でも使えるって聞いたのに、アップロードの項目が見当たらない」という話をよく聞きます。
自分で作ったzipを載せるカスタムスキルはPro/Max/Team/Enterpriseで、しかもコード実行を有効にした状態じゃないと出てこないんですよ。
自分で作ったzipを載せるカスタムスキルはPro/Max/Team/Enterpriseで、しかもコード実行を有効にした状態じゃないと出てこないんですよ。
室谷代表取締役なるほど。手順としてはこういう順番ですね。
- コード実行を有効にする
- 「Settings」の「Features」を開く
- スキルのzipファイルをアップロードする
テキトー教師DotAI 認定講師はい。あと地味に大事なのが、このアップロードは基本その人個人の単位なんですよ。
チーム全員に配りたいなら別の仕組みが要る、という前提で見ておいたほうがいいです。
チーム全員に配りたいなら別の仕組みが要る、という前提で見ておいたほうがいいです。
Claude Codeは個人用とプロジェクト共有用で置き場所が違う
室谷代表取締役Claude Codeはファイルの置き場所の話になりますね。個人用なら
ここを間違えると「共有したはずのスキルが効かない」ってことになる。
~/.claude/skills/<name>/SKILL.md、プロジェクトで共有するなら .claude/skills/<name>/SKILL.md。ここを間違えると「共有したはずのスキルが効かない」ってことになる。
テキトー教師DotAI 認定講師現場感覚で言うと、最初は個人用に置いて試して、固まってからリポジトリにコミットして共有、という順番が安全です。個人用のほうは自分の全プロジェクトで効きますが、Coworkやクラウドのセッションには読み込まれないという違いもあります。
室谷代表取締役そこは運用設計の話で、経営目線で言うと「誰がどのスキルを持っているか分からない」状態が一番コストが高いんですよ。統制を効かせるならプロジェクト用に寄せたほうがいい。
テキトー教師DotAI 認定講師たしかに。あとclaude.aiにサインインしたセッションだと、そちらで有効にしたスキルが同期用のディレクトリに入ってくるので、横から見ると二重管理に見えるんですよね。
APIはcontainer.skillsと/v1/skillsで指定する
テキトー教師DotAI 認定講師APIはまた別物で、コード実行ツールが前提になります。指定は
container.skills パラメータの中で行う形で、ビルトインはskill_idで参照、自作のものは /v1/skills エンドポイントにアップロード、という役割分担です。室谷代表取締役ここ、ワークスペース全体で共有されるのがポイントですよね。個人の設定というより、組織の資産として置くイメージになる。
テキトー教師DotAI 認定講師そこは切り分けが要りますね。逆に言うと、APIに上げたものはclaude.aiの画面には出てこない。
それぞれ別の引き出しだと思っておいたほうがいいです。
それぞれ別の引き出しだと思っておいたほうがいいです。
室谷代表取締役つまり同じスキルを三箇所に置く前提で考えると、更新漏れが起きる。最初に「どこで使うか」を決めるのが先、と。
サンドボックスゆえの制約と、サーフェス間で同期されない罠
Agent Skillsの利用サーフェス別の置き場所と条件
claude.ai
- ビルトインスキル(PowerPoint・Excel・Word・PDF作成)はFree含む全プランで利用可
- 自作zipのアップロードはPro/Max/Team/Enterpriseで、コード実行の有効化が条件
- 手順: コード実行を有効化 → SettingsのFeaturesを開く → zipをアップロード
- アップロードは基本その人個人の単位。チーム全員への配布には別の仕組みが必要
Claude Code
- 個人用は ~/.claude/skills/<name>/SKILL.md
- プロジェクト共有用は .claude/skills/<name>/SKILL.md
- 個人用は自分の全プロジェクトで有効だが、Coworkやクラウドのセッションには読み込まれない
- claude.aiにサインインしたセッションでは、有効にしたスキルが同期用ディレクトリに入る
室谷代表取締役サンドボックスの中身も確認しておきたい。ネットワークアクセスは無し、実行時のパッケージインストールも不可。
ここを知らないと設計が崩れます。
ここを知らないと設計が崩れます。
テキトー教師DotAI 認定講師初めて触る人がだいたい止まるのがそこなんですよ。「実行時に何かを取りに行く」前提で組むと動かない。
事前に用意したものだけが使える前提で組み立てる必要があります。
事前に用意したものだけが使える前提で組み立てる必要があります。
室谷代表取締役で、一番事故りやすいのが自動同期されない件。claude.aiに上げたスキルはAPIに反映されないし、逆も同じ。
Claude Codeはファイルベースで、両者とは別管理になる。
Claude Codeはファイルベースで、両者とは別管理になる。
テキトー教師DotAI 認定講師なので先に自分の利用面を決めてから置き場所を選ぶのが、結局いちばん早いです。同じものを三箇所に抱えると、どれが最新か分からなくなりますから。
Agent SkillsとMCPはどう違う？併用するときの設計
MCPが道具でSkillsがレシピという関係
室谷代表取締役MCPとSkillsって「どっちを使えばいいんですか」って聞かれるんですけど、置き換えの関係じゃないんですよね。公式が厨房とレシピの比喩を使っていて、MCPが道具と設備、Skillsがその使い方の手順にあたります。
テキトー教師DotAI 認定講師たしかに。初めて触る人は「MCPがあるならSkillsはいらないのか」と思いがちなんですが、包丁があっても「この店はこの切り方」という決まりが無いと味が揃わないのと同じで。
室谷代表取締役MYUUUの現場でも、MCPでつないだだけだと毎回プロンプトで手順を説明している状態で。そこにSkillsを1枚置くと、その手順書を毎回書かなくて済む。
工数削減というより、属人化の解消に近い効果なんですよね。
工数削減というより、属人化の解消に近い効果なんですよね。
テキトー教師DotAI 認定講師現場感覚で言うと、MCPだけ入れて「なんかイマイチ」と言っている人の大体は、道具は揃ってるのに手順が無い状態なんですよ。
プロジェクト機能・カスタム指示との違い
室谷代表取締役じゃあプロジェクト機能やカスタム指示と何が違うのか。ここが一番混ざりやすいところです。
テキトー教師DotAI 認定講師プロジェクトは常時読み込まれる静的な背景知識で、カスタム指示は全チャットに広く効くもの。Skillsはタスクに関連したときだけ動的に読み込まれる手順知識で、しかもClaudeのどの画面でも使える点が違うんですよね。
室谷代表取締役常時読み込む前提だと、情報を足すほどコンテキストを食う。必要なときだけ読む設計だから、たくさん置いても本体を圧迫しない。
これは機能差というより設計思想の差なんですよ。
これは機能差というより設計思想の差なんですよ。
テキトー教師DotAI 認定講師そうそう。「全部カスタム指示に書けばいい」で膨らませると、だんだん効かなくなってくる。
あれ、パンパンの冷蔵庫と一緒で、入ってはいるけど取り出せないんですよね。
あれ、パンパンの冷蔵庫と一緒で、入ってはいるけど取り出せないんですよね。
MCP連携の上に手順を載せる実務パターン
室谷代表取締役実務だと、MCPで外部サービスにつないで、その上にSkillsでベストプラクティスを載せる形が推奨されてます。土台の上に手順を重ねるイメージです。
テキトー教師DotAI 認定講師具体的には、MCPで「触れる」ようにして、Skillsで「どの順番で、何を確認しながら、どこに出すか」を書く。新人にオンボーディングガイドを渡すのに近いですね。
室谷代表取締役順番としてはMCPが先で、Skillsが後。既にMCP連携を持っているチームほど、Skillsの効きは早いんですよね。
ゼロから作るより、動いている業務に手順を足す方が立ち上がりが速い。
ゼロから作るより、動いている業務に手順を足す方が立ち上がりが速い。
テキトー教師DotAI 認定講師そこ、ハマる人多いんですよ。逆にSkillsだけ先に作り込んで、道具が無いから何もできない、というパターンもよく聞きます。
レシピだけあって厨房がない状態ですね。
レシピだけあって厨房がない状態ですね。
自前のスキルを1つ作って試す具体的な手順
まずユースケースを2〜3個、発話レベルで書き出す
室谷代表取締役スキル作り、いきなりSKILL.mdを書き始めるとだいたい失敗するんですよ。先に「誰がどんな言葉で頼むか」を2〜3個書き出すところからなんですよね。
テキトー教師DotAI 認定講師そうなんです。現場でよく聞くのは、作りたい機能から入っちゃうパターンで。
トリガーとなる発話、ステップ、期待される結果をセットで書き出すと一気に具体的になります。
トリガーとなる発話、ステップ、期待される結果をセットで書き出すと一気に具体的になります。
室谷代表取締役発話レベルってのがミソで。「経費精算のやり方」じゃなくて、実際に打つ文をそのまま書く。
ここが雑だと、後で作るdescriptionも雑になるんですよ。
ここが雑だと、後で作るdescriptionも雑になるんですよ。
テキトー教師DotAI 認定講師2〜3個で十分です。欲張って10個並べると初回は終わらないので。
skill-creatorで雛形を作り、15〜30分で一度動かす
自前スキルを1つ作って試す手順
- 01ユースケースを2〜3個、発話レベルで書き出す「誰がどんな言葉で頼むか」を実際に打つ文で書く。トリガーとなる発話・ステップ・期待される結果をセットで。欲張らず2〜3個で十分
- 02skill-creatorで雛形を作り、15〜30分で一度動かすkebab-caseのフォルダにSKILL.mdを置き、YAMLフロントマターにnameとdescription(1024文字以内、「何をするか」と「いつ使うか」)を書く。本文はInstructions / Examples / Troubleshootingの順
- 03トリガーテスト・機能テスト・パフォーマンス比較の3種で確認発火すべき依頼10〜20件と発火すべきでない依頼で発火を確認。出力の正しさ・エラー処理、スキル有無でのツール呼び出し回数と消費トークンを比較
- 04発火しない／発火しすぎる場合はdescriptionを直す発火しないときは抽象的すぎるdescriptionを機能＋トリガーフレーズの形に。発火しすぎるなら「Do NOT use for...」で使わない場面を明示しスコープを絞る
- kebab-caseのフォルダを作る（スペース・アンダースコア・大文字は不可）
- フォルダ直下に SKILL.md を置く（ファイル名は大文字小文字まで厳密に）
- YAMLフロントマターに name と description を書く（descriptionは1024文字以内、「何をするか」と「いつ使うか」の両方を含める）
- 本文を Instructions / Examples / Troubleshooting の順で書く
- skill-creator を使う場合は、ユースケースを渡してフロントマター生成から検証までを対話で進める
室谷代表取締役MYUUUの現場だと、まず1個動くものを15〜30分で作れって伝えてます。作り込む前に発火するか見た方が早いので。
テキトー教師DotAI 認定講師skill-creatorを使うと、ユースケースを渡すだけで雛形から本文、検証まで対話で進みます。手で全部書くより最初の一歩が軽いんですよね。
室谷代表取締役ただ自動テストの実行や定量評価まではやってくれないので、そこは自分で回す前提ですね。
テキトー教師DotAI 認定講師はい。あとフォルダ名のkebab-caseとSKILL.mdの大文字小文字、初めて触る人が最初に戸惑うのはだいたいここです。
トリガーテスト・機能テスト・パフォーマンス比較の3種
室谷代表取締役テストは3種類あるんですけど、一番抜けやすいのがトリガーテストなんですよね。発火すべき依頼を10〜20件、発火すべきでない依頼も用意して、自動で発火するかを見る。
テキトー教師DotAI 認定講師機能テストは出力が正しいか、エラー処理が動くか。パフォーマンス比較は、スキル有り無しでツール呼び出し回数と消費トークンを比べる、ですね。
室谷代表取締役トークンの比較はコストに直結するので、経営目線だとここは飛ばさない方がいいんですよ。数字で見ておくと後で説明しやすいですし。
テキトー教師DotAI 認定講師3種そろって初めて「動いた」と言える、という感覚があります。
発火しないとき／発火しすぎるときの直し方
室谷代表取締役発火しないときはdescriptionが抽象的すぎるケースが多い。公式ガイドの悪い例が「Helps with projects.」で、これだとClaude側もいつ出せばいいか判断できないんですよね。
テキトー教師DotAI 認定講師良い例は機能とトリガーフレーズを両方書く形です。たとえばデザインファイルを分析して引き継ぎ資料を作るスキルなら、何をするかに加えて、ファイルがアップロードされたとき、設計仕様を聞かれたとき、といった使う場面まで書く。
室谷代表取締役逆に発火しすぎるなら「Do NOT use for...」のように使わない場面を明示してスコープを絞る。足すより削る意識ですね。
テキトー教師DotAI 認定講師この2方向の直し方さえ押さえておけば、初回でもだいたい形になります。
使う前に知っておきたいセキュリティと運用の注意点
信頼できる作成元のスキルだけを使う原則
外部スキル利用前の判断フロー
作成元が自作またはAnthropic提供か？
YES ／ 信頼できる作成元
- 外部URLへのアクセス指示があるか確認
- 外部URLを含む場合は組織ルールに従い一旦停止を検討
- 導入後も依存先の変化を運用中に監視
NO ／ 未知の外部ソース
- SKILL.md本文・同梱スクリプト・画像をすべて監査
- ファイル操作・bash・コード実行の悪用余地をレビュー
- 外部URLを含む場合は一旦停止を検討
室谷代表取締役スキルって作る側は楽しいんですけど、配布されてるものをそのまま入れるのは経営判断としてはかなり危ないんですよね。手順書の形をしていて、裏でツール権限が動くわけですから。
テキトー教師DotAI 認定講師現場でよく聞くのが「便利そうだったので配られてたものをそのまま入れました」というパターンです。中身を読まずに使うのが、たぶん一番怖いんですよ。
室谷代表取締役公式が推奨してるのは、自作かAnthropic提供のもの、つまり作成元がはっきりしているスキルだけを使うことなんです。外部の未知のソースしかない場合は、SKILL.mdの本文も、同梱のスクリプトも画像も、使用前に全部監査する前提で考えたほうがいい。
テキトー教師DotAI 認定講師ファイル操作やbashコマンド、コード実行といったツールが、本来の目的と違う形で悪用される余地があるんですよね。データの持ち出しや意図しない操作まで繋がりうるので、レビューの工程は省かないほうが安全です。
外部URLを含むスキルが特に危ない理由
テキトー教師DotAI 認定講師特にグレーなのが、外部のネットワークURLへアクセスする指示が入っているスキルです。取得してきたコンテンツの中に、悪意ある指示が紛れ込む可能性があるんですよ。
室谷代表取締役そこが厄介で、一度チェックしたから終わりでもないんですよね。信頼できる作成元のスキルであっても、参照している外部の依存先が後から変われば危険になりうる。
ソフトウェアの依存関係と同じで、入れた瞬間ではなく運用中に傷んでいくタイプのリスクです。
ソフトウェアの依存関係と同じで、入れた瞬間ではなく運用中に傷んでいくタイプのリスクです。
テキトー教師DotAI 認定講師初めて触る人は「URLを読むだけなら安全でしょう」と思いがちなんですけど、読み込んだ先の文章も指示として効いてくるのが引っかけで。ここ、ハマる人が多いところです。
室谷代表取締役だから組織で配るなら「外部URLを含むスキルは一旦止める」くらいの線引きが現実的だと思います。レビューに人員を割くコストを時給で換算しても、事故ったあとの対応コストのほうが普通に高いんですよね。
Enterpriseのスキルコンテンツスキャンとデータ保持の扱い
室谷代表取締役大企業だと、そもそも入り口で止めたいところですよね。Enterpriseプランであれば、claude.aiとClaude Coworkにアップロードされたカスタムスキルに対して、スキルコンテンツスキャンを有効化できるんです。
テキトー教師DotAI 認定講師ただし範囲外があるのを忘れがちで。Skills APIやConsole経由でアップロードしたものはスキャンの対象外なんですよ。
ここは社内説明でも見落とされやすいポイントです。
ここは社内説明でも見落とされやすいポイントです。
室谷代表取締役あとデータ保持も地味に効く論点です。スキルはゼロデータリテンションの対象外で、Anthropicの標準のデータ保持ポリシーに従う。
情シスに稟議を通すときは、機能の便利さより先にここを出すべきなんですよね。
情シスに稟議を通すときは、機能の便利さより先にここを出すべきなんですよね。
テキトー教師DotAI 認定講師現場感覚だと、監査の話は「入れる前」よりも「入れた後に何が残るか」を聞かれることが多いです。だから配布ルールと一緒に、保持の扱いも運用フローへ最初から組み込んでおくと後で揉めません。
よくある質問
Q1. プロンプトのテンプレートを保存しておくのと何が違う？
室谷代表取締役テンプレ集めてる人多いじゃないですか。あれって結局、必要なときに自分でコピペする運用なんですよね。
手が止まるのは「どれを使うんだっけ」を人間が判断してる時間で・・・
手が止まるのは「どれを使うんだっけ」を人間が判断してる時間で・・・
テキトー教師DotAI 認定講師現場でよく聞くのは「テンプレはあるのに使われない」なんですよ。Agent Skillsはフォルダを置いておけば、必要な場面でモデル側が取りに行く。
人が探す工程が消えるのが効くんだと思います。
人が探す工程が消えるのが効くんだと思います。
室谷代表取締役あとは属人化しないことですね。テンプレは個人のメモで終わりがちですけど、フォルダなら共有もレビューもできる。
中の人的にはそこの差が大きいんですよ。
中の人的にはそこの差が大きいんですよ。
Q2. 作ったスキルが勝手に呼ばれないときは？
テキトー教師DotAI 認定講師最初に戸惑うのがこれで。「置いたのに使われない」ってなるんですよ。
だいたいは説明文がぼんやりしてて、いつ使うものなのか読み取れてないケースですね。
だいたいは説明文がぼんやりしてて、いつ使うものなのか読み取れてないケースですね。
室谷代表取締役名前と説明は、中の人から見ると採用票みたいなものなんですよ。何をするか、どういうときに使うかが一目で分からないと選ばれない。
テキトー教師DotAI 認定講師あとは中身を詰め込みすぎてる場合もありますね。手順を1ファイルに全部書くより、参照用のファイルに逃がしたほうが読みに来やすいです。
まず説明文を具体的にするのが最初の一歩だと思います。
まず説明文を具体的にするのが最初の一歩だと思います。
Q3. チームで同じスキルを回すには？
室谷代表取締役チーム配布を考えると、置き場所をそろえるのが先なんですよね。個人のフォルダに置かれると、その人が抜けた時点で消える。
テキトー教師DotAI 認定講師たしかに。Git管理してるリポジトリに入れておくと、差分でレビューできるのが大きいです。
プロンプトだと差分が読めないですけど、Markdownなら日本語の直しもそのまま議論できますから。
プロンプトだと差分が読めないですけど、Markdownなら日本語の直しもそのまま議論できますから。
室谷代表取締役あと更新の責任を決めておくことですね。誰でも書ける状態にすると、似たスキルが乱立して選ばれなくなる。
時給で換算すると、整理の手間より重複のほうが高くつくんですよ。
時給で換算すると、整理の手間より重複のほうが高くつくんですよ。
Q4. 複数のスキルが同じ場面で候補になったら？
テキトー教師DotAI 認定講師発動条件がかぶると、こっちの想定と違う方が選ばれることがあります。説明文の書き分けが甘いと起きやすいんですね。
室谷代表取締役設計としては、1つのスキルに役割を詰め込まないことなんですよ。何でも屋スキルは結局どれにも当てはまって見えるので、選ばれ方も不安定になる。
テキトー教師DotAI 認定講師範囲を狭くすると発動もしやすくなるし、外したときの影響も小さいですからね。まずは小さい単位で分けたほうが運用は楽だと思います。
Q5. ChatGPTやGeminiにも同じ仕組みはある？
室谷代表取締役他社が同じ形で用意してるかというと、まだ過渡期なんですよね。各社が近い方向の機能を出してくる段階で、フォルダとMarkdownという素朴な形に落ち着いてるのは今のところ特徴的かなと。
テキトー教師DotAI 認定講師初めて触る人は「特定のツール専用の技術」と受け取るんですけど、実体はテキストの置き方の話なので。考え方は他に持ち運べますから、覚えて損はないです。
室谷代表取締役乗り換えのコストを見ておくのは大事で。フォルダで持っておけば、中の手順はそのまま別の環境でも使い回せる。
囲い込みの強い形式で書くのは、中の人的には避けたいところですね。
囲い込みの強い形式で書くのは、中の人的には避けたいところですね。
まとめ
室谷代表取締役今日の話、まとめると「大きな仕組みを覚える」というより「置き方を覚える」話だったんですよね。
テキトー教師DotAI 認定講師たしかに。SKILL.mdを1枚書いて、フォルダに置いて、呼ばれるか試す。
そこまでやると一気に腹落ちします。
そこまでやると一気に腹落ちします。
室谷代表取締役いきなり全部を仕組み化しようとしないほうがよくて。まず自分の業務で一番よく出す指示を1つ選ぶ。
それだけで十分なんですよ。
それだけで十分なんですよ。
テキトー教師DotAI 認定講師最初に戸惑うのは書き方より「何を書くか」なので、いつも口で頼んでることをそのまま書き出してみるのが近道だと思います。
室谷代表取締役MCPとの使い分けも、作りながら線が引けていきますから。手を動かした分だけ判断が早くなる。
まず1個、置いてみてください。
まず1個、置いてみてください。
