7-1 Claude Code で競合調査を自動化｜市場リサーチ

このレッスンで身につくこと

このレッスンは、第 7 章「データ分析」の入口になります。これまでの章で身につけた「Claude Code にやりたいことを伝える力」を、市場リサーチ という具体的な仕事に転用していきます。

競合調査は、営業・マーケ・プロダクト企画・経営企画など、ほぼすべてのビジネス職に共通して「やった方がいいけど、後回しになりがち」な仕事の代表格です。理由はシンプルで、情報を集める作業が異常に手間がかかる からです。Claude Code はここに直接効きます。

所要時間 — 約 60 分（実機ハンズオン込み。読むだけなら 30 分） 難易度 — ★★★☆☆（Claude Code の基本操作ができる前提）

なぜ競合調査を自動化したいのか

新人マーケターが上司から「うちの競合 5 社の最新動向、来週までにまとめておいて」と言われたとします。多くの人は、こうします。

1. 競合の公式サイトを 1 つずつブラウザで開く
2. プラン・価格・機能一覧をスクロールしながら コピペ
3. Excel に貼り付け、整形、表のスタイルを整える
4. レビューサイトを開き、星評価と上位コメントを書き写す
5. また来月、同じことを繰り返す

ここで失われている時間は「考える時間」ではなく、ほぼ全部「動かす時間」 です。考える時間 — つまり「この差は戦略上どういう意味を持つのか」「どの機能が真の差別化要因なのか」 — は、本当はもっと長く取りたいはずです。Claude Code に動かす時間を移譲すれば、その分を全部「考える時間」に再配分できます。

競合調査の典型タスク 5 種類

実務で発生する競合調査は、ほぼ次の 5 つに分類できます。最初にこの 5 種類を頭に入れておくと、Claude Code への指示がスッと出てきます。

レッスンの後半で、このうち ①②④ を具体的に Claude Code でやっていきます。③⑤ は応用編として、章末の Challenge で自分で再現してもらいます。

Web 情報の収集 — WebFetch ツールの使い方と限界

Claude Code は、Web 上のページを取得して読み込む WebFetch というツールを内蔵しています。これが競合調査の主力です。

基本の使い方

ターミナルで claude を起動し、URL を含むプロンプトを投げます。

> https://example-saas.com/pricing の料金プランを読んで、
> プラン名・月額・含まれる機能を Markdown のテーブルにして

このとき内部では、こういう流れが走ります。

1. Claude が「URL を指定された」と判断
2. ==WebFetch ツールを選択== し、URL を引数に実行
3. Anthropic のサーバ側が当該 URL を HTTP GET でフェッチし、HTML を取得
4. HTML を Markdown に変換して Claude のコンテキストに投入
5. Claude が指示どおり、料金テーブルだけを抽出して整形

ブラウザを開かなくても、人間がスクロールしなくても、機械的に情報が取れる — これが WebFetch の威力です。

WebFetch でできること・できないこと

万能ではありません。最初に「限界」を知っておく方が、トラブルが減ります。

ログインが必要なサイト、SPA で JS レンダリングが重いサイト は、WebFetch だけでは取れない場合があります。その場合は次のいずれかに切り替えます。

• MCP（Model Context Protocol） 経由で Firecrawl / Playwright を呼ぶ（第 8 章）
• ブラウザで開いて手動で本文をコピーして貼り付ける
• RSS フィード があればそちらを優先する

試しに 1 ページ取ってみる

具体例として、架空の SaaS の料金ページを取得するとします。

> 次の URL の料金プランを読み、プラン名・月額・最大ユーザ数・主要機能を
> Markdown テーブルにして。出典 URL も末尾に明記。
> https://example-saas.com/pricing

Claude はおおむねこういうアウトプットを返してきます。

## example-saas.com 料金プラン

| プラン | 月額 | 最大ユーザ | 主要機能 |
|---|---|---|---|
| Starter | $9 / 月 | 3 名 | 基本機能、メール通知 |
| Team | $29 / 月 | 10 名 | API、Slack 連携、優先サポート |
| Business | $99 / 月 | 50 名 | SSO、監査ログ、SLA |

出典: https://example-saas.com/pricing (取得日 2026-05-19)

出典 URL と取得日を必ず付ける — これは絶対のルールです。後で内容を検証するときに、自分が見たのと違うバージョンを Claude が見ていた、というのはよくあります。

競合の機能比較表を自動生成

ここから本番です。3 社 の SaaS を例に、機能比較マトリクスを自動生成します。

Step 1 — 比較項目を先に決める

プロンプトを書く前に、紙に比較したい項目を 7〜10 個書き出してください。これをやらずにいきなり Claude に投げると、「Claude が選んだ項目」で表が作られ、自社の戦略に必要な軸からズレた表が出てきます。

たとえば、CRM プロダクトの機能比較なら次のとおりです。

1. 月額（最小プラン）
2. 月額（中位プラン）
3. ユーザ数の上限
4. メール一斉送信機能
5. Slack 連携
6. API 公開
7. モバイルアプリ
8. SSO / SAML
9. 監査ログ
10. 日本語サポート

Step 2 — 3 社の URL を渡して取得させる

> 次の 3 つの URL から、CRM プロダクトの情報を取得してほしい。
> A 社: https://example-a.com/features
> B 社: https://example-b.com/features
> C 社: https://example-c.com/features
>
> 以下 10 項目で比較マトリクスを作って。
> 1. 月額(最小プラン) 2. 月額(中位プラン) 3. ユーザ数上限
> 4. メール一斉送信 5. Slack 連携 6. API 公開
> 7. モバイルアプリ 8. SSO/SAML 9. 監査ログ 10. 日本語サポート
>
> 機能の有無は ◯ / △ / ✕ で表現。
> 各セルの根拠 URL も別表で出して。

「根拠 URL を別表で出して」が決定的に重要 です。これを書かないと、Claude が「思い出し」で書く部分が混じってきます。「事実」と「Claude の推測」を明示的に分離させる ことが、ハルシネーションを防ぐ最大のコツです。

Step 3 — 結果を見て、足りない箇所を追撃指示

ほぼ確実に、いくつかのセルが 「情報なし」 や 「不明」 になります。それで OK です。「分からないことは分からない」と書ける Claude は むしろ信頼できる Claude です。

> 「情報なし」になっているセルを埋めたい。
> A 社の「監査ログ」については、公式の docs サイト
> https://docs.example-a.com を探して、関連ページを取ってきて。

1 回のプロンプトで完璧を狙わない。3〜4 回の会話で詰めていくのが Claude Code の正しい使い方です。

価格テーブル比較

次に 価格 にフォーカスした比較を作ります。価格は競合分析の中でも特に「間違えると経営に影響する 」情報です。慎重に取りに行きましょう。

価格を取るときの注意点

価格ページは、'次のような落とし穴 があります。

• 「年払いと月払いで違う」（表示は年払い、実際は月払いで請求すると倍）
• 「税込/税抜の表記が抜けている」
• 「最小ユーザ数の縛りがある」（「$9/ユーザ」と書いてあっても、最低 3 名から）
• 「上位プランは要問い合わせ」（価格非公開）
• 通貨が混在（USD / JPY / EUR）

これらを Claude に意識させるプロンプトはこうです。

> A 社・B 社・C 社の料金ページから、次の項目を必ず明示して比較表を作って。
> - プラン名
> - 表示価格（通貨を明記）
> - 課金単位（ユーザ / 月 / 年）
> - 最小契約ユーザ数
> - 税込 / 税抜
> - 年払い割引の有無
> - 「要問い合わせ」のプランは "要問い合わせ" と書く
>
> 価格を 1 円単位まで取らない。月額換算で四捨五入して OK。

出力例

## CRM プロダクト 価格比較（2026-05-19 時点）

| プラン | A 社 | B 社 | C 社 |
|---|---|---|---|
| 最小プラン | ¥1,200 / ユーザ / 月（税抜） | $9 / ユーザ / 月（税抜） | ¥1,500 / ユーザ / 月（税抜） |
| 中位プラン | ¥3,000 / ユーザ / 月（税抜） | $29 / ユーザ / 月（税抜） | ¥3,800 / ユーザ / 月（税抜） |
| 最上位プラン | 要問い合わせ | $99 / ユーザ / 月（税抜） | 要問い合わせ |
| 最小契約ユーザ数 | 3 名 | 1 名 | 5 名 |
| 年払い割引 | 20% | 15% | 10% |

出典:
- A 社: https://example-a.com/pricing
- B 社: https://example-b.com/pricing
- C 社: https://example-c.com/pricing

通貨が混在している場合は無理に円換算しない のが鉄則です。為替で揺れるので、レポートとしての信頼性が下がります。「USD と JPY が混在しています」と注釈をつけたまま並べる方が誠実です。

レビュー・SNS の感情分析

価格・機能の客観情報を取ったら、次は 顧客の生の声 を集めます。これが競合の本当の強みと弱みをあぶり出します。

どこから取るか

まずレビューサイトから攻めるのが王道 です。星評価という定量データと、自由記述という定性データが揃っているので、感情分析の素材として最適です。

プロンプト例

> https://example-review-site.com/products/example-saas のレビューを読み、
> 次の構造で要約して。
>
> - ポジティブな声（頻出するキーワード Top 5）
> - ネガティブな声（頻出するキーワード Top 5）
> - 機能要望（頻出するもの Top 5）
> - 5 つ星レビューの代表 3 件（引用、URL 付き）
> - 1〜2 つ星レビューの代表 3 件（引用、URL 付き）
>
> 引用は原文ママで。改変しない。

引用は原文ママ — これも譲れないルールです。Claude が要約しすぎると、原文のニュアンスが消えます。「不満を感じる」と書いてあったものが「使いにくい」に変わったり、軽い愚痴が深刻な批判に変わったりします。

結果の使い方

レビュー要約が出てきたら、それで終わりにせず、「次の打ち手」を Claude に提案させる と一気に実用度が上がります。

> 上のネガティブな声を踏まえて、自社の弱みと重なる部分があれば指摘して。
> また、競合 A 社が改善できていないポイントを、自社が先に潰すための
> 機能追加アイデアを 3 つ提案して。

調査 → 解釈 → 打ち手 の 3 段階を 1 セッションで回せる のが Claude Code の真価です。Excel と人力では、この 3 段階を別の日に分けてやることになります。

注意 — 公開情報の利用範囲、規約遵守、引用元明示

ここは飛ばさずに読んでください。競合調査の自動化で、最も訴訟リスクがある領域 です。

公開情報なら何でも使えるわけではない

「公開されているから使っていい」というのは半分しか正しくありません。

• 公式サイトの利用規約に「自動取得を禁ずる」と書かれていることがある（特に求人・不動産・グルメ系）
• レビューサイトは通常、レビュー本文の 商用転載を禁止 している
• SNS の投稿は投稿者本人に著作権がある（引用の要件を満たさないと違反）
• プレスリリースは引用 OK だが、出典明記が必須

Claude Code を使うときの 5 つの最低ライン

NG パターン

引用元明示のテンプレート

レポートの末尾には、必ず 次のようなフッタを入れます。

---
## 情報源・引用

本レポートは 2026-05-19 時点の公開情報を基に作成しました。

- A 社: https://example-a.com (取得日 2026-05-19)
- B 社: https://example-b.com (取得日 2026-05-19)
- C 社: https://example-c.com (取得日 2026-05-19)
- レビュー要約は ITreview, G2 の公開レビューを参照（引用は原文ママ、出典 URL 記載）

本レポートの記載内容は予告なく変更される可能性があります。意思決定の前に
最新の公式情報をご確認ください。
---

このフッタを毎回入れる ことで、レポートを社内で回したときの「これ大丈夫？」リスクが大幅に下がります。

プロンプトテンプレート 4 つ

ここまで紹介した内容を、コピペで使えるテンプレート に圧縮しました。次回以降の調査はこれをベースにすれば、毎回ゼロから書く必要はありません。

テンプレート 1 — 機能比較

次の URL から [プロダクト種別] の情報を取得して、機能比較マトリクスを作って。

URL:
- A 社: [URL_A]
- B 社: [URL_B]
- C 社: [URL_C]

比較項目:
1. [項目1]
2. [項目2]
3. [項目3]
...

ルール:
- 機能の有無は ◯ / △ / ✕ で表現
- 不明なセルは「不明」と書く（推測しない）
- 根拠 URL を別表で出力
- レポートの末尾に取得日と出典フッタを付ける

テンプレート 2 — 価格比較

[プロダクト種別] の料金ページから次の項目を取得して比較表を作って。

URL:
- A 社: [URL_A]
- B 社: [URL_B]
- C 社: [URL_C]

取得項目:
- プラン名
- 表示価格（通貨明記）
- 課金単位（ユーザ/月/年）
- 最小契約ユーザ数
- 税込/税抜
- 年払い割引

ルール:
- 通貨換算はしない
- 「要問い合わせ」のプランはそのまま「要問い合わせ」
- 取得日と出典 URL をフッタに記載

テンプレート 3 — レビュー感情分析

[レビューサイト URL] の [プロダクト名] のレビューを読み、次の構造で要約して。

- ポジティブな声（頻出キーワード Top 5）
- ネガティブな声（頻出キーワード Top 5）
- 機能要望（Top 5）
- 5 つ星レビュー代表 3 件（引用、URL 付き）
- 1〜2 つ星レビュー代表 3 件（引用、URL 付き）

ルール:
- 引用は原文ママ
- 改変しない
- 出典 URL を必ず付ける

テンプレート 4 — 月次定点モニタリング

先月作成した competitors.md を読んで、今月の差分を生成して。

更新対象:
- 価格の変化
- 新機能のリリース
- プレスリリース
- レビュー件数 / 平均点の変化

ルール:
- 変化がある箇所は ⚠️ マークを付ける
- 変化がない項目は省略しない（「変化なし」と書く）
- 出典 URL と取得日を更新する
- 前月比のサマリーを冒頭に 3 行で書く

出力フォーマット — Markdown / Excel / Notion 投入

調査結果はどこに置きますか？ 用途別に最適なフォーマットがあります。

Markdown — 一次成果物のデフォルト

まず Markdown で出させる のが鉄則です。理由は次のとおりです。

• Git 管理できる（差分が読める）
• GitHub / GitLab / Notion / Slack にそのまま貼れる
• HTML / PDF / Word にいくらでも変換できる
• 人間がそのまま読める

> 上の比較結果を competitors-2026-05.md として保存して

ファイル名に年月を入れる と、来月以降との比較が一目で分かるようになります。

Excel / CSV — 数値を扱うとき

価格比較・売上推定など 数値を再加工する可能性がある データは CSV にも出します。

> 上の価格比較テーブルを pricing.csv にも書き出して。
> ヘッダー行は英語で。日本語の値はダブルクオート囲み。

英語ヘッダー / 日本語値 は、後で BI ツールにつないだときに文字化けを避けるための定番パターンです。

Notion — 社内共有がメインの場合

Notion を使っている組織なら、MCP 経由で直接ページを作らせる のが最速です（第 8 章で詳しく扱います）。

> 上のレポートを Notion の「市場調査」DB に新規ページとして投稿して。
> タイトルは「2026-05 競合分析 - CRM カテゴリ」
> プロパティ: カテゴリ=CRM, 更新月=2026-05

MCP が未設定の場合は、Markdown を生成して人間が Notion に貼るのが現実解です。Notion は Markdown のペーストに対応しているので、コピペで大体イケます。

HTML ダッシュボード — 経営報告

役員報告など 見た目が大事な 用途では、HTML ダッシュボード（Chart.js + 比較表）を生成すると一段見栄えが上がります。次のレッスン 7-2「ダッシュボード作成」でこのパターンを掘り下げます。

失敗パターン

ここまでが理想形の話。次は 現実によく起こる失敗 を 4 つ並べます。最初に知っておくと、ハマる時間が 90% 減ります。

失敗 1 — 古い情報を最新だと思い込む

Claude のモデルには 学習データのカットオフ があります。たとえば Claude Opus 4.7 のカットオフは 2026 年 1 月。そこから先のリリースは 知らない のが基本です。

WebFetch を使えば最新情報は取れますが、Claude が WebFetch を使わずに「知っている振り」で答えてしまう ことがあります。

ユーザー: A 社の最新プランを教えて
Claude: A 社の最新プランは... (実際は半年前の古い情報)

対策 は次のとおりです。

> 必ず WebFetch を使って公式サイトを取得してから答えて。
> 自分の記憶だけで答えないで。
> もし WebFetch が失敗したら「取得失敗」とだけ答えて。

「記憶で答えるな」 を明示するだけで、ハルシネーションの大半は消えます。

失敗 2 — ハルシネーション（もっともらしい嘘）

機能比較で「監査ログ あり」と書いてあっても、実際には 存在しない機能 であることがあります。Claude が「他社が持っているからこの会社も持っているだろう」と推測してしまったケースです。

対策 は 根拠 URL を必ず別表で要求する こと。根拠が出せないセルは、Claude 自身が「不明」と書かざるを得なくなります。

> 全ての ◯/△/✕ について、必ず根拠 URL を別表で出して。
> 出典が見つからないセルは ◯/△/✕ を書かずに「不明」と書いて。

失敗 3 — 偏ったソース（同じ立場の記事ばかり）

特定のメディアの記事だけを Claude に渡すと、その記事の立場に引きずられた要約が出ます。たとえば、自社製品を持っているメディアが書いた「比較記事」は、自社製品を 過大評価 している可能性が高いです。

対策 は次のとおりです。

• 公式サイトを最優先 ソースにする
• 中立のレビューサイト を 2 つ以上参照する
• まとめ系メディア は補助情報として扱い、メインソースにしない
• 1 社の自社メディア だけで判断しない

失敗 4 — 競合社内資料の流入

最も怖いパターンです。社員が「これ参考になりそう」と元同僚から競合社内資料をもらってきて、Claude に読み込ませる — これは情報漏洩リスクと NDA 違反リスクが同時に発生します。

判断基準はシンプル です。「自分の会社で同じものが漏れたら困るか？」と自問してください。Yes なら、それは Claude にも社内 Slack にも投げてはいけません。

定期実行と継続モニタリング

1 回作って終わりではなく、月次・四半期で継続 するための仕組みも作っておきましょう。

ファイル構成の推奨

~/work/competitor-research/
├── templates/
│   ├── feature-comparison.txt
│   ├── pricing-comparison.txt
│   ├── review-analysis.txt
│   └── monthly-diff.txt
├── data/
│   ├── 2026-03/competitors.md
│   ├── 2026-04/competitors.md
│   └── 2026-05/competitors.md
└── notes/
    └── insights.md

フォルダ名に年月 を入れることで、過去の調査をスナップショットとして残せます。半年前の自分の調査と今を比較 できるのが、定期実行の最大の価値です。

CLAUDE.md に調査ルールを書いておく

~/work/competitor-research/CLAUDE.md に、調査の前提ルールをまとめておくと、毎回プロンプトで指定しなくても Claude が守ってくれます。

# 競合調査の前提ルール

## 必ず守ること
- 公式サイトを WebFetch で取得してから答える
- 自分の記憶だけで答えない
- 全ての主張に根拠 URL を別表で示す
- 不明なセルは「不明」と書く

## 出力フォーマット
- 一次成果物は Markdown
- 数値データは CSV にも出す
- レポート末尾に出典フッタを付ける
- ファイル名は competitors-YYYY-MM.md

## 禁止事項
- 非公開資料の取り込み
- 引用元の改変
- 商用転載

CLAUDE.md は「Claude への永続メモ」。これがあると、新しいセッションでも毎回ゼロから指示する必要がなくなります（第 5 章で詳しく扱いました）。

スケジューラで月次自動化

慣れてきたら、月初の朝に自動でレポートを生成 する仕組みを作れます。

# cron で毎月 1 日 9:00 に実行（macOS / Linux）
0 9 1 * * cd ~/work/competitor-research && \
  claude -p "$(cat templates/monthly-diff.txt)" > data/$(date +\%Y-\%m)/competitors.md

月曜の朝、コーヒーを淹れている間にレポートが出来上がっている — ここまで来ると、自動化の本当の威力を感じます。

公開している有志ツールも組み合わせる

Claude Code 単体でほとんどの調査はカバーできますが、組み合わせると更に強くなる外部ツールがあります。

Wayback Machine（archive.org） は特に便利で、「3 ヶ月前のこのページ」を取得できます。価格の値上げ前後を比較するときなど、定点調査と相性が抜群です。

> https://web.archive.org/web/2026*/example-a.com/pricing から
> 過去 1 年の料金プランのスナップショットを 3 ヶ月おきに取得して、
> 価格推移のテーブルを作って

自社のリリース履歴と並べて見せる と、競合の打ち手が「自社のあの動きへの反応だったのか」と気づくことがあります。

まとめ

長いレッスンでしたが、押さえてほしい要点を 7 つに絞ります。

1. 競合調査は 機能比較・価格比較・ターゲット分析・レビュー分析・戦略動向 の 5 タイプに分解できる
2. WebFetch ツールで公開ページを取得できるが、ログイン要・SPA・robots.txt 禁止のページは取れない
3. 機能比較は 項目を先に決める / 価格比較は 通貨と税込/税抜 を必ず確認 / レビューは 原文ママの引用 を守る
4. 根拠 URL を別表で出させる ことが、ハルシネーション対策の最重要テクニック
5. 公開情報 でも、利用規約・robots.txt・著作権・個人情報保護法の確認は必須
6. プロンプト 4 種類（機能・価格・レビュー・月次差分）を テンプレ化 して再利用する
7. 月次自動化 まで持っていくと、ROI が 10 倍跳ねる

<Checklist items={["競合 3 社の機能比較を Markdown で生成できた","全てのセルに根拠 URL を付けた","出典フッタ（取得日・URL）を付けた","プロンプトテンプレートを ~/templates/ に保存した","月次定点モニタリングの仕組みを 1 つ仕込んだ"]} />

<Quiz question="Claude Code で競合調査を自動化するとき、ハルシネーションを最も効果的に防ぐ指示はどれ？" options={["全ての主張に根拠 URL を別表で出させ、出典が無いセルは「不明」と書かせる","Claude のモデルを Opus に切り替える","プロンプトを英語で書く"]} answer={0} />

<Quiz question="競合調査で「やってはいけない」のはどれ？" options={["競合の社内資料を入手して Claude に読み込ませる","公開されている料金ページを WebFetch で取得する","レビューサイトの公開レビューを要約する（出典明記）"]} answer={0} />

次のレッスン 7-2: ダッシュボード作成 では、本レッスンで生成した競合データを、Chart.js を使ったインタラクティブなダッシュボード に変換していきます。数字の羅列ではなく、グラフで意思決定に直結する形に仕上げる工程を一緒に作りましょう。