要約
Agent Skillsは、定型作業を自動化し、創造的な時間を確保するための強力なツールである。本記事では、開発系10個、コンテンツ作成・クリエイティブ系10個、ドキュメント・ナレッジ系2個の計22ユースケース（+番外編2個）を紹介する。オンボーディング効率化からSEO最適化、画像・音楽生成プロンプト作成まで、実際に業務またはプライベートで活用している具体的なスキル構成例と使い方を解説する。
対象読者: Agent Skillsの基本を理解し、具体的な活用例を探しているエンジニア、コンテンツクリエイター、マーケター、生産性向上を目指すビジネスパーソン
検証環境: Claude Code 2.0.76 / Claude Max プラン（2025年12月時点）
この記事を読むことで得られるメリット
実際に業務またはプライベートで何回もやっている作業をスキル化した事例を紹介する。スキルの構成やファイル名などは例なのでご留意いただきたい。
この記事を読むことで以下のことが分かる:
- 初級から上級まで24種類の実践的なユースケース
- 各ユースケースの具体的なスキル構成例と実行方法
- 定型作業を最小化し、創造的な時間を確保する方法
この記事を読むのにかかる時間
約25分（全ユースケースを通読した場合）
※目次から興味のあるユースケースのみ読む場合は5-10分
環境
- MacOS Apple M4 Max Sequoia 15.1
- Claude Code 2.0.76
- Claude Pro / Max / Team / Enterpriseプランのいずれか
Agent Skillsユースケース一覧
本記事で紹介するユースケースの一覧である。3カテゴリ、22個のユースケース（+番外編5個）を網羅している。特定のタスクに専門知識が必要だったり、いくつかのパターンがあったり、プラクティスやアンチパターン、ルールがある場合にAgent skillsを使うとその便利さがわかって良いと思う。
maasaablog.com
Agent Skillsとは？仕組みと基本概念をわかりやすく解説
maasaablog.com
【ハンズオン】Agent Skillsの作り方・ベストプラクティス・配布方法
開発系（10個）
# | ユースケース | 概要 |
|---|---|---|
1 | オンボーディング効率化 | 新規メンバーのキャッチアップ支援 |
2 | コーディングルール・詳細設計 | 規約とデザインパターンの体系化 |
3 | パフォーマンス最適化 | FE/BE/DBのパフォーマンス改善 |
4 | コードレビュー・品質チェック | 変更点のレビューと問題指摘 |
5 | セキュリティチェック | OWASP Top 10ベースの脆弱性、秘匿情報の検出 |
6 | テスト計画・テストコード生成 | テスト戦略から進捗管理、コード生成まで |
7 | デバッグ・調査 | エラー分析と根本原因特定 |
8 | リファクタリング | 技術的負債の可視化と改善 |
9 | ドキュメント・仕様書作成 | コードからドキュメント自動生成 |
10 | フロントエンドデザイン | AIっぽさを排除した高品質UI生成 |
コンテンツ作成・クリエイティブ系（10個）
# | ユースケース | 概要 |
|---|---|---|
11 | SEOに最適化されたブログ記事作成（多言語記事も） | メモから高品質な記事を生成 |
12 | ブログ記事リライト | 検索順位改善のためのリライト |
13 | X投稿最適化 | エンゲージメント向上と自動投稿 |
14 | YouTubeメタデータ生成 | タイトル・説明文・タグの最適化 |
15 | Chrome拡張機能開発時のストアの申請チェック | 審査通過のためのチェックリスト |
16 | リリースノート生成 | コミット内容から自動生成 |
17 | FAQや想定質問と回答生成 | コンテンツから質問を先回り生成 |
18 | 画像処理・変換 | リサイズ・変換・最適化の自動化 |
19 | 画像生成プロンプト作成 | 対話形式で最適なプロンプト生成 |
20 | 音楽生成プロンプト作成 | Suno等向けのプロンプト最適化 |
ドキュメント・ナレッジ系（2個）
# | ユースケース | 概要 |
|---|---|---|
21 | 会議のアジェンダ作成 | 目的・論点・時間配分の設計 |
22 | ナレッジDB管理 | 情報の一元管理と活用 |
番外編（今後実践したい）（2個）
# | ユースケース | 概要 |
|---|---|---|
- | ブランドガイドライン遵守チェック | ブランド規約準拠の確認 |
- | ポートフォリオ管理 | キャリア情報の整理・更新 |
開発系ユースケース
開発系はサブエージェントと組み合わせることでより最適化できるかもしれない
ユースケース1: オンボーディング効率化
概要
新規のプロジェクトメンバーがスピーディにキャッチアップできるように、質問するだけで欲しい情報にアクセスできるようにすることが可能である。開発だけではなく事務手続き、社内ルールなどにも応用できる。このスキルを使うと以下を順番に、あるいは好きな項目をいつでも質問できるような感じだ（MCPサーバーの開発プロジェクトと想定してもらいたい）
- 環境セットアップ
- 外部リソース（Google Drive資料やドキュメントの場所）
- 要件定義書や開発ロードマップ、過去の打ち合わせ議事録、バックログ、開発スケジュール
- アーキテクチャ概要、プロジェクト構造の理解
- 開発フロー、ローカル開発とデバッグ
- コーディング規約
- テストの書き方、テストケースの規則、カバレッジ
- 開発ガイド（MCPサーバーの開発、ツールの作り方など）
- 初めての機能追加、実践チュートリアル
- Git規約（Conventional Commits）
- トラブルシューティング、よくある問題と解決方法
解決する課題
課題 | 詳細 |
|---|---|
新メンバーの立ち上がり時間 | キャッチアップに時間がかかる |
同じ質問への繰り返し回答 | 既存メンバーの工数を消費 |
ドキュメントの探索コスト | 必要な情報が見つからない |
構成例
/.claude/skills/onboarding/
├── SKILL.md # ハブ（目次・ナビゲーション）
├── 01-setup/
│ └── SKILL.md # 環境セットアップ
├── 02-architecture/
│ └── SKILL.md # アーキテクチャ理解
├── 03-dev-flow/
│ └── SKILL.md # 開発フロー
├── 04-coding-standards/
│ └── SKILL.md # コーディング規約
└── ...
使い方
「今日からこのプロジェクトに参加するので、最初に知っておいた方がいいことを教えて」
「このプロジェクトでMCPサーバーのツールを新しく追加するにはどういう手順が必要？」
自然言語で質問でき、知りたい情報だけに焦点を当てて知ることができる。CLAUDE.mdでは汎用性が足りず量も多い。コマンドではそもそもそのようなコマンドがあることを知っておく必要があるので、気軽に質問できて使いやすいスキルが向いている。指示に対して100パーセント合致するスキルがなくても、「ユーザーからの曖昧な依頼からに対してこれはどうでしょうか」と提案してくれるのも良いところである。
ユースケース2: コーディングルール・詳細設計
概要
プロジェクト固有のコーディング規約、設計原則、デザインパターンをスキルとして体系化し、Claudeが一貫したコード生成できるようにする。新規コード作成時は規約に沿ったコードを生成し、既存コードのレビュー時は規約違反やコードスメルを検出する。
- 命名規則・フォーマット規約
- ファイル・ディレクトリ構成ルール
- エラーハンドリング方針
- デザインパターンの適用基準
- SOLID原則・アーキテクチャパターン
- コードスメル検出・リファクタリング指針
解決する課題
課題 | 詳細 |
|---|---|
規約の属人化 | 「あの人に聞かないとわからない」暗黙知の排除 |
新メンバーの学習コスト | 規約を覚えるまでの時間短縮 |
規約違反の見落とし | 人の目だけでは限界がある |
規約ドキュメントの形骸化 | 書いたけど誰も見ない問題 |
設計判断の迷い | 「どのパターンを使うべきか」の指針不足 |
一貫性のないコードベース | 人によって書き方がバラバラ |
リファクタリングの先送り | 「何を直すべきか」が不明確 |
構成例
/.claude/skills/
├── design-patterns/
│ ├── SKILL.md # パターン選択ガイド
│ ├── creational/ # 生成パターン
│ │ ├── factory.md
│ │ ├── builder.md
│ │ ├── singleton.md
│ │ └── dependency-injection.md
│ └── behavioral/ # 振る舞いパターン
│ ├── strategy.md
│ ├── observer.md
│ ├── command.md
│ └── state.md
│
├── coding-standards/
│ ├── SKILL.md # 規約の概要・適用ルール
│ ├── naming.md # 命名規則
│ ├── file-structure.md # ファイル・ディレクトリ構成
│ ├── comments.md # コメント規約
│ ├── error-handling.md # エラーハンドリング規約
│ ├── typescript.md # TypeScript固有ルール
│ └── formatting.md # フォーマット
│
├── architecture/
│ ├── SKILL.md # アーキテクチャ選択ガイド
│ ├── clean-architecture.md # クリーンアーキテクチャ
│ ├── layered.md # レイヤードアーキテクチャ
│ ├── ddd.md # ドメイン駆動設計
│ ├── modular.md # モジュール分割
│ └── dependencies.md # 依存関係管理
│
└── solid-principles/
├── SKILL.md # SOLID概要
├── srp.md # 単一責任の原則
├── ocp.md # 開放閉鎖の原則
├── lsp.md # リスコフの置換原則
├── isp.md # インターフェース分離の原則
└── dip.md # 依存性逆転の原則
使い方
「ユーザー登録機能を実装して」 「このクラスが規約に沿っているかチェックして」 「この処理、どのデザインパターンが適切？」
ユースケース3: パフォーマンス最適化
概要
コードやシステムのパフォーマンス問題を特定し、体系的に改善する。フロントエンド（Core Web Vitals）、バックエンド（API応答速度）、データベース（クエリ最適化）を網羅する。実装時点で最適化しておくのも手だが、時にはスピード優先でこういった内容は後から別途着手したいこともあるだろう。
解決する課題
課題 | 詳細 |
|---|---|
ボトルネックの特定に時間がかかる | どこが遅いかわからない |
最適化の優先順位が不明確 | どこから手をつけるべきか |
計測なしの「感覚的な」チューニング | 効果が測定できない |
同じパフォーマンス問題の繰り返し | 再発防止ができていない |
構成例
/.claude/skills/
└── performance/
├── SKILL.md # ハブ（概要・診断フロー）
│
├── diagnosis/ # 問題特定
│ ├── SKILL.md # 診断の進め方
│ ├── profiling.md # プロファイリング手法
│ └── metrics.md # 計測すべき指標
│
├── frontend/ # フロントエンド最適化
│ ├── SKILL.md # FE最適化の基本
│ ├── core-web-vitals.md # LCP, FID, CLS対策
│ ├── bundle-size.md # バンドルサイズ削減
│ ├── rendering.md # レンダリング最適化
│ └── images.md # 画像最適化
│
├── backend/ # バックエンド最適化
│ ├── SKILL.md # BE最適化の基本
│ ├── api-response.md # API応答速度改善
│ ├── caching.md # キャッシュ戦略
│ ├── async.md # 非同期処理・並列化
│ └── memory.md # メモリ最適化
│
└── database/ # DB最適化
├── SKILL.md # DB最適化の基本
├── query.md # クエリ最適化
├── indexing.md # インデックス設計
├── n-plus-one.md # N+1問題対策
└── connection.md # コネクション管理
使い方
問題診断: 「このAPIが遅いので原因を調査して」 「ページの読み込みが遅い原因を特定して Lighthouseスコアが40点」
フロントエンド最適化: 「Core Web Vitalsを改善したい LCPが4秒、CLSが0.3ある」 「バンドルサイズを削減したい 現在2.5MBある」 「このReactコンポーネントの再レンダリングを最適化して」
バックエンド最適化: 「このエンドポイントのレスポンス時間を改善して。現在500msかかっている」 「キャッシュ戦略を提案して。同じデータを何度もDBから取得している」
データベース最適化: 「このクエリを最適化して。EXPLAIN結果も見てほしい」 「N+1問題がないかチェックして」 「適切なインデックスを提案して」
ユースケース4: コードレビュー・品質チェック
概要
コードの変更点をレビューし、改善点や潜在的な問題を指摘する。設計観点・ビジネス観点・セキュリティ観点からの多角的なレビューを体系化。レビュー観点のチェックリスト、よくある指摘パターン、レビューコメントのテンプレートを提供し、一貫性のある高品質なレビューを実現する。
- レビュー観点のチェックリスト
- 観点別の詳細ガイド（設計、セキュリティ、パフォーマンス等）
- よくある指摘パターンと改善例
- レビューコメントの書き方
- セルフレビューのフロー
- 言語・フレームワーク別の注意点
解決する課題
課題 | 詳細 |
|---|---|
レビュー観点の漏れ | チェックすべき点を見落とす |
コードの一貫性維持 | スタイルがバラバラになる |
潜在的なバグの早期発見 | 問題が本番で発覚する |
レビューの属人化 | 人によって指摘内容が異なる |
指摘の伝え方が難しい | 批判的に聞こえてしまう |
セキュリティ観点の欠如 | 脆弱性を見逃す |
設計観点が弱い | 動くかどうかしか見ていない |
レビューに時間がかかる | 何を見ればいいかわからない |
構成例
/.claude/skills/
└── code-review/
├── SKILL.md # ハブ（レビューフロー）
│
├── checklist/ # チェックリスト
│ ├── SKILL.md # チェックリストの使い方
│ ├── general.md # 汎用チェックリスト
│ ├── pr-size.md # PR規模別チェックリスト
│ └── self-review.md # セルフレビュー用
│
├── perspectives/ # レビュー観点
│ ├── SKILL.md # 観点の概要
│ ├── design.md # 設計観点
│ ├── security.md # セキュリティ観点
│ ├── performance.md # パフォーマンス観点
│ ├── readability.md # 可読性観点
│ ├── testability.md # テスタビリティ観点
│ ├── maintainability.md # 保守性観点
│ └── business.md # ビジネス観点
│
├── patterns/ # よくある指摘パターン
│ ├── SKILL.md # パターンの使い方
│ ├── common-bugs.md # よくあるバグ
│ ├── anti-patterns.md # アンチパターン
│ ├── security-issues.md # セキュリティ問題
│ └── performance-issues.md # パフォーマンス問題
│
├── comments/ # コメントの書き方
│ ├── SKILL.md # コメント作法
│ ├── severity.md # 重要度の伝え方
│ ├── templates.md # コメントテンプレート
│ └── tone.md # トーン・言い回し
│
├── languages/ # 言語別の注意点
│ ├── javascript.md # JavaScript/TypeScript
│ ├── python.md # Python
│ ├── go.md # Go
│ └── react.md # React
│
└── config.md # プロジェクト固有設定使い方
PRレビュー依頼:
User: このPRをレビューして
[差分を貼り付け or PR URL]
Claude: レビュー結果をお伝えします。
【サマリー】
変更ファイル: 5件
追加行: 120行 / 削除行: 45行
リスクレベル: 中（DB変更を含む）
【指摘事項】
🔴 Critical（要修正）
1. [security] SQLインジェクションの可能性
L.45: `query = f"SELECT * FROM users WHERE id = {user_id}"`
→ プレースホルダーを使用してください
🟡 Warning（推奨）
2. [design] 責務が大きすぎる関数
L.78-150: `process_order()` が複数の処理を担当
→ 単一責任の原則に沿って分割を検討
3. [performance] N+1クエリの可能性
L.92: ループ内でDBアクセス
→ バッチ取得への変更を推奨
🟢 Suggestion（任意）
4. [readability] 変数名の改善
L.23: `d` → `user_data` など意図が伝わる名前に
【Good Points】
✅ テストカバレッジが十分
✅ エラーハンドリングが適切特定観点でのレビュー:
User: セキュリティ観点でレビューして
Claude: セキュリティ観点でのレビュー結果です。
【認証・認可】
✅ 認証チェックあり
⚠️ 認可チェックが不十分（L.34: 他ユーザーのデータにアクセス可能）
【入力検証】
🔴 SQLインジェクション: L.45
🔴 XSS対策なし: L.78
【機密情報】
⚠️ APIキーがハードコード: L.12
✅ パスワードは適切にハッシュ化
【推奨アクション】
1. 認可チェックの追加（優先度: 高）
2. プレースホルダーの使用（優先度: 高）
3. 出力エスケープの追加（優先度: 高）
4. APIキーを環境変数に移動（優先度: 中）セルフレビュー:
User: PR出す前にセルフレビューしたい
Claude: セルフレビューチェックリストを実行します。
【基本チェック】
- [ ] コードは動作するか（ローカルで確認）
- [ ] テストは通るか
- [ ] Lint/フォーマットは通るか
【設計チェック】
- [ ] 変更の影響範囲は適切か
- [ ] 責務は適切に分離されているか
- [ ] 既存の設計パターンに従っているか
【セキュリティチェック】
- [ ] 入力値は検証しているか
- [ ] 認証・認可は適切か
- [ ] 機密情報は含まれていないか
【可読性チェック】
- [ ] 変数名・関数名は意図が伝わるか
- [ ] コメントは必要十分か
- [ ] 複雑な処理に説明があるか
チェックリストを埋めながら確認しますか？ユースケース5: セキュリティチェック
概要
コードやシステム構成のセキュリティ脆弱性を体系的に検出・対策する。OWASP Top 10をベースに、入力バリデーション、認証・認可、データ保護、依存関係の脆弱性など多角的にチェックする。セキュアコーディングのベストプラクティスを適用し、脆弱性の早期発見と予防を実現する。
- OWASP Top 10 チェックリスト
- 入力バリデーション・サニタイズ
- 認証・認可の実装パターン
- SQLインジェクション・XSS対策
- シークレット管理
- 依存関係の脆弱性スキャン
- セキュリティヘッダー設定
- ログ・監査証跡
解決する課題
課題 | 詳細 |
|---|---|
脆弱性の見落とし | レビューだけでは検出困難なセキュリティホール |
セキュリティ知識の属人化 | 「セキュリティに詳しい人」への依存 |
対策方法がわからない | 脆弱性は知っていても正しい修正方法が不明 |
後付けのセキュリティ対策 | 開発後に問題発覚し大幅な手戻り |
依存パッケージの脆弱性放置 | 更新タイミングや影響範囲が不明 |
シークレット漏洩リスク | ハードコード、誤コミット、ログ出力 |
チェック観点のばらつき | 人によって確認範囲が異なる |
セキュリティ要件の曖昧さ | 「セキュアに」の具体的基準がない |
構成例
/.claude/skills/
└── security/
├── SKILL.md # ハブ（概要・チェックフロー）
│
├── owasp/ # OWASP Top 10
│ ├── SKILL.md # OWASP概要・優先度
│ ├── injection.md # A03: インジェクション
│ ├── broken-auth.md # A07: 認証の不備
│ ├── sensitive-data.md # A02: 機密データの露出
│ ├── xxe.md # XML外部エンティティ
│ ├── broken-access.md # A01: アクセス制御の不備
│ ├── misconfig.md # A05: セキュリティ設定ミス
│ ├── xss.md # A03: クロスサイトスクリプティング
│ ├── deserialization.md # 安全でないデシリアライゼーション
│ ├── vulnerable-deps.md # A06: 脆弱なコンポーネント
│ └── logging.md # A09: ログと監視の不足
│
├── input-validation/ # 入力検証
│ ├── SKILL.md # バリデーションの基本
│ ├── sanitization.md # サニタイズ手法
│ ├── file-upload.md # ファイルアップロード
│ └── api-input.md # APIリクエスト検証
│
├── data-protection/ # データ保護
│ ├── SKILL.md # データ保護の基本
│ ├── encryption.md # 暗号化
│ ├── secrets.md # シークレット管理
│ ├── pii.md # 個人情報保護
│ └── logging-safe.md # 安全なログ出力
│
├── infrastructure/ # インフラセキュリティ
│ ├── SKILL.md # インフラセキュリティ基本
│ ├── headers.md # セキュリティヘッダー
│ ├── cors.md # CORS設定
│ ├── https.md # HTTPS/TLS設定
│ └── csp.md # Content Security Policy
│
└── dependencies/ # 依存関係
├── SKILL.md # 依存関係管理
├── audit.md # 脆弱性スキャン
└── update-strategy.md # 更新戦略
使い方
「このAPIエンドポイントにセキュリティ脆弱性がないかチェックして」 「このコードにSQLインジェクションのリスクがないか確認して」 「依存パッケージの脆弱性をスキャンして」 「シークレットが漏洩するリスクがないかレビューして」 「OWASP Top 10の観点でセキュリティレビューして」
ユースケース6: テスト計画・テストコード生成
概要
テスト戦略の策定からテストコード生成、カバレッジ分析、テスト作成進捗管理までを体系的に支援する。テストピラミッド（Unit/Integration/E2E）の設計、テストケースの洗い出し、モック・スタブの活用、境界値分析などのテスト技法を適用する。既存コードのカバレッジ不足箇所を特定し、効果的なテストコードを生成する。
- テスト戦略・テストピラミッド設計
- テストケース設計技法（境界値、同値分割、デシジョンテーブル）
- Unit/Integration/E2Eテストの書き分け
- モック・スタブ・スパイの使い方
- テストデータ管理
- カバレッジ分析・改善
- TDD/BDDアプローチ
- テストの保守性・可読性
解決する課題
課題 | 詳細 |
|---|---|
テストの書き方がわからない | 何をどこまでテストすべきか不明確 |
テストケースの漏れ | 境界値やエッジケースの見落とし |
カバレッジの偏り | 行カバレッジは高いが分岐が未テスト |
テストの保守コスト | 実装変更のたびにテストが壊れる |
モックの乱用 | 何でもモックして意味のないテストに |
遅いテスト | E2Eに依存しすぎてCI/CDが遅い |
テストコードの品質 | テスト自体が読みにくく保守困難 |
テスト戦略の属人化 | 「どこまでテストするか」が人による |
構成例
/.claude/skills/
└── testing/
├── SKILL.md # ハブ（テスト戦略・方針）
│
├── strategy/ # テスト戦略
│ ├── SKILL.md # 戦略策定の基本
│ ├── test-pyramid.md # テストピラミッド
│ ├── what-to-test.md # 何をテストすべきか
│ └── coverage-goals.md # カバレッジ目標設定
│
├── design/ # テスト設計技法
│ ├── SKILL.md # テスト設計の基本
│ ├── boundary-value.md # 境界値分析
│ ├── equivalence.md # 同値分割
│ ├── decision-table.md # デシジョンテーブル
│ ├── state-transition.md # 状態遷移テスト
│ └── error-guessing.md # エラー推測
│
├── unit/ # ユニットテスト
│ ├── SKILL.md # Unitテストの基本
│ ├── structure.md # テスト構造（AAA, Given-When-Then）
│ ├── assertions.md # アサーションパターン
│ ├── mocking.md # モック・スタブ・スパイ
│ ├── async.md # 非同期テスト
│ └── parameterized.md # パラメータ化テスト
│
├── integration/ # 統合テスト
│ ├── SKILL.md # Integrationテストの基本
│ ├── api.md # APIテスト
│ ├── database.md # DBテスト
│ └── external-services.md # 外部サービステスト
│
├── coverage/ # カバレッジ
│ ├── SKILL.md # カバレッジ分析
│ ├── metrics.md # メトリクスの見方
│ ├── improvement.md # カバレッジ改善
│ └── branch-coverage.md # 分岐カバレッジ
│
└── test-data/ # テストデータ
├── SKILL.md # テストデータ管理
├── fixtures.md # フィクスチャ
├── factories.md # ファクトリパターン
└── seeding.md # シーディング
使い方
「このユーザー登録機能のテストケースを洗い出して」 「src/services/payment.ts のユニットテストを生成して」 「このAPIエンドポイントの統合テストを書いて」 「カバレッジが低い箇所を特定して改善案を出して」 「この関数の境界値テストを追加して」 「モックの使い方が適切かレビューして」 「E2Eテストのシナリオを設計して」 「テストが壊れやすい原因を分析して」
ユースケース7: デバッグ・調査
概要
エラーメッセージやスタックトレースをもとにコードリーディング、バグ調査、修正をサポートする。体系的な調査手法（仮説立案→検証→絞り込み）を適用し、根本原因を特定する。調査結果は統一フォーマットで報告し、再発防止策まで提案する。ログ解析、再現手順の確立など実践的なデバッグ技法を網羅する。
- エラー分析・スタックトレース解読
- 体系的な調査フロー（仮説→検証→絞り込み）
- ログ解析・トレーシング
- 再現手順の確立
- 根本原因分析
- 調査報告フォーマット
解決する課題
課題 | 詳細 |
|---|---|
調査が行き当たりばったり | 推測で修正して時間を浪費 |
再現できない | 「自分の環境では動く」問題 |
原因特定に時間がかかる | どこから調べていいかわからない |
対症療法で終わる | 根本原因を解決せず再発 |
調査結果が共有されない | 同じ問題を別の人がまた調査 |
報告フォーマットがバラバラ | 必要な情報が欠けた報告 |
ログが読めない | 大量のログから必要な情報を見つけられない |
デバッグ知識の属人化 | 「あの人しか調査できない」状態 |
構成例
/.claude/skills/
└── debugging/
├── SKILL.md # ハブ（調査フロー・基本原則）
│
├── analysis/ # エラー分析
│ ├── SKILL.md # エラー分析の基本
│ ├── stack-trace.md # スタックトレース解読
│ ├── error-messages.md # エラーメッセージ解釈
│ └── common-errors.md # よくあるエラーパターン
│
├── investigation/ # 調査手法
│ ├── SKILL.md # 調査の進め方
│ ├── hypothesis.md # 仮説立案・検証
│ ├── binary-search.md # 二分探索（git bisect）
│ ├── reproduce.md # 再現手順の確立
│ └── isolation.md # 問題の切り分け
│
├── logging/ # ログ解析
│ ├── SKILL.md # ログ解析の基本
│ ├── reading.md # ログの読み方
│ ├── tracing.md # 分散トレーシング
│ └── tools.md # ログ解析ツール
│
├── techniques/ # デバッグ技法
│ ├── SKILL.md # デバッグ技法一覧
│ ├── breakpoints.md # ブレークポイント活用
│ ├── rubber-duck.md # ラバーダック法
│ ├── print-debug.md # printデバッグの効果的な使い方
│ └── diff-debug.md # 差分デバッグ
│
├── rca/ # 根本原因分析
│ ├── SKILL.md # RCAの基本
│ ├── five-whys.md # なぜなぜ分析
│ └── fishbone.md # 特性要因図
│
└── reporting/ # 報告フォーマット
├── SKILL.md # 報告の書き方
├── bug-report.md # バグ報告テンプレート
├── investigation-report.md # 調査報告テンプレート
└── postmortem.md # ポストモーテムテンプレート
使い方
「このエラーの原因を調査して」 「スタックトレースを解析して原因を特定して」 「この問題の再現手順を確立して」 「git bisectでバグが入ったコミットを特定して」 「調査結果を報告フォーマットでまとめて」 「根本原因分析（なぜなぜ分析）をして」 「このログから問題箇所を見つけて」 「ポストモーテムを作成して」
ユースケース8: リファクタリング
概要
既存コードの外部振る舞いを変えずに内部構造を改善する。リファクタリングパターンの適用、安全なリファクタリング手順を体系化する。技術的負債の可視化・解消計画の策定から、段階的な改善実施までをサポートする。大規模リファクタリングの分割戦略やリスク管理も含む。
- リファクタリングカタログ（パターン集）
- 安全なリファクタリング手順
- 技術的負債の可視化・優先順位付け
- 段階的リファクタリング戦略
- リファクタリング前後のテスト戦略
- 大規模リファクタリングの分割・計画
- レガシーコード対応
解決する課題
課題 | 詳細 |
|---|---|
リファクタ方法がわからない | 改善したいが具体的な手法が不明 |
リファクタで壊してしまう | 修正による予期せぬバグの発生 |
技術的負債の優先順位 | どこから手をつけるべきか判断できない |
大規模リファクタの計画 | 一度にやると危険、分割方法が不明 |
リファクタの効果が説明できない | ビジネス側への説明・承認が困難 |
レガシーコードが触れない | テストがなく変更が怖い |
リファクタが終わらない | スコープが膨らみ完了しない |
構成例
/.claude/skills/
└── refactoring/
├── SKILL.md # ハブ（リファクタリングの進め方）
│
├── detection/ # 検出
│ ├── SKILL.md # コードスメル検出の基本
│ ├── code-smells.md # コードスメル一覧
│ ├── metrics.md # コード品質メトリクス
│ └── tools.md # 静的解析ツール
│
├── catalog/ # リファクタリングカタログ
│ ├── SKILL.md # カタログの使い方
│ ├── extract-method.md # メソッド抽出
│ ├── extract-class.md # クラス抽出
│ ├── inline.md # インライン化
│ ├── rename.md # 名前変更
│ ├── move.md # 移動
│ ├── replace-conditional.md # 条件分岐の置き換え
│ ├── introduce-parameter.md # パラメータ導入
│ └── decompose.md # 分解
│
├── safety/ # 安全なリファクタリング
│ ├── SKILL.md # 安全に進めるための基本
│ ├── test-first.md # テストファースト
│ ├── small-steps.md # 小さなステップ
│ ├── strangler-fig.md # ストラングラーフィグパターン
│ └── feature-flags.md # フィーチャーフラグ活用
│
├── legacy/ # レガシーコード対応
│ ├── SKILL.md # レガシーコードの扱い方
│ ├── seams.md # シーム（接合部）の見つけ方
│ ├── characterization-test.md # 特性テスト
│ └── sprout-method.md # スプラウトメソッド/クラス
│
├── planning/ # 計画
│ ├── SKILL.md # リファクタリング計画
│ ├── tech-debt.md # 技術的負債の可視化
│ ├── prioritization.md # 優先順位付け
│ ├── scope.md # スコープ管理
│ └── communication.md # ステークホルダーへの説明
│
├── patterns/ # パターン別
│ ├── long-method.md # 長いメソッドの解消
│ ├── god-class.md # 神クラスの分割
│ ├── feature-envy.md # 機能の横恋慕
│ ├── primitive-obsession.md # プリミティブ執着
│ ├── shotgun-surgery.md # 散弾銃手術
│ └── divergent-change.md # 発散的変更
│
└── checklists/ # チェックリスト
├── before-refactoring.md # リファクタリング前
├── during-refactoring.md # リファクタリング中
└── after-refactoring.md # リファクタリング後
使い方
「この長いメソッドをリファクタして」 「技術的負債を洗い出して優先順位をつけて」 「このレガシーコードを安全にリファクタする計画を立てて」 「神クラスを分割する方法を提案して」 「条件分岐をポリモーフィズムに置き換えて」 「リファクタリング前にテストを追加して」 「段階的にリファクタする計画を作成して」
ユースケース9: ドキュメント・仕様書作成
概要
コードベースから自動的にドキュメントや仕様書を生成する。シーケンス図で流れの整理、クラス図でやり取りを可視化、DB設計なども含む。
解決する課題
課題 | 詳細 |
|---|---|
ドキュメントとコードの乖離 | 実装と説明が合っていない |
仕様書作成の工数 | 手動で書くのに時間がかかる |
API仕様の可視化 | エンドポイントの全体像が見えない |
構成例
/.claude/skills/
└── doc-generator/
├── SKILL.md # ハブ（概要・ナビゲーション）
│
├── diagrams/ # 図の生成
│ ├── SKILL.md # 図生成の共通ルール
│ ├── sequence.md # シーケンス図
│ ├── class.md # クラス図
│ ├── er.md # ER図
│ ├── flowchart.md # フローチャート
│ └── architecture.md # アーキテクチャ図
│
└── api-docs/ # API仕様書
├── SKILL.md # API仕様書生成ルール
├── openapi.md # OpenAPI形式
├── endpoint-template.md # エンドポイント記述テンプレート
└── examples.md # 良い例
使い方
「ユーザー認証のフローをシーケンス図にして」 「src/models/ 配下のクラス関係を図にして」 「src/api/routes/ からOpenAPI仕様書を生成して」
ユースケース10: フロントエンドデザイン
概要
このユースケースは、Anthropic公式ブログで紹介されたフロントエンドデザインスキルを深掘りする。AIが生成するUIの「AIっぽさ」を解消する優れた例である。
AIが生成するフロントエンドUIには、特有の「AIっぽさ」が存在する。
解決する課題
課題 | 詳細 |
|---|---|
AIっぽいUI | グラデーション過多、装飾過剰 |
スタイル一貫性 | コンポーネント間で統一感がない |
ブランド不適合 | 汎用的でプロジェクトに合わない |
構成例
フロントエンドデザインスキルは、驚くべきことにたった1つのマークダウンファイルで構成されている。
frontend-design/
└── SKILL.mdSKILL.mdには、デザイン思考のプロセス、フロントエンド美学ガイドライン、避けるべきパターンなどが記載されている。
参考:
GitHub
claude-code/plugins/frontend-design/skills/frontend-design/SKILL.md at main · anthropics/claude-code
効果
項目 | Before | After |
|---|---|---|
グラデーション使用 | 過剰 | 必要最小限 |
スタイル一貫性 | 低い | 高い |
コード保守性 | 低い | 高い |
アクセシビリティ | 考慮なし | WCAG準拠 |
レスポンシブ対応 | 不十分 | モバイルファースト |
使い方
「高品質なフロントエンドのデザインを作成して」
コンテンツ作成・クリエイティブ系ユースケース
ユースケース11: SEOに最適化されたブログ記事作成
概要
メモ書きや雑多な情報からブログ記事の見出し構成、本文、SEO用のタイトル・メタディスクリプションを生成する。文体（です・ます調 / だ・である調）、過去記事、トーン、ターゲット読者に合わせた一貫性のある記事を作成する。構成テンプレート、SEOチェックリストなどを駆使して品質の高い記事を効率的に生成する。
- 記事構成テンプレート（How-to、比較、リスト等）
- 見出し設計（H1〜H3の階層）
- 本文ライティングガイド
- 文体・トーン規約
- SEO最適化（タイトル、メタ、キーワード）
- リード文・まとめの書き方
- 画像・図解の挿入指針
解決する課題
課題 | 詳細 |
|---|---|
記事構成に時間がかかる | 見出しの設計で悩んで手が止まる |
SEO対策の知識不足 | タイトルやメタの最適化方法がわからない |
文体がバラバラ | 記事ごとに「です・ます」「だ・である」が混在 |
書き出しが苦手 | リード文で何を書くか迷う |
冗長な文章になる | 要点が伝わらない長い記事 |
一貫性のないフォーマット | 記事によって構成がバラバラ |
ネタはあるが形にならない | メモから記事に昇華できない |
構成例
/.claude/skills/
└── blog-writing/
├── SKILL.md # ハブ（記事作成フロー）
│
├── structure/ # 記事構成
│ ├── SKILL.md # 構成設計の基本
│ ├── templates/ # 構成テンプレート
│ │ ├── how-to.md # ハウツー記事
│ │ ├── listicle.md # リスト記事
│ │ ├── comparison.md # 比較記事
│ │ ├── review.md # レビュー記事
│ │ ├── case-study.md # 事例紹介
│ │ └── tutorial.md # チュートリアル
│ ├── headings.md # 見出し設計
│ └── outline.md # アウトライン作成法
│
├── writing/ # ライティング
│ ├── SKILL.md # ライティングの基本
│ ├── lead.md # リード文の書き方
│ ├── body.md # 本文の書き方
│ ├── conclusion.md # まとめの書き方
│ ├── transitions.md # 接続・つなぎ
│ └── examples.md # 具体例の入れ方
│
├── style/ # 文体・トーン
│ ├── SKILL.md # 文体規約
│ ├── desu-masu.md # です・ます調
│ ├── da-dearu.md # だ・である調
│ ├── tone.md # トーン設定
│ └── ng-expressions.md # 避けるべき表現
│
├── seo/ # SEO最適化
│ ├── SKILL.md # SEOの基本
│ ├── title.md # タイトル最適化
│ ├── meta-description.md # メタディスクリプション
│ ├── keywords.md # キーワード配置
│ ├── headings-seo.md # 見出しのSEO
│ └── internal-links.md # 内部リンク
│
├── media/ # メディア
│ ├── SKILL.md # 画像・図解の使い方
│ ├── alt-text.md # alt属性の書き方
│ └── placement.md # 配置の指針
│
├── blog-config.md # ブログ固有設定
│
└── checklists/ # チェックリスト
├── before-publish.md # 公開前チェック
└── seo-checklist.md # SEOチェック
使い方
「このメモからブログ記事の構成を作って」 「ハウツー記事のテンプレートで見出しを設計して」 「SEO用のタイトルとメタディスクリプションを生成して」 「リード文を書いて」 「この記事の読みやすさを改善して」 「公開前チェックリストで確認して」 「技術ブログ向けのトーンに調整して」
ユースケース12: ブログ記事リライト
概要
過去に書いたブログ記事のリライト案を生成し、検索順位・ユーザー体験を改善する。検索順位が下がった記事、古くなった情報、読了率が低い記事を分析し、具体的な改善ポイントを特定する。SEO観点（タイトル・見出し・キーワード）、コンテンツ品質（情報の鮮度・網羅性・読みやすさ）、競合分析をもとに優先度をつけてリライト計画を立てる。
- リライト対象記事の選定基準
- 記事分析・課題特定
- 競合記事との比較分析
- SEO改善ポイント抽出
- コンテンツ拡充・更新指針
- タイトル・見出しの改善案生成
- リライト優先度・計画策定
- 効果測定の指標設定
解決する課題
課題 | 詳細 |
|---|---|
検索順位の低下 | 公開時は上位だったが順位が下がった |
情報の陳腐化 | 古い情報のまま放置されている |
どの記事をリライトすべきかわからない | 優先順位が判断できない |
何を直せばいいかわからない | 改善ポイントが不明確 |
競合に負けている | 同じキーワードで他サイトが上位 |
クリック率が低い | 検索結果に表示されるがクリックされない |
読了率・滞在時間が短い | 離脱が早く最後まで読まれない |
リライトの効果が測定できない | 改善したか判断できない |
構成例
/.claude/skills/
└── blog-rewrite/
├── SKILL.md # ハブ（リライトフロー）
│
├── selection/ # 対象記事の選定
│ ├── SKILL.md # 選定基準
│ ├── metrics.md # 判断指標（順位、PV、CTR等）
│ ├── prioritization.md # 優先度付け
│ └── audit-template.md # 記事棚卸しテンプレート
│
├── analysis/ # 記事分析
│ ├── SKILL.md # 分析の進め方
│ ├── seo-analysis.md # SEO観点の分析
│ ├── content-analysis.md # コンテンツ品質分析
│ ├── competitor-analysis.md # 競合記事分析
│ └── user-analysis.md # ユーザー行動分析
│
├── improvement/ # 改善施策
│ ├── SKILL.md # 改善の進め方
│ ├── title-rewrite.md # タイトル改善
│ ├── heading-rewrite.md # 見出し改善
│ ├── content-update.md # 本文更新・拡充
│ ├── freshness.md # 情報の鮮度更新
│ ├── structure.md # 構成の改善
│ └── internal-links.md # 内部リンク最適化
│
├── templates/ # テンプレート
│ ├── rewrite-plan.md # リライト計画書
│ ├── before-after.md # 変更点まとめ
│ └── report.md # 効果報告
│
└── measurement/ # 効果測定
├── SKILL.md # 効果測定の基本
├── kpi.md # 測定指標
└── tracking.md # 追跡方法
使い方
「この記事のリライト案を出して」 「検索順位が落ちた原因を分析して」 「競合記事と比較して改善ポイントを洗い出して」 「タイトルの改善案を5パターン出して」 「古い情報を最新化するポイントを教えて」 「リライト優先度の高い記事を選定して」 「見出し構成を競合に勝てるよう改善して」 「リライト計画書を作成して」
現状、Search Consoleの公式MCPがないので、CSVでダウンロードしてインプットとして入力するか、GAのMCPを使うと良いだろう
ユースケース13: X投稿最適化
概要
Xの投稿内容を最適化し、エンゲージメント率を向上させる。アルゴリズムに有利な投稿フォーマット、効果的なフック、ハッシュタグ戦略を適用する。ブログ記事やメモから投稿文を自動生成し、投稿パターンの分析・改善サイクルを回して継続的にエンゲージメントを向上させる。
- 投稿フォーマット・構成テンプレート
- フック（冒頭文）の書き方
- アルゴリズム最適化戦略
- ハッシュタグ・メンション戦略
- 画像・メディア活用指針
- スレッド投稿の構成
- 投稿スケジュール最適化
- エンゲージメント分析・改善
解決する課題
課題 | 詳細 |
|---|---|
エンゲージメント率が低い | いいね・RT・リプライが伸びない |
投稿文面の最適化がわからない | 何を書けばバズるかわからない |
アルゴリズムに不利な投稿 | 外部リンク直貼りで表示が抑制される |
投稿作業が面倒 | 毎回手動で投稿するのが手間 |
投稿ネタが尽きる | 何を投稿すればいいかわからない |
投稿時間が最適でない | フォロワーがいない時間に投稿 |
一貫性がない | 投稿のトーンやスタイルがバラバラ |
効果測定ができていない | 何が効果的かわからない |
構成例
/.claude/skills/
└── x-posting/
├── SKILL.md # ハブ（投稿最適化フロー）
│
├── writing/ # 投稿文作成
│ ├── SKILL.md # 投稿文作成の基本
│ ├── hooks.md # フック（冒頭）の書き方
│ ├── formats.md # 投稿フォーマット集
│ ├── cta.md # CTA（行動喚起）の入れ方
│ └── tone.md # トーン・文体設定
│
├── algorithm/ # アルゴリズム対策
│ ├── SKILL.md # アルゴリズムの基本
│ ├── engagement-boost.md # エンゲージメント向上策
│ ├── link-strategy.md # 外部リンクの扱い方
│ ├── timing.md # 投稿タイミング
│ └── avoid.md # 避けるべきパターン
│
├── content-types/ # コンテンツタイプ別
│ ├── SKILL.md # タイプ別の使い分け
│ ├── thread.md # スレッド投稿
│ ├── quote.md # 引用RT
│ ├── poll.md # アンケート
│ ├── media.md # 画像・動画付き投稿
│ └── blog-promo.md # ブログ宣伝投稿
│
├── hashtags/ # ハッシュタグ戦略
│ ├── SKILL.md # ハッシュタグの基本
│ └── research.md # タグリサーチ方法
│
├── templates/ # テンプレート
│ ├── daily-tips.md # 日常Tips投稿
│ ├── learning-log.md # 学習記録投稿
│ ├── opinion.md # 意見・考察投稿
│ ├── announcement.md # 告知投稿
│ └── engagement.md # エンゲージメント狙い投稿
│
├── automation/ # 自動化
│ ├── SKILL.md # 自動投稿の設定
│ └── scheduling.md # スケジュール投稿
│
├── account-config.md # アカウント固有設定
│
└── analysis/ # 分析・改善
├── SKILL.md # 分析の基本
├── metrics.md # 測定指標
└── improvement.md # 改善サイクル
使い方
「このメモからX投稿を作成して」 「このブログ記事の宣伝投稿を作って」 「エンゲージメントが高くなるフォーマットで書き直して」 「スレッド形式で投稿を作成して」 「この投稿を最適化してそのまま投稿して」 「今週の投稿ネタを10個提案して」 「過去の投稿を分析して改善点を教えて」 「アルゴリズムに有利な形式に変換して」
ユースケース14: YouTubeメタデータ生成
概要
動画のタイトル、説明文、タグ、ハッシュタグ、サムネイル、サムネイルテキストを最適化し、検索流入とクリック率を向上させる。YouTube SEOを意識したタイトル設計、視聴者維持に効果的なタイムスタンプ、チャンネルブランディングに沿った一貫性のある概要欄フォーマットを適用する。動画内容からメタデータを自動生成し、公開作業を効率化する。
- タイトル最適化（SEO・CTR向上）
- タイトルABテスト用案生成
- 説明文テンプレート・構成
- タグ・ハッシュタグ戦略
- サムネイル、サムネイルテキスト案生成
- タイムスタンプ（チャプター）生成
- 終了画面・カード設定指針
- チャンネル固有設定
- 競合分析・キーワードリサーチ
解決する課題
課題 | 詳細 |
|---|---|
メタデータ作成に時間がかかる | 毎回ゼロから考えるのが手間 |
SEOを意識したタイトルが作れない | 検索に引っかからない |
概要欄のフォーマットがバラバラ | 動画ごとに構成が違う |
タグの選定基準がない | 何を設定すればいいかわからない |
クリック率が低い | 表示されてもクリックされない |
視聴維持率が低い | タイムスタンプがなく離脱される |
サムネイルテキストが思いつかない | インパクトのある文言が作れない |
競合に埋もれる | 似たような動画と差別化できない |
構成例
/.claude/skills/
└── youtube-metadata/
├── SKILL.md # ハブ（メタデータ生成フロー）
│
├── title/ # タイトル最適化
│ ├── SKILL.md # タイトル設計の基本
│ ├── patterns.md # 効果的なパターン集
│ ├── keywords.md # キーワード配置
│ └── ab-testing.md # A/Bテスト手法
│
├── description/ # 説明文
│ ├── SKILL.md # 説明文の基本
│ ├── structure.md # 構成テンプレート
│ ├── first-lines.md # 最初の3行の書き方
│ ├── timestamps.md # タイムスタンプ生成
│ └── links.md # リンク・CTAの配置
│
├── tags/ # タグ・ハッシュタグ
│ ├── SKILL.md # タグ戦略
│ ├── research.md # キーワードリサーチ
│ ├── hashtags.md # ハッシュタグの使い方
│ └── competitor.md # 競合タグ分析
│
├── thumbnail/ # サムネイル
│ ├── SKILL.md # サムネイルテキストの基本
│ ├── text-patterns.md # テキストパターン集
│ └── guidelines.md # デザイン指針
│
├── optimization/ # 最適化
│ ├── SKILL.md # YouTube SEOの基本
│ ├── algorithm.md # アルゴリズム対策
│ ├── ctr.md # CTR改善
│ └── retention.md # 視聴維持率改善
│
├── templates/ # テンプレート
│ ├── tutorial.md # チュートリアル動画
│ ├── review.md # レビュー動画
│ ├── vlog.md # Vlog
│ ├── listicle.md # 〇〇選動画
│ └── comparison.md # 比較動画
│
├── channel-config.md # チャンネル固有設定
│
└── checklists/ # チェックリスト
├── before-publish.md # 公開前チェック
└── seo-checklist.md # SEOチェック
使い方
「この動画のメタデータを生成して」 「SEOを意識したタイトル案を5パターン出して」 「説明文のテンプレートに沿って概要欄を作成して」 「この動画内容からタイムスタンプを生成して」 「効果的なタグを20個提案して」 「サムネイルに使うテキスト案を出して」 「競合動画を分析してタイトル改善案を出して」 「公開前チェックリストで確認して」
ユースケース15: Chromeストアの申請チェック
概要
Chrome Web Storeへの拡張機能申請に必要なチェックリスト、ポリシー準拠確認、ストア掲載素材の準備を体系化する。審査通過率を高めるためのマニフェスト検証、プライバシーポリシー作成、スクリーンショット・説明文の最適化を支援する。申請却下の回避と再申請対応までをカバーする。
- マニフェスト（manifest.json）検証
- Chrome Web Storeポリシー準拠チェック
- 権限（permissions）の正当性確認
- プライバシーポリシー作成
- ストア掲載素材（アイコン、スクリーンショット、説明文）
- 審査対応・却下理由への対処
- 更新申請時のチェック
- Manifest V3移行対応
解決する課題
課題 | 詳細 |
|---|---|
審査で却下される | ポリシー違反に気づかず申請 |
必要な素材がわからない | アイコンサイズや説明文の要件が不明 |
権限の正当性説明ができない | なぜその権限が必要か説明できない |
プライバシーポリシーがない | 必要なのに用意していない |
却下理由が理解できない | 何を直せばいいかわからない |
Manifest V3対応漏れ | V2のまま申請して却下 |
説明文が最適化されていない | ストアで見つけてもらえない |
更新申請で躓く | 初回は通ったが更新で却下 |
構成例
/.claude/skills/
└── chrome-store-submission/
├── SKILL.md # ハブ（申請フロー）
│
├── manifest/ # マニフェスト検証
│ ├── SKILL.md # マニフェストの基本
│ ├── required-fields.md # 必須フィールド
│ ├── permissions.md # 権限の検証・正当性
│ ├── v3-migration.md # Manifest V3移行
│ └── validation.md # バリデーションツール
│
├── policy/ # ポリシー準拠
│ ├── SKILL.md # ポリシー概要
│ ├── prohibited.md # 禁止事項
│ ├── user-data.md # ユーザーデータ取り扱い
│ ├── ads-monetization.md # 広告・収益化ルール
│ └── branding.md # ブランドガイドライン
│
├── privacy/ # プライバシー
│ ├── SKILL.md # プライバシー要件
│ ├── policy-template.md # プライバシーポリシー雛形
│ ├── data-disclosure.md # データ利用開示
│ └── single-purpose.md # 単一目的ポリシー
│
├── store-listing/ # ストア掲載素材
│ ├── SKILL.md # 掲載素材の基本
│ ├── icons.md # アイコン要件
│ ├── screenshots.md # スクリーンショット要件
│ ├── description.md # 説明文作成
│ └── promotional.md # プロモーション素材
│
├── review/ # 審査対応
│ ├── SKILL.md # 審査プロセス
│ ├── common-rejections.md # よくある却下理由
│ ├── appeal.md # 異議申し立て
│ └── resubmission.md # 再申請のポイント
│
├── update/ # 更新申請
│ ├── SKILL.md # 更新時の注意点
│ └── version-bump.md # バージョン管理
│
└── checklists/ # チェックリスト
├── pre-submission.md # 申請前チェック
├── assets-checklist.md # 素材チェック
└── policy-checklist.md # ポリシーチェック
使い方
「この拡張機能の申請前チェックをして」 「manifest.jsonがポリシーに準拠しているか確認して」 「この権限が必要な理由の説明文を作成して」 「プライバシーポリシーを生成して」 「ストア掲載用の説明文を最適化して」 「却下理由を分析して修正点を教えて」 「Manifest V3への移行チェックをして」 「申請に必要な素材一覧を出して」
ユースケース16: リリースノート生成
概要
個人開発などでリリースしたプロダクトの複数リポジトリのコミットを分析し、機能ごとにグルーピングした統合レポートを自動作成する。
解決する課題
課題 | 詳細 |
|---|---|
リリースノート作成の工数 | 毎回手動で書くのが手間 |
複数リポジトリの変更追跡 | 変更を把握しきれない |
機能ベースでのグルーピング | コミット単位では伝わらない |
使い方
「今週のリリースノートを作成して」
## リリースノート v2.5.0
- ダッシュボードに新しいウィジェットを追加
- APIレート制限の設定が可能に
### 改善
- ページ読み込み速度を30%改善
### バグ修正
- ログイン時のセッションエラーを修正ユースケース17: FAQや想定質問生成
概要
ブログ記事、動画等のコンテンツに対する想定質問を網羅的に生成し、事前に回答を用意する。ユーザーの疑問・不安・反論を先回りして解消することで、コンテンツの説得力向上、問い合わせ削減、コンバージョン率向上を実現する。質問のカテゴリ分類、優先度付け、回答トーンの統一までを体系化する。
- 想定質問の抽出・生成
- 質問カテゴリ分類
- 回答テンプレート・トーン設定
- FAQ構造化（Schema.org対応）
- プロダクト別質問パターン
- 反論・懸念への対応
- 質問の優先度付け
- 継続的なFAQ改善
解決する課題
課題 | 詳細 |
|---|---|
FAQ作成に時間がかかる | どんな質問が来るか予測するのが難しい |
顧客の疑問点を予測できない | 問い合わせが来てから気づく |
同じ質問に何度も回答 | サポート工数が増大 |
コンテンツの説得力不足 | 疑問が解消されず離脱される |
回答のトーンがバラバラ | 担当者によって回答品質が異なる |
FAQが見つけにくい | 構造化されておらず検索性が低い |
反論・懸念に対応できない | 購入前の不安を解消できない |
FAQが更新されない | 古い情報のまま放置 |
構成例
/.claude/skills/
└── faq-generator/
├── SKILL.md # ハブ（FAQ生成フロー）
│
├── extraction/ # 質問抽出
│ ├── SKILL.md # 質問抽出の基本
│ ├── from-content.md # コンテンツから抽出
│ ├── from-product.md # プロダクト情報から抽出
│ ├── from-feedback.md # 問い合わせ・レビューから抽出
│ └── question-patterns.md # 質問パターン集
│
├── categorization/ # カテゴリ分類
│ ├── SKILL.md # 分類の基本
│ ├── categories.md # カテゴリ体系
│ └── prioritization.md # 優先度付け
│
├── answering/ # 回答作成
│ ├── SKILL.md # 回答作成の基本
│ ├── tone.md # トーン・文体設定
│ ├── structure.md # 回答の構造
│ └── templates.md # 回答テンプレート
│
├── objections/ # 反論・懸念対応
│ ├── SKILL.md # 反論対応の基本
│ ├── common-concerns.md # よくある懸念パターン
│ └── reframing.md # リフレーミング手法
│
├── formats/ # 出力形式
│ ├── SKILL.md # 形式別ガイド
│ ├── structured-data.md # Schema.org/JSON-LD
│ ├── accordion.md # アコーディオンUI
│ └── chatbot.md # チャットボット用
│
├── content-types/ # コンテンツタイプ別
│ ├── blog-faq.md # ブログ記事用
│ ├── product-faq.md # プロダクト用
│ ├── service-faq.md # サービス用
│ ├── video-faq.md # 動画用
│ └── event-faq.md # イベント・セミナー用
│
├── config.md # プロジェクト固有設定
│
└── checklists/ # チェックリスト
├── quality-check.md # 品質チェック
└── seo-check.md # SEOチェック
使い方
「このブログ記事から想定質問を10個生成して」 「このプロダクトのFAQを作成して」 「この動画内容に対する視聴者の疑問を洗い出して」 「購入前の不安・懸念に対応するFAQを作って」 「このFAQをSchema.org形式で出力して」 「回答のトーンを統一してリライトして」 「問い合わせ履歴から頻出質問を抽出して」 「反論への対応を追加して」
ユースケース18: 画像処理・変換
概要
画像のリサイズ、フォーマット変換、最適化をスクリプトで自動化する。複数画像の一括処理、Web用の軽量化、サムネイル生成などを効率的に実行する。決定論的な処理をスクリプト化することで、再現性を保証し、トークン消費を最小限に抑える。ImageMagickなどのCLIツールを活用したスクリプト集。
- リサイズ（指定サイズ、アスペクト比維持）
- フォーマット変換（WebP、AVIF、PNG、JPEG）
- 画像最適化（圧縮、メタデータ削除）
- 一括処理スクリプト
- サムネイル・OGP画像生成
- 透かし・ウォーターマーク追加
- 画像情報取得
- Node.js/Python連携
スクリプト活用のメリット:
- 決定論的な処理（同じ入力 → 同じ出力）
- トークン消費の最小化（LLMに画像を渡さない）
- 高速な一括処理
- 再現性・自動化が容易
解決する課題
課題 | 詳細 |
|---|---|
複数画像の一括処理 | 1枚ずつ手動で処理するのが面倒 |
Web用の画像最適化 | ファイルサイズが大きくページ速度が遅い |
フォーマット変換の手間 | WebP/AVIF対応したいが変換が面倒 |
サイズ統一 | SNS用、サムネイル用など複数サイズが必要 |
メタデータ削除 | 位置情報などプライバシー情報を削除したい |
品質と容量のバランス | 最適な圧縮率がわからない |
処理の再現性 | 同じ処理を繰り返し実行したい |
構成例
/.claude/skills/
└── image-processing/
├── SKILL.md # ハブ（使い方・ツール選択）
│
├── scripts/ # 実行スクリプト
│ ├── resize.sh # リサイズ
│ ├── convert-format.sh # フォーマット変換
│ ├── optimize.sh # 最適化
│ ├── batch-process.sh # 一括処理
│ ├── thumbnail.sh # サムネイル生成
│ ├── watermark.sh # 透かし追加
│ ├── info.sh # 画像情報取得
│ └── strip-metadata.sh # メタデータ削除
│
├── node-scripts/ # Node.js版（Sharp使用）
│ ├── resize.mjs
│ ├── convert.mjs
│ ├── optimize.mjs
│ └── batch.mjs
│
├── recipes/ # 用途別レシピ
│ ├── web-optimization.md # Web用最適化
│ ├── social-media.md # SNS用画像生成
│ ├── ogp-images.md # OGP画像生成
│ └── responsive-images.md # レスポンシブ画像セット
│
├── reference/ # リファレンス
│ ├── imagemagick.md # ImageMagickコマンド集
│ ├── sharp.md # Sharp API
│ ├── formats.md # 画像フォーマット比較
│ └── quality-guide.md # 品質設定ガイド
│
└── setup.md # 環境セットアップ
使い方
「この画像を800x600にリサイズして」 「imagesフォルダ内の画像をすべてWebPに変換して」 「ブログ用に画像を最適化して」 「SNS用のサムネイルを生成して」 「OGP画像を1200x630で作成して」 「画像からEXIF情報を削除して」 「フォルダ内の画像を一括で圧縮して」 「透かしを追加して」
ユースケース19: 画像生成プロンプト作成
概要
Nabo Bananaなどの画像生成AIに最適化されたプロンプトを生成する。対話形式で被写体、色調、スタイル、構図を選択し、ベストプラクティスに沿った高品質なプロンプトを自動生成する。一貫性のあるビジュアルスタイルを維持し、効率的な画像制作ワークフローを実現する。
- プロンプト構造・基本要素
- スタイル辞書（アート様式、時代、媒体）
- 色調・ライティング設定
- 構図・アングル・カメラ設定
- 品質向上キーワード
- ネガティブプロンプト
- ツール別最適化（Midjourney, DALL-E, SD等）
- 対話フロー・テンプレート
解決する課題
課題 | 詳細 |
|---|---|
プロンプトの書き方がわからない | 何をどう書けば良い画像になるか不明 |
生成結果が安定しない | 毎回違うテイストになってしまう |
一貫性のあるスタイルが作れない | シリーズものの統一感が出せない |
キーワードの語彙が足りない | 表現したいことを言語化できない |
ツールごとの違いがわからない | Midjourney向け、SD向けなど最適化できない |
品質が上がらない | クオリティを上げるキーワードを知らない |
試行錯誤が多い | 理想の画像まで何度も生成が必要 |
ネガティブプロンプトが書けない | 避けたい要素の指定方法がわからない |
構成例
/.claude/skills/
└── image-prompt/
├── SKILL.md # ハブ（対話フロー）
│
├── structure/ # プロンプト構造
│ ├── SKILL.md # 基本構造
│ ├── elements.md # 構成要素
│ ├── order.md # 要素の順序・重み付け
│ └── syntax.md # 構文・記法
│
├── vocabulary/ # 語彙辞書
│ ├── SKILL.md # 辞書の使い方
│ ├── styles.md # アートスタイル
│ ├── mediums.md # 媒体・技法
│ ├── artists.md # アーティスト参照
│ ├── eras.md # 時代・年代
│ ├── moods.md # 雰囲気・感情
│ └── aesthetics.md # 美学・世界観
│
├── visual/ # ビジュアル要素
│ ├── SKILL.md # ビジュアル設定
│ ├── colors.md # 色彩・カラーパレット
│ ├── lighting.md # ライティング
│ ├── composition.md # 構図
│ ├── camera.md # カメラ・アングル
│ └── textures.md # テクスチャ・質感
│
├── quality/ # 品質設定
│ ├── SKILL.md # 品質向上の基本
│ ├── enhancers.md # 品質向上キーワード
│ ├── negative.md # ネガティブプロンプト
│ └── parameters.md # パラメータ設定
│
├── tools/ # ツール別最適化
│ ├── SKILL.md # ツール選択ガイド
│ ├── midjourney.md # Midjourney
│ ├── dalle.md # DALL-E
│ ├── stable-diffusion.md # Stable Diffusion
│ └── nano-banana.md # Nano Banana Pro
│
├── templates/ # テンプレート
│ ├── character.md # キャラクター
│ ├── landscape.md # 風景
│ ├── product.md # プロダクト
│ ├── portrait.md # ポートレート
│ ├── concept-art.md # コンセプトアート
│ ├── icon.md # アイコン・ロゴ
│ └── ui-mockup.md # UIモックアップ
│
├── workflows/ # ワークフロー
│ ├── iterative.md # 反復改善
│ ├── variations.md # バリエーション生成
│ └── consistency.md # 一貫性維持
│
└── config.md # プロジェクト固有設定
使い方
対話形式での生成:
「ブログのアイキャッチ画像を作りたい」
Claude: 了解です。いくつか質問させてください。
1. 被写体は何ですか？
→ プログラミングに関する記事のアイキャッチ
2. どんな雰囲気にしますか？
a) モダン・テック感
b) 温かみ・親しみやすい
c) クール・プロフェッショナル
d) その他
→ a
3. 色調の好みは？
a) ダークモード（暗め）
b) ライトモード（明るめ）
c) ビビッド（鮮やか）
d) パステル（柔らかい）
→ a
4. 使用ツールは？
→ Midjourney
生成されたプロンプト:
「modern tech workspace, floating code snippets, holographic UI elements,
dark background with cyan and purple accent lighting, isometric view,
clean minimal aesthetic, digital art, 4K, highly detailed --ar 16:9 --v 6」
他にも、4コマ漫画や図解、インフォグラフィックなどの生成用スキルも活用している。
ユースケース20: 音楽生成プロンプト作成（Suno等）
概要
Sunoなどの音楽生成AI向けに最適化されたプロンプトを生成する。対話形式でジャンル、ムード、テンポ、楽器構成を選択し、イメージ通りの楽曲を生成する。BGM制作、ジングル作成、プロトタイピングなど用途に応じた一貫性のある音楽制作ワークフローを実現する。歌詞生成、スタイル指定、バリエーション展開までをカバーする。
- プロンプト構造・基本要素
- ジャンル辞書（ロック、ポップ、エレクトロニカ等）
- ムード・感情設定
- テンポ・BPM指定
- 楽器・音色設定
- 歌詞生成・構造設計
- ツール別最適化（Suno, Udio等）
- 対話フロー・テンプレート
解決する課題
課題 | 詳細 |
|---|---|
プロンプトの書き方がわからない | 何を書けばイメージ通りの曲になるか不明 |
ジャンルの指定が曖昧 | 細かいサブジャンルを知らない |
生成結果が安定しない | 毎回違うテイストになってしまう |
ムードの表現が難しい | 感情やシーンを音楽で表現できない |
楽器構成の知識がない | どの楽器を指定すればいいかわからない |
歌詞の構造がわからない | Verse、Chorus等の構成が不明 |
BGMとして使えない | ボーカルなしの曲を作りたい |
一貫性が保てない | シリーズもののBGMがバラバラ |
構成例
/.claude/skills/
└── music-prompt/
├── SKILL.md # ハブ（対話フロー）
│
├── structure/ # プロンプト構造
│ ├── SKILL.md # 基本構造
│ ├── elements.md # 構成要素
│ ├── song-structure.md # 曲構成（Verse, Chorus等）
│ └── syntax.md # ツール別構文
│
├── vocabulary/ # 語彙辞書
│ ├── SKILL.md # 辞書の使い方
│ ├── genres.md # ジャンル一覧
│ ├── subgenres.md # サブジャンル詳細
│ ├── moods.md # ムード・感情
│ ├── eras.md # 時代・年代
│ └── artists.md # アーティスト参照
│
├── musical/ # 音楽要素
│ ├── SKILL.md # 音楽要素の基本
│ ├── instruments.md # 楽器・音色
│ ├── tempo.md # テンポ・BPM
│ ├── key-scale.md # キー・スケール
│ ├── dynamics.md # ダイナミクス
│ └── production.md # プロダクション・音質
│
├── lyrics/ # 歌詞生成
│ ├── SKILL.md # 歌詞生成の基本
│ ├── structure.md # 歌詞構造
│ ├── themes.md # テーマ・トピック
│ ├── techniques.md # 作詞テクニック
│ └── metatags.md # メタタグ（[Verse]等）
│
├── tools/ # ツール別最適化
│ ├── SKILL.md # ツール選択ガイド
│ ├── suno.md # Suno
│ ├── udio.md # Udio
│ └── musicfx.md # MusicFX
│
├── templates/ # テンプレート
│ ├── bgm.md # BGM・インスト
│ ├── jingle.md # ジングル・SE
│ ├── pop-song.md # ポップソング
│ ├── cinematic.md # シネマティック
│ └── ambient.md # アンビエント
│
├── workflows/ # ワークフロー
│ ├── iteration.md # 反復改善
│ ├── variations.md # バリエーション生成
│ └── series.md # シリーズBGM制作
│
└── config.md # プロジェクト固有設定
使い方
対話形式での生成:
User: YouTube動画のBGMを作りたい
Claude: 了解です！音楽生成プロンプトを作成しますね。
1. どんなジャンルが良いですか？
a) エレクトロニック/EDM
b) ローファイ/チル
c) シネマティック/オーケストラ
d) ポップ/ロック
→ b
2. 動画の雰囲気は？
a) リラックス・落ち着き
b) 集中・作業用
c) 楽しい・明るい
d) 感動・エモーショナル
→ b
3. テンポの好みは？
a) スロー（70-90 BPM）
b) ミディアム（90-120 BPM）
c) アップテンポ（120-140 BPM）
→ a
生成されたプロンプト:
「lofi hip hop, study beats, chill instrumental,
mellow piano, warm vinyl crackle, soft drums,
relaxing atmosphere, 85 BPM, no vocals」
ドキュメント・ナレッジ系ユースケース
ユースケース21: 会議のアジェンダ作成
概要
会議前の目的・ゴールの明確化、論点整理、時間配分設計を効率化し、会議の質を向上させる。決定事項・アクションアイテムの抽出、フォーマット統一までをカバーする。組織の情報公開・透明性向上にも貢献する。ゴールや議題の決まっていない打ち合わせは嫌いである
- アジェンダ設計（目的、ゴール、論点）
- 時間配分・タイムボックス
- 決定事項・アクションアイテム抽出
- 参加者・役割管理
- フォローアップ・共有
- 会議タイプ別テンプレート
解決する課題
課題 | 詳細 |
|---|---|
アジェンダ作成に時間がかかる | 毎回ゼロから作成している |
会議の目的が曖昧 | 何を決めるか不明確なまま開始 |
論点が整理されていない | 話が脱線し時間が足りなくなる |
決定事項が曖昧 | 何が決まったか不明確 |
アクションアイテムが追跡されない | 担当・期限が曖昧で実行されない |
フォーマットがバラバラ | 人によって書き方が異なる |
情報共有が不十分 | 参加していない人に伝わらない |
構成例
/.claude/skills/
└── meeting-docs/
├── SKILL.md # ハブ（作成フロー）
│
├── agenda/ # アジェンダ作成
│ ├── SKILL.md # アジェンダ設計の基本
│ ├── structure.md # 構成要素
│ ├── goals.md # 目的・ゴール設定
│ ├── time-boxing.md # 時間配分
│ └── preparation.md # 事前準備・共有
│
├── templates/ # 会議タイプ別
│ ├── standup.md # デイリースタンドアップ
│ ├── sprint-review.md # スプリントレビュー
│ ├── retrospective.md # 振り返り
│ ├── one-on-one.md # 1on1
│ ├── kickoff.md # キックオフ
│ ├── brainstorm.md # ブレインストーミング
│ ├── decision.md # 意思決定会議
│ ├── status-report.md # 進捗報告
│ └── all-hands.md # 全体会議
│
├── facilitation/ # ファシリテーション
│ ├── SKILL.md # 進行の基本
│ ├── roles.md # 役割分担
│ ├── techniques.md # ファシリテーション技法
│ └── remote.md # リモート会議のコツ
│
├── follow-up/ # フォローアップ
│ ├── SKILL.md # フォローアップの基本
│ ├── sharing.md # 共有・公開
│ ├── tracking.md # 進捗追跡
│ └── feedback.md # フィードバック収集
│
├── formats/ # 出力形式
│ ├── markdown.md # Markdown形式
│ ├── notion.md # Notion形式
│ └── confluence.md # Confluence形式
│
└── config.md # プロジェクト固有設定
使い方
アジェンダ作成:
「来週の開発進捗会議のアジェンダを作って」
Claude: 了解です！いくつか確認させてください。
1. 会議の主な目的は？
a) 進捗確認・報告
b) 課題解決・意思決定
c) ブレインストーミング
d) 情報共有
→ a, b
2. 参加者は？
→ 開発チーム5名、PM1名
3. 所要時間は？
→ 60分
4. 特に話し合いたい議題は？
→ スプリント遅延の原因と対策
生成されたアジェンダ:
「## 開発進捗会議
日時: 2025/1/7 14:00-15:00
参加者: 開発チーム、PM
### 目的
- 現在のスプリント進捗を確認する
- 遅延の原因を特定し対策を決定する
### アジェンダ
1. [5分] 前回アクションアイテム確認
2. [15分] 各担当の進捗報告
3. [20分] 遅延原因の分析と対策検討
4. [10分] 次スプリントの優先度確認
5. [5分] アクションアイテム確認・まとめ
6. [5分] バッファ」
ユースケース22: ナレッジDB管理
概要
関心のある情報（記事、動画、書籍、論文、ポッドキャストなど）を一元管理し、知見・思考・学びを蓄積する。プレゼン・登壇資料作成時の引用元として、ブログ記事執筆の参考材料として、SNS発信のネタ元として活用する。Zettelkasten、PARA、Second Brainなどの知識管理手法を取り入れ、情報を「消費」から「資産」に変える。
- 情報収集・インポート
- 分類・タグ付け体系
- 要約・メモ・ハイライト
- 引用・参照管理
- リンク・関連付け
- 検索・発見
- 活用（プレゼン、記事、SNS）
- メンテナンス・棚卸し
解決する課題
課題 | 詳細 |
|---|---|
情報の散在 | ブックマーク、メモ、スクショがバラバラ |
「あの記事どこだっけ」 | 読んだはずの情報が見つからない |
読んで終わり | インプットが活用されない |
知識の属人化 | 個人の頭の中にだけある |
再利用性の低さ | 毎回ゼロから調べ直し |
引用元がわからない | 出典を探すのに時間がかかる |
情報の陳腐化 | 古い情報が更新されない |
発信ネタがない | インプットはあるがアウトプットに繋がらない |
構成例
/.claude/skills/
└── knowledge-db/
├── SKILL.md # ハブ（運用フロー）
│
├── capture/ # 情報収集
│ ├── SKILL.md # 収集の基本
│ ├── sources.md # 情報ソース別の収集方法
│ ├── quick-capture.md # クイックキャプチャ
│ └── import.md # 一括インポート
│
├── processing/ # 情報処理
│ ├── SKILL.md # 処理の基本
│ ├── summarize.md # 要約・抽出
│ ├── highlight.md # ハイライト・メモ
│ ├── tagging.md # タグ付け
│ └── linking.md # 関連付け・リンク
│
├── organization/ # 整理・分類
│ ├── SKILL.md # 整理の基本
│ ├── categories.md # カテゴリ体系
│ ├── tags.md # タグ設計
│ ├── para.md # PARAメソッド
│ └── zettelkasten.md # Zettelkasten
│
├── retrieval/ # 検索・発見
│ ├── SKILL.md # 検索の基本
│ ├── search.md # 検索方法
│ ├── browse.md # ブラウジング
│ └── serendipity.md # 偶発的発見
│
├── output/ # 活用・アウトプット
│ ├── SKILL.md # 活用の基本
│ ├── presentation.md # プレゼン・登壇
│ ├── writing.md # 記事・ブログ
│ ├── social.md # SNS発信
│ └── citation.md # 引用・参照
│
├── maintenance/ # メンテナンス
│ ├── SKILL.md # メンテナンスの基本
│ ├── review.md # 定期レビュー
│ ├── archive.md # アーカイブ・削除
│ └── update.md # 情報更新
│
└── templates/ # テンプレート
├── article.md # 記事
├── video.md # 動画
├── book.md # 書籍
├── paper.md # 論文
└── podcast.md # ポッドキャスト
使い方
情報の登録:
「この記事をナレッジDBに追加して https://example.com/article-about-llm-agents」
Claude: 記事を分析しました。以下の内容で登録します：
タイトル: LLMエージェントの設計パターン
URL: https://example.com/article-about-llm-agents
カテゴリ: AI/LLM
タグ: #エージェント #設計パターン #LLM
追加日: 2025/01/01
要約（自動生成）:
LLMエージェントの主要な設計パターンを解説。
ReAct、Plan-and-Execute、Multi-Agent等の
アーキテクチャの特徴と使い分けを説明している。
ハイライト/メモを追加しますか？
知識の活用:
「LLMエージェントについてプレゼンするんだけど、参考になる記事をナレッジDBから探して」
Claude: LLMエージェント関連の記事を5件見つけました：
1. 📄 LLMエージェントの設計パターン
- ReAct、Plan-and-Execute等のアーキテクチャ比較
- 引用に使える: 「エージェント設計の主要パターン」
2. 📄 Claude MCPの仕組み
- ツール連携の実装方法
- 引用に使える: 「外部ツール連携の実例」
3. 📺 AI Agent解説動画
- 概念のわかりやすい説明
- スライドの参考に
これらを使ってプレゼン構成案を作成しますか？
SNSネタの発見:
「今週インプットした内容からSNS投稿ネタを提案して」
Claude: 今週追加された12件から、発信ネタを3つ提案します：
1. 🔥 反響が見込めるネタ
「LLMエージェントの設計パターン」から
→ 「エージェント設計で最も重要なのは〇〇」
2. 💡 学びの共有
「プロンプトエンジニアリング実践」から
→ 「プロンプトで失敗しがちな3つのパターン」
3. 🔗 キュレーション
今週読んだAI関連記事5選としてまとめ投稿
どれを深掘りしますか？
番外編（今後実践したい）
以下のユースケースは、今後実践したいと考えているものである。
ブランドガイドライン遵守チェック
概要: 企業のブランドガイドラインに沿った文書やコンテンツを作成する。トーン＆マナー、ロゴ使用規定、カラーパレットなどの準拠をチェックする。企業利用で需要が高いユースケースである。
ポートフォリオ管理
概要: 経歴書や職務経歴書の作成・最適化を支援する。プロジェクト経験の言語化、強みの整理、業界・職種に合わせた調整を行う。キャリア形成を継続的にサポートする。
まとめ
本記事では、Agent Skillsの実践的なユースケースを24個を3つのカテゴリ（+番外編）に分けて紹介した。
開発系（10個）: オンボーディング効率化、コーディングルール・詳細設計、パフォーマンス最適化、コードレビュー・品質チェック、セキュリティチェック、テスト計画・テストコード生成、デバッグ・調査、リファクタリング、ドキュメント・仕様書作成、フロントエンドデザイン
コンテンツ作成・クリエイティブ系（10個）: SEOに最適化されたブログ記事作成、ブログ記事リライト、X投稿最適化、YouTubeメタデータ生成、Chromeストアの申請チェック、リリースノート生成、FAQや想定質問生成、画像処理・変換、画像生成プロンプト作成、音楽生成プロンプト作成
ドキュメント・ナレッジ系（2個）: 会議のアジェンダ作成、ナレッジDB管理
番外編（今後実践したい）（2個）: ブランドガイドライン遵守チェック、ポートフォリオ管理
Agent Skillsは、一度作成すれば繰り返し活用できる。まずは自分がよく行うタスクを1つ選び、小さなスキルから始めてみることを推奨する。
