脆弱性対応にAIを使う企業が知っておきたいOSS「CVE MCP Server」の使いどころ

「脆弱性の情報が毎日のように出てきて、どれから直すべきか決めるだけで一日が終わる」「AIに調べさせれば速くなりそうだが、何をどこに問い合わせているのか分からないまま使ってよいのか」——脆弱性対応を少人数で回している情報システム部門から、よく聞こえてくる二つの声です。AIに調べものを肩代わりさせる便利な道具の話に見えますが、それだけではありません。本当は、修正の優先順位という、会社の判断そのものにAIの出した答えが入り込むことをどう扱うかが問われています。この記事では、脆弱性の公開情報や悪用の指標をAIから一度に引けるようにするOSS「CVE MCP Server」について、一次情報で確かめられる事実、脆弱性管理での使いどころ、外部のサービスへ送られる情報やライセンス表記の食い違いといった注意点を整理します。導入や設定の手順は扱いません。

CVE MCP Serverとは何か。2026年10月時点で確かめられる事実

CVE MCP Server は、GitHub上で公開されているOSSです。リポジトリの説明によれば、MCP（AIと外部の道具をつなぐ共通の取り決め）に対応した脆弱性とセキュリティの情報を調べるための道具をまとめてAIに渡すサーバーです。READMEは、Claude Desktop や Claude Code などから使う形を図で示しています。本体は Python で書かれており、AIが直接つながるのはこのサーバーで、サーバーが公的な脆弱性の情報源や各種の調査サービスへ問い合わせて、結果をAIに返す流れです。

公開の時期と規模も押さえておきます。リポジトリが作られたのは2026年4月14日で、最後の更新は2026年10月1日です。2026年10月23日時点でスターはおよそ1,600、複製（フォーク）は268で、1日あたりの伸びは平均して8前後です。パッケージの設定ファイルに書かれた版は0.2.0ですが、GitHub上の公開済みの版（リリース）は登録されていません。派手に急伸したのではなく、半年かけて着実に注目を集めてきたOSSだといえます。

作者は個人のアカウント（mukul975）で、アカウントの作成は2018年8月、公開しているリポジトリは33、フォロワーはおよそ1,400です。ライセンスの文書には作者の個人名で著作権の表示があります。所属する会社は確認できませんでした。公開済みのセキュリティ勧告は、確認した範囲では見当たりません。一方で、脆弱性の報告の窓口を定めた方針の文書は置かれています（後述）。

道具の数の書き方には揺れがあります。リポジトリの説明欄は「21の情報源にまたがる27の道具」としていますが、READMEの本文は「28の道具と、一度の呼び出しでまとめて振り分ける機能、24の情報源」としています。版を重ねる中で説明の更新が追いついていないと見られ、数字は版によって変わるものとして読むのが無難です。この記事ではREADMEの本文の分類に沿って説明します。

ライセンス表記の食い違いと「OSS」と呼べる理由

ライセンスは、導入の可否を左右するので丁寧に見ておきます。リポジトリに置かれたライセンスの文書そのものは、Apache-2.0 の全文で、パッケージの設定ファイルもライセンスとしてこの文書を指しています。GitHubの表示も Apache-2.0 です。

ところが、READMEの冒頭の小さな表示と末尾のライセンスの節は「MIT」と書いています。つまり、同じリポジトリの中でライセンスの表記が二通りある状態です。どちらが作者の意図なのかは、一次情報からは確かめられませんでした。一般には、リポジトリに置かれたライセンスの文書が優先して読まれることが多いものの、法的な判断は社内の担当部門に委ねるべき点です。

幸い、Apache-2.0 も MIT も、OSI（オープンソースの定義を管理する団体）が承認したライセンスです。どちらであっても、この記事で「OSS」と呼ぶことに問題はありません。ただし両者は、特許の扱いや変更点の明示の求め方などで条件が異なります。社内で改変して配る予定があるなら、どちらのライセンスとして扱うかを作者に確かめるか、より条件の多い側に合わせて運用するのが安全です。

なぜ脆弱性の振り分けにAIをつなぐ動きが出てきたのか

READMEは、この道具が解こうとする問題をはっきり書いています。一つの脆弱性を振り分けるだけでも、公的な脆弱性データベースで深刻度を見て、悪用の可能性の指標を見て、実際に悪用が確認された脆弱性の一覧に載っているかを見て、修正の情報を探す。その結果を頭の中で突き合わせる作業を、数十件分くり返すと一日が終わる、という問題です。

この悩みは多くの企業に共通します。公表される脆弱性の数は年々増え、深刻度の点数だけで順番を決めると、点数は高いが実際にはほとんど狙われないものに手を取られます。そこで、悪用の可能性の指標として知られる EPSS（FIRST という国際団体が公開する、今後30日の間に悪用が観測される確率の推定）や、米国の CISA が公開する実際に悪用が確認された脆弱性の一覧（KEV）を組み合わせて優先順位を決める考え方が広がってきました。

ただ、こうした指標は情報源が別々で、見に行く先が増えるほど手間も増えます。CVE MCP Server は、その見に行く先をAIの側からまとめて呼べるようにし、人がブラウザーのタブを行き来していた作業を、AIへの一つの問いかけに置き換えることを狙っています。少人数で脆弱性対応を回す組織ほど、この発想に引かれるのは自然です。

機能1：脆弱性の情報を一度にまとめて引く

READMEによると、中心にあるのは脆弱性の情報を調べる道具群です。脆弱性の番号から公的なデータベースの記録（深刻度の点数・弱点の種類・影響を受ける製品・参考情報など）を引く、製品名や深刻度で脆弱性を探す、悪用の可能性の指標を引く、悪用が確認された一覧に載っているかを確かめる、深刻度の点数の内訳を説明する、といった道具が並んでいます。最大20件をまとめて引く道具もあります。

さらに、版0.2.0では、一度の呼び出しで複数の情報源へ同時に問い合わせ、点数の計算までまとめて行う振り分けの機能が加わったと説明されています。公的なデータベースが混み合って応答が遅いときには、別の事業者が提供する写しに切り替える仕組みも書かれています。個々の道具を組み合わせる手間をAIに任せず、決まった手順で一気に集める設計だと読めます。

このほか、公開されている攻撃の手口の分類（MITRE ATT&CK）や攻撃の型の一覧との対応づけ、公開された検証用のコード（概念実証）があるかどうかの確認、使っている部品の一覧から既知の脆弱性を探す道具、GitHubのセキュリティ勧告を引く道具も並びます。いずれも読み取りの問い合わせで、READMEは、能動的な診断（相手の機器に通信を送って調べること）は行わないと明記しています。

READMEの分類	道具の数	主な役割（概要）
まとめて振り分ける機能	1	複数の情報源へ同時に問い合わせ、点数と推奨をまとめて返す
脆弱性の基本情報	8	公的データベースの記録・悪用の可能性・悪用確認の一覧・深刻度の内訳など
攻撃の手口と検証コードの情報	4	手口の分類との対応・検証用コードの有無・攻撃の型の一覧
点数と報告	4	独自の点数・報告のまとめ・優先順位づけ・話題の脆弱性
通信先の情報	4	IPアドレスの評判・外部の調査サービスでの機器の情報・過去の名前解決の記録
脅威の情報	4	ファイルの評判・不正なプログラムや痕跡の検索・身代金要求の情報
開発と運用の安全	3	部品の脆弱性の確認・GitHubの勧告・ウェブページの調査サービス

表はREADMEの本文の分類を日本語でまとめたもので、合計は28です。前に触れたとおり説明欄では27とされており、道具の数は版によって変わることに注意してください。

機能2：複数の指標を一つにまとめるリスクの点数

この道具の特徴の一つが、独自の「総合リスクの点数」です。READMEによると、深刻度の点数を20%、悪用の可能性の指標を35%、悪用が確認された一覧への掲載を30%、検証用コードの有無を15%の重みで足し合わせ、条件によって割り増しをかけて、0から100の点数にします。76以上を最も重い段階とし、悪用が確認された一覧に載っている脆弱性は、計算の結果にかかわらず最も重い段階に引き上げるという決まりも組み込まれています。

深刻度の点数を「悪用の有無を示す信号」ではなく「影響の大きさの信号」として扱う、とREADMEが断っている点は、脆弱性管理の考え方として筋が通っています。実際に狙われているかどうかを重く見て、点数の高さだけで順番を決めない、という近年の優先順位づけの流れに沿った設計です。

また、詳しく調べる設定では、米国の CERT/CC が考案し CISA も採用している SSVC（脆弱性への対応の緊急度を、悪用の状況や影響の広さから段階的に判断する枠組み）に沿った判断を試験的に出す機能もあると書かれています。ただし、ここで押さえたいのは、この重みづけは作者が決めた一つの考え方であり、業界の標準でも、あなたの会社の基準でもないという点です。自社にとって重要な仕組みかどうか、外から触れられる場所にあるかどうかといった事情は、この点数には入っていません。

機能3：脅威の情報と外部の調査サービスへの問い合わせ（概要）

脆弱性の情報のほかに、IPアドレスやドメイン、ファイルの指紋（ハッシュ値）などを外部の調査サービスに問い合わせる道具もあります。READMEの図では、インターネットにつながった機器の情報を集めた検索サービスの Shodan や、ファイルやURLの評判を調べる VirusTotal などが情報源として挙げられています。これらの多くは、各サービスの利用登録で得る鍵が必要だとされています。

この記事では、これらの道具の個別の使い方には立ち入りません。防御の立場で押さえておくべきは二点です。一つは、問い合わせた値そのものが、外部のサービスへ送られることです。もう一つは、外部の機器の情報を調べる機能は、自社の守りの確認にも、他者の調査にも使えてしまう、という両面性です。後の節で、それぞれの注意点を整理します。

なお、READMEは、社内向けのIPアドレス（社内の網で使う範囲や、自分自身を指す番号など）は外部への問い合わせの前に止める作りだと説明しています。社内の機器の情報がうっかり外部へ送られることを防ぐ配慮として評価できますが、外部に公開している自社のIPアドレスやドメインは止める対象に入らない点は理解しておく必要があります。

脆弱性管理での使いどころ：下調べと説明の材料づくり

では、企業の脆弱性管理のどこで役立つのでしょうか。最も素直な使いどころは、新しく公表された脆弱性について、公開情報を集めて一枚にまとめる下調べです。深刻度・悪用の可能性・悪用確認の一覧への掲載・修正の情報の有無を、担当者が一件ずつ見に行かなくてもそろえられます。

二つ目は、修正の順番を決める会議の材料づくりです。数十件の候補を並べ、点数と根拠をそろえて示せれば、議論の出発点を早く作れます。経営層や他部門に「なぜこれを先に直すのか」を説明するときにも、悪用が確認されているか、悪用の可能性がどの程度か、という外部の公的な指標を根拠として添えられるのは助けになります。

三つ目は、使っている部品の一覧から既知の脆弱性を洗い出す確認です。開発の現場で部品の更新を判断する際の参考になります。いずれの使いどころでも共通するのは、AIが集めて並べるところまでを任せ、どれを直すかの決定は人が行うという分担です。この分担を崩さない限り、少人数の組織でも下調べの負担を大きく減らせる可能性があります。

従来の調べ方との違い

CVE MCP Server を使う形と、これまでの調べ方を比べてみます。ここでの比較は、READMEの説明と一般的な運用の姿をもとにした整理で、特定の製品との優劣を示すものではありません。

観点	担当者が各サイトを手で調べる	CVE MCP Server をAIにつなぐ	商用の脆弱性管理の製品
情報の集め方	人が一件ずつ見に行く	AIが複数の情報源へまとめて問い合わせる	製品が自動で取り込む
優先順位の根拠	担当者の経験と判断	作者独自の重みの点数＋AIの説明	製品ごとの点数と自社の資産情報
自社の資産との突き合わせ	人が台帳と照らす	基本的に含まれない	資産の台帳と連携できるものが多い
外部へ出る情報	閲覧した内容のみ	問い合わせた番号・IPアドレス・ドメインなど	製品の契約と設定による
運用の担い手	担当者	自社（鍵の管理・更新・点検）	提供元と自社

表から分かるとおり、CVE MCP Server は「人の手作業」と「商用の製品」の間に位置します。手作業より速く、商用の製品より手軽に始められる一方、自社の資産との突き合わせや、運用の責任は自社に残るという性格を持っています。どの形が合うかは、組織の規模と、すでに使っている仕組みによって変わります。

安全性の評価：注意付きとした根拠

このラインでは、OSSをクローン・インストール・実行せず、公開されている情報だけで安全性を精査しています。CVE MCP Server の判定は「注意付き」としました。根拠は次のとおりです。

まず、安心材料になる事実があります。作者のアカウントは2018年に作られ、フォロワーもおよそ1,400と、急ごしらえの匿名アカウントではありません。確認した範囲で公開済みのセキュリティ勧告はなく、脆弱性の報告の窓口と対応の目安を定めた方針の文書も置かれています。READMEには、外向きの暗号化された通信だけを使うこと、利用状況の送信（テレメトリー）をしないこと、外部から受け取るデータの危険な読み込み方を避ける部品を使っていることなど、安全面の配慮が具体的に書かれています。

それでも「注意付き」としたのは、問い合わせた内容が、複数の外部サービスへ送られる作りであることと、ライセンスの表記がリポジトリの中で食い違っていることの二点です。加えて、個人が運営するOSSで、公開済みの版の管理がまだ整っていない点も考慮しました。なお、問題が見つからなかったことは安全の保証ではありません。ここでの判定は、2026年10月23日時点で公開情報から確かめられた範囲に基づくものです。

注意点の詳細：外部へ送られる情報と、鍵と記録の扱い

READMEの安全とプライバシーの節は、脆弱性の番号、IPアドレス、ファイルの指紋、ドメイン、部品の名前が、それぞれの情報源へ送られると明記しています。脆弱性の番号だけなら公開情報ですが、どの番号を調べたかの並びは、自社がどの製品を使っているかを映す情報になりえます。IPアドレスやドメインを調べれば、自社や取引先の通信先が外部のサービスの記録に残る可能性もあります。各サービスが問い合わせをどう扱うかは、それぞれの利用規約によります。

また、READMEは、書き込みの操作は行わないとしつつ、例外としてウェブページの調査サービスへの提出を挙げています。この種のサービスでは、提出したURLや調査結果が他の利用者から見える設定になることがあるため、社内向けのURLを提出しないといった線を引いておくのが安全です。公開の範囲がどうなるかは、サービス側の設定と規約で確かめてください。

鍵の扱いについて、READMEは、各サービスの鍵は環境の設定から読み込み、記録や一時保存には残さないと説明しています。手元には、問い合わせの結果を一時的に保存する小さなデータベースと、利用の記録（監査ログ）が残る作りです。監査ログは一定の大きさで切り替わり、問い合わせの中身そのものは記録しないとされています。鍵が個人の端末に散らばらないようにすること、記録をどこまで残すかを決めることは、使う側の責任です。

運営の体制にも触れておきます。方針の文書によれば、報告には48時間以内に受け付けの連絡、7日以内に解決の見通しを示すとしています。支えられる版は最新の版と、一つ前の版を90日間です。個人が運営するOSSとしては丁寧な部類ですが、企業の契約による保守とは性格が違うことは理解しておきましょう。READMEの説明と今後の計画の間には、実装済みかどうかの記述の食い違いも見られます。また、READMEには作者の研究アンケートへの協力の呼びかけが載っています。こうした外部への案内は道具の機能とは関係がなく、社内で使う判断の材料にはしないのが無難です。

悪用されうるリスク

この道具は防御のための情報収集を目的としていますが、一般論として、悪用されうる面もあります。一つは、外部の機器の情報や過去の名前解決の記録を調べる機能です。これらは公開情報の調査であり、それ自体が攻撃ではありませんが、対象を他者の資産に向ければ、下調べの手間を減らす道具にもなりうるという両面性があります。検証用コードの有無を確かめる機能も、守る側にとっては優先順位の材料ですが、立場を変えれば狙いやすい脆弱性を探す手がかりになる可能性があります。

もう一つは、AIに外部の文章を読ませること自体のリスクです。脆弱性の説明文や参考情報、公開された検証用コードの説明などは、第三者が書いた外部のデータです。OWASP は、AIが読み込んだ外部の文章に紛れた指示によって振る舞いがゆがめられる危険を、間接的なプロンプトインジェクションとして挙げています。集めてきた外部の文章の中に、AIをだますための指示が混ざる可能性はゼロではなく、この道具に限らず、外部の情報をAIに読ませる仕組み全般に当てはまる注意です。現時点で、この道具を通じた実際の被害の報告は確認していません。

さらに、配布物そのものへの注意もあります。人気のあるOSSは、名前の似た偽物や、改ざんされた複製が出回る対象になりがちです。READMEは、登録された道具の一覧から計算した指紋を取り出せる仕組みを、改ざんの検知のためと説明しています。正規のリポジトリから入手し、更新のたびに中身の変化を確かめるという基本は、ここでも欠かせません。

導入を検討するときに確かめること

社内で使うかどうかを判断する前に、確かめておきたい点を順に並べます。操作の手順ではなく、判断の段取りとして読んでください。

企業が取るべき対策

CVE MCP Server を使う場合も、使わない場合も、脆弱性の調べものにAIをつなぐ企業が整えておきたい対策を挙げます。一つ目は、AIにつなぐ道具の一覧を会社として管理することです。担当者が個人の判断で調査用のサーバーをAIにつなぐと、どの情報がどの外部サービスへ流れているかを誰も把握できなくなります。MCPで道具をつなぐときは、申請と承認の流れに乗せましょう。

二つ目は、外部サービスの鍵と利用規約の管理です。無料の範囲で取得した鍵は、多くの場合、個人の登録にひもづきます。業務で使う鍵は会社の名義で取得し、担当者が替わっても止められる状態にすることが大切です。商用での利用が許されているかも、サービスごとに確かめてください。

三つ目は、点数を社内の基準に組み込むときの扱いです。外部の指標や独自の点数は、自社の資産の重要度や、外から触れられるかどうかと組み合わせて初めて意味を持つものです。社内の脆弱性対応の規程では、どの指標を参考にし、最終的な順番を誰が決めるかを明文化しておきましょう。四つ目は、取り込んだOSSの更新と点検の担当を決めることです。個人が運営する道具は、保守の状況が変わることがあります。定期的に更新の有無とライセンスの表記を確かめる担当を置くと安心です。

AIに任せる範囲と、人が決める範囲

脆弱性管理にAIを使うとき、最も避けたいのは、AIが出した点数や推奨をそのまま修正の順番にしてしまうことです。AIは情報を集めて並べ、根拠を添えて説明するところまでは得意ですが、自社のどの仕組みが止まると困るのか、どこまでの危険を受け入れるのかは知りません。そこは人が決める範囲です。

• AIが「すぐ直すべき」と答えた順番を、そのまま修正の計画にする
• 点数の高い順に並べるだけで、自社の資産の重要度や外部からの触れやすさを考えない
• 取引先のIPアドレスやドメインを、確認なしに外部の調査サービスへ問い合わせる
• 担当者の個人名義の鍵で業務の問い合わせを続け、異動や退職で止まる
• AIが読み込んだ外部の文章の内容を、元の情報源で確かめずに報告書へ書き写す

裏を返せば、AIに任せてよいのは、公開情報を集めて一覧にし、なぜその点数になったのかの根拠を書かせるところまでです。AIには必ず根拠となった情報源を示させ、人がその情報源を確かめてから判断する。どの脆弱性をいつまでに直すか、例外を認めるかは、規程に沿って人が決めます。人が確認する範囲を先に決めておけば、AIの速さを生かしながら、判断の責任を手放さずに済みます。

よくある質問

無料で使えますか

ソフトそのものはOSSとして公開されています。READMEによると、脆弱性の基本情報など多くの道具は鍵なしでも使えますが、公的なデータベースは鍵がないと問い合わせの回数に強い制限があります。外部の調査サービスの多くは鍵が必要で、無料の範囲には回数の上限があるとされています。業務で使うなら、各サービスの料金と規約を別に確かめてください。

自社のネットワークの中を調べる道具ですか

いいえ。READMEは、能動的な診断は行わず、公開されている情報源への問い合わせだけを行うと説明しています。社内向けのIPアドレスは問い合わせの前に止める作りです。自社の機器にどの脆弱性があるかを知るには、資産の台帳や診断の仕組みと組み合わせる必要があります。

出てきた点数を社内の基準にしてよいですか

参考にはなりますが、そのまま基準にすることはおすすめしません。重みづけは作者独自のもので、自社の資産の重要度は含まれていません。公的な指標そのもの（悪用の可能性の指標や、悪用が確認された一覧への掲載）を自社の基準に組み込み、この道具はそれを集める手段として使う、という整理が現実的です。

• CVE MCP Server の機能・道具の数・点数の計算方法・安全面の配慮は、2026年10月23日に GitHub のリポジトリ（README・ライセンスの文書・方針の文書・パッケージの設定ファイル）を確かめた範囲に基づきます。版によって変わることがあります
• ライセンスは、ライセンスの文書とGitHubの表示が Apache-2.0、READMEの表記が MIT で食い違っています。どちらが作者の意図かは確認できていません
• この記事はソフトウェアを実行せずに書いています。点数の精度や動作の安定性は検証していません。外部サービスの料金・規約・問い合わせの扱いは各サービスで確かめてください

まとめ

CVE MCP Server は、脆弱性の公開情報や悪用の指標をAIから一度に引けるようにするOSSです。公的なデータベース、悪用の可能性の指標、悪用が確認された一覧などを束ね、独自の総合リスクの点数まで出してくれます。少人数で脆弱性対応を回す企業にとって、下調べと説明の材料づくりを速くする道具として使いどころがあります。

一方で、問い合わせた番号やIPアドレス、ドメインなどは外部のサービスへ送られます。ライセンスはリポジトリの中で Apache-2.0 と MIT の表記が食い違っており、個人が運営する若いOSSでもあります。導入するなら、外部へ送ってよい情報の線、鍵と記録の置き場所、ライセンスの扱いを先に決め、隔離した環境で小さく試すのが順序です。

そして何より、AIが出した点数や推奨は判断の材料であって、判断そのものではありません。AIに根拠を示させ、人が確かめ、修正の順番は自社の基準で人が決める。この線を守れば、AIの速さを脆弱性管理の味方にできます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。