エージェントスキル（Agent Skills）

 (agentskills.io)
35 ポイント 投稿者 GN⁺ 2026-02-04 | 6件のコメント | WhatsAppで共有
  • エージェントスキルは、AIエージェントに新しい機能と専門知識を追加するためのオープンフォーマット
  • Anthropicが開発後、オープンスタンダードとして公開され、さまざまなエージェント製品で採用中
  • スキルは指示、スクリプト、リソースで構成されたフォルダ形式で、エージェントがこれを探索して、より正確かつ効率的に作業を実行する
  • ドメイン専門性、新機能の拡張、再現可能なワークフロー、相互運用性を支援
  • 企業と開発者は、これを通じて組織知識の再利用とデプロイ自動化を実現できる

概要

  • Agent Skillsは、エージェントに新しい能力と専門性を付与するためのシンプルでオープンな形式
  • 各スキルはコマンド、スクリプト、リソースを含むフォルダで構成され、エージェントがこれを読み込んで作業の正確性と効率を高める

なぜAgent Skillsなのか

  • エージェントはますます強力になっているが、実務を安定して遂行するためのコンテキスト情報の不足という問題がある
  • スキルは、必要なときに手続き的知識と組織・チーム・ユーザーごとのコンテキストを読み込めるように提供する
  • スキルを持つエージェントは、タスクに応じて能力を拡張できる
  • スキル作成者は、一度構築した機能を複数のエージェント製品に配布できる
  • 互換エージェントでは、ユーザーがすぐに新機能を追加できる
  • チームと企業は、組織の知識をバージョン管理可能なポータブルパッケージとして保存できる

Agent Skillsでできること

  • ドメイン専門性: 法務レビュー、データ分析などの特化知識を再利用可能な指示としてパッケージ化
  • 新機能: プレゼンテーション作成、MCPサーバー構築、データセット分析など、さまざまな機能を追加
  • 再現可能なワークフロー: 多段階タスクを一貫性があり監査可能なプロセスに変換
  • 相互運用性: 同じスキルを複数の互換エージェント製品で再利用可能

採用状況

  • Agent Skillsは複数のAI開発ツールでサポートされている
  • 例として、Factory.ai、Gemini CLI、Mux、Ampcode、Letta、Autohand.ai、Spring AI、Goose、Piebald.ai、OpenAI Codex、Cursor、Databricks、Mistral Vibe、Roocode、VS Code、Agentman.ai、Trae.ai、Commandcode.ai、Firebender、Opencode.ai、Claude.aiなどが含まれる

オープン開発

  • Agent Skillsフォーマットは、Anthropicが最初に開発し、オープンスタンダードとして公開
  • その後、さまざまなエージェント製品がこれを採用しており、エコシステム全体からの貢献を受け入れている
  • GitHubリポジトリでフォーマットとサンプルスキルを確認できる

はじめ方

関連記事

6件のコメント

 
cgl00 2026-02-04

Anthropicの公式リポジトリがあるのに、なぜサードパーティーがこのようなプロジェクトをやっているのでしょうか？
 
skageektp 2026-02-04

> Agent Skills is an open format maintained by Anthropic and open to contributions from the community.

Anthropicが標準を作ったんですね
 
cgl00 2026-02-04

ここも公式なんですね.. https://github.com/anthropics/skills これとは別物なんでしょうか？
 
skageektp 2026-02-04

はい、お送りいただいたそれは実装体です。
本文で共有されているのは Spec です。

たとえば
Docker のようなものの標準 = OCI
Docker、podman = OCI を実装したコンテナランタイム

（間違っているかもしれません）
 
cgl00 2026-02-04

ああ、仕様と実装なんですね……ありがとうございます
 
GN⁺ 2026-02-04
Hacker Newsのコメント

  • この議論は、標準化の必要性への疑問から始まっている
    私は、良いドキュメントの本質は依然として「人が読みやすく書くこと」だと思う。わざわざ新しいフォーマットを強制する理由があるのだろうか。もし本当に生産性が向上するなら、比較研究で証明できるはずだ

    • 他の人たちが言っていることに加えて、標準化は訓練とRLに活用できる機会も開くと思う
    • 実際に比較実験はあった。Hugging Faceの社員がQwen3-0.6Bモデルを codex + skills でファインチューニングしたところ、humanevalスコアが+6向上したという。関連リンクはこちら、プロジェクトはhuggingface/upskillにある
    • このシステムは単なるドキュメントではなく、すべてのskillsのインデックスを作成して各会話ごとにLLMへ渡す。こうすると、LLMは必要なときだけskillを読む。GUIの機能発見性に近い考え方だ。個人的にはREADME中心の構造のほうが直感的だと思う
    • 私はClaude Codeで業務自動化をしており、各作業をスラッシュコマンドでつないでいる。結局のところ、skillsもドキュメント化の別形式にすぎないように感じる。長期的には、context windowの拡張とモデル知能の向上によってskillsパラダイムは消えていく気がする
    • ただし現在のモデルで見ると、Claudeはskillの説明までしか読まずに止まるため、トークン節約効果が大きい。大規模リポジトリではこの差を体感できるほどだ。このパターンを広く知らせる価値はある

  • 私たちのチームはskillsを再利用可能な準決定的関数のように扱って成功してきた
    たとえば /create-new-endpoint スキルには、OpenAPIの更新、統合テストの追加など、あらゆるボイラープレートが含まれている。CLIでJIRAチケット番号を入力すると、LLMが一貫した品質で作業を完了する

    • 誰かが「時間が経ってもその一貫性をどうテストするのか」と尋ねていた

  • フォルダ構成を標準化しようという提案があった

    .claude/skills
.codex/skills
.opencode/skills
.github/skills
    • 標準ではないが、多くのCLIツールは .md ファイルをスキャンして実行する。それでもプラグインまで含めた統合標準化があるとよいと思う
    • 実際にCodexが始めて、OpenCodeがすぐ後に続いたという。関連ツイート
    • この議論はagentskills/agentskills#15でも進行中だ
    • ある人は「まだ初期段階すぎて、標準化は創造性を制限しかねない」と言っていた
    • 別の人は、XDG base spec に従って ~/.config/claude のようなパスを使うほうがよいと主張していた。現在の ~/.claude 方式は不便だという

  • 各サブフォルダにREADME.mdを作って関連するskillへのリンクを置け、というコツもあった。人間にとっても有用だ。関連する記事はClaude Skills Considered Harmful

    • 「skillsは結局、特定テーマのREADMEにすぎない」という意見も出ていた。繰り返し説明しなければならない内容をskillとして整理すればよい。標準フォルダに従う必要もなく、必要なときに直接contextへ追加すればよい
    • また別の人は、just のようなコマンドランナーを使えば人間にもエージェントにも役立つと言っていた

  • 私はskillsを明示的なワークフローとして扱うのが効果的だった
    「Xをして、Yをして、Zを検証する」のように完結した手順として定義すると、エージェントはそれをひとつのモードとして認識する。一方で、曖昧なガイドラインの形だと無視されやすい

    • ある人は、特定の状況でskillを自動有効化するhookシステムをClaudeに適用したと言っていた。Pythonファイルを扱うときに自動で関連skillを呼び出す、といった具合だ
    • 別の人は、skillとcommandの違いが曖昧だと指摘していた。結局どちらもコマンドのように使われるなら、区別する必要があるのかという疑問だ
    • この構造はObsidianのノートやCLIコマンド集に似ている、という人もいた
    • また別の人は、skillの有効化条件を非常に明確に記述すべきだと強調していた。Claude Codeでは /foo のように明示的に呼び出せるので、その方式を好むという

  • ある人は、skillsによって暗黙のドメイン知識を文書化できると見ていた。開発者の頭の中にあったルールを記録し、それをLLM学習に再利用できる

  • 「エージェントが要求しない限りskillsを使わないのでは？」という質問が出ていた

    • 同じ問題を経験している人は多い。現在のモデルはskillsベースでRLVR訓練されていないため混乱しやすい。次世代モデル（たとえばOpus）は、skillsをはるかに安定して使うようになると期待されている
    • Vercelの評価でも、56%のケースでskillが呼び出されなかったという。代わりにAGENTS.mdアプローチのほうがより広い範囲で効果的だったと報告している。関連ブログ
    • Codexを使っている人は、AGENTS.mdでskillディレクトリを明示しておけばかなりうまく機能すると言っていた。ただし、skillsが増えるほど衝突の可能性も高まるので、シンプルに保つのがよいという
    • また別の人は、skillsをほとんど使えなかったとして、むしろskillの内容をAGENTS.mdに直接入れたほうが正確だったと言っていた

  • skills.shで3番目に人気のskillは、単なるコマンドのダウンロードリンクだったという。こうしたSKILLS.md/AGENTS.md/COMMANDS.mdファイルは結局のところプロンプト集にすぎず、使い方を誤ると危険になりうる

    • ただ、ある人は「道具は結局、責任ある使用が重要だ」と応じていた

  • 新しいプログラミング言語を開発中の人は、LLMが学習していない言語を理解させるためにAGENTS.mdとSKILLSを使っているという。標準化のおかげでツール統合が容易になったという話だ

  • 本当の価値はフォーマットではなく、段階的開示（progressive disclosure）にある
    すべての指示をひとつの文書に詰め込むと、不要なトークンを浪費する。skillsパターンは、必要な瞬間にだけ詳細を読み込めるようにしてくれる。標準化は主に    配布と再利用    のためのものだ

    • これについてMOOLLMプロジェクトの開発者は、Semantic Image Pyramidの概念へ拡張したと説明していた。
      GLANCE.yml → CARD.yml → SKILL.md → README.md の順で段階的な詳細化を適用する。
      GLANCEは5〜70行で「関係があるか？」だけを判断し、CARDはインターフェース定義、SKILLは実際の手順、READMEは人間向けの説明だ。
      INDEX.mdはINDEX.ymlより80%以上圧縮率が高く、物語的な構造を提供すると言っている。
      関連リンク: INDEX.yml, INDEX.md
      さらにsniffable-python構造により、コード先頭50行だけ読めばAPIを把握できるようにしている。
      関連資料: Semantic Image Pyramidの説明, sister-script, sniffable-python README, sniffable-python SKILL