オープンソースの脆弱性をAIで探して保守者に届ける無料サービス「OSS Scanner」とは

「自社で公開しているオープンソースに、AIが見つけた脆弱性の報告が大量に届くようになったらどう受け止めればよいのか」「業務で使っているライブラリの修正版が急に増えたが、追いかけきれるだろうか」——オープンソースを公開する側と使う側、両方の立場の開発・セキュリティ担当者から聞こえ始めた声です。AIが脆弱性を見つける話は、便利な道具が一つ増えたというだけではありません。本当は、見つかる脆弱性の量が人の確認の速さを上回り、確かめる責任が受け取る側へ移り始めているという変化です。この記事では、Anthropicが2026年10月に始めた無料サービス「OSS Scanner」について、一次情報で確かめられる仕組み、申し込むと外部に渡すことになる情報、利用規約の確認点、AIの指摘を人が確かめる体制を整理します。申し込みの手順や設定ファイルの書き方は扱いません。

OSS Scannerとは何か。2026年10月時点で確かめられる事実

OSS Scanner は、Anthropic が提供する、オープンソースのリポジトリを対象にした脆弱性の点検サービスです。サービスの説明ページによると、参加した事業の保守者は、提供元の最も強い言語モデルによる定期的な点検を無料で受けられるとされています。2026年10月8日に受け付けが始まり、同月13日には参加の条件や報告の届け先についての説明が書き足されました。

GitHub上の同名のリポジトリは、Apache-2.0のライセンスで公開されています。ただし中身は点検の仕組みそのものではなく、サービスへ申し込むための窓口です。READMEによると、保守者は自分の事業の情報を書いたフォルダを一つ加える変更の提案を、このリポジトリへ送って申し込みます。提供元は申込の変更だけを受け付け、それ以外の貢献は受けないと明記しています。

このため、この記事では「オープンソースのツール」ではなく「サービス」として扱います。2026年10月21日時点で、リポジトリのスターはおよそ1,350、複製（フォーク）はおよそ800です。複製が多いのは、申込の変更を送るために各保守者が複製を作る仕組みだからだと考えられます。READMEの冒頭には、利用はサービスの規約に従うと書かれています。

なぜ今始まったのか：AIが見つける脆弱性の量が人の確認を上回った

提供元の発表によると、言語モデルの脆弱性を見つける力が大きく伸び、提供元は過去6か月で2万9,000件を超える脆弱性の候補を見つけたものの、人が手作業で確かめられたのはおよそ6,000件にとどまったとされています。一部の保守者からは、確認前の報告でもまとめて送ってほしいという要望があり、すでに5,000件近くを直接送ってきたとも書かれています。

これまで提供元は、見つけた脆弱性を人が確かめてから保守者に知らせる、協調的な脆弱性の開示（関係者と調整してから公表する進め方）を行ってきました。OSS Scanner は、人の確認を待たずに、見つかった報告をすぐ受け取りたい保守者のための「早回し」の道と位置づけられています。人が確かめる従来の進め方も、確認の人手を持たない事業のために続けるとしています。

発表は、攻め手が脆弱性を突く方法を短時間で作れるようになった以上、守る側が早く見つけることに意味がある、という考え方を示しています。裏を返せば、見つける速さが上がった分だけ、確かめて直す側の負担が重くなるということでもあります。この点は、後の見出しで利用企業の立場から考えます。

仕組み：隔離した環境で構築し、外部につながない状態で点検する

READMEとサービスの説明によると、点検は二段階で進みます。まず、保守者が用意した構築の手順に従って、事業を隔離した仮想の機械の中で組み立てます。この段階では、必要な部品を取り込むためにインターネットにつながります。次に、その機械をインターネットにつながらない網へ移してから点検するとされています。

構築に失敗した場合は、登録した主な連絡先に誤りの内容がメールで届きます。点検は一度で終わらず、新しく入り込んだ脆弱性や前回見逃したものを探すために、定期的に繰り返されるとされています。点検を行うAIの担い手も、外部への通信を断った強化済みの隔離環境で動くと説明されています。

サービスの説明では、見つかった報告が依存する部品ではなく、点検の対象の事業そのものの脆弱性に当たるかを確かめる仕組みを設けているとも書かれています。ただし、その仕組みの精度や中身は公開されておらず、依存部品の問題が混ざらないことが保証されているわけではないと受け止めるのが妥当です。

報告に含まれるもの：再現の手がかり・説明・修正案

READMEによると、見つかった問題は登録した連絡先へメールで届き、可能な場合は再現の手がかりと修正案が付きます。発表では、単独で動く再現の手がかり、問題の説明、可能なら問題が入り込んだ時期の特定、修正の候補が報告に含まれうると説明されています。

報告は暗号化して受け取ることもできます。公開鍵（OpenPGP の方式）を登録すると、報告は主な連絡先だけに送られ、追加の宛先には送られなくなるとされています。暗号化と追加の宛先は両立しないため、チームで報告を共有したい場合と、経路の秘匿を優先したい場合とで、どちらを取るかを決める必要があります。

修正案が付いてくるのは便利に見えますが、規約は、提案された修正が機能を壊すことがあると明記しています。修正案はそのまま取り込む完成品ではなく、検討の出発点として扱うべきものです。修正の採否は、事業の設計と試験を知る保守者が決めることになります。

人の確認を経ない「早回し」の報告であること

OSS Scanner の最も大きな特徴は、READMEが報告は言語モデルが作ったもので、人は確認していないと明記している点です。発表でも、人による確認や仕分けを経ずに送ることで点検の回数を増やし、早く結果を返せる一方、誤った報告や無効な報告が混じりうると説明しています。

提供元は精度の目安も示しています。発表によると、初期版の点検で見つかった重大度「緊急」「高」の97件（48の事業）を、提供元の開示の確認を担う専門の検査担当者が調べたところ、85件（88％）が提供元の開示の基準を満たしました。残る12件のうち11件は実在するものの既知の問題などとの重複で、誤検知は1件だったとされています。

ただし、これは提供元自身による検証で、外部の第三者が確かめた数字ではありません。発表は、保守者から、重大度が高めに付けられる、事業の脅威の想定を誤解するといった声が寄せられていることも認め、完璧は保証できないと書いています。数字は参考にとどめ、自分の事業での当たり外れは自分で確かめる前提が欠かせません。

申し込める条件：重要な基盤となるオープンソースに限られる

サービスの説明によると、受け付けの基準は、グーグルの継続的な点検の仕組みである OSS-Fuzz に近いとされています。考慮される要素として、事業の年数、更新の頻度、OpenSSF（オープンソースの安全性を高める業界団体）の重要度の指標、オープンソースのライセンス、スターと複製の数、利用の広がり、安全面での重要さが挙げられています。

一方で、新しく始まったばかりの事業や、ほとんどの複製は対象になりにくいとされています。また、確認済みの重大度「高」「緊急」の報告に、すでに対応できている事業を想定しているとも書かれています。報告を受け止める力がない事業に大量の報告を送らないための線引きと読めます。

規約では、申込者は事業の中心となる保守者か、その許可を得た人でなければならず、社員として事業を保守している場合は、所属する組織の許可が要ると定めています。申込は人が確かめ、申込者が中心の保守者か、連絡先が正当なものかを確認するとされています。採否は事業ごとに判断され、提供元は申込を断ったり、参加を取り消したりできます。

申し込むと外部に渡すもの：リポジトリの情報・連絡先・脅威の想定

申し込みで提供元に渡す情報は、READMEから次のように読み取れます。点検してほしいリポジトリの所在、報告を受け取る主な連絡先と追加の宛先、事業を組み立てる手順、そして任意で、事業の脅威の想定（どこから信頼できない入力が入り、何を守りたいかを書いた文書）です。

渡すもの	どこに置かれるか	注意したい点
点検するリポジトリの所在	申込の窓口（公開のリポジトリ）	公開の事業が前提。点検の対象として登録したことも公開される
主な連絡先・追加の宛先	申込の窓口（公開）	READMEは連絡先が公開されると明記。セキュリティ用の共有の宛先を使うよう勧めている
構築の手順	自分のリポジトリか、申込の窓口	構築は提供元の隔離環境で、インターネットにつないで行われる
脅威の想定（任意）	自分のリポジトリか、申込の窓口	どこに弱点がありうるかを書く文書。公開の場に置く内容は選ぶ
暗号化用の公開鍵（任意）	申込の窓口（公開）	登録すると追加の宛先は使えない

READMEは、連絡先のメールの宛先が公開されることを明記し、公開されても困らない、セキュリティ用の共有の宛先を使うよう勧めています。個人の宛先を書けば、迷惑メールや、保守者を装った働きかけの的になりうるため、この勧めには従うのが無難です。

脅威の想定は、点検の精度を上げるために「強く勧める」とされる一方、公開の窓口に置けば誰でも読めます。どこから信頼できない入力が入るか、どの部品が重要かを書いた文書は、攻め手にとっても手がかりになりうるため、公開してよい粒度に整えてから置くことが大切です。

利用規約の確認点：報告は提供元の機密、責任の上限は1,000ドル

規約で特に確かめておきたいのは、報告の扱いです。規約は、サービス、各報告、関連する資料は提供元の機密情報だと定めています。参加者は、脆弱性が直るか公表されるまで報告を機密として安全に保つ合理的な措置を取る義務を負い、報告を共有できるのは事業の権限ある保守者だけです。

報告を使ってよいのは、事業の脆弱性や不具合を見つけ、評価し、直す目的に限られ、第三者の仕組みを攻撃する目的などでの利用は禁じられています。サービスと報告は現状のまま提供され、報告が不完全・不正確であること、脆弱性を見逃すこと、重大度を誤ること、修正案が機能を壊すことがありうると明記されています。報告と修正案を使う前に確かめる責任は参加者にあり、提供元の賠償の上限は1,000ドルとされています。

学習への利用については、この規約のページには書かれておらず、提供元の一般向けの規約を取り込むとだけ書かれています。提出した情報や報告が学習に使われるかどうかは、確認した範囲では確かめられませんでした。気になる場合は、一般向けの規約もあわせて読む必要があります。適用される法律や紛争の扱いも、このページには記載がありません。

参加者はいつでも参加を止めたり終えたりでき、提供元もいつでもサービスや参加を変更・停止・終了できるとされています。無料のサービスは、提供元の都合で内容が変わりうることを前提に、点検をこのサービスだけに頼らない計画にしておくのが無難です。

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

このラインでは、対象を取得・導入・実行せず、公開されている情報と精査の記録をもとに安全性を判定しています。OSS Scanner の判定は「注意付き」です。根拠は、リポジトリ自体はApache-2.0で公開されているものの、実体は提供元のサービスの申込窓口で、利用には独自の条件を含む規約が適用されることです。報告の機密保持の義務、利用目的の制限、賠償の上限など、ソフトウェアのライセンスだけでは分からない約束が伴います。

加えて、報告は人の確認を経ずに届くこと、申し込むと連絡先が公開されることも、使う前に知っておくべき点です。READMEには、申込前に構築を手元で試すための道具も置かれていますが、その道具は事業の構築の手順をネットワークにつないだ状態で動かすため、信頼できる事業だけで試すか、失って困るものがない機械で使うよう、提供元自身が注意を書いています。

一方、精査の範囲では、リポジトリに公開済みのセキュリティ勧告はなく、導入の際に自動で動く処理も見つかりませんでした。提供元は実績のある組織で、リポジトリの作成は2026年10月8日です。スターの伸びは1日あたり100前後と急ですが、発表と報道に合わせた関心の集まりと見られます。問題が見つからなかったことは安全の保証ではありません。

悪用されうるリスクと、公開の時期をめぐる注意

脆弱性の報告は、直す側にとっては宝ですが、攻める側にとっても価値のある情報です。規約が報告を機密とし、第三者への攻撃への利用を禁じているのはこのためです。申し込んだ事業の側では、報告のメールが届く宛先と、それを読める人の範囲が、そのまま情報の守りの境目になると考える必要があります。

公開の時期にも注意が要ります。READMEは、人が確認していない報告には90日の開示の期限を設けず、公表もしないとしています。一方、規約では、人が手作業で確かめた脆弱性については、保守者に知らせてから90日後以降に提供元が開示しうるとされています。さらにサービスの説明では、将来、重大度の高い一部の報告に、事前の通知と辞退の機会を設けたうえで開示の期限を付ける可能性があると書かれています。

つまり、報告を放置しても公表されないとは限らないということです。推測になりますが、同じ脆弱性を別の誰かがAIで見つける可能性もあり、見つかったものは早く確かめて直すのが基本になります。公開の連絡先を狙った、提供元を装う偽の報告メールが現れる可能性にも備えておくべきでしょう。

自社が依存するオープンソースの利用企業にとっての意味

OSS Scanner に申し込むのは保守者ですが、影響は利用企業にも及びます。重要な基盤のオープンソースで報告と修正が増えれば、修正版の公開や、脆弱性の識別番号（CVE）の登録が増える可能性があります。自社の製品や社内の仕組みが使っている部品の更新を、これまでより速く、多く追いかける場面が出てくると考えられます。

これは悪い知らせではありません。見つかって直される脆弱性が増えるのは、利用者にとっても安全の底上げです。ただし、部品の一覧（SBOM、ソフトウェアの部品表）を持たず、何を使っているか分からない企業は、修正の波に乗れないという差がはっきり出ます。どの部品のどの版を使っているかを把握しているかどうかが、守りの速さを分けます。

また、自社がオープンソースを公開している企業であれば、自社の事業が対象になりうるか、社員が業務として申し込む場合の許可の手続きをどうするかを、先に決めておく必要があります。規約が所属組織の許可を求めている以上、担当者の判断だけで申し込める話ではありません。

修正版が増えたときの優先順位の付け方も、あらかじめ決めておくと慌てずに済みます。たとえば、社外から届く入力を直接扱う部品、認証や権限に関わる部品、多くの製品で共通に使っている部品を先に確かめる、といった順番です。修正版の公開を知ってから考えるのではなく、どの部品を先に追うかを平時に決めておくことが、AIによる発見が増える時代の備えになります。更新の告知に書かれた重大度も、提供元や保守者の判断であり、自社の使い方での影響は自社で見積もる必要があります。

申し込みを検討するときに確かめること

自社が保守するオープンソースについて OSS Scanner の利用を考える場合、次の順で確かめておくと、後からの手戻りを防げます。

企業が取るべき対策

OSS Scanner を使うかどうかにかかわらず、AIによる脆弱性の発見が広がる中で企業が取るべき対策は共通しています。第一に、自社が使うオープンソースの部品の一覧を整え、更新を追える状態にすることです。修正版の公開が増えたときに、影響のある製品と担当者がすぐ分かるようにしておきます。

第二に、脆弱性の報告を受け付ける窓口と、受け取った報告を仕分ける手順を決めておくことです。自社のオープンソースや製品に、AIが作った報告が外部から届く場面は今後も増えると考えられます。第三に、報告や修正案の扱いを社内の規程に書き込み、機密として扱う範囲と共有してよい相手を明確にします。

第四に、提供元を装う偽の報告や、報告に付いた修正案を名目にした不審な変更の提案に備え、送り主と内容を確かめる手順を設けます。第五に、外部のサービスにリポジトリや連絡先を登録する前に、何を渡すかを一覧にして承認を取る運用にします。点検を受けることと、点検の結果を安全に受け止めることは別の準備が要る、と考えておくのが現実的です。

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

OSS Scanner は、見つけるところから報告を書くところまでを言語モデルが担うサービスです。だからこそ、脆弱性かどうか、どれだけ深刻か、どう直すかの判断をAIに任せないことが前提になります。AIに任せてよいのは、候補を広く拾い、再現の手がかりや修正の候補を用意するところまでです。

人が決めるのは、報告を本物と認めるか、重大度をどう付けるか、修正案を採るか、利用者にいつどう知らせるかです。そのために、報告に付いた再現の手がかりと根拠の説明を、人が実際に確かめることを手順に入れます。人が確認する範囲（たとえば重大度「高」以上はすべて人が再現する、など）も先に決めておくと、報告が増えても判断がぶれません。避けたい使い方を挙げます。

• 報告に書かれた重大度を、そのまま利用者への告知や優先度の判断に使う
• 付いてきた修正案を、査読や試験を通さずに取り込む
• 報告のメールを個人の宛先で受け、誰が読んだか分からないまま放置する
• 報告を、事業の権限ある保守者以外の社外の協力者に転送する
• 報告が来なかったことを、事業に脆弱性がない証拠として説明する

脅威の想定の文書を整えておくことも、AIの判断のぶれを減らす手段になります。READMEは、重大度の付け方の方針や、どこから信頼できない入力が入るかを書いておくことを勧めています。判断の物差しは人が決めて渡し、AIには根拠を示させるという役割分担が、報告を活かす近道です。

よくある質問：報告で問題が見つからなければ安全と言えるのか

答えは「言えない」です。規約は、報告が脆弱性を見逃すことがあると明記しています。点検は外部につながらない環境で、提供された構築の手順の範囲で行われるため、本番の設定や運用の仕方によって生まれる弱点まで見ているとは限りません。点検に使う言語モデルや仕組みが変われば、結果が変わる可能性もあります。

では受ける意味がないのかというと、そうではありません。定期的に同じ事業を点検し直す仕組みなので、新しく入り込んだ問題を早めに拾える可能性があります。「安全の証明」ではなく「弱いところの候補を早く知る手段」として位置づけ、従来の査読や試験、ほかの点検の手段と組み合わせるのが現実的です。

もう一つ、「自社のオープンソースでなくても申し込めるのか」という問いもありそうです。規約上、申込者は中心の保守者かその許可を得た人に限られ、申込は人が確かめるとされています。利用しているだけの部品を、利用企業が勝手に申し込むことは想定されていません。利用企業にできるのは、使っている部品の保守者が出す修正版や告知を確実に受け取り、自社への影響を見積もることです。

• OSS Scanner の仕組み・申込の条件・報告の扱い・規約の内容は、GitHubのリポジトリ（README）、サービスの説明ページ、規約のページ、提供元の発表を2026年10月21日に確かめた範囲に基づきます。サービスは始まったばかりで、内容は変わる可能性があります
• 提出した情報や報告が学習に使われるかどうか、適用される法律、依存部品との区別の仕組みの精度は、確認した一次情報の範囲では確かめられませんでした
• この記事は守りと評価の目線で書いています。申し込みの手順、設定ファイルの書式、手元での確認の道具の使い方は扱いません

まとめ

OSS Scanner は、Anthropic が重要なオープンソースを隔離した環境で構築し、外部につながない状態で言語モデルが定期的に点検して、見つけた脆弱性を再現の手がかりや修正案とともに保守者へ届ける無料サービスです。GitHubのリポジトリはApache-2.0で公開されていますが、中身は申込の窓口で、利用には独自の条件を含む規約が伴います。

報告は人の確認を経ずに届き、重大度の過大評価や誤りがありうると提供元自身が認めています。申し込むと連絡先は公開され、報告は機密として扱う義務を負い、社員として保守している場合は組織の許可が要ります。申し込む前に、報告を受け取る人・確かめる手順・公開してよい情報の範囲を決め、AIの指摘は人が根拠を確かめてから判断することが、このサービスとの現実的な付き合い方です。利用企業の側でも、部品の一覧を整え、増えうる修正版を追える備えをしておくことが求められます。

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