こんにちは、開発チームの木村です
この記事はAI Shift Advent Calendar 2025の10日目の記事です。
はじめに
バックエンドでエラーが発生したとき、どのように原因調査をしていますか？
ログを見て、コードを追って、DBのデータを確認して...、複数のツールを行き来しながら調査を進めるのではないかと思います。
私は普段からコーディングにはCursorを愛用しており、コーディング時にテーブル定義を参照させたいため、CursorがDBを参照できるような.cursor/rulesを設定していました。この仕組みを拡張すれば、バックエンドのエラー調査にも使えるのではないかと考えました。
いろいろ試行錯誤した結果ある程度使えるようになったので本記事では、その設定方法と実際の使い方を紹介したいと思います。
ゴール
例えば「先ほど起こったprod環境のAPIサーバのエラーについて原因を調査してください」といったプロンプトだけで、ログ、ソースコード、DBのデータを横断的に調査して原因を特定し、結果を報告してもらうことを目指します。
実行例
Cursorのプロンプトでエラーが発生した時間（RequestID的なものでも可）を指定して、エラー調査をしてもらいます。Cursorは最初にログを見に行き、該当のエラーを確認。必要に応じてDBのデータやソースコードを調査します。
プロンプトの例
Cursorによる調査過程
アプリケーションログ調査
Cursorがdateコマンドで現在時刻の確認から始めています。
ここは少し時間がかかりますが、Cursorがgcloud loggingコマンドを発行しています。ソースコードも参照してログを出力している箇所と照らし合わせて調査してくれます。
gcloudの認証が切れている場合は、Cursorが勝手にgcloud auth loginを発行してブラウザの認証ページが開きログインが求められます。「AIの要求で人間が許可を出す」という近い未来の形を垣間見た気がします。
DB調査
必要に応じてCursorがDB検索をします。
ソースコードの調査
Cursorなのでデフォルト機能として必要に応じてソースコードも調査します。
調査結果
最後にCursorの調査結果がまとめられます。有識者が調査時間をかけて得られるようなズバリな回答することもあれば、見当違いな回答をすることもあります。ただ、回答結果に対して人がさらに指示をして複数ターンやり取りすればそれなりの精度で原因調査をしてくれます。エラーの原因調査に集中して時間が取れないミーティング続きのプレイングマネージャにも最適な方法といえます。
設定の仕方
mdcファイルとしてCursorに使えるツールとして情報提供することで実現します。
Cursorのmdcファイルとは
mdc（Markdown with Configuration）ファイルは、Cursorのワークスペース固有のルールやコンテキストを定義するためのファイルです。.cursor/rules/ディレクトリに配置され、AIアシスタントがコード生成や質問応答を行う際の参照情報として機能します。
詳細については公式ページをご覧ください。
今回はログの取得方法とDB検索方法をそれぞれ記述しておきます。このmdcファイルはまずdescriptionがLLMに送られ、必要であれば本文が参照される仕組みのため、descriptionはLLMが必要性を判断するのに十分な情報を簡潔に書き、本文は長文になってもいいので詳しく書きます。
MCPでも同じことができると思いますが、この方法はCursorの標準機能のみでシンプルに設定できる点がメリットです。
ログ取得方法
.cursor/rulesの下に任意の名前でxxxx.mdcとしてファイルを作成します。今回の例ではGCP環境でCloud Loggingを使用している前提です。
---
description: Kubernetesのログを取得するgcloudコマンド集
globs:
alwaysApply: false
---
# dev環境
## 基本ルール
ログを取得する場合は始めにdateコマンドで現在時刻を確認してください。
## 基本的なログ取得
gcloud logging read 'resource.type="k8s_container" AND resource.labels.project_id="xxxx" AND resource.labels.location="xxxx" AND resource.labels.cluster_name="xxxx" AND resource.labels.namespace_name="xxxx" AND labels."k8s-pod/app"="xxxx" AND labels."k8s-pod/env"="xxxx" AND severity>=DEFAULT' --limit=50
サンプルコマンドを書いておくと、LLMが条件をよしなに追加したり変更したりしてくれます。
LLMは現在時刻を知らないのでdateコマンドで確認する指示を入れています。実際にCursorがコマンドを発行する場合は時間に沿って以下のような条件を勝手に加えてくれます。
timestamp>="2025-12-05T06:50:00Z" AND timestamp<="2025-12-05T07:00:00Z"
healthチェックのログが多く出ている場合は人と同じようにLLMにとっても見にくいログになってしまうので、サンプルコマンドの条件で除外しておくと検索の速度と精度が上がります。
複数のアプリケーションがある場合はk8s-pod/appの種類をこのファイルで記述しておくとよいです。
例：
k8s-pod/appの種類
- app-api : ユーザー向けアプリケーションのAPI
- admin-api : 管理画面のAPI
冒頭のプロンプトのようにエラーを調査する指示をした場合は、Cursorが勝手にseverity>=ERRORの条件をつけてくれたりもします。
DB検索方法
上記とは別のmdcファイルとして作成します。今回の例ではMySQLに接続しています。mysqlコマンドを直に叩いてもいいですが、インストール可否やバージョンに左右されないメリットを重視してDocker経由にしています。
---
description: DBに接続してDDLやデータの確認が必要なときは以下のコマンドを参考に接続してください。
globs:
alwaysApply: false
---
## 基本コマンド
docker run --rm mysql:8.0 mysql -u {DB_USER} -p{DB_PASS} -h {DB_HOST} -P 3306 {DB_NAME} -e "SHOW TABLES;"
## dev
DB_HOST=xxxx
DB_USER=xxxx
DB_PASS=xxxx
DB_NAME=xxxx
...
TIPS
権限に注意
DBでは指示によってはデータの変更ができてしまうため、SELECTのみが許可されたユーザを作成して使いましょう。
ログの参照について、今回のgcloudコマンドの例では自分と同じ権限で実行することになるため、普段から必要以上の権限はつけない、必要な場合にのみ権限を付与するなどの運用が重要になります。
各モデルの所感と使い分け
私は普段はClaude SonnetをMAXモードで使っています。完全にLLMだけで解決することはまだ難しいと思っているため、そこそこの賢さに加えて応答の早さから、複数ターンやり取りしながら解決する場合に向いています。
ただし、ミーティング中など指示を投げっぱなしで後から確認する場合は、応答速度が遅くても賢いモデルを使ったりと使い分けています。
Claude OpusはSonnetとあまり変わらない応答速度でさらに一段階賢い印象ですが、コストが高いのが特徴です。すぐにCursorのUsage枠を使い切ってしまうのでここぞという時に使っています。
GPT-5 Codexはまだそれほど使い込んでいませんが、Claude Opusに近い賢さで応答速度もそこまで遅くなく、Claude Opusほどコストはかからないというバランスになっていて最近注目しています。
ちなみにここまで書いた所感はエラー調査時の話ですが、コーディング時も同じで、さらにコーディング時は応答速度を重視して選んでいます。
今後の展望
現状は アラート検知→人→Cursorに調査を依頼 という流れですが、今後は以下のような自動化を検討しています。
- エラーログの自動検知をトリガーにして、Cursorやその他のAIエージェントが自動で調査を開始する
- 調査結果をSlackに通知し、人間が確認・判断するフローを構築する
- 軽微なエラーについては修正PRの自動作成まで行う
エラー発生から調査開始までのリードタイムをゼロに近づけることで、障害対応の初動を大幅に短縮できると考えています。
ただ、3つ目についてはまだ手放しでLLMに任せられる状態ではないのでその理由とともに別の機会に考察できればと思います。
まとめ
Cursorの.mdcファイルにログ取得コマンドとDB接続コマンドを記述しておくことで、エラー調査を大幅に効率化できます。ポイントは以下の3点です。
- descriptionにはLLMが必要性を判断できる情報を簡潔に書く
- 本文には具体的なコマンドと環境ごとの設定を詳しく書く
- 権限管理を徹底し、SELECT専用ユーザの作成や最小権限の原則を守る
完全自動化にはまだ課題がありますが、「プロンプトだけでログ・DB・コードを横断調査」できるだけでも、エラー調査の負担は大きく軽減されます。ぜひ試してみてください。
採用情報
AI Shiftではエンジニアの採用に力を入れています！
少しでも興味を持っていただけましたら、カジュアル面談でお話しませんか？
（オンライン・19時以降の面談も可能です！）
【面談フォームはこちら】
Discussion