この蚘事の芁玄

  • 課題: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技術を積極的に掻甚し、運甚の高床化に取り組んでいたす。
もしシステム監芖やトラブルシュヌティングでお悩みなら、ぜひ私たちにご盞談ください。

最埌たで読んでいただきありがずうございたした。この蚘事が、皆さんのシステム運甚のヒントになれば幞いです。