AIエージェント

Agent Skillsとは：仕組み、MCPとの違い、作る価値のあるスキル

2026/7/2 （更新: 2026/10/12）

🤖 AIを使用して執筆

Skill の実体はただのフォルダ

一つのスキルは、手順・スクリプト・参照資料をまとめたフォルダである²。最小構成は SKILL.md ひとつである。このファイルの先頭に name と description を書いた YAML を置き、その下に「何を、どういう手順でやるか」を書く。PDF のフォームを埋める、社内の表記ルールに従う、といった仕事の”やり方”を、コードとして持ち運べる形にしたものだ。仕様が薄い（ただのフォルダと Markdown）ことが、この速い普及の一因だと本稿は見る。Anthropic 自身は、この形式の単純さを、組織や開発者が自前のエージェントを作りやすくなる利点として挙げている²。

段階的開示でコンテキストを軽く保つ

肝は段階的開示（progressive disclosure）である²。

1. 最初は、各スキルの名前と一行説明だけがシステムプロンプトに載る。だからスキルをいくつ入れても、常時載るのは一行ぶんずつで済む。
2. その仕事に関係するときだけ、モデルはそのスキルの SKILL.md 本文を読み込む。
3. さらに必要なら、同梱された参照ファイルやスクリプトを個別に辿る。モデルは、関係ないスキルの中身を最後まで読まない。

ファイルシステムとコード実行のツールを持つエージェントなら、作業のたびにスキル全体をコンテキストに読み込む必要はなく、必要な分だけ読めばよい。だから一つのスキルに同梱できる量は、実質的に無制限になる²。Anthropic がオープン標準として公開した狙いは、ツールをまたいだ移植性にある³。

MCP と何が違うのか

エージェントを使う人がまず疑問に思うのは、先行する標準 MCP（Model Context Protocol）との棲み分けだろう。両者の違いをひと言でいえば、次のとおりである。

• MCP は「接続」。 外部のデータやシステムへ、安定した経路でつなぐ（=エージェントに新しい能力を足す）⁴。
• Skills は「手順」。 公式は Skills も「新しい能力を足すもの」と書くが、その中身は、つないだ先で何を・どうやるかをそろえる手順書である。形式はフォルダと Markdown、必要ならスクリプトである（=毎回説明し直さずに済ませる作法）²。本稿の「能力／手順」という切り分けは、公式の語法ではなく説明のための整理である。

両者は競合せず、補完し合う。さらにいまは、MCP の側が Agent Skills を取り込んでいる。MCP の「Skills Over MCP」作業部会は、スキルを MCP を通じてどう発見・配布・消費するかを定める場で、Agent Skills 仕様との連携も正式に scope に入っている⁷。その成果として、Skills 拡張（SEP-2640）が2026年9月に Final になり、公式の拡張 io.modelcontextprotocol/skills として公開された⁷。作業部会はもともと、スキルを MCP の第一級プリミティブにする提案（SEP-2076）の議論から生まれたが、その提案自体は2026年2月に閉じられている。実務では、たとえば MCP で GitHub や CI につなぎ、Skill で「ビルド傾向の分析とレポートの型」を固定する、というふうに重ねて使うのが素直な形になる。

どのスキルを作る価値があるか

仕組みは軽いので、作ろうと思えばいくらでも作れる。だが、作る手間に見合うスキルは限られる。本稿では、次の三つに価値が集まりやすいと考える。二つ目は、仕様サイトが「組織・チーム・利用者に固有のコンテキスト」として名指しする用途である³。一つ目は Anthropic の解説記事が挙げるコードの決定性に²、三つ目は仕様サイトの「反復可能なワークフロー」と、専門知識の例に並ぶ体裁の整形を本稿でまとめたものに当たる³。

• 決定的な再現性が要るとき。 手順を毎回モデルに推論させるのでなく、同梱したスクリプトを実行させる。PDF から全フォーム項目を抜く、といった「毎回同じでないと困る」処理はここに落とす²。
• 組織・チーム固有の作法。 表記ルール、レビューの手順、社内ドメインの前提がこれに当たる。いずれも、モデルが事前学習で持っていない、その現場だけの知識である。
• フォーマット重めの反復作業。 帳票・定型ドキュメント・決まった体裁の生成物。

逆に、一度きりの指示や、モデルが放っておいてもできる自明なことをスキルにしても、常時載る名前と一行説明の一覧に、ほとんど選ばれない項目が増えやすい。仕様サイトはさらに、「この PDF を読んで」のような単純な一段階の依頼なら、説明文の噛み合いが完璧でも、基本のツールで片づくためにスキルが呼ばれないことがあると書く⁸。自明な仕事では、description をどれだけ磨いても選ばれるとは限らない。

普及が生む二つの新しいリスクは説明文の質と実行の信頼

普及の速さは魅力だが、運用側が見落としやすい点が二つある。

• 発見は description の質に懸かっている。 多数のスキルが載る設計では、モデルは名前と一行だけを見て「関係ある／ない」を判断する。仕様サイトはこの一行が「発火の負担をまるごと背負う」と書いており、専用の指針まで置いている⁸。中身がどれだけ良くても、その一行で選ばれなければ読まれない。スキルを増やすほど、書き分けの精度が効いてくる。
• スキルはコードを実行できる。 同梱スクリプトを走らせられるのが強みだが、それは裏を返せば「何を実行させるか」という信頼と実行の面が増えるということだ。移植性が上がり、他所で書かれたスキルを載せやすくなるほど、出所の確認は省けなくなる。

ここは楽観できない。共有スキルの説明文やコード例に不正なロジックを仕込んでおくと、エージェントが通常作業でそれを流用した瞬間に、明示的な指示なしでシステム権限のペイロードが走る。Qu らは、2026年4月に公開した査読前の報告で、この「サプライチェーン汚染」を実証したと述べている。4フレームワーク・5モデルの8構成で、エージェントが悪性コードを生成するか実行するかしてしまう率は11.6〜33.5%。ただし下限をつくっているのは守りの堅さではない。11.6%の構成は試行の6割が実行時エラーで落ちており、論文自身がこのセルを「保守的な下限」と断って、主要な結論は妥当応答率87%超の5構成に置いている。守りが最も堅い構成の値は13.5%だ⁶。実際にホスト上でペイロードが走った率だけを取っても2.3〜27.1%あり、最も堅い構成でも2.3%は走った。同じ構成で、露骨に「これを実行しろ」と書き込む従来型の注入は実行率0%だった⁶。論文はこの対照を「下限を与えるもの」と限定し、より巧妙な注入との比較は今後の課題としている⁶。攻撃は防御の二層もともに抜けている。静的解析は攻撃の90.7%を捕まえたが、2.5%は静的解析とモデル側の安全アライメントの両方をすり抜けた。なお著者らは責任開示を行っており、確認された4件の脆弱性のうち2件は修正済みだと記している。4件の共通原因として論文が挙げるのは、フレームワークが実行権限を意味ではなく構文上の境界で与えるという、設計上の穴である⁶。

共通して効く歯止めは新しくない。認可は LLM の判断に任せず下流で強制し、エージェントに渡す機能と権限は必要な最小限にとどめることだ⁹。Qu らの報告はさらに、Claude Code 上の3モデルの結果を突き合わせ、3つとも突破した攻撃用スキルが1.6%にとどまると数えている（単一モデルでは13〜20%）⁶。論文はここから、異種モデルの併用で攻撃面が2%未満へ縮むと推論している。併用した防御そのものを走らせた値ではない。

競合をまたぐ共通フォーマットは、MCP と、常時読ませる指示ファイルの共通形式 AGENTS.md¹ に続いて、ここでも合意に至った。ただし運営の形は同じではない。MCP と AGENTS.md は2025年12月、Linux Foundation の下に新設された中立の財団 Agentic AI Foundation へ移された¹⁰。Agent Skills は、仕様サイトがもともと Anthropic の開発と記す形式で、2026年10月時点ではこの財団の事業の一覧に載っていない³¹⁰。いずれにしても、「置くだけで動く」の手軽さと、「どれを置くべきか・その出所は確かか」の判断は別の問題として残る⁶。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。