昨年後半くらいからですかね、AI を使った脆弱性の発見が一般的になり、公表される脆弱性が一気に増え、攻撃する側も AI で攻撃コードを素早く用意できるようになったことで、重大な脆弱性が見つかるペースも件数も大きく増えたと感じます。
結果として、お仕事、プライベートを問わず、自分が管理したり関わったりしているサーバやシステムでも、対応すべきセキュリティ事案の件数が増えただけでなく、より速い対応が必要になっています。
AI が当たり前ではない時代、といっても数年前の話ですが、その頃なら、JVN やベンダのアドバイザリー、メーリングリストなどで脆弱性を知り、自分の環境に影響があるかを調べ（ググったり）、検証環境で動作を確認して～ みたいな準備作業をしてから、次のメンテナンスの日程に合わせてパッチを当てる、みたいな流れが普通でした。よほど重大なものでなければ、週単位や月単位で計画を立てていても多くの場合はそこまで問題にならなかったと思います（もちろん携わっているサーバやシステムにはよりますけども）。
ところが今はある脆弱性に対して公表、修正版が出てから実際に悪用されるまでの期間がどんどん短くなり、下手すると修正版が出る前に悪用が始まることも珍しくありません。しかも AI が見つける脆弱性には何十年もの間、誰にも気付かれていなかったものや、少ない手順で RCE につながるような重大なものが少なくありません。怖い。
もちろん、ある脆弱性が自分の環境にどの程度影響するのかについては、単純な CVSS のスコアだけで決まるようなものでもなく、環境に依存する部分も大きいため、何でもかんでもやばいやばい騒いでも仕方ないのは確かなんですが、とはいえ、昨今の次のメンテナンスを悠長に待っている間に攻撃を受けてもおかしくない状況、かつ対応すべき件数も増え続けている状況で、脆弱性情報を 1 件ずつ人間が調べて～ なんてやってる場合じゃねぇなと。
そこで、脆弱性情報の収集と、見つかった脆弱性の概要や攻撃が成立する条件の整理を、AI エージェントに任せることにしました。さらに、単なる情報収集だけだと結局は重要度の判定をこちらがやらないといけなくなるので、そこも解消するため、管理対象のサーバやシステムへの影響度の調査、初期対応の方法と優先順位の検討といった一次トリアージも AI に任せることで、人の負担を減らしつつ対応を速くする仕組みを作ってみました。頻度は「毎朝」。
最終的な判断と対応は人間が行いますが、その手前の「情報収集」→ 「自分の環境に当てはめて影響があるのか、あるならその危険度はどの程度で、どういう対処が必要かの一次トリアージを行う」までの作業を AI エージェントに毎朝のルーティンとしてやってもらうイメージです。
何をしているのか
絶対にこの構成じゃなければいけないということはないんですが、今回は、3 つの AI エージェントにご参加いただき、専用の GitHub のリポジトリを使用して作業してもらう形になっています。
| 役割 | 使っているもの | 動作タイミング |
|---|---|---|
| 脆弱性情報の収集（X 中心） | Grok Bot | 毎朝 7 時 ～ 8 時 |
| 脆弱性情報の収集（Web 検索中心） | Muse | 毎朝 7 時 ～ 8 時 |
| 裏取り・影響判定・深掘りレポートの作成 | Claude Code（「スケジュール済みタスク」を利用） | 毎朝 8 時半 |
サーバ構成表（stack.md）の更新 |
Claude Code（ローカルで実行） | サーバの構成を変えたとき |
| レポートと構成表の置き場所 | GitHub のリポジトリ | -- |
脆弱性情報収集には 2 つの AI エージェントを使用していますが、Grok を使っているのは、特に X での情報収集に優位性があることを活かしてもらうためです。というのは脆弱性やセキュリティの話題は、X で先に話題になることが多いため。
もうひとつの Muse は、別に Claude でも ChatGPT でも同じことはできるんですが、ちょうど Muse にやらせるタスクを探してたのと、どの程度の精度が出るのか確認したかったのでちょうどいいやって理由。Muse には主に Web の記事や公式情報で見つかるものを探してもらいます。ちなみに Muse にこのタスクを頼むとき、「君は Web 検索だけでなく、Facebook とかの情報も見るの？」と聞いてみたら、「見ない」って言われたので、彼（？）は基本的に Web 検索中心の情報収集係になります。
全体の流れを大まかに
大まかな動作の流れは図解にすると以下の通り（クリックすると拡大画像を別ウィンドウで表示）で、詳しくは続く本文で説明します。
サーバ構成の更新（ローカル作業フォルダ）
まず事前準備として、管理対象となるサーバや稼働しているシステムで使用している OS やパッケージ、技術スタック等をファイル（これは Git 管理外）にまとめ、Claude Code が深掘りするための前提となる「サーバ構成表」と Claude Code が処理をする際の参考にする CLAUDE.md を作成してリポジトリに push しておきます。
この中の「技術スタック等をまとめたファイル」と、それを基にした「サーバ構成表」は適宜更新します。
- 管理対象サーバから、サーバ内情報（OS やパッケージのバージョン、稼働中のサービスなど）を収集スクリプトで取得する。取得は手動で、カーネルやパッケージを更新したときや、ソフトウェアを新たにインストールしたときに毎回行う。自動更新等によるずれをなるべく生まないため、最低でも月 1 回は取り直す。
- サーバ内情報を取り直すたびに、Claude Code に
stack.mdの更新を依頼する。 - Claude Code はサーバ内情報の内容を確認し、要約して
stack.mdを更新する。 - 更新された
stack.mdを私が念のため確認してから、GitHub に push する。これで翌朝からの深掘りレポートの作成は、この新しいstack.mdに基づいて行われる。
毎朝の自動処理（定期実行タスク）
各 AI エージェントは毎朝決められた時間帯にレポートを作成し、リポジトリに push してきます。
このレポートを使って、Claude Code（Opus 5.5）が情報の裏取り、深掘り、前述の「サーバ構成表」をもとに、影響度やとるべき対策などをまとめて深掘りレポートをリポジトリに push、私に通知を送ってきます。
- 毎朝 7 時～8 時に、2 つの AI Bot が定期実行される。
Grok は X の話題を中心に、Muse は Web 検索を中心に、直近 24 時間で話題になった脆弱性情報やサプライチェーン攻撃、セキュリティインシデントなどを収集し、日次レポート（YYYY-MM-DD.md）を生成して GitHub に push する。 - 毎朝 8 時半に、Claude が定期実行される。
Claude は GitHub 上の日次レポートとstack.md（管理対象サーバの構成をまとめたファイル）を読み込み、一次情報（NVD、JVN、ベンダのアドバイザリー、GitHub Security Advisory、Ubuntu CVE Tracker、CISA KEV など）で CVE の内容や修正版、悪用状況を確認しながら深掘り調査する。
そのうえで、脆弱性情報の管理対象サーバへの影響などをまとめた深掘りレポート（YYYY-MM-DD.md）を生成して GitHub に push する。 - 毎朝 7 時～9 時の間に、各定期実行タスクから私に通知が届く。
人間の対応
毎朝、AI たちが作ってくれたレポートを閲覧し、急ぎ対応しないといけなそうなものがあれば具体的な対処をしたり、深掘りレポートには社内や関係者に共有する際の短い文章の草案みたいなものも入れてもらっているので、それを使って情報共有したりといった対応をします。
- 私は Claude からの通知を受けて深掘りレポートを確認し、サーバの保守作業や、社内・関係先への情報共有など、必要に応じて対処する。
ということで、やっていることはまぁ普通なんですが、ここまで 1 週間くらい回してみて、それなりに満足いく精度でレポートが上がってきているので、今後もしばらく運用してみようと思っています。
少しだけ工夫したところ
いくつか工夫したことがあるのでメモしておきます。
各 AI エージェントのレポートは「未検証の外部データ」として扱う
各 AI エージェントのレポートは X や Web の情報を元に書かれているので、（可能性は低いんですが）悪意のある文章が紛れ込む可能性があります。そこで Claude Code には、レポートの中に何か指示など、怪しい情報が含まれていた場合はそれを無視した上で、深掘りレポートの「異常」欄に記録しておいてもらうようにお願いしています。所謂プロンプトインジェクション対策です。
Grok や Muse が自分のレポート以外のファイルを書き換えたりするような想定外（与えている指示の中では禁止している）の動作が起こった場合も、コミット履歴から検知して「異常」欄に載せてもらうことで、私が早めに気がつくようにしてもらっています。
また、Claude Code に対しても、定期タスクでは stack.md や CLAUDE.md を勝手に書き換えたりしないように指示するなど、やっていいことと駄目なことを明確に伝えるようにしています。
事実は一次情報で確認し、確認できないものは「未確認」と素直にレポートさせる
Claude には Grok や Muse が作ってくるレポートの内容を盲目的に信用せず、NVD やベンダのアドバイザリーなどの一次情報を自分で探して裏を取り、もし Grok や Muse が書いてきたレポートの記述と一次情報が食い違う場合は、一次情報の内容を採用した上で食い違いをレポートに明記すること、裏がとれなかった情報は勝手に推測したり、あまり信頼性の高くない情報で無理に埋めたりせずに、素直に「未確認」とレポートするように指示をしています。
これによって、未確認な情報はきちんと把握し、必要に応じて後からもう一度追いかけたりできるようにします。
判定ルールを構成表に書いておくことでレポートの精度と統一感を上げる
影響度の判定は「影響あり」「要確認」「影響なし」の 3 段階で行うようにお願いし、判定の精度を上げるため、stack.md にはサーバ構成だけでなく、例えば次のような判定ルールも書いています。
- Ubuntu の公式パッケージは、修正を古いバージョンに取り込む（backport する）ので、upstream のバージョン番号だけで判定せず、Ubuntu のセキュリティ通知（USN）や Ubuntu CVE Tracker で修正版を確認せよ
- universe のパッケージは、Ubuntu Pro（ESM）がないと修正が来ないことがあるので、「自動更新されるから安全」と判断しないこと
- サードパーティの apt リポジトリ（NodeSource など）は自動更新の対象外なので、古いままの可能性があることに留意せよ
- インストール済みでも停止中のソフトウェアは、影響度を一段下げること
加えて、自分が特に気にしている製品名を「監視キーワード」として並べておき、一致した話題を優先して深掘りさせるなど、Claude Code に何をして欲しいかを明確に伝えるようにしています。
サーバ構成の元データは GitHub に置かない
私が手動（といっても収集スクリプトを使って自動化はしていますが）で取得したサーバ内情報には、IP アドレスなどサーバ自体を特定できる情報は入れていないものの、OS やパッケージの細かいバージョンや稼働中のサービスなど、攻撃者にとっては下調べになる情報が並んでいます。そのため、この元データは手元にだけ置き、GitHub にはこの元データを使って Claude Code に作ってもらった、判定に必要な要約（stack.md）だけを置く形にしています。
リポジトリはプライベートですし、そこまで神経質になるほどの情報ではないのですが、念のためという感じ。
（余談）当初は Vuls を使ってやろうと思っていたけれど......
当初は、脆弱性スキャナーの Vuls を使って同じような仕組みを作ろうと考えていましたが、結局、サーバ内の構成を自分で取得する方向に切り替えて、今の形になりました。
Vuls は、サーバに入っているパッケージをすべて CVE のデータベースと突き合わせる方式なので網羅性は高いものの、修正版がまだ出ていないものや実際には悪用しにくいものまで大量にレポートとして出てきます。数が多いと Claude Code にトリアージさせるにしても精度が出るか疑問だったのと、大量のレポートは人間が見るのも大変。なのでもうちょいシンプルに、「今、話題になっている脆弱性」をキーに自分の環境に関係あるのか、ないのかを素早くチェックできる、シンプルな仕組みにしようと今回の形にしました。
今回の仕組みは「直近で話題になっている脆弱性」を入口にしていることで、毎朝、レポートの対象になる情報の件数は比較的少なく、悪用状況や KEV の対応期限で優先度が付いた状態で届くため人間が見てわかりやすいのと、集めた脆弱性情報と照らし合わせるサーバ構成も Markdown 形式にすることで Claude Code が扱いやすいし、再利用性も高いというメリットもあります。
一方で、X や Web を探して「話題になっているもの」をキーにするため、「あまり話題になっていない脆弱性を取りこぼす」懸念はありますが、サーバ側での定期的なパッケージアップデートはやっていて、OS のパッケージなら話題にならなくても修正は入るので、まぁいいだろうと。
あと頻度が 1 日 1 回（毎朝）なので、日本時間で午前中とかにわーっと話題になったことなんかは次の日の朝までレポートには上がってこないんですけども、まぁ起きている間は X 見たりしているし、大騒ぎになってりゃレポートを待たずに私が気がつくだろってことでそこも気にしていません。
ということで、AI エージェントさんたちに働かせることで少しでも楽をしようという試み。もともと脆弱性情報なんかは、n8n を自前でホストして自動収集する仕組みを昨年くらいから作ってたんですけども、最近は AI エージェントが様々なサービスと連携しやすくなってきたり、定期タスクを簡単にお願いできるようになってきたので今回の仕組みを試してみている感じ。
サーバ構成なんかが絡むため、具体的な stack.md や CLAUDE.md、Claude Code が作成した深掘りレポートの実物なんかが公開できなくて申し訳ないんですが、何かの参考になれば幸いです。
