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

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

Claude Codeに接続する

npx経由で起動できるため、ローカルへの事前インストールは不要です。単一プロジェクトなら、トークンを環境変数で渡すだけで接続できます。

手順2のコマンドは次の形です。

claude mcp add -s project rollbar -e ROLLBAR_ACCESS_TOKEN=<トークン> -- npx -y @rollbar/mcp-server@latest

Claude Code v2.1.287で、一時ディレクトリに対してこのコマンドを実行すると、作業ディレクトリに.mcp.jsonが次のとおり生成されました(トークンはダミー値です)。READMEのClaude Code向け設定と同じ構造です。

{
  "mcpServers": {
    "rollbar": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@rollbar/mcp-server@latest"],
      "env": {
        "ROLLBAR_ACCESS_TOKEN": "dummy-token"
      }
    }
  }
}

注意点が2つあります。1つ目は、-s projectを付けるとトークンが.mcp.jsonに平文で書き込まれることです。このファイルはリポジトリに入れて共有する前提のスコープなので、トークンを含めたままコミットしない運用が必要です。READMEも、トークンは秘密情報の管理機構かシェルの環境設定に置き、ソース管理に入れないよう書いています。トークンをファイルに残したくない場合は、後述のROLLBAR_CONFIG_FILEでリポジトリ外のパスを指す方法があります。

2つ目は、-eの書き順です。-eは複数の値を取るオプションなので、claude mcp add -e ROLLBAR_ACCESS_TOKEN=... rollbar -- npx ...のようにサーバー名より前に置くと、rollbarまで環境変数として読まれてしまいます。同じv2.1.287で試すと、次のエラーで登録に失敗しました。

Invalid environment variable format: rollbar, environment variables should be added as: -e KEY1=value1 -e KEY2=value2

サーバー名を先に書き、-eを後ろに置くと通ります。claude mcp addの使い方全般はClaude Code MCP設定ガイドで扱っています。

トークンの与え方は権限設計で決まる

トークンの与え方は3通りあります。単一プロジェクトのROLLBAR_ACCESS_TOKEN、アカウント全体のROLLBAR_ACCOUNT_ACCESS_TOKEN、そして.rollbar-mcp.jsonによる設定ファイルです。選ぶ基準は、横断したいプロジェクトの数と、書き込みを許す範囲です。

2つは併用できます。アカウントトークンをread専用にしておき、書き込み(update-item)が必要なプロジェクトだけ、read and writeのプロジェクトトークンを設定ファイルに追加します。

{
  "accountToken": "acct_tok_abc123",
  "projects": [
    { "name": "backend", "token": "tok_backend_readwrite" }
  ]
}

設定ファイルに明示したプロジェクトのトークンは、アカウントトークンより常に優先されます。上の例なら、backendだけ書き込みでき、ほかのプロジェクトは読み取り専用のままです。プロジェクトが1つだけなら、{ "token": "tok_abc123" }という短縮形も使えます。複数プロジェクトをトークン別に管理する場合は、READMEのprojects配列にnameとtokenの組を並べます。

アカウントトークンを使うときは、スコープの組み合わせに注意が必要です。アカウントトークンでの呼び出しは、最初にプロジェクトを特定するためGET /projects(read)を呼び、そのあとでPATCH(write)を呼びます。write専用トークンだと、更新に届く前の特定の段階で失敗します。READMEが示す指針は、update-itemが必要でなければread権限のトークンで運用する、というものです。

設定が効かないときは優先順位を疑う

.mcp.jsonに書いたはずのトークンや設定ファイルが反映されないときは、まず読み込み順を確認します。順序は次のとおりです。

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

設定ファイルが存在するのに中身が壊れている場合、サーバーは下位の設定にフォールバックせず、エラーで終了します。「環境変数のトークンが無視される」ときは、まず上位の設定ファイルが残っていないかを確認します。カレントディレクトリに古い設定が残っていると、ホームディレクトリ側を更新しても反映されません。

.rollbar-mcp.jsonをカレントまたはホームに置く場合、.mcp.jsonのenvブロックは不要です。パスを明示したいときだけ、envにROLLBAR_CONFIG_FILEを書きます。

自社ホスティングのRollbarや検証用のAPIを使うときは、ROLLBAR_API_BASE環境変数か設定ファイルのapiBaseキーでAPIのベースURLを上書きできます。既定値はhttps://api.rollbar.com/api/1です。

トークンの種類を意識しなくて済む仕掛けもあります。ROLLBAR_ACCESS_TOKENだけが設定されていてアカウントトークンが明示されていない場合、サーバーは初回に一度だけGET /projectsを呼び、そのトークンがアカウントトークンかどうかを調べます。アカウントトークンならアカウントモードに自動で切り替わり、判定結果はキャッシュされます。通常のプロジェクトトークンなら、これまでどおり単一プロジェクトとして動きます。

使えるツールと聞き方

list-projectsは接続先の確認用です。単一プロジェクトトークンなら設定した1件、アカウントトークンならアカウント配下の全プロジェクトが返ります。調査用のツールは次のとおりです。

• get-item-details(counter): item番号を渡すと、item詳細と直近のoccurrence(発生インスタンス)をまとめて返します。「item詳細を見てから最新のエラーを別途取得する」手間を1回で済ませる設計です。例は「Rollbar item #123456の根本原因を調べて」
• get-deployments(limit): 直近のデプロイ履歴を返します。例は「直近5件のデプロイを一覧にして」。失敗したデプロイの有無を尋ねる使い方もREADMEに載っています
• get-version(version, environment): gitのSHAなどのバージョンが、ある環境でいつ最初に・最後に出現したかを返します
• get-top-items(environment): 指定環境で過去24時間に最も多く発生しているitemを返します
• list-items(status?, level?, environment?, query?): statusの既定値はactiveで、解決済み・ミュート済みのitemは除外されます。pageとlimitで取得量を絞り、queryでテキスト検索もできます
• list-occurrences(counter, limit?, page?, last_id?): item配下の個別の発生を、タイムスタンプ・環境・エラー詳細つきで返します
• get-replay(environment, sessionId, replayId): セッションリプレイのメタデータとペイロードを取得し、エラー直前のユーザー操作を追えます
• update-item(itemId, status?, ...): ステータス・レベル・タイトル・担当者・解決バージョン・スヌーズ・担当チームを変更します。書き込み権限のトークンが必須です。例は「item #123456をresolvedにして」

ページングには2通りあります。occurrenceが多いitemでは、直前に受け取った最後のidをlast_idに渡すカーソル方式が使えます。ページ番号方式だと、呼び出しの間にoccurrenceが入れ替わったときに結果の重複や欠落が起こりえますが、カーソル方式はそれを避けるための仕組みです。両方を渡した場合はlast_idが優先されます。

一次調査の流れ: 件数の多いエラーからデプロイに当たる

調査の起点は、get-top-itemsでいま一番壊れているitemを知ることです。そこからデプロイとバージョンに絞り込みます。

一度の依頼でここまで進めるなら、次のように聞きます。

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

Claudeはget-top-itemsの結果にget-deploymentsの一覧を重ね、時刻の近さから「このデプロイが怪しい」という仮説を組み立てられます。バージョンが絞れたら、次のように続けます。

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

デプロイ時刻と最初の発生時刻がほぼ一致していれば、そのデプロイが原因である可能性が高いと言えます。発生がデプロイよりずっと前から続いていれば、今回のデプロイとは別の既存バグとして切り分けられます。

つまずきの切り分け

• update-itemだけ失敗する: readスコープのトークンは、書き込み系のツールだけが弾かれます。プロジェクトトークンならwriteスコープ、アカウントトークンならreadとwriteの両方が必要です
• グループ化されたitemでoccurrenceが空に見える: 複数のitemを束ねたグループitemは、RollbarのAPIがoccurrence一覧にまだ対応していません。この場合group_item_not_supportedというメッセージが返ります。発生が0件のitemと見分けるための明示的な応答です
• get-replayでdelivery="resource"が動かない: rollbar://リンクで返すこの方式は、サーバーが単一プロジェクトしか扱わない構成でのみ機能します。単一プロジェクトトークンか、プロジェクトが1つだけのアカウントトークンが該当します。複数プロジェクト構成ではdelivery="file"(既定)を使い、projectを明示します。file方式は一時ファイルにJSONを書き出すため、ファイルの後始末は自分で行います

@latestで起動するときの版の扱い

@rollbar/mcp-serverの初版0.1.0は2025年7月27日にnpmへ公開されました。npmのレジストリには0.1.0から0.6.1まで13のバージョンが並びます。主なバージョンの公開日は、0.3.0が2025年10月15日、0.4.0が2025年11月11日です。続く0.5.0が2026年3月25日、0.6.0が2026年7月27日、0.6.1が2026年9月29日(UTC)です。0.4.0から0.5.0まで、0.5.0から0.6.0までは、どちらも4か月前後の間隔が空いています。

.mcp.jsonの例が@rollbar/mcp-server@latestを指しているため、起動のたびに最新版が使われます。npmの版を固定すれば特定の版での挙動を再現できるので、挙動が急に変わったときの切り分けに使えます。

まとめ

まずreadのトークンで調査だけを任せ、ステータス更新まで任せるかは運用が固まってから決める、という順序が取りやすい構成です。

エラーの一次調査をRollbarの画面を開かずにClaude Codeのセッション内で済ませたいチームには、導入コストの低い選択肢です。リモート型のMCPサーバーを繋ぐ例はSlack MCPサーバーの使い方に、HostとClientとServerの基本構造はMCPアーキテクチャの三層構造にあります。