サポート案件の調査は本質的にはリサーチの課題であり、顧客の課題に対応するうえで最も時間がかかる部分は常に「適切なコンテキストを集めること」でした。コード、ログ、チームのナレッジ、これまでのやり取りを 1 つの Cursor セッションにまとめることで、私たちはほとんどの業務におけるそのボトルネックを取り除きました。

現在では、Cursor のサポート対応の 75% 以上が Cursor 上で行われており、サポートエンジニアのスループットは 5〜10 倍に向上しています。これにより、わずか 1 年前と比べても、サポートエンジニアにとって実現可能なことの水準が飛躍的に変わりました。

#コードベースから始める

調査を行うときは、通常 Ask モードから始めます。症状を指定し、それに関連するプロダクトの挙動をさかのぼって追跡させます。完全なコードベースがローカルで利用できるため、Cursor は同じセッション内でプロダクトコード、ドキュメント、社内ツール全体に対してインデックスを作成し、セマンティック検索を行えます。

ここでマルチルートワークスペースが真価を発揮します。プロダクトのコンテキストは、ほぼ必ず複数のリポジトリにまたがります。ユーザーからの「なぜこのボタンは無効化されているのか？」という質問に答えるには、フロントエンドのロジック、バックエンドのポリシーチェック、想定される挙動を説明するドキュメントが関わってくるかもしれません。その種の質問に 1 つのスレッドで答えられるよう、関連するリポジトリは 1 つのワークスペースにまとめています。

#MCP との連携によるサポート情報源の統合

私たちは、コンテキストを取得して調査に取り込むために MCP サーバーを利用しています。必要なコンテキストはすべて Cursor 内で利用できるため、サポートエンジニアは関連する情報を得るために複数のツールを横断して検索する必要がなくなりました。

MCP サーバーにより、次のようなものを統合できます：

• サブスクリプションのプラン、チーム設定、プライバシー設定などの顧客情報を含むデータベース
• 利用されたサービス、テレメトリエラー、ネットワークの問題に関する詳細を含むストリーミングされたイベントログ
• Slack などのコミュニケーションプラットフォーム。スレッドや会話が蓄積されており、お客様が製品とどのように関わっているかを理解する助けになります
• それぞれ異なる運用を行っている可能性のある、数十ものチーム向けエンジニアリングチケットプラットフォーム
• ランブックやトラブルシューティングガイドを含む社内ドキュメントサービス
• 顧客へのアプローチ方法やトーンに影響しうる重要な顧客情報を含むアカウント管理サービス

Cursor と MCP サーバーを組み合わせることで、サポートエンジニアは、コードベースの調査に必要な情報を迅速に直接取り込むことができます。

#障害がどこで発生したかを特定する

お客様からエラーの報告があった場合、まず確認すべきなのは「報告されている問題は再現性のあるものなのか一時的なものなのか」、そして「Cursor のどこで正確に障害が発生したのか（クライアント側、API エッジ層、下流の依存サービス、認証）」という点です。Datadog MCP を使うことで、関連するログやトレースを調査スレッド内に直接取り込み、原因候補の絞り込みをすぐに始められます。

#類似ケースの特定

新しいサポートチケットが来た場合、その問題はすでに別のお客様や社内メンバーが経験している可能性が高くあります。サポートプラットフォームや Slack と連携した MCP を使うことで、そのコンテキストを直接検索し、調査にとって最も関連性の高いスレッドを取得できます。まずはエラー文字列やリクエスト ID といった厳密な識別子で検索し、必要に応じて検索範囲を広げ、最新のステータス、回避策、担当者が含まれている最新スレッドを探します。

#バグかどうかを判断する

多くの調査は「バグなのか、それとも想定どおりの動作なのか？」という問いに行き着きます。Notion MCP を使うと、関連する runbook をスレッドに取り込み、実際に発生している事象と突き合わせることで、その動作が正しいかどうかを確認したり、より明確なバグ報告としてエスカレーションしたりできます。

#バグ報告の起票

Cursor での調査が完了する頃には、修正が必要な問題があれば、エンジニアリングチーム向けのチケットを起票するために必要な情報は一通りそろっています。Linear MCP を使うと、そこまでのコンテキストをすべて引き継ぎ、同じスレッドから直接、フォーマット済みのエスカレーションとして送信できます。

#ドキュメントの更新

複数のお客様が同じ点でつまずいたり同じ質問をされる場合、多くはドキュメントを改善する必要がある兆候です。テクニカルサポートチームは、この種の修正を直接実施するのに最も適したポジションにあります。Slack で更新が必要な内容と一緒に @Cursor をメンションすると、クラウドエージェントがドキュメント用のリポジトリに対して自動で PR を作成します。

#プロセスの自動化

#よくある手順用コマンド

このプロセスで頻繁に繰り返される手順には、スラッシュコマンドを使用します。

#繰り返しパターン向けの Rules と Skills

サポート調査でよく発生するプロセスを自動化するために、Rules と Skills を使用します。

#ステップを並列実行する Subagent

Subagent を使うことで、サポートプロセスのよくあるステップを逐次ではなく並列に実行できます。

• LogInvestigator は Datadog を検索して、障害ポイントとその裏付けとなる証拠を探します。
• KnownIssueMiner は Slack と Notion をスキャンして、過去のスレッドやワークアラウンドを探します。
• TicketWriter は証拠を整形し、完全なエスカレーションチケットにまとめます。
• CustomerReplyDrafter は、社内向けの詳細を取り除いたうえで、顧客への返信文を作成します。

これらの結果は 1 つの出力に統合され、私たちがレビューして送信します。

#AIネイティブなテクニカルサポート

これらのツールを組み合わせることで、コード調査をテクニカルサポートのプロセスそのものに直接組み込むことができます。私たちは、この仕組みによって、複数のツールやチーム間を行き来する従来のアプローチと比べ、最大で桁違いの生産性向上が見込めると試算しています。この生産性向上により、小規模（ただし成長中）のサポートエンジニアチームでも、急速に拡大しているユーザー基盤を効果的に支援できるようになります。

CXワークフローにCursorをどのように組み込めるか、詳しく知りたい場合は、お問い合わせください。