🤹

Agent Skillsに全部賭ける価値はあるか

に公開

はじめに

https://agentskills.io/

Agent Skillsがオープンスタンダードとして公開されました。

https://gihyo.jp/article/2025/12/agent-skills-to-open-standard

今年に入ってからCline, Claude Code, opencode, Codexとコーディングエージェントがたくさん出てきましたが、どれも発展途上であり、場当たり的なアップデートばかり繰り返され、全部賭けるにはリスクが大きすぎるようなものばかりでした。

また、コーディングエージェントが登場する前から存在するRAGやMCP、コーディングエージェントを効率的に利用するためのAGENTS.mdファイルにおいても、互換性を重視するあまり、良い仕様改定が行われてきませんでした。

そんな中登場したのがAgent Skillsです。

個人的には今まで登場してきたものの中で、唯一、文句無しの完成度を誇るものでした。

自作コーディングエージェントShaftの作者であり、コンテキストエンジニアリングに関する様々な知見を持つ私が自信をもってオススメできます。

ただ、驚き屋みたいなことはしたくないので、この記事を読むだけではAgent Skillsの良さは伝わらないかもしれません。
可能な範囲で、良さを伝えてきたいと思います。

何が違うか

まず、Agent Skillsのないコーディングエージェントは、どのような動作をするのかざっくりと説明します。

  1. 何らかのテンプレートやスキーマを参考にAIが出力したtextやjsonをもとに、検索と置換を行う形式(ファイルシステムベースのエージェント)
  2. Tool Calling(旧Function Calling)をもとに、AIエージェントのように自律的な作業を行う形式(ツールベースのエージェント)

AiderやClineのような古典的なコーディングエージェントは主に1を行っており、Claude CodeやCodexのような一般的なコーディングエージェントは2を行っています。

ちなみにShaftは1を行っています。
なぜShaftが1のようなファイルシステムベースのエージェントにしたのかというと、当時のツールベースのエージェントはコマンドやテストをバイパスする癖があったからです。
要するに、勝手にrm -rf ~/しないようなコーディングエージェントにしたかったのです(皆さんもこのコマンドは絶対実行しないでね!)

今回のAgent Skillsは、何とこの1と2のどちらでも実装できる仕様になっています! わーい!

https://agentskills.io/integrate-skills

仕様ではbashやcatのようなシェルコマンドを通じてアクセスするよう紹介されていますが、以下の作業を行えるのであれば何でもよさそうです。

概要
スキルに対応したエージェントには、以下の機能が必要です。

  1. 設定されたディレクトリからスキルを検出する
  2. 起動時にメタデータ(名前と説明)を読み込む
  3. ユーザーのタスクと関連スキルを照合する
  4. 完全な指示を読み込んでスキルを有効化する
  5. 必要に応じてスクリプトを実行し、リソースにアクセスする

nani.now: AIが高速に解説付きで翻訳

さて、ここで気になるのが、MCPやAGENTS.mdとどう違うのか、という点です。

まずMCPですが、クライアントサーバモデルなので、通常のWebサービスと同様トラフィックの問題が発生します。
ローカルでサーバを立てる方法もありますが、サーバを動かし続ける手間が発生します。

また、MCPはツールを呼び出すために必要な説明でコンテキストウィンドウのスペースを占有してしまい、コード編集に必要なTool Callingに時間がかかったり、正常に機能しなくなったりする問題が発生します。

Agent Skillsで必須のnameは最大64文字、小文字、数字、ハイフンのみ使用可能で、descriptionは最大1024文字という厳格な制限を設けているため、Claude CodeやMCPが抱えているコンテキストエンジニアリングの問題を解決する設計になっていることが分かります。

https://agentskills.io/specification

続いてAGENTS.mdですが、実はこのSKILL.mdはAGENTS.mdの上位互換と言っても過言ではない仕様になっています。
SKILL.mdでアクセスできるぐらいなので……。

現在のAGENTS.mdのデメリットをいくつか挙げてみましょう

  • AGENTS.mdが何をするファイルなのかファイル名を見ただけではわからない
  • Frontmatterでメタデータを付与できない
  • AGENTS.mdをプロジェクトルート以外に置けてしまう(プロジェクトルートのディレクトリを再帰的に読み取る)
  • AGENTS.md以外のファイル(mdファイル含む)を参照できない
  • OpenAIのやる気がない (agentsmd/agents.md/issues)

SKILL.mdは何かよくわからんけど学習やナレッジをもとにしたスキルなんだなということがすぐにわかりますし、Frontmatterで様々なメタデータを付与することができます。

また、Markdownと同じ書き方でスキルのディレクトリにあるコンテキストファイルを読み込む仕組みになっています。
これはCLAUDE.mdと異なる点で、アットマークをパスの先頭につける必要がないので、Markdownで使える静的サイトジェネレータとも相性がいいですね。

最後にAgent Skillsの仕様ですが、MCPほど複雑ではなく、AGENTS.mdよりしっかり定義されているため、実装もしやすいです。
公式でskills-refというリファレンス実装ツールも提供されています。

https://github.com/agentskills/agentskills/tree/main/skills-ref

まあAnthropicがやる気出しまくって仕様やSDKを更新した結果、破たんしかけているMCPもあったりするので、あまりAnthropicにやる気があっても困るのですが……。

既知の問題

Security considerationsを除けば99%文句無しの完成度を誇るAgent Skillsですが、唯一、仕様に含まれておらず、不満に感じる点があります。
何だか分かりますか?

Directory structure
A skill is a directory containing at minimum a SKILL.md file:

skill-name/
└── SKILL.md          # Required

skill-nameディレクトリの親ディレクトリが定義されていないのです。
このスキルがホームディレクトリに存在するべきなのか、コーディングエージェントのプロジェクトルートに存在するべきなのか、一時的なものは/tmp/skillsディレクトリに置いてもいいのかすら定義されていないのです。

現時点ではClaude Codeは~/.claude/skills、Github Copilotは~/.copilot/skills、実験的に実装したCodexは~/.codex/skillsがAgent Skillsのルートディレクトリになっているので、もしこれらのコーディングエージェントで同じスキルを使用したい場合はディレクトリをsyncする手間が発生します。

この点についてはあえて定義しなかった可能性も考えられます。
コーディングエージェントのプロジェクトルートで決め打ちしてしまうとプロジェクトをまたいだ時に使えなくなりますし、コーディングエージェントではないAIエージェントがスキルを使う場合はホームディレクトリを汚染する可能性があります。

もし今後Agent Skillsの仕様が改定されたら~/.claude/skillsの中のAgent Skillsが使えなくなる可能性も考えられますが、スキルの親ディレクトリを定義しなければ~/.claude/skills-v2にマイグレーションしてもらうとかできますからね。

でもそのうち./.agents/skillsディレクトリか~/.config/agents/skillsディレクトリで統一すべき謎の勢力が出てくるんだろうな……。

おわりに

ここまでいくつか説明しましたが、Agent Skillsに全部賭けるとはどういうことなのでしょうか?

  • Agent Skillsを実装したコーディングエージェントを使う
  • Agent Skillsを使いやすくするツールを作成する
  • ツルハシのごとくAgent SkillsをGitHubで配布する

そうではなく、まず初めに、古いやり方から脱却する必要があるように思えます。
最近のコーディングエージェントは何も考えずMCPを使用したり、CLAUDE.mdやAGENTS.mdでオレオレプロンプトエンジニアリングを行っていたり、過剰なTool Calling呼び出しを行っていたり、まあひどいです。

Agent Skillsから逆算して考えることで、生成AIやコーディングエージェントに必要なものは何なのか分かるようになってきます。

https://agentskills.io/what-are-skills

  • ファイル単位ではなく、ディレクトリ単位で考える
    • ディレクトリであれば拡張しやすく、zipやtar.gzでパッケージにできる
  • SKILL.md以外のファイルを必須にしない
    • ディレクトリ単位で考えるけど、ディレクトリ内にはファイル1つだけあればいい
  • 必須のメタデータを複雑にしない
    • domainのような命名規則をもったnameと、minLengthとmaxLengthのみを設けたdescription
  • Markdownに独自のシンタックスを追加しない
    • アットマークをパスの先頭につけるやつ
  • Tool Callingのようなツールベースで考えない
    • [runtime, script, ...args]や仕様駆動開発(SDD)のようなファイルシステムベースの仕組みはまだ発展の余地がある
  • 常識に囚われない
    • ターミナルコマンドとシェルスクリプトいる? 全部JavaScript/TypeScriptとPythonでよくない?
  • Security considerationsの解決

これらをまとめて実現できるのがAgent Skillsですから、Agent Skillsに全部賭けるのは、まあ悪くないと思いませんか?

最後にAgent Skillsに全部賭ける価値はあるか考えるきっかけになった、SkillPortの紹介をして終わりにしたいと思います。
ありがとうございました。

https://zenn.dev/gotalab/articles/65cd3ff3cb9152

参照

https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
https://blog.lai.so/claude-skills/
https://syu-m-5151.hatenablog.com/entry/2025/12/19/173309

今回の内容は今まで書いてきた生成AIやコンテキストエンジニアリングに関する記事を踏襲しているので、併せてご参照ください。

https://zenn.dev/tkithrta/articles/9a6f1f2d249790
https://zenn.dev/tkithrta/articles/6f7160584c3124
https://zenn.dev/tkithrta/articles/898bf6c84f8584
https://zenn.dev/tkithrta/articles/e4379c440c3841

そのうちShaftにもAgent Skillsを実装する予定ですので、実装したら改めて紹介します。

https://gitlab.com/tkithrta/shaft

Discussion