こんにちは、Hitomiです。
自社のデバイスやサーバーで脆弱性対応が必要なものが出てきたとき、CVE 番号は分かるのに、「これは結局何で、うちは急ぐのか」を毎回ゼロから調べ直していて時間が溶ける、という場面があります。番号は分かる。一次情報のリンクもたどれる。それでも、その「読み始め」の手間は、毎回人が背負っている。
そこで、社内 Slack に常駐している Claude Tag に、CVE の「これはどんな脆弱性？」を自動で先付けさせてみました。
結論から言うと、これは実用になります。
ただ、期待していた「レポートが来たら即、全自動で解説」までは届きませんでした。Claude の起動判定はトップレベルの投稿しか確実に見てくれず、定期実行も最短で 1 時間おき。
そこで運用はハイブリッドに落ち着きました。急ぎの CVE は、人がトップレベルで直接メンションする。それ以外はスタンプで“解説予約”しておいて、毎日のスイープでまとめて拾う。
そしてもうひとつ分かったのは、解説の信用を決めるのは派手な機能ではなくプロンプト設計だということ。一次情報をもとに書かせて、確認できないことは「未確認」と正直に書かせる——この地味な工夫がいちばん効きました。
前回、弊社代表のシンジが Claude Tag そのものを設定・監査ログまで検証した記事「Claude Tag という名の新機能登場、設定・テスト・監査ログまで実践レビュー」がありますが、本記事はその姉妹編として、Claude Tag を「セキュリティ運用の実務にひとつ入れてみた」話を、はまりどころも含めて残しておきます。
TL;DR
- Slack に常駐させた Claude Tag に、CVE の「攻撃成立要件」と「解説」を自動で先付けさせ、脆弱性トリアージの“読み始め”を速くしました。
- 効いたのは派手な機能よりプロンプト設計。一次情報ベースで書かせ、確認できないことは「未確認」と明示させるのがキモ。最終判断は人が一次情報で裏取りします。
- “即時”の壁は 2 つ。起動判定はトップレベル投稿しか確実に見ないため、スレッドの中でメンションをして呼びかけても気づいてもらえないことが多く、あとから定期的に見回って拾ってくれる仕組み（スイープ）を待つ形になります。そのスイープも繰り返し実行の下限が最小 1 時間。入力が日次なら頻度を合わせればよく、「急ぎは人がトップレベルで直接メンション／それ以外はスタンプで解説予約して毎朝 1 回のスイープで回収」が現実解でした。
やりたかったのは「これは何？」を先付けすること
弊社では、脆弱性管理ツールから日次で脆弱性レポートが Slack に流れてくる運用になっています。レポートには CVE 番号と、参考 URL（NVD などの一次情報リンク）が並びます。
実務で毎回コストになるのは、レポートを受けてから次の一次判断までの部分です。これは何の脆弱性で、どういう条件で刺さるのか。うちの環境で急ぐ案件なのか、様子見でいいのか。ここを Claude に肩代わりさせ、「攻撃成立要件」と「脆弱性の解説」をスレッドに先付けしておければ、人はそこから一次情報で裏取りして判断に集中できます。
最初に強調しておきたいのは、Claude の解説はあくまでトリアージの“一次補助”で、最終判断は人がやる、という前提です。セキュリティの実務で LLM の出力をそのまま結論にするのは危険なので、ここは後半でもう一度触れます。
全体の流れ
起動の経路は 3 つあります。急ぎのときに人がトップレベルで直接メンションする即時経路、普段のスタンプ（ワークフロー）による“解説予約”、そして返信が付かないままの解説予約を拾う毎日のスイープです。
なぜ経路が 3 つも必要になったのかは、後半の「はまりどころ」で説明します。最初は素直に「レポートが来たら自動で解説してくれるだろう」と思っていたのですが、そう単純ではありませんでした。
どう作ったか：ワークフローで @Claude を定型プロンプトで叩く
CVE スレッドに対して、Slack ワークフロー「CVE 解説呼び出しちゃん」が @Claude メンションと定型プロンプトを投稿し、Claude を起動します。運用上は、スレッドのスタンプ（「説明しよう！」）を押すとワークフローが動く形にしています。ただし後述のとおり、スレッド返信でのメンションは起動判定をすり抜けることがあるため、このスタンプは「即時起動ボタン」というより「解説予約」に近い位置づけです（すり抜けた分は毎日のスイープが拾います）。
実際に投げているプロンプトがこちらです。まず全文を載せます。
あなたはセキュリティ専門家です。以下のCVEについて、Slack投稿用に日本語で解説してください。
対象: スレッドに記載のCVE番号
【トーン】
- セキュリティに詳しくない読者にもわかるよう噛み砕く。ただし専門用語は正しいまま残し、初出時にカッコ書きで短い補足を添える。
- たとえ話に逃げず、実際に「何が起きているか」を説明する。
【出力形式】以下の3セクションのみ。前置き・結論は書かない。
*{CVE-ID}*（通称があれば併記）
*攻撃成立要件*（何が揃うと成立するか）
- 3〜5項目。各項目は「何が起きたら/何が揃うと成立するのか」という条件の形で書く。
- 権限の要否（PR）、リモート可否（AV）、ユーザー操作の要否（UI）、前提となる稼働条件・対象バージョン、パッチ/PoCの有無を必ず含める。CVSS表記は使う場合カッコ書きで補足する。
*脆弱性の解説*（何が起きているか）
- 3〜5項目。脆弱性の種類とCWE-ID、根本原因、攻撃メカニズム（どう悪用するか）、影響（どこまで奪えるか）を、噛み砕いて説明する。
- 用語はそのまま残す（例: TOCTOU, reparse point 等）。詳しい定義は用語集に回す。
*用語集*
- 本文に出てきた専門用語のうち、説明が要るものだけを挙げる（本文に出ていない語は入れない）。
- 各語: 「正式名（読み/和名）：1〜2行の平易な説明。この脆弱性での役割」。SYSTEMやPoC等、一般的すぎて読者が知っていそうな語は入れない。
【事実の扱い】
- 一次情報（NVD/MITRE/ベンダー勧告/GitHub Advisory）を優先する。確認できない事実は「未確認」と明記し、推測で断定しない。
- CVSSスコアが採点主体で割れる場合は両論併記する。
- 最後に出典の種類を1行で明記し、一次ソースを直接確認できなかった場合はその旨も添える。プロンプトをこう書いた理由
このプロンプトは、ルール一つひとつに運用上の意図があります。
まず「前置き・結論を書かない／決まったセクションだけ」。いまの形は、CVE-ID の見出し＋「攻撃成立要件」「脆弱性の解説」「用語集」の 3 セクション構成です。出力は Slack スレッドにそのまま流れるので、ノイズを削って毎回同じ型で読めるようにしておくと、複数の CVE が並んだときに比較しやすくなります。
次に「専門用語はそのまま残し、初出にカッコで短い補足を添える」。TOCTOU（処理の時間差を突く欠陥）や reparse point（Windows のファイル参照の仕掛け）といった特定のワードは、消してしまうと一次情報や PoC を当たるときの検索性が落ちます。残したうえで補足を付けることで、専門外の担当でも読める。そのうえで、説明が要る語は末尾の「用語集」に分離させています。本文では用語をそのまま残して検索性と正確さを保ちつつ、詳しい定義は用語集に寄せる。専門外の人は用語集で補い、詳しい人は本文だけで読める、という両立を狙ったものです。
そして、この記事でいちばん伝えたいのが「一次情報に基づき、出典の種類を 1 行で明記する／確認できない事実は『未確認』と書き、推測で断定しない」のところです。LLM に CVE を解説させるときの最大のリスクは、CVSS 値や影響バージョン、PoC の有無を“それっぽく”埋めてしまうことです。これを出力側で「未確認」と自己申告させておくと、読み手はその表示をそのまま「人が一次情報で裏取りすべき場所」のマーカーとして使えます。さらに、CVSS が採点主体で割れる場合は両論併記させ、一次ソースを直接確認できなかったときはその旨も添えさせています。
トーンも「たとえ話に逃げず、実際に何が起きているかを説明する」と縛りました。比喩で分かった気にさせるより、条件と事実で語らせたいからです。幸い、参考 URL は日次レポーターが既にスレッドに出しているので、Claude は宙に浮いた知識ではなく、その場の一次情報を起点に書けます。
最後にセクションの順番です。「攻撃成立要件 → 脆弱性の解説」という並びは、トリアージの思考順そのものにしています。まず「自分の環境に刺さるか」（権限の要否・リモート可否・user interaction の要否・対象バージョン）を見て、急ぐかどうかを先に判断する。中身（CWE・根本原因・攻撃メカニズム・影響・CVSS・PoC）はその後で読む、という流れです。
返ってくる解説は、たとえば次のような形になります（フォーマットを示すための例で、値はプレースホルダです。実際の CVE の数値ではありません）。
「影響を受ける範囲」や「深刻度（CVSS）」「悪用状況（PoC）」に、未確認がそのまま残せる作りになっているのが分かります。ここが、人が NVD などで裏取りすべき場所のサインです。
実際に動かして分かった、はまりどころ
ここからが正直なところです。最初の想定どおりにいかなかった点を、4 つ残しておきます。
はまり①：ボットの投稿には Claude が自分から反応しない
最初に面食らったのがこれでした。脆弱性レポーターのような Webhook／ボットからの投稿に、Claude はデフォルトでは自分から反応しません。ボットの投稿は「通知（情報）」として扱われ、自分から勝手に動かないようになっていました。
これは不具合ではなく、前回記事で扱った Agent Identity の考え方（自然言語の指示はあくまで“助言”で、デフォルトは安全側に倒す）と一貫した、むしろ望ましい挙動です。だからこそ、レポートに対して解説させたいなら、ワークフローで明示的に @Claude メンションして起動する必要があります。
……と、当初はここまでの理解でした。ところが運用を始めてから、盲点がもう一段深いところにあると分かります。事前の起動判定はトップレベル投稿の本文しか確実に見ておらず、スレッド返信でのメンションはイベントが確実には発火しないのです。ワークフローが投稿する @Claude はスレッド返信なので、実はこの制約にかかります。
例外は、Claude がすでにそのスレッドで一度動いている（セッションが立っている）場合で、このときは後続のスレッド返信メンションにもリアルタイムで応答します。逆に、まだ一度も絡んでいない“冷えた”スレッドへの返信メンションは、すり抜ける恐れが残ります（ボットからのメンションですり抜けた実例が 1 件あり、これは後述のスイープが回収しています。人からのメンションが同じ扱いになるかは未確認）。確実に即時で動かしたいなら、トップレベルで @Claude を呼ぶのがいちばん確実、ということになります。
ボット投稿に自動で動いてほしい場合の選択肢は 2 つあります。ひとつは、都度、人が @Claude で「このレポート見て」と振る方法。もうひとつは、チャンネルに「このレポートが来たら毎回、要約・トリアージして」と指示して、自動応答設定として記憶させる方法です。今回は後者の発想を、「来たら毎回全部」ではなく「スタンプで解説予約された分だけ」に絞った形で、次に出てくるスイープ（定期実行）として実現しました。
はまり②：即時化の下限は「1 時間」だった
「ボットが投稿した瞬間に拾って即解説」を自動でやりたかったのですが、ここで壁にぶつかりました。
漏れを拾う安全網として、まずチャンネルに「解説予約の @Claude メンションが付いているのに、まだ返信していない CVE スレッドを確認して解説して」と自然言語で頼み、定期実行（トリガー）を設置しました。最初は毎時（cron 0 * * * *）で様子を見ていて、これは実際に機能しました。ある朝、スイープが 10:00 に未対応分を検知して解説を自動投稿してくれて、はまり①ですり抜けた 1 件を、実際に回収できています。
そのうえで「もっと短い間隔にできないか」と試したのですが、ここには下限がありました。10 分間隔の cron を設定しようとするとサーバ側に明確に拒否され、エラーは minimum interval is 1 hour。繰り返し実行の下限が 1 時間であることが、弊社のテナントで試した限りでははっきりしました（公式ドキュメントに明記された値というより、実機で返ってきたエラーメッセージからの確認です）。単発予約を毎回自分で繋ぐ「自己再帰方式」なら数分間隔まで詰められますが、チェーンが切れると止まり、常時セッションを消費するので、脆く高コストです。基本はおすすめしません。
ただ、ここで立ち止まって気づいたのは、そもそも頻度を詰める必要があるのか、という点でした。弊社では脆弱性レポートの Slack 通知が毎朝 9 時に確定で出ます（他は出現次第）。入力が日次なら、スイープを毎時回す意味は薄く、通知の 1 時間後＝毎朝 10 時に 1 回だけ拾えば十分です。結局いまは、1 日 1 回・10 時のスイープ（cron 0 10 * * *）に落ち着きました。なお、出現次第で届くレポートは、スタンプで解説予約しておいても最悪翌朝のスイープまで未解説のまま残りますが、急ぎであれば人がトップレベルで直接メンションする運用でカバーできるため、ここは割り切っています。「スレッド返信のメンション → 即起動」をプッシュで確実に実現する手段は手元には無いものの、入力の周期に合わせれば毎時である必要はなかった、ということです。
はまり③：安全網のスイープは「タダの保険」ではない
もうひとつ、コストの話です。Claude Tag のチャンネル利用は従量課金で、前回記事でも組織ハードキャップとチャンネル個別上限の 2 層になっていることが整理されています。
ここで効いてくるのが、はまり①で書いた「ボット投稿には自分から反応しない＝オプトイン」という性質です。仮に全部のボット投稿へ自動反応させると、解説が要らない CVE にもクレジットを消費します。逆に「解説が要るときだけスタンプ（ワークフロー）を押す」運用なら、押さなければ解説対象にならず、その分のクレジットも使われません。デフォルトで静観してくれるのは、安全側であると同時に、必要な CVE だけにコストを使うという意味でも都合がよかった、ということです。
一方で、安全網のスイープは別です。これは返信の無い解説予約が残っていないかを確認するために定期的に動くので、ヒットの有無にかかわらずベースコスト（チャンネルコンテキストの読み込み等の起動コスト）が乗ります。「拾い直す保険」はタダではない、という前提で持つ層です。
だからこそ、前のはまりで触れたように、頻度は入力の周期に合わせるのが効きます。弊社は確定の定時通知が毎朝 9 時の 1 回なので、スイープも毎朝 10 時の 1 回だけ。仮に毎時で回す場合と比べて実行回数は 1/24 で、この層のコストはほぼ起動回数で決まるため、削減効果はそのまま効きます。
はまり④：知らないうちに「常時観測」が動いていた
最後は、いちばん統制の話らしいはまりです。ある日、スイープの時刻より早く CVE 解説が付いていたことがありました。調べてみると、チャンネル全体を見ている常駐の観測セッションがスレッド返信も含めて監視しており、ワークフローの返信メンションをほぼリアルタイムで検知して Claude に引き渡していたのです。トップレベルしか見ない起動判定の制約を受けない“別経路”が、こちらの設計図に無いところで動いていました。
便利は便利です。ただ、この常時観測はこのチャンネルに必要がなく、コストの見積もりにも乗っていませんでした。一旦方針を明示的に確定させてチャンネルメモリに記録しました。
トップレベルのメンションは即応、スレッド返信は 1 日 1 回のスイープで拾う、遅くて困るときは人がトップレベルで直接呼ぶ。常時観測が解説予約を先に拾って解説が早く付くことはあっても、それは「たまたま早かった」扱いにして当てにしません。自動で動く経路としては、スイープ一本に寄せた形です。
なお、スイープを日 2〜4 回に増やせば遅延は数時間まで縮みますが、コストは回数に比例して増えます。うちは「遅くて困るなら人が呼ぶ」で足りるので、1 日 1 回（最大約 24 時間の遅延を許容）を維持しています。
現実解：急ぎは人、漏れは毎日のスイープ
判定はこれだけです。
CVE が来た
│
├─ 急ぐ？──[Yes]→ 人がトップレベルで @Claude に直接メンション（即時）
│
└─[No]──→ スタンプで“解説予約”（解説が要らなければ何もしない）
└→ 返信が付かなかった解説予約を毎朝10時のスイープが拾う（安全網・通知の約1時間後）4 つの起動方式を、即時性・安定性・コストで並べると整理がつきます。
| 起動方式 | 即時性 | 安定性 | コスト | 向いている用途 |
|---|---|---|---|---|
人がトップレベルで直接 @Claude（手動） | ◎ 即時 | ◎ | 呼んだときだけ | 緊急の CVE |
| スタンプ（ワークフローのスレッド返信） | △ 実質スイープ待ち（セッションが立っていれば即応） | ○ | スイープに相乗り | 通常の CVE の“解説予約” |
毎日10時のスイープ（cron 0 10 * * *） | △ 通知の約1時間後 | ◎ | 1日1回のベースコスト | 取りこぼしの安全網 |
| 自己再帰方式（単発予約の連鎖） | ○ 数分 | △ 切れると停止 | 常時セッション消費 | 基本おすすめしない |
当面の運用ルールはシンプルです。緊急の CVE は人がトップレベルで @Claude に振る。それ以外はスタンプで“解説予約”しておき、毎朝 10 時のスイープが拾う（定時通知が 9 時なので、その 1 時間後）。即時性を厳密に要件化したいなら、Claude Tag の自律トリガーに寄せきらず、レポーター側や別の通知経路と組み合わせる設計も検討する価値があります。
設置済みのトリガーは、チャンネルでこう聞けばいつでも棚卸しできます。
@Claude what triggers do you have set up here?運用に乗せるためのチェックリスト
この仕組みを実務に置くなら、私は少なくとも次を押さえます。
- プロンプトを固定する（一次情報ベース・「未確認」明示・CVE-ID 見出し＋3 セクション構成）。出力の「未確認」は、人が裏取りすべき場所のサインとして扱う。
- CVSS・影響範囲・対象バージョン・PoC の有無は、必ず NVD／JVN／ベンダー勧告で人が裏取りしてから判断する。Claude の解説をそのまま報告に転記しない。
- 安全網のスイープは頻度を入力の周期に合わせる（弊社は通知が毎朝 9 時なので、10 時に 1 日 1 回）。毎時のように回しすぎないことでベースコストを抑える。
- 緊急はトップレベルでの直接メンション、それ以外は解説予約＋毎日のスイープ、という役割分担をチームの手順に明記する。スレッド返信でのメンションは（セッションが立っていない限り）すり抜ける前提で扱う。
what triggers do you have set up here?を定期的に実行し、不要・重複のトリガーを止める。
緊急性の高い脆弱性が出たときにも力を発揮する
この仕組みは日次レポートの処理のために作りましたが、実際に使ってみると、定時運用の外で出てくる脆弱性にも同じように効きます。ニュースやベンダー勧告で急に話題になった CVE、お客様から「これはうちに影響ありますか」と聞かれた CVE。そういうときは日次レポーターの投稿を待つ必要はなく、チャンネルのトップレベルで @Claude に CVE 番号を添えて同じ定型プロンプトを投げれば、その場で同じ型の解説が返ってきます。トップレベルのメンションは起動判定の制約を受けないので、急ぎのときほど確実な経路でもあります。
緊急時こそ、この「毎回同じ型」が効きます。慌てているときにいちばん欲しいのは、「攻撃成立要件」を上から読んで、権限の要否・リモート可否・対象バージョンから「うちに刺さるか」を数分で見立てられることです。「未確認」のマーカーは、そのまま裏取りに走るべき場所のリストになります。解説はスレッドに残るので、後から合流したメンバーも同じ読み始めから入れます。
つまりこの仕組みは、「毎朝のレポートを効率化する仕掛け」であると同時に、「任意の CVE をいつでも同じ品質で読み始められる窓口」でもあります。日次の定型運用と、突発対応。入り口が違うだけで、プロンプトも読み方も裏取りの作法も同じ、というのが運用として楽なところです。
FAQ
ボットの投稿に Claude が反応しません。故障ですか？
故障とは限りません。少なくとも弊社のテナントでは、Webhook／ボットの投稿は「通知（情報）」として扱われ、Claude がデフォルトで自分から動かない挙動でした。また、起動判定はトップレベル投稿しか確実に見ていないようで、スレッド返信でのメンション（ワークフロー経由を含む）がすり抜けるケースを観測しています（公式に文書化された仕様としては未確認）。
確実に反応させたいときはトップレベルで @Claude を呼ぶのが無難で、すり抜けた分は毎日のスイープで拾えます。結果としては安全側に倒れつつ、必要な CVE だけにクレジットを使える形になっています。
解説のラグを 1 時間より短くできますか
2026年7月時点で弊社のテナントで試した限りでは、繰り返し実行の下限は 1 時間でした（10 分間隔は minimum interval is 1 hour で拒否）。スイープを日 2〜4 回に増やせば遅延は数時間まで縮みますが、コストは回数に比例して増えます。急ぎは人がトップレベルで直接メンションするのが確実です。自己再帰方式で数分間隔も理屈の上では可能ですが、脆く常時コストがかかるため、基本はおすすめしません。
Claude の解説をそのまま報告に使っていいですか
いいえ。解説は“読み始めの一次補助”です。CVSS・影響範囲・対象バージョン・PoC の有無は、出力の「未確認」も手がかりにしながら、NVD／JVN／ベンダー勧告で人が裏取りしてから判断してください。
まとめ
Claude Tag に CVE の「これは何？」を自動解説させる試みは、トリアージの読み始めを確実に速くしてくれて、実用になりました。ただ、効いたのは派手な機能ではなく、プロンプトで一次情報と「未確認」を強制する地味な設計のほうです。
そして振り返ってみると、役に立ったのは「すごい自動化」ではなく、日々の運用を楽にするための小さな工夫の積み重ねでした。毎回同じ型で解説が返ってくるから、読み始めで迷わない。「未確認」がそのまま裏取りの目印になる。急ぎは人がトップレベルでメンションし、それ以外はスタンプで解説予約して毎朝 1 回のスイープに任せておけば、急ぎでないものに関しては張り付いていなくても翌朝には解説が揃っている。
即時性には「起動判定はトップレベル投稿しか確実に見ない」「自律トリガーは最小 1 時間」という壁がありましたが、入力が日次ならそこに頻度を合わせるだけで、運用は拍子抜けするほど軽くなります。
便利だからではなく、説明できるから置く。そして置くなら、日々の手間が確実に減る形で。小さな CVE 解説の自動化でも、結局そこが大事だと思います。
参考（一次情報）
- 前回記事：Claude Tag という名の新機能登場、設定・テスト・監査ログまで実践レビュー
- Anthropic 公式発表「Introducing Claude Tag」
- Claude Tag ドキュメント（Overview）
- Agent identity: a new access model for autonomous, team-wide AI
補足：本文中の「minimum interval is 1 hour」「スイープによる取りこぼし回収」「ボット投稿への非反応」「起動判定がトップレベル投稿しか確実に見ないこと」「チャンネル常時観測セッションの存在」などは、弊社テナントでの実機観測です。公式に文書化された仕様値ではないため、導入判断時は最新の公式ドキュメントとご自身のテナント表示をご確認ください。また本記事は仕組みの検証が目的で、個別 CVE の技術的内容そのものは検証・断定していません。
