---
title: "Minds MCPを使ってCursorでマーケティングリサーチエージェントを構築する"
description: "PostHogからデータを取得し、Mindsパネルを実行し、Slackに投稿するカスタムマーケティングリサーチエージェントをCursorで構築する実践的なウォークスルー。"
canonical_url: "https://getminds.ai/blog/ja/build-marketing-research-agent-cursor-minds-mcp"
last_updated: "2026-06-02T02:51:19.835Z"
---

# Cursorでマーケティングリサーチエージェントを構築する

本ガイドは、既製品を使うのではなく、カスタムのマーケティングリサーチエージェントを自ら構築したい方向けです。最終的に完成するのは、平易な言葉で書かれたリサーチ概要を受け取り、PostHogから製品アナリティクスを取得し、Mindsで合成パネル調査を実行し、両者を相互参照して、その要約をSlackに投稿するCursor内のエージェントです。3つのサービスのアカウントを既にお持ちであれば、全体で約90分の作業時間です。

目的は、洗練された製品を完成させることではありません。エージェントが概要を受け取り、複数のMCPサーバーを順次呼び出し、統合された結果について推論し、報告するというエージェントのループを具体的に理解することです。一度構築すれば、このパターンは他のあらゆる構築したいものに応用できます。

## 前提条件

3つのアカウントと3つのAPIキーが必要です。

- MindsアカウントとAPIキー（`minds_…`）。お持ちでない場合は、getminds.aiでサインアップしてください。
- PostHogアカウントと個人用APIキー。
- Webhookまたはアプリトークン経由でチャンネルに投稿できるSlackワークスペース。

Cursorのインストール（またはMCPをサポートする任意のエディタ。VS CodeとCopilotでも同様に動作します）。

集中してセットアップに約30分、その後エージェントの概要とプロンプトの改善に60分ほどかかります。

## ステップ1：3つのMCPサーバーを接続する

3つのサービスはそれぞれMCPサーバーを公開しています。これら3つすべてをCursorに接続します。

Cursorで、設定 → MCPを開き、3つのサーバーを追加します。

*Minds*。[Mindsのマーケットリサーチ用MCPサーバー](/mcp/overview)をURL `https://getminds.ai/mcp`で追加し、OAuth経由で認証します。12個のMindsツール（`create_panel`、`ask_panel`、`export_panel`など）がツールピッカーに表示されます。クライアント固有の手順については、[Minds MCPセットアップガイド](/mcp/setup)を参照してください。

*PostHog*。PostHogは独自のMCPサーバーを提供しています。推奨されるセットアップは、`https://app.posthog.com/mcp`のリモートエンドポイントで、これもOAuthを使用します。イベント、ファネル、コホート、ダッシュボードをカバーする55個のツールが利用可能になります。

*Slack*。Slack MCPサーバーはnpm経由で利用できます。`npx -y @modelcontextprotocol/server-slack`と環境変数（env）に設定したSlackボットトークンを使って、stdioサーバーとして追加します。`slack_post_message`と`slack_list_channels`の2つのツールで十分です。

Cursorを再起動します。3つのサーバーすべてがエージェントのツールリストに表示されるはずです。エージェントにパネルの一覧表示（Minds）、コホートの一覧表示（PostHog）、チャンネルの一覧表示（Slack）を依頼して、それぞれをテストしてください。

## ステップ2：自動化する価値のあるリサーチワークフローを選ぶ

エージェントは、与えられたワークフロー以上の価値は生み出しません。具体的なものを選びましょう。ここで構築する例は次の通りです。

> 機能名を受け取り、PostHogで過去30日間にその機能を使用したユーザーを見つけ、Mindsを介して彼らを合成ペルソナとして特徴付け、そのペルソナにその機能を推薦する理由・しない理由を尋ね、要約をSlackの#product-researchチャンネルに投稿する。

このパターン（実データに基づく根拠付け＋合成データによる補強＋チームへの共有）は、多くの意思決定で再利用可能です。ご自身のワークフローに置き換えてみてください。

## ステップ3：エージェントのプロンプトを作成する

エージェントのプロンプトは、Cursorの`.cursorrules`ファイルに記述するか、エージェントセッションのシステムメッセージとして設定します。うまく機能する構成は次の通りです。

```text
You are a marketing research agent. Your job is to take a feature name as input
and return a recommendation summary, posted to Slack.

For each request, do the following in order:

1. Use PostHog tools to find users who triggered the feature event in the last
   30 days. Get a count and basic properties (plan tier, account age, region).

2. Build a Minds persona that matches the dominant cohort from step 1. Use
   `create_mind` with a description that captures the cohort's plan tier,
   tenure, and likely role.

3. Create a panel of three personas matching that profile, using `create_panel`
   then `ask_panel`. Ask: "Would you recommend this feature to a colleague?
   Why or why not? What would have to change for it to be a yes?"

4. Cross-reference the panel response against the PostHog data. Look for
   alignment (do the panel's stated reasons match the actual usage patterns?)
   and gaps (does the panel surface concerns the metrics don't show?).

5. Post a summary to #product-research in Slack with three sections:
   - Cohort profile (who used it)
   - Panel verdict (recommend or not, top stated reasons)
   - Recommended action (what to do next)

Keep the Slack summary under 500 words. Link back to the full panel export.
```

このプロンプトは、意図的に3つのことを行います。

- エージェントが手順を省略しないように、ステップを厳密に順序付けています。
- ツールを単に呼び出す方法だけでなく、ツール間の結果をどのように構成するかをエージェントに指示しています。
- Slackのメッセージが実際に読めるように、出力を制限しています。

## ステップ4：実際の機能でテストする

製品で実際にリリースした機能を選び、エージェントを実行します。期待されるシーケンスは次の通りです。

1. エージェントがPostHogの`events`クエリを呼び出し、`feature_used`を機能名と過去30日間でフィルタリングします。件数とサンプルが返されます。
2. エージェントがPostHogの`cohorts`を呼び出し、ユーザーを特徴付けます。主要な料金プランと平均アカウント期間を特定します。
3. エージェントがMindsの`create_mind`を、「中間層の有料顧客、プラットフォーム利用期間6〜18ヶ月、<span>

機能カテゴリ

</span>

の主要ユーザー」のようなペルソナ記述で呼び出します。
4. エージェントがMindsの`create_panel`を、それらのペルソナ3体で呼び出します。
5. エージェントがMindsの`ask_panel`を、推薦に関する質問で呼び出します。
6. エージェントが回答を読み取ります。Mindsの`export_panel`を呼び出し、Slackリンク用に完全なセッションを保存します。
7. エージェントがSlackの`slack_post_message`を、構造化された要約とエクスポートリンクで呼び出します。

エンドツーエンドの時間：コホートのサイズとパネルの回答の長さによって60〜120秒。エンドツーエンドのコスト：MCPコールコストで約$0.15、エージェントの推論で$0.05。

いずれかのステップで失敗した場合、エージェントは通常一度再試行するか、方向転換します。もし行き詰まった場合、最も一般的な原因はステップ4のプロンプトが脆弱であることです（ペルソナ記述がコホートにうまく適合しない）。ペルソナ記述のプロンプトをより柔軟に書き直し、再実行してください。

## ステップ5：スケジュールを設定する

エージェントは、あなたが介在しなくても実行されて初めて価値を生み出します。2つの方法があります。

*Slack経由の手動トリガー*。Cursorエージェントをトリガーする`/research [feature-name]`スラッシュコマンドを追加します。これが最も簡単な方法で、アドホックなリサーチに適しています。

*Cronトリガー*。CIワークフロー（GitHub Actions、Linearオートメーションなど、スケジュール実行可能なもの）を使用して、毎週月曜日に機能名のリストをエージェントのエンドポイントに送信します。エージェントは機能ごとにワークフローを一度実行し、各要約を投稿します。チームは、人手を介さずに月曜の朝にリサーチダイジェストを受け取ることができます。

価値が複利的に増えるのは、cronを使用する方法です。四半期ごとにリリースされた全機能について機能レベルのリサーチを実行するチームは、年に一度大規模な調査を行うチームよりも、自社製品についてより多くを学びます。しかも、そのコストは5%未満です。

## カスタムエージェントが既製品に勝る点

パッケージ化されたリサーチツールを使うのではなく、これを自作する理由は次の通りです。

*ワークフローの特化性*。既製のツールは、最も一般的なケースに最適化されています。あなたのチームのリサーチワークフローが最も一般的なケースであることは稀です。カスタムエージェントは、あなたの意思決定のリズムに正確にフィットします。

*ツールの組み合わせ*。興味深い動きは、合成リサーチが実際の製品データに基づいて行われ、チームのチャンネルで共有されるときに起こります。既製のツールでこの一連の流れをすべて行えるものはありません。3つのMCPを繋ぎ合わせたカスタムエージェントなら可能です。

*コスト管理*。支払いはコールごと、サービスごとです。シートライセンスや追加のプラットフォーム料金はありません。チーム規模でのヘビーユースはパッケージツールよりも安価になり、ライトユースは実質的に無料です。

*イテレーションの速さ*。ワークフローの変更は、プロンプトの変更を意味します。ベンダーのロードマップや機能リクエストは関係ありません。制約となるのは、他社のリリースサイクルではなく、あなた自身の注意力です。

## よくある落とし穴

本番環境でこれを実行する際に注意すべき点がいくつかあります。

- *コール間のペルソナのズレ*。実行ごとに新しいMindを作成すると、ペルソナのプロファイルが毎回微妙に変化します。Mindを一度永続化（IDをキャッシュ）して再利用してください。Minds MCPは、まさにこの目的のために`list_minds`を公開しています。
- *PostHogクエリのタイムアウト*。大規模なコホートはエージェントをタイムアウトさせます。プロンプトでコホートサイズの上限を設定するか、代表的なサンプルに事前フィルタリングしてください。
- *Slackのメッセージサイズ制限*。Slackは4000文字を超えるメッセージを切り捨てます。プロンプトの500ワードという上限はそれを十分に下回りますが、エージェントがそれを無視した場合は、単一のメッセージではなくスレッドとして投稿してください。
- *OAuthトークンのローテーション*。3つのサービスはすべて定期的にトークンをローテーションします。エージェントが突然動作しなくなった場合は、プロンプトをデバッグする前に、各コネクタを再認証してください。

## 今後の展開

単一機能の推薦ワークフローは出発点です。これが機能するようになれば、同じエージェントを次のように一般化できます。

- 週次のキャンペーン効果測定ループ（キャンペーン開始前に合成広告反応を実行し、開始後に実際のクリックスルー率と照らし合わせて検証する）
- 月次の競合ポジショニング（競合のメッセージングに対して合成パネル調査を実行し、自社のコンバージョンデータと相互参照する）
- 四半期ごとのペルソナ更新（観測された製品行動の変化に基づいて合成ペルソナを更新する）

それぞれが同じ形をしています。実データに基づく根拠付け、合成データによる補強、チームへの共有です。まずは最初の1つを構築しましょう。残りはそのバリエーションです。

他に接続する価値のあるものについては、[2026年版：マーケティングおよびリサーチエージェント向けのベストMCPサーバー](/blog/best-mcp-servers-marketing-research-agents-2026)をご覧ください。その根底にあるカテゴリについては、[エージェント型マーケットリサーチの定義](/blog/agentic-market-research-definition)をご覧ください。合成データの出力に関する信頼性の問題については、[エージェント型リサーチアウトプットの検証](/blog/validating-agentic-research-output-eval-frameworks)をご覧ください。