Claude Media
Rollbar MCPサーバーでClaudeにエラーの一次調査を任せる
Claude CodeMCPClaude連携チュートリアル

Rollbar MCPサーバーでClaudeにエラーの一次調査を任せる

RollbarのMCPサーバー@rollbar/mcp-serverをClaude Codeに繋ぎ、item詳細の取得からデプロイ突合、ステータス更新まで自然文でエラー調査を任せる手順をまとめます。

読了目安 約11分

Rollbarは公式のMCPサーバー@rollbar/mcp-serverを配布しています。stdio方式でClaude CodeなどのAIツールが直接プロセスを起動する作りで、リモートサーバーを別途運用する必要はありません。item(Rollbarが検知したエラーのまとまり)の詳細取得からデプロイ履歴の突合、ステータス変更まで一通りの一次調査をカバーしており、エラーを見てからRollbarの画面を開くまでのひと手間を省けます。

Rollbar MCPサーバーとは

rollbar/rollbar-mcp-serverはRollbar公式org配下のリポジトリで、直近の更新も数日単位という頻度で継続的にメンテナンスされています。npmパッケージ@rollbar/mcp-serverとして配布され、npx経由でそのまま起動できるためローカルへの事前インストールは不要です。

トークンの与え方は3通りあります。

方式向いている場面
ROLLBAR_ACCESS_TOKEN(単一プロジェクトトークン)向いている場面1プロジェクトだけを見る個人利用
ROLLBAR_ACCOUNT_ACCESS_TOKEN(アカウントトークン)向いている場面アカウント配下の全プロジェクトを1つのトークンで横断したい場合
.rollbar-mcp.json(設定ファイル)向いている場面複数プロジェクトをプロジェクトごとに個別トークンで管理したい場合

アカウントトークンと個別プロジェクトトークンは併用もできます。アカウントトークンをread専用にしておき、書き込み(update-item)が必要な一部のプロジェクトだけread+writeのプロジェクトトークンを設定ファイルに追加する、という絞り方が可能です。設定ファイル側に明示されたプロジェクトのトークンは、同名のアカウントトークンより常に優先されます。

設定の優先順位を押さえておく

トークンの与え方は複数あるため、どれが優先されるかを最初に確認しておくと事故を避けられます。読み込み順は次のとおりです。

  1. ROLLBAR_CONFIG_FILE環境変数で指定したパス
  2. カレントディレクトリの.rollbar-mcp.json
  3. ホームディレクトリの~/.rollbar-mcp.json
  4. ROLLBAR_ACCESS_TOKENまたはROLLBAR_ACCOUNT_ACCESS_TOKEN環境変数

設定ファイルが存在するのに中身が壊れている場合、サーバーは下位の設定にフォールバックせずエラーで終了します。「なぜか環境変数のトークンが無視される」という相談は、大抵このケースです。存在するファイルの中身を先に確認します。

自社ホスティングのRollbarや検証用の別リージョンを使っている場合は、ROLLBAR_API_BASE(単一プロジェクト環境変数構成)や設定ファイルのapiBaseキーでAPIのベースURLを上書きできます。既定値はhttps://api.rollbar.com/api/1です。

もう1つ知っておくと便利な挙動があります。ROLLBAR_ACCESS_TOKENだけを設定し、明示的なアカウントトークンを与えていない場合、サーバーは初回に一度だけGET /projectsを呼んでそのトークンが実はアカウントトークンかどうかを自動判定します。アカウントトークンだと分かればアカウントモードへ自動で切り替わり、通常のプロジェクトトークンならそのまま単一プロジェクトとして動きます。この判定結果はキャッシュされるため、毎回追加のAPI呼び出しが発生するわけではありません。トークンの種類を意識せずROLLBAR_ACCESS_TOKENを設定するだけで、単一・複数どちらの構成にも自然に対応する設計です。

Claude Codeに接続する

.mcp.jsonにサーバーを追加します。単一プロジェクトなら環境変数だけで済みます。

{
  "mcpServers": {
    "rollbar": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@rollbar/mcp-server@latest"],
      "env": {
        "ROLLBAR_ACCESS_TOKEN": "<プロジェクトのread/writeアクセストークン>"
      }
    }
  }
}

トークンはRollbarのアカウント設定 → Account Access Tokensから発行します。update-item(ステータス変更)を使う予定がなければ、readスコープだけで残りの全ツールが動きます。書き込みが必要な場合だけread and writeを選びます。

複数プロジェクトを横断したい場合は.rollbar-mcp.jsonを作業ディレクトリかホームディレクトリに置き、envをROLLBAR_CONFIG_FILEに置き換えるだけです。

{
  "projects": [
    { "name": "backend",  "token": "tok_abc123" },
    { "name": "frontend", "token": "tok_xyz789" }
  ]
}

使えるツールと典型的な頼み方

list-projectsでまず接続先のプロジェクト一覧を確認できます。単一プロジェクトトークンなら設定した1件だけが、アカウントトークンならアカウント配下の全プロジェクトが返ります。

  • get-item-details(counter) — item番号を渡すと、item詳細と直近のoccurrence(発生インスタンス)をまとめて返します。「item詳細を見てから最新のエラーを別途取得する」という2手順を1回で済ませる設計です。例: 「Rollbar item #123456の根本原因を調べて」
  • get-deployments(limit) — 直近のデプロイ履歴を返します。エラーの発生・収束とデプロイのタイミングを突き合わせる用途です。例: 「直近5件のデプロイを一覧にして」
  • get-version(version, environment) — 特定バージョン(gitのSHAなど)がある環境でいつ最初に・最後に出現したかを調べます。あるリリースがバグを持ち込んだのか直したのかを確認する場面で使います
  • get-top-items(environment) — 指定環境で過去24時間に最も多く発生しているitemを返します。「今何が一番壊れているか」を最初に把握する起点です
  • list-items(status?, level?, environment?, query?) — statusの既定値はactiveで、解決済み・ミュート済みのitemは自動的に除外されます。テキスト検索も可能です
  • list-occurrences(counter, limit?, page?, last_id?) — item配下の個別発生を、タイムスタンプ・環境・エラー詳細付きで返します。occurrenceが多いitemではlast_idによるカーソルページングを使うとページ番号方式のような重複・欠落を避けられます
  • get-replay(environment, sessionId, replayId) — セッションリプレイのメタデータとペイロードを取得し、エラー発生直前のユーザー操作を追えます
  • update-item(itemId, status?, ...) — ステータス・レベル・タイトル・担当者・解決バージョンなどを変更します。書き込みスコープのトークンが必須です。例: 「item #123456をresolvedにして」

デプロイ突合でエラーの原因を絞り込む

一次調査で効くのは、get-top-itemsとget-deploymentsを組み合わせた聞き方です。

production環境で過去24時間に一番多く発生しているエラーを教えて。直近のデプロイと時刻が近いものがあれば教えて

Claudeはget-top-itemsで件数の多いitemを取得したあと、get-deploymentsで直近のデプロイ一覧を引き、時刻の近さから「このデプロイが怪しい」という仮説を組み立てられます。さらに疑わしいバージョンが分かればget-versionでそのバージョンの出現履歴を絞り込み、デプロイ直後から急増しているのか、以前から出ていたものかを切り分けられます。

デプロイv2.4.1がstaging環境に投入されたのが14時ちょうど。このバージョンでエラーが最初に発生したのはいつ?

get-versionはバージョン(gitのSHAなど)と環境を指定すると、そのバージョンのoccurrenceが最初と最後にいつ現れたかを返します。デプロイ時刻と最初の発生時刻がほぼ一致していれば、そのデプロイが原因である可能性が高いという判断材料になります。逆に発生時刻がデプロイよりずっと前から続いていれば、今回のデプロイとは無関係の既存バグだと切り分けられます。

よくあるつまずき

  • update-itemだけ失敗する: readスコープのトークンでは書き込み系ツールだけが弾かれます。アカウントトークンの場合は、プロジェクト解決のためのGET /projects呼び出し自体がread権限を必要とするため、write専用トークンではこの手前で失敗します。read and write両方を持つトークンを用意します
  • グループ化されたitemでoccurrenceが空に見える: 複数のitemが1つに束ねられたグループitemは、Rollbarの公開APIがまだoccurrence一覧に対応していません。この場合group_item_not_supportedという明示的なメッセージが返るので、実際に発生が0件なのか未対応なのかを取り違えずに済みます
  • get-replayが動かない: delivery="resource"を使うファイルレス方式は、サーバーが単一プロジェクトしか扱わない構成(単一プロジェクトトークン、またはプロジェクトが1つだけのアカウントトークン)でのみ機能します。複数プロジェクト構成ではdelivery="file"(既定)を使い、projectを明示します
  • .rollbar-mcp.jsonを置いたのに反映されない: 設定ファイルの検索順は環境変数ROLLBAR_CONFIG_FILE→カレントディレクトリ→ホームディレクトリの順です。カレントディレクトリに古い設定が残っていると、ホームディレクトリ側の更新が無視されます

リリースの頻度から見る開発の勢い

@rollbar/mcp-serverは2025年7月にnpmへ最初のバージョンが公開され、現在の最新版は0.6.0です。0.2系から0.6系まで、機能追加を挟みながら短い間隔でマイナーバージョンが上がっており、直近の更新も数日以内という頻度です。アカウントトークンの精度・グループitemの扱い・カーソルベースのページングといった、この記事で紹介した機能の多くも比較的新しく足された部分にあたります。エラー監視ツールのMCPサーバーとしては後発ですが、頻繁なリリースで機能を積み増している段階だと捉えておくと、今後もツールの追加や挙動の変更が起きやすいという前提で運用しやすくなります。

まとめ

Rollbar MCPサーバーは、item調査に必要な一連の操作(詳細取得・occurrence確認・デプロイ突合・バージョン履歴・セッションリプレイ)を1つのstdioサーバーにまとめています。設定の分岐は多いものの、単一プロジェクトならROLLBAR_ACCESS_TOKEN1つで最短の設定が終わり、複数プロジェクトを横断する場合もアカウントトークンと個別プロジェクトトークンを併用すれば権限を絞りつつ運用できます。エラーの一次調査をRollbarの画面を開かずにClaude Codeのセッション内で完結させたいチームには、導入コストの低い選択肢です。

MCPサーバーの追加構文やスコープ管理の全体像はClaude Code MCP設定ガイドにまとめています。stdio方式ではなくリモート型のMCPサーバーの接続例はSlack MCPサーバーの使い方が参考になります。MCPのHost/Client/Serverという基本構造から確認したい場合はMCPアーキテクチャの三層構造を先に読むと理解が早くなります。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →