脆弱性ニュース、追いきれていますか？——Claude Code の /schedule で情報収集を半自動化する話
はじめに
最近、セキュリティ系のニュースを目にしない日がありません。
このブログでも Apache HTTP Server の RCE 脆弱性 CVE-2026-23918 や axios のサプライチェーン攻撃、AI関連OSSの安全性について何度か取り上げてきました。書いた当時は「結構大きい話だな」と思っていたのですが、振り返ってみると、ここ数か月だけでも同じ規模感のニュースが何件も出ています。
しかも、最近は AI と絡んだセキュリティ問題 が増えてきました。AI が生成した怪しいコード、AI ベースの拡張機能、MCP サーバー経由のプロンプトインジェクション——攻撃面が一気に増えた、というのが体感です。
正直に言うと、自分自身も全部は追いきれていません。今日はその「追いきれない問題」と、Claude Code の /schedule 機能を使って情報収集を半自動化しはじめた話を書きます。技術解説というより、情報収集をどう設計し直すか という観点での試行錯誤の記録です。
体感として、脆弱性ニュースが明らかに増えている
CVE の番号が CVE-2026-XXXXX で、もう 3 万番台後半まで来ています。1 年でこの数字、というのは数年前と比べてもかなり加速している印象です。
特に最近よく見るパターンを並べてみると、
- 広く使われている OSS の RCE（リモートコード実行）系: Apache、nginx、各種ランタイム
- 依存パッケージ のサプライチェーン攻撃: npm / PyPI / RubyGems などへの悪意あるパッケージ混入
- クラウドサービスの設定起因: S3 公開、IAM 過剰権限、API キー露出
- AI 系ツール周辺: MCP サーバー、AI コーディング補助、AI チャット拡張機能の権限悪用
- エディタ拡張機能の悪用: VSCode 拡張機能の不正アクセス、認証情報窃取
一つ一つは「ああ、なるほど」で終わる話なのですが、毎週のように新しいパターンが出てくる ので、自分の使っているスタックに刺さっているかどうかを判断するだけでもそれなりに時間を取られます。
AI と拡張機能の組み合わせは、特に怪しいものが増えている
ここ最近で個人的に一番警戒しているのが、AI を売りにした拡張機能 です。
「AI コードレビュー」「AI でテスト生成」「AI で○○を自動化」——VSCode のマーケットプレイスや GitHub の Trending を見ていると、こうした拡張機能が日々増えています。便利そうなものも多いのですが、中身を確認せずに入れると、
- ソースコードを丸ごと外部 API に送信する
- 認証情報（
.envや~/.aws/credentials等）を「コンテキストとして」読み取る - バックグラウンドで通信を続け、リポジトリの内容を継続的に送る
といった挙動をするものが混ざってきます。AI を使う以上、何らかの形で外部にコードを送るのは仕方ないのですが、何を、どこに、どの頻度で送っているか が説明されていない拡張機能は要注意です。
実際に GitHub でも、VSCode 拡張機能起因と疑われる不正アクセス被害の事例が報告されています。詳細は事案ごとに異なりますが、概ね「開発者が信頼して入れた拡張機能が、トークンやソースコードを抜いていた」というストーリーです。一度入れてしまうと、自分の開発機ごと汚染されるので影響範囲も大きい。
AI関連OSSを導入する前に の記事でも書きましたが、便利そう→とりあえず入れる、をやめる だけでもかなりリスクは下がります。ただ、便利なものは便利なので、「入れない」ではなく「入れる前に確認する」運用が現実的です。
人の目で全部見極めるのは、もう無理
問題は、入れる時の確認だけでは足りないということです。
入れた後にも、そのライブラリ・拡張機能・依存パッケージのどれかに脆弱性が出る 可能性があります。GitHub の Dependabot は依存パッケージの一部しかカバーしないし、拡張機能側のアップデートはマーケットプレイス頼みです。
たとえば、自分の手元の環境を雑にリストアップしても、
- OS（macOS / Linux）
- ランタイム（Node.js / Python / PHP / Go など）
- フレームワーク（Next.js / Laravel / CakePHP / React / Tailwind …）
- エディタと拡張機能（VSCode + 数十個の拡張）
- CLI ツール（Claude Code / gh / aws / docker / …）
- クラウドサービス（AWS / Cloudflare / Google Cloud …）
くらいは普通に並びます。これら全部の脆弱性ニュースを毎日チェックするのは、現実的に無理です。
しかも、ニュースの一次ソースは英語が多く、ベンダーごとに発信チャンネルもバラバラ。GitHub Security Advisory、CVE データベース、各ベンダーのブログ、X、Hacker News——情報がここまで分散していると、「全部読む」という戦略はもう成立しない、と感じます。
「セキュリティニュースをどこまで把握していますか？」と聞かれて、胸を張って「全部」と答えられる人は、おそらくセキュリティ専業の人だけです。
Claude Code の /schedule 機能を使ってみる
そこで最近試しているのが、Claude Code の /schedule 機能を使った セキュリティニュースの定期収集 です。
/schedule は、Claude Code 上で「指定したプロンプトを cron スケジュールで定期実行する」ための機能です。リモートエージェントとして動くため、自分のローカルマシンが起動していなくても動きます。これを使って、毎朝決まった時間にセキュリティ系の情報を集めて、自分が使っているスタックに関連するものだけを要約してもらう、という運用を試しはじめました。
具体的にやっていることは大きく 3 つです。
1. 一次ソースを定期的にスキャンする
CVE データベース、GitHub Security Advisories、主要ベンダーのセキュリティブログ などを WebSearch / WebFetch で巡回し、直近 24 時間ぶんの新規情報をピックアップする、という指示を /schedule に登録しています。
2. 自分の利用スタックに絞り込む
CLAUDE.md や package.json、composer.json に書かれているフレームワーク・ライブラリ名をベースに、自分に関係しそうなものだけを抽出 してもらいます。
たとえば、このブログで言えば、
- Next.js / React / Tailwind
- Node.js ランタイム
- Cloudflare Pages 周辺
- Claude Code 本体・各種プラグイン
あたりに絞れば、ノイズはだいぶ減ります。Apache の脆弱性は確かに重要ですが、このブログの構成では使っていないので、優先度を下げて構いません（むしろ、業務側の EC2 環境のほうに紐づけて読みます）。
3. 重要度のラベリングと要約
最後に、抽出した項目に「緊急で対応が必要」「自分の構成では関係ない可能性が高い」「念のためメモ」のラベルをつけてもらい、要約だけを Slack なり Markdown ファイルなりに落としてもらう、という流れです。
実体感として、毎朝 3〜5 分眺めるだけで、その日の脆弱性のおおまかな全体像 をつかめるようになります。全部を細かく読まなくても、「今日は自分に関係するやばいやつは無さそうだ」「Next.js の話が出ているから、後でちゃんと読む」くらいの粒度で判断できれば十分です。
実際にこのブログで動かしてみた感想
Cloudflare Pages に移行してから、このブログ自体のセキュリティ管理対象はかなり減りました（移行記事 で書いた通り、AWS のサーバー運用責任が消えたのが大きい）。
それでも、ビルドに使うパッケージや、開発に使う Claude Code 周りのプラグインなど、依存しているものはそれなりにあります。/schedule でセキュリティ情報を毎日拾ってみると、
- 思っていたより自分には関係ないニュースが多い: これは良い気付きでした。「巨大な脆弱性ニュース」も自分の構成に紐づかなければ慌てる必要はない、と整理がつきます。
- 逆に、見逃していたものがそこそこある: 特に開発ツール側（CLI、エディタ拡張）の話は、普段ほぼノーチェックだったので、拾えるようになっただけで体感の安心感が違います。
- 一次ソースが英語でも問題にならない: Claude が日本語要約してくれるので、英語を頑張って読む必要がない。
逆に、現時点でうまくいっていない部分もあります。
- 絞り込みの粒度がまだ甘い: 「Node.js の脆弱性」は確かに関係ありますが、自分が踏むパスとは別の機能の話、ということも多い。「使っている機能名」までキーワードに含めて絞らないと、ノイズが残ります。
- 重要度の判定がブレる: 同じ CVSS スコアでも、構成によって緊急性は変わります。ここはまだ「自分の頭で最終判断する」運用です。
- 過去の対応履歴と紐づいていない: 「これは前に対応済み」「これは関係ないと判断済み」を覚えてくれる仕組みが欲しいですが、まだそこは手作業です。
つまり、/schedule は「最初のフィルター」としてはかなり優秀だけれど、最終判断と運用設計は人間側に残る、というのが正直なところです。
早く気付くだけで、トラブルの大半は防げる
これは AWS の運用をやっていて何度も感じることなのですが、脆弱性そのものよりも、脆弱性に気付くのが遅いことの方が圧倒的に被害が大きい です。
公開された CVE をすぐに把握できれば、
- 影響範囲を確認する
- 暫定の緩和策（例: WAF ルール、機能無効化）を入れる
- 計画的にアップデートを当てる
という当たり前の手順で、ほぼ問題なく対処できます。問題が起きるのは、「公表から 1 か月後にニュースで知った」「攻撃を受けてからログを見てやっと気付いた」というパターンです。
セキュリティ対応は、気付きの速さ で 8 割が決まると言っても過言ではないと感じます。だからこそ、情報収集の仕組み化に多少コストをかける価値があります。
まだ模索中の部分
/schedule でのセキュリティ情報収集は、まだ「動き始めた」段階で、運用としては全然完成していません。特に課題に感じているのは、
- 本当に関係するニュースだけを残す絞り込みロジック: フレームワーク名だけでなく、使っている機能・バージョン・設定までを反映した絞り込みが理想です。
- 複数のリポジトリ・スタックを横断する管理: 個人ブログだけでなく、業務で扱う複数のスタックを跨ぐと、絞り込みの軸がもっと複雑になります。
- 読まない判断を蓄積する仕組み: 一度「これは自分に関係ない」と判断した話は、二度と上げてこないでほしい。ここはメモリ機能などとの連携を考えるべきポイント。
- 誤検知のレビュー: AI が「これは重要」と言ったものが本当に重要か、たまに人間側でレビューしないとズレていく気がします。
このあたりは引き続き手探りで、運用しながら調整していくつもりです。何か知見が貯まったら、別記事でまとめます。
情報の早い時代だからこそ、情報収集も「設計」する
このブログでは、技術スタックの選定や CLAUDE.md のメンテナンス、AI ツールの安全性など、「変化に合わせて運用そのものを見直す」というテーマを何度か取り上げてきました。
情報収集も同じだと思っています。
少し前までは「セキュリティ系のフィードを RSS で受けて、時々読む」くらいで何とかなりました。今は CVE の量も、攻撃の手口の多様化も、AI を絡めた新しいリスクの登場も、明らかに加速しています。同じやり方を続けていると、いつか「気付くのが遅れて事故になる」可能性は確実に上がります。
幸い、Claude Code の /schedule のように、情報収集の一次フィルターを AI に任せられる 時代になっています。完璧ではなくても、毎朝のチェック時間を 3〜5 分にまで圧縮できるなら、十分に価値があります。
情報収集も、コードや CLAUDE.md と同じように「ちゃんと設計してメンテナンスする対象」として扱う。これがこれからのスタンダードになっていくのではないかと、最近強く感じています。
まとめ
- 脆弱性ニュースは体感で明らかに増えており、特に AI と絡んだリスク（拡張機能・MCP・サプライチェーン）が目立つ
- VSCode 拡張機能起因の不正アクセス事例なども出ており、便利さの裏でリスクは確実に増えている
- 全てのニュースを人間が追うのは現実的でなく、仕組み化が必要
- Claude Code の
/scheduleで、セキュリティニュースを定期収集 → 自分のスタックに絞り込み → 要約、という流れを試している - 関係ないニュースを切り捨てるためのロジックはまだ模索中だが、それでも気付くのが早くなった効果は十分にある
- セキュリティ対応は「気付きの速さ」で大半が決まる。情報収集も設計してメンテナンスする時代
/schedule の具体的な書き方や、絞り込みの工夫が固まってきたら、もう少し実装寄りの記事として続きを書こうと思います。