執筆している2026年9月15日時点の情報です。Cowork は更新が速い機能のため、最新情報は必ず公開情報（本記事末尾の参考リンク）もあわせてご確認ください。
「自分用のSkillを作れたけれど、意図したときに動いてくれる？」
「品質スコアが高ければ、安全に使えると考えてよい？」
Copilot CoworkのカスタムSkillを使い始めると、作り方だけでなく、作ったSkillをどう評価すればよいかも気になってきます。
Microsoft Learnの利用ガイドでは、Skillの作成・更新・検証時に自動評価を行い、結果を Skill Report として返す仕組みが説明されています。
この記事では、評価の観点と結果の読み方、Skillの指示を書くときに意識したいポイントを整理します。
なお、今回は公式ドキュメントに基づく機能解説です。実環境での検証結果や、評価機能の新規リリースを報告する記事ではありません。
1. 最初に結論：品質の点数と安全性の判定は別です
今回のポイントは、次の3つです。
- Skillは、適切なタイミングで呼び出されるかと、呼び出された後に正しく動くかの両面から評価されます。
- 品質は100点満点で評価されますが、高得点だけでは安全性の判定を通過できません。
- 公開後の変更では、過去の基準と比較し、以前より悪くなっていないかも確認されます。
学校の試験にたとえるなら、品質スコアは「答案の出来栄え」、安全性ゲートは「必ず守るべき条件の確認」です。答案の点数が高くても、別の必須条件を満たしたことにはなりません。
自動評価があることと、Microsoftによる認証や無条件の安全保証があることは区別して考えましょう。
出典：Microsoft Learn — How Cowork evaluates skills
2. Skillの失敗には「呼ばれ方」と「動き方」があります
カスタムSkillは、特定の仕事の進め方をCoworkに伝えるための指示です。
たとえば「週報を作るSkill」では、単に週報を書けるだけでなく、週報を頼まれたときに呼び出され、関係のない依頼では呼び出されないことも大切です。
公式資料では、失敗を大きく2つに分けています。
| 失敗の種類 | 説明用の例 |
|---|---|
| 呼び出しが適切ではない | 「週報を作って」では動かず、「文章を短くして」という別の依頼で動く |
| 呼び出し後の動作が適切ではない | 週報Skillは動くが、対象期間を取り違えたり、依頼していない処理まで行ったりする |
つまり、「一度うまく動いた」だけではSkill全体の品質は判断できないということです。
この区別は、Skillの説明文と処理手順を見直すときにも役立ちます。呼ばれ方の問題ならトリガーや対象範囲、動き方の問題なら具体的な指示を確認します。
出典：Microsoft Learn — How Cowork evaluates skills
3. 静的チェックと動作チェックの違い
Coworkの評価には、2種類のチェックがあります。
静的チェック：実行せずに指示や構造を確認する
静的チェックでは、Skillの構造や制限、同梱コードのセキュリティ上の問題、指示文に含まれるプロンプトインジェクションのパターンなどを確認します。
プロンプトインジェクションとは、文書などに紛れ込んだ指示によって、AIを本来の依頼とは異なる行動へ誘導する手法です。
公式資料では、静的チェック中にコードは実行しないと明記されています。
動作チェック：実際に近い依頼で振る舞いを確認する
動作チェックでは、現実的なプロンプトを使い、出力内容、実行するアクション、ツールの使い方の効率などを評価します。
呼び出しについては、**適合率（precision）と再現率（recall）**で評価すると説明されています。
| 指標 | Skillで考えると |
|---|---|
| 適合率 | 呼び出された場面のうち、本当にそのSkillが必要だった割合 |
| 再現率 | そのSkillが必要な場面のうち、実際に呼び出せた割合 |
「何でもこのSkillで処理する」と広く定義すればよいわけではありません。必要な依頼を拾いながら、別のSkillの仕事を奪わないことも重要です。
出典：Microsoft Learn — How Cowork evaluates skills
4. 品質スコアは4項目・各25点
品質スコアは、次の4項目を各25点、合計100点で評価します。
| 評価項目 | 意味 | 指示を書くときの着眼点 |
|---|---|---|
| Trigger clarity | 適切なときに呼び出される | どの依頼に使うSkillかを明確にする |
| Instruction specificity | 何をすべきか分かる | 入力、手順、出力形式を具体化する |
| Scope boundaries | 目的の範囲内にとどまる | 対象外の作業も明示する |
| Robustness | 想定外の入力を安全に扱う | 情報不足や処理できない場合の対応を書く |
右端の着眼点は、公式の評価項目をもとにした筆者の整理です。
点数の区分は次のとおりです。
| 点数 | 区分 |
|---|---|
| 85点以上 | Excellent |
| 70〜84点 | Good |
| 50〜69点 | Needs work |
| 50点未満 | Poor |
ただし、85点以上なら必ず公開できる、という意味ではありません。品質の区分と、次に説明するゲートは別の役割を持ちます。
出典：Microsoft Learn — How Cowork evaluates skills
5. ゲートは「点数だけでは判断できない条件」を確認します
公式資料では、品質スコアに加えて、公開や変更の可否を判断するゲートが説明されています。
初回公開の最低条件
Launch floorは、初回公開前に満たす必要がある、リスクに応じた最低スコアです。安全性の失敗がないことも必要です。
確認した資料には、すべてのSkillに共通する具体的な合格点は記載されていません。
安全性と責任あるAIの確認
Safety and RAI scanは、安全性と責任あるAI（Responsible AI）の観点から指示を確認します。
たとえば、破壊的な操作や確認なしの送信などは、適切な保護策がなければ失敗になると説明されています。
また、Trust and safety gateでは、プロンプトインジェクション、制約を回避させる誘導、機微なデータ、未確認のアクションなどに関するテストを扱います。
このゲートは品質スコアから独立しており、高得点でも自動的には通過しません。
Skill同士の競合
Conflict scanは、同じ依頼を取り合うSkillを検出します。
たとえば「会議内容を整理するSkill」と「議事録を作るSkill」の範囲が曖昧だと、同じ依頼で競合する可能性があります。
公式資料では、Skill間の明示的な引き継ぎを追加して競合を解消すると説明されています。
変更後の品質低下
Regression checkは、新しい評価結果を公開後の基準値と比較します。基準からの低下があれば、その変更をブロックすると説明されています。
Regressionは「回帰」や「退行」と呼ばれ、ここでは修正によって以前できていたことが悪くなることを指します。
機能追加だけでなく、既存の振る舞いを守ることも評価対象です。
出典：Microsoft Learn — How Cowork evaluates skills
6. すべてのSkillで同じ深さの評価をするわけではありません
評価の深さは、Skillが使われる範囲とリスクの高さによって変わります。
公式資料が挙げる利用範囲は個人・チーム・組織・ストア、リスクは低・中・高です。
| 深さ | 評価内容 |
|---|---|
| Minimal | 構造の検証と品質スコア |
| Standard | 動作テストを追加 |
| Full | 同梱ファイルなどの検証、安全性テスト群、競合スキャンを追加 |
| Maximal | 人によるレビュー、回帰テスト群、攻撃的な入力を想定したテスト群を追加 |
高リスクのSkillは、少なくともFullの深さで評価されます。 また、前回の評価から変更がなければ、評価の実行はスキップされます。
このため、「自動評価があるから、すべてのSkillを毎回人がレビューする」という理解も正確ではありません。
出典：Microsoft Learn — How Cowork evaluates skills
7. 具体例：週報Skillの指示をどう改善するか
ここからは、評価項目を理解するための仮想例です。実際に実行したSkillや、評価済みの結果ではありません。
たとえば、次の指示だけでは判断の余地が大きく残ります。
仕事の情報を集めて、いい感じに週報を作る。
何を集めるのか、どこまで処理するのか、情報が足りない場合にどうするのかが分かりません。
指示の内容を、次のように具体化してみます。
「週報を作成して」「今週の活動を週報にまとめて」と依頼されたときに使用する。
ユーザーが指定した対象期間と資料をもとに、「完了したこと」「進行中のこと」「課題」「次のアクション」の順で週報の下書きを作成する。
対象期間や参照資料が不明な場合は、作成前に確認する。資料から確認できない成果・数値・担当者は推測して補わない。
このSkillの担当範囲は下書きの作成までとし、メール送信やTeamsへの投稿は行わない。
この例では、呼び出し条件、出力形式、対象外の処理、情報不足時の対応を分けて書いています。
大切なのは、指示を長くすることではなく、判断が分かれそうな箇所を具体化することです。
このように書けば必ず高得点になる、あるいは安全性ゲートを通過するという保証はありません。実際のSkill Reportと業務上の要件を見ながら改善します。
8. 作成からSkill Reportの確認まで
公式ガイドにある、Customizeページから作成する流れは次のとおりです。
- Coworkの左側ナビゲーションから Customize を開きます。
- Skills タブで Add → Create new を選びます。
- 名前、説明、カテゴリ、指示についての質問に回答します。
- 下書きを確認し、チャットで確定します。SkillはOneDriveに保存され、次のセッションで利用可能になります。
作成・更新・検証時には自動評価が行われるため、評価を別途依頼する必要はないと説明されています。
返される Skill Report は判定から始まり、問題がある場合には優先度の高い具体的な改善点が示されます。
読むときは、総合点だけでなく、呼び出し条件、処理範囲、安全性、競合、変更後の品質低下のどこに問題があるかを確認しましょう。
なお、利用開始ガイドでは、Microsoft 365 Copilotライセンス、Coworkの有効化、従量課金とCowork課金の有効化などが前提です。カスタムSkillはモバイルではサポートされていません。
出典：
Use Copilot Cowork ／ Get started with Copilot Cowork
9. 自動評価を過信しないための注意点
今回確認した利用ガイドの資料日付は2026年9月14日です。ただし、資料の更新日と機能の提供開始日は同じではありません。
評価機能単独の提供開始日や、全テナントへの展開完了時期は、確認した資料からは特定できません。
また、安全性の評価と、日々の作業におけるアクションの承認は別の話です。公式ガイドでは、メール送信などの機微な操作について承認方法が説明されています。セッション中の類似操作について確認を省略する設定もあるため、承認する範囲を理解しておく必要があります。
Skillの評価結果が良好でも、実行時の宛先・内容・操作範囲の確認を不要にするものではありません。
出典：Microsoft Learn — Approve actions
10. まとめ
CoworkのSkill自動評価は、指示文の出来栄えだけでなく、呼び出しの適切さ、動作、安全性、Skill間の競合、変更後の品質低下まで扱う仕組みです。
作成時には、次の4つの問いを意識すると整理しやすくなります。
- いつ使うSkillなのか
- 何を、どの形式で完成させるのか
- どこから先は担当しないのか
- 情報不足や想定外の入力にどう対応するのか
「一度動けば完成」ではなく、Skill Reportを手がかりに、意図した範囲で使い続けられる指示へ改善していきましょう。
参考リンク
いずれも2026年9月15日確認。
- Microsoft Learn — Use Copilot Cowork
- Microsoft Learn — How Cowork evaluates skills
- Microsoft Learn — Get started with Copilot Cowork
- Microsoft Learn — Approve actions
ご質問・追記要望は本ページのコメント欄までお寄せください。