Agent Skillsとは？Claude・Copilot・Codexの違いと実務での使い分けを解説

監修者_SD以外

監修者プロフィール

森下浩志

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

Agent Skillsとは何か

Agent Skillsは、AIエージェントに『この場面ではこの手順で動く』と教えるための再利用パッケージです。単発のプロンプトと違い、指示文だけでなく、補助ドキュメントや必要なスクリプトまでまとめて持てるので、同じ作業を何度も安定して再現しやすくなります。

たとえば『差分レビューの観点を固定する』『デプロイ前の確認手順を共通化する』『記事制作の流れを毎回同じ品質で回す』といった場面では、毎回長い指示を書き直すよりskillにしておいた方が運用しやすくなります。Claude CodeやCodexの公式docsも、skillsをタスク固有の能力や再利用ワークフローとして説明しています。

ここで最初に押さえたいのは、open standardという言葉を『どのツールでも完全に同じ動きをする』という意味で受け取らないことです。共通なのは主にSKILL.mdを中心にしたパッケージの考え方で、保存場所、常時読む指示ファイル、配布方法は製品ごとに違います。この記事では、その共通点と差分を分けて整理していきます。

最初の理解としては、次の3つだけ覚えておけば十分です。

なぜ今Agent Skillsなのか

今Agent Skillsを押さえる意味は、単に新機能だからではありません。2026年前半に入ってから、VS Code、GitHub Copilot、Codex、Claude Codeの各公式docsが、skillsを『再利用できる作業資産』としてはっきり打ち出し始めたからです。

流れを大づかみすると、2026年1月のVS Code 1.109でAgent Skillsやagent customizationが前面に出され、2月にはVS Code blogがskillsの一般提供を告知しました。6月時点ではGitHub Copilotがskillsの対応surfaceや保存先を整理し、Codexはskillsとpluginsの役割分担を明文化し、Claude CodeもCLAUDE.mdとskillsの使い分けを説明しています。

つまり今は、skillsが一部の人だけの実験機能ではなく、複数のエージェントで共通概念になり始めたタイミングです。その一方で、保存場所や自動読み込み、UIの見え方はまだ製品差分が大きく、communityでも混乱が続いています。だからこそ『流行っているらしい』の段階で止まらず、今のうちに比較して理解しておく価値があります。

特に実務では、次の3つが揃ったときにskillsの効果が大きくなります。

3ツールの違い

Claude・Copilot・Codexは、どれも『再利用できる手順資産としてのskill』を持っています。ただし、同じなのは考え方の中心だけで、実務で効いてくる違いはかなりあります。先に比較軸を決めておくと、このあと各ツールの説明を読みやすくなります。

見るべき軸は主に4つです。

ここで覚えておきたい結論はシンプルです。フォーマットは近づいていても、導入のしかたはツールごとに違うということです。とくに『open standardだから1つのフォルダをそのまま全ツールで共有できる』と考えると、後でハマりやすくなります。

次の3章では、Claude・Copilot・Codexを順番に見ながら、この4軸で何が違うのかを整理します。読者としては、まず自分が一番よく使うツールを基準に読み、そのあと他ツールとの差分だけを拾うと理解しやすいです。

① Claudeのskills

Claude Codeでは、毎回守ってほしい前提はCLAUDE.mdに置き、特定の作業でだけ使う長い手順はskillsに分けるのが基本です。たとえば文体、レビュー基準、禁止事項のようにセッション全体へ効かせたい内容はCLAUDE.md向きで、記事制作や障害切り分けのような段取りはskill向きです。

skillsに向いているのは、毎回同じ順で進めたいのに、都度プロンプトへ貼ると抜け漏れが出やすい作業です。Claudeの公式docsでも、skillは必要になった場面で読み込む拡張単位として扱われています。短い注意書きまで何でもskillに入れるより、長くて再利用したい手順だけを逃がした方が運用は安定します。

迷ったら判断基準はシンプルです。その指示が常に必要ならCLAUDE.md、特定タスクでだけ必要ならskillです。この分け方を先に決めておくと、skillの数が増えても管理しやすくなります。

② Copilotのskills

GitHub Copilotは、3ツールの中でも役割の分け方が多い側です。repository custom instructionsは常時の応答方針、prompt filesは再利用したい呼び出し文、agent instructionsはエージェントの前提、skillsは特定の作業をやり切るための専門手順という位置づけで見ると整理しやすくなります。

特に迷いやすいのは、prompt filesとskillsの違いです。短い依頼文を何度も呼ぶだけならprompt filesで足りますが、参照資料や段取り込みで再利用したいならskillsの方が向いています。Copilotのdocsも、skillsをspecialized task向けの拡張として案内しています。

実務では、まずcustom instructionsで全体ルールをそろえ、その上でレビュー、調査、リリース確認のような重い作業だけskillsへ切り出す形が扱いやすいです。全部をskillsへ寄せるより、役割を分けた方が保守しやすくなります。

③ Codexのskills

Codexは、役割の切り分けが比較的はっきりしています。AGENTS.mdは常時守る運用ルール、skillsは必要な作業能力、pluginsはそれらを配る仕組みと考えると混乱しにくくなります。毎回読むべき前提をskillsへ入れるのではなく、まずAGENTS.mdで土台をそろえるのが先です。

skills側には、コードレビュー、調査、記事制作のように手順が長く、再利用価値が高いタスクを置くのが向いています。Codexの公式docsでもskillsはtask-specific capabilitiesと説明され、pluginはskillsやツールを配布する単位として分けて扱われています。

つまりCodexでは、指示そのものと配布方法を分離して考えるのが重要です。個人で使うならまずAGENTS.mdと小さなskillで十分で、チーム配布や導入体験まで整えたくなった段階でpluginを検討すると無駄がありません。

導入の進め方

ここからは、比較で分かった差分を踏まえて、実際に導入するときの順番を整理します。

Agent Skillsを始めるときは、最初から立派な共通資産を作ろうとしない方がうまくいきます。先に常時指示とtask-specificな手順を分け、そのあと最小のSKILL.mdを1つ作り、最後に各ツールの保存場所へ合わせる順で進めると迷いが減ります。

逆に失敗しやすいのは、役割分担が曖昧なまま大量のskillを作ることです。これをやると、どれが常時ルールで、どれが場面別の手順なのか後から分からなくなります。まずは次の3ステップだけで十分です。

① 常時指示を分ける

最初にやるべきことは、常時指示とskillsの役割を分けることです。文体、禁止事項、レビュー方針、使う言語のように毎回守ってほしい内容は、AGENTS.mdやCLAUDE.md、Copilot custom instructionsの側へ置きます。

一方で、リサーチの進め方、障害調査の段取り、公開前チェックのように、ある場面でだけ必要になる手順はskillsに向いています。ここを混ぜると、skillを呼ばないと基本ルールが抜けたり、逆に常時ファイルが長くなりすぎて読まれにくくなったりします。

迷ったら『その指示は毎回必要か』で切ってください。Yesなら常時指示、Noならskill候補です。この判断を先に済ませるだけで、後からskillを増やしても構成が崩れにくくなります。

② 最小SKILL.mdで始める

最初のskillは、小さく作るのが正解です。いきなり複数ファイルや複雑な分岐を盛り込むより、descriptionと手順だけで成立する1作業を選ぶと、どこまで自動で呼ばれ、どこから手動説明が必要かをつかみやすくなります。

最小形のイメージは次のようなものです。

---
name: release-check
description: リリース前の確認手順をまとめたskill
---

1. 変更差分を確認する
2. 影響範囲を洗い出す
3. テスト結果を要約する

この段階では、完璧な共通化より『本当に再利用したい手順か』を確かめる方が重要です。1つ試して便利だと分かったら、その後に補助資料やscriptsを足す形で十分育てられます。

③ 共有は保存場所を分ける

open standardという言葉は便利ですが、期待の置き方を間違えると止まりやすくなります。実務で大事なのは、同じ考え方のskillを使い回すことであって、必ずしも1つのフォルダを全ツールで共有することではありません。

たとえばSKILL.md中心の構成は近くても、発見場所はCopilot、Codex、Claudeで差があります。だから運用としては、元になるskill資産を1か所で管理しつつ、各ツールが見に行く場所へ配置する発想の方が安全です。無理に完全共通ディレクトリへ寄せると、検出されない原因になります。

『同じフォーマットを複数の置き場へ配る』と考えると、open standardの意味を実務に落とし込みやすくなります。まずは手動配置でも十分で、定着してからsymlinkや同期スクリプトを考えれば足ります。

現時点の注意点

最後に、導入前に知っておきたいハマりどころを整理します。

skillsは公式docsで位置づけがかなり明確になってきた一方、実際の発見UIや検出挙動はまだ揺れる場面があります。communityでも『置いたのに出てこない』『pickerに表示されない』『どの保存先が有効か分かりにくい』といった声は続いています。ここは仕様そのものと、UX上の不安定さを分けて見るのが大切です。

まず信じるべき正本は公式docsです。そのうえで動かないときは、保存先、フォルダ名、SKILL.mdの配置、対応surface、アプリ更新や再起動の順で確認すると切り分けしやすくなります。community報告は参考になりますが、製品仕様の断定根拠としては使いすぎない方が安全です。

よくある質問

まとめ

最後に、実務で押さえるポイントだけを短くまとめます。

Agent Skillsは、Claude・Copilot・Codexで共通して『再利用できる作業手順』として育ってきています。ただし、常時指示ファイル、保存場所、配布方法までは共通ではありません。最初にこの差分を理解しておくと、open standardという言葉に振り回されにくくなります。

重要なのは次の3点です。

次にやることはシンプルです。自分が一番よく使うツールを1つ決めて、レビューや公開前確認のような身近な作業を1つだけskill化してみてください。小さく始めた方が、どこまで再利用できるかを早くつかめます。

比較で全体像をつかんだうえで1つ試せば、skillsは『便利そうな新機能』ではなく、実務資産として使える感覚に変わっていきます。