9
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

New Relic AI Knowledge × Autopilot で「怪しいアクティビティ」を検知させてみた

9
Last updated at Posted at 2026-10-26

New Relic AI Knowledge 機能と Autopilot(旧 SRE Agent) を組み合わせると、単なるメトリクスの異常検知にとどまらず、「そのシステムにとって何が“正常”で何が“怪しい”のか」という 業務ドメインの文脈 をAIに持たせた上で分析させられます。

image.png

本記事では、PHP/Laravel 製のサンプルアプリに「ユーザーIDの正常基準」や「正規の外部通信先」といった知識を New Relic AI Knowledge として登録し、Autopilotにセキュリティ観点で怪しいアクティビティを分析させる検証を行った流れを紹介します。

⚠️ 本記事の「脆弱性を仕込む」「攻撃リクエストを送る」部分は、すべて自分のデモ環境に対する検知テストです。実際の攻撃には使用しないでください。


やりたかったこと

「脆弱性をついた攻撃を受けたとき、New Relic のデータから怪しいアクティビティを検出できないか?」というのが出発点でした。

そのためには、以下の2つの観点が重要です。

  1. 検知のための“手がかり”になるコンテキストを New Relic に送ること(APMカスタム属性・ログなど)
  2. 「何が正常で何が異常か」をAIが判断できる“基準”を与えること(AI Knowledge)

この2つを揃えて、Autopilot に「怪しいアクティビティはないか?」と聞いて検証しました。


全体の流れ

[PHPアプリ] --- APMカスタム属性 / ログ ---> [New Relic]
                                                  |
[AI Knowledge] --- 正常基準の知識 --------------> [Autopilot]
                                                  |
                                           「怪しいアクティビティは?」
                                                  |
                                            分析結果(異常の指摘)

補足:“手がかり”になるコンテキストを New Relic に送る重要性について

AI(Autopilot)による自律的な調査やセキュリティ観点の分析と聞くと、「AIが魔法のように原因を見つけてくれる」と思われがちですが、実際はそうではありません。
AIが的確な推論を行えるようにするために、APMやログからコンテキストを渡すことが重要です。

具体的には、APMを導入することで以下のようなデータが網羅的に収集されています。

  • トランザクション&エンドポイント情報:
    どのURIに、どのようなリクエスト(メソッド、パラメータ、HTTPステータスコード)が届き、どこでどれだけ時間がかかったか。
  • エラーと詳細なスタックトレース:
    フレームワークや言語レベルで捕捉された例外の詳細、発生箇所のクラスやメソッド、行番号。
  • 分散トレース(Distributed Tracing):
    マイクロサービス間の呼び出し連鎖、外部サードパーティAPIへのリクエスト、DBクエリの実行内容とレイテンシ。
  • コンテキスト付きログ(Logs in Context):
    トランザクションIDやTrace IDと紐づいたアプリケーションログ。
  • リクエストヘッダーやカスタム属性:
    認証情報に関わるヘッダーの有無やステータス、クライアントのユニークな属性(ユーザーID..etc)など。

Step 1. 検知の手がかりになるデータを仕込む

まず、アプリ側で「ユーザーの行動」を New Relic から追えるようにします。今回のサンプルアプリ(php-sample-app)には、以下の3つを追加しました。

  • APM のカスタム属性にユーザーIDを付与(Transaction の user_id)
  • ログインログの出力(ユーザーID を含む)
  • ログイン時に外部サービスへの通信(正規の連携先は www.google.com)

PHP(Laravel)の実装イメージはこんな形です。

// ログイン成功時
Log::info('User logged in', [
    'user_id'  => $userId,
    'username' => $username,
    'ip'       => $request->ip(),
]);

if (extension_loaded('newrelic')) {
    // APM のトランザクションにカスタム属性としてユーザーIDを付与
    newrelic_add_custom_parameter('user_id', $userId);
}

Step 2. 「正常の基準」を AI Knowledge に登録する

ここが今回の肝です。Autopilot に「このアプリにとっての正常」を教えるために、ナレッジドキュメントを作成しました。内容は以下のようなものです。

  • ユーザーID(user_id / context.user_id)は 必ず数字4桁(1000〜9999)である
  • ユーザーID は APM の Transaction カスタム属性 と ログの context 属性 の両方に付与されている
  • 4桁の数字以外の値(文字列・SQL断片・<script> など)が入っていたら、怪しいアクティビティの可能性
  • このアプリがログイン時に正規に通信する外部ドメインは www.google.com のみ

ドキュメントには、Autopilotが実際に検知へ使えるよう NRQL のサンプル も添えています。

-- 非4桁の user_id を含むログを検出
SELECT `context.user_id`, `context.username`, message, timestamp
FROM Log WHERE message = 'User logged in'
AND `context.user_id` NOT IN (1000, 1001, 1002, 1500, 9999)
SINCE 1 day ago

ナレッジのサンプルはこちらでご確認いただけます。

Step 3. 攻撃を模した異常アクティビティを発生させる

検知が機能するかを確かめるため、正常系と異常系の user_id を送るログイン試行スクリプトを用意しました(デモ環境専用)。

  • 正常系: 1001, 1002, 1500, 9999(いずれも4桁)
  • 異常系: 123(3桁), 12345(5桁), abcd(英字), 1001' OR '1'='1(SQLインジェクション), <script>alert(1)</script>(XSS), ../../etc/passwd(パストラバーサル) など

スクリプトを実行すると、New Relic の Log に正常系・異常系すべての値が記録されるようにしています。

SELECT count(*) FROM Log WHERE message = 'User logged in'
FACET `context.user_id` SINCE 10 minutes ago
context.user_id 分類
1001 / 1002 / 1500 / 9999 正常(4桁)
123 / 12345 / -100 異常(桁数・符号)
abcd / 12ab 異常(非数値)
1001' OR '1'='1 異常(SQLi 痕跡)
<script>alert(1)</script> 異常(XSS 痕跡)
../../etc/passwd 異常(パストラバーサル痕跡)

ナレッジに書いた検知NRQL(正常IDを除外する条件)でも、異常系だけをきれいに抽出できました。

Step 4. Autopilot に分析させる

データと知識が揃ったので、Autopilotに自然言語で聞いてみます。

「php-sample-app について、過去1時間でユーザーアクティビティに怪しいものがないか、ナレッジの正常基準に照らして分析して。」

Autopilot は AI Knowledge に登録した「ユーザーIDは数字4桁」「外部連携は www.google.com のみ」という基準を参照し、4桁以外の user_id や、SQLインジェクション・XSS を思わせる値が注入されているログイン試行 を怪しいアクティビティとして指摘してくれます。

ポイントは、「何が異常か」をAIが勝手に推測したのではなく、こちらが与えた業務ドメインの基準に基づいて判断している という点です。これにより、汎用的な異常検知では拾いにくい「このシステム固有のルール違反」を検出できます。

image.png
image.png
image.png


検証してわかったこと

  • データ(手がかり)と知識(基準)はセットで価値を生む。ログや属性を送るだけでも、正常基準を与えるだけでもなく、両方揃うと「このシステムにとっての異常」をAIが言語化できる
  • ナレッジに 属性名と NRQL の具体例 を書いておくと、Autopilot がそのまま検知クエリに使えて精度が上がる。

終わりに

New Relic AI Knowledge に「正常の定義」を教え込むことで、Autopilot は、システムの文脈を理解してセキュリティ観点の分析まで手伝ってくれるアシスタント に近づきます。

今回は「ユーザーIDは4桁」「外部連携は Google だけ」というシンプルな基準でしたが、同じ考え方で「このAPIは特定の国からしか呼ばれないはず」「この操作は管理者しか行わないはず」といった業務ルールを登録していけば、より実践的な不正検知にも応用できそうです。

New Relicでは、新しい機能やその活用方法について、QiitaやXで発信しています!
無料でアカウント作成も可能なのでぜひお試しください!


New Relic株式会社のX(旧Twitter) や Qiita Organizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。

無料のアカウントで試してみよう!
New Relic フリープランで始めるオブザーバビリティ!

9
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
9
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?