「障害調査でもう泣かない」 Cursor技術サポートが明かす、コンテキスト収集の極意エディタ上のサポートで処理能力5〜10倍

Cursorを開発するAnysphereは、同社の技術サポートチームがCursorを活用してサポート業務を効率化している具体的な手法を公開した。サポートエンジニアのスループットが5〜10倍に向上したという。

» 2026年04月15日 08時00分 公開
[@IT]

この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。

 AIコーディングエディタ「Cursor」を開発するAnysphereは2026年3月3日(米国時間)、同社技術サポートチームによるCursor活用事例をブログで公開した。技術サポート担当が執筆した記事によると、サポート対応の75%以上がCursor上で実施されており、サポートエンジニアのスループット(処理能力)は5〜10倍に向上したという。

 技術サポートにおける調査作業の本質は、適切なコンテキスト(背景情報)の収集にあるという。従来のサポート業務では、コードやログ、チームのナレッジ、過去のサポート履歴などを複数のツールから個別に収集する必要があった。Cursorでは、これらの情報を1つのセッションに統合することで、そのボトルネックを解消したという。

コードベースを起点とした調査フロー

 調査はCursorの「Askモード」から開始する。障害の症状を入力すると、Cursorは関連するプロダクトの挙動をさかのぼって追跡する。コードベースをローカルで利用できるため、同一セッション内でプロダクトコードやドキュメント、社内ツール全体を対象にしたインデックス作成とセマンティック検索が可能になる。

 ここで、マルチルートワークスペースが真価を発揮する。プロダクトのコンテキストは複数リポジトリにまたがるため、「なぜこのボタンは無効化されているのか?」といった問い合わせに答えるには、フロントエンドのロジックとバックエンドのポリシーチェック、ドキュメントを横断して調査する必要がある。関連するリポジトリを1つのワークスペースに統合することで、そうした質問を1つのスレッドで処理できる。

調査に必要なコンテキストをCursor内で直接取得する方法

 調査に必要なコンテキストをCursor内で直接取得するために、MCP(Model Context Protocol)サーバを活用している。MCPサーバを通じて統合している情報源は以下の通り。

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

 これらを統合することで、サポートエンジニアは複数のツールを行き来せずに必要な情報を収集できる。

障害調査の5ステップ

 Cursorサポートチームでは、障害調査を次の手順で進める。

1.障害箇所の特定

 顧客からエラーの報告があった場合、問題の再現性の有無と、「障害がCursorのどの層で発生したか(クライアント側、APIエッジ層、下流の依存サービス、認証)」を確認する。サーバ監視サービス「Datadog MCP Server」を使ってログやトレースを調査スレッド内に直接取り込み、原因候補を絞り込む。

2.類似ケースの検索

 新しいサポートチケットが来た場合、サポートプラットフォームやSlackと連携したMCPサーバを使って過去の関連スレッドを検索する。エラー文字列やリクエストIDなどの厳密な識別子で検索し、最新のステータス、回避策、担当者情報を持つスレッドを取得する。

3.バグか仕様かの判断

 情報共有ツール「Notion MCP」を使って関連するランブックをスレッドに取り込み、発生している事象と照合することで、仕様通りの動作かバグかを判断する。バグと判断した場合はエスカレーションの対象とする。

4.バグチケットの起票

 調査完了後、タスク管理ツール「Linear MCP」を使ってそれまでのコンテキストを引き継ぎ、エンジニアリングチーム向けのフォーマット済みエスカレーションチケットを同じスレッドから直接起票する。

5.サポートドキュメントの更新

 複数の顧客が同じ問題に直面している場合は、サポートドキュメントの改善が必要なサインと判断する。Slackで更新内容とともに「@Cursor」をメンションすると、クラウドエージェントがドキュメント用リポジトリに対して自動でプルリクエストを作成する。

スラッシュコマンドと「Rules」「Skills」による自動化

 頻繁に繰り返される手順については、スラッシュコマンドを定義して自動化している。サポートチケットの作成、顧客への返信文の下書き、既知の問題の検索、ログの検索などが代表的なコマンドとして運用されている。

 さらに、Rules(ルール)とSkills(スキル)を組み合わせることで、調査プロセスの一部を自動化している。具体的には以下のような用途で活用されている。

  • 顧客向け返信文の生成
    安全かつ実行可能な返信内容を自動生成する
  • 高品質なバグチケットの作成
    必要な情報を整理したチケットを自動生成する
  • 既知問題の調査
    SlackとNotionを対象に過去の類似事例を自動検索する

サブエージェントによるステップの並列実行

 複数の調査ステップを逐次ではなく並列で実行するために、サブエージェントを活用している。サポートプロセスで並列実行されるサブエージェントは以下の4つ。

  1. LogInvestigator
    「Datadog」を検索し、障害ポイントとその裏付けとなる証拠を収集する
  2. KnownIssueMiner
    SlackとNotionをスキャンし、過去のスレッドやワークアラウンドを検索する
  3. TicketWriter
    収集した証拠を整形し、完全なエスカレーションチケットとしてまとめる
  4. CustomerReplyDrafter
    社内向けの詳細情報を除いた上で、顧客への返信文を生成する

 これら4つのサブエージェントの結果は1つの出力に統合され、サポートエンジニアがレビューして送信する。

 技術サポート担当は各サブエージェントには狭いスコープ、明確な出力、明示的な制約を設けることが重要だと説明。複数のツールやチーム間を行き来する従来のアプローチと比較して、大幅に生産性が向上するため、小規模なサポートエンジニアチームでも急速に拡大するユーザー基盤を効果的に支援できるようになるとしている。

Copyright © ITmedia, Inc. All Rights Reserved.

アイティメディアからのお知らせ

スポンサーからのお知らせPR

注目のテーマ

その「AIコーディング」は本当に必要か?
Microsoft & Windows最前線2026
4AI by @IT - AIを作り、動かし、守り、生かす
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。