1. はじめに
この記事を作成する背景は、Skills を追加した後に「手順を守るようになった」「便利になった」と感じても、モデル変更、依頼文の改善、会話履歴、追加したスクリプトなどの影響を切り分けにくいことです。ファイルを配置したことや、エージェントが「スキルを使いました」と返答したことだけでは、品質改善の証拠になりません。
この記事の目的は、何が分かっていて、何を自分の Copilot 環境で測る必要があるかを整理し、Skills の有無を比較できる評価手順を示すことです。公式仕様、公開研究の結果、本記事の評価設計を区別します。
以降の研究数値は引用元の実験結果です。GitHub Copilot の改善率や費用削減率として転用せず、本稿では Copilot 上の未実測スコアを掲載しません。
2. Agent Skills は何を変えるのか
2.1 タスクに応じて知識と手順を読み込む
GitHub Copilot の Agent Skills は、SKILL.md を中心とする指示・スクリプト・リソースのフォルダです。Copilot は依頼と description を基に利用を判断し、選んだ Skill の本文をコンテキストへ読み込みます。[^github-skills][^adding-skills]
仕様と VS Code の公式説明では、概ね メタデータの発見 → 本文の読込 → 必要なリソースへのアクセスという段階的な読み込みを採用します。これはモデルの重みを更新する学習とは別で、実行時に利用できる手順や情報を増やす方式です。[^skills-spec][^vscode-skills][^skillsbench]
| 期待する変化 | 評価するもの | 保証できないこと |
|---|---|---|
| チームの手順を再利用する | 必要な確認の抜け、受け入れ条件の充足 | 誰が使っても必ず同じ品質になること |
| 専門知識を必要時に渡す | 関連タスクでの検証済完了率 | すべてのタスクで改善すること |
| 長い共通指示を分ける | 実際の入力・出力、利用コスト | 一定割合のトークン削減 |
| スクリプトやテンプレートを再利用する | 成果物、実行成功、保守負荷 | 追加ツールの効果まで SKILL.md の形式だけに帰属できること |
この表は本記事の評価仮説です。段階的な読込でもメタデータや本文は入力となり、余計な読込・探索・ツール実行が増える可能性があります。「Skills があればコンテキスト消費はゼロ」とは考えません。[^skills-spec]
2.2 登録・読込・利用・成果を分ける
| 観測段階 | 確認する証拠 | まだ言えないこと |
|---|---|---|
| 利用可能 | 対応する場所・形式・有効設定、Skill 一覧 | 対象タスクで本文が読まれること |
| 読込 | SKILL.md の読込・呼び出しを確認できるトレース | 書かれた手順を実行したこと |
| 利用 | 必要な確認やコマンドが実際に行われた記録 | 最終成果が良くなったこと |
| 成果 | 同じテスト、受け入れ基準、レビューで得た結果 | 別タスク・モデル・クライアントでも再現すること |
VS Code の公式資料も、発見された Skill がすべての関連プロンプトで呼び出されるとは限らないと明記しています。読込や利用を観測できない場合は 未確認と記録し、エージェントの自己申告だけで確認済みにしません。[^vscode-skills]
2.3 比較するクライアントを一つに固定する
公式資料は Copilot CLI、app、cloud agent、code review、IDE の agent mode などの対応を案内していますが、配置場所や任意機能はクライアントにより異なります。評価の一組では、たとえば Copilot CLI 同士、または VS Code 同士を比較します。CLI の A と cloud agent の B を混ぜると、Skills 以外の差が大きくなります。[^github-skills][^vscode-skills]
共通の coding guidelines は custom instructions、詳細なタスク手順は Skills、という役割の区別も重要です。Skills なしの A から .github/copilot-instructions.md や AGENTS.md まで取り除き、現実より弱い対照群を作らないようにします。[^adding-skills]
3. 公開研究から分かる効果と限界
3.1 SkillsBench v4 は改善とばらつきを報告している
SkillsBench は、固定されたタスクと検証器に対して Skills なし／curated Skills ありを比較する研究です。本稿は arXiv の v4、Table 2・3 と本文の結果分析を対象とし、更新されるリーダーボードや旧版の数値を混ぜません。[^skillsbench]
| 項目 | v4 の報告 | 読み取る際の注意 |
|---|---|---|
| 評価範囲 | 87 タスク、8 領域、18 モデル・harness 構成 | 専門的な terminal／container タスクの集合 |
| 全体平均 pass 率 | 33.9% → 50.5%、差は +16.6 pp | タスク単位で平均し、構成を集約した研究結果 |
| Software Engineering 領域 | 16 タスクで 37.6% → 49.2%、+11.6 pp | 特定のタスク集合・構成での結果 |
| 構成別の改善量 | +4.1〜+25.7 pp | 同じ増強でも agent stack により差がある |
| タスク別の悪化 | 87 タスク中 13 タスクで負の差 | 平均改善は「全タスクで有効」を意味しない |
pp は percentage points、つまり パーセントポイントです。33.9% と 50.5% の差が 16.6 pp であり、「16.6% 速くなった」「費用が 16.6% 減った」という意味ではありません。[^skillsbench]
図は報告平均だけを示しています。構成ごとのばらつきや信頼区間は原論文を参照してください。研究では Skills を読み込む割合が高くても解決率が高いとは限らず、不要に重い手順、強い既定の戦略の置き換え、デバッグしにくいツールへの誘導などを失敗例として挙げています。[^skillsbench]
3.2 この数値を GitHub Copilot の効果にしない
v4 の実験で列挙される harness は OpenHands、Gemini CLI、Claude Code、Codex CLIです。GitHub Copilot は含まれません。同じモデル名を選べても、Skill の発見・読込、ツール、承認、コンテキスト管理を担う harness が異なれば、効果は同じとは限りません。[^skillsbench]
タスクの選び方にも注意が必要です。論文は専門作業を重視し、構築過程で Skills による差が測れない低シグナルのタスクを除く方針を説明しています。普段の修正チケットを無作為に集めた標本ではないため、平均改善量を自分の業務の期待値にしません。[^skillsbench]
また、モデルが実行中に Skill を作る self-generated 条件は、別途評価された三つの構成で baseline を下回りました。ただし、内容の誤りだけでなく、Skill が発見されないことや作成工程が解決作業を圧迫することも混ざっています。「AI が作った Skills はすべて無効」とは結論できません。固定した Skill の品質と実行中の作成コストを分けて評価します。[^skillsbench]
3.3 情報の追加と、Skills 形式の価値を分ける
SkillsBench 自身も、Skills あり条件はコンテキストを増やすため、改善の一部が情報量の追加に由来する可能性を限界として挙げています。したがって、A/B が良くなっただけで「同じ情報を普通に渡すより Skills 形式が優れる」とは言えません。[^skillsbench]
AGENTS.md などの repository-level context files を調べた別研究もありますが、これは Agent Skills の実験とは異なります。同研究は context files によってテストや探索、特定ツールの利用が増えることを報告しています。指示を読んで行動が変わることと、成果が改善することを分けるという参考にはなりますが、Skills の効果量として足し合わせません。[^context-files]
4. GitHub Copilot での A/B 評価を設計する
以下は公開研究の paired evaluation と評価の基本原則を参考にした、本記事の提案プロトコルです。公式の Copilot ベンチマーク仕様ではありません。[^skillsbench][^agent-evals]
4.1 「対象 Skills 一式の有無」を主比較にする
| 条件 | 共通するもの | 変えるもの | 分かること |
|---|---|---|---|
| A：対象 Skills なし | タスク、コード、モデル、共通指示、基本ツール、権限 | 評価対象ライブラリへアクセスできない状態 | 現実的な対照群の成績 |
| B：対象 Skills あり | A と同じ | 固定した対象ライブラリを利用可能にする | そのライブラリを導入する効果 |
| 補助 I：同じ知識を通常の指示で渡す | 同じタスク・知識・必要なリソース | Skill の代わりに通常の指示へ追加 | 内容の価値と渡し方を検討する材料 |
ここで「なし」は 評価対象ライブラリがないという意味です。クライアントの内蔵機能や共通の既存 Skills まで完全にゼロにしたとは主張せず、それらは A/B で固定して記録します。
主比較の A/B では依頼文を同じにし、B だけに /skill-name を付けません。自動選択と明示呼び出しを比べたい場合は、別の条件として実施します。補助 I は同じ知識を追加するためプロンプトが変わり、読込タイミングなどの差も残ります。形式だけの純粋な因果効果を完全に切り分ける条件ではありません。
4.2 固定する条件を manifest に残す
| 固定・記録する項目 | 比較を壊す例 |
|---|---|
| クライアントとバージョン、モデルと reasoning 設定 | A は軽量モデル、B は高性能モデル |
| タスクコード・依存 lockfile・OS・実行環境 | B にだけ必要な依存が入っている |
| 共通 instructions、custom agent、基本ツール、MCP、承認設定 | B だけに追加の権限や別の agent を与える |
| 対象 Skill の本文・description・補助ファイルの hash | 毎試行「最新版」を入れ直す |
| 個人・plugin・親フォルダの Skills と memory の設定 | A にも別のパスから同じ Skill が入る |
| 依頼文、時間・利用量の上限、終了条件 | B だけ長時間実行し、A は早く打ち切る |
| 採点コード、受け入れ基準、レビュー手順 | 結果を見てから B に有利な基準へ変える |
モデルを固定できない環境や、Auto が実際に違うモデルへ振り分けた試行では、その差を記録します。固定名でもバックエンドを完全に凍結できるとは限らないため、実行日時と実際に確認できたモデル識別子を残します。
入力の量、model／reasoning、履歴、ツール、キャッシュが利用コストに影響することは公式ガイドでも説明されています。通常運用の最適化と、A/B で差を切り分けるための条件固定は、目的を分けて扱います。[^ai-usage]
4.3 タスクは「Skills が得意なものだけ」にしない
タスク集合は、たとえば回帰テスト、既存 API の修正、ログ調査、ドキュメント更新など、自分の業務分布から選びます。さらに、対象 Skill と関係が薄いタスクを 負の対照として含め、余計な読込や誤った手順の適用が増えないか確認します。
Skills を作成・改善する開発用タスクと、最終評価用の holdout タスクは分離します。Skill に個別タスクの正解パッチ、固定の正解値、採点用テスト、答えを埋め込まないことも重要です。公開する依頼文・受け入れ条件は A/B で同じにし、非公開の採点基準が隠れた追加要件にならないよう設計します。[^skillsbench]
4.4 毎回初期化し、順序と反復を決める
各試行は、同じタスクコードから作った 別の作業コピーと新しい会話・セッションで始めます。A の出力を B に渡したり、前の成功パッチを残したりしません。B の Skill 追加は実験設定として別に管理し、成果物の余計な変更数へ数えません。
タスクと反復ごとに A→B／B→A の順を無作為に割り当て、時刻・負荷・キャッシュの偏りを抑えます。完全に制御できないキャッシュや memory は、その制約も記録します。モデル出力の変動に備える複数試行は、一般的な agent evaluation の基本です。[^agent-evals]
たとえば「10 タスク × 各条件 3 回 × A/B」の pilot は 60 試行になります。これは計画数の説明であり、本稿の実施数ではありません。3 回なら有意差を保証できるわけでもないため、予算・ばらつき・必要な改善幅を基に本評価の規模を事前に決めます。
5. 小さな Skill と共通の依頼文を用意する
5.1 個別の答えではなく、再利用する手順を書く
以下は .github/skills/regression-test-design/SKILL.md の 説明用サンプルです。実際に利用する場合は、プロジェクトのテスト方式に合わせてレビューします。name とディレクトリ名の一致、description に能力と利用場面を記すことは仕様に基づきます。[^skills-spec]
---
name: regression-test-design
description: >
既存コードの不具合に対する回帰テストを設計・実行する。
バグ修正、失敗ケースの追加、既存動作の維持を確認する場面で使う。
---
# 回帰テストの設計手順
1. 依頼の期待動作と、既存の公開契約・テスト方式を確認する。
2. 正常、異常、境界、状態遷移のうち対象に必要なケースを列挙する。
3. 修正前に失敗を再現するテストを作り、実際の失敗理由を確認する。
4. 修正後に対象テストと関連する既存テストを実行する。
5. 成功、失敗、未実行を分け、コマンド・結果・残課題を報告する。
テストの削除、skip、弱い assert によって成功扱いにしない。
無関係な改修や未承認の依存追加は行わず、制約に阻まれたら停止して報告する。
このサンプルには特定タスクの正解や期待スコアは入れていません。最初はこのような指示中心の Skill にすると、スクリプトや追加リソースの有無まで同時に変える複雑さを減らせます。スクリプト付きのライブラリを評価する場合は、パッケージ全体の効果として報告します。
5.2 A/B で同じ依頼文を使う
たとえば、Python の既存クライアントを題材にした評価タスクなら、依頼は次のように具体化します。これは仮想プロジェクト用の入力例で、実際の実験結果ではありません。
目的:
クライアントのタイムアウト時に例外情報が失われる不具合を修正する。
制約:
公開 API と既存の成功時の挙動は変えない。
変更対象は該当クライアントと関連するテストに限定する。
依存追加、テスト削除、skip は行わない。
受け入れ条件:
タイムアウト時の例外情報を呼び出し元が取得できる。
既存の正常系・異常系が壊れない。
不具合を再現する回帰テストがある。
検証と終了条件:
リポジトリの標準コマンドで対象・関連テストを実行する。
実行したコマンド、成功・失敗・未実行、残課題を報告して終了する。
ここでは Skill 名を指定しません。明示的に呼ぶ条件を試す場合は、「利用可能にした効果」ではなく 明示呼び出しを含む運用の効果として、主 A/B と別に記録します。
5.3 利用可能な状態は事前に確認する
Copilot CLI では、対話セッション内の /skills list、/skills info などで利用可能な Skills と配置元を確認できます。Skill 追加後の /skills reload、有効・無効の切り替えも公式に案内されています。[^cli-skills]
/skills list
/skills info regression-test-design
これは 登録・設定の確認であって、評価タスクでの本文読込の証明ではありません。確認後は新しいセッションで試行を開始し、事前確認の会話を本番の入力へ混ぜないようにします。
比較は実験用の作業領域・設定で行い、普段使う個人 Skills を無条件に削除しません。対象 Skill が個人設定、plugin、親リポジトリなどから A に入っていないかも確認します。配置元や提供形態はクライアントの公式ガイドを正としてください。[^github-skills][^vscode-skills]
6. 品質・時間・費用を測る
6.1 主指標は独立して確認した完了にする
コード課題では、保護した受け入れテスト、既存テスト、必要な静的チェックを基に採点します。「テストが通りました」という回答ではなく、採点者が確認した成果物と実行結果を証拠にします。自然言語・ドキュメント課題では、事前に定めた rubric と条件を伏せたレビューを組み合わせます。[^agent-evals]
主指標の例は、割り付けた試行のうち、上限内で必要条件をすべて満たした 検証済完了率です。人が後から修正して完成させた場合でも、元の自律試行を成功へ書き換えず、手戻りとして別に記録します。
6.2 指標の定義と取得範囲をそろえる
| 指標 | 定義例 | 注意点 |
|---|---|---|
| 検証済完了率 | pass の試行数 ÷ 割り付けた試行数 | 未検証や timeout は成功にしない |
| 制約違反 | 範囲外変更、テスト削除、未承認操作の件数 | 品質を平均点だけにしない |
| 自律試行の時間 | 依頼開始から提出と独立検証まで | Queue・setup を含むか両条件で統一 |
| 人の手戻り | 受け入れまでの修正時間・追加指示 | 条件を伏せた成果物レビューが望ましい |
| 利用量・費用 | 取得できる AI credits、token、実行費用 | 取得不可は欠測。Token 数をそのまま請求額にしない |
| 診断情報 | 本文読込、必要な手順の実行、ツール利用 | 回数増加を品質改善の代わりにしない |
入力、出力、キャッシュ、モデルなどがコストを左右するため、Skills が短いかどうかだけでは費用差を決められません。試行単位の利用量を取得できないクライアント・契約では、その粒度の差を断定せず、取得範囲と欠測を報告します。[^ai-usage]
6.3 未読込の試行を主集計から除かない
B で Skill が読まれなかった試行も、「利用可能にする」という運用の実際の結果です。主集計に残し、読込率や読込後の失敗を診断に使います。
読込済みの B だけを、すべての A と比較すると、読込を起こしやすいタスクを後から選ぶことになります。読込済みの部分集合は探索的分析として扱い、A/B 全体の因果効果と区別します。
環境障害、未検証、timeout も記録します。環境障害だけを都合よく除くのではなく、再試行や打ち切りの規則を事前に決め、元の割付・追加試行・除外理由を追跡します。障害の偏りで比較が成立しない場合は、Skills の品質効果を判断保留にします。
6.4 記録を再集計できる形にする
次は 記録項目の CSV header 例です。実測行は含めていません。
task_id,repeat_id,attempt_id,condition,client_version,model_id,base_code_commit,common_config_hash,skill_tree_hash,skill_available,skill_loaded,skill_followed,verdict,wall_seconds,ai_credits,human_fix_minutes,evidence_path
skill_loaded と skill_followed は yes／no／unknown を区別します。verdict は、独立に確認できた pass／fail、成果を確認できない unverified、事前に定義した infra_error などとして保存します。利用量の欠測をゼロで埋めません。
トレースには秘密情報や個人情報が含まれ得るため、共有する記録は必要な証拠を保ったまま匿名化・マスキングします。
7. タスクごとの差を集計し、不確実性を示す
7.1 試行を全部まとめず、タスク単位で比較する
各タスクを同じ重みで評価するなら、まずタスクごとに反復試行の検証済完了率を計算し、A/B の差を平均します。これは本稿の集計案であり、業務で別の重みが必要なら事前に定義します。
p_A,i = タスク i の A の pass 数 / 事前に割り付けた試行数 R_i
p_B,i = タスク i の B の pass 数 / 同じ R_i
d_i = p_B,i - p_A,i
改善量（pp）= 100 × タスクごとの d_i の平均
pass と確認できなかった試行は、この割付ベースの主指標の成功数へ入りません。環境障害等の内訳と、事前規則に基づく再試行の結果も併記し、障害を含む完了率と純粋なコード品質を同じものとして説明しないようにします。
モデルやクライアントを複数評価する場合は、まず構成別に結果を出します。集約するなら、構成や業務カテゴリの重みも公開します。
7.2 反復の相関と、後からの選択に注意する
同じタスクの反復は独立した別タスクではありません。信頼区間を推定する一案は、タスクを単位に A/B の対応を保って再標本化する paired bootstrapです。各タスクの反復結果を平均してから d_i を計算し、タスク単位で標本を作り直します。SkillsBench も対応する条件間の差を扱う評価設計を採用しています。[^skillsbench]
少ないタスクでは区間が不安定で、反復を増やすだけでは業務の多様性を補えません。平均だけでなく、タスク別の差、悪化ケース、欠測、費用と手戻りを確認します。
改善幅と許容コスト、試行数、停止条件は事前に決めます。差が出るまで同じ結果を見ながら試行を足すのではなく、追加検証は別の計画・新しい holdout として扱います。
7.3 報告には適用範囲と限界を残す
結果を公開する場合は、少なくとも次をそろえます。ここでは未実測なので、改善量や削減率の架空の数値は埋めません。
- 対象クライアント・モデル・日時、タスクと Skill の版、共通設定
- 割付数、反復数、採点方法、完了率と対応差、不確実性
- 読込率・観測できなかった部分、失敗・環境障害・除外の内訳
- 時間、利用量、人の手戻り、Skill 作成・保守の負担
- 改善した／悪化したタスク、対象外のクライアントや業務
成功一件当たりの観測費用を出すなら、失敗も含めた同じ対象集合の費用合計を検証済成功数で割ります。成功がゼロなら値は未定義であり、「費用ゼロ」「最適」とは扱いません。
8. 効果が出ないときの見直しと導入判断
8.1 四段階のどこで止まったかを見る
| 観測結果 | 見直す点 |
|---|---|
| 利用可能になっていない | 配置、ファイル名、name、有効設定、重複名、配置元 |
| 利用可能だが本文が読まれない | description と依頼の対応、適用場面、クライアントの選択規則 |
| 読まれたが必要な手順が実行されない | 手順の具体性、参照先、ツール・環境要件、矛盾する指示 |
| 手順は実行されたが品質・費用が悪化 | 不要に重い処理、冗長な内容、既定の良い手順の置換 |
| 品質は改善したが運用コストが高い | 対象タスクの限定、内容の分割、作成・保守負担 |
読み込まれない Skill に手順を足しても、選択の問題が直るとは限りません。一方、手順が実行されているのに成果が悪いなら、呼び出しを強制するだけでは不十分です。
8.2 Skill 作成・維持まで含めて判断する
導入判断では、エージェントの利用費用だけでなく、Skill の作成、レビュー、環境追従、失敗の調査、メンテナンスも含めます。検証済完了率が上がっても、日常の対象件数が少なく保守が重ければ、チーム全体の利益は小さい可能性があります。
共有 Skills は GitHub による内容保証を意味しません。指示とスクリプトを確認し、必要な権限を両条件でそろえます。評価を有利にするために script 実行の確認やネットワーク制御を緩めないことも重要です。[^adding-skills]
研究と自分の評価から改善が期待できる タスクの範囲を決め、その範囲で段階的に導入するのが実務的です。Skill、モデル、クライアント、共通指示を変更したら、同じ評価セットと新しい holdout で回帰を確認します。
9. まとめ
- 公開研究には curated Skills の改善報告がありますが、条件によるばらつきと悪化もあり、GitHub Copilot の改善率としては転用できません。
- 利用可能、本文読込、手順利用、成果改善を分け、ファイル数や呼び出し回数を品質の代理にしません。
- 主 A/B は、現実的な共通指示を残して対象 Skills 一式へのアクセスだけを変えます。追加した知識と渡し方を考えるなら、情報をそろえた補助比較も設けます。
- 同じタスク・初期状態・モデル・権限・採点で反復し、Skill 未読込の B、未検証、障害、悪化ケースも記録します。
- 品質、費用、手戻り、不確実性、Skill 作成・保守負担まで含め、どの業務に有効かを判断します。
10. 参考情報
- About agent skills — GitHub Copilot での機能と対応クライアントの入口
- Adding agent skills for GitHub Copilot CLI — 配置、登録確認、有効設定、呼び出しの手順
- SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks — 本稿の数値と比較設計を確認する arXiv 公開版 v4
- SkillsBench — タスク構造、検証器、公開実験資料を調べるリポジトリ
- 🤖 Awesome GitHub Copilot — 評価対象候補を探せるコミュニティの Skills・カスタマイズ集
- GitHub Copilot を Markdown でカスタマイズする実践ガイド — 共通指示とタスク別の設定を整理する関連記事
- Eval Engineering とは — 生成 AI・AI エージェント評価を設計する（Part 1／全 2 回） — 評価データセット、評価器、失敗分類の設計を扱う関連記事
[^github-skills]: About agent skills — GitHub Docs（確認日: 2026-10-04）
[^adding-skills]: Adding agent skills for GitHub Copilot — GitHub Docs（確認日: 2026-10-04）
[^skills-spec]: Specification — Agent Skills（確認日: 2026-10-04）
[^vscode-skills]: Use Agent Skills in VS Code — Visual Studio Code（確認日: 2026-10-04）
[^skillsbench]: SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks — arXiv（確認日: 2026-10-04）
[^context-files]: Evaluating AGENTS.md:Are Repository-Level Context Files Helpful for Coding Agents? — arXiv（確認日: 2026-10-04）
[^agent-evals]: Demystifying evals for AI agents — Anthropic（確認日: 2026-10-04）
[^ai-usage]: Optimizing your AI usage to maximize efficiency and reduce cost — GitHub Docs（確認日: 2026-10-04）
[^cli-skills]: Adding agent skills for GitHub Copilot CLI — GitHub Docs（確認日: 2026-10-04）
この記事の執筆にあたり、AI の支援を受けています。
