Copilot Studioのエージェント開発において、とても便利な「スキル（Skill）」機能。
これまで「Instructions（システムプロンプト）」にすべてのルールや手順を詰め込んでCopilotを動かすと「動作が重い」「無駄なトークンを消費してしまう」「関係ない場面で誤作動する」みたいな問題があった。
この記事の「スキル」を活用すれば、特定シナリオ専用の手順を別モジュールとして切り出し、必要な時だけ賢く動く“身軽なエージェント”を作ることができる。
さらにびっくりしたのは、このスキル内に「Pythonスクリプト（Scripts）」を直接組み込める点。これにより、単なるプロンプト制御の枠を超えた、独自処理もエージェントに任せられるようになった。
この記事では、Copilot Studioにおける「スキル」の基本的な説明から、「Instructions」との使い分け、実際のつくり方などをご紹介。
スキルとは
Copilot Studioの「スキル（Skill）」をざっくりいうと、「特定の業務を任せる際の、その業務専用のマニュアル」みたいなもの。
今までのエージェント開発では、システムプロンプト（Instructions）にすべてのルールや手順を書いていた。
しかしそれだと、「今はその仕事をしてない」ってときまで関係ない指示を常に読み込み続けるから、AIのメモリ（コンテキスト）を無駄遣いするし、精度落ちやレスポンス低下の原因になっていた。
そこで「スキル」。たとえば「有給日数の計算」みたいな特定シナリオ専用の手順を、別モジュールとして切り出せるようになったのがスキルの大きな利点。
エージェントは必要な時だけそのスキルを呼び出してタスクを実行することで、基本のプロンプトはシンプルに保ちつつ、必要な時だけ賢く動く身軽なエージェントが作れるし、機能ごとに分割管理できるから、開発者目線でも保守性が大きく上がる。
「スキル」に書くか、「指示」に書くか
エージェントへのルールや手順を「スキル（Skill）」に持たせるか、基本の「指示（Instructions）」に書くか。迷ったときは、この記事の考え方がめちゃくちゃ参考になる。
判断基準は、「その指示を、すべての会話に常に適用したいか？」という1点。
常に適用されるルール ＝ 「Instructions」
どんなシナリオでも100%守るべき前提条件は、Instructionsに書く。
- エージェントの役割
- 口調（トーン）
- 絶対に破ってはいけない禁止事項（ガードレール） など
これらは常にコンテキスト（AIの記憶）に置いておくことで、エージェントの行動の一貫性がしっかり担保される。
特定の状況でのみ使うルール ＝ 「Skill」
特定のシナリオでしか使わないルールや手順は、Skillに切り出す。
毎回の会話で使わない指示を、常にAIに覚えさせておく必要はなくて、特定の状況になったときだけ、必要な取扱説明書を引っ張り出させるのがスキルのいいところ。
使い分けることで得られる4つの効果
この切り分けを徹底すると、エージェントの性能が劇的に良くなる。
- コンテキストウィンドウの節約: 無駄な情報を常駐させないから、AIのメモリがパンクしない。
- 管理のしやすさ（保守性）: スキルごとに独立しているから、後からの修正や追加が圧倒的にラク。
- 精度の向上: 大量のルールから正解を探させるのではなく、ピンポイントで必要な指示だけを渡すため、AIが迷わず的確な判断ができる。
- スピード向上とコスト削減: 無駄な推論や検索ループが減るため、レスポンスが早くなり、無駄なトークン消費も抑えられる。
Skillsのベストプラクティス
Skillを作る際のベストプラクティスは色々書いてあったけど、個人的に参考になったのはこの3つ。
簡潔さが鍵
当然だけどスキルを含めた指示はコンテキストウィンドウ（AIへの指示）を消費する。その他の「システムプロンプト」「会話履歴」等もAIに渡されることを考えると、スキルの内容は極力簡潔にするのが推奨される。
大前提として「最近のAIはすでに賢い」ので、
- 本当にこの説明は必要か？
- AIはこのことを知っていると仮定して大丈夫？
- この段落はそのトークンコストに見合う価値があるか？
辺りを考えながら作るのが良いと書かれている。
宣言よりも手続きを優先する
基本的には「特定の状況に対するピンポイントの答え」をSkillに直書きするのではなく、「どんな質問が来ても、自力で答えにたどり着ける手順（ワークフロー）」を教えるのがセオリー。
- 宣言的な例：「売上を聞かれたら、このSQLを実行しろ」
- 手続的な例：「売上を聞かれたら、まずスキーマを確認し、関連テーブルを結合したうえで、ユーザーの条件に合わせてWHERE句を作成しろ」
答えを固定するのではなく、考え方のプロセスを渡すことで、Skillの汎用性がグッと上がる。
ただし、これはあくまで「AIに考えさせたい場合」の話。
次で説明する「自由度を低くしたい（ガチガチに固定したい）タスク」の場合は、むしろ宣言的に書いた方がいいこともあると思っている。
適切な自由度を設定する
「手続き」を教えるにしても、AIにどれくらい裁量を与えるか（ガチガチに縛るか）の調整が必要になる。タスクの性質によって、厳密さを変えるイメージ。
- システムの本番環境やDBに直接触る処理
- 会社の規定で1文字でもフォーマットがズレてはいけない書類作成
ここはAIのクリエイティビティとか不要で、がちがちに固めた指示を書くか、ワークフローやScriptといったプログラムを実行させるべきとき。
- 決まったフォーマットでのレポート生成やデータ集計
「アウトプットの型（マークダウンやテンプレ）」は指定しつつ、その中での表現やデータ処理はAIに任せる場面。実務ではこのバランス型が一番多い。
- アイディア出し、壁打ち
- コードのレビューやリファクタリング提案
正解は一つじゃないから、「良い例」のように考え方のプロセスだけを渡し、AIの圧倒的な知識量と地頭の良さを最大限引き出したい場面。
いずれにしろ、Skillをつくるときは「自由度」を考えることが大事かと。
実践：Skillを作ってみる
ということで、説明が長くなっちゃったけど、実際にスキルを作ってみる。
テーマ：独自休暇管理エージェント
今回は「独自休暇エージェント」として「社長が決めた独自休暇が多い会社」のエージェントをつくってみる。
1. 独自休暇の詳細を説明するスキル
2. 実稼働日を計算するスキル
まずはベースとなるエージェントを作成
まずはベースとなるエージェントを作成する。
スキル追加 : 独自休暇の詳細を説明するスキル
続いてスキル1「独自休暇の詳細を説明するスキル」を作成してみる。
イメージとして「休暇がいつか？」くらいはナレッジだけで回答できるようにして、「なんでこんな休暇があるの？」みたいなマニアックな質問をされたときだけこのスキルを使う、みたいなイメージ。
SKILL.mdもこんな感じで作成する。
--- name: vacation-details-skill description: 当社の独自休暇（ねこの日、怠け者の日、ポッキーの日、ふろの日、いい肉の日など）の詳細や制定趣旨、社長メッセージについて回答する際に使用する。ユーザーが特定の独自休暇の由来や社長の想い、過ごし方について質問したときに呼び出すこと。 --- # 休暇の詳細回答 Skill 当社の独自休暇について、その背景や「社長からの熱いメッセージ」を添えて回答するための指示書です。 ## 動作フロー 1. **参照ファイルの読み込み** ユーザーから独自休暇（ねこの日休暇、怠け者の日休暇、ポッキーの日休暇、ふろの日休暇、いい肉の日休暇など）に関する質問を受けたら、`独自休暇について.pdf` を確認し、該当する休暇の「日付」「制定趣旨」「社長コメント」を取得する。 2. **回答の構成とトーン** - **全体**: 社員のモチベーションを高める熱く前向きなトーンで回答する。 - **明確な分離**: 「AIアシスタントとしての解説・アドバイス」と「社長からの熱いメッセージ（引用文）」を明確に区別して出力する。 ## 出力フォーマット 回答を出力する際は、必ず以下のフォーマットを遵守すること。 ```markdown ### ［休暇名］についてのご案内 ［AIアシスタントからの概要・過ごし方のアドバイスやエール］ > **🔥 社長からの熱いメッセージ** > > ［『独自休暇について.pdf』から取得した、対象の休暇に関する社長コメントやメッセージを熱意を込めて引用形式で記載］ --- ※この休暇は有給の特別休暇です。業務を調整の上、全力で羽を伸ばしてください！
※zipは、SKILL.mdやreferencesフォルダがzip直下にくるよう作成すること
vacation-details-skill/
├── SKILL.md
└── references/
└── 独自休暇について.pdf
スキル追加 : 実稼働日を計算するスキル
続いて、独自休暇の情報から「実稼働日を計算するSkill」を作成してみる。
ここで、せっかくなのでオープンフォーマットのAgent Skillsで使用できる「Pythonスクリプト」がCopilot Studioでも動くかを確認する。
SKILL.mdをこんな感じで作成し、
---
name: business-days-calculator
description: 指定された期間（start〜end）における当社の実稼働日数（営業日数）を計算する際に使用する。土日、日本の国民の祝日、および当社独自の特別休暇を除外した正確な稼働日数を算出する場合に呼び出すこと。
---
# 実稼働日数計算 Skill
ユーザーからの質問をもとに指定期間の始点（`start`）と終点（`end`）を特定し、土日・祝日・当社独自休暇を除外した実稼働日数を計算・回答するための指示書です。
## 動作フロー
1. **期間（start / end）の特定**
- ユーザーの入力（例：「今年の11月の稼働日数は？」「2026年8月1日から8月31日までの実働日数」など）から、計算対象の開始日（`start`: `YYYY-MM-DD`）と終了日（`end`: `YYYY-MM-DD`）を判定する。
- 年の指定がない場合は、現在の年（または文脈上適切な年）を補完する。
2. **独自休日データセットの準備**
当社の独自休暇情報をナレッジ（`独自休暇規定.pdf`）から取得し、オブジェクト配列に整形する。
list of dict: [{"date": "YYYY-MM-DD", "name": "..."}]
※対象年に合わせて日付の `YYYY` 部分を設定すること。
3. **Pythonスクリプトの実行**
`scripts/calculate_business_days.py` を bash コマンドで呼び出し、計算を実行する。
```bash
python3 scripts/calculate_business_days.py \
--start "取得した開始日（yyyy-MM-dd）" \
--end "取得した終了日（yyyy-MM-dd）" \
--custom-holidays '[{"date": "独自休暇日", "name": "休暇名"}]'
```
4. **結果の整形と回答**
スクリプトの実行結果（JSON / 標準出力）を受け取り、分かりやすくユーザーに回答する。
## 出力フォーマット
```markdown
### 📅 実稼働日数計算結果（［start］〜［end］）
対象期間の実稼働日数は **［実働日数］日** です！
#### 【内訳】
- **総日数**: ［総日数］日
- **土日**: ［土日の数］日
- **国民の祝日**: ［祝日の数］日（［該当する祝日名］）
- **当社独自休暇**: ［独自休暇の数］日（［該当する独自休暇名］）
---
※独自休暇もしっかりカウントから除外されています！無理せず計画的に業務を進めましょう！
```
## 注意事項
- 独自休暇が土曜日または日曜日に重複している場合、ダブルカウントして引きすぎないようスクリプト側で処理されていることを前提とする。
- ユーザーへの回答時には、どの祝日や独自休暇が対象期間に含まれていたか内訳を明示すること。
business-days-skill/
├── SKILL.md
└── scripts/
└── calculate_business_days.py
このとき「ブラックフライデー」も休日としてカウント（独自知識）されているので、AIの知識ではなくPythonを使って正解を出した（であろう）ことがわかる。
ということで非常に便利なSkills。今後はこのSkillsをいい感じに作って、社内で公開して、エージェントの開発速度がアップして、みたいな使い方が増えてくのかな。
コメント