Agent Skillsの作り方｜指示と手直しを減らす5ステップ

AIへ毎回伝えている業務手順や判断基準を、再利用できる資産にする仕組み。それが「Agent Skills」です。

本記事では、Agent Skillsの基本概念から作成の5ステップまでを、議事録作成の具体例を交えて解説します。自社で取り組むべき業務の選び方、品質の検証方法、そして社内へ定着させるプロセスまで網羅してご紹介します。

---

「決定事項を冒頭にまとめて」「担当者と対応期日を明記して」。昨日も伝えたはずの指示を、今日もAIに対して繰り返していないでしょうか。

生成AIの出力スピードは非常に高速です。しかし、指示出しや手直しに時間を取られていては、本質的な業務効率化にはつながりません。

この課題を解決する鍵が「Agent Skills」にあります。適切に設計できれば、業務手順を毎回説明する手間を省き、成果物の品質基準を社内で均一化できます。

ただし、従来のプロンプト（指示文）を単に保存するだけでは不十分です。重要なのは、「どのような業務を、どこまで達成できたら完成とするか（完成基準）」を事前に定義することです。

---

Agent Skillsの基本概念

新しいメンバーへ業務を引き継ぐ際、単にマニュアルを渡すだけでは十分な引き継ぎとは言えません。

過去の良質なアウトプット例を見せる、指定のフォーマットを共有する、「この数値の整合性は必ず確認してほしい」と留意点を添えるなど、相手が判断に迷いそうなポイントまで丁寧に伝えるはずです。

Agent Skillsの思想もこれと同じです。いわば、AI向けの「業務引き継ぎパッケージ」と捉えると理解しやすくなります。

技術的な定義としては、自律型AI（AIエージェント）に専門知識や業務フローを渡すための共通仕様規格を指します。AIエージェントとは、与えられた指示に対して情報の検索やツールの操作を自律的に行いながらタスクを遂行するAIシステムのことです。

Agent Skillsの中核を担うのは、SKILL.mdというMarkdown形式の指示書ファイルです。このファイルと同じディレクトリ内に、参照用の社内資料、テンプレート、データ処理用スクリプトなどをひとまとめにして管理できます。

対応するAIは、タスクに応じて必要なSkillを自動的に読み込んで処理を実行します。

プロンプト・Skill・外部連携の違い

「普段チャット欄に入力しているプロンプトと何が違うのか」という疑問に対しては、それぞれの役割を次のように整理できます。

仕組み	主な役割	議事録作成における具体例
プロンプト（指示文）	今回実行してほしい作業内容を伝える	「この会議の議事録を作成してください」
Agent Skills	繰り返し適用する手順・判断基準を定義する	決定事項と検討事項の分類基準、必須項目、検証ルール
ツール・コネクター（MCP等）	外部ファイルや各種SaaSツールを操作する	会議録音データの取得、社内ストレージへの議事録保存

Skillの内部にもプロンプトは含まれますが、「周辺資料や検証ロジックを包括し、再利用可能なパッケージとして管理されている点」が大きく異なります。

なお、Skill内に「議事録を社内ストレージに保存する」と記述しても、AI側にアクセス権限や通信手段がなければ実行できません。これは「手順書に『倉庫から備品を取り出す』と書いてあっても、倉庫の鍵がなければ入れない」状態と同じです

外部サービスとの安全な連携には、MCP（Model Context Protocol）などの連携基盤と適切な権限設定が別途必要になります。

※本記事の作成例は、ファイルの読み書きやコマンド実行が可能な「Claude Code」などのAgent Skills対応環境を前提としています。一般的なWebチャット画面にテキストを貼り付けるだけではSkillとして保持されない点にご留意ください。

---

議事録作成における完成イメージ

まずは、目指すべきアウトプットの具体像を確認します。ここでは「営業定例ミーティングの文字起こしテキストから、議事録のドラフトを作成する」ケースを取り上げます。

以下は、検証用のサンプルデータと目標とする出力形式です。

入力データ（文字起こしテキストの例）

00:10 田中：
A社への提案は、運用支援プランを軸に進めましょう。
鈴木さん、10月8日までに提案書の初稿作成をお願いできますか。
00:22 鈴木：
承知いたしました。対応します。
00:40 田中：
価格設定は月額20万円をベースに考えていますが、原価試算を確認した上で最終決定します。
00:52 佐藤：
原価の確認は私が担当します。確認完了の期日は追って調整させてください。

目指すべき議事録の出力例

区分	整理された内容	原文根拠
決定事項	A社向け提案は「運用支援プラン」を軸に進行する	00:10
未決・保留事項	提供価格：月額20万円案をベースに、原価確認を経て確定する	00:40
ネクストアクション	提案書初稿の作成（担当：鈴木 / 期日：10月8日）	00:10, 00:22
ネクストアクション	原価の試算・確認（担当：佐藤 / 期日：要確認）	00:40, 00:52

ビジネス実務において重要なのは、単に整った文章を作ることではありません。

• 「検討段階の価格」を、誤って「決定事項」として記載していないか
• 「未定の期日」を、AIが勝手な推測で補完していないか
• 「誰が・いつまでに・何をすべきか」が明確で、次の行動に直結するか

この精度の差が、実務でそのまま通用するか、人が手直しに追われるかの分岐点になります。

良質なAgent Skillsを構築するためには、こうした実務上の判断基準を言語化して組み込んでいく必要があります。

---

Agent Skillsを作成する5つのステップ

Skillの構築プロセスは、以下の5段階で進めます。

1. 対象業務の選定
2. 完成基準（Doneの定義）の策定
3. AIとの対話による条件の言語化
4. 指示書（SKILL.md）への構造化
5. テスト実行とプロンプトの改善

最初から指示書ファイルを記述するのではなく、まずは対象とする業務のスコープと基準を明確に定義することが成功のポイントです。

ステップ1：対象業務の選定

選定の第一候補となるのは、「業務手順を毎回AIに説明している作業」です。議事録作成、週次レポートの集計、提案骨子の作成、ブログ記事の構成案作成などが該当します。

候補が複数ある場合は、以下の3条件を満たす業務から優先的に着手してください。

• 実行頻度が高い業務
• インプットとなる情報や参照データが社内に揃っている業務
• 出力された成果物の良し悪しを、自社メンバー自身で即座に判定できる業務

営業会議の議事録であれば、文字起こしデータと過去の議事録フォーマットが存在し、会議出席者が内容の正確性を検証できるため、最初の検証対象として非常に適しています。

ここで留意すべきは「業務のスコープ（切り出し範囲）」です。

「アジェンダ作成」「日程調整」「当日の記録」「関係者への送信用メール作成」までを一度に自動化しようとすると、必要な情報やツール連携が複雑化し、エラー発生時の原因特定が難しくなります。

まずは「会議の文字起こしから、決定事項とタスクが整理されたドラフトを作成する」というように、入力から成果物までが一気通貫で完結する独立した単位で切り出してください。

ステップ2：完成基準（Doneの定義）の策定

対象業務が決まったら、以下の6つの要素を定義します。

定義項目	議事録作成における設定例
目的	会議の欠席者が、決定事項と次のタスクを正確に把握できるようにする
スコープ	文字起こしテキストの構造化および下書きの作成（外部共有・送信は含まない）
入力情報	会議名、開催日時、参加者、文字起こしテキスト
出力項目	会議概要、決定事項、未決・保留事項、タスク一覧（内容/担当/期日）、要確認事項
制約条件	原文にない推測情報の追加は厳禁。不明な期日や担当者は「要確認」と明記する
完成条件	決定事項と検討事項が明確に分離され、全タスクに担当・期日があり、原文根拠と照合できること

単に「議事録を作ること」をゴールに設定すると、AIはどのレベルまで厳密にチェックすべきか判断できません。「読み手が次のアクションへ迷わず移れる状態」を逆算することで、必要な制約や必須項目が明確になります。

このフェーズでは、過去に社内で高く評価された「理想の成果物サンプル」が役立ちます。「過去のこの議事録のようにまとめて」と指示するだけでなく、なぜそれが良質な成果物なのかを言語化します。

「冒頭を見れば結論が分かる」「タスクが1人1アクションで分解されている」「未確定の議論が混ざっていない」といった具体的な評価基準を用意することで、AIへの指示精度が高まるだけでなく、人間の検収基準も明確になります。

ステップ3：AIとの対話による条件の言語化

普段無意識に行っている業務判断を、最初からすべて自力で網羅・言語化するのは容易ではありません。

その場合、AIを壁打ち相手（インタビュアー）として活用するのが効果的です。AIからの多角的な質問に回答していくアプローチをとることで、暗黙知を効率的に引き出せます。

以下のプロンプトをチャットツールに入力し、条件の棚卸しを進めてみてください。

営業会議の文字起こしデータから、議事録のドラフトを作成するAgent Skillを設計したいと考えています。
目的は「会議の欠席者が、決定事項と次に必要なアクションを正しく把握できる状態を作ること」です。
なお、メール送信やチャットへの共有作業はスコープ外とします。
まだSKILL.mdファイルは作成しないでください。
目的、スコープ、入力、出力、制約条件、完成条件を過不足なく定義するために、
私に対して1問ずつ順番に質問を投げかけてください。
私の回答が抽象的だった場合は、実務の具体例を交えながら追加質問をお願いします。
十分な情報が揃った段階で、決定した要件と未決定の論点を整理して出力してください。

「担当者が決まっていないタスクはどう扱いますか？」「会議中に議論が二転三転した場合、最終結論のみを残しますか、それとも経緯も記録しますか？」といったAIからの問いかけに答えていく過程で、従来の業務マニュアルに記載されていなかった細かな判断基準が可視化されます。

ステップ4：指示書（SKILL.md）への構造化

要件定義が完了したら、AIを活用してSKILL.mdの記述に落とし込みます。

Agent Skillsの記述においては、冗長な背景説明を避け、AIが実行すべきアクションを動詞ベースで簡潔に記述することが推奨されます。「適切にまとめる」といった曖昧な指示ではなく、「抽出する」「分類する」「原文と突き合わせて照合する」のようにステップを分解します。

以下は、そのまま実務向けにカスタマイズして活用できるSKILL.mdの構成テンプレートです。

---
name: sales-meeting-minutes
description: 営業会議の文字起こしテキストから、決定事項・未決事項・タスクを整理した議事録ドラフトを作成する。営業定例の議事録作成時に呼び出す。日程調整や外部共有は対象外。
---
# 目的
会議の欠席者が、決定事項と次に取るべきアクションを即座に把握できる議事録ドラフトを作成する。
# 入力情報
- 必須：会議名、開催日、参加者、文字起こしテキスト（または会議メモ）
- ※原文テキストが存在しない場合は、ユーザーへ提出を求める。
- ※会議名・開催日・参加者が不明な場合は「要確認」と記載する。
# 処理手順
1. 原文テキストを解析し、「決定事項」「未決の議論」「発生した作業（タスク）」を抽出する。
2. 提案・アイデア段階の発言と、参加者間で合意された決定事項を明確に区別する。
3. タスクごとに「具体的なアクション」「担当者」「完了期日」を整理する。
4. 原文中で確定していない担当者や期日は、推測せず「要確認」と明記する。
5. 抽出した全項目について原文の発言箇所と照合し、根拠のない情報や推測を排除する。
# 出力フォーマット
以下の順序でMarkdown形式にて出力する。
1. 会議基本情報（会議名、日時、参加者）および会議の全体概要
2. 決定事項（原文の発言時刻または該当箇所の引用を付記）
3. 未決・保留事項（原文の発言時刻または該当箇所の引用を付記）
4. タスク一覧（テーブル形式：タスク内容 / 担当者 / 期日 / 原文根拠）
5. 要確認事項
※該当する情報が存在しないセクションは「特になし」と明記する。
# 完成条件（品質チェックリスト）
- 検討段階のアイデアが「決定事項」に混入していないこと。
- すべてのタスクにおいて、担当者と期日が明確に分離されていること。
- 不明瞭な情報に対して、AI独自の推測による補完が行われていないこと。
- 主要な記述のすべてに、原文テキストとの対応関係（エビデンス）が存在すること。
- 生成完了後はドラフトの提示のみを行い、外部ツールへの送信や共有は行わないこと。

ファイルの先頭にあるnameにはSkillの識別名を、descriptionには「どのような業務の、どのタイミングで使用するか」を記述します。AIがタスクに応じて自律的にSkillを選択する際、このdescriptionの記述精度がトリガーの正確性を左右します。

作成したファイルは、Skill名と同じ名称のディレクトリを作成して格納します。Claude Codeを利用する場合、プロジェクトルート直下に以下のパスで配置します。

.claude/skills/sales-meeting-minutes/SKILL.md

Claude Code上で該当プロジェクトを開き、/sales-meeting-minutesコマンドを実行して会議メモを渡すことで、定義通りの議事録ドラフトが生成されるかを確認できます。

ステップ5：テスト実行とプロンプトの改善

Skillの初回検証には、過去に実施された社内会議の文字起こしデータなど、「人間が正解のアウトプットを把握できているデータ」を使用します。なお、入力データは社内の情報セキュリティ規程で利用が許可されているものに限定してください。

検証時には、先ほどの例で言えば「検討中の月額20万円が決定事項に紛れ込んでいないか」「別のタスクの期日が混同されていないか」といったクリティカルなポイントを重点的に確認します。

期待と異なる出力があった場合、単に出力結果を手作業で修正するのではなく、「なぜその誤りが発生したのか」を分析し、SKILL.mdの手順や制約条件へルールとしてフィードバックします。

例えば「あるタスクの期日が、別のタスクの期日で上書きされていた」という事象であれば、「各タスクの期日は必ずその発言箇所と直接紐づく記述から取得し、前後の別タスクの期日を代用してはならない」といった具体的な禁止事項をプロンプトへ追記します。

修正を行ったら、同じ会議データだけでなく、別の会議データでも再度テストを実施します。特定のデータセットに過剰適合（オーバーフィッティング）していないか、以前は正しく動作していた出力ロジックが崩れていないかを確認するためです。

---

成果物の品質を担保する2つの設計思想

Skillの改善を重ねる過程で、「どこまで厳密にルール化すべきか」「関連資料をどこまで読み込ませるべきか」というトレードオフに直面します。

その際は、以下の2つの設計思想を基準に判断します。

1. 業務に応じた「厳密さ」と「自由度」の使い分け

エラー発生時のリスクが大きい工程（コンプライアンス違反や重大な誤認につながる箇所）は、手順や判定フローを厳密に規定します。例えば、議事録の外部共有までを視野に入れる場合、「送信前の宛先確認ステップ」や「数値の原文突合ルール」は厳格に固定すべきです。

一方で、企画の切り口出しやドラフトの言い回しといった創造性が求められる工程まで細かく制約を設けると、出力の多様性が失われ、金太郎飴のような無難なアウトプットに偏ってしまいます。

業務の性質に応じて、「数値や固有名詞、事実関係のチェックは厳密に規定し、表現や構成の展開には適度な自由度を持たせる」というように、メリハリをつけた設計が重要です。

2. ファイルの役割分担（構造化）

初期段階では単一のSKILL.mdのみで運用しても問題ありません。

しかし、参照すべき業務マニュアルや例外規定が増加してきた場合は、ファイルをディレクトリごとに分割管理することで、AIの参照精度と処理速度を維持できます。

skills/sales-meeting-minutes/
├── SKILL.md          # 実行手順、完成条件、全体のオーケストレーション
├── references/       # 詳細な判断基準、業界用語集、過去の良質な議事録サンプル
├── assets/           # 指定フォーマット、Markdownテンプレート
└── scripts/          # 必須項目の抜け漏れを自動判定するバリデーション用コード

ファイルを分割した際は、SKILL.md側から「表記ゆれを確認する際は、references/terminology.mdを参照すること」のように、参照すべきタイミングと対象ファイルを明示的に指定します。

また、「所定のセクションがすべて出力されているか」といった定型的なフォーマットチェックは、LLMに推論させるよりも、Python等の軽量なスクリプトに機械検証させた方が、コスト・速度・確実性のすべての面で優れています。

---

導入効果の検証アプローチ

Skillを業務へ導入した後は、それが実際に業務効率化と品質向上に寄与しているかを定量・定性の両面から検証します。

最も確実な検証方法は、同一のインプットを用いて「一般的なプロンプトのみで指示した場合（Skillなし）」と「Agent Skillsを適用した場合（Skillあり）」の出力を直接比較することです。

評価指標	測定する項目
品質・精度	決定事項と検討事項の誤認件数、ハルシネーション（事実無根の補完）の発生件数
網羅性	タスク、担当者、対応期日などの必須項目の記載漏れ件数
作業工数	人間側が指示出し・確認・手直しに要した合計時間
実行効率	出力完了までのレスポンスタイム、API利用コスト

定例会議のデータだけでなく、「タスクの担当者が曖昧な会議」「議論の結論が二転三転した会議」など、難易度の高いエッジケースでもテストを実施してください。

もし「Skillを導入しても人間の修正時間が変わらない」「Skillがなくても一般的な指示だけで十分な品質が出せる」という業務であれば、無理にSkill化を維持する必要はありません。技術の導入自体を自己目的にせず、トータルの工数削減につながる業務へリソースを集中させることが肝要です。

---

社内定着・組織展開を成功させるポイント

作成者本人は便利に使えていても、チームの他メンバーへ展開した途端に利用が進まなくなるケースは少なくありません。

この障壁の多くは、「作成者だけが無意識に持っている前提条件」が共有されていないことに起因します。ツールを渡すだけでなく、「どんな元データを用意し、どのタイミングで実行し、生成後の成果物をどこに着目してチェックすべきか」という運用手順をワンセットで提供する必要があります。

チームへの試験導入を進める際は、事前に以下の運用要件を定義しておくことで、現場と管理職の間でスムーズに合意形成を図れます。

導入項目	定義すべき内容
対象業務と導入目標	営業議事録のドラフト作成を標準化し、作成・修正工数を50%削減する
パイロット担当者	推進担当者（作成・調整）と、業務レビュー担当者（品質確認）を指定する
利用データと環境	社内セキュリティ規程に準拠した文字起こしツール、および動作確認済みの実行環境
検証期間とスコープ	2〜3週間の試行期間を設け、通常会議および例外的な会議の両方で検証する
継続運用の評価基準	修正工数の削減効果、成果物の品質維持、ツール運用コストのバランスで判断する
保守メンテナンス責任	業務プロセスの変更やAIモデルのアップデートに伴うSkill更新の担当者を決める

推進担当者による検証が完了した後は、他メンバーに実際に操作してもらい、「どの手順で手が止まったか」「どのような口頭補足が必要だったか」を記録します。その補足内容をSKILL.mdや付随マニュアルへ還元していくことが、最も確実な定着への近道です。

株式会社ミチガエルが提供する伴走支援においても、「既存業務を他者に引き継げるレベルまで構造化・可視化し、AIとの対話を通じて暗黙知を補完しながらSkillへ落とし込む」という実践的なアプローチを一貫して採用しています。

業務の棚卸しを通じて身近なタスクから小さく着手し、実際の検証結果を持ち寄って継続的にブラッシュアップしていくプロセスこそが、形骸化させずに社内へAIを定着させる最適解です。

---

まず取り組むべき最初のアクション

社内でAgent Skillsの活用をスタートするなら、まずは「普段から何度も同じ説明を繰り返している業務」を1つだけ選定し、過去に作成された最も完成度の高い成果物を手元に用意してみてください。

そして、その成果物の「優れている理由（合格基準）」を3点だけ言語化してみましょう。

• 「結論がファーストビューで一目で理解できる」
• 「すべての数値データに出典と根拠が明記されている」
• 「次に誰がいつまでに何を行うべきか、一切の迷いが生じない」

普段は感覚的に行っているレビュー視点こそが、AIに渡すべき「良質なSkill」の最も貴重な構成要素となります。現場のメンバーが長年の実務経験で培ってきた判断基準を、組織の再利用可能な資産へと昇華させること。それこそが、Agent Skillsを構築する真の価値です。

自社業務のどこからSkill化を進めるべきか、どのように社内展開を推進していくべきかお悩みの際は、ぜひミチガエルへお気軽にご相談ください。業務プロセスの棚卸しから、組織に合わせた実践型研修、PoCの実施・改善まで、貴社の状況に合わせた最適なAI定着をご支援いたします。

元動画・参考資料

元動画は、良いAgent Skillsの作り方完全解説！AI活用のプロがSkillsを作るコツを話しますです。

• Agent Skills：概要
• Agent Skills：公式仕様
• Claude Code：スキルの作成・設定