Claude CodeのFiretigerプラグインで本番の調査をMCPで回す

Firetigerプラグインは、オブザーバビリティ基盤FiretigerをClaude Codeにつなぎ、本番の調査をMCP経由で回すためのプラグインです。中身は https://api.cloud.firetiger.com/mcp/v1 へのHTTP接続設定と、7つのskillsだけです。トレース・ログ・メトリクスへのSQL照会、障害の調査、PRごとのデプロイ監視まで、エディタを離れずに頼めます。

ここでは入れるものの中身、導入と認証、6つの使い方、そして取り違えやすい点を順に説明します。

このプラグインに入っているもの

Claude Codeのプラグインは、skillsとMCPサーバーを1つにまとめて配る仕組みです。Firetigerプラグインのリポジトリは、4つのものだけで構成されています。

マーケットプレイスの説明文は「Firetigerのオブザーバビリティ・ワークフローとMCPによる調査のためのClaude Codeプラグイン」です。リポジトリの冒頭では、Firetiger側のエージェントが監視・調査・既知の問題の整理・runbookの適用を自律的に進め、Claude Codeはコードの構築とデバッグを助ける、という役割分担が説明されています。

MCPとskillsが同じパッケージで届く点は、プラグイン同梱のMCPサーバーと同じ型です。claude mcp add を自分で打つ必要はありません。

導入と認証

掲載ページには「Install in Claude Code」の導線があります。コマンドで入れる場合は、/plugin の画面でマーケットプレイスからfiretigerを探します。マーケットプレイスの追加と一覧の見方は、プラグインとマーケットプレイスの解説にまとめています。

入れる前に中身を確かめたいときは、リポジトリをクローンしてプラグインディレクトリ指定で起動できます。

git clone https://github.com/firetiger-oss/claude-plugin.git
claude --plugin-dir ./claude-plugin

認証はOAuthです。Firetigerの公式ドキュメントによると、Claude Codeでは最初の接続時にOAuthの流れが走り、Firetigerのアカウントでサインインします。ヘッダーの設定は要りません。接続は /mcp で確かめられます。

スクリプトやCIから使うときは、OAuthの代わりにAPIキーも使えます。FiretigerのUIでAPIキーを作り、アクセスレベルはread-writeを選びます。read-onlyのキーは /mcp/v1 に届きません。この場合は、プラグインを使わずに次の形でMCPを足す方法がドキュメントに載っています。

claude mcp add firetiger --transport http \
  --header "Authorization: $FT_AUTH" \
  https://api.cloud.firetiger.com/mcp/v1

$FT_AUTH には、キーを作ったときのダイアログに表示される Basic ... の文字列を入れます。パスワードが表示されるのは作成時の1回だけです。

6つのスラッシュコマンドを使い分ける

掲載ページは、ライフサイクルに沿った6つのスラッシュコマンドを挙げています。実体は、先ほどの7つのskillsのうち、入口になる firetiger を除いた6つです。入口の firetiger は、依頼内容を見て専門のskillへ振り分けるルーター役です。

「ログを見て」「このPRを監視して」のように普通に頼んでも、Claudeが説明文から適切なskillを選びます。コマンドは、使うものを自分で決めたいときの近道です。

setup: 導入を1回で終わらせる

setup は、まず get_ingest_credentials を呼びます。必要ならFiretiger側のバックエンドを自動で用意し、OTLPの送信先とユーザー名・パスワードを返します。課金が有効な環境では、続けて契約状態を確認し、無料枠の bootstrap か有料の growth のチェックアウトURLを開く手順も入っています。

その後、コードベースを調べてスタックを検出します。見るのはデプロイ先(Vercel・Cloudflare・AWS・GCP)、既存の計測(OpenTelemetry・Datadog・Prometheus・Vector)、データベース、GitHubなどです。検出結果に応じて、プラットフォームのドレイン、Datadog Agentの向き先変更、Prometheusの remote_write などを選びます。該当がなければ、instrument に引き継ぎます。

この流れで意外なのが、取り込みを前提にしていない点です。skill自身が、DatadogやPrometheus、GCPメトリクス、データベースには、取り込まずにFiretigerから照会する「プル型」の接続があると書いています。すでに計測基盤を持つチームは、計装を足さずに始められる場合があります。

また、GitHubの連携は早めに済ませる前提です。デプロイ監視と、サービスの自動検出の両方に必要なためです。サービスの自動検出は、GitHubと、テレメトリーまたは照会元の両方がつながって初めて動きます。

instrument: OpenTelemetryを正しい順序で入れる

instrument はNode.js・Next.js・Python・Go・Rustに対応しています。注意点は2つです。

• 初期化は、他のどのimportよりも先に読み込む(後から読むとExpressやDBドライバーに自動計装が効かず、スパンが出ない)
• Firetigerの取り込み認証はBearerではなくHTTP Basic認証(Authorization=Basic <base64(user:password)>)

環境変数は次の3つが基本です。

OTEL_EXPORTER_OTLP_ENDPOINT="https://ingest.cloud.firetiger.com"
OTEL_EXPORTER_OTLP_HEADERS="Authorization=Basic <base64(username:password)>"
OTEL_SERVICE_NAME="your-service-name"

エンドポイントは get_ingest_credentials が返す値を使う、とskillは念を押しています。組織やリージョンで変わりうるためです。認証情報を含む .env.local は .gitignore に入れます。

OTEL_SERVICE_NAME はあとで効いてきます。この名前が、照会するテーブル名の一部になるからです。

query: 「テーブル名は引用符で囲む」だけ覚える

FiretigerはテレメトリーをApache Icebergのテーブルに置き、MCPの query ツールがDuckDBのSQLを受け付けます。query は接続のたびに既定の接続先を指定するので、テーブルは名前だけで参照します。

checkout-service の直近1時間のエラースパンを、遅い順に20件出して。
先に SHOW TABLES でテーブル名を確かめて。

この依頼がうまくいくために、skillが前提にしている決まりがいくつかあります。例えば次のような形のSQLです(skillのクイックスタートに沿った形)。

SELECT trace_id, name, end_time - start_time AS duration, start_time
FROM "opentelemetry/traces/checkout-service"
WHERE start_time >= NOW() - INTERVAL '1 hour'
  AND status.code = 2
ORDER BY duration DESC
LIMIT 20;

ログのテーブルは "opentelemetry/logs/{service_name}"、メトリクスは1つずつ別のテーブルです。ログの重大度は整数で、WARN以上は severity_number >= 13 で絞れます。

接続済みのPostgres・MySQL・ClickHouseは、"connections/{name}".schema.table の形で同じ query から読めます。Datadog・Prometheus・GCP Monitoringは、datadog_search_logs(...) のような関数で呼びます。ただしTrinoとElasticsearchは、query ツールからは届きません。

investigate: 調査はエージェントのセッション

investigate で押さえる点は、調査が書類ではなくエージェントのセッションだということです。investigations に問題の記述を渡して作ると、Firetiger側の investigate エージェントが影響範囲を把握し、クエリを走らせ、原因に向かって推論します。

/firetiger:investigate checkout-service の5xxが14:20 UTCから約4倍。
原因と影響範囲を調べて。

調査リソースには、結論を書くフィールドがありません。status もサーバー側が設定する値(実行中の EXECUTING と、入力待ちの WAITING)で、人が「解決」にはできません。進め方を変えたいときは、send_agent_message でセッションに指示します。中身を読むのは read_agent_messages です。

調査の成果として残るのは、Issue(既知の問題)です。IDは FT-{番号} 形式でサーバーが採番し、状態は調査中、対応可能、修正の検証中、完了の順に進みます。完了には理由が必須で、解決済み・リスク受容・誤検知・重複・有用でない、のいずれかを選びます。

Issueのトリアージは専任のエキスパートエージェントが担います。そのため、フィールドを手で書き換えて進めるのではなく、Issueのセッションへメッセージを送るのが正しい使い方です。

monitor-deploy: PRをデプロイ後まで見張る

Claude Codeの作業中にPRのURLがあるなら、MCPの monitor_pr を使います。URLは https://github.com/org/repo/pull/123 の完全な形で渡します。PRの差分から監視計画が作られ、デプロイ後に事前の基準値と比べる仕組みです。

GitHubのPRにコメントする方法もあります。

gh pr comment 123 --body "@firetiger checkout の5xxとレイテンシの悪化を見て"

どちらの場合も、確認の合図として目のリアクションが付き、監視計画がPRコメントとして投稿されます。マージとデプロイの後、10分・1時間・24時間・72時間のチェックポイントで確認が走り、結果はPRとIssueに出ます。掲載ページには「デプロイ後10分から72時間」と書かれており、この4点と整合します。

@firetiger のコメントには、FiretigerのGitHub Appの連携が必要です。連携がないと、メンションは無視されます。チェックポイントの基準になるのはコメントの時刻ではなく、実際のデプロイ時刻です。デプロイを検知できない環境では、CIから /deployments にデプロイ情報をPOSTして登録します。認証はここでもBasicです。

create-agent: 目的を日本語で伝える

常設の監視は、create_agent_with_goal に目的を渡して作るのが推奨の経路です。

/firetiger:create-agent checkoutのAPIルートのエラーと遅い応答を監視して。
エラー率の急増とp95レイテンシの悪化を通知して。

プランナー(計画を立てる内部エージェント)が、プロンプト・接続・トリガーを設定します。プランナーが質問を返してきたら、send_agent_message で答えないと作成が終わりません。

用意されたカタログから入れる方法もあります。Postgres・MySQL・ClickHouse・Temporalの性能、AWSのコスト最適化、Datadogのコスト分析などのテンプレートが並びます。ただし、カタログから入れたエージェントは AGENT_STATE_RECOMMENDED で始まり、人が AGENT_STATE_ON にするまで動きません。

トリガーはエージェントとは別のリソースで、cron・手動・デプロイ後・テーブルへの行の到着・Slackのメッセージ・Slackでのメンションの6種類です。scheduled-agent-runs は定期実行ではなく1回限りの遅延実行なので、繰り返しにはcronトリガーを使います。

使い始めて詰まりやすい点

skillが「よくある間違い」として挙げている点のうち、実際に手戻りになりやすいものを抜き出します。

• MCPツールが見えないときは、まだ接続していません。/mcp でfiretigerにサインインしてから、同じ依頼をやり直します
• 計装の初期化が遅いと、データが何も出ません
• OTEL_SERVICE_NAME の綴りが、照会するテーブル名と食い違うことがあります
• テーブル名を推測せず、SHOW TABLES; と DESCRIBE で確かめます
• 認証情報を含むファイルをコミットしません
• 作成・更新の前は schema でフィールドを確かめます。フィールドは変わりうるためです

他の観測系プラグインとの違い

同じ観測データを扱う別のプラグインもあります。モニタリングチェックを作る用途ならChecklyプラグイン、障害調査ならgroundcoverプラグインの記事が参考になります。

Firetigerプラグインの特徴は、調査をClaude Codeの中で完結させず、Firetiger側のエージェントに任せる点です。Claude Codeは依頼の窓口とコード修正を担い、長い調査や常設の監視はFiretigerのセッションとして残ります。コードと観測データを往復する作業が多い開発では、この分担が効きます。

一方で、データはFiretigerに置く前提です。すでにDatadogなどの基盤がある場合は、プル型の接続で照会元として足す形から始められます。