Agent Skillsとは？Claude・Copilot・Codexで再利用できるスキルの作り方と違いを解説

監修者_SD以外

監修者プロフィール

森下浩志

日本最大級のAI情報プラットフォーム「romptn ai」編集長。著書に「0からはじめるStable Diffusion」「0からはじめるStable Diffusion モデル・拡張機能集編」など、AmazonベストセラーのAI関連書籍を多数執筆。AIにおける情報の非対称性を解消するための社内研修や出張講義も行う。

Agent Skillsで何が変わる？

ここでは、Agent Skills を入れると何が楽になるのかを先に押さえます。

Agent Skills の価値は、毎回チャットで説明していた手順を SKILL.md に切り出し、必要な場面だけ読ませられることです。リリース前チェック、記事下書き、障害切り分けのような繰り返し作業を 1 本の手順書として残せるので、担当者や使うエージェントが変わっても再利用しやすくなります。

ただし、便利なのは「同じ文章を起点にしやすい」点であって、保存場所や呼び出し方まで完全に同じになるわけではありません。まず共通の core を作り、その上で Claude、Copilot、Codex ごとの差分だけを薄く足す設計にすると、手順が散らばりにくくなります。

先に知る役割分担

ここからは、情報をどこに置くと迷いにくいかを整理します。

最初に分けたいのは、常時効かせる前提 と 必要な時だけ読む手順 と 別の役割で動く実行者 の3層です。これを混ぜると、AGENTS.md に長い手順を書きすぎたり、逆に skill に毎回共通の注意書きまで詰め込んだりして、読み込みも保守も重くなります。

判断基準は単純です。毎回守らせたいルールは AGENTS.md 系、ある作業のやり方は skills、別人格や別権限で動かしたい時は custom agents に置きます。この順番で考えると、同じ内容を複数ファイルへ重複して書かずに済みます。

① AGENTS.md系の役割

AGENTS.md 系は、作業を始める前に読んでほしい前提を置く場所です。コード編集時の注意、ブランチ運用、レビュー観点のように、どの作業でも外してほしくないルールをまとめます。

逆に、長い操作手順をここへ詰め込むのは向きません。毎回全文を読む層に詳細手順まで混ぜると、本当に大事な共通ルールが埋もれるからです。AGENTS.md は「この repo でどう振る舞うか」、skills は「この作業をどう進めるか」と切り分けると、両方が読みやすくなります。

② skillsの役割

skills は、毎回は不要でも、特定の作業では深く効いてほしい手順書です。たとえば「リリース前チェック」「記事の下書き」「障害の一次切り分け」のように、流れと確認項目が決まっている仕事をまとめると相性が出ます。

scripts や references を一緒に置けるのも強みです。単なるプロンプト断片ではなく、手順、補助ファイル、実行コマンドをひとかたまりで再利用できるので、同じ作業を別のエージェントへ渡しても品質がぶれにくくなります。

③ custom agentsの役割

custom agents や subagents は、手順の再利用よりも 役割分担 に向く仕組みです。レビュー担当、調査担当、UI 担当のように視点や責務を分けたい時は、1 本の skill を大きくするより、実行者を分けた方が判断がぶれません。

見分け方は「同じ自分に手順を教えたいのか」「別の担当者として動かしたいのか」です。前者なら skills、後者なら custom agents です。この境界を先に決めておくと、instructions と skills と agents が重複しにくくなります。

3ツールの違いを見る

ここでは、同じ skill をどこまで共有できるのかを比較でつかみます。

portable なのは SKILL.md を中心にした考え方 であって、保存場所や起動導線まで完全一致するわけではありません。共通部分と差分を一度並べて見ると、導入時にどこで product-specific な調整が要るかが見えやすくなります。

この後は、各ツールごとの差分を 1 つずつ見ていきます。最初から全部を同じ挙動にそろえようとせず、まずは共通 core を作ってから差分を足す方が失敗しません。

① Claude Codeの特徴

Claude Code では、CLAUDE.md を常時読む前提にしつつ、長い手順は skills 側へ逃がす設計が取りやすいです。repo 全体の原則は CLAUDE.md に残し、検証フローやデプロイ手順のような重い作業だけ SKILL.md に切り出すと、共通ルールが埋もれません。

もう一つの特徴は、open standard の core を保ちながら、invocation control や subagent execution の拡張を重ねられる点です。つまり、共通 spec を土台にしつつ、Claude らしい分担や自動化を後から追加しやすい構造になっています。

② Copilotの特徴

Copilot は、skills を 1 つの画面だけで使う仕組みではありません。cloud agent、code review、CLI、app、VS Code の agent mode まで視野に入るので、同じ手順を複数 surface で回したい人ほど相性があります。

その代わり、最初に迷いやすいのが discovery path です。.github/skills、.claude/skills、.agents/skills のどこを起点にするかは、今の運用と共有相手で決める必要があります。加えて、repository 全体の方針は custom instructions、細かい作業手順は skills と分ける意識を持つと、設定が肥大化しません。

③ Codexの特徴

Codex では、skills は reusable workflow をまとめる形式として扱われます。つまり、単発の便利プロンプトではなく、何度も回す作業を保存して呼び戻す前提が強く、CLI、IDE extension、Codex app をまたいで同じ発想で育てやすいのが特徴です。

一方で、作業前に読む project guidance は AGENTS.md 側に置く考え方がはっきりしています。repo 全体の原則と task-specific な手順を分けやすいので、まず AGENTS.md で土台を固め、重い手順だけを skill 化する流れにすると運用が崩れにくくなります。

最小のSKILL.mdを作る

ここからは、最初の 1 本をどう作るかに絞って進めます。

おすすめは、いきなり大作を目指さず、毎週くり返す確認作業を 1 つだけ skill 化することです。まず共通の型を書く、次に各ツールの置き場所へつなぐ、最後に本当に呼ばれるか確かめる。この3段階で考えると、portable core と tool-specific 差分を自然に分けられます。

最初の題材は、lint とテストの確認、PR 前チェック、記事公開前の見直しのような、手順が安定していて結果を比べやすい仕事が向いています。成功体験を 1 本作ってから、次の skill を増やす方が定着しやすいです。

① 共通の型を書く

最小構成は、何をする skill かが一読で伝わる名前と説明、そして実際の手順です。最初から大量の補助ファイルを抱え込む必要はなく、まずは短い説明と 3〜5 手順で十分です。

---
name: release-check
description: リリース前に差分確認とテスト実行を行う手順
---

手順:
1. 変更ファイルを確認する
2. テストを実行する
3. 失敗時はログを要約して原因候補を並べる

script や reference が必要になったら後から足せます。先に大事なのは、description を読んだ時に「どの場面で呼ぶ skill か」が明確になっていることです。

② 各ツールに配置する

同じ SKILL.md を使い回したくても、置き場所はツールごとに見直しが必要です。Claude だけで試すなら .claude/skills、GitHub や Copilot を中心に回すなら .github/skills、複数エージェントで共有したいなら .agents/skills のように、運用の主戦場から決めると迷いません。

おすすめは、canonical な skill 置き場を 1 つ決めて、必要に応じて sync や symlink で配る形です。手動で同じファイルを複製し続けると、description だけ古い、手順だけ違う、といった事故が起きやすくなります。

③ 呼び出し方を確かめる

配置しただけで満足せず、本当に見つかるかを必ず確認します。description が曖昧だと、存在していても relevant な場面で拾われにくいので、呼びたい作業名や判断条件を短く入れておく方が安全です。

確認の仕方はツールごとに違っても、見るべき点は共通です。想定した作業で skill が候補に出るか、読ませた後の手順が長すぎないか、共通ルールと衝突していないか。この3点が通れば、次からは同じ作業を毎回説明し直す負担がかなり減ります。

共有時の注意点

ここでは、複数ツールで使い回す時に詰まりやすい点をまとめます。

一番の落とし穴は、「open standard だから全部同じように動くはず」と考えることです。実際には discovery path、always-on guidance の扱い、agent 拡張の有無が違うので、共通化するほど 差分をどこへ隔離するか が大事になります。

運用では、core の SKILL.md は provider-neutral に保ち、各ツール固有の注意だけを薄い補助ファイルや同期設定へ逃がす形が安定します。共有相手が増えるほど、正本を 1 つに決める、更新経路を 1 本に絞る、差分は短く保つ、の3つを守った方が保守しやすいです。

Agent SkillsのFAQ

まとめ

最後に、最初の1本を作る時の判断軸だけを残します。

次にやることは、普段くり返す作業を 1 つ選び、name と description を持つ最小の SKILL.md を作ってみることです。Claude、Copilot、Codex のどれで先に試すかを 1 つ決めて検証すれば、どこまで共通化できるかもすぐ見えてきます。

共通 core と tool-specific 差分を分けて考えれば、手順書は増えても管理は複雑になりません。複数エージェントを併用するほど、この切り分けが効いてきます。