claude/skills/ideation-competitor-analysis/SKILL.md
直接競合・間接競合を分析し、差別化ポイントを明確にする。新規プロダクト企画時、市場参入前の調査、既存プロダクトのポジショニング見直し時に使用。「競合を分析したい」「差別化ポイントを見つけたい」「市場調査」「既存の解決策を調べたい」などのリクエストで起動。
npx skillsauth add skanehira/dotfiles ideation-competitor-analysisInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
対話とWebサーチを通じて競合を分析し、以下を生成する:
前のステップの出力ファイルを読み込む。
docs/PROBLEM_DEFINITION.mdRead({ file_path: "docs/PROBLEM_DEFINITION.md" })
読み込んだ内容から以下を抽出し、フェーズ1で活用:
遷移条件: フェーズ1へ(対象ジョブの質問をスキップ可能)
フェーズ1でAskUserQuestionを使って対象ジョブを確認。
遷移条件: フェーズ1へ
分析対象を明確にする。
注: フェーズ0でPROBLEM_DEFINITION.mdを読み込み済みの場合、対象ジョブの質問はスキップし、既知の競合の確認のみ行う。
AskUserQuestion({
questions: [
{
question: "どのような問題/ジョブに対する競合を分析しますか?",
header: "対象ジョブ",
options: [
{ label: "ジョブを入力", description: "ユーザーが達成したいこと" }
],
multiSelect: false
},
{
question: "すでに知っている競合はありますか?",
header: "既知の競合",
options: [
{ label: "ある", description: "競合名を入力" },
{ label: "ない", description: "これから調査する" }
],
multiSelect: false
}
]
})
遷移条件: 対象ジョブが明確になったらフェーズ2へ
直接競合と間接競合を洗い出す。
同じ問題を同じ方法で解決しようとしているプロダクト。
WebSearch({
query: "[対象領域] ツール 比較"
})
同じ問題を異なる方法で解決しているもの。
考えるべき間接競合:
AskUserQuestion({
questions: [
{
question: "ユーザーは今、この問題をどうやって解決していますか?(ツールを使わない方法も含む)",
header: "現状の解決策",
options: [
{ label: "解決策を入力", description: "例: 手動でEXPLAIN分析、外部DBAに依頼" }
],
multiSelect: false
}
]
})
遷移条件: 競合が5-10個リストアップできたらフェーズ3へ
各競合について情報を収集する。
WebSearch({
query: "[競合名] 機能 価格 レビュー"
})
| 項目 | 説明 | | -------------- | -------------------------- | | 概要 | 何をするプロダクトか | | ターゲット | 誰向けか | | 主要機能 | コア機能は何か | | 価格 | 料金体系 | | 強み | ユーザーに評価されている点 | | 弱み | 不満や欠点 |
遷移条件: 主要競合3-5個の情報が揃ったらフェーズ4へ
競合を軸に沿って比較する。
AskUserQuestion({
questions: [
{
question: "ユーザーにとって重要な選択基準は何ですか?(3-5個)",
header: "比較軸",
options: [
{ label: "基準を入力", description: "例: 使いやすさ、価格、精度、対応DB" }
],
multiSelect: false
}
]
})
| 競合 | 軸1 | 軸2 | 軸3 | 軸4 | | ------ | --- | --- | --- | --- | | 競合A | ◎ | △ | ○ | × | | 競合B | ○ | ◎ | △ | ○ | | 手作業 | △ | ◎ | × | ○ |
遷移条件: 比較表が完成したらフェーズ5へ
競合と比較して、どこで勝てるかを明確にする。
質問パターン:
AskUserQuestion({
questions: [
{
question: "競合と比較して、どこで差別化できそうですか?",
header: "差別化",
options: [
{ label: "差別化ポイントを入力", description: "競合より優れている点、競合にはない点" }
],
multiSelect: false
}
]
})
| 種類 | 説明 | 例 | | -------------------- | ------------------ | ----------------- | | 機能差別化 | 競合にない機能 | 実測ベンチマーク | | ターゲット差別化 | 異なるセグメント | DBA不在チーム向け | | 価格差別化 | 価格帯が異なる | 安価、従量課金 | | 体験差別化 | UXが優れている | 30秒で結果が出る | | 統合差別化 | 既存ツールとの連携 | GitHub PR連携 |
遷移条件: 差別化ポイントが1-3個明確になったらフェーズ6へ
2軸で競合をマッピングする。
高機能
│
┌───────┼───────┐
│ B │ A │
│ │ ★ │ ← 自社
高価 ──────┼────── 安価
│ C │ D │
│ │ │
└───────┼───────┘
│
シンプル
AskUserQuestion({
questions: [
{
question: "ポジショニングマップの2軸は何にしますか?",
header: "軸の選択",
options: [
{ label: "軸を入力", description: "例: 価格 vs 機能、専門性 vs 使いやすさ" }
],
multiSelect: false
}
]
})
遷移条件: マップが作成できたらフェーズ7へ
# 競合分析
## 対象ジョブ
[ユーザーが達成したいこと]
## 競合マップ
### 直接競合
| 競合名 | 概要 | ターゲット |
|--------|------|-----------|
| ... | ... | ... |
### 間接競合
| 解決策 | 概要 | 長所 | 短所 |
|--------|------|------|------|
| 手作業 | ... | ... | ... |
## 競合比較表
| 競合 | 価格 | 機能 | 使いやすさ | ... |
|------|------|------|-----------|-----|
| ... | ... | ... | ... | ... |
## 競合詳細分析
### [競合A]
- **概要**: ...
- **ターゲット**: ...
- **主要機能**: ...
- **価格**: ...
- **強み**: ...
- **弱み**: ...
- **ユーザーの声**: ...
## ポジショニングマップ
[Mermaid or ASCII図]
## 差別化ポイント
1. **[差別化1]**: ...
2. **[差別化2]**: ...
## 結論・示唆
- ...
Write({
file_path: "docs/COMPETITOR_ANALYSIS.md",
content: competitorAnalysisContent
})
生成したドキュメントのレビューをサブエージェントに委譲する。
Task({
description: "競合分析レビュー",
subagent_type: "general-purpose",
prompt: `
以下の競合分析ドキュメントをレビューし、問題があれば修正してください。
## レビュー対象ファイル
- docs/COMPETITOR_ANALYSIS.md
## レビュー観点
1. **競合の網羅性**: 直接競合と間接競合が十分に洗い出されているか
2. **情報の正確性**: 各競合の情報が正確か、最新か
3. **比較の妥当性**: 比較軸がユーザーにとって重要な基準か
4. **差別化の明確さ**: 差別化ポイントが具体的で実現可能か
5. **ポジショニングの妥当性**: 選択した軸が適切か、マップが正確か
## 出力形式
1. 発見した問題のリスト(問題がない場合は「問題なし」)
2. 各問題の修正内容
3. 修正後のファイル更新(Editツールで修正)
問題がなくなるまでレビューと修正を繰り返すこと。
`
})
tools
ローカルのコミット履歴と差分からDraft PRを作成する。ブランチ未作成・コミット未作成の状態でも、必要に応じてブランチ作成とコミットを行ってからPRを作成する。`.github/` にPRテンプレートがあれば内容を埋めて、なければ作業内容から本文を生成し、`AskUserQuestion`で作成可否を確認してから `gh pr create --draft` を実行する。「PRを出したい」「draft PRを作成」「プルリクを作って」「PR本文を生成」などのリクエストで起動。
tools
複数サブエージェントに異なる立場を与えて議論を反復し、相違が収束するまで議題を検証して結論を提示する。設計妥当性検証・実装方針比較・原因分析のセカンドオピニオン・アイデアの壁打ちに使用。「議論したい」「壁打ちしたい」「セカンドオピニオン」「複数視点で検証したい」などで起動。
tools
変更内容を分析し、Conventional Commit形式でコミットする (pushはユーザが手動)
development
React 19 + Vite+ (`vp`) + TypeScript + Tailwind CSS v4 + React Router v7 (HashRouter) でモバイル向け静的SPAデモサイトをTDDで構築し、Cloudflare Workers (Static Assets) へ自動デプロイするまでの標準ワークフローを提供する。テンプレートリポジトリ `skanehira/demo-site-template` を `gh repo create --template` で clone することで scaffold を省略する。`localStorage` でフロントエンドのみ完結する"フロントのみ完結デモ"に特化。デザインコンセプトの確立には `frontend-design` スキルを呼び出して連携する。起動トリガー:「デモサイトを作りたい」「モバイル向け静的デモ」「SPAを作ってCloudflareにデプロイ」「静的プロトタイプを公開」「localStorage でフロントだけ完結」。ユースケース:(1)クライアント提案用のUI/UXたたき台、(2)新機能のプロトタイプ、(3)モバイル向けランディング。ツールチェーンは Vite+ (`vp`) で統合(内部 PM は pnpm)。