Agent Skillsとは、AIエージェントに特定の作業手順や判断フローを持たせるための仕組みです。

通常、AIに作業を依頼する時は、目的、前提条件、進め方、注意点、出力形式などをプロンプトに書きます。単発の作業であれば、それでも大きな問題はありません。

しかし、同じ種類の作業を何度も依頼する場合、毎回同じ説明を書くのは非効率です。さらに、説明の抜け漏れがあると、AIの出力品質も安定しにくくなります。

Agent Skillsは、このような繰り返し発生する作業の進め方を、AIが再利用できる形でまとめるために使います。

AIが読める業務手順書として考える

Agent Skillsは、人間向けのマニュアルをそのまま置き換えるものではありません。

AIが作業中に読み、判断に使いやすいように、簡潔で実行しやすい形にする必要があります。

特に重要なのは、長い背景説明を入れすぎないことです。AIがすでに理解できる一般論ではなく、自社の業務で守るべき手順や判断基準を中心に書く方が実用的です。

Agent Skillsを理解するうえで、最も混同しやすいのがRulesとMCPです。

結論から言うと、以下のように役割が違います。

ここでは例として、FigmaデザインをもとにWebページを実装する「Figma実装Skill」を作る場合を考えます。

まず整理するのは、「どの場面で使うSkillなのか」です。Figma実装Skillであれば、Figmaデザインを確認してWebページを実装する時、既存パーツを探す時、PC/SP差分を確認する時、実装後の表示確認をする時などが対象になります。

この内容は、SKILL.mdのdescriptionに書きます。descriptionは、そのSkillが何をするものか、どのような場面で使うものかを示す説明文です。ここが曖昧だと、意図した場面でSkillが使われにくくなります。

次に、SKILL.mdの本文には作業の流れを書きます。Figma MCPで対象デザインを確認する、既存テンプレートやコンポーネントを探す、流用できる箇所と新規実装が必要な箇所を分ける、PC/SP差分を確認する、実装後に表示やリンクを確認する、といった流れです。

この時、単に手順を並べるだけでなく、判断基準も入れておくと実務で使いやすくなります。たとえば、既存パーツを優先して使うのか、新規実装にする条件は何か、確認できない項目をどう報告するか、といった内容です。

ここまで整理できたら、Skillをディレクトリとして管理します。構成はシンプルで、最低限必要なのはSKILL.mdだけです。

figma-build-skill/
├── SKILL.md      # 必須 - Skillの概要、使う場面、作業手順を書く
├── references/   # 任意 - 補足資料やルール
├── templates/    # 任意 - 出力テンプレート
├── scripts/      # 任意 - 実行用スクリプト
└── assets/       # 任意 - 画像やサンプルファイル

このように、SkillはSKILL.mdを中心に作成できます。

ただ、最初からファイル構成やdescriptionの書き方を意識すると、難しく感じるかもしれません。その場合は、いきなりSKILL.mdを書き始めるのではなく、AIに「こういうSkillを作りたい」と相談するところから始めるのもよい方法です。

たとえば、「Figma実装のSkillを作りたい」「既存パーツ確認、PC/SP差分確認、実装後の表示確認まで含めたい」と伝えれば、対象業務や使う場面、作業手順、判断基準を対話しながら整理できます。

skill-creatorのような「Skillを作るためのSkill」を使えば、この整理をより進めやすくなります。そこから、descriptionに何を書くか、SKILL.mdの本文にどの手順を入れるかを詰めていくことも可能です。

Skillは、作っただけでは使われるとは限りません。どの場面で使うのか、どの粒度で分けるのかを決めておかないと、存在していても実務に定着しにくくなります。

どのタイミングでSkillを使うか決める

まず重要なのは、「いつSkillを使うのか」を決めることです。

例えば、FigmaからのWordPress構築Skillなら、以下のようなタイミングがあります。

• 新規ページ構築時
• 下層ページ追加時
• パーツ追加時
• コードレビュー前
• 実装後確認時

毎回明示的に呼ぶのか、自動で呼ばれる前提にするのかでも運用は変わります。

このルールを決めておかないと、Skillが存在していても使われなくなります。

Skillを細かく分けすぎない

Skill運用でよく起きるのが、「Skillが増えすぎる問題」です。

例えば、

• Figma確認Skill
• パーツ追加Skill
• フォーム確認Skill
• レスポンシブ確認Skill

のように細かく分けすぎると、どれを使うべきか分からなくなります。

そのため、Skillは「作業フロー単位」で分ける方が管理しやすくなります。

今回の例であれば、

• Figma確認
• 既存パーツ確認
• WordPress実装
• 実装後確認

までを、1つの構築Skillとして扱う方が自然です。

Agent Skillsは、一度作って終わりではありません。

実際に使ってみると、手順が足りない、出力形式が使いにくい、確認漏れが起きる、といった問題が見えてきます。

そうした運用結果をもとに見直すことで、Skillは実務に合う形へ近づいていきます。

定期的にログを見直す仕組みを作る

Skill改善は、気づいた時だけ行うよりも、定期的に見直す仕組みにした方が続けやすくなります。

たとえば、週に1回、直近Skillを使ったセッションを自動で抽出し、AIに改善案を出させる運用が考えられます。

この時に見るべきなのは、単に「うまくいったかどうか」だけではありません。想定した場面でSkillが使われたか、手順が飛ばされていないか、出力形式が使いやすいか、確認漏れが起きていないかを確認します。

そのうえで、description、手順、禁止事項、出力形式のどこを直すべきかを整理すると、感覚ではなく実際の利用結果にもとづいてSkillを改善しやすくなります。

Agent Skillsは、AIエージェントに作業を丸投げするための仕組みではありません。

人が持っている業務フローや判断基準を、AIが再利用できる形に整理するための仕組みです。

まずは、よく繰り返している作業を1つ選び、その手順をAgent Skillsとして整理することから始めるのが現実的です。

作って終わりにせず、実際の利用結果を見ながら更新していくことで、Agent Skillsは、AI活用を継続的に見直すための土台になります。