ログ確認コマンド、改善４回で育ちきる

こんにちは、鈴木です。

とある Web システムのログを日次で確認する機会がありました。まだ PoC 段階のため SLO の設定やエラー検知の仕組みは作り込んでいない状態ですが、問題の予兆を積極的に見つけたいという事情があったためです。

この記事は、対応要否の判断基準を言語化するのは億劫だと思いつつも、Cursor Command にしてみたら改善を4回繰り返すだけで育ちきりました、という話です。意外と楽にできたので、同じように「言語化しないとねぇ・・」と思っている方の後押しになれば嬉しいです。

まずはログを目視確認

アプリケーションのログは New Relic に転送するようにしていました。

まずは New Relic の画面を開き、ログを絞り込み、HTTP ステータスコードが 400 番台と 500 番台のものを確認します。調査が必要と判断したものは NRQL（New Relic Query Language）でクエリを書いて関連するログを確認していきます。

当たり前ですが、結構手間だと感じました。

ちょうど New Relic が MCP サーバを提供していることを知ったので、使ってみることにしました。

New Relic MCP を使うことで変わったこと

Cursor に New Relic MCP をセットアップすると、自然言語でログを問い合わせられるようになりました。「直近のエラーログを確認して」と打つだけで、New Relic MCP 経由でログを取得して整理してくれます。

目視でやっていたことが一気に楽になりました。具体的には2点です。

  • NRQL を自分で書かなくて良くなった：「400番台・500番台を確認して」と伝えるだけでクエリを生成して実行してくれます
  • 複数のログをまとめて判断できるようになった：「頻発していなければ問題なし」のような、複数のログを見て判断する作業を AI に任せられるようになりました

さらに「要対応 / 人間判断が必要 / 対応不要」の基準を伝えた上で分類して表示するように指示しました。自分が見るべきものが絞られるので、確認にかかる時間と認知負荷が大きく下がりました。

Cursor Command にして育てた

「要対応 / 人間判断が必要 / 対応不要」の基準を毎回書くのは大変なので、/check-newrelic-logs という名前の Cursor Command を作成しました。

New Relic の Logs を取得・分析し、以下を報告して。

 * 全体の傾向（「要対応のログ」や「要対応であるか判断が必要なログ」の傾向を記載する）
 * 要対応のログ
 * 要対応であるか判断が必要なログ（**該当件数も併せて報告する**こと）

# 目的

対応が必要なシステムの問題を検知すること。
ログ設計に対する改善指摘（例: ログレベルが適切ではない）はおこなわない。

# ログの取得条件

指示がない場合は以下を条件とする。

 * アカウント: 〇〇
 * 期間: JST で昨日の 9:00 以降
 * 条件: level が INFO 以外

# 対応可否の判断方法

取得したログを以下のルールに **上から順に** 照合し、最初にマッチしたルールで分類する。
どのルールにもマッチしないログは「要対応であるか判断が必要なログ」として報告する。

## 対応不要と判断して良いログ

 * NestJS の起動時のログ
 * 〇〇欠如エラー
 * 〇〇警告

## 数が少なければ対応不要と判断して良いログ

 * 〇〇関連
 * 〇〇関連
 * 〇〇関連
 * 〇〇関連
 * 〇〇関連
 * React / フロントエンド警告

コマンドを実行 → 人間が確認が必要なログだけ確認する → 対応不要と判断したものはコマンドに反映、という改善サイクルを繰り返しました。その回数は4回。初版作成から8日で育ちきりました。

  • 1回目：「やらないこと」を明示（ログ設計への改善指摘はしない）→ AI がスコープ外の報告をしなくなった。フィルタ3件追加
  • 2回目：新たに発見した対応不要ログのフィルタを追加
  • 3回目：ルールが10件を超えたためカテゴリ構造に整理 → AI の適用精度が回復。「要判断ログは件数も報告する」指示を追加
  • 4回目：〇〇関連のバリデーションエラーを対応不要リストに追加

おわりに

「属人化はよくない、言語化しましょう」とはよく言われます。まあそうなんですけど、実際に言語化するのは大変な気がしますよね。重い腰が上がらない。

それでも実際にやってみると、ざっくり書き出してから改善サイクルを4回まわすだけ。改善するたびにどんどん楽になっていきました。何もしなければ属人化した作業が一つ増えるところでした。

今回はログ確認の話でしたが、同じアプローチが使えることは他にもあるはずです。この記事を読んで「ちょっとやってみようかな」と思ってもらえたら嬉しいです。

弥生では一緒に働く仲間を募集しています。
www.yayoi-kk.co.jp

弥生のエンジニアに関する note 記事もご覧ください。
note.yayoi-kk.co.jp


弥生エンジニアの公式Xのフォローもよろしくお願いします！