この記事の要約

  • 課題:ALBヘルスチェックエラー（UnHealthyHostCount）の原因調査。
  • 手法: New Relic MCP x Gemini CLI を使い、AIと対話しながらログとメトリクスを深掘り。
  • 結果: 標準AI機能では特定できなかった「Bot攻撃による大量404エラー」という真因を数分で特定完了。

はじめに

運用担当者の皆さん、夜間のアラート対応で「原因がすぐにわからない」という経験はありませんか？
「CPU負荷かな？」「メモリ不足？」と推測でコンソールやログを行ったり来たりしながら調査を進めるのは、時間も精神力も消耗しますよね。

今回、自社サイト（www.iret.co.jp）で発生したロードバランサーのヘルスチェックエラーについて、「New Relic MCP x Gemini」 というAIアシスタントを活用して調査を行いました。

その結果、人間がログを漁るよりも圧倒的に早く、かつNew Relic標準のAI機能でも検知できなかった原因を特定することに成功しました。

この記事では、実際のAIとの対話プロセスと、手動検証による裏付け、さらに標準機能との比較検証を交えながら、どのようにして複雑なパフォーマンス低下の原因を突き止めたのかをご紹介します。

UnHealthyHostCountの検知

www.iret.co.jp を監視しているNew RelicからUnHealthyHostCountアラートが通知されました。

通常、ここからNew Relicの管理画面を開き、グラフを重ね合わせ、ログを確認する…という原因調査が始まります。

しかし今回は、New Relic MCP（Model Context Protocol）を組み込んだGemini CLIに調査を依頼しました。

リソース不足を疑う（AIによる一次切り分け）

まず最初に、AIに対してシンプルに調査を依頼しました。

私: Account ID: xxxxxxx のwww.iret.co.jp で発生したアラートの原因を調査してください。

AI:

承知いたしました。www.iret.co.jp で発生したアラートの原因を調査します。

www.iret.co.jp に関連するアラートは1種類あります。

1. UnHealthyHostCount アラート (ホスト異常検知)

原因を報告します。

1. UnHealthyHostCount アラートの原因

  • 直接原因: UnHealthyHostCount (異常なホストの数) のメトリクスが 0 を超えたこと。

  • 発生日時: 2026年1月16日 午前2時50分ごろから午前6時10分ごろにかけて、断続的に発生。

この根本原因を特定するためには、異常と判定された時間帯のEC2インスタンス (prd-xxxxxx)

の状態を確認する必要があります。例えば、CPU使用率の急増やメモリ不足、アプリケーション自体のエラーなどが考えられます。

もしよろしければ、この時間帯のEC2インスタンスのCPUおよびメモリ使用率を調査しますが、いかがでしょうか？

発生したアラートの種類と発生時時刻を正確に特定することができました。
また過去の事例から推測される一般的な原因として「CPU使用率の急増」や「メモリ不足」の可能性を提示し、調査を提案してくれました。

CPU・メモリは正常だった

AIがEC2インスタンスのCPUおよびメモリ使用率を調査を提案してくれたので、調査してもらいましょう。

私:該当時間帯のEC2インスタンスのCPUおよびメモリ使用率を調査してください。

AI: 承知いたしました。prd-iretcorp EC2インスタンスの、2026年1月16日 午前2時45分から午前6時30分 までのCPUおよびメモリ使用率を調査します。

EC2インスタンスのCPUおよびメモリ使用率 (2026年1月16日 02:45 – 06:30 JST)

時間帯 (JST)  平均CPU使用率 平均メモリ使用率 UnHealthyHostCount (参考)
02:45 – 03:00 12.51% 36.78% 0.3
03:00 – 03:15 19.54% 30.93% 1.0
03:15 – 03:30 6.83% 32.19% 0.2
… … … …
05:00 – 05:15 13.61%% 36.06% 0.2
… … … …
06:00 – 06:15 14.06% 34.90% 0.3

 

所感:
CPU使用率:
UnHealthyHostCount が 1.0を記録した午前3時ごろに、CPU使用率が約20%に上昇しているピークが見られます。
しかし、これは一般的に高負荷とは言えず、通常であればインスタンスが異常になるほどのレベルではありません。
他の UnHealthyHostCount の上昇時（例: 05:05、05:10、06:05）には、CPU使用率は比較的低い状態でした。

メモリ使用率:
メモリ使用率は期間を通じて30%〜37%程度で安定しており、リソース不足の兆候は見られません。

結論:
EC2インスタンスのCPUおよびメモリ使用率のデータを見る限り、リソース枯渇（CPU飽和やメモリ不足）が直接の原因となってホストが異常になったという強い証拠は見つかりませんでした。

このことから、異常なホスト発生の要因として、以下の可能性が考えられます。

  1. アプリケーション固有の問題:
    EC2インスタンス上で動作しているアプリケーションが、リソース使用率が高くないにも関わらず、特定のタイミングでエラーを起こしたり、応答不能になったりした可能性が
    あります。
  2. ネットワークの問題: ロードバランサーのヘルスチェックが、一時的なネットワーク障害によってインスタンスに到達できなかった可能性があります
  3.  ロードバランサーのヘルスチェック設定: ヘルスチェックの閾値が厳しすぎるか、アプリケーションが特定の状況下でヘルスチェックへの応答が遅延した可能性があります。

次の調査ステップ:
根本原因をさらに深掘りするためには、以下の情報が必要になります。

  • 当該時間帯のEC2インスタンスのアプリケーションログ:
    • 異常なホストが検知された時間帯に、アプリケーション側で何らかのエラーや異常な挙動が記録されていないか確認する必要があります。
  • ロードバランサーのアクセスログ:
    • ヘルスチェックが失敗した理由（タイムアウトや不正な応答など）の詳細が記録されている可能性があります。
  • New Relic APMデータ:
    • もしAPMがEC2インスタンス上で動作していれば、トランザクションエラー、応答時間、特定アプリケーションメトリクスなどの詳細な情報が原因特定に役立つ可能性があります

これらの情報があれば、より詳細な原因特定に進むことができます。

AIからの回答は正確であり、人間が見やすいように表まで作成してくれました。
インフラリソースに問題がないことがわかると、「アプリケーション側やネットワーク、AWS側の設定が問題では？」と仮説を立ててくれました。
その後、さらに深ぼった調査をするために確認するべき情報を提示まで行なってくれました。

これにより、わずか2回のやり取りで「インフラのリソース不足ではない」ことが確定しました。

APM観点から調査

リソースに余裕があるのに、なぜヘルスチェックに落ちるのか？
AIは次の可能性として「アプリケーション固有の問題」を示唆しました。

そこで、New Relic APM（Application Performance Monitoring）のデータを深掘りするよう指示しました。

私: New Relic APMデータから原因の特定を試みてください。

AI:

承知いたしました。New Relic APMのデータを用いて、prd-iretcorp アプリケーションの調査を行います。
UnHealthyHostCount が上昇した時間帯 (2026-01-16 02:45:00 から 06:30:00 JST) において、以下の4つの観点からアプリケーションの挙動を確認します。

  • トランザクションエラー数: エラーが急増していなかったか。
  • 平均応答時間: レスポンスが極端に遅くなっていなかったか。
  • スループット: リクエスト数が急激に増減していなかったか。
  • 遅いトランザクション: 特に時間がかかっていた処理は何か。

これらの情報を一括で取得し、分析します。

APMデータ分析 (2026年1月16日 02:45 – 06:30 JST)

時間帯 (JST) 平均応答時間 スループット エラー数 UnHealthyHostCount(参考)
02:45 – 03:00 1.68s 1.947 1 0.3
03:00 – 03:15 1.85s 2.658 2 1.0
03:15 – 03:30 0.23s 602 0 0.2
… … … … …
04:15 – 04:30 0.44s 2.486 9 0
… … … … …
05:00 – 05:15 1.58s 1.769 1 0.2
… … … … …
06:00 – 06:15 1.55s 1.890 1 0.3

 

分析結果:

  1. 応答時間の悪化とスループットの急増が相関:
    UnHealthyHostCount が上昇した時間帯（例:午前3:00、5:00、6:00）は、いずれもスループット（リクエスト数）が急増し、それに伴い平均応答時間が1.5秒〜1.8秒へと大幅に悪化しています。
  2. エラーの発生:
    応答時間が悪化している時間帯には、少数ですがトランザクションエラーも発生しています。

結論:
APMのデータは、「断続的なアクセスの急増（スループットのスパイク）にアプリケーションが対応しきれず、応答時間が大幅に悪化した。

その結果、ロードバランサーのヘルスチェックに応答できなくなり（タイムアウトなど）、Unhealthyと判定された」というシナリオを強く示唆しています。

EC2インスタンス自体のCPUやメモリは限界に達していませんでしたが、アプリケーションレベルでのパフォーマンス低下が根本原因である可能性が非常に高いです。

最後に、具体的にどの処理が応答時間を悪化させていたのかを特定するため、この時間帯で最も遅かったトランザクショントップ10を調査します。（先ほどのクエリがエラーとなったため、修正して再実行します。）

✦ 最後に、応答時間を悪化させていたトランザクションの調査結果です。

遅延が大きかったトランザクション Top 10

トランザクション名 平均応答時間(s) 呼び出し回数
WebTransaction/Action/.temp 3.52 20
WebTransaction/Action/404 2.18 5,851
WebTransaction/Action/archive 1.65 10
WebTransaction/Action/index 1.57 54
WebTransaction/Action/template 0.9 15
WebTransaction/Action/front-page 0.88 19
WebTransaction/Action/test.php 0.66 2
WebTransaction/Action/sample.php 0.51 2

原因：
大量の404エラー（ページが見つかりません）へのアクセスが、アプリケーション全体のパフォーマンスを極端に低下させたため。

詳細：
調査した時間帯に、存在しないページへのアクセス (404) が 5,851回も発生していました。

WordPressでは、ページが存在しないことを判断して404ページを生成するのにも一定の処理負荷がかかります。

この大量の404アクセスがアプリケーションの応答時間を全体的に引き上げ（平均2.18秒）、結果、アプリケーションがロードバランサーのヘルスチェックに時間内に応答できなくなりました。

これが、EC2インスタンスがUnhealthyと判定された直接の引き金です。

推奨されるアクション

  • 404エラーの発生源を特定する:
    • ウェブサーバーのアクセスログを分析し、どのURLへのアクセスが404エラーを引き起こしているのか、またリクエスト元のIPアドレスはどこかを特定すべきです。
    • 外部サイトからのリンク切れ、あるいは悪意のあるボットによるスキャン活動の可能性があります。
  • 隠しファイル へのアクセスをブロックする。
    • ウェブ経由で 隠しファイル（.tempなど）に直接アクセスされるべきではありません。
      ウェブサーバーの設定で、このファイルへの直接アクセスを禁止することを強く推奨します。

以上で、UnHealthyHostCount アラートに関する一連の調査を完了します。

AIが出してきた分析結果はUnHealthyHostCountアラートの原因の確信をつくものでした。

  • 応答時間の悪化: 通常0.2秒程度の応答時間が、アラート発生時に1.5秒〜1.8秒へ大幅に悪化。
  • スループットの急増: リクエスト数が通常時の数倍にスパイクしている。

つまり、「5,851回もの404アクセスが短時間に集中したことでアプリの応答が遅れ、ロードバランサーのヘルスチェック（タイムアウト設定）に間に合わなくなった」という原因が浮かび上がってきました。

手動でアラートの原因を特定

AIが出してくれた仮説が本当にあっているのか、実際にEC2内部のログを確認してみます。

まずはNGINXのエラーログを見てみましょう。

該当時刻付近に以下のエラーログが頻発していました。

2026/01/16 xx:xx:xx [alert] … 1024 worker_connections are not enough while connecting to upstream …

これは、Nginxが処理できる最大同時接続数を使い切ってしまった ことを意味します。
これにより、新しい接続（ALBからのヘルスチェックを含む）を受け入れられなくなり、タイムアウト＝Unhealthyと判定されました。

では次にアクセスログを確認して、webサーバーへのアクセスを確認してみます。

172.30.10.52 – – [16/Jan/2026:xx:xx:xx +0900] “GET /xxx/.xxx/config HTTP/1.1” 404 548 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36” “84.247.xxx.xxx”

IPアドレス[84.247.xxx.xxx]から、隠しファイルに向けてアクセスがあり、404エラーを返しているアクセスログが大量に発生していました。

送信元IPアドレスをAbuseIPでチェックしたところ、悪意のあるbotによる脆弱性スキャンである可能性が非常に高いことがわかりました。

つまり今回のアラートの原因はAIの仮説通り

隠しファイルを標的とした大量の脆弱性スキャンを受けた → Nginxの同時接続数オーバー → サーバーが過負荷になりヘルスチェックへの応答がタイムオーバー → UnHealthHostCountアラート発生

であることがわかりました。

New Relic AIとの比較

ここまで読んで、「それ、New Relicの画面についているAI（New Relic AI）でも分かったんじゃないの？」と疑問に思った方もいるでしょう。

そこで、公平を期すために全く同じプロンプトをNew Relic標準のAIアシスタントにも投げて、回答を比較してみました。

Q. 「www.iret.co.jp で発生したアラートの原因を調査してください」

🤖 New Relic AI の回答（標準機能）

AIは以下のようなNRQLクエリを生成しました。

FROM NrAiIncident SELECT * WHERE targetName = ‘www.iret.co.jp’ SINCE 2 weeks ago

結果：No chart data available（データなし）

「インシデントテーブルを検索する」という動作は行いましたが、具体的な原因分析や、関連するメトリクス（CPUやAPM）の自動調査までは行われませんでした。

✨ Gemini CLI + MCP の回答（今回）

一方、Gemini CLIは以下のように思考を巡らせました。

  1. 「UnHealthyHostCountのアラートだね」と認識
  2. 「まずはCPUとメモリを見てみよう」→ 異常なし
  3. 「じゃあAPMでエラー率と応答時間を見よう」→ 応答遅延を発見
  4. 「どの処理が重い？」→ 404エラーが原因と特定

New Relic MCPとNew Relic AIの比較

この結果から、両者の決定的な違いがわかりました。

  • 標準のNew Relic AI：

    「テキストをNRQLに変換するツール」として動作します。

    ユーザーが「APMの404エラーの回数を出して」と具体的に指示すれば答えられますが、漠然とした「原因調査」という依頼に対して、自律的に仮説検証を行うことは苦手なようです。

  • Gemini CLI (MCP)：

    「調査エージェント」として動作します。
    AIが自ら「次は何を調べるべきか」を判断し、コマンド（ツール）を実行して情報を集め、答えに辿り着くまで深掘りしてくれます。

「どう書けばいいか分からないクエリ」を教えてもらうなら標準AI、「何が起きているか分からないトラブル」を相談するならMCP、という使い分けが両者の違いでした。

まとめ：New Relic x Geminiの威力

今回の調査にかかった時間は、実質数分です。
「アラートだ！CPUか？」→「違う」→「APM見よう」→「404が大量に来てる！」という流れを、AIが半自動的に完結できました。

今回の教訓：

  • New RelicのデータとMCPを組み合わせると、トラブルシューティングは劇的に早くなる。
  • New Relic上の様々な情報を紐づけて調査が可能
  • APMやログなどの情報をNew Relicに出力することでより練度の高い調査が可能

アイレットでは、こうした最新のオブザーバビリティツールやAI技術を積極的に活用し、運用の高度化に取り組んでいます。
もしシステム監視やトラブルシューティングでお悩みなら、ぜひ私たちにご相談ください。

最後まで読んでいただきありがとうございました。この記事が、皆さんのシステム運用のヒントになれば幸いです。