GitHub CopilotのAgent Skillsとは？使い方・作り方・活用事例を徹底解説

GitHub Copilotは、エージェントに業務フローを教え込ませるための新機能「Agent Skills」を導入しました。 <Br>これは、SKILL.mdやスクリプトを1つのフォルダにまとめることで、Copilot coding agentやCLI、VS Codeのエージェントモードに対して、リポジトリ固有の手順や運用ルールを守らせながらタスクを実行させる仕組みです。

本記事では、オープンなスキル仕様に基づくAgent Skillsの基本概念から、SKILL.mdを用いた具体的な作成手順、そしてCI障害調査やコードレビュー観点の標準化といった実務での活用事例までを体系的に解説します。

GitHub CopilotのAgent Skillsとは？

Agent Skillsは、Anthropicが提唱した**オープンなスキル仕様「Agent Skills standard」**に基づく、「エージェントに業務フローを教えるためのスキルフォルダ」です。

GitHub Copilotでは、このAgent Skillsを使うことで、Copilot coding agent や GitHub Copilot CLI、VS Codeのエージェントモードに「特定タスクのやり方」を教え込むことができます。

ひとつのスキルは、次のような要素で構成されます。

• どんなタスクを、どんな手順で行うかを書いたMarkdown（SKILL.md）
• 必要に応じて呼び出すスクリプト（例：PythonやShell）
• 参考資料・テンプレートファイル（テスト用設定、README、雛形ドキュメントなど）

エージェントは、該当リポジトリに用意されたスキルを状況に応じて読み込み、GitHub Actionsの障害調査やログ解析、共通のリリース手順などを、毎回同じ流れで実行できるようになります。

GitHub CopilotでAgent Skillsが使えるチャネル・料金プラン

ここでは、GitHub Copilotのどの機能からAgent Skillsを使えるのかと、ざっくりした前提プランを整理します。

実務的には、個人なら Pro / Pro+、組織なら Business / Enterprise を前提にしておくと考えると分かりやすいです。

• Agent Skillsが動くチャネル

  • Copilot coding agent
  • GitHub Copilot CLI
  • Visual Studio Code Insiders のエージェントモード（Stable版は順次対応予定）
    
    

• 利用可能プラン

  • coding agent / Copilot CLI:Pro / Pro+ / Business / Enterprise で利用可能
  • VS Code Insiders のエージェントモード:Copilotライセンスがあれば利用可能だが、Freeは月50リクエスト程度の上限があるため「検証用途」寄り

【関連記事】
GitHub Copilotの料金プラン一覧！個人・法人プランの違いと選び方を解説

Copilot coding agent

Copilot coding agentは、GitHub.comやVS Codeなどから利用できる「会話型の開発エージェント」です。

Agent Skillsは、このcoding agentが扱えるスキルのひとつとして動作し、PRレビューやリファクタリング、設計相談などの文脈の中で、リポジトリ固有の手順書を参照しながら動きます。

使いどころのイメージ

• PRレビュー時に「このリポジトリ用のレビュー観点スキル」を呼び出す
• 新機能の実装時に「このプロジェクトの標準構成スキル」を使って雛形を用意してもらう
• 設計相談の流れの中で、「このサービスでの過去のベストプラクティス」をスキル経由で引き出す

GitHub Copilot CLI

GitHub Copilot CLIは、ターミナルからコマンドベースでCopilotを操作するためのインターフェースです。

Agent Skillsは、CLIからも利用できるため、テスト・ビルド・ログ調査などの定型フローをスキルとしてまとめておくと相性が良いです。

使いどころのイメージ

• 「このリポジトリに対して、いつものテスト→Lint→ビルドの流れを実行して」
• 「最近のGitHub Actions失敗ログをまとめて要約して、よくある原因を分類して」
• 「release-checklistスキルに沿って、本番デプロイ前の確認項目を洗い出して」

Visual Studio Code（エージェントモード）

執筆時点では、Agent Skills（オープン標準）として利用できるのは VS Code Insiders のエージェントモードです（Stable版は順次対応予定）。

「.github/skills」配下に置いたスキルはVS Code Insidersが検出し、エージェントが必要に応じて参照します。

使いどころのイメージ

• エディタ内から「このスキルを使ってテストコードを書いて」と依頼し、SKILL.mdで定義した観点に沿ってテストを生成してもらう
• 「このプロジェクトの標準構成に合わせて、新しいサービス／モジュールを追加して」と指示し、雛形ファイル一式を用意してもらう
• コードや設定ファイルを開いたまま、「このリポジトリのガイドラインスキルを前提にレビューして」といった形で、ローカル文脈＋スキルを組み合わせて使う

Agent Skillsの仕組み：SKILL.mdとフォルダ構成

GitHub Copilotで使われるAgent Skillsは、基本的に「SKILL.mdファイルを含むフォルダ」として定義します。

現時点では、Agent Skillsはリポジトリ単位でのみ作成できます（組織全体・エンタープライズ全体で共有するスキルカタログは、今後の拡張が予定されています）。
そのため、まずは「このリポジトリにだけ効くスキル」として設計し、必要に応じて他リポジトリにコピーしていく運用が前提になります。

:::messgae
具体的な作り方やコマンド例は、「Agent Skillsの作り方：GitHub Copilot編」で詳しく解説します。
:::

SKILL.mdの役割

「SKILL.md」は、スキルの中心となる定義ファイルです。
ここに、以下の要素をまとめておきます。

• スキルの識別子（name）
• スキルの説明（description）
• 必要であればライセンスなどのメタ情報
• 実際の手順書（本文）

Copilotは、SKILL.mdの冒頭（フロントマター）に書かれたnameとdescriptionだけを先に読み込み、ユーザーのリクエストと照らし合わせて「どのスキルを使うべきか」を判断します。

実際にスキルを使うと決めたタイミングで、本文や関連リソースを詳しく読む、という二段階構造になっています。

スキルフォルダの基本構成

リポジトリ内では、Agent Skillsは次のようなフォルダ構成で置くのが基本です。

.github/
  └── skills/
      └── github-actions-failure-debugging/
          ├── SKILL.md
          ├── scripts/
          │   └── summarize_logs.py
          ├── references/
          │   └── actions-guidelines.md
          └── assets/
              └── example-log-snippet.txt

ポイントは次のとおりです。

• スキルは**「.github/skills/スキル名」**配下に置く
• スキル名のディレクトリは、nameフロントマターと揃えておくと分かりやすい
• scripts/ 以下に、ログ解析や変換処理などのスクリプトを置ける
• references/ に、長めの仕様書やルールを分離しておける
• assets/ には、テンプレートやサンプルファイルなどの補助リソースを置ける

GitHubの仕様では、「.github/skills」に加えて .claude/skills」ディレクトリもサポートされており、Claude Skills用に用意したスキル構造を、Copilot側でも検出できるようになっています。

ただし、新しく作るスキルは .github/skills 配下に置くことが推奨されており、.claude/skills は主に既存のClaude Skills資産を流用するための互換ディレクトリという位置づけです。

このため、「Claude CodeとGitHub Copilotの両方で共有したいスキル」は、同じフォルダ構成・SKILL.md形式で持つのが基本方針になります。

Agent Skillsの作り方：GitHub Copilot編

ここからは、実際にGitHub Copilot向けのAgent Skillsを作るときの基本フローを整理します。

前提：利用プランと環境

Agent Skillsをフルに活用するには、少なくとも次のような前提が必要になります。

• GitHub Copilot Pro / Pro+ / Business / Enterprise など、Copilot coding agentやCopilot CLIが利用できるプラン
• CLIやVS Codeなど、エージェント機能を有効にした開発環境
• スキルを配置したいリポジトリへの書き込み権限

個人検証ならPro / Pro+、チーム導入ならBusiness / Enterpriseで触っておくとイメージが掴みやすいです。

ステップ1：スキル用ディレクトリを作る

今回は、「GitHub Actions障害調査スキル」を例に手順を説明していきます。

まず、対象リポジトリのルートに「.github/skills」ディレクトリを作成します。

mkdir -p .github/skills/github-actions-failure-debugging

その上で、作りたいスキルごとにサブディレクトリを切ります。

• 「.github/skills/github-actions-failure-debugging」
• 「.github/skills/release-checklist」
• 「.github/skills/log-analysis」

フォルダ名はスキルのIDと揃えておくと、後から見返したときに管理しやすくなります。

ステップ2：SKILL.mdを書く

次に、各スキルフォルダの中に「SKILL.md」を作成します。

---
name: github-actions-failure-debugging
description: Help debug failing GitHub Actions workflows in this repository. Use this skill when the user asks to investigate or fix failing CI runs.
---

# GitHub Actions Failure Debugging

## Purpose
Help the user debug failing GitHub Actions workflows for this repository, following a consistent investigation process.

## Inputs
- The branch, pull request, or workflow run to investigate
- Optional: specific error messages or job names to focus on

## Outputs
- A summary of likely root causes
- A list of suggested fixes or next steps
- Links to the most relevant workflow runs and logs

## Steps
1. Identify the most recent failing workflow runs related to the user’s request.
2. Inspect the failing jobs and extract key error messages.
3. Group failures by common patterns (configuration issue, dependency problem, flaky test, etc.).
4. Propose concrete next steps the user can take to reproduce and fix the issue.
5. If appropriate, draft changes to workflow files or documentation.

## Style guidelines
- Explain findings in plain language before showing log excerpts.
- Prefer bullet points and short paragraphs over long error dumps.
- Highlight any risky changes or destructive operations explicitly.

## Examples
- "Why is the CI failing on my latest pull request?"
- "Help me debug the nightly workflow that has been failing since yesterday."

押さえておきたいポイントは次のとおりです。

• フロントマターのnameは、英小文字＋ハイフンで短く・一意にする
  
  

• descriptionには、「何をするスキルか」「どんな依頼のときに使うか」を1〜2文で具体的に書く
  
  

• 本文は

  • Purpose
  • Inputs / Outputs
  • Steps
  • Style guidelines
  • Examples

のように見出しを分けて構造化しておくと、エージェントにも人間にも読みやすい「手順書」になります。

ステップ3：スクリプトや補助リソースを追加する

SKILL.mdだけでも、テキストベースのスキルとしては十分成立します。
より高度な自動化をしたい場合は、scriptsやreferencesフォルダを使ってスキルを拡張します。

.github/skills/github-actions-failure-debugging/
├── SKILL.md
├── scripts/
│   └── summarize_job_logs.py
└── references/
    └── actions-guidelines.md

• scripts
  ログ要約、テストの再実行、設定ファイルの検査などを行うスクリプトを置く
  
  

• references
  チーム独自のガイドラインや「よくあるトラブルシューティング手順」をMarkdownでまとめておく

エージェントは、必要に応じてこれらのファイルを読み込みつつ、SKILL.mdで定義した手順に沿って処理を進めます。

ステップ4：リポジトリにコミットして、Copilotから呼んでみる

スキルフォルダができたら、通常のコードと同じようにリポジトリにコミットします。

git add .github/skills
git commit -m "Add GitHub Actions failure debugging skill"
git push origin main

そのうえで、Copilot coding agentやCopilot CLIから、次のように試してみます。

• 「このリポジトリのgithub-actions-failure-debuggingスキルを使って原因を調べて」
• 「最新のワークフロー失敗の概要と、よくある原因候補を教えて」

最初は挙動を観察しながら、SKILL.mdの説明やStepsを微調整していくと、エージェントとスキルの“相性”がだんだん見えてきます。

スキル設計の粒度とアンチパターン

実際に運用してみると、次のようなつまずきがよく起きます。

• 1つのスキルが大きすぎて「結局なんでも屋」になってしまう
  → 目的やInputs/Outputsが2〜3種類に増えてきたら、スキルを分割するサインです。
  
  

• 逆に細かく分けすぎて「どのスキルを呼べばいいか分からない」状態になる
  → 人間の作業単位で考えたときに「普段この塊で頼んでいるか？」を基準に見直します。
  
  

• SKILL.mdを自然文だけで書いてしまい、エージェントにも人間にも意図が伝わりにくい
  → Purpose / Inputs / Outputs / Steps / Examples など、見出しを決めて構造化するのがおすすめです。

最初は「人間に説明するときに、そのまま渡したい手順書」くらいの粒度で作ってみて、運用しながら統合・分割していくと失敗しにくくなります。

GitHub Copilot Agent Skillsでできること：代表ユースケース

Agent Skillsは、「人間の開発フローの塊」をエージェントに教えるための仕組みです。

ここでは、GitHub Copilotならではの代表的なユースケースを3つのパターンに分けて見ていきます。

1. GitHub Actionsの障害調査・ログ解析

もっとも分かりやすいのが、CI/CDパイプラインの障害調査フローをスキル化するパターンです。

• 「GitHub Actionsが落ちたとき、いつもこの順番で確認する」という手順
• よくある失敗パターンと、確認すべきログ箇所
• 再現・修正・再実行までの流れ

といった手順を「SKILL.md」に落とし込み、必要に応じてログ解析用スクリプトをscriptsフォルダに置いておきます。

このスキルがあると、たとえば次のようなことをエージェントに任せやすくなります。

• 「直近で落ちているWorkflowを洗い出して、原因をまとめて」
• 「この失敗ログから、設定ミスとコードバグのどちらが疑わしいか教えて」

CI担当者の暗黙知をスキルとして共有すれば、新メンバーでも同じステップで障害調査ができるようになります。

2. コードレビュー観点・コーディング規約の標準化

次に、コードレビューやコーディング規約の観点をスキル化するパターンです。

• リポジトリごとのスタイルガイド
• 「このプロジェクトでは、この点を必ず見る」というレビュー観点
• セキュリティ・パフォーマンスなどのチェックリスト

をSKILL.mdに整理しておくことで、Copilot coding agentに「このリポジトリではこうレビューする」という前提を持たせられます。

エージェントに対して、

• 「このPRを、このリポジトリのレビュー観点スキルに沿ってチェックして」
• 「セキュリティ観点だけ先に洗い出してほしい」

といった依頼をすると、人がやっているレビュー観点の一部を肩代わりさせることができます。

3. プロジェクトテンプレート・スキャフォールドの自動生成

3つ目は、「新サービス追加や新機能実装時の“お決まりの初期セットアップ”」をAgent Skillsにしてしまうパターンです。

• 新しいマイクロサービスを追加するときのフォルダ構成
• 最低限のCI設定（テスト・Lint・ビルド）
• ベースとなる設定ファイル（Dockerfile、環境設定、README雛形など）

をSKILL.mdおよびテンプレートファイルとして定義しておきます。

このスキルを使うと、たとえば次のような対話が可能になります。

• 「このリポジトリに、新しいバックエンドサービスをいつもの構成で追加して」
• 「標準テンプレートに従って、新しい機能モジュールのディレクトリを作って」

プロジェクトごとの「いつもの始め方」をスキルに落とすことで、属人化しがちな初期セットアップを一定の品質で繰り返せるようになります。

【組織向け】GitHub CopilotにおけるAgent Skillの導入フロー

Agent Skillsをいきなり全社展開しようとすると、運用・セキュリティ・教育のコストが重くなりがちです。

ここでは、個人 → 部門 → 全社カタログという3段階で、現実的な導入ステップを整理します。

個人・小規模チームでの試行フェーズ

まずは、影響範囲の小さいリポジトリやチームを対象に、「よく発生する作業」を1〜2個だけスキル化してみる段階です。
日頃「毎回同じ手順でやっているな」と感じる作業から着手すると、効果が見えやすくなります。

• 例：
  • 「このサービスのテスト→Lint→ビルドの標準フロー」
  • 「このリポジトリ専用のレビュー観点チェック」
  • 「よくあるCI失敗を調べるための手順」

このフェーズでは、厳密な数値評価よりも、どの作業がスキル化と相性が良いか、どのくらいの粒度・記述量だと運用しやすいかといった感触をつかむことが目的です。
作業時間の短縮感や、新メンバーでも同じ手順を踏めるようになったかどうかをざっくり確認しておくと、次のステップに進む判断材料になります。

部門単位でのPoC・パイロット導入

個人・小規模チームでの手応えが見えてきたら、次は特定部門（例：開発部の一チーム）を対象にしたPoCフェーズに進みます。
ここでは、「スキルを前提にした開発フロー」が部門レベルでも機能するかを検証します。

• 対象業務を2〜3パターンに絞る（CI、リリース、レビューなど）
• スキル設計のひな形（SKILL.mdテンプレート）を作る
• 成果指標（作業時間、エラー件数など）をざっくり決めておく

この段階では、対象業務を絞りつつ、SKILL.mdのテンプレートやレビューの回し方など、「運用ルール」を試行錯誤するフェーズと位置づけると進めやすくなります。
PoCを通じて、どのタイプの業務がスキル化で効果を出しやすいか、スキルの粒度をどこに置くと現場の負担が少ないか、といった自社なりのパターンを見極めていきます。

全社展開時の標準スキルカタログ運用

PoCで効果と運用パターンのあたりがついたら、共通スキルを資産として管理する「標準スキルカタログ」のフェーズに進みます。
開発組織全体で再利用できるスキルを整理し、継続的にメンテナンスしていく体制づくりが中心です。

• 業務領域ごと（開発基盤 / プラットフォーム / 各プロダクトなど）に標準スキルを整理
• スキルごとにオーナー（メンテナー）を決める
• 新入社員やジョインメンバー向けに「スキルの使い方トレーニング」を組み込む

ここまで整うと、Agent Skillsは単発の仕組みではなく、**「開発組織の標準フローを配布するプラットフォーム」**として機能するようになります。
プロジェクトごと・チームごとのバラつきを抑えつつ、Copilotエージェントを通じて、一定水準の開発プロセスを再現しやすくなります。

Agent SkillsとMCPの関係：どう使い分けるか？

ざっくり言うと、Agent SkillsとMCPは次のような役割分担になっています。

• Agent Skills
  → 「このリポジトリでは、こういう順番でこう作業する」という
  人間の開発フローを標準化する仕組み（手順書・チェックリスト側）
  
  

• MCP（Model Context Protocol）
  → データベース・SaaS・社内APIなど、
  外部システムへの接続やツール呼び出しを標準化する仕組み（コネクタ・ツール側）

たとえば次のような組み合わせが典型です。

• MCPで「社内CIシステムのAPI」や「オンプレJira」「社内Wiki」をツールとして公開しておき、
• Agent Skillsで「障害調査の手順」や「リリースチェックリスト」をSKILL.mdにまとめる

こうしておくと、

• MCP側： 「どの情報・どのツールにアクセスできるか」
• Agent Skills側： 「どの順番で何を確認し、どう対応するか」

をきれいに分離して設計できます。
結果として、「ツールの増減や変更」はMCP側で、「作業フローの改善」はAgent Skills側で、それぞれ独立に進めやすくなります。

【セキュリティと権限設計】Agent Skillsを「コードと同じ扱い」にする

Agent Skillsは、リポジトリ内のスクリプトや設定ファイルを実行・参照する前提なので、実質的にはコードやIaCと同じ扱いが必要です。

ここでは、「リポジトリ内での基本ルール」と「組織全体での権限設計」の2つの視点でポイントを整理します。

リポジトリ内での基本ルール

個々のスキルについては、少なくとも次のようなガイドラインを決めておくと安全です。

• 危険なファイル操作（削除・強制上書きなど）をスキル内に書かない
• 外部サービス連携や機密データアクセスは、別途ポリシーを決める
• 本番環境向けのスキルは、コードレビューと同様のレビュー／承認フローを通す
• 公開リポジトリのスキルをそのまま持ち込まず、「中身を読んでから」導入する

スキルは「人間の手順書＋スクリプト」のセットなので、誤った記述や過剰な権限が入ると、そのままエージェント経由で広く再利用されてしまいます。

実際のコードと同じレベルでレビュー対象に含める前提で設計しておくと安心です。

組織全体での権限設計

組織としてCopilotを導入している場合は、リポジトリ単位のルールに加えて、「誰がどこまでスキルを置けるか」という権限設計も重要になります。

• 誰がどのリポジトリにどのスキルを置いてよいか
• 危険な操作を含むスキルをどう管理するか（専用リポジトリに分離する、承認フローを必須にする など）

これらをセキュリティチームやプラットフォームチームと連携しながら決めておくと、Agent Skillsを安心して共有しつつ、意図しない操作や権限エスカレーションのリスクを抑えやすくなります。

よくある疑問とハマりポイント

最後に、Agent Skillsを試すときによく出てくる疑問と、ハマりやすいポイントを簡単にまとめます。

Q1. SKILL.mdを書いたのに、エージェントがスキルを使ってくれません

次のような点を確認してみてください。

• name と description が、スキルの用途を十分に表しているか
• ユーザーのプロンプトに、descriptionと関連するキーワードが含まれているか
• スキルフォルダの場所が正しいか（.github/skills/スキル名/）
• リポジトリにコミットされているか

テスト時は、「このリポジトリのgithub-actions-failure-debuggingスキルを使って〜して」と明示的にスキル名を指定すると挙動を把握しやすくなります。

Q2. Claude Skillsと完全に同じフォルダを、そのままCopilotでも使えますか？

SKILL.md＋フォルダ構成という大枠は共通ですが、

• スキルの配置場所（.github/skills / .claude/skills）
• 実行されるスクリプトの環境（利用できるライブラリやツール）
• それぞれのエージェントが得意とするタスク

などには差分があります。

「構造は共有できるが、細部の挙動はツールごとに検証が必要」というイメージで捉えておくと安全です。

Q3. セキュリティ的に注意すべき点は？

Agent Skillsは、リポジトリ内のスクリプトや設定ファイルを実行・参照する前提なので、

• 危険なファイル操作（削除・強制上書きなど）をスキル内に書かない
• 外部サービス連携や機密データアクセスは、別途ポリシーを決める
• 本番環境向けのスキルは、コードレビューと同様のレビュー/承認フローを通す

といった観点が重要になります。
特に、組織としてCopilotを導入している場合は、セキュリティチームやプラットフォームチームと連携しながらルールを決めるのがおすすめです。

まとめ：Agent Skillsで「いつもの開発フロー」をエージェント化する

GitHub CopilotのAgent Skillsを使うと、単なるコード補完や自然言語チャットを超えて、「このリポジトリではこうやって開発する」という一連の流れをエージェントに覚えさせられるようになります。

• CI障害調査
• コードレビュー観点の標準化
• 新サービス追加時のスキャフォールド
• プロジェクト固有のガイドライン適用

といった業務を、SKILL.md＋スクリプト＋テンプレートのセットとしてスキル化しておけば、「誰がやっても、だいたい同じクオリティの作業が、Copilot経由で再現できる」状態に近づけます。

まずは小さなスキルを1つ作ってみて、「この作業、Agent Skillsにしておくと楽だな」と感じるパターンを少しずつ増やしていくところから始めてみてください。