AIコーディングアシスタントを使っていて、「毎回同じ指示を書くのが面倒」「もっと的確に動いてほしい」と感じたことはないでしょうか。筆者自身、Claude CodeやGemini CLIを日常的に使う中で、プロンプトの再利用性に限界を感じていました。たとえば「このプロジェクトではTypeScriptのstrictモードを使う」「テストはVitestで書く」といった前提条件を、新しい会話を始めるたびに伝え直す手間は想像以上にストレスです。そんな課題を解決してくれるのが、GitHubで31,000スター以上を獲得しているオープンソースライブラリ「antigravity-awesome-skills」です。
antigravity-awesome-skillsとは何か
antigravity-awesome-skillsは、AIコーディングアシスタント向けの再利用可能なSKILL.mdプレイブックを1,370以上収録したインストール可能なGitHubライブラリです。対応ツールはClaude Code、Cursor、Codex CLI、Gemini CLI、Google Antigravity、GitHub Copilotなど多岐にわたります。
ここで言う「スキル」とは、エージェントが特定のタスクを実行する際に読み込む構造化された指示書のことです。たとえばデータベースマイグレーションの手順、セキュリティレビューの観点、テストコード生成の規約など、チームのベストプラクティスをSKILL.mdファイルとして定義します。エージェントはタスクに応じて必要なスキルを動的にロードし、汎用的なテキスト生成器から特定領域の専門家へと変わります。
従来のプロンプトテンプレートとの違いを具体的に挙げると、まず粒度の設計が異なります。一般的なプロンプトテンプレートは「Reactコンポーネントを作って」のような大まかな指示が多いのに対し、スキルは「Reactコンポーネント作成時にはカスタムフックを分離し、Props型をexportし、Storybookファイルを併設する」といったレベルまで手順が構造化されています。また、前提条件と制約の明示が組み込まれている点も特徴的です。どのような環境で使うか、何をしてはいけないかが明記されているため、エージェントが文脈を誤解するリスクが大幅に下がります。
さらに見逃せないのが**合成可能性（コンポーザビリティ）**です。スキルは単体で機能するだけでなく、複数のスキルを組み合わせて使うことが前提に設計されています。たとえば「Next.jsルート設計スキル」と「Supabase連携スキル」と「セキュリティレビュースキル」を同時にロードすれば、セキュリティを考慮したデータフェッチ付きのルート実装を一度の依頼で生成できます。プロンプトテンプレートでは複数の観点を一つのプロンプトに詰め込む必要があり、長くなるほどエージェントの注意が分散しがちですが、スキルはそれぞれが独立したファイルとして構造化されているため、組み合わせても指示の精度が落ちにくいのです。
最初にこの仕組みを知ったとき、正直なところ「ただのプロンプト集では」と思っていました。しかし実際に導入してみると、スキルの粒度や構造化の工夫が一般的なプロンプトテンプレートとは一線を画しており、認識を改めさせられました。
導入手順と基本的な使い方
導入はnpmのnpxコマンド一つで完了します。以下に主要ツール別のインストールコマンドをまとめました。
| 対象ツール | インストールコマンド |
|---|---|
| 全ツール共通（デフォルト） | npx antigravity-awesome-skills |
| Claude Code | npx antigravity-awesome-skills --claude |
| Cursor | npx antigravity-awesome-skills --cursor |
| Gemini CLI / Antigravity | npx antigravity-awesome-skills --gemini |
| Codex CLI | npx antigravity-awesome-skills --codex |
ツール固有のフラグを指定すると、そのツールが参照するスキルディレクトリに直接配置されます。たとえばGoogle Antigravityの場合は.agent/skills/ディレクトリ、Claude Codeの場合は.claude/skills/ディレクトリです。
実際にClaude Codeで試した際の流れを紹介すると、プロジェクトのルートディレクトリでnpx antigravity-awesome-skills --claudeを実行すると、数秒で.claude/skills/配下にスキルファイルが展開されます。その後Claude Codeを起動すれば、エージェントがスキルを自動的に認識し、関連するタスクを依頼した際にスキルの内容に沿った出力を返してくれるようになります。特別な設定ファイルの編集やAPI連携は不要です。
インストール後は、ロールベースの「バンドル」から始めるのが効率的です。フロントエンド開発者向け、バックエンド開発者向け、DevOpsエンジニア向けなど、職種に応じた推奨スキルセットがあらかじめ用意されています。同じように「どのスキルから入れればいいのか」と悩んでいる方も多いのではないでしょうか。筆者もバンドルから始めて、必要に応じて個別スキルを追加していく方法が最も無理のない進め方だと感じました。
インストール後の確認とディレクトリ構成
インストールが正しく完了したかどうかは、以下のコマンドで確認できます。
# Claude Codeの場合、スキルファイルの一覧を確認
ls -la .claude/skills/
# Gemini CLI / Antigravityの場合
ls -la .agent/skills/
# Cursorの場合
ls -la .cursor/skills/たとえばClaude Codeでインストールした場合、ディレクトリ構成は以下のようになります。
.claude/
└── skills/
├── development/
│ ├── code-review.md
│ ├── refactoring.md
│ └── typescript-strict.md
├── testing/
│ ├── unit-testing.md
│ └── integration-testing.md
├── security/
│ ├── owasp-review.md
│ └── dependency-audit.md
└── infrastructure/
├── terraform-best-practices.md
└── docker-optimization.mdカテゴリごとにサブディレクトリで整理されているため、不要なスキルを個別に削除したり、特定カテゴリだけ残したりする運用もしやすい構成です。もし特定のカテゴリだけインストールしたい場合は、バンドル指定を活用します。
# セキュリティ関連スキルのみインストール
npx antigravity-awesome-skills --claude --bundle security
# フロントエンド開発向けバンドル
npx antigravity-awesome-skills --claude --bundle frontend.gitignoreとスキルファイルの管理方針
導入時に意外と迷うのが、スキルファイルをGitリポジトリに含めるかどうかという点です。チーム共通のスキルはリポジトリにコミットして全員で共有し、個人の好みに依存するスキルは.gitignoreに追加してローカルのみで管理する、という使い分けが実務上スムーズでした。具体的には、コーディング規約やアーキテクチャに関するスキルはリポジトリに含め、エディタの操作支援やコミットメッセージの文体に関するスキルは個人管理としています。この境界線を最初に決めておくだけで、後々の運用トラブルがかなり減ります。
.gitignoreに追加する場合の記述例はこちらです。
# 個人用スキルは除外し、チーム共有スキルのみコミット
.claude/skills/personal/
.cursor/skills/personal/スキルのカテゴリと活用シーン
収録スキルは以下の6領域に分類されています。それぞれの領域で具体的にどのような場面で威力を発揮するか、実務での活用シーンとともに整理しました。
| カテゴリ | 主な内容 | 活用シーンの例 |
|---|---|---|
| Development | コーディング規約、アーキテクチャ設計、リファクタリング | 新規機能実装時のコード品質担保 |
| Testing | テスト戦略、カバレッジ基準、テストコード生成 | CI/CDパイプラインのテスト自動化 |
| Security | 脆弱性スキャン、セキュリティレビュー、依存関係監査 | リリース前のセキュリティチェック |
| Infrastructure | IaC、デプロイメント、監視設定 | クラウド環境の構築・運用 |
| Product | 要件定義、ユーザーストーリー、仕様書作成 | プロダクト企画フェーズの文書化 |
| Marketing | コンテンツ生成、SEO最適化、分析 | 技術ブログやドキュメントの作成 |
各カテゴリの具体的な活用例
Developmentカテゴリでは、たとえば「Next.js App Routerのルート設計スキル」を読み込ませると、Server ComponentとClient Componentの使い分け、データフェッチの配置場所、レイアウトの入れ子構造について一貫した方針でコードを生成してくれます。プロジェクト途中からジョインしたメンバーが「既存のコードと異なるパターンで実装してしまう」という問題は多くのチームで経験があるかと思いますが、スキルで設計方針を共有しておけばエージェント経由で統一感のあるコードが出力されます。
たとえば、エージェントにAPIルートの実装を依頼する場合、スキルが適用されていると以下のような一貫した構成で生成されます。
// スキル適用後のエージェント出力例
// app/api/users/route.ts
import { NextRequest, NextResponse } from 'next/server'
import { z } from 'zod'
import { createClient } from '@/lib/supabase/server'
// バリデーションスキーマを先頭で定義（スキルの規約に準拠）
const createUserSchema = z.object({
name: z.string().min(1).max(100),
email: z.string().email(),
})
export async function POST(request: NextRequest) {
try {
const body = await request.json()
const validated = createUserSchema.parse(body)
const supabase = await createClient()
const { data, error } = await supabase
.from('users')
.insert(validated)
.select()
.single()
if (error) {
return NextResponse.json({ error: error.message }, { status: 400 })
}
return NextResponse.json(data, { status: 201 })
} catch (e) {
if (e instanceof z.ZodError) {
return NextResponse.json({ error: e.errors }, { status: 422 })
}
return NextResponse.json({ error: 'Internal Server Error' }, { status: 500 })
}
}スキルなしの場合、バリデーションの有無、エラーハンドリングの書き方、レスポンス形式がその都度バラバラになりがちですが、スキルを通じて統一されるのが大きな利点です。
Testingカテゴリでは、テストの命名規則やアサーションの書き方だけでなく、「どのレベルのテストをどの粒度で書くか」という戦略まで定義できます。筆者のチームでは、ユニットテストはロジック層のみ、APIルートは統合テスト、UIはE2Eで主要パスのみカバーするという方針をスキルに落とし込んでいます。エージェントに「テストを書いて」と依頼するだけで、この方針に沿ったテストコードが生成されるのは実用的です。
具体的には、以下のようにエージェントへの指示がシンプルになります。
# スキル導入前：テストの前提条件を毎回伝える必要がある
# 「Vitestを使って、describeでグループ化して、
# itの中でarrange-act-assertパターンで書いて、
# モックはvi.mockを使って...」
# スキル導入後：一言で済む
# 「getUserById関数のテストを書いて」エージェントがスキルを参照して出力するテストコードの例です。
// スキルに沿って生成されたテストコード例
import { describe, it, expect, vi } from 'vitest'
import { getUserById } from '@/lib/users'
describe('getUserById', () => {
it('存在するユーザーIDを指定した場合、ユーザー情報を返す', async () => {
// Arrange
const userId = 'user-123'
// Act
const result = await getUserById(userId)
// Assert
expect(result).toBeDefined()
expect(result.id).toBe(userId)
})
it('存在しないユーザーIDを指定した場合、nullを返す', async () => {
// Arrange
const userId = 'non-existent-id'
// Act
const result = await getUserById(userId)
// Assert
expect(result).toBeNull()
})
})Securityカテゴリはとりわけ印象的で、OWASP Top 10に準拠したレビュー観点が構造化されています。たとえばSQLインジェクション、XSS、CSRF、認証・認可の不備といった観点ごとにチェック項目が用意されており、コードレビュー時にスキルを指定してレビューを依頼すると、これらの観点を網羅的に検査してくれます。手動でチェックリストを用意していた頃と比べると、抜け漏れが格段に減りました。一方で、プロジェクト固有のセキュリティ要件までは当然カバーされないため、ベースラインとして活用しつつカスタマイズする運用が現実的かもしれません。
Infrastructureカテゴリには、TerraformやCloudFormationのベストプラクティスをまとめたスキルが含まれています。「S3バケットを作成して」とだけ伝えた場合でも、パブリックアクセスのブロック設定、バージョニングの有効化、暗号化設定といったセキュリティ上の基本設定が自動で含まれる点は、うっかりミスの防止に役立ちます。
Productカテゴリも実用性の高い領域です。要件定義やユーザーストーリーの作成では、往々にしてエンジニアとプロダクトマネージャーの間で粒度や表現が食い違いがちです。このカテゴリのスキルを使うと、受け入れ基準の書き方やストーリーポイントの見積もり基準が統一された形式で出力されるため、チーム間のコミュニケーションコストが下がります。筆者も要件定義フェーズでエージェントにたたき台を作ってもらい、それをベースにステークホルダーと議論するという使い方をしていますが、ゼロから書くより議論の質が上がった実感があります。
カスタムスキルの作成とチーム展開
既存スキルだけでなく、自チーム独自のスキルを作成できる点もこのライブラリの大きな強みです。SKILL.mdの基本構造は以下のとおりです。
# スキル名
## 概要
このスキルが解決する課題と適用場面の説明
## 前提条件
- 必要な環境・ツール
- 事前に完了しておくべき設定
## 実行手順
1. 具体的なステップ1
2. 具体的なステップ2
3. 具体的なステップ3
## 制約・注意事項
- 守るべきルールや禁止事項
- エッジケースへの対処方針
## 成果物
- 期待されるアウトプットの形式と品質基準ポイントは、指示を曖昧にせず具体的な制約と成果物の基準を明記することです。「きれいなコードを書いて」ではなく「ESLintルールセットXに準拠し、関数あたりの行数は30行以内」のように定量的な基準を設けると、エージェントの出力品質が安定します。
カスタムスキルの実例
実際に筆者のチームで運用しているカスタムスキルの一例を紹介します。Supabaseを使ったプロジェクトで、データベースマイグレーション用のスキルを作成しました。概要欄には「既存データを保持したまま安全にスキーマ変更を行う」と記載し、実行手順には「1. 新規マイグレーションファイルを作成」「2. ALTER TABLEで既存テーブルを変更（DROP TABLEは禁止）」「3. psqlコマンドで対象ファイルのみを適用」「4. 適用結果をスキーマ差分で確認」と具体的に記載しています。制約事項には「supabase db resetは絶対に実行しない」「データ型の変更時は必ずバックアップ手順を提示する」を明記しました。
このスキルの実際のファイル内容は、以下のような形です。
# Supabase マイグレーション
## 概要
既存データを保持したまま安全にスキーマ変更を行う。
本番環境への適用を前提とした慎重な手順を定義する。
## 前提条件
- Supabase CLIがインストール済みであること
- psqlコマンドが使用可能であること
- ローカルのSupabaseインスタンスが起動していること
## 実行手順
1. マイグレーションファイルを作成する
```bash
supabase migration new <migration_name>- 生成されたSQLファイルにALTER TABLE文を記述する
- psqlコマンドで対象ファイルのみを適用する
psql postgresql://postgres:postgres@127.0.0.1:54322/postgres \ -f supabase/migrations/<ファイル名>.sql - 履歴テーブルに適用記録を追加する
psql postgresql://postgres:postgres@127.0.0.1:54322/postgres \ -c "INSERT INTO supabase_migrations.schema_migrations (version, name) VALUES ('<バージョン>', '<名前>');" - スキーマ差分を確認する
supabase db diff
制約・注意事項
supabase db resetは絶対に実行しない（全データが消失する）supabase migration upは使用しない（意図しないマイグレーションが適用される）- DROP TABLE / DROP COLUMN は原則禁止。必要な場合は必ずバックアップ手順を提示する
- データ型の変更は、新カラム追加 → データ移行 → 旧カラム削除の3段階で行う
成果物
- 適用済みのマイグレーションSQLファイル
- 適用前後のスキーマ差分の確認結果
このスキルを導入してから、エージェントがマイグレーションを提案する際に`db reset`のような危険なコマンドを出すことがなくなりました。小さなことのように思えるかもしれませんが、本番環境に影響を与えかねない操作を事前に防げるのは、実運用において非常に心強いものです。
### スキル作成時のよくある失敗と対策
振り返ると、最初はスキル定義が抽象的すぎて期待した結果が得られず、遠回りをしました。具体性と再現性を意識して書き直してから、ようやくチームメンバー間でも一貫した結果が出るようになった経験があります。
よくある失敗パターンをいくつか挙げておきます。まず**指示が広すぎる**ケース。「良いコードを書く」ではエージェントの解釈に幅が出すぎるため、「関数は単一責任にする」「引数は3つ以内」のように分解して記述します。次に**前提条件の省略**。Node.jsのバージョンやパッケージマネージャーの種類など、人間が暗黙に了解している前提をスキルに書き忘れると、エージェントが異なる前提で動作することがあります。最後に**成果物の基準が不明確**な場合。「テストを書く」だけでなく「カバレッジ80%以上を目指し、境界値テストを必ず含める」のように期待値を具体的に記述することが重要です。
作成したスキルはGitリポジトリで管理し、チーム全体で共有するのが推奨されるワークフローです。コードレビューと同様にスキルレビューの文化を取り入れると、ナレッジの属人化を防ぎつつ、組織全体のAI活用レベルを底上げできるのではないでしょうか。
## 既存のCLAUDE.mdやルールファイルとの使い分け
antigravity-awesome-skillsを検討する際に気になるのが、Claude CodeのCLAUDE.mdやCursorの.cursorrules など、各ツールが標準で備えているルールファイルとの関係性です。
結論から言えば、これらは排他的なものではなく**補完関係**にあります。CLAUDE.mdやルールファイルはプロジェクト全体に常時適用されるグローバルな方針を定義するのに適しています。一方、スキルは特定のタスクを実行するときだけ動的にロードされる局所的な専門知識です。
たとえば「コミットメッセージはConventional Commits形式で書く」「日本語で応答する」といったプロジェクト全体のルールはCLAUDE.mdに書き、「データベースマイグレーションの具体的な手順」「パフォーマンスチューニング時のプロファイリング手順」のようなタスク固有の深い知識はスキルとして切り出す、という整理が明快です。CLAUDE.mdに何もかも詰め込むとファイルが肥大化してエージェントの注意が分散しますが、スキルとして切り出すことで必要なときだけ必要な知識がロードされる仕組みになります。
具体的な使い分けの例を表にまとめます。
| 記述内容 | 配置先 | 理由 |
|---|---|---|
| コミットメッセージ形式 | CLAUDE.md | 全タスクに共通で適用 |
| レスポンス言語（日本語） | CLAUDE.md | 全タスクに共通で適用 |
| DB マイグレーション手順 | SKILL.md | スキーマ変更時のみ必要 |
| セキュリティレビュー観点 | SKILL.md | レビュー時のみ必要 |
| パフォーマンス最適化手順 | SKILL.md | チューニング時のみ必要 |
| コーディング規約（ESLint設定） | CLAUDE.md | 全コード生成に共通 |
| API設計のRESTful規約 | SKILL.md | API実装時のみ必要 |
この整理を意識するだけで、CLAUDE.mdの肥大化を防ぎながらも、必要な場面では深い知識をエージェントに渡せるバランスの良い運用が実現できます。
## 導入時に押さえておきたい注意点
便利なライブラリではありますが、導入にあたっていくつか注意しておきたい点もあります。
**スキルの取捨選択は必須です。** 1,370以上のスキルをすべてインストールすると、エージェントが読み込むコンテキストが膨大になり、かえって応答精度が下がる場合があります。プロジェクトの技術スタックに合ったスキルだけを選んで導入するのが望ましい運用です。筆者の場合、最初に全スキルを入れて試したところ、関係のない言語やフレームワークのルールが混在してしまい、すぐにバンドル単位の選択的インストールに切り替えました。
不要なスキルを整理する際は、以下のようなコマンドでスキルの棚卸しができます。
```bash
# インストール済みスキルの総数を確認
find .claude/skills -name "*.md" | wc -l
# カテゴリごとのスキル数を確認
for dir in .claude/skills/*/; do
echo "$(basename $dir): $(find $dir -name '*.md' | wc -l) スキル"
done
# プロジェクトで使わない言語のスキルを特定
grep -rl "Python" .claude/skills/ --include="*.md"
grep -rl "Ruby" .claude/skills/ --include="*.md"定期的なアップデート確認も大切です。 オープンソースプロジェクトである以上、スキルの追加や改善が継続的に行われています。古いバージョンのスキルを使い続けると、最新のベストプラクティスから乖離してしまう可能性があります。月に一度程度、リポジトリの更新を確認して必要なスキルを更新する運用をおすすめします。
アップデートは再度npxコマンドを実行するだけで完了します。既存のカスタムスキルは上書きされないため、安心して実行できます。
# スキルのアップデート（カスタムスキルは保持される）
npx antigravity-awesome-skills@latest --claudeチーム内での運用ルール策定も欠かせません。 カスタムスキルを各メンバーが自由に追加・変更すると、スキル同士が矛盾する指示を含んでしまうことがあります。スキルの追加・変更にはプルリクエストを必須とし、少なくとも1名のレビューを経るフローを整えておくと、こうした混乱を防げます。
スキルの効果測定も意識したいところです。 導入して満足するのではなく、実際にエージェントの出力品質がどう変わったかを定期的に振り返ることをおすすめします。筆者のチームでは、スキル導入前後でコードレビューの指摘件数やCI失敗率を比較しています。数値として効果が見えると、チームメンバーのスキル運用へのモチベーションも上がりますし、どのスキルが機能していてどのスキルが形骸化しているかの判断材料にもなります。
まとめと今後の展望
antigravity-awesome-skillsは、AIコーディングアシスタントを「指示待ちのツール」から「チームの知見を体現した専門エージェント」へと進化させるライブラリです。1,370以上の実戦的なスキルが即座に利用でき、かつカスタムスキルによるチーム固有のナレッジ蓄積も可能な点が、他のプロンプト管理手法との大きな差別化要因といえます。
AIエージェントの活用が標準化されていく中で、スキルの設計と運用はソフトウェア開発プロセスの新たなレイヤーになりつつあります。これまでコーディング規約やレビューガイドラインとして文書化されてきたチームの暗黙知が、スキルという形でエージェントにも共有される時代が来ています。人間同士のナレッジ共有とAIへのナレッジ共有が同じ仕組みで実現できるというのは、考えてみればとても自然な進化ではないでしょうか。
一概にすべてのチームにフィットするとは言えない部分もありますが、まずはバンドルの導入から試してみる価値は十分にあるでしょう。小さく始めて効果を確認し、必要に応じてカスタムスキルを育てていく。その積み重ねが、チーム全体のAI活用力を着実に引き上げてくれるはずです。
aduceでは、AIエージェントを活用した開発プロセスの最適化やDX推進を支援しています。自社に合ったAIスキル設計や導入戦略についてご相談があれば、こちらからお気軽にご連絡ください。