はじめに
こんにちは！KIYOラーニング で AirCourse の開発をしている森下です。
今回は、Claude Code のスキルで New Relic CLI と Backlog MCP を組み合わせ、エラー調査と進捗管理を自動化した話をご紹介します。
今回は、普段から使い慣れている New Relic CLI を利用しました。MCP を利用する方法も考えられますが、本記事では CLI ベースの構成で紹介します。
普段のエラー監視では「これバグ？」「もう起票した？」「対応中？」「直したのにまた出てる（再発）？」を1件ずつ確認していて、これが地味に大変でした。そこで、調査レポートの作成と進捗ダッシュボードの更新をまとめて行うスキルを自作しました。この記事では、その中身・仕組み・作り方までを一通り解説します。
Claude Code の「スキル（Skill）」は、AI に業務の手順を覚えさせて再利用できる仕組みです。今回はこれで一連のエラー対応を自動化しました。
【目次】
- こんな人におすすめ
- このスキルが作る2つの成果物
- スキルでできること
- なぜ作ったか（背景）
- 前提ツール
- 成果物① モニタリング調査レポート
- 成果物② 進捗ダッシュボード
- このスキルの一番のポイント：対応状況の可視化と再発検知
- 仕組み：New Relic と Backlog をどうつないでいるか
- 作り方とセットアップ
- まとめ
- 最後に
- KIYOラーニング株式会社について
良かったら最後まで見てください！
こんな人におすすめ
- New Relic でエラー監視はしているが、対応状況（対応中／完了／再発）の管理が大変な方
- New Relic と Backlog のように、監視ツールと課題管理ツールの突き合わせを手作業でやっている方
- Claude Code のスキルで自分の業務を自動化してみたい方
このスキルが作る2つの成果物
ac-error-triage を実行すると、次の2つが自動で作られます。
- モニタリング調査レポート（Markdown） … その時点のエラーを appName ごとにトリアージした調査レポート
- 進捗ダッシュボード（HTML） … エラーが Backlog で対応済みか・再発していないかを一覧で確認できる進捗ダッシュボード
スキルでできること
- 対象アプリ・対象期間を対話で確認（期間は「昨日10:00〜現在 / 直近1週間 / 直近2週間 / 直近1カ月」から選択）
- 5つの観点（PHP例外・JSエラー・4xx・5xx・DB負荷）を appName ごとに横断集計
- 先週比などで急増（🚨）を検知
- 外部要因やクライアント環境起因など、想定内のノイズと実バグ候補を仕分け
- 実バグ候補が Backlog に起票済みかを検索し、状態・リリース予定日・進捗段階を確認
- 継続的なエラー管理のための台帳更新
- 状態（対応中／完了／再発／リリース待ち／未起票／沈静化）を判定して HTML ダッシュボードを再生成
なぜ作ったか（背景）
Web サービスを運用していると、New Relic にはいろんなエラーが流れてきます。私たちのチームの運用フローはこうです。
[New Relic でエラー確認] → [ソースコード調査で原因確認] → [バグなら Backlog にチケット起票] → [対応して直す]
シンプルなのですが、エラー1件1件に対して毎回こんな確認を手作業で繰り返すことになり、これが地味に面倒です。
- そもそもこれはバグなのか？（外部要因や想定内のアクセスによるノイズではないか）
- バグだとして、もう Backlog に起票済みか？
- 起票済みなら、今は対応中か、もう完了か？
- 完了なら、再発なのでは？
- それとも件数が少ないし様子見でいいやつ？
しかも、この確認をアプリ（appName）ごと・エラーの種類ごとに繰り返す必要があり、正直しんどいです。
さらに New Relic と Backlog という2つの別々の画面を行き来して突き合わせる手間もかかります。
この「1件ずつの確認」と「2画面の突き合わせ」を毎回手作業でやるのをやめたい。それが ac-error-triage を作った理由です。
前提ツール
それぞれ多機能なツールですが、ここではこの記事での役割に絞って紹介します。各ツールが本来できることはもっと広いので、詳細は公式ドキュメントを参照してください。
| ツール | この記事での役割 |
|---|---|
| New Relic | アプリのエラーやパフォーマンスを監視するサービス。本記事では「今どんなエラーが出ているか」の情報源として使います。 |
| New Relic CLI | New Relic をコマンドラインから操作する公式ツール。本記事では NRQL でエラーを集計・取得する用途だけに使っています。（ダッシュボード操作やデプロイ記録など、他にもできることは多数あります） |
| Backlog | 課題管理ツール。本記事では「そのエラーが起票済みか・対応中か完了か」の情報源として使います。 |
| MCP | AI が外部ツールとつながるための共通規格。本記事では Claude が Backlog を読むための接続に使っています。 |
| Claude Code | ターミナルで動く AI アシスタント。本記事では一連の調査を実行する役割で使います。 |
| スキル（Skill） | Claude Code に手順を覚えさせる仕組み。今回は「調査＆進捗管理」の手順を覚えさせるのに利用しています。 |
New Relic からデータを取り出すときは、NRQL という SQL に似た言語を使います（例：「過去1週間のエラーを集計して」）。スキルが裏で組み立ててくれるので、使う側が書く必要はありません。
成果物① モニタリング調査レポート
appName ごとに「5つの観点（PHP例外・JSエラー・4xx・5xx・DB負荷）＋先週比」のサマリーを出し、そのあとに実バグ候補を1件ずつ掘り下げ、最後にノイズ集計と推奨アクションを並べます。実際にサンプル用に出力されたレポートから一部を抜粋します。
総評（冒頭に全体所感）
全体的に許容範囲で、新規の重大事象なし。前週に目立っていた事象はいずれも大幅に減少。新規の急増🚨は一部アプリの 4xx のみで、主因は想定内のアクセス制御によるもの。ユーザーへの実害は限定的。
以下のサマリーは記事用に内容を抽象化したサンプルです。実際の数値や原因とは無関係です。
アプリ別サマリー（抜粋）
「先週比」は前週の同じ期間との比較です（1.0 を超えると増加、🚨 は目立った急増）。
■ app-name-01（アプリA）
- PHP例外 : 9件（先週比 2.25倍）— 軽微な警告が中心で低頻度
- JSエラー : 78,462件（先週比 1.07倍）— ほぼ横ばい。大半はクライアント環境起因の可能性が高いもの
- 4xx : 13,243件（先週比 1.53倍 🚨 急増）— 主因は想定内のアクセス制御によるもの
- 5xx : 12件（先週比 1.09倍）— 一部操作で散発する軽微なもの
- DB負荷 : 問題なし
■ app-name-02（アプリB）
- PHP例外 : 20件（先週比 0.09倍）— 前週から大幅に減少
- 5xx : 23件（先週比 0.10倍）— 前週から大幅に減少
- DB負荷 : ⚠ 一部の処理が重め（応答に時間がかかるものがある）
実バグ候補（1件ずつ掘り下げ・抜粋）
4. 管理画面の一部で軽微な警告（app-name-03 / 12件）
- バグらしさ : 中（画面は動く(HTTP200)が、警告が出続けてログのノイズ源になっている）
- 発生箇所 : 管理ツールの一部画面
- 概要 : 外部連携先の仕様変更で参照していたデータの一部が取得できなくなり、
画面側がそれを参照し続けているため警告が出ている
- Backlog : 既に起票済み（PROJ-XXXX・処理中／リリース前のレビュー段階）。
新規対応は不要で、状態のフォローだけでよい
このように「件数」「先週比」「発生箇所」「見立て」「Backlog の起票有無と状態」までを1件ずつ揃えてくれるので、人間は「で、どうする？」の判断に集中できます。
成果物② 進捗ダッシュボード
レポートが「その時点の調査結果をまとめた文書」なら、ダッシュボードは「エラーの現在の状態を一覧で把握するための画面」です。完成イメージは次のとおりで、状態ごとに色分けされ、絞り込みや並べ替えもできます。
以下の進捗ダッシュボードは記事用に作成したサンプルです。実際の数値や原因とは無関係です。
- 状態の色バッジ（🔴 再発／🟠 リリース待ち／🟡 対応中／⚪ 未起票／🟢 完了／⚫ 沈静化）で状態が分かる
- 状態・アプリでの絞り込みと、列のソートができる
- 各エラーの Backlog チケット・初検知/最終検知・件数（合計＋検知日ごとの内訳）を1行で表示
再発や対応中など「今どれを見るべきか」をすぐ拾えるようにしてあります。
このスキルの一番のポイント：対応状況の可視化と再発検知
この記事で一番伝えたいのはここです。New Relic は「今エラーが出ている」ことは分かりますが、それが未対応なのか・対応中なのか・もう直したのかまでは教えてくれません。このスキルは検知したエラーを Backlog のチケットと突き合わせ、各エラーの「今の状況」を一覧で把握できるようにします。状況が分かって初めて「次に何をすべきか」を判断できるようになります。
そして状況が分かると、一歩進んで「直したはずなのにまた出ている＝再発」も見分けられます。ここで大事なのは「完了＝直った」と単純に決めつけないことです。たとえば Backlog のチケットが「完了」でも、まだ本番にリリースされていないことがあります。その場合はエラーが出続けるのが当たり前で、再発ではありません。そこで二段構えで判定しています。
- 「本番に反映済みか」を、Backlog のリリース予定日（無ければマイルストーンの段階。例：
本番リリース承認／本番モニタリング中）で判定 - そのうえで「本番反映後もまだ出ているか」を New Relic の発生状況で確認
判定表はこうです。
| 今出ている？ | チケット | 本番反映 | → 状態 |
|---|---|---|---|
| 出ている | 完了 | 済み | 🔴 再発（修正後も再び発生） |
| 出ている | 完了 | まだ | 🟠 リリース待ち（出て当然。再発ではない） |
| 出ている | 処理中/未対応 | — | 🟡 対応中 |
| 出ている | 無し | — | ⚪ 未起票 |
| 出ていない | 完了 | 済み | 🟢 完了 |
| 出ていない（しばらく） | 無し | — | ⚫ 沈静化 |
「完了にしたはずのエラーが、本番に出てからもまだ発生している」を 🔴 で目立たせることで、「直したと思っていたバグの再発」を逃さずに済みます。
仕組み：New Relic と Backlog をどうつないでいるか
New Relic は「今出ているエラー」、Backlog は「その対応状況」と、見たい情報が2つのツールに分かれています。この2つを突き合わせるのが、このスキルの肝でした。
- New Relic CLI で「今どんなエラーが出ているか」を取得（NRQL で集計・トリアージ）
- Backlog MCP で「そのエラーは対応済みか」を取得（チケットの状態・リリース予定日・マイルストーン）
-
ローカル台帳（
registry.json） で「昨日のあのエラー」と「今日のこのエラー」を同じものだと同定し続ける
① New Relic CLI で集計・トリアージ
↓
② Backlog MCP でチケットの状態・リリース予定日を取得
↓
③ 台帳(registry.json)と突き合わせて同一エラーを同定・更新
↓
④ 状態（対応中/完了/再発/リリース待ち…）を判定
↓
⑤ Markdownレポート ＋ HTML進捗ダッシュボードを出力
台帳があることで、調査が「その場限り」ではなく「時系列で追い続けられる」ようになり、再発検知が可能になります。
作り方とセットアップ
スキル本体は skill-creator で作成
このスキルは、Anthropic 公式の skill-creator を使って作りました。スキルの雛形作り・テスト・改善のループを助けてくれるスキルです。
skill-creator 自体の使い方は本記事では深入りしません。別記事や公式ドキュメントを参照してください。ここでは「これを使うとスキル作りが一気に楽になる」とだけ紹介します。
設定手順①：New Relic CLI（コマンドで導入）
New Relic CLI をインストールし、プロファイル（API キー・アカウントID）を登録します。
# インストール（公式：OS ごとのパッケージマネージャ）
# macOS
brew install newrelic-cli
# Linux
sudo snap install newrelic-cli
# Windows
scoop bucket add newrelic-cli https://github.com/newrelic/newrelic-cli.git
scoop install newrelic-cli
# プロファイル登録（API キー・リージョンは必須。値は自分のものに置き換え）
newrelic profile add \
--profile aircourse \
--region us \
--apiKey <YOUR_USER_API_KEY> \
--accountId <YOUR_ACCOUNT_ID>
# 動作確認（1時間のトランザクション件数）
newrelic nrql query --accountId <YOUR_ACCOUNT_ID> \
--query "SELECT count(*) FROM Transaction SINCE 1 hour ago"
インストール手順は公式チュートリアルが最新です。プロファイルは API キーとリージョン（
usまたはeu）が必須です。
設定手順②：Backlog MCP（.mcp.json に貼るだけ）
プロジェクト直下の .mcp.json に次を追記するだけです。
※今回はDocker で行ってます。
{
"mcpServers": {
"backlog": {
"type": "stdio",
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "BACKLOG_DOMAIN=<your-space>.backlog.com",
"-e", "BACKLOG_API_KEY=<YOUR_BACKLOG_API_KEY>",
"ghcr.io/nulab/backlog-mcp-server"
],
"env": {}
}
}
}
BACKLOG_DOMAIN は自分のスペース（例：xxxx.backlog.com）、BACKLOG_API_KEY は Backlog の「個人設定 → API」で発行したキーに置き換えてください。
API キーは秘密情報です。
.mcp.jsonを Git にコミットする運用なら、キーは環境変数や.gitignore対象ファイルに分離するのが安全です。
ファイル構成
スキルは1つのディレクトリにまとまっています。
ac-error-triage/
├── .claude-plugin/
│ └── plugin.json # プラグインのメタ情報
├── README.md
└── skills/
└── ac-error-triage/
├── SKILL.md # スキル本体（手順書）
├── references/
│ ├── nrql-catalog.md # 観点別の NRQL クエリ集
│ ├── known-noise.md # 既知ノイズの参考リスト
│ └── registry-schema.md # 台帳スキーマ・状態ステートマシン
└── scripts/
├── nrql.sh # New Relic CLI 呼び出しヘルパー
└── render_dashboard.py # registry.json → dashboard.html
ポイントは、
- SKILL.md に「何を・どの順で調べ、どう判定するか」を書く（手順書）
- 細かい知識は references/ に分離（NRQLの定型、ノイズの見分け方、台帳の状態遷移ルール）
- 機械的な処理は scripts/ に切り出す（HTML 生成は Python に任せ、判断は Claude が担う）
という役割分担です。判断は AI に、定型処理はスクリプトに任せる、というのが作ってみて分かったポイントでした。
SKILL.md の中身（抜粋）
スキルの“手順書”である SKILL.md は、先頭に「いつ・何のために使うか」を書く frontmatter があり、本文にワークフローを番号付きで並べるだけです。実物を一部抜粋します（社内固有の値は伏せています）。
---
name: ac-error-triage
description: |
New Relic CLI で対象アプリ・対象期間のエラーを横断的に調査する。
PHP例外・JSエラー・4xx/5xxレート・DB負荷 を appName 別に集計し、前日比/先週比で異常を検知。
ノイズと実バグを仕分け、実バグ候補は Backlog に起票済みかを確認する。
集計結果やノイズ集計表をまとめた「調査レポート（Markdown）」を出力し、
さらに実行をまたいだ台帳で状態（対応中/完了/再発）を管理して「進捗ダッシュボード（HTML）」を更新する。
when_to_use: |
「New Relicのエラーを調べて」「このエラーは対応中？」「完了したのに再発してない？」
「進捗ダッシュボードを更新して」など、調査・トリアージ・進捗管理を頼まれたら使う。
allowed-tools: Bash(newrelic:*), Bash(python3:*), …, mcp__backlog__get_issues, mcp__backlog__get_issue
---
本文のワークフローはチェックリスト形式。Claude はこの順に進めます。
- [ ] ステップ1：期間 → 対象アプリ（appName）を対話で確定
- [ ] ステップ2：アプリ別に5観点を集計（PHP例外/JSエラー/4xx/5xx/DB負荷）
- [ ] ステップ3：前日比・先週比を算出し急増を検知
- [ ] ステップ4：ノイズ/想定内を仕分け、実バグ候補を深掘り
- [ ] ステップ5：Backlog で既起票確認＋台帳の既存チケットの状態を取得
- [ ] ステップ6：調査レポートを出力して保存
- [ ] ステップ7：追跡台帳 registry.json をマージ更新（状態・再発を導出）
- [ ] ステップ8：進捗ダッシュボード dashboard.html を再生成
このように「やることを日本語の手順で書く」だけでスキルになります。細かい判断基準（NRQL の定型、ノイズの見分け方、状態遷移ルール）は references/ に逃がし、SKILL.md 本体は読みやすさを保つようにしています。
使い方
スキルとして登録してあるので、Claude Code でスラッシュコマンドを打つだけです。
/ac-error-triage
起動すると、まず調査期間（昨日10:00〜現在／直近1週間／直近2週間／直近1カ月）、次に対象アプリ（appName）を順に聞かれるので、選ぶだけです。あとは調査 → Backlog 突き合わせ → 台帳更新 → レポートと進捗ダッシュボード生成まで進めてくれます。最後にブラウザで開けるリンクも出ます。
もちろん、最初から条件を添えて自然文で頼んでもOKです（その場合は対話の確認が省略されます）。
/ac-error-triage aircourse-app-name-01 の直近1週間のエラーを調べて、進捗ダッシュボードも更新して
まとめ
- New Relic と Backlog を連携し、「現在発生しているエラー」と「対応状況」を突き合わせられるようにした
- 本番リリース後も同じエラーが発生しているかを検知し、再発しているものを 🔴 で可視化した
- Claude Code のスキルで、調査・突き合わせ・調査レポート/進捗ダッシュボード生成までをまとめて自動化した
これまで1件ずつ手作業で行っていたエラー調査と対応状況の確認を、短時間で完了できるようになりました。
本記事が、New Relic や Backlog、Claude Code のスキルを使って、自分のチーム向けのエラー管理フローを作る際の参考になればうれしいです。
最後に
最後まで読んでくださり、ありがとうございました。
少しでもお力になれれば幸いです。
よろしければ、いいね・ストックの方もお願いします。
KIYOラーニング株式会社について
当社のビジョンは『世界一「学びやすく、分かりやすく、続けやすい」学習手段を提供する』ことです。革新的な教育サービスを作り成長させていく事で、オンライン教育分野でナンバーワンの存在となり、世界に展開していくことを目指しています。
プロダクト
- スタディング：「学びやすく・わかりやすく・続けやすい」オンライン資格対策講座
- スタディングキャリア：資格取得者の仕事探しやキャリア形成を支援する転職サービス
- AirCourse：受け放題の動画研修がついたeラーニングシステム（LMS）
KIYOラーニング株式会社では一緒に働く仲間を募集しています