Agent Skills（SKILL.md）の作り方ガイド｜設計手順と改善実例

Skill（エージェントスキル）2026.08.08

Agent Skills（SKILL.md）の作り方ガイド｜設計手順と改善実例

「毎回同じような指示プロンプトを入力しているのに、AIから返ってくる回答の質が安定しない」「AIが出したドラフトを手直しするのに時間がかかり、二度手間になってしまう」

Claude CodeなどのAIエージェントツールを実務で使い始めた際、こうした課題を感じることは少なくありません。

指示プロンプトを都度チャット欄に貼り付ける運用では、指示の順序や文量によってAIが制約を見落とし、一般的な回答に留まることがあります。

この課題を解決する仕組みが 「Agent Skills（エージェントスキル）」 の作成です。

Agent Skillとは、業務の目的、前提ルール、禁止事項、出力形式をまとめた指示書（SKILL.md）をフォルダ単位で管理し、AIに読み込ませる仕組みです。あらかじめ仕事の要件や制約を明記しておくことで、AIの回答精度や出力形式を実務に合わせて安定させることができます。

活用されている実在Skillの例

実際に公開されているSkillサイトや実務コミュニティでは、以下のようなSkillが活用されています。

【マーケティング・執筆】brand-guidelines / copywriting-polisher
- 通常のプロンプト: 一般的で無難な表現になりやすい。
- Skillを通した出力: 自社のブランドトーン、文体ルール、NG表現を適用し、意図に沿った文面を作成する。
【バックオフィス・進行管理】meeting-insights-analyzer
- 通常のプロンプト: 会議の文字起こしから概要を箇条書きにするにとどまり、担当者や期日が漏れやすい。
- Skillを通した出力: 「決定事項」「保留事項」「Action Items（担当者・期日・タスク）」を指定の表形式で整理する。
【企画・事業開発】buyer-eval / proposal-refiner
- 通常のプロンプト: アイデアの要約や一般的な構成案にとどまりやすい。
- Skillを通した出力: 「想定される反論」「導入リスクと対策」を検証させ、検討の抜け漏れを事前に洗い出す。

Skillを作成する価値は、単なる入力の手間削減にとどまりません。 業務に必要な判断基準や制約条件を明文化し、AIの出力品質を安定させること にあります。

本記事では、手作業で SKILL.md を作成する手順、役割に応じた分割の考え方、および実際の改善例を解説します。

第1章：Agent Skillの基本構造と公式仕様（agentskills.io規格）

Agent Skillの設計全体像

Agent Skillの実体は、特定のプログラム言語ではなく、 「所定のフォルダに、設定と作業手順を記述したテキストファイルを置く」 というシンプルな構成です。

Anthropic社やオープンソースコミュニティを中心に策定されている標準規格（agentskills.io）に沿って作成すれば、Claude Code、OpenAI Codex、Antigravityなどの主要なAIエージェントツールで共通して利用できます。

Skillのディレクトリ構造

1つのSkillは、原則として以下のフォルダ構成で作成します。

my-skill-name/
├── SKILL.md          # 【必須】設定と作業手順が書かれた中核ファイル
├── references/       # 【任意】トンマナや専門用語集などの参照資料
└── scripts/          # 【任意】データ検証や計算を行う補助プログラム

実務における基本形は、 フォルダと SKILL.md の1ファイル で構成されます。

`SKILL.md` の中身（YAMLフロントマターと本文）

SKILL.md のファイル内は、「設定エリア（YAMLフロントマター）」と「指示エリア（Markdown本文）」の2つで構成されます。

---
name: my-skill-name
description: このSkillが何をするものか、どんな時に呼び出すべきかを簡潔に記述します。
---

# ここから下に、AIに対する具体的な作業マニュアル（Markdown本文）を書く

設定エリア（YAMLフロントマター）のルール

name は半角小文字の英数字とハイフン（-）のみ
my_skill（アンダースコア）や MySkill（大文字）は使用できません。proposal-refiner のように小文字とハイフンで記述します。親フォルダの名前と一致させることが公式規格の要件です。
description は「何をするか」と「いつ使うか」を書く
AIはこの説明文を読み取り、ユーザーの指示内容に適したSkillを判定します。
ファイル先頭の --- で囲む
ファイルの1行目から --- で始め、設定項目の末尾も --- で閉じます。

主要AIツール別の配置場所一覧

作成したSkillフォルダは、利用するツールの所定ディレクトリに配置することで認識されます。

Claude Code
- プロジェクト単位: .claude/skills/<skill名>/
- ユーザー共通: ~/.claude/skills/<skill名>/
OpenAI Codex
- プロジェクト単位: .agents/skills/<skill名>/（または .codex/skills/<skill名>/）
- ユーザー共通: ~/.codex/skills/<skill名>/
Antigravity
- プロジェクト単位: .agents/skills/<skill名>/
- ユーザー共通: ~/.gemini/config/skills/<skill名>/
共通標準規格（agentskills.io 推奨パス）
- 共通利用: .agents/skills/<skill名>/

※ ~ はホームディレクトリ（Windowsの場合は C:\Users\<ユーザー名>）を表します。

第2章：手動でゼロから作る `SKILL.md` の書き方（4ステップ）

AIに指示通り作業をさせるためには、最初から複雑な指示を書くのではなく、手作業で50〜100行程度のシンプルな手順書を作成するのが確実です。

以下の4ステップで作成を進めます。

ステップ1：フォルダの作成と命名

作業フォルダを作成します。名前はSkillの役割が分かる半角英数字（ハイフン区切り）にします。

例：企画書の骨子を作成するSkillなら proposal-refiner という名前で新規フォルダを作成します。

ステップ2：YAMLフロントマターの記述

作成したフォルダ内に SKILL.md を作成し、先頭に設定を記述します。

---
name: proposal-refiner
description: 企画書のメモを読み込み、論理構成の確認、想定反論、リスク対策を含めた提案骨子を作成する時に使用します。
---

ステップ3：本文の論理構成（4つの要素）

YAMLの下に、AIへの作業指示を記述します。指示のブレを防ぎ、全工程の品質を安定させるため、以下の4要素を順番に記述します。

# [スキル名]

## 1. 前提ルール（本Skill全体に適用）
- 【事実と推測の分離】入力情報にない数値や事実を推測で創作しないこと。
- 【文体の維持】業務目的に適したトーン（客観的・断定的・平易など）で統一すること。
- 【出力規約】チャット画面に長文を直接出力せず、指定ファイルに書き出すこと。

## 2. 目的とゴール
[誰に向けて、何を作成・解決するのかを簡潔に1〜2行で記述]

## 3. 作業手順
1. 【入力整理】入力されたテキストから「解決すべき課題」や「前提条件」を抽出する。
2. 【思考・加工】抽出した要素をもとに、必要な論点（効果・懸念・対策など）を整理・検証する。
3. 【参照確認】必要に応じて `references/` 内のガイドラインやサンプルを参照し、基準に適合しているか確認する。
4. 【出力整形】「4. 出力フォーマット」の形式に従って成果物を作成し、指定ファイルに保存する。

## 4. 出力フォーマット
# [成果物のタイトル]
## ■ 概要・背景
## ■ 主要な提案・分析結果
## ■ 次のアクション

作業手順は「Input → Process → Output」で設計する

AIに対する作業手順は、実務の業務マニュアルと同様に以下の3段階で整理すると、AIが迷わず指示通りに動作します。

Input（入力整理）
渡されたメモや資料から、作業に必要な要素（課題、数値、前提条件など）を特定・抽出させる。
Process（思考・加工）
単なる要約で終わらせないため、「想定反論の検証」「参照ファイルの確認」など、プロとしての判断基準を指定する。
Output（出力整形）
どの形式・ファイルに成果物をまとめるかを指定する。

Skillの「前提ルール」に書くべき内容

Skillの前提ルールには、 「どの作業ステップでも一貫して守らせたい、業務固有の品質基準」 を定義します。

事実と推測の分離
入力データにない情報を推測で補完することを防ぐ基準。
文体・トーンの統一
曖昧な推量表現を排除し、実務に適した客観的なトーンを維持する。
成果物の出力規約
チャット画面への直接出力を避け、指定ファイルへの書き出しと要約提示に統一する。

これらを冒頭に明記することで、各作業ステップで重複して注意書きを書く必要がなくなり、全体の整合性を保ちやすくなります。

ステップ4：所定ディレクトリへの配置とテスト

作成した proposal-refiner フォルダを、ツールのスキルディレクトリ（例: Claude Codeなら .claude/skills/）に配置します。

チャット画面で「新しい事業のアイデアメモを書いたので、企画骨子をまとめて」と入力し、Skillが読み込まれて指定フォーマットで出力されるか確認します。

第3章：失敗しない「粒度設計」：1つのSkillに機能を詰め込まない考え方

1つのSkillに機能を詰め込まない粒度設計

Skill作成時によく見られる失敗が、1つのSkillに多くの役割を持たせようとすることです。

「1つのSkillで、リサーチ、構成案作成、本文執筆、校正まで行いたい」「ユーザーの指示に応じてAモード、Bモード、Cモードを分岐させたい」

このように条件分岐を多く詰め込むと、指示の解釈が複雑になり、出力精度が低下しやすくなります。

機能を詰め込んだ場合のリスク

ルールの混同
複数の処理パターンが1つのファイルにあると、別のモード用の制約が誤って適用されることがあります。
作業記憶（コンテキスト）の消費
実行しない処理に関する長文指示も毎回読み込まれるため、モデルの処理効率が低下します。
メンテナンス性の低下
手順が複雑化すると、どの部分を修正すれば期待通りの挙動になるのかが把握しにくくなります。

分割の基準：「1 Skill = 1 目的」

Skillの設計では、 「入力が定まり、出力される成果物のゴールが1つに決まる単位」 で分割することが推奨されます。

【例】記事制作プロセスの分割

避けるべき例:
- article-master/: リサーチ・構成・執筆・校正をすべて1つのSkillにまとめる。
推奨される例:
- article-outliner/: キーワードと前提情報を入力し、「見出し構成案」を出力するSkill。
- article-writer/: 決定した見出し構成を入力し、「本文ドラフト」を出力するSkill。
- article-proofreader/: 完成原稿を入力し、「誤字脱字・表記ゆれのチェック結果」を出力するSkill。

工程ごとに分割することで、各ステップで必要な指示に集中させることができます。

第4章：呼び出し設計と意図しない自動起動（Over-triggering）の防止

Skillを配置した後、それを「どのように呼び出すか」の設計も実用上のポイントです。

自動起動の仕組み

Claude Codeなどのエージェントツールでは、起動時に各Skillの SKILL.md 先頭にある description（説明文） を読み込みます。

ユーザーの指示内容が description の条件に合致すると判断された場合、該当するSkillが自動的に読み込まれて実行されます。

意図しない自動起動への対処

description の記述が曖昧だと、一般的な会話や簡単な質問に対してもSkillが起動してしまうことがあります。

業務用のSkillや、出力形式が厳密に決まっているSkillについては、 手動呼び出し（スラッシュコマンド）を基本とする設定 が有効です。

YAMLフロントマターに disable-model-invocation: true を指定します。

---
name: proposal-refiner
description: 企画書の骨子メモを読み込み、提案骨子を生成します。
disable-model-invocation: true
---

この設定を行うと、モデルによる自律的な自動起動が行われなくなり、ユーザーが /proposal-refiner と明示的に入力した時のみ実行されます。

日常会話から自動起動させたい場合は、description に除外条件を具体的に記述します。

例: description: 売上データ（CSV）の集計・分析時に使用します。一般的な質問や雑談には使用しないでください。

第5章：参照ファイルの分離（Progressive Disclosure）

業務で必要な用語集やマニュアル、サンプル文面など、参照情報が多い場合は、SKILL.md にすべて記載せず別ファイルに分離します。

`SKILL.md` を適切な長さに保つ

SKILL.md 本文には作業手順の骨組みを記述し、詳細な参照資料は references/ フォルダに配置します。

my-writing-skill/
├── SKILL.md                 # 50〜100行程度の手順書
└── references/
    ├── tone-guideline.md    # 文体ルール・表記ガイドライン
    └── sample-articles.md   # 記事の作成サンプル

本文からの参照指定

SKILL.md 本文中から、必要なタイミングでファイルを参照するように指定します。

## 作業手順
1. 入力内容を確認する。
2. 執筆前に `references/tone-guideline.md` を確認し、表記ルールに準拠すること。
3. 見出しの構成は `references/sample-articles.md` の形式に準拠すること。

※参照ファイルは references/ フォルダの直下にフラットに配置すると、AIがファイルパスを正確に特定しやすくなります。

第6章：実データでの検証と「過去の失敗事例と対策」の記録

Skillを作成した後は、実際のデータを用いたテストと運用の振り返りを通じて指示内容を調整します。

代表的な実データ1件で検証する

作成したSkillのテストは、過去の標準的な実データ1件を用いて実行します。

出力結果を確認し、「不足している論点はないか」「指定したルールが守られているか」を確認します。

「過去の失敗事例と対策」でSkillを改善する

指示通りに動作しなかった箇所がある場合、抽象的な指示を追加するのではなく、SKILL.md の末尾に ## 過去の失敗事例と対策 として具体的な事実と対策を追記します。

## 過去の失敗事例と対策
- 【事例】改善案の出力時にツール名（Slack等）の記載のみで終わる場合がある。
  → 【対策】ツール名だけでなく、具体的な運用担当者と運用ルールを併記すること。
- 【事例】入力メモに日付の記載がない場合、架空の日付が出力されることがある。
  → 【対策】日付が明記されていない項目は「[未定]」と記載すること。

発生した事象と対策を具体的に書き足すことで、運用の蓄積に応じたSkillの改善が行えます。

第7章：AI生成ツール（Skill Creator等）利用時の注意点

対話形式でSkillを生成するツール（Anthropic公式の skill-creator 等）を利用する場合、出力された SKILL.md をそのまま使わず、内容を確認して整理することが重要です。

自動生成された SKILL.md には、不要な例外処理や複雑な条件分岐が含まれることがあります。そのまま利用すると指示が肥大化し、意図した挙動にならない原因となります。

生成ツールを利用する際は、以下の点を確認して手動で調整します。

不要な条件分岐を削除する。
手順を50〜100行程度に整理する。
業務固有の全体ルールが冒頭に配置されているか確認する。

第8章：作成と改善の実例（商談メモの社内共有サマリー化）

手作業でSkillを作成し、出力を確認しながら実務向けに改善していく具体的な流れを示します。題材として、日々の商談や打ち合わせメモから社内共有用のサマリーを作成するSkill（meeting-recap-writer）を取り上げます。

ステップ1：初版Skillの作成

まずは最小限の手順のみを記述した初版 SKILL.md を作成します。

---
name: meeting-recap-writer
description: 商談や打ち合わせのメモを読み込み、社内共有用の要約を作成します。
---

# 商談サマリー作成Skill

## 手順
1. 入力された商談メモを読み込む。
2. 重要なポイントを箇条書きで要約する。

ステップ2：テスト実行と課題の確認

以下の商談メモを入力して初版Skillを実行します。

入力メモ: 「A社との初回商談（オンライン）。先方は業務効率化ツールに関心あり。現状はExcel管理で属人化と入力ミスが課題。予算はまだ確定していないが来期の検討候補に入れたいとのこと。次回は2週間後に詳細見積もりとデモを見せる。先方参加者は山田部長とシステム担当の佐藤さん。こちらからは次回、営業の田中とエンジニアの鈴木が同席予定。」

初版Skillの出力例

近年のAIモデルは標準でも文章力が高いため、以下のように自然で整った箇条書きを出力します。

# 商談要約：A社
- **顧客**: A社（参加者：山田部長、システム担当 佐藤様）
- **課題**: Excel管理による業務の属人化および入力ミスの発生
- **ニーズ**: 業務効率化ツールの導入に関心あり
- **予算**: 未確定（来期の検討候補）
- **次回アクション**: 2週間後に詳細見積もりとデモを実施（自社：田中、鈴木）

出力から見つかった「実務現場での4つの惜しい点」

一見すると綺麗にまとまっていますが、チームの実務でそのまま共有・運用するには、以下のような 「手作業での手直し」 が発生します。

独自フォーマットの不一致
要約としては成立していますが、たとえば「チーム内で『案件概要』『現状の課題とニーズ』『BANT条件』『ネクストアクション』という指定フォーマットで共有する運用ルールがある」と仮定した場合、AIの汎用的な出力では項目順や粒度が合わず、毎回手作業でコピペや並び替えをする手間が発生します。
アクションの責任者・期日の曖昧さ
「2週間後に詳細見積もりとデモ」とあるが、「自社側がいつまでに資料を用意するのか」「先方からの宿題があるのか」が分かれておらず、タスクの管理が漏れやすい。
未確定情報の混在
本人がメモに書き忘れた社内情報と、次回顧客に確認すべき事項が区別されておらず、共有を受けた上司が次に何を判断すべきかが伝わりにくい。
ファイル保存・命名ルールの欠如
チャット画面に全文を出力したり、固定のファイル名で保存する運用では、次回の商談サマリーで上書きされて過去の記録が消えてしまいます。実務では「いつ・誰との商談か」がファイル名から一目でわかる命名ルール（例: YYYYMMDD_<顧客名>_商談サマリー.md）が不可欠です。

ステップ3：課題に対応する指示の追加

見つかった4つの課題に対して、SKILL.md の「作業手順」と「出力フォーマット」に具体的な指示を追記して品質を固定します。

課題1（フォーマット不一致）への対策
「4. 出力フォーマット」を新設し、社内指定の見出し構成（顧客基本情報・現状の課題とニーズ・BANT検討状況・ネクストアクション）を固定する。
課題2（アクションの曖昧さ）への対策
作業手順（ステップ3）に「自社タスク（担当・期日）」と「先方タスク（次回ヒアリング事項）」を分離する指示を追加する。
課題3（未確定情報の扱い）への対策
作業手順（ステップ2）に「メモ未記載の社内項目は [未記入: ○○]」「顧客への確認事項は [要ヒアリング: ○○]」と分類する指示を追加する。
課題4（ファイル管理の欠如）への対策
作業手順（ステップ4）に「YYYYMMDD_<顧客名>_商談サマリー.md でのファイル保存」と「チャットへの3行要約の出力」を追加する。

改善後の `SKILL.md`

---
name: meeting-recap-writer
description: 商談・打ち合わせメモから、社内共有用のサマリーファイルとチャット用3行要約を作成します。
disable-model-invocation: true
---

# 商談サマリー作成Skill

## 1. 前提ルール（本Skill全体に適用）
- 【事実と推測の分離】入力メモにない事実を勝手に推測・創作しないこと。
- 【客観的な文体の維持】主観的な推測を排除し、顧客の発言（事実）と提案者の所感を明確に区別すること。

## 2. 目的
商談や打ち合わせのメモを読み込み、チームや上司への共有に必要な項目（課題・BANT・次回アクション）を漏れなく整理したサマリーを作成する。

## 3. 作業手順
1. 【入力整理】入力メモから「顧客名」「参加者」「現状の課題」「導入意向」「次回予定」を抽出する。
2. 【情報の分類とプレースホルダー設定】
   - メモに記載のない社内基本情報（商談日や自社担当者など）: `[未記入: ○○]` と記載する（本人がサマリー確認時に追記するため）。
   - 顧客側に確認が必要な未確定情報（予算規模や決裁者など）: `[要ヒアリング: ○○]` と記載する（次回商談の確認事項とするため）。
3. 【アクションの分離】次回までのタスクを「【自社タスク】（担当・期日）」と「【先方タスク（次回ヒアリング事項）】」に明確に分離する。
4. 【ファイル保存とチャット通知】
   - 「4. 出力フォーマット」に沿ってサマリーを作成し、`YYYYMMDD_<顧客名>_商談サマリー.md`（例: `20260808_A社_商談サマリー.md`）として保存する（商談日が不明な場合は当日日付を使用）。
   - チャット画面には全文を出力せず、作成したファイルへのリンクと「社内共有用3行要約」のみを出力する。

## 4. 出力フォーマット（YYYYMMDD_<顧客名>_商談サマリー.md）
# 【商談サマリー】[顧客名] 様（[商談日]）

### 1. 案件概要
- **顧客名**: 
- **先方参加者**: 
- **自社参加者**: 
- **商談種別**: （初回商談／デモ実施／提案／クロージング 等）

### 2. 現状の課題と顧客ニーズ
- **現状の運用**: 
- **抱えている課題**: 
- **期待する導入効果**: 

### 3. BANT検討状況
- **Budget（予算）**: 
- **Authority（決裁者）**: 
- **Needs（必要性）**: 
- **Timeframe（導入時期）**: 

### 4. ネクストアクション
- **【自社タスク】**:
  - [担当者名] [対応内容]（期日: ○月○日まで）
- **【先方タスク（次回ヒアリング事項）】**:
  - [確認・ヒアリング内容]

## 5. 過去の失敗事例と対策
- 【事例】自社の次回参加予定者がサマリーから漏れ、当日の社内連携に混乱が生じた。
  → 【対策】次回同席予定の自社メンバー（営業・技術等）を自社タスク欄に必ず明記すること。
- 【事例】先方の役職や担当領域が抜けており、決裁ルートの把握が遅れた。
  → 【対策】参加者名には可能な限り担当役職や役割（システム担当等）を付記すること。

ステップ4：改善後の出力確認

改善したSkillで同一の商談メモを実行した結果です。

改善後の出力例（チャット画面への表示）

20260808_A社_商談サマリー.md に商談サマリーを出力しました。

【社内共有用 3行要約】
1. 案件概要: A社様との初回商談（オンライン）。Excel運用の属人化・入力ミス解消に向けツール導入に関心あり。
2. 検討状況: 予算・時期は来期検討候補（予算額・決裁者は次回ヒアリング要）。
3. 次回予定: 2週間後にデモ・詳細見積もり提示（自社同席：田中、鈴木 / 先方：山田部長、佐藤様）。

生成されたファイル（`20260808_A社_商談サマリー.md`）の内容

# 【商談サマリー】A社 様（2026/08/08）

### 1. 案件概要
- **顧客名**: A社
- **先方参加者**: 山田部長、佐藤さん（システム担当）
- **自社参加者**: [未記入: 初回担当者]
- **商談種別**: 初回商談（オンライン）

### 2. 現状の課題と顧客ニーズ
- **現状の運用**: Excelで管理
- **抱えている課題**: 属人化、入力ミス
- **期待する導入効果**: 業務効率化ツールに関心あり（具体的な期待効果は [要ヒアリング: 導入により期待する効果]）

### 3. BANT検討状況
- **Budget（予算）**: 未確定。来期の検討候補 ※[要ヒアリング: 具体的な予算枠]
- **Authority（決裁者）**: [要ヒアリング: 決裁者・決裁フロー]
- **Needs（必要性）**: Excel管理における属人化・入力ミスの解消ニーズあり
- **Timeframe（導入時期）**: 来期の検討候補 ※[要ヒアリング: 具体的な導入希望時期]

### 4. ネクストアクション
- **【自社タスク】**:
  - 田中（営業）: 次回商談に同席予定（期日: 2週間後の次回商談）
  - 鈴木（エンジニア）: 次回商談に同席予定（期日: 2週間後の次回商談）
  - [未記入: 担当者]: 詳細見積もりを準備（期日: 2週間後の次回商談まで）
  - [未記入: 担当者]: デモを準備（期日: 2週間後の次回商談まで）
- **【先方タスク（次回ヒアリング事項）】**:
  - 予算に関する確認（[要ヒアリング]）
  - 導入時期に関する確認（[要ヒアリング]）
  - 決裁者・決裁フローに関する確認（[要ヒアリング]）

改善は一度で終わらない：実務で運用しながら修正し続ける

上記の改善により、初版に比べて報告の抜け漏れがなくなり、そのまま社内共有できる水準に達しました。

しかし、実際の業務で使い続けると、以下のような新たな現場ニーズや課題が日常的に見つかります。

「他社ツールの利用状況やリプレイス検討の有無を記録する項目をフォーマットに追加したい」
「顧客が最も懸念しているリスク事項（セキュリティ要件や他ツール連携など）を明記する欄を新設したい」
「Slack等のチャット共有時に、担当上司へのメンション（@mention）を自動で付けたい」

Skillは 「一度作れば完成する静的なプログラム」ではなく、「日々の実務に合わせて継続的に育てていく業務マニュアル」 です。

実務で手直しや不便さを感じるたびに、

## 過去の失敗事例と対策 に起きたミスと再発防止策を追記する
出力フォーマットに必要な見出しや項目を追加・調整する
references/ に自社の営業マニュアルや評価基準ガイドラインを追加する

といった小さな見直しを重ねていくことで、チーム全体の作業効率とアウトプット品質を継続的に高めていくことができます。

まとめ：Agent Skillによる業務指示の標準化

Agent Skillを活用する本質は、プロンプトの都度入力による属人化や出力のバラつきを解消し、 「業務の判断基準や出力形式をドキュメントとして標準化すること」 にあります。

本記事で解説した設計と運用の要点は以下の通りです。

小さく始める
まずは50〜100行程度で、前提ルール、目的、作業手順（Input → Process → Output）、出力フォーマットを記述する。
業務固有の全体ルールを定義する
「事実と推測の分離」「文体の統一」「ファイル出力規約」を冒頭に配置し、全工程の品質基準を担保する。
1 Skill = 1 目的で分割する
入力と出力のゴールを1つに絞り、指示の肥大化やルールの混同を防ぐ。
呼び出しを制御する
意図しない自動起動を防ぐため、業務用のSkillには disable-model-invocation: true を設定し、手動呼び出しを基本とする。
実運用を通じてSkillを更新する
テストや実務での出力結果をもとに、「過去の失敗事例と対策」や参照資料（references/）を継続的に追記・修正する。

業務の手順と制約を1つのフォルダに整理して運用することで、AIエージェントの作業品質を安定させ、実務における再現性を高めることができます。

Agent Skills（SKILL.md）の作り方ガイド｜設計手順と改善実例