New Relic Security RXの新機能「Security RX Agent」がパブリックプレビューになったので試してみました。Security RXが見つけた脆弱性をAIが分析し、修正計画入りのGitHub Issueを作成。そこからコーディングエージェント（今回はClaude）がPull Requestを作るところまで、画面のクリックだけでつながります。

Security RX Agentは2026年10月時点でパブリックプレビューです。仕様や画面は今後変わる可能性があります。ご利用いただくには、New RelicのアカウントIDを担当の営業までご連絡いただく必要があります。アカウントごとにプレビューを有効化します。

また、Security RX AgentそのものはPublic Previewですが、Security RX App/Infra使うにはAdvanced Computeのご契約が必要になります。

Security RX Agentとは

Security RXは、アプリケーションが実際に読み込んでいるライブラリから脆弱性を見つけて、重要度ごとに一覧で見せてくれる機能です。自分も普段から使っていますが、Criticalが何件、Highが何十件と並んでいるのを見ると、「どれから直せばいいの？」「直すのは誰？」で手が止まってしまうことがよくありました。見えているのに直せない、というのがいちばんもどかしいところです。

Security RX Agentは、この「見つけたあと」を手伝ってくれるAIエージェントです。脆弱性を1つ選ぶと、本番で動いているエンティティの情報をもとにリスクと影響を分析し、修正計画を作ります。修正計画はGitHub Issueとして登録され、そのIssueをきっかけにGitHub CopilotやClaudeといったコーディングエージェントがPull Requestを作ります。人がやるのは、最後のレビューとマージだけです！

画面にも、流れが4つのステップで紹介されています。

なぜ今、脆弱性の「修正」を自動化したいのか

AIエージェントを使った攻撃が、もう現実のものになっています。Anthropicは2025年11月、Claude Codeを悪用したサイバー諜報活動を検知して止めたと公表しました。攻撃のおよそ80〜90%をAIが実行し、人が判断したのは1回の攻撃あたり4〜6箇所程度だったそうです。2026年7月にはPalo Alto NetworksのUnit 42が、AIエージェントが公開された資産を自分で列挙し、2026年のCVEの公開PoCをGitHubから探して、攻撃を試みていた事例を報告しています。この報告では、人が手作業でやれば数百時間かかる標的の分析が、数分で終わっていたとされています。

ここで大事なのは、狙われているのが「公開されていて、PoCもある既知の脆弱性」だという点です。攻撃側は、CVEが出てから試すまでの時間をAIでどんどん縮めています。一方、守る側の「見つける → 誰が直すか決める → 調べる → 直す → 確かめる」は、まだ人の手で回っていることが多いのではないでしょうか。脆弱性が見えているのに修正が何週間も後回しになる、その間が攻撃者にとってのチャンスになってしまいます。

Security RX Agentは、この差を埋めるための機能だと自分は捉えています。整理すると次のとおりです。

機能 … Security RXが見つけた脆弱性を、New Relicの本番のテレメトリを踏まえてAIが分析し、修正計画入りのGitHub Issueを作る。そのIssueからコーディングエージェントがPull Requestを作る
これまでとの違い …「この脆弱性はうちのどのサービスに効くのか」「止まると何が起きるのか」の調査と、ライブラリを上げる修正作業を、人の代わりにエージェントが進める
嬉しいこと … 人がやるのはレビューとマージだけになり、脆弱性を見つけてから直すまでの時間を短くできる。攻撃側がAIで速くなるなら、守る側もAIで速くする
根拠 … 今回の検証では、Issueが作られてからClaudeがPull Requestを出すまで約2分でした。Pull Requestには、ビルドとテストが通ったことまで書かれていました

とくに効きそうだと感じたユースケースは3つです。1つ目は、PoCが公開されたCritical / Highのライブラリ脆弱性への緊急対応です。夜間や休日でも、修正のPull Requestまでは先に用意しておけます。2つ目は、Highが何十件と並んでいて手が回らない状況での優先度付けです。本番で実際に読み込まれていて、リクエストを受けているエンティティから順に分析してくれるので、「本当に関係あるのか」を調べる時間が減ります。3つ目は、依存ライブラリのバージョンを上げるだけ、といった定型的な修正です。こうした作業はエージェントに任せ、人はレビューに集中する、という分担ができます。

利用するための前提

公式ドキュメントに書かれている前提は次のとおりです。

Security RX Appsが有効で、アカウントがSecurity Agentのパブリックプレビューに登録されていること（アカウントIDを営業担当にご連絡ください）
GitHubの接続を作るために、New RelicのOrganization Managerロールを持っていること
対象リポジトリを持つアカウントまたはOrganizationで発行した、GitHubのPersonal Access Token（PAT）。Issues: Read and writeの権限が必要です
対象リポジトリでGitHub Issuesが有効になっていて、コーディングエージェントがインストールされていること（手順は次の節で紹介します）

今回はGitHub.comの個人リポジトリ（Goのバックエンドを含むデモアプリ）に、ClaudeのGitHub Appを入れた状態で試しました。オンボーディング画面の［Need help?］には、PATにContents: Readも付けるよう書かれていたので、あわせて付けています。

PATは対象リポジトリを持つアカウントやOrganizationで発行してください。別のOrganizationで作ったトークンは、リポジトリの選択画面に出てきてもIssueを作れないと画面のヘルプに書かれています。

GitHub側の準備をする

New Relicを設定する前に、GitHub側でPATの発行と、Claudeを動かす準備をしておきます。Claudeの部分は、Claude Code GitHub Actionsの公式ドキュメントの手順そのままです。

1. GitHubのPersonal Access Tokenを発行する

GitHubの［Settings］>［Developer settings］>［Personal access tokens］から発行します。fine-grained tokenなら、対象リポジトリに絞ってIssues: Read and writeとContents: Readを付けます。発行したトークンは、あとでNew Relicの［Create GitHub connection］に貼り付けます。

2. Claude GitHub Appを対象リポジトリにインストールする

下のページから、Claude GitHub Appを対象のリポジトリにインストールします。リポジトリの管理者権限が必要です。

3. リポジトリのシークレットにAPIキーを登録する

リポジトリの［Settings］>［Secrets and variables］>［Actions］で、Claude ConsoleのAPIキーをANTHROPIC_API_KEYという名前で登録します。Claudeのサブスクリプションを使う場合は、claude setup-tokenで発行したトークンをCLAUDE_CODE_OAUTH_TOKENとして登録します。

4. ワークフローのファイルを置く

公式のサンプルexamples/claude.ymlを、リポジトリの.github/workflows/にコピーします。これで、Issueやコメントで@claudeとメンションされるとClaudeが動くようになります。

ローカルでClaude Codeを使っているなら、対象リポジトリで/install-github-appを実行すると、2〜4をまとめてやってくれます。詳しくはClaude Code GitHub Actionsをご覧ください。

Claude Code GitHub Actionsは、リポジトリへの書き込み権限を持つ人のコメントにだけ反応し、botのコメントは既定で無視します。今回の検証では、Security RX Agentが作ったIssueの作成者は、PATを発行した自分になっていました。PATは、対象リポジトリに書き込み権限を持つ人のアカウントで発行しておくと安心です。

Security RX Agentをオンボーディングする

1. ［Security RX］から［Security Agent］をクリックし、［Onboard Security Agent］を選択

冒頭の画像の左メニューにある、［Security RX］>［AI AUTOMATIONS］>［Security Agent］から開けます。

2. ［Select or add GitHub connection］から、GitHubの接続を作成

接続名、GitHub URL、PATを入力して［Create connection］をクリックします。GitHub.comなら、URLはhttps://api.github.com/graphqlのままで大丈夫です。PATは保存後に再表示されません。

3. ［Select repositories］から、対象のリポジトリを選んで［Save］

4. ［Select remediation mode］と［Trigger phrase］を設定して［Continue］

修正の依頼方法は2つから選べました。

Comment-trigger … Security AgentがIssueにトリガーフレーズをコメントし、それをきっかけにコーディングエージェントが動き出す
Agent-assignment … Security AgentがIssueにコーディングエージェント（GitHub Copilotなど）を直接アサインする

ClaudeのGitHub Appはメンションで動くので、今回は［Comment-trigger］にしました。トリガーフレーズの初期値は@claude fixです。日本語で指示したかったので「報告された脆弱性を修正」と入力したところ、［Review］では@claude 報告された脆弱性を修正になっていました。

5. ［Jira configuration］は今回［Skip］

Jiraの接続を作ると、チケットの起票先のプロジェクトや種別、優先度も設定できます。今回はGitHubだけで試したので飛ばしました。

6. ［Review］で内容を確認して［Confirm & configure］

これでオンボーディングは完了です。設定はここまでで、10分もかかりませんでした！

脆弱性を選んで修正を依頼する

1. 左の一覧から、直したい脆弱性をクリック

今回はgopkg.in/yaml.v3のDenial of Service（CVE-2022-28948、High）を選びました。

2. ［Agent analysis］で分析結果を確認

分析は［What is the risk?］［Why is it important?］［What is the impact?］の3つに分かれていました。CVSSのスコアに加えて、「このアプリは今どれくらいリクエストを受けていて、止まると何が起きるか」まで書かれているのが嬉しいポイントです。脆弱性情報だけでなく、New Relicに入っている本番のテレメトリを踏まえて分析してくれます。下には［Security impact metrics］として、攻撃を受けたときに監視すべきメトリクス（今回はError Rate）も提案されていました。

3. ［Choose entities］で修正対象のエンティティを選択

選んだエンティティごとに修正計画が作られます。画面は別の脆弱性（gRPC-Go）で開いたときのものですが、操作は同じです。

4. 修正計画を確認し、GitHub Issueを作成

修正計画には、修正の手順だけでなく、［Validation steps］（直ったことの確かめ方）や［Agent Instructions］（コーディングエージェントにやってほしいこと・やってほしくないこと）まで入っていました。Issueを作成すると、［GitHub issue creation results］に結果が表示されます。［View issue］からGitHubに飛べます。

修正計画はAIが生成した提案です。公式ドキュメントにも、実装前に人がレビューするよう書かれています。

GitHubでIssueとPull Requestを確認する

1. 作成されたIssueを開く

Issueは[Security] [HIGH] Upgrade gopkg.in/yaml.v3 to remediate CVE-2022-28948 Denial of Serviceというタイトルで作られていました。本文には問題の説明、修正方針、影響を受けるリソース、修正手順が並んでいます。Security RX Agentが作るIssueには、必ずsrx-remediateラベルが付きます。Issueの作成者はPATの持ち主（自分）になっていました。

2. コーディングエージェントが作ったPull Requestを開く

トリガーフレーズのコメントを受けて、ClaudeがPull Requestを作ってくれました。gopkg.in/yaml.v3をv3.0.0からv3.0.1に上げ、変更はbackend/go.modとbackend/go.sumの2ファイルだけです。本文の［Test results］には、go list -mでバージョンを確かめたこと、go mod graphで古いバージョンが残っていないこと、go buildとgo testが通ったことまで書かれていました。修正計画の［Validation steps］に書かれた確認を、そのままこなしてくれた形です。

Pull Requestの本文にはFixes #8と書かれているので、マージするとIssueも閉じます。自分がやったのは、差分を見てマージするだけでした！

最後に

いかがでしたでしょうか。Security RXで脆弱性を見つけるところから、AIによる分析、Issueの作成、コーディングエージェントによるPull Requestの作成まで、ひとつの流れで試すことができました。これまで「見えているけど誰も直していない」状態になりがちだった脆弱性を、開発者が普段使っているGitHubのIssueとPull Requestに乗せられるのが大きいと感じました。

本番で実際に動いているエンティティやメトリクスを踏まえて分析してくれるので、「この脆弱性、うちに本当に関係あるの？」を調べる時間も減らせそうです。

改めてになりますが、Security RX Agentは現在パブリックプレビューです。試してみたい方は、New RelicのアカウントIDを担当の営業までご連絡ください。ぜひお試しください！

参考

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