エージェントスキル

概要

Agent Skills は、エージェントの業務精度と効率を高めるための 手順・スクリプト・リソース集。 会社やチーム固有の知識 をエージェントが随時取得可能。 スキル作成者 は一度構築した機能を複数エージェント製品へ展開可能。 組織知識のパッケージ化 と バージョン管理 による再利用性向上。 Anthropic発のオープン標準 としてGitHubで公開、幅広いエコシステムで採用拡大中。

Agent Skillsの概要

Agent Skills は、エージェントが業務を正確かつ効率的に遂行するための 指示・スクリプト・リソース のフォルダー
エージェントが本来持たない 業務文脈や手順知識 を外部から動的に取得可能
会社・チーム・ユーザー固有の情報 をエージェントに柔軟に付与可能
タスクに応じて スキルの組み合わせや拡張 が可能な仕組み

スキル作成者・エージェント・組織への利点

スキル作成者 ：一度作成したスキルを複数エージェント製品へ 横展開 可能
エージェント ：スキル対応で 新機能を即時追加 できる柔軟性
チーム・企業 ： 組織知識のパッケージ化 と バージョン管理 による知見の蓄積・再利用

Agent Skillsが可能にすること

ドメイン専門性 ：法務レビューやデータ分析など 専門知識の再利用可能な手順化
新機能追加 ：プレゼン作成やMCPサーバー構築、データセット分析など エージェントの能力拡張
再現性あるワークフロー ：複数工程の業務を 一貫性と監査可能性 のあるフローに変換
相互運用性 ： 異なるエージェント製品間で同一スキルを再利用 可能

採用状況・オープン開発体制

主要AI開発ツール でAgent Skillsのサポート拡大傾向
Anthropic が開発したフォーマットを オープン標準 として公開
GitHub 上で仕様や実装がオープンに管理・貢献可能
エコシステム全体 からの参加・拡張が促進されている状況

参考リンク

GitHub での仕様・導入方法閲覧
エージェント製品 や 開発ツール での導入事例

Hackerたちの意見

エージェントって、頼まないと全然使わないって人いる？

└

キーワードを使って明示的にトリガーしても、期待してた時に発動しないことが多いんだよね。

└

「スキル」って、結局は.mdファイルで、圧縮された統計出力マシンが見つけるかどうかも怪しいし、ちっちゃいコンテキストウィンドウに保持されるかも微妙なんだよね。

└

Vercelも同じことを発見したみたいだね: 「56%の評価ケースで、スキルは一度も呼び出されなかった。エージェントはドキュメントにアクセスできたけど、使わなかった。スキルを追加してもベースラインより改善はなかった。」 > … > スキルは無駄じゃないよ。AGENTS.mdアプローチは、Next.jsでのエージェントの動作を全タスクにわたって広く改善するんだ。スキルは、ユーザーが明示的にトリガーする縦のアクション特化型ワークフローでより効果的に機能するよ。https://vercel.com/blog/agents-md-outperforms-skills-in-our-...

└

そうそう。頼んでも全然スキルを使ってくれなくて、ほんとに困ってる。数日前に誰かの分析を見たんだけど、エージェントがスキルのコンテキストを直接AGENTS.mdに放り込むと、もっと正確になるって言ってた。

└

これ、うちでも問題になってる。スキルを使う時もあれば、使わずに自分でやろうとする時もある。イライラするよね。これは（ほぼ）解決できる問題だと思う。今の最先端モデルはスキルでRLVRトレーニングされてなかったし（その時は存在しなかったから）、小さい説明が同じツールコールスキーマに詰め込まれてることでちょっと混乱してるんじゃないかな。（少なくともClaude Codeではそうなってる。）次の世代は、スキルが使えるタスクでたくさんRLVRされてるだろうから、もっと信頼性高く使うようになると思う。とにかく、次のOpusリリースまで待ってれば、かなりの改善が見られるはずだよ。（もちろん、これらは非決定論的なことだから、あれこれ言うのはあれだけど、「スキルを30%の確率で見逃す」から「2%の確率で見逃す」になるのは期待してもいいと思う。）

└

同じく！スキルの指示を一般のAGENTS.mdに入れると、うまくいくよ。

└

使うものによるかもね。俺はcodexを使ってるけど、指示に従ってくれることが多いよ。リポジトリのスキルディレクトリを明示的に指し示すAGENTS.mdを使ってる。そこには、ビルドの仕方とかテストの仕方、何をするべきかとか、そういう明らかなことの指示を主に入れてる。あんまりスキルは多くないかな。スキルが多いほど混乱するかもしれないし、対立する指示が増えると、LLMが本当にやりたいことを理解するのが難しくなるからね。スクリプトから外れたら、よく中断して何をするべきか教えて、関連するスキルを更新するようにしてる。これが結構うまくいくみたい。シンプルに保つのが効果的だね。

フォルダを標準化してほしいな。 .claude/skills .codex/skills .opencode/skills .github/skills

└

ln -sが助けてくれる！

└

.agent/ スキルはまだ標準化するには早い気がする。まだ始まったばかりなのに、なんでそんなに早くクリエイティビティを制限したいんだろう？

└

さらに悪いことに、opencodeはデフォルトで単数形を使うんだよね： .opencode/skill

└

これが標準じゃないとはいえ、-cliツールがリポジトリ内の.mdファイルをスキャンして、ほとんどの場合スキルを実行してくれるのは分かる。でも、これだけじゃなくてプラグインのためにも標準があった方がいいな。

└

競合する基準が14個あるよ。

└

それについては https://github.com/agentskills/agentskills/issues/15 で話し合われてるよ。

└

今まさにこれが起こってるよ。Codexが始めて、OpenCodeもそれに続いた感じ。

└

標準化するにはまだ早いかもね。基準はいいけど、開発や実験を遅らせることもあるから。

└

これらのツールがxdgベースの仕様に従って、設定を~/.config/claudeとかに置くといいのにね。~/.claudeじゃなくて。これがすごく気になるところなんだ（確かに、設定の環境変数で上書きできるツールも多いけど、自動的に正しいことをしてくれたら嬉しいな）。

私たちのチームは、スキルを再利用可能な半決定論的な関数のように扱うことで成功を収めてる。ランダムなエッジケースのための運任せのプロンプトとは違う感じでね。例えば、/create-new-endpointというスキルがあって、そのスキルにはエンジニアがロジックを実装する以外にやるべきボイラープレートタスクの詳細なチェックリストが含まれてる（例えば、OpenAPI仕様の更新、統合テストの追加、エンドポイントのボイラープレートなど）。エンジニアはCLIからスラッシュコマンドでスキルを手動で呼び出し、JIRAのチケット番号を提供して、簡単な設計の話をする。LLMは、私たちの既存のアプリケーションアーキテクチャに合った形で、これらのチケットを一発で処理できるんだ。

└

これらのスキルの一貫性を時間をかけてどうやってテストするの？それとも、そんなの必要ないの？

この件は、苦い教訓が十分に理解されていないように感じる。理解できる形式なら、英語で指示を書いてもいいんじゃない？人間の読者に対してやるのと同じように！良いドキュメントの定義は本当に変わってないよ。（追記：私の狭量さが出てるけど、英語じゃなくてもいい）この標準化は本当に必要なの？これが利益をもたらすのは、こういう仕様を書くのが好きな人たちだけじゃないの？もし本当に生産性が上がるなら、比較研究を行って証明できるはずだよね。それでも、長期的には価値がないかもしれない。

└

すべてはコンテキストの管理にかかってる。苦い教訓は長期的に適用されるし、そう、長期的に見れば、コンテキストウィンドウが大きくなったり、異なるアーキテクチャで完全になくなったりするから、こういうのは必要なくなるだろう。でも、ここ1、2ヶ月で十分なスキルを定義したから、もしこれらを全部CLAUDE.mdに入れたら、コーディング用のコンテキストが残らなくなっちゃうと思う。これは一時的な標準になるだろうけど、現状の技術を考えると、役に立つものだね。

└

みんな比較をしてるね。Hugging Faceの社員からの情報だけど、Codex + スキルのファインチューニングでQwen3-0.6BがHumanEvalで+6になって、最初の実行でベーススコアを上回ったんだ。今週の実験を再実行したけど、Codexの新しいスキル統合を使ったよ。Claude Codeみたいに、Codexはフルスキルをコンテキストに取り込んで、失敗した実行から始まらないんだ。最初の実行でベーススコアを上回って、2回目の実行ではClaude Codeを上回ったよ。とはいえ、実行間のCodexモデルの不一致があるから、完璧な比較ではないね。著者はスキル評価にかなり力を入れているみたい。

└

僕はClaude Codeを使ってビジネスのタスクを自動化してるんだけど、それぞれのタスクにスラッシュコマンドを設定したんだ。各スラッシュコマンドは、指示が書かれた.mdファイルを読み込むところから始まる。Claudeにこれがスキルとどう違うのか聞いたら、唯一の実質的な違いは、スラッシュコマンドを呼び出さないとClaudeはこれを使えないってことだった（それは別にいいけどね。勝手に在庫をチェックされるのは嫌だから）。だから、結局はドキュメントに過ぎないと思う。スキルがうまく機能する証拠も見られたけど、長い目で見れば、プロンプトエンジニアリングみたいに廃れていく気がする。まず、多くのスキルが不要になると思う。モデルは特定のスキルなしでスライドデッキを作ったり、フロントエンドデザインをしたりできるから（Geminiは、基本モデル以上のものでデザインがすでに優れてると思う）。次に、コンテキストウィンドウの拡大や全体的な知能の向上が、特定のスキルのパラダイムを不要にするだろうね。Claudeに知ってほしいことをclaude.mdに全部ぶち込んでおけばいいんだ。

└

指示は標準的な文書だけど、これだけじゃないんだ。このシステムが追加するのは、すべてのスキルのインデックスで、説明から構築されていて、各会話でLLMに渡されるんだ。アイデアは、必要なときにLLMがスキルを読むことを許可して、事前にコンテキストに読み込まないことなんだ。人間もインデックスを使うけど、こんな風には使わないよね。でも、GUIとの類似点があって、人間にとって機能の発見を促進する方法があると思う。READMEを中心に整理してほしいな。タスクのディレクトリがあって、そこにREADME.mdもあるんだけど、Codexがスキルを持つ前から、タスクを扱うときにREADMEを読む必要があることを理解してたんだ。スキルシステムはディレクトリ依存が少ないから、少し普遍的だけど、これが本当に必要かどうかはわからないな。

└

この標準化は本当に必要なの？この標準化は、基本的に文書のリストをスキャンしやすくするものだよね。人間には永続的な記憶があるけど、LLMにはそれがないから、コンテキストに読み込む必要があって、必要なときだけ読み込むのが助けになることもある。例えば、前向性健忘症があったら、すべてを最適に整理してラベル付けしたいと思うよね？すべての情報を手元に置いておくアプリがあればいいかも。

└

指示のことじゃなくて、発見性とデータのことだよ。確かにWWWはただのテキストだけど、それがHTTPやHTML、ブラウザや検索エンジンが必要ないってわけじゃない。スキルもそれと同じで、エージェントの能力のためのものなんだ。長期的には君の言う通り、エージェントはこれらを自分で取得するようになるだろうし、いつかは私たちのエージェントではなくなるかもね。

└

自然言語のことは正しいけど、標準化はすごく重要だよ。モデルそのものだけの話じゃないからね。いわゆるハーネスはLLMのパフォーマンスに大きな影響を与えるし、標準化があればすべてのハーネスがスキルをインデックスできるようになる。

└

スキルはただのドキュメントじゃないよ。計算可能性（プログラムやスクリプト）、データ（アセット）、そしてすべてを効果的に使うためのドキュメント（リソース）を含んでいる。プログラムとデータは、LLMがアクセスできる決定論的な結果の基盤なんだ。面白い情報（バスの時刻表、食事情報、その他千のこと）を含むSQLiteデータベースを埋め込んで、スキルによって実行されるPythonプログラムがそれにアクセスできる。少なくともClaudeの場合、VM内で実行されて、スマホからも使えるよ。確かに、今のところスキルは標準というより慣習に近い。スキルにはバージョン管理、配布、更新、ユニークな命名、選択的ネットワークアクセスが欠けてるけど、すごく便利でアクセスしやすい。

└

ここで標準化が必要なのは、スキルが動作する環境だね。スキルの指示はAIによって解釈されるし、サポートスクリプトは環境によって解釈される。LZMAを圧縮する方法を英語で説明して、AIにトークンごとにやらせるのは避けたいよね。とはいえ、それはAIにとってかなり良い厳密なベンチマークタスクになるかも。

└

あなたの言う通りかもしれないけど、相手によって英語の書き方が変わるのを感じるんだ。人とAIでね。正式な研究はしてないから証明できないけど、英語をLLMの「考え方」に合わせて調整すると、エージェントからの出力が良くなる気がするんだよね。

エージェントがスキルを明示的に求められないと使わないっていう観察には共感する。実際には、スキルを背景のコンテキストではなく、明示的な「ワークフロー」として扱うことで成功してる。うまくいくパターンは、完全で自己完結したシーケンスを表すスキル - 「Xをやって、次にY、次にZ、最後に確認」 - で、明確なトリガー条件があること。エージェントはこれをオプションの参考資料ではなく、異なる操作モードとして認識する。うまくいかないのは、スキルを一般的なガイドラインや「ベストプラクティス」の文書として扱うこと。これらは文脈の中で埋もれたり、完全に無視されたりする。エージェントには適用するタイミングの明確な信号がないからね。メンタルモデルのシフト：スキルをドキュメントではなく、明示的に呼び出すサブルーチンのように考える。もしそれに対して関数を書かないなら、たぶんスキルにすべきじゃないよ。

└

さらに良いのは、特定の状況でスキルを発動させるシステムだね。俺はこれにClaudeを使ってフックを使ってるけど、めっちゃうまくいってる。スキルの説明は「ガイダンスによって指示されない限り発動しない」って感じ。例えば、Pythonファイルが読み込まれたり書き込まれたりしたら、ガイダンスが返ってくる（1回だけ、長いクールダウン付き）ことで、グローバルや会社特有のPythonスキルが発動するんだ。Claudeはそのスキルを発動させて、俺たちの好みに合わせてPythonを書いてくれる。

└

説明は「いつスキルを使うか」を非常に正確にしないといけない。なぜなら、フロントマターはモデルがコンテキストで見る唯一のものだから。でも一方で、少なくともClaude Codeでは、スキル「foo」は/ fooとしてアクセスできるから、古いコマンドディレクトリの一般化として、そういう意味では明示的にすることを好む傾向がある。

└

それは「スキル」と「コマンド」の価値についての疑問を提起するね。Claude Codeは両方をサポートしてるけど、どちらを使うべきかはっきりしないことが多い。特にスキルが、まあ、コマンドとして最も効果的な場合はね。

└

自分のObsidianのノートを思い出すな。たまに必要になるCLIコマンドで、未来の自分のために説明も書いてる。

スキルの概念を含むドメイン特化型エージェントを作ってるよ。一度に一つだけアクティブにすることで、指示が衝突する可能性を減らしてる。各ターンの始めにアクティブなスキルを選択・維持・変更するために小さなサブエージェントを使ってる。最近の会話にマッチするスキル（またはなし）を見つけるために小さくて速いモデルを使ってる。他のアプローチも試したけど、自分のユースケースにはこれがうまくいった。スキルのモデルはこれに似てるけど、いつ使うか、いつ使わないかの具体的な例と反例を持たせるように拡張した。これが、小さなモデルが自由形式のテキスト説明のニュアンスを捉えられない傾向を助けたんだ。

└

これを「行動」と呼ぶことを考えてみたら？ゲームやロボットAIの行動ツリーに似せる感じで。単一の行動が同時にアクティブになるという考え方に従ってるし。

プロのヒント：AGENTS.mdファイルに入れるかもしれない役立つ内容を含むREADME.mdファイルをサブフォルダに作って、関連するスキルをそこにリンクさせるといいよ。スキルやスキルフォーマットって呼ばなくても大丈夫。すべてに使えるし（人間にもね！）。少し前にスキルについての愚痴を書いたけど、今でもいくつかの点で関連性があるよ。

実装ノート: - スキルをファイルシステムを通じて公開する必要は全くないよ。スキルをロードするためのツールコールを追加するのも簡単だし、指示メタデータにスキルIDを入れるだけでいい。もし指示からスキルを完全に外したいなら、discover_skillsツールを用意してもいいし。 - もう一つの方法は、エージェントの呼び出しの前に「スキルセレクター」の推論を置くこと。これにより、現在の問い合わせやトランスクリプトとスキルのメタデータを受け取り、関連するスキルのリストを返すことができるよ。ツール選択と同じ考え方で、大量のスキルがある時にコンテキストの帯域幅を節約できる。

└

「discover_skillsツールを持つべきだよ。スキルの「フロントマター」をツール呼び出しの「関数定義」として扱うのは、ある種の同値類みたいなもんだ。この理解があったおかげで、この標準化が提案されるずっと前に、LLMに依存しない（サンドボックス化された）オープンスキルを作ることができたんだ。」

オープンスキル: https://github.com/instavm/open-skills

事前に用意された「スキル」はフロンティアモデルにとって逆効果だと思う。これらのスキルはすでにLLMの中に存在しているから、彼らがすでに知っていることを説明する必要はないよ。この問題を完全に逆転させて、環境が時間をかけてモデルに反発することで、望ましい行動や能力を引き出すのが好きなんだ。エージェントが環境を数ターン探ることを許可して、彼らの行動が不適切だというエラーをフィードバックすると、もっと面白い行動が得られるよ。ツールのフィードバックが詳細であれば、モデルが期待される行動に「ロックオン」するのにそれほど時間はかからない。良いツールフィードバックを使えば、空白のシステムプロンプトでも高品質な結果が得られるよ。

数日前に気づいたんだけど、https://skill.mdが新しいURLにリダイレクトされるようになった。

ハクソク