Skills: Skill の解剖:プロンプト+ツール+トリガー
最終更新:2026-08-31
Skill の骨格を見透かす——プロンプトは脳、ツールは両手、トリガーは神経。
1. 3つのコンポーネントの概要
完全な Skill は3つのコアコンポーネントで構成されています:
graph LR
A[トリガー Trigger] -->|有効化| B[プロンプト Prompt]
B -->|導く| C[ツール Tools]
C -->|実行| D[出力結果]
D -->|フィードバック| B
| コンポーネント | 役割 | 例え |
|---|---|---|
| プロンプト | AI の行動規範と出力フォーマットを定義 | 脳——「どう考えるか」を決める |
| ツール | AI が外部とやり取りする能力を提供 | 両手——「何ができるか」を決める |
| トリガー | Skill をいつ有効化するかを制御 | 神経——「いつ反応するか」を決める |
2. プロンプトの深掘り
(1) プロンプトの構造
高品質なプロンプトは以下の階層を含みます:
TEXT
📖 参照専用
プロンプト構造
├── ロール定義(あなたは誰か)
├── タスク記述(何をするか)
├── 実行フロー(どうするか)
├── 制約条件(何をしてはいけないか)
├── 出力フォーマット(どんな出力か)
└── サンプル(参考テンプレート)
(2) ロール定義
MARKDOWN
# ロール定義の例
あなたはシニア DevOps エンジニアで、Kubernetes と CI/CD パイプライン設計を専門としています。
以下の専門分野を持っています:
- コンテナ化デプロイとオーケストレーション
- GitHub Actions / GitLab CI 設定
- 本番環境のモニタリングとアラート
(3) 実行フロー
MARKDOWN
# 実行フローの例
以下の手順でデプロイチェックを実行:
1. Dockerfile を読み込み、ベースイメージのバージョンを確認
2. CI 設定ファイルをチェックし、パイプラインステップを確認
3. ハードコーディングされた環境変数とシークレットを検索
4. ヘルスチェックエンドポイントの設定を確認
5. チェックレポートを出力
(4) 出力フォーマットの制約
MARKDOWN
# 出力フォーマット
以下のフォーマットでチェック結果を出力:
| チェック項目 | ステータス | 詳細 |
|:-------|:-----|:-----|
| ベースイメージ | ✅/⚠️/❌ | バージョン番号と提案 |
| CI ステップ | ✅/⚠️/❌ | 欠落しているステップ |
| 機密情報 | ✅/⚠️/❌ | 発見場所 |
| ヘルスチェック | ✅/⚠️/❌ | 設定の提案 |
3. ツールバインディングの深掘り
(1) ツールの分類
| カテゴリ | ツール | 用途 |
|---|---|---|
| ファイル読み込み | Read | ファイル内容の読み込み |
| ファイル書き込み | Write, Edit | ファイルの作成または修正 |
| コード検索 | Grep, Glob | コードパターンの検索 |
| コマンド実行 | Bash | Shell コマンドの実行 |
| ネットワークリクエスト | WebFetch | Web コンテンツの取得 |
| MCP ツール | カスタム | 外部サービスへの接続 |
(2) ツール選択の原則
TEXT
📖 参照専用
最小権限の原則:
- 読み取り専用タスク → Read のみバインド
- 検索が必要 → Grep/Glob を追加
- 修正が必要 → Edit を追加(Write より安全)
- 実行が必要 → Bash を追加(最高権限、慎重に使用)
(3) ツールバインディングの例
YAML
# 読み取り専用レビュー——最も安全
tools:
- Read
- Grep
- Glob
# コード修正——編集権限が必要
tools:
- Read
- Edit
- Bash
# 完全デプロイ——最高権限
tools:
- Read
- Write
- Edit
- Bash
- WebFetch
4. トリガーの深掘り
(1) トリガータイプ
| タイプ | 構文 | 説明 |
|---|---|---|
| キーワード | keyword: "review" |
ユーザー入力のキーワードにマッチ |
| ファイルパターン | file_pattern: "**/*.py" |
操作するファイルタイプにマッチ |
| コンテキスト条件 | context: "git_diff" |
現在の環境状態にマッチ |
| 複合トリガー | any_of / all_of |
複数条件の論理組み合わせ |
(2) キーワードトリガー
YAML
triggers:
- keyword: "review|レビュー|code review"
- keyword: "deploy|デプロイ"
(3) ファイルパターントリガー
YAML
triggers:
- file_pattern: "**/*.py"
- file_pattern: "**/Dockerfile"
(4) 複合トリガー
YAML
triggers:
- all_of:
- keyword: "review"
- file_pattern: "src/**/*.ts"
5. 3つのコンポーネントの連携
▶ 例:セキュリティ監査 Skill
YAML
---
name: security-audit
description: "セキュリティ監査スキル、コード内のセキュリティ脆弱性をチェック"
triggers:
- keyword: "security|セキュリティ監査|脆弱性チェック"
- file_pattern: "**/*.{py,js,ts,go,java}"
tools:
- Read
- Grep
- Glob
---
# セキュリティ監査スキル
## ロール
あなたはセキュリティ監査専門家で、OWASP Top 10 脆弱性の検出を専門としています。
## 実行フロー
1. Glob でプロジェクトの技術スタックを特定
2. Grep で一般的な脆弱性パターンを検索(SQL 結合、eval、ハードコーディングされたシークレット)
3. Read で不審なファイルを詳細にチェック
4. 脆弱性レポートを出力
## チェックリスト
- [ ] SQL インジェクション
- [ ] XSS クロスサイトスクリプティング
- [ ] ハードコーディングされたキー/パスワード
- [ ] 安全でないデシリアライゼーション
- [ ] パストラバーサル
- [ ] コマンドインジェクション
## 出力フォーマット
各脆弱性について出力:深刻度、場所、説明、修正提案
Alice はこの Skill で、プロジェクト内の以前気付かなかった3つのセキュリティ脆弱性を発見しました。Bob は言います:「ツールとプロンプトの連携がポイント——Grep で初期スキャン、Read で深度確認、プロンプトでチェックの漏れを防ぐ。」
❓ よくある質問
Q 3つのコンポーネントのうちどれが最も重要ですか?
A プロンプトがコア——Skill の品質の上限を決めます。ツールは能力の境界を決め、トリガーは利便性を決めます。良いプロンプトがなければ、ツールが多くてもうまく使えません。
Q トリガーはいくつ設定すべきですか?
A 1〜3個で十分です。多すぎると誤トリガーの原因になり、少なすぎると有効化しづらくなります。キーワードトリガーが最も一般的で、ファイルパターントリガーは自動化シナリオに適しています。
Q ツールをバインドしたのに AI が使わない場合は?
A プロンプトでツールの使用を明示的に要求し、具体的な呼び出し手順を記載してください。「Read ツールでファイルを読み込む」は「ファイルを確認する」より明確です。
📖 まとめ
- Skill の3つのコンポーネント:プロンプト(脳)、ツール(両手)、トリガー(神経)
- プロンプト構造:ロール→タスク→フロー→制約→フォーマット→サンプル
- ツール選択は最小権限の原則に従う
- トリガータイプ:キーワード、ファイルパターン、コンテキスト条件、複合論理
📝 練習問題
- 基礎問題(難易度⭐):以前に作成した Skill を分析し、3つのコンポーネントがすべて揃っているか確認してください。
- 応用問題(難易度⭐⭐):「パフォーマンス最適化」Skill を作成し、適切なプロンプト、ツールバインディング、トリガーを設計してください。
- チャレンジ問題(難易度⭐⭐⭐):複合トリガーの Skill を設計し、特定のファイルタイプ+特定のキーワードが同時に現れた時のみ有効化するようにしてください。