New Relicを使った運用・保守の現場では、「AskAI」を活用する機会が増えています。
自然言語で質問するだけで、関連するメトリクスやログ、NRQLを提示してくれる機能です。


とはいえ、実際の障害対応において、AskAIがどの程度まで有効かは十分に検証されていません。


そこで今回は、弊社サイト（iret.media）で発生した
「URL監視アラート」および「EKS Podのメモリ使用率100%」という実際の事例を題材に、
AskAIを利用してどこまで原因特定に近づけるかを検証しました。


結論として、AskAIは調査工程の一部を効率化できますが、
環境に依存する情報や時刻変換など、利用者側の補正が必要な部分も多いことが分かりました。

障害の概要


  • 発生日時: 2025年10月31日 0時〜5時 (JST)

  • 事象1: URL監視（Synthetics）のアラートが発報

  • 事象2: EKS上の特定Pod（wordpress-55b69f8df8-…）のメモリが100%に張り付いていた


この2つの事象の関連性を、AskAIを用いて調査しました。

AskAIによる調査プロセス

Step 1: アラートの把握（評価：⭕️ 成功）

人間が入力したプロンプト:


「日本時間 10月31日の0時から5時の間、iret.media に関連する異常やアラートはありましたか？クローズされたものについても教えてください」

AskAIが生成したNRQL:


FROM NrAiIncident SELECT * WHERE (entity.name LIKE ‘%iret.media%’ OR description LIKE ‘%iret.media%’) AND (event = ‘open’ OR event = ‘close’) SINCE ‘2025-10-31 00:00:00 +09:00’ UNTIL ‘2025-10-31 05:00:00 +09:00′


JST（+09:00）を含めて意図通りのアラート一覧を取得できました。
「どのアラートが発生していたか」を確認する初動としては十分な精度でした。

Step 2: EKSとの関連把握（評価：❌ 不十分）

人間が入力したプロンプト:


「URL監視アラートと同時刻帯（日本時間 10月31日0時〜5時）に、EKS環境でパフォーマンスの問題はありましたか？」

AskAIが生成したNRQL:


FROM K8sNodeSample SELECT average(cpuUsedCores), average(memoryUsedBytes) WHERE clusterName = ‘iret.media’ SINCE ‘2025-10-31 00:00:00 JST’ UNTIL ‘2025-10-31 05:00:00 JST'


PodレベルではなくNodeレベルを見ており、clusterNameも実際の環境と一致しませんでした。
この段階では、EKS上のどのリソースに問題があったのかまではたどり着けませんでした。

Step 3: メモリ高騰Podの特定（評価：🔺 難航しつつも最終的に成功）

人間が入力した最初のプロンプト:


「日本時間 10月31日0時から5時の間に、EKSでメモリ使用率が95%を超えていたPodを教えてください。」

AskAIが最初に生成したNRQL:


FROM K8sPodSample WHERE memoryUsagePercent > 95 AND clusterName = ‘EKS’ SINCE ‘2025-10-31 00:00:00 JST’ UNTIL ‘2025-10-31 05:00:00 JST'


ここから、AskAIに正しいクエリを書かせるために、以下のようなプロンプトを段階的に入力しました。


  • 試行1: 「clusterNameを指定しないでクエリを書いてください」

  • 試行2: 「memoryUsedBytes と memoryLimitBytes を使って、メモリ使用率をパーセントで計算してください」

  • 試行3: 「さきほどの計算式と、『10月31日0〜5時(JST)』をUTCに変換した時間を組み合わせてクエリを書いてください」

  • 試行4: 「年が2023年になっているので、2025年に修正してください」


AskAIは計算式やWHERE条件の一部は正しく作るものの、


  • 年を2023年に戻してしまう

  • JST→UTC変換を忘れる


といった問題が続いたため、最終的にはAskAIが出したクエリをベースに年のみ人間が2025年に修正して実行しました。

最終的に人間が実行したNRQL:


FROM K8sContainerSample SELECT max((memoryUsedBytes / memoryLimitBytes) * 100) WHERE (memoryUsedBytes / memoryLimitBytes) * 100 > 95 FACET podName SINCE ‘2025-10-30 15:00:00’ UNTIL ‘2025-10-30 20:00:00′


このクエリにより、メモリ使用率が95%以上となっていたPodとして、
wordpress-55b69f8df8-… が特定できました。

Step 4: コンテナの特定（評価：🔺 最終的に成功）

人間が入力したプロンプト:


「Pod名が wordpress-55b69f8df8 で始まるPodについて、必ず2025年のデータを見てください。2025年10月31日の日本時間0時から5時の間に、最もメモリを消費していたコンテナ名（containerName）は何ですか？」

AskAIが生成したNRQL:


FROM K8sContainerSample SELECT latest(memoryUsedBytes) WHERE podName LIKE ‘wordpress-55b69f8df8%’ SINCE ‘2025-10-31 00:00:00’ UNTIL ‘2025-10-31 05:00:00’ FACET containerName, processDisplayName LIMIT 1


JST→UTC変換はされていないものの、このクエリを実行することで、
対象のコンテナが wordpress であることを確認できました。

Step 5: ログ調査（評価：⭕️ 成功）

人間が入力したプロンプト:


「2025年10月31日の日本時間0時から5時の間（UTCでは 2025-10-30 15:00〜20:00）のログを調べてください。wordpress コンテナで Error や Exception、OutOfMemory に関連するメッセージはありますか？」

AskAIが生成したNRQL:


FROM Log SELECT * WHERE podName LIKE ‘wordpress-55b69f8df8%’ AND containerName = ‘wordpress’ AND (message LIKE ‘%Error%’ OR message LIKE ‘%Exception%’ OR message LIKE ‘%OutOfMemory%’) SINCE ‘2025-10-30 15:00:00’ UNTIL ‘2025-10-30 20:00:00′


UTC時間をプロンプト内で明示したことで、年月日・時間とも意図通りのクエリが生成されました。
ただし、該当時間帯にError/OOM系のログは残っておらず、結果は「No logs found」となりました。

Step 6〜7: 相関分析と原因推定（評価：❌失敗）

人間が入力したプロンプト:


「これまでの結果（URL監視アラート、Podのメモリ100%、ログにError/OOMがないこと）を踏まえて、wordpress コンテナのCPU使用率・ネットワークトラフィック・リクエスト数に急激な変化があったか確認したいです。2025年10月31日の日本時間0〜5時（UTC 2025-10-30 15:00〜20:00）で、関連しそうな変化があれば教えてください。」

AskAIが生成したNRQL（イメージ）:


FROM K8sContainerSample SELECT average(cpuUsedCores) … WHERE containerName = ‘wordpress’ AND podName = ‘wordpress-55b69f8df8’ SINCE ‘2025-10-31 00:00:00 JST’ UNTIL ‘2025-10-31 05:00:00 JST'


ここでは再び、JST→UTC変換が行われていない、podNameが完全一致指定になっている、などの問題があり、
AskAIが生成したクエリだけでは有効なデータを取得できませんでした。


そのため、AskAIが「CPUやネットワークを見るべき」という方向性だけをヒントとして受け取り、
最終的なクエリは人間側で次のように修正して実行しました。

人間が最終的に実行したNRQL:


FROM K8sContainerSample SELECT average(cpuUsedCores), average(receiveBytesPerSecond), average(transmitBytesPerSecond) WHERE containerName = ‘wordpress’ AND podName LIKE ‘wordpress-55b69f8df8%’ SINCE ‘2025-10-30 15:00:00’ UNTIL ‘2025-10-30 20:00:00’ TIMESERIES


このクエリの結果、以下の点を確認できました。


これにより、「深夜帯にwordpressコンテナ内で高負荷処理が走り、その後メモリが枯渇した」という流れが見えてきました。

AskAIの特徴

適している場面


  • NRQL構文の叩き台や計算式の生成

  • アラートやメトリクスの初期確認

  • 時間や条件を明示したうえでのクエリ生成

検証結果

今回の徹底検証でわかった、New Relic AskAIが「得意」と「苦手」をまとめます。

⭕️ 得意なこと

  • クエリの作成: (memoryUsedBytes / memoryLimitBytes) * 100 のような計算式や、LIKE句、FACET句を使ったクエリの叩き台を瞬時に生成します。
  • 明確な指示の実行: 「（ヒント: UTC …）」のように、具体的に時間をプロンプトに含める必要があります（Step 5）。
  • 初動調査: アラートの確認（Step 1）は非常にスムーズでした。

❌ 苦手なこと

  • 文脈の維持（特に時間）: 会話が長くなると、「年（2025年）」と「JST→UTC変換」を繰り返し忘れます。これが最大の課題であり、利用者が最も注意すべき点です。
  • 環境の自動認識: clusterName や podName のサフィックス（-xxxxx）など、こちらの環境の「暗黙の前提」を自動で認識することはできません。
  • 推論の精度: 調査の最終ステップ（Step 7）で、集めた情報を元に「推論」させるのは、クエリの精度が低いためまだ難しいようです。

まとめ：AskAIの活用方法

今回の検証で、New Relic AskAIは、エンジニアの作業を強力にサポートする「賢いアシスタント（Copilot）」であることが分かりました。

AskAIに障害調査をすべてお任せするのではなく、

「人間がAskAIにクエリを作らせ、人間がそれをレビュー・修正して実行し、次のステップをAskAIに依頼する」

という流れこそが、障害調査の効率を最大化する鍵となりそうです。

AskAIのクセを理解し、特に時間指定（UTC）を人間がサポートしてあげることで、障害の原因（今回のCPUスパイク）」にたどり着くまでの時間を大幅に短縮できる可能性があるが、現時点では最終的な原因特定やAPMの読み解きは、
依然として人間側の判断が重要であることが確認できました。

あとがき

今回のURL監視アラートが発砲した原因について、APMを使って調査しました。


  • URL監視アラート: Podの応答遅延（タイムアウト）が直接原因

  • 応答遅延の原因: Podがメモリ100%に張り付き、リクエスト処理が極端に遅延していた

  • メモリ100%に至った要因: homeトランザクション（WordPressトップページ）の処理が他ページと比べて異常に重かった


APMの slowest transactions を確認すると、home の平均実行時間は約40秒となっており、
他のページ（5〜7秒程度）と比較して明らかに突出していました。


さらに、home トランザクションの内訳を見ると、処理時間の約88%が PHP アプリケーション本体に集中しており、
DBクエリや外部API呼び出しがボトルネックではないことも分かりました。


最終的な流れは、次のように整理できます。


  • WordPressトップページ（home）の内部処理が深夜帯に高負荷状態になる

  • その影響でPod内のメモリが枯渇し、リクエスト処理が極端に遅延

  • 外形監視（Synthetics）がタイムアウトを検知し、URL監視アラートが発報

以上のことから、今回のアラートの原因はアプリケーションの処理に起因するものであることがわかりました。

次回の記事では、APMのデータをさらに深掘りし、アプリケーションのどの処理がボトルネックとなっていたのか、被疑箇所の特定に挑戦します。
ご期待ください。

最後まで読んでいただきありがとうございました。この記事が、皆さんのNew Relic運用保守の参考になれば幸いです。