Agent Skillsとは？MCP・プロンプトとの違いと作り方

Agent Skillsとは？MCP・プロンプトとの違いと作り方

毎週の会議メモを整理するとき、毎回「決定事項を先に書く」「担当者が不明なら補わない」「期限がある作業は表にする」と説明していませんか。Agent Skillsは、このように繰り返す依頼の共通部分を、必要な場面で参照できる形にまとめるために役立ちます。

ただし、ファイルを保存するだけで、どんなAIでも必ず同じように動くわけではありません。この記事では、一般的な仕組みと製品ごとの設定を分けながら、プロンプトやMCPとの違い、SKILL.mdの構成、最小の作成例、選ばれ方と出力を確かめる方法まで説明します。

Agent Skillsで再利用するのは「作業の進め方」

Agent Skillsを理解するには、単なる知識集よりも「特定の仕事のための手順書一式」と考えると分かりやすくなります。人が引き継ぎを受けるときも、資料を渡されるだけでは、どこから読み、何を判断し、どの形で提出すればよいか分かりません。目的、順序、判断基準、見本がまとまっていると、仕事を進めやすくなります。

AIへの依頼でも同じです。「会議を要約して」という指示だけでは、会話の流れを短くするのか、決まったことだけを抜き出すのかが曖昧です。そこで、決定事項、TODO、未確認事項という出力区分や、提案を決定と取り違えない基準をスキルに記述します。会議ごとに変わる記録は、その都度の入力として渡します。

このとき、再利用する部分と、毎回変わる部分を分けることが大切です。例えば「期限の記載がなければ未記載とする」は共通の手順です。一方、「次回の公開日は10月10日」という情報は、その会議に固有のデータです。後者を共通手順へ混ぜると、別の会議でも古い日付を使ってしまう原因になります。

スキルの中には、文章による指示だけでなく、補足資料やテンプレート、必要に応じた実行コードも含められます。しかし、すべてを最初から用意する必要はありません。繰り返し使う判断と出力形式が整理されていれば、文章だけの小さなスキルにも意味があります。高度な自動化の仕組みを先に作るより、まずは一つの作業の完成条件を明確にする方が始めやすいでしょう。

また、スキルを追加しても、モデルの内部の重みが更新されるわけではありません。モデルが実行時に参照できる情報が増えることと、学習によって能力を変えることは異なります。特定業務の手順を補う仕組みとして捉えると、「導入すれば未知の業務まで自動で正しく判断できる」という期待を避けられます。

プロンプト・MCP・ハーネスとの違い

Agent Skills、プロンプト、MCP、ハーネスは、同じものを別の名前で呼んでいるわけではありません。ただし、互いに排他的な選択肢でもありません。指示を与える、業務手順をまとめる、外部ツールにつなぐ、実行を支えるという役割で整理すると、組み合わせ方が分かります。

通常のプロンプトとの違いは、指示文であるかどうかよりも、どう整理し、いつ参照し、何と一緒に再利用するかにあります。長い定型プロンプトをコピーしても業務は進められますが、用途の説明や参考ファイルまで一緒に管理したい場合にはスキルの形式が役立ちます。逆に、一度だけの短い依頼なら、その場で条件を伝える方が簡単な場合もあります。

MCPとの関係は、文書を取り出す部分と、文書を整理する部分に分けると理解できます。MCPを通じて取得した記録を、スキルに書かれた手順で要約することは可能です。一方、ユーザーが会議記録を貼り付けるだけなら、その整理作業に外部接続は必要ありません。Skillsの利用にMCPが常に必要なわけでも、MCPを使えば業務手順が自動でそろうわけでもありません。

例えば、社内の文書サービスにつながっていても、「承認前の案を決定事項に含めない」という会社のルールまでは接続だけで伝わりません。その判断基準をスキルに持たせ、実際のデータ取得には利用環境が提供するツールを使います。業務知識と接続方法を分けることで、文書サービスが変わっても手順の一部を再利用しやすくなります。

個々の概念をさらに確認したい場合は、プロンプトエンジニアリングの解説、MCPの解説、ハーネスエンジニアリングの解説も参考になります。本記事では、これらを前提に業務手順をどう切り出すかへ焦点を当てます。

SKILL.mdを中心としたフォルダー構成

スキルの中心となるのが、SKILL.mdというMarkdownファイルです。冒頭にYAML形式の設定部分を置き、その後に通常のMarkdownで指示本文を書きます。YAMLは設定項目と値を表す書き方で、ここでは名前や説明を記述します。Markdownは見出しや箇条書きを書くための形式です。最初は、決まった書式の冒頭部分と、その下の手順書という理解で十分です。

meeting-notes-organizer/
├── SKILL.md
├── scripts/       （任意：実行コード）
├── references/    （任意：補足資料）
└── assets/        （任意：テンプレートなど）

この図の補助フォルダーは、役割を説明するために並べたものです。最小構成では、meeting-notes-organizerフォルダーと、その中のSKILL.mdだけで始められます。空の補助フォルダーを形式的に作る必要はありません。資料が増えた時点で、手順そのものと参考情報を分けると管理しやすくなります。

形式の詳細はAgent Skillsの公式仕様にまとめられています。SKILL.mdを500行未満に保つことは推奨であり、500行に達した瞬間に形式違反になるという意味ではありません。また、行数が少なければ良いスキルになるわけでもありません。必要な判断は本文に残し、特定の場合にしか使わない長い資料を分ける、という設計が重要です。

例えば、会議の決定事項とTODOを整理するだけなら本文だけで足ります。一方、部署ごとに異なる書式を使うなら、部署別のテンプレートを補助ファイルに分けられます。その際は「どの条件なら、どのファイルを見るか」を本文に書きます。ファイルを追加しただけで、用途まで正しく伝わるとは限らないためです。

必要な情報を段階的に読み込む仕組み

Agent Skillsの特徴の一つが、必要な情報を段階的に開示する考え方です。一般的な流れは、名前と説明から候補を把握し、選ばれたスキルの本文を読み、さらに必要な補足資料やコードを利用するというものです。すべてのスキルの全資料を、毎回まとめて読ませる設計とは異なります。

1. 候補を把握する：名前とdescriptionを手掛かりに、そのスキルが何のために用意されているかを判断します。
2. 手順を読む：依頼に関連するスキルが選ばれると、SKILL.mdの本文から進め方や出力条件を確認します。
3. 必要な補足を参照する：詳しいルール、テンプレート、実行コードが必要になった場合に、それらを使います。

例えば、会議メモ整理のスキルに通常会議用と専門委員会用の補足資料があるとします。通常の会議なら共通手順だけを読み、専門委員会の記録であると分かった場合に、その委員会の用語集を参照する設計が考えられます。本文に資料の利用条件を置くことで、関係のない資料まで読み込む必要を減らせます。

ただし、重要な入口の情報まで補足ファイルに隠してしまうと、最初の選択がうまくいきません。「何の依頼に使うか」はdescriptionへ、「選ばれた後に何をするか」は本文へ、「特定の条件で必要な詳細」は補足へ分けます。段階的な読み込みは、短くするために情報を削ることではなく、必要になる順序に合わせて置き場所を分けることです。

この考え方は、モデルが一度に扱える情報量に関係するコンテキストウィンドウを意識するうえでも役立ちます。ただし、スキルを使えば必ず処理が速くなる、料金が安くなるとは断定できません。参照する資料の量、実行する処理、やり直しの回数、利用製品によって結果は変わります。

実装ごとの細かな読込方法には違いがありますが、仕組みの基本はAgent Skillsの公式概要で説明されています。利用者としては、資料を大量に詰め込むよりも、どの資料をいつ読むかが追える構成にすることが実践的です。

スキルが選ばれる条件とdescriptionの書き方

スキルを作るときは、本文の詳しさだけでなく、入口になる説明を整える必要があります。利用環境によっては、ユーザーが使うスキルを明示的に指定する方法と、依頼内容から関連するスキルが暗黙に選ばれる方法があります。具体的な指定の操作や表記は製品ごとに異なるため、スキル名を書けばすべての環境で同じ呼び出しになるとは考えないでください。

descriptionには、何を処理し、何を出力し、どのような依頼に使うかを書きます。「仕事を効率化する」「文章を分かりやすくする」といった広い説明では、議事録、メール、報告書など多くの依頼に当てはまってしまいます。スキル同士の役割も重なりやすくなるため、対象と成果物が分かる表現にします。

「会議」という単語だけで適用範囲を決めないことも大切です。会議の記録を整理する依頼と、来週の会議の議題を考える依頼は、どちらも会議に関係しますが、作業の目的が違います。前者では既存記録の忠実な整理が必要で、後者では新しい案の作成が必要です。利用場面を「既存の記録を整理する依頼」と書けば、この境界を説明しやすくなります。

本文に細かい発動条件を何十個も並べても、本文を読む前の候補選択には十分に役立たない場合があります。入口では短く具体的に用途を伝え、選択後の判断は本文で説明すると役割が明確になります。似たスキルが複数あるなら、descriptionを横に並べて、入力と成果物の違いが読み取れるかを確かめましょう。

また、発動条件は厳密なプログラムの条件分岐と同じではありません。環境や依頼の書き方によって、想定したスキルが選ばれないこともあります。通常の依頼文で試したうえで、明示指定が可能な環境ではその方法も試すと、選択の問題なのか、選ばれた後の手順の問題なのかを切り分けやすくなります。

最小のSKILL.md例：議事録から決定事項とTODOを整理

ここでは、ユーザーが渡した会議記録を整理するだけのスキルを作ります。メール送信やファイルの削除、外部サービスへの登録は行わない例なので、手順の書き方に集中できます。以下は記事用に作成した最小例です。対応環境で使う際は、親フォルダーをmeeting-notes-organizerとし、その中のSKILL.mdへ記述します。

---
name: meeting-notes-organizer
description: 会議メモや文字起こしから、決定事項・TODO・未確認事項を整理する。既存の会議記録を整理する依頼で使う。会議の企画や招待文の作成には使わない。
---

# 会議記録の整理

## 目的
渡された記録に基づき、決まったことと次に行う作業を把握できる形にする。

## 手順
1. 会議記録があるか確認する。なければ記録の提供を依頼する。
2. 決定事項、TODO、提案、未確認の内容を区別する。
3. 記録から読み取れる内容だけを整理する。提案を決定扱いにしない。
4. TODOは、作業内容・担当者・期限の3列の表にする。
5. 担当者や期限の記載がない場合は「未記載」とする。
6. 矛盾や採否不明の提案は、未確認事項に残す。

## 出力形式
- 決定事項：箇条書き。該当する記載がなければ「記録上なし」。
- TODO：作業内容・担当者・期限の表。なければ「記録上なし」。
- 未確認事項：確認が必要な点を箇条書き。なければ「記録上なし」。

## 作業範囲
- 入力された記録を整理する。記録にない事実を外部から補わない。
- メール送信や外部サービスへの登録は、このスキルの作業に含めない。

先頭と途中にある---で囲まれた部分が、YAML front matterと呼ばれる設定部分です。nameはスキルを識別する名前で、ここでは親フォルダー名とそろえています。descriptionは、本文を読む前でも用途が分かるように書いています。その下にある「目的」「手順」「出力形式」「作業範囲」は、作業を進めるための本文です。

本文の見出し名や数を、この例と同じにすることが必須というわけではありません。仕事の内容に合わせて構成できます。ただし、何を目指し、どの順に処理し、何を提出するかが分かれていると、人も確認しやすくなります。最初から長い注意書きを並べるより、期待する振る舞いを短い手順として表す方が、修正箇所を特定しやすいでしょう。

この例で重視しているのは、記録にない内容を埋めないことです。「TODOの表を必ず完成させる」とだけ指示すると、担当者や期限まで推測して書く余地が生まれます。そこで、情報がない欄には「未記載」と書くルールを設けました。入力不足の扱いを決めることは、見た目を整えること以上に、業務で使える出力につながります。

実際に試すときは、次のような架空の短い会議メモで十分です。

ヘルプページの公開日は10月10日に決定。佐藤さんが10月3日までに原稿案を提出する。掲載画像も差し替えることになったが、担当者と期限は決めていない。英語版を作る案も出たが、採否は未決定。

期待する整理では、決定事項に公開日と画像差し替えを含め、TODOは次のように分けます。元の記録に年の指定がないため、年を推測して加える必要はありません。

未確認事項には、画像差し替えの担当者と期限、英語版作成の採否を残します。英語版の作成は提案段階なので、確定したTODOとして登録しません。「英語版も作ることに決定」と出力されたなら、要約が読みやすくても確認に合格したとはいえません。

スキル本文に作業範囲を書いたとしても、それ自体がシステム上のアクセス制御になるわけではありません。ここでは何をする手順なのかを明確にしています。実際に利用できるツールや権限は、実行するアプリケーションや組織の設定で管理する必要があります。

初めて作るときの5つの手順

最初のスキルは、大きな業務全体を自動化しようとするより、入力と完成形を説明できる作業に絞ると作りやすくなります。議事録の整理、決まった観点での文章レビュー、提出用レポートの整形など、普段の依頼から毎回繰り返す部分を探してみてください。

1. 対象の作業を一つ選ぶ。「会議業務を全部支援する」ではなく、「既存の会議記録から決定事項とTODOを整理する」と範囲を決めます。入力が何で、何を出力すれば終わりかを一文で表します。
2. 良い出力の条件を決める。見出しや列だけでなく、提案を決定扱いしない、不明な担当者を補わないなど、間違えてはいけない判断を整理します。手元にある良い作例を、機密情報を除いて見本にする方法もあります。
3. name、description、短い本文を書く。利用場面を説明し、必要な手順と出力形式を記述します。最初は補助フォルダーを増やさず、本文だけで成立するかを確かめます。
4. 利用製品が対応する場所へ配置する。スキルを読み込める環境か、どこへ置くか、どう指定するかを確認します。配布形式が共通でも、設定方法まで一つに統一されているとは限りません。
5. 代表的な依頼で試し、必要な箇所だけ直す。選択、出力、入力不足への対応を分けて確認します。説明を追加するときは、実際に起きた問題と結び付けて修正します。

配置の具体例として、Codexではリポジトリ内の.agents/skills/<skill-name>/SKILL.mdという形が使えます。この例なら.agents/skills/meeting-notes-organizer/SKILL.mdです。これはCodexにおけるローカル配置の例であり、すべてのAI製品に共通するインストール先ではありません。他の製品で同じ場所へ置いても、そのまま検出されるとは限りません。

また、配置が終わった段階では、まだ期待どおりに使えることを確認したことにはなりません。利用環境で候補として認識されるか、依頼時に選ばれるか、必要な手順が実行されるかを確かめます。スクリプト付きのスキルなら、読み込みとは別に、必要なプログラムや実行権限がそろっているかも確認対象になります。

作成の考え方や明示指定・暗黙選択については、OpenAIのスキル作成ガイドも参考になります。本記事の例は手順を学ぶためのものであり、製品ごとの設定手順や組織の運用ルールは、使う環境に合わせて確認してください。

「使う・使わない・入力不足」の3種類で検証する

スキルの確認では、成功しやすい依頼を一つ試すだけでは足りません。使ってほしい場面で選ばれることに加え、関係のない依頼へ過剰に適用されないこと、必要な入力がないときに作り話で埋めないことを見ます。最初は次の3種類を用意すると、問題のある箇所を見つけやすくなります。

選ばれたかどうかと、良い出力になったかどうかは別々に評価します。環境にスキル利用の表示やログがある場合は、読み込まれたスキルを確認します。表示がない場合、出力が期待する形になっただけで「必ずスキルが選ばれた」とは判断できません。モデルが通常の依頼だけで似た回答を作ることもあるためです。

出力の評価では、元記録と照らし合わせて、事実が増えていないかを見ます。表の形が整っていても、担当者を取り違えたり、未決定の提案を実施予定に変えたりしていれば問題です。反対に、必要な情報が記録にないため「未記載」と返すことは、この例では正しい動作です。空欄をなくすことを成功条件にしないでください。

短い例で確かめた後は、少し条件を変えます。決定事項がない記録、期限だけが省略された記録、途中で方針が変更された記録などを用意すると、単純な抽出だけでは分からない問題が見えてきます。個人情報や機密情報を使わず、架空の記録で始めても判断ルールの確認はできます。

効果を見たい場合は、同じ入力を、スキルを指定する場合と通常の依頼だけの場合で比べる方法があります。完成までに必要だった修正回数、事実の抜けや追加、作業時間など、目的に合った観点を使います。利用モデルや入力条件が違うと比較しにくいため、できる範囲で条件をそろえ、少数の試行だけで効果を断定しないことが大切です。

修正するときは、「選ばれなかったのでdescriptionの利用場面を明確にする」「不明な期限を補ったので本文の扱いを具体化する」というように、問題と変更点を対応させます。変更後は成功例だけでなく、使わない依頼と入力不足の依頼も試します。適用範囲を広げる修正で、別の依頼への過剰適用が増えることもあるからです。

うまく動かないときの見直し方

期待どおりの結果が出なかったとき、すぐに指示を長くする必要はありません。認識、選択、手順の実行、出力の確認のどこで問題が起きたかを切り分けます。配置場所が違っていて読まれていないのに本文を詳しくしても、原因は解決しません。

例えば、会議招待メールの作成にも議事録整理のスキルが選ばれてしまうなら、「会議の仕事を支援する」という説明が広すぎる可能性があります。除外条件を大量に追加する前に、「既存の会議記録から決定事項とTODOを整理する」と対象を明確にします。一方、選択は正しくてもTODOの担当者を推測する場合は、descriptionより本文の判断基準を直す方が問題に対応しています。

短く明確な説明や適用条件、必要な資料だけを読む構成については、OpenAIのスキルとプロンプトに関する運用指針でも扱われています。過剰に細かい指示は、重要な条件を埋もれさせる場合があります。実際の失敗に対応する説明を加え、重複や矛盾が生まれていないかを読み返すことが有効です。

変更のたびに、何を直したかを一文で記録しておくと改善を追いやすくなります。「品質向上」のような広い説明より、「未決定の提案がTODOに混ざるため、提案の扱いを明記した」と書く方が、次に同じ問題が起きたときの判断材料になります。

使いどころと導入を見送る場面

スキルに向いているのは、入力内容は毎回変わる一方で、進め方や完成条件には共通部分がある作業です。同じ注意点を何度も伝えている、担当者ごとに出力形式がばらつく、資料のどこを見るべきかが決まっている、といった場面から探すと候補を見つけやすくなります。

• 議事録の整理：記録は毎回変わっても、決定事項、TODO、未確認事項に分ける基準を共通化できます。
• 文章のレビュー：事実と意見を区別する、用語の揺れを指摘する、修正理由を添えるなど、確認の観点をそろえられます。
• レポートの整形：受け取った数値やメモを決まった順序に整理し、根拠のない数値を追加しないといったルールをまとめられます。
• 社内資料に沿った説明：依頼に応じて必要な手引きを参照し、回答に必要な部分を整理する手順を共有できます。

例えば文章レビューでも、「すべてを良い文章に直す」では好みの違いが大きくなります。「製品紹介文に含まれる断定表現を確認し、根拠の不足を指摘する」のように、確認対象と出力を限定すると判断しやすくなります。対象が定まった後で、必要なら用語集や表記ルールを補足資料として追加します。

一方、次にいつ使うか分からない単発の依頼なら、スキルとして管理する手間の方が大きい場合があります。また、作業の目的や評価基準がまだ決まっていない段階では、先に試行を重ねて良い進め方を見つける必要があります。曖昧な手順をそのまま保存しても、曖昧さが解消されるわけではありません。

日々変わる数値や最新情報を、スキル本文へ固定して書くことにも注意が必要です。例えば毎月の売上を整理するなら、集計や説明の手順を再利用し、その月のデータは別の入力として渡します。定型手順と更新頻度の高い情報を分けることは、古い情報を使い続けないためにも役立ちます。

複数の業務を一つに詰め込みたくなったら、入力と成果物が同じかを確認してください。会議前の議題作成、会議後の記録整理、参加者への連絡は連続する仕事ですが、使う情報や必要な権限が違います。独立した作業として試せる単位に分けると、それぞれの適用範囲と確認方法を明確にできます。

安全に運用するための権限・資料・変更管理

実務で使うときは、スキルに書かれた手順と、それを実行する環境を分けて管理します。スキルを保存しても、コード実行環境、外部ツール、認証情報、利用権限が自動で付与されることはありません。「社内文書を読む」と書いてあっても、接続先と権限がなければ取得できません。実行できない処理を、指示文を強くするだけで解決しようとしないことが大切です。

逆に、環境が広い権限を持っていれば、その環境で動く手順やスクリプトの内容を確認する必要があります。外部配布のスキルを導入するときは、SKILL.mdの説明だけでなく、同梱されたコードが何を読み、何を書き換え、どこへ送信するかを確認します。外部の処理を追加で取得する仕組みがある場合は、その取得先も確認対象です。

初めて試す場合は、機密情報を含まない架空の入力や、変更しても支障のない作業用データから始めると挙動を確認しやすくなります。例えば議事録整理なら、本文で使った短い架空の会議記録で、記録の内容に忠実な出力になるかを先に見られます。外部送信や本番データの更新を伴うスキルでは、利用環境側の権限や確認の設定も作業に合わせます。

APIキー、パスワード、アクセストークンなどの認証情報を、SKILL.mdや共有する参考資料へ直接書くのは避けます。フォルダーを配布したり、リポジトリへ保存したりすることで、意図しない相手へ渡る可能性があるためです。認証が必要な場合は、利用環境が提供する秘密情報の管理方法を使い、スキルには必要な設定の名称や前提を記述します。

参照資料の扱いも重要です。要約対象の会議記録や取得した文書は、作業の入力です。その中に「別のファイルを送信して」といった文が含まれていても、作業手順を変更するための正当な指示とは限りません。資料の内容と、ユーザーが依頼した作業範囲を区別し、想定外の操作が必要になったときは用途と権限を確認できる運用にします。

社内で共有する場合は、管理者と更新のタイミングも決めます。出力書式が変わったのに古いテンプレートが残っていたり、本文と補足資料で異なるルールを書いていたりすると、結果のばらつきにつながります。業務ルールを変更したら、本文、参照資料、テンプレート、確認に使う入力例をまとめて見直します。

手順を変更した後は、以前使っていた確認用の依頼を再度試すと、別の箇所が悪化していないかを見られます。大規模な仕組みを最初から用意する必要はありません。少数の代表例と、変更理由を残すところから始めれば、個人の工夫をチームで保守できる手順へ育てやすくなります。

製品間の違いとよくある疑問

同じスキルをChatGPT、Claude、Codexでそのまま使えますか？

フォルダーやSKILL.mdという共通の考え方は、手順を持ち運びやすくします。ただし、配置場所、呼び出し方、使えるツール、ファイルへのアクセス、権限の扱いまで完全に同じとは限りません。文章だけの手順を移す場合でも、対象環境で読み込めるかを確認します。特定のコマンドやサービス接続に依存するスキルは、その前提も合わせて確認する必要があります。

作るためにプログラミングは必要ですか？

本文で示した議事録整理の例なら、Markdownによる手順と、冒頭の簡単なYAML設定から始められます。大量のファイルを処理したい、一定の計算を繰り返したいといった理由がある場合には、スクリプトの追加が選択肢になります。コードを付けることを目的にせず、その仕事に必要かどうかで判断してください。

一度作れば、毎回同じ精度で動きますか？

スキルは手順を明確にする助けになりますが、正確性を保証するものではありません。入力の品質、モデルの判断、周辺の指示、利用環境によって結果は変わります。手順が選ばれたことと、事実に忠実な出力が得られたことを分けて確認し、重要な出力は元資料と照合する工程を残します。

処理時間や利用料金は減りますか？

毎回同じ説明を書く手間や、出力を修正する回数が減る可能性はあります。一方、資料の読み込みや追加処理が増えれば、実行時間や消費するトークンが増える場合もあります。比較するなら、AIの応答時間だけでなく、人が依頼を準備し、確認し、修正する時間も含め、実際の作業全体で判断します。

Agent Skillsは2026年に初めて登場したのですか？

今回参照しているAnthropicのAgent Skills解説は2025年10月16日公開で、2025年12月18日の追記でオープン標準化が告知されています。2026年9月11日のOpenAIの運用指針は、その利用や設計に関する資料であり、Agent Skills自体の初登場日を示すものではありません。記事の日付を見るときは、仕組みの紹介と、その後の使い方の更新を分けて捉えると整理できます。

まとめ：小さな手順を一つ作り、選ばれ方から育てる

Agent Skillsは、特定の仕事に使う手順や判断基準、必要な資料をまとめる仕組みです。プロンプトに相当する指示文を含みながら、用途の説明と補助ファイルを一緒に管理できます。MCPなどの外部接続と組み合わせることもできますが、文章の手順だけで成立する用途もあります。

初めて取り組むなら、議事録から決定事項とTODOを整理するような、入力と完成形が明確な作業を選びましょう。SKILL.mdに名前、用途の説明、手順、出力形式を記述し、「使ってほしい依頼」「使わなくてよい依頼」「入力不足の依頼」で確認します。選ばれ方と出力のどちらに問題があるかを見て、必要な部分を直していきます。

完成の目安は、ファイルが長くなったことや補助資料が増えたことではありません。そのスキルをいつ使い、何を入力し、どこまで処理し、どう結果を確認するかを説明できることです。小さな作業でこの一連の流れを確かめることが、再利用しやすい業務手順を作る第一歩になります。

参考資料

仕様や製品に関する説明は、2026年9月29日時点で確認された以下の一次資料に基づいています。製品ごとの配置方法や利用条件は更新されるため、導入時には利用する環境の案内も確認してください。

• Agent Skills公式仕様：SKILL.md、必須項目、フォルダー構成、記述上の推奨事項。
• Agent Skills公式概要：スキルの役割と段階的な情報の読み込み。
• AnthropicによるAgent Skillsの解説：設計の背景、MCPとの関係、オープン標準化に関する追記。
• OpenAIによるスキルとプロンプトの運用指針：説明と適用条件の明確化、必要な資料を読む構成。
• OpenAIのスキル作成ガイド：作成の基本と、明示指定・暗黙選択の考え方。

更新履歴