Claude CodeのLogRocketプラグインでセッションリプレイと問題を引く
LogRocketプラグインの入れ方、同梱スキルとMCPツールの役割、紹介ページとドキュメントで食い違うツール数、toolsetsでの絞り込みと認証の選び方をまとめます。
LogRocketのプラグインをClaude Codeに入れると、セッションリプレイ、メトリクス、問題(issue)をターミナルから自然言語で引けます。「チェックアウトでエラーに当たったユーザーのセッションを探して」と頼めば、Claude Codeが該当セッションを絞り込み、中身を見て、原因の仮説までまとめます。
プラグインの中身は2つだけです。LogRocketのMCPサーバーへの接続設定と、使い方を教えるスキルが1つ。この記事では、導入の手順、ツールの役割分担、資料ごとに数が食い違うツール一覧の読み方、取得範囲を絞る設定を扱います。
入れる前に必要なもの
プラグインはLogRocketのアカウントを前提にします。MCPサーバーは、ブラウザで見られるのと同じ組織とプロジェクトにアクセスする仕組みです。つまり、LogRocketのSDKをアプリに組み込み済みで、セッションがすでに記録されているチームが対象になります。
プラン別の利用条件は、紹介ページにもリポジトリのREADMEにも記載がありません。契約プランで使えるかどうかは、LogRocketの管理画面かサポートで確かめてください。
マーケットプレイスの紹介ページには、導入数199が表示されています。プラグイン名は logrocket、提供元はLogRocket自身です。ライセンスはプラグイン定義にMITと書かれています。
インストールと認証
入れ方は2通りあります。READMEはマーケットプレイスを追加してから入れる手順、ドキュメントは /plugin の検索画面から入れる手順を案内しています。
/plugin marketplace add logrocket/logrocket-claude-plugin
/plugin install logrocket@logrocket/plugin を開いてDiscoverタブで logrocket を検索し、そこから入れても同じプラグインです。
入れたら /reload-plugins で読み込み、認証に進みます。認証は /mcp から行います。
OAuth認証の流れ
- 1
プラグインを読み込む
/reload-pluginsを実行します。 - 2
MCPの画面を開く
/mcpを実行し、Built-in MCPsの中からplugin:logrocket:logrocketを選びます。 - 3
Authenticateを選ぶ
ブラウザでLogRocketにログインして許可します。ここで得られる権限は、ブラウザで見えるものと同じ範囲です。
OAuthが難しい環境(サーバー上でブラウザを開けない場合など)では、APIキーで認証する方法もあります。ただし、これはプラグインを使わずに直接つなぐ構成になります。
claude mcp add --transport http logrocket \
https://mcp.logrocket.com/mcp \
--header "Authorization: Bearer <your-api-key>"APIキーはLogRocketのSettings > API Keysで作ります。キーはプロジェクト単位なので、複数プロジェクトを見たいなら、プロジェクトごとに作って接続を分ける必要があります。OAuthなら、アクセスできる組織とプロジェクトがまとめて使えます。
同梱のスキルとMCPは何をするか
リポジトリは plugins/logrocket の下に、MCPの接続設定とスキルを置いています。READMEの表では、構成要素は次の2つです。
| 構成要素 | 役割 |
|---|---|
| MCPサーバー | 役割LogRocketのAPIにClaude Codeをつなぐ |
| Use LogRocketスキル | 役割LogRocketへの問い合わせ方をClaude Codeに教える |
接続先は https://mcp.logrocket.com/mcp?toolsets=all です。toolsets=all が付いているので、LogRocket側で後から増えるツールも自動で有効になります。
スキルの本文は、ツールの使い分けを6つの方針に落としています。ここを知っておくと、頼み方が決まります。
- 広い質問、探索的な質問は
use_logrocketに自然言語で投げる。セッション、メトリクス、問題をまとめて扱える - 特定のセッションを調べたいときは
find_sessionsで絞り込み、watch_sessionsで中身を分析する - ネットワーク通信だけが知りたいなら、
watch_sessionsではなくget_network_entriesを使う - 問題の整理は
find_issues。既定では「重大度が高く、未対応で、直近1週間」の問題が返る - 組織やプロジェクトを指定しなかったときは、
list_organizationsとlist_projectsで探し、複数あれば聞き返す - 会話の続きは、前回の
use_logrocketの応答にあるchatIDを渡して引き継ぐ
use_logrocket の裏側はAsk Galileoという、LogRocketのダッシュボードにもある会話型の機能です。ダッシュボード側のドキュメントによれば、指標、セッション視聴、問題、顧客フィードバックの4種類の質問に答えます。
紹介ページとドキュメントでツールの数が違う
ツール一覧は資料ごとに数が違います。どれが誤りというより、書かれた時期と範囲の差と読むのが自然です。
| 資料 | 挙げているツール |
|---|---|
| 紹介ページ | 挙げているツール6つ(list_organizations / list_projects / use_logrocket / find_sessions / watch_sessions / build_metric) |
| README・スキル本文 | 挙げているツール8つ(紹介ページの6つに、get_network_entries と find_issues を加えた構成) |
| LogRocketのMCPドキュメント | 挙げているツール9つ(get_metric を加えた全部) |
注意したいのは、プラグインの設定が toolsets=all であることです。紹介ページの6つはあくまで説明文で、実際に露出するのはサーバーが提供する全ツールです。get_metric は、保存済みのメトリクスのリンクから、時系列、ファネル、テーブル、リテンション、セッション数を取り出すツールで、ファネルの離脱ステップに当たったセッションの例も付けられます。紹介ページだけを読むと、この機能の存在に気づけません。
手元で何が見えているかは、/mcp の画面でこのサーバーを開くと確かめられます。LogRocket側の更新でツールは増減します。紹介ページや記事の数に合わせて期待せず、実際の一覧を基準にしてください。
頼み方の実例
プロンプトの型は、LogRocketが用意している5つの使いどころで足ります。READMEの例を、目的別に並べ直します。
| やりたいこと | 頼み方の例 |
|---|---|
| 報告されたバグの原因 | 頼み方の例「ユーザーXがチェックアウトで困ったと報告した。LogRocketでセッションを見て根本原因を探して」 |
| 機能の使われ方 | 頼み方の例「検索機能に手を入れる前に、今どう使われているかをLogRocketで把握したい」 |
| 新しい問題の仕分け | 頼み方の例「先週の新しい問題をLogRocketで見て、原因を推測し、直せそうなものを挙げて」 |
| デプロイ後の退行 | 頼み方の例「先週のコミットを全部見て、LogRocketのデータで退行が出ていないか確認して」 |
| 次にやる作業の優先度 | 頼み方の例「セッションと問題を見て、次に取り組むべき優先度の高いものを教えて」 |
どれも「何をLogRocketで見るか」と「見てどうするか」を1文に入れています。後半の「直せそうなものを挙げて」「確認して」まで書くと、Claude Codeは取得したデータをコードの修正に結びつけます。
精度を上げるコツは、スキル本文とAsk Galileoのドキュメントで共通しています。
- URL、クリック対象、ユーザーのメールアドレス、期間、カスタムイベントを具体的に書く
- 結果が物足りないときは、セッションを実際に見る(watch)ように頼む。リプレイの分析が最も詳細な情報を返す
- 比較を頼むと、Ask Galileoは既定で各コホートのセッションを100件ずつ見る
- 追加の質問を重ねて掘り下げる
ツールを絞る: toolsetsと範囲指定
ドキュメントの例には、メールアドレスでユーザーのセッションを引くプロンプトが並びます。READMEは、このプラグインがユーザーのセッションデータを扱うことを注記し、データの扱いはLogRocketのプライバシーポリシーを参照するよう案内しています。業務で使う前に、見せてよい範囲を決めておくと安全です。
MCPサーバーには、公開範囲を絞る仕組みが2つあります。
1つ目は toolsets クエリパラメーターです。指定したツールセットのツールだけが露出します。
| toolsetsの値 | 露出するツール |
|---|---|
sessions | 露出するツールfind_sessions / watch_sessions / get_network_entries |
metrics | 露出するツールbuild_metric / get_metric |
issues | 露出するツールfind_issues |
ask-galileo | 露出するツールuse_logrocket |
all | 露出するツールすべて(省略時と同じ) |
たとえばセッションとメトリクスだけにするなら、URLは https://mcp.logrocket.com/mcp?toolsets=sessions,metrics です。READMEは、プラグイン側では plugins/logrocket/.mcp.json のURLを書き換えると説明しています。
2つ目は、URLのパスで組織やプロジェクトを固定する方法です。
- 組織で絞る:
https://mcp.logrocket.com/mcp/<organization_id> - プロジェクトで絞る:
https://mcp.logrocket.com/mcp/<organization_id>/<project_id>
IDは https://app.logrocket.com/<organization_id>/<project_id>/s/... のようなURLや、Settings > Project SettingsのApp IDで分かります。App IDは <organization_id>/<project_id> の形です。組織で絞ると list_organizations が、プロジェクトで絞ると list_projects が見えなくなります。
メトリクスの日付の区切りはUTCが既定です。日本時間の日次で見たいなら、timezone=Asia/Tokyo のようにIANAタイムゾーンをURLに付けます。クライアントがタイムゾーンを渡す場合もあり、個別のクエリで「Asia/Tokyoで日ごとに」と指定して上書きもできます。toolsets と併用でき、無効な値は無視されてUTCになります。
プラグインのURLを書き換える代わりに、上の claude mcp add で目的に合ったURLを直接登録する運用もあります。この場合は、プラグインとMCPの登録が二重にならないよう、/mcp で一覧を確認してください。
使うときの落とし穴
問題データの保持期間は30日です。スキル本文に、問題のデータは30日間だけ保持されるとあります。「半年前から出ている不具合」のような問いは、find_issues では答えられません。
find_issues の既定は絞り込み済みです。既定では重大で未対応のものが直近1週間だけ返ります。「問題はありませんでした」と返ってきても、条件の外にあるだけかもしれません。重大度、対応状況、期間を広げるように頼んでください。
ネットワークの欠落は異常ではありません。 get_network_entries で本文、ヘッダー、Cookie、タイミングが欠けたり切り詰められたりするのは想定内だと、スキルは明記しています。アプリのバグと読まないでください。結果が大きいときは、URL、メソッド、ステータスコード、時間帯で絞ると小さく済みます。ページ分割もあるので、続きがあれば offset を進めて呼び直します。
複数セッションの調査は1件ずつ回ります。ネットワークの取得は1セッション単位です。find_sessions で見つけたセッションごとに呼ぶ必要があるため、件数が多い依頼ほど呼び出し回数が増えます。
認証のやり直しは /mcp で行います。認証が自動で始まらなかったときは、/mcp から手動で認証を始められます(クライアント共通の案内です)。保存済みの資格情報まわりの症状は、MCPのstored credentialsエラーにまとめています。
他のMCP・プラグインと組み合わせる
LogRocketのドキュメントは、フロントエンドのLogRocketデータと、バックエンドの可観測性ツール(Datadog MCPなど)を組み合わせたスキルを作る使い方を挙げています。画面で何が起きたかをLogRocketで、サーバーで何が起きたかを別のツールで引き、Claude Codeに突き合わせさせる構成です。
エラー監視ならSentryのCLIスキルが近い入口で、セキュリティ系の検査にはAikidoのプラグインがあります。いずれも「外部サービスの名前で頼めば、Claude Codeが専用ツールを選んで引く」点は共通です。
プラグインを増やすとコンテキストの消費も増えます。入れたあとに負荷を測るなら、claude plugin detailsが使えます。toolsets で露出するツールを絞れば、ツール定義の分も軽くなります。
自動化も例示されています。サポートチケットが届いたら該当ユーザーのセッションを調べる、解約や低評価のユーザーの行動を調べる、毎週新しい問題とUXの摩擦の兆候を洗い出す、といった使い方です。ZendeskとIntercomには、セッションのリプレイをチケットに添付する連携があります。
まとめ
LogRocketのプラグインは、MCPへの接続とスキル1つという小さな構成です。価値はそこにつながる先、つまりすでに記録されているセッションにあります。導入は /plugin と /mcp の2手で済み、その後の差は頼み方と絞り方で決まります。
ツール数は資料によって6〜9と異なりますが、toolsets=all の接続では全部が見えます。まず /mcp で実際の一覧を確かめ、業務データを扱うなら toolsets と範囲指定で、見えるものを必要な分だけに絞っておくと運用しやすくなります。