はじめに

こんにちは！

VSCode + GitHub Copilot、Cursor、Google AntiGravity、Claude Codeなど、AI統合のIDEを使っている方なら、Rules、Workflows、Skills、Slash Commandsという用語を聞いたことがあるでしょう。でも...これらは一体何なのか？いつ使うべきなのか？そして最も重要なのは、どうすればこれらの力を最大限に活用できるのか？

この記事では、これら4つの概念をわかりやすく詳しく解説します。それでは始めましょう！

クイックサマリー

詳細に入る前に、全体像を把握するための簡単なまとめです：

概念	簡単な説明	いつ使うか	例
Rules	AIの「憲法」- 常に適用される	コーディング規約、セキュリティ、アーキテクチャ	「常にTypeScriptを使用する」
Workflows	特定タスク用のマクロ/テンプレート	繰り返しタスク、手動トリガー	コードレビュー、テスト生成
Skills	AIが自動的に使用タイミングを判断する専門知識	PDF処理、データベースマイグレーション	「PDFについて話すと、AIが自動的に処理方法を知る」
Slash Commands	Workflowを呼び出すショートカット	タスクへの素早いアクセス	`/review`、`/test`

1. Agent Rules - AIエージェントの「憲法」

Rulesとは？

新しい同僚が入社したと想像してください。仕事を始める前に、あなたは彼らにこう言うでしょう：

「ここでは常にTypeScriptを使います」
「コードには最低80%のユニットテストカバレッジが必要です」
「APIキーは絶対にgitにコミットしないでください」

Agent Rulesはまさにそのようなルールです！ これらは常に有効（always-on）な指示であり、AIがすべてのタスクで従うべき「基盤」のようなものです。毎回思い出させる必要はありません。

Rulesの特徴

Passive と Persistent：自動的にロードされ、トリガー不要
Hierarchical：階層構造あり（Enterprise > User > Project > Local）
Universal：すべてのリクエスト、すべてのファイルに適用
Foundation Layer：AIの動作の基盤を形成

Rulesを使うべきとき

以下の場合にRulesを使用します：

チームのコーディング規約に従わせたい
セキュリティ原則を常に遵守させたい
プロジェクトのアーキテクチャを理解させたい
テスト標準を知らせたい

実践例

コーディング規約：

# コーディングルール
- JavaScriptではなく常にTypeScriptを使用する
- インデントは2スペース、タブは使用しない
- コールバックではなくasync/awaitを優先する
- 変数名はcamelCase、クラス名はPascalCase
- すべてのpublic関数にJSDocコメントを書く

プロジェクトアーキテクチャ：

# アーキテクチャルール
- Controllerは`src/controllers/`、Serviceは`src/services/`に配置
- すべてのデータベースアクセスにRepositoryパターンを使用
- SOLID原則を遵守する
- APIレスポンスでデータベースエンティティを直接返さない

セキュリティ：

# セキュリティルール
- APIキーやシークレットをハードコードしない
- ユーザー入力は処理前に必ずバリデーション
- SQL文字列連結ではなくパラメータ化クエリを使用
- すべてのAPIエンドポイントには認証ミドルウェアが必要

効果的なRulesの書き方

やるべきこと：

ルールは簡潔、具体的、箇条書きで
Markdownの見出しでグループ化
最も重要なルールを先頭に配置
プロジェクトの成長に合わせて定期的にレビュー・更新

やってはいけないこと：

長すぎる、複雑すぎる記述（AIが「圧倒」される）
レベル間で矛盾するルール
ルールが多すぎる（50以上）- AIは弁護士ではありません！

2. Agent Workflows - 繰り返しタスク用のマクロ

Workflowsとは？

Rulesが「憲法」なら、Workflowsは標準化された**「作業手順」**のようなものです。

同じプロンプトを何度も書いたことはありませんか？例えば：

「このコードをレビューして、セキュリティ、パフォーマンス、テストカバレッジをチェックして...」
「この関数のユニットテストをエッジケース含めて生成して...」

Workflowsはこれらのプロンプトを保存し、一つのコマンドで再利用できます！

Workflowsの特徴

User-Invoked：呼び出したときだけ実行（手動トリガー）
Task-Specific：特定のタスク用に設計
Reusable Templates：何度も再利用可能、時間節約
Context-Rich：指示と必要なコンテキストの両方を含められる

Workflowsを使うべきとき

Workflowsは以下の場合に適しています：

繰り返し行うタスクがある
チーム全体でプロセスを標準化したい
複数のステップを含む複雑なプロンプトが必要
同僚とベストプラクティスを共有したい

実践例

コードレビューWorkflow：

---
name: review-code
description: 包括的なコードレビュー
---

# コードレビュー手順

選択したコードを以下の基準でレビュー：
1. **コード品質**：構造、可読性、命名規則
2. **セキュリティ**：脆弱性、入力検証、認証
3. **パフォーマンス**：アルゴリズム、データベースクエリ、メモリ
4. **テスト**：テストカバレッジ、エッジケース
5. **ドキュメント**：コメント、JSDoc、README更新

出力内容：
- 発見された問題のサマリー
- 問題のあるコード行の特定
- コード例付きの改善提案
- 優先度の分類（緊急/高/中/低）

ユニットテスト生成Workflow：

---
name: generate-unit-test
description: 自動ユニットテスト生成
---

# ユニットテスト生成手順

選択したコードのユニットテストを作成：
1. すべてのpublic関数を特定
2. 以下を含むテストを作成：
   - 正常系（happy path）
   - 境界値（空の入力、null、edge cases）
   - エラーハンドリング
3. Jestのdescribe/it構文を使用
4. わかりやすいテスト名を付ける

効果的なWorkflowsの書き方

やるべきこと：

機能を明確に説明する名前を付ける
ステップバイステップの明確な指示を含める
期待する出力フォーマットを記述
gitを通じてチームとWorkflowsを共有
繰り返しタスク用のWorkflowsを作成

やってはいけないこと：

汎用的すぎるWorkflowsを作成
要件変更時の更新を忘れる
WorkflowsとRules間でロジックを重複させる

3. Agent Skills - 自動的に発動する専門知識

Skillsとは？

これが最も興味深い部分です！

Skillsは、AIが**いつ使うべきかを自動的に判断する****「専門知識パッケージ」です。Rules（常にアクティブ）やWorkflows（手動トリガー）とは異なり、Skillsは「model-invoked」**方式で動作します - AIが自分で決定します！

わかりやすい例：PDF処理について質問すると、AIは自動的にPDFのSkillを持っていることを「思い出し」、その知識を適用します。「PDFスキルを使って」と言う必要はありません - AIが自動的に判断します！

Skillsの特徴

Model-Invoked：AIがコンテキストに基づいて使用タイミングを自動決定
Progressive Disclosure：必要なときだけロード（メモリ最適化）
Portable：オープンスタンダード、クロスプラットフォーム対応
Composable：1つのタスクで複数のSkillsを組み合わせ可能
Self-Contained：指示、スクリプト、例を含む完全なパッケージ

Skillsの動作原理

Discovery：開始時、AIは全Skillsのリスト（名前+説明のみ）を受け取る
Relevance Check：AIがリクエストとSkillsの説明を比較
Activation：マッチした場合、AIがSkillの全内容をロード
Execution：AIがSkill内の指示に従って実行
Iteration：Skillは会話中に何度でも再利用可能

Skillの構造

.github/skills/my-skill/    
├── SKILL.md                 # 必須：指示 + メタデータ
├── references/              # オプション：参考ドキュメント
│   └── api-docs.md
├── examples/                # オプション：サンプル
│   └── sample-usage.ts
└── scripts/                 # オプション：ヘルパースクリプト
    └── helper.py

SKILL.mdのフォーマット：

---
name: pdf-processing
description: テキスト抽出、フォーム入力、PDF結合。PDFファイル、ドキュメント、.pdf形式で作業する際に使用。
---

# PDF処理スキル

## 指示
AIのための実行手順...

## 例
具体的な使用例...

## ベストプラクティス
原則と推奨事項...

Skillsを使うべきとき

Skillsは以下の場合に適しています：

特定のドメイン知識がある（PDF処理、データベースマイグレーション、API生成など）
毎回思い出させなくてもAIに「より賢く」なってほしい
チームと自然な形で専門知識を共有したい
クロスプラットフォームのオープンスタンダードを活用したい

実践例

PDF処理Skill：

---
name: pdf-processing
description: テキスト抽出、フォーム入力、PDF結合。PDFファイル、ドキュメント、.pdf形式、ドキュメント内容分析の際に使用。
---

# PDF処理スキル

## 機能
- PDFからテキスト抽出
- PDFフォームの自動入力
- 複数PDFの結合
- PDFを画像に変換

データベースマイグレーションSkill：

---
name: database-migrations
description: データベースマイグレーションの作成と管理。スキーマ変更、マイグレーション、データベースバージョニング、テーブル変更について質問された際に使用。
---

# データベースマイグレーションスキル

## ベストプラクティス
- 常にロールバック可能なマイグレーションを作成
- 本番環境の前にステージングでテスト
- 必要に応じてデータマイグレーションも含める

効果的なSkillsの書き方

Descriptionが鍵！ これはAIがSkillを使うかどうかを決定するために読む部分です。

悪い例：

description: ドキュメント作業をサポート

良い例：

description: Excelファイルの分析、ピボットテーブル作成、グラフ生成。Excelファイル、スプレッドシート、.xlsx形式、表形式データ分析の際に使用。

良いパターン：

description: [アクション] + [具体的なタスク]。[トリガーキーワード/状況]の際に使用。

その他のアドバイス：

Single Responsibility：1つのSkill = 1つの明確な機能
Include Examples：サンプルがあるとAIの理解が早まる
Progressive Structure：基本的な指示はSKILL.md、詳細は別ファイル
十分なテスト：5-10種類の異なる質問でSkillをテスト

4. Slash Commands - 素早いアクセスのためのショートカット

Slash Commandsとは？

Slash Commandsは単純にWorkflowsを呼び出すショートカットです！Workflowを探す代わりに、/とコマンド名を入力するだけです。

例：

コードレビューの長いプロンプトを書く代わりに、/reviewと入力
テスト生成Workflowを思い出す代わりに、/testと入力

Slash Commandsの特徴

Quick Access：数文字でWorkflowにアクセス
Memorable：Workflowを探すより覚えやすい
Discoverable：/を入力すると利用可能なコマンド一覧が表示
Customizable：自分専用のコマンドを定義可能

Slash CommandsとWorkflowsの関係

Slash Commandsは実質的にWorkflowsの短縮名です：

/review  →  "review-code" Workflowを起動
/test    →  "generate-unit-test" Workflowを起動
/deploy  →  "deploy-feature" Workflowを起動

使用例

あなた: /review
AI: [開いているファイルのコードレビューを自動実行]

あなた: /test UserService
AI: [UserServiceクラスのユニットテストを生成]

あなた: /docs
AI: [選択したコードのドキュメントを生成]

5. いつ何を使うべきか？Decision Framework

これは重要なセクションです！素早く決定するお手伝いをします：

シンプルなルール

すべてのタスクに適用？           → Rules
繰り返しタスク、手動トリガー？   → Workflows（+ Slash Commands）
AIが自動的に使うべき時を判断？   → Skills

詳細なDecision Tree

START: AIに何をさせたいか？

├─ すべてのタスクに適用？（コーディング規約、コンベンション）
│  └─ はい → RULES
│     ├─ 個人 → User Rules
│     ├─ チーム → Project Rules
│     └─ 会社 → Enterprise Rules
│
├─ 特定タスクの手動トリガー？（コードレビュー、テスト生成）
│  └─ はい → WORKFLOWS
│     ├─ 複数プロジェクト → Global Workflows
│     └─ このプロジェクトのみ → Project Workflows
│
└─ AIが自動的に使用タイミングを判断？（専門知識）
   └─ はい → SKILLS
      ├─ 個人 → Personal Skills
      └─ チーム → Project Skills（gitにコミット）

適用例

要件	解決策	理由
「常にJavaScriptではなくTypeScriptを使用」	Rule	すべてのタスクに適用
「ユニットテストを生成するボタンが欲しい」	Workflow + Slash Command	オンデマンドタスク
「PDFについて話すとき、AIは処理方法を知るべき」	Skill	自動認識
「チーム全体がフォローするコードレビュー手順」	Rule + Workflow	Ruleで基準定義、Workflowで実行

6. Best Practices：効果的なシステム設計

設計原則

Single Responsibility（単一責任）
- 各Rule：1つの関心事（スタイル、セキュリティ、アーキテクチャ）
- 各Workflow：1つの特定タスク
- 各Skill：1つの専門分野
Progressive Disclosure（段階的開示）
- Rules：簡潔、箇条書き
- Skills：軽い説明、必要時に全内容をロード
- Workflows：明確なステップバイステップ

Layered Approach（階層化アプローチ）

レイヤー1 - Foundation (Rules): 常に正しい基盤
レイヤー2 - Capabilities (Skills): 専門的な機能
レイヤー3 - Orchestration (Workflows): 問題解決のための組み合わせ

パフォーマンスのヒント

やるべきこと：

Rulesは合計100行以下に抑える
プロジェクトあたりSkillsは5-10個に制限
Workflowは集中的に、多くのことをやらせすぎない

やってはいけないこと：

Rules/Skills/Workflows間で情報を重複させる
複雑すぎるディレクトリ構造を作成
説明を長く書きすぎる（AIは素早くスキャンするだけ！）

7. IDE別サポート状況

各IDEは異なる実装をしています。以下は簡単な概要です：

サポート比較

機能	VSCode + GitHub Copilot	Cursor	Google AntiGravity	Claude Code
Rules	あり	あり	あり	あり
Workflows	あり（Prompt Files）	あり	あり	Skills で代替
Skills	あり	あり	あり	あり
Slash Commands	あり（`/prompt`）	あり	あり（`/`メニュー）	あり

IDE別保存場所

VSCode/GitHub Copilot

タイプ	場所
User Instructions	Settings → GitHub Copilot → Instructions
Repository Instructions	`.github/copilot-instructions.md`
Prompt Files (Workflows)	`.github/prompts/*.prompt.md`
Skills	`.github/skills/` または `~/.copilot/skills/`

Cursor

タイプ	場所
Global Rules	Cursor Settings → Rules for AI
Project Rules	`.cursor/rules` または `.cursorrules`
Workflows	`.md`ファイルをrulesと組み合わせて使用

Google AntiGravity

タイプ	場所
Global Rules	`~/.gemini/GEMINI.md`
Project Rules	`./.antigravity/rules.md` または `./GEMINI.md`
Global Workflows	`~/.gemini/antigravity/workflows/`
Project Workflows	`./.antigravity/workflows/`
Skills	`~/.gemini/antigravity/skills/` または `.agent/skills/`

Claude Code

タイプ	場所
Enterprise Policy	`/Library/Application Support/ClaudeCode/CLAUDE.md` (macOS)
User Memory	`~/.claude/CLAUDE.md`
Project Memory	`./CLAUDE.md` または `./.claude/CLAUDE.md`
Local Project Memory	`./CLAUDE.local.md`（プライベート、コミットしない）
Skills	`~/.claude/skills/` または `.claude/skills/`

注意： お使いのIDEが特定の機能をサポートしていない場合、通常は別の機能で同様の目的を達成できます。例：Claude Codeには独立したWorkflowsはありませんが、SkillsとMemoryを組み合わせることで同様の結果を得られます。

公式ドキュメント

お使いのIDEの詳細な設定方法については、以下を参照してください：

おわりに

Agent Rules、Workflows、Skillsは互いに競合する別々の概念ではなく、AIエージェントエコシステムにおける3つの補完的なレイヤーです：

Rules = 基盤 - 常に正しいこと
Skills = 能力 - AIができること
Workflows = オーケストレーション - 複雑な問題を解決するための組み合わせ方

正しく組み合わせることで、AIがより速くコードを書くだけでなく、チームの標準とベストプラクティスに従ってより正確に、よりスマートにコードを書くことができる強力なシステムが生まれます。

「AIアシスタント」から「AIチームメンバー」への旅は、Rules、Skills、Workflowsを通じてAIにあなたのコンテキスト、好み、専門知識を教えることから始まります。小さく始めて、素早く改善し、そして最も重要なのは、学んだことをコミュニティと共有してください！

Happy coding with your AI agents!