公式スキル · プロダクト

競合製品のティアダウン

v1.0.0・2026年11月4日更新

公開ページやトライアルのメモから競合を分解する。オンボーディング、料金、コアループ、強み、弱み、まねること・まねないこと、未確認の印。

Claude・ChatGPT・コーディング用の AI で使えます。TeamとBusiness では、Pod に入れた公式スキルが改善のたびに自動で最新版になります。

使う場面

• 競合がすでに持っているオンボーディング、料金、機能を設計する前
• だれかが競合製品を試し、メモがあるとき

AI に渡すもの

• 競合の名前と、見た日付つきの証拠
• チームが知りたいこと
• 自社製品の相当する部分（なくてもよい）

できあがるもの

オンボーディングの表、料金の表、コアループ、強み、弱み、まねる・まねない・差をつける、確かめることの一覧がそろったティアダウン。

手順

1. すべての主張に出どころの印をつける 事実ごとに「確認済み」（トライアルのメモか引用したページの文面で見たもの。日付つき）か「未確認」（記憶、レビューサイト、推測）。料金とプランの制限はよく変わる。入力で見ていない価格は書かず、「[要確認: 現在の価格]」と書く。
2. オンボーディングを1ステップずつ書き出す 最初のページから、最初に価値を感じる瞬間まで。画面ごとに、何を聞くか、入力欄の数、クレジットカードが必要か、メモにあればかかった時間。ステップの数を数える。新しい利用者がつまずきそうなところに印をつける。
3. 料金とプランの組み方を並べる プラン、プランを分ける制限（シート数、使用量、機能）、無料プランかトライアル、アップグレードのきっかけ（製品がお金を求める瞬間）。入力にあるものだけで。
4. コアループを説明する 利用者がくり返す行動は何か、何が返ってくるか、何が利用者を呼び戻すか（メール、通知、共有された作業）。短い1段落で。
5. 強みと弱みを並べる 役に立つところでは、NN/g の10のユーザビリティ原則を視点に使う。システムの状態の見せ方、わかりやすい言葉、エラーからの回復、ヘルプ。強みは、なくなったら利用者が困るもの。弱みは、利用者がつまずくところ、価値を見る前にお金を払うところ、助けが必要なところ。
6. まねること、まねないこと、差をつけるところを決める NN/g の競合評価の助言: 強み、傾向、独自の解決策、すきまを探し、わかったことを自社製品への提案に変える。まねるのは自社の利用者に合うものだけにし、それぞれ理由を書く。「まねない」には、相手の規模、ブランド、顧客層だからこそうまくいっているものを入れる。
7. 次に確かめることを並べる 判断にかかわる未確認の主張は、それぞれ確認の作業にする。トライアルに登録する、料金ページを読む、乗り換えた顧客に聞く。

SKILL.md の全文

AI が読むファイルそのものです。 ダウンロード

---
name: product-teardown
description: 競合製品の分解レポート（ティアダウン）を、公開ページ、無料トライアル、文章で説明したスクリーンショット、利用者のトライアルのメモから書く。オンボーディングの手順、料金とプランの組み方、コアループ、強み、弱み、まねること・まねないことを、すべての主張に確認済みか未確認かの印をつけてまとめる。競合のティアダウン、製品の競合分析、「X はどうやって新規ユーザーを立ち上げているか」「X の料金の決め方は」、競合製品から何を学べるかを聞かれたときに使う。
---

# 競合製品のティアダウン

ティアダウンが役に立つのは、チームが月曜から何を変えればよいかがわかるとき。製品が実際に何をするかを、証拠から1ステップずつ書く。見たことと推測を分ける。最後に、まねること、避けること、差をつけるところの短いリストで締める。目的は競合に勝つことで、競合を複製することではない。

## 使う場面

- 競合がすでに持っているオンボーディング、料金、機能を設計する前。
- 営業や経営陣から、競合について「あそこはどうやっている？」と聞かれたとき。
- だれかが競合のトライアルを終え、メモがあるとき。
- 反論への対応つきの営業向けバトルカードには使わない（competitor-battlecard を使う）。買う製品の選定にも使わない（vendor-comparison を使う）。

## 用意するもの

- 競合の名前と証拠。公開ページの文面、料金ページの文面、ヘルプ記事、トライアルのメモ、説明つきのスクリーンショット。それぞれ見た日付つきで。
- チームが知りたいこと（オンボーディング、料金、ある機能）。なければ一度だけ聞く。それでもなければ、すべての項目を書く。
- あれば、比べるための自社製品の相当する部分。

## 手順

1. **すべての主張に出どころの印をつける。** 事実ごとに「確認済み」（トライアルのメモか引用したページの文面で見たもの。日付つき）か「未確認」（記憶、レビューサイト、推測）。料金とプランの制限はよく変わる。入力で見ていない価格は書かず、「[要確認: 現在の価格]」と書く。
2. **オンボーディングを1ステップずつ書き出す。** 最初のページから、最初に価値を感じる瞬間まで。画面ごとに、何を聞くか、入力欄の数、クレジットカードが必要か、メモにあればかかった時間。ステップの数を数える。新しい利用者がつまずきそうなところに印をつける。
3. **料金とプランの組み方を並べる。** プラン、プランを分ける制限（シート数、使用量、機能）、無料プランかトライアル、アップグレードのきっかけ（製品がお金を求める瞬間）。入力にあるものだけで。
4. **コアループを説明する。** 利用者がくり返す行動は何か、何が返ってくるか、何が利用者を呼び戻すか（メール、通知、共有された作業）。短い1段落で。
5. **強みと弱みを並べる。** 役に立つところでは、NN/g の10のユーザビリティ原則を視点に使う。システムの状態の見せ方、わかりやすい言葉、エラーからの回復、ヘルプ。強みは、なくなったら利用者が困るもの。弱みは、利用者がつまずくところ、価値を見る前にお金を払うところ、助けが必要なところ。
6. **まねること、まねないこと、差をつけるところを決める。** NN/g の競合評価の助言: 強み、傾向、独自の解決策、すきまを探し、わかったことを自社製品への提案に変える。まねるのは自社の利用者に合うものだけにし、それぞれ理由を書く。「まねない」には、相手の規模、ブランド、顧客層だからこそうまくいっているものを入れる。
7. **次に確かめることを並べる。** 判断にかかわる未確認の主張は、それぞれ確認の作業にする。トライアルに登録する、料金ページを読む、乗り換えた顧客に聞く。

## 出力の形式

```markdown
# ティアダウン: [競合] — [焦点]

**証拠:** [出どころと見た日付] · **作成日:** [日付]

## 要点
- [3つの箇条書き: チームが知っておくべきいちばん大事なこと]

## オンボーディング
| # | 画面 / ステップ | 何を聞くか | メモ | 出どころ |
|---|---|---|---|---|
| 1 | [ステップ] | [入力欄か選択肢] | [つまずきか強み] | 確認済み [日付] / 未確認 |

**最初の価値までのステップ数:** [n] · **カードの登録:** [必要 / 不要 / 未確認]

## 料金とプランの組み方
| プラン | 価格 | 主な制限 | 出どころ |
|---|---|---|---|
| [プラン] | [見たとおりか要確認] | [制限] | 確認済み [日付] / 未確認 |

**アップグレードのきっかけ:** [製品がお金を求めるとき]

## コアループ
[1段落。]

## 強み
- [強み] — [証拠]

## 弱み
- [弱み] — [証拠]

## 自社にとって
- **まねる:** [何を] — [自社の利用者に合う理由]
- **まねない:** [何を] — [合わない理由]
- **差をつける:** [はっきり上回れるところ]

## 確かめること
- [未確認の主張] — [確かめ方]
```

## 例

**入力（トライアルのメモ、5月2日）:** 「レジャリーに登録した。ステップ1: メールアドレスとパスワード。ステップ2:『お仕事は？』のプルダウン、選択肢12個。ステップ3: 銀行口座の連携 — スキップできる。ステップ4: 最初の請求書のテンプレートを選ぶ。サンプルの取引先が入力済み。約4分でテストの請求書を送れた。カードは聞かれなかった。料金ページ: Free（月5件まで）、Pro、Team — Pro の価格はメモしていない。送った請求書にはすべて『レジャリーで送信』のフッターがつく。翌日、自分あてに『請求書が開封されました』のメール。値上げするといううわさを聞いた」

**出力:**

```markdown
# ティアダウン: レジャリー — オンボーディングと料金

**証拠:** トライアルのメモ、5月2日 · **作成日:** [日付]

## 要点
- 新しい利用者は、カードを登録せずに約4分で最初の請求書を送れる。サンプルの取引先が、白紙から始める問題をなくしている。
- 無料プランの制限は月あたりの請求書の件数なので、実際に使いはじめるとアップグレードのきっかけが来る。
- 無料の請求書にはすべてブランドがつき、利用者の取引先に届く。

## オンボーディング
| # | 画面 / ステップ | 何を聞くか | メモ | 出どころ |
|---|---|---|---|---|
| 1 | 登録 | メールアドレス、パスワード | ふつう | 確認済み 5月2日 |
| 2 | 職業 | プルダウン、選択肢12個 | 長い。新しい利用者には目的がわからない | 確認済み 5月2日 |
| 3 | 銀行口座の連携 | 口座の連携 | スキップできる。よい | 確認済み 5月2日 |
| 4 | 最初の請求書 | テンプレート、サンプルの取引先が入力済み | 強み: 完成した請求書がすぐ見える | 確認済み 5月2日 |

**最初の価値までのステップ数:** 4 · **カードの登録:** 不要

## 料金とプランの組み方
| プラン | 価格 | 主な制限 | 出どころ |
|---|---|---|---|
| Free | 無料 | 月5件まで | 確認済み 5月2日 |
| Pro | [要確認: 現在の価格] | [要確認: 制限] | メモなし |
| Team | [要確認: 現在の価格] | [要確認: 制限] | メモなし |

**アップグレードのきっかけ:** その月の6件目の請求書 [仮定。無料の制限から]。

## コアループ
利用者が請求書を送り、取引先がそれを開き、レジャリーが開封されたことを利用者にメールで知らせる。そのメールが、入金を確かめに利用者を呼び戻す。「レジャリーで送信」のフッターが、すべての取引先に製品を見せる。

## 強み
- 入力済みの最初の請求書 — 約4分で最初の価値。
- 「請求書が開封されました」のメール — 翌日に戻ってくる理由になる。

## 弱み
- 価値を見せる前に、選択肢12個の職業のプルダウン。
- 値上げのうわさ — 未確認。

## 自社にとって
- **まねる:** 入力済みのサンプルの請求書 — 自社の利用者も白紙の画面から始めている [要確認: 自社のデータ]。
- **まねない:** 有料プランでもブランドのフッターをつけること — 自社の利用者は、自社のブランドで仕事を納める制作会社 [要確認]。
- **差をつける:** 最初の請求書までは何も聞かない。職業の質問はそのあとに回す。

## 確かめること
- Pro と Team の価格と制限 — 料金ページを読み、日付を記録する。
- 値上げ — 変更履歴かお知らせを確かめる。見つからなければ削る。
- 有料プランでもフッターが出るか — 有料プランを試すか、ヘルプ記事を読む。
```

## 送る前のチェック

- [ ] オンボーディングと料金のすべての行に、出どころの印（日付つきの確認済みか、未確認）がある。
- [ ] 入力にない価格、制限、数字を書いていない。
- [ ] うわさと推測には、未確認か「[仮定]」の印がある。
- [ ] 「自社にとって」に、まねる、まねない、差をつけるが少なくとも1つずつあり、それぞれ理由がある。
- [ ] 提案に影響する未確認の主張は、すべて「確かめること」にある。

## よくある失敗

- 機能の一覧を書く。ティアダウンは利用者の通る道をたどる。ステップの順番そのものが発見になる。
- 見えているからという理由で、競合の料金をまねる。相手の制限は相手のコストと顧客層に合わせたもので、自社のものではない。
- 覚えている価格を事実として書く。料金ページは変わる。見たものに日付をつける。

チームで使う

AI Skill Pod に追加すると、業務委託の方も含めてチーム全員が、自分の AI から同じ版を使えます。 AI スキルをチームで共有する方法を読む

チームのPodに追加

変更履歴

• v1.0.0 · 2026年11月4日 · First release.