Anthropicは2026年10月8日、オープンソース向けの「OSS Scanner」を発表しました。参加するプロジェクトには、AIによる定期的なセキュリティ検査を無料で提供します。OSSとは、ソースコードを公開し、利用や改変を認めているソフトウェアのことです。［1］
保守を助ける可能性はあります。ただし、人間の確認が不要になるわけではありません。省略するのは、Anthropicが報告を送る前に行う人手での確認です。報告を受け取った保守担当者には、内容や修正案を確かめる役割が残ります。［2］［3］
AIが問題を何件見つけるかに加え、担当者が内容を確認し、修正版を届けるまでにかかる時間も評価する必要があります。公式資料と過去の事例をもとに、無料スキャンの利点と、受け手に残る負担を整理します。
OSS Scannerは何をしてくれるのか
OSS Scannerは、脆弱性が疑われる問題の再現手順と、可能な場合は修正案を保守担当者に届けるサービスです。公式リポジトリによると、検査対象のソフトウェアを隔離された仮想マシン上で構築し、その後、インターネットに接続できない環境へ移して検査します。結果は指定した連絡先にメールで届きます。［4］
仮想マシンは、検査用に用意した独立したコンピューター環境です。構築時には必要な部品をダウンロードできますが、検査時の通信は制限されます。ただし、この仕組みで報告内容や修正案の正しさが保証されるわけではありません。
参加するには、主要な保守担当者が申請する必要があります。公式GitHubリポジトリに対象コードの場所や連絡先を登録し、検査環境の作り方を記した「Dockerfile」も用意します。［4］
対象となるのは、社会の基盤や利用者の安全に大きく関わるプロジェクトです。参加の可否は個別に判断されます。誰でも好きなコードを投入できる一般公開の検査サイトとは、利用の仕組みが異なります。［2］
97件中1件の誤検知——「約99％」だけでは評価できない
Anthropicは初期版の検証で、48プロジェクトから得られた97件の報告を専門家に確認してもらいました。対象は、AIが深刻度を「Critical」または「High」と判定した報告です。専門家による分類は次のとおりです。［5］
| 専門家による分類 | 件数 | 97件に占める割合 |
|---|---|---|
| Anthropicの協調的な脆弱性開示の基準を満たした | 85件 | 87.6％ |
| 実在する問題だが、既知の問題や他の報告と重複していた | 11件 | 11.3％ |
| 無効な報告・誤検知だった | 1件 | 1.0％ |
出典：Anthropicの公式発表。割合は本記事で「件数÷97×100」を計算し、小数第1位に丸めました。丸め処理のため、合計は100％になりません。
問題が実在した報告の割合は96÷97で約99.0％ですが、開示基準を満たした報告の割合は85÷97で87.6％です。両者には約11.3ポイントの差があります。既知の問題や重複した報告でも、受け手には内容の確認や、過去の報告との照合が必要です。
この検証だけでは、すべての報告の精度は分かりません。脆弱性をどれだけ見逃したかも不明です。同社は、深刻度を過大に評価した例や、想定される攻撃条件を誤解した例があったことも認めています。［5］
無料でも作業時間は必要——週6時間なら何件受けられるか
スキャン料金がゼロでも、報告の確認や修正案の検証には時間がかかります。その負担を考えるため、保守担当者が検査結果への対応に使える時間を週6時間と仮定します。
報告1件の初期確認にかかる時間は、15分と仮定します。以下は実測値ではなく、負担の大きさを説明するための試算です。修正や公開にかかる時間は含めていません。
| 週に届く報告 | 初期確認に必要な時間 | 週6時間の枠に残る時間 |
|---|---|---|
| 10件 | 2.5時間 | 3.5時間 |
| 20件 | 5時間 | 1時間 |
| 40件 | 10時間 | 4時間不足 |
計算式は「報告件数×15分÷60」です。週6時間をすべて初期確認に使った場合、処理できる上限は24件です。実際には修正作業も必要なので、無理なく受けられる件数はさらに少なくなります。
仮に初期確認を5分に短縮できれば、上限は72件になります。これもOSS Scannerの実績ではありません。再現手順を分かりやすくしたり、重複した報告をまとめたりすることで、対応できる件数が大きく変わることを示す計算です。
確認したい指標は、報告1件の確認にかかる時間と、未処理の報告数です。精度が高くても、毎週届く件数が処理能力を超えれば、重要な報告への対応も遅れる可能性があります。
GoogleやGitHubの検査と何が違うのか
OSS Scanner、OSS-Fuzz、Dependabot、CodeQLは、検査する対象と方法が異なります。今回確認した公式資料には、同じ条件で性能を比較したものはありません。下表は役割を比較したもので、精度のランキングではありません。
| サービス・機能 | 主な役割 | 使う側が確認すること |
|---|---|---|
| Anthropic OSS Scanner | AIがコードを検査し、脆弱性が疑われる問題と再現手順を報告する | 報告の妥当性、攻撃条件、修正案の影響 |
| Google OSS-Fuzz | 大量の入力を与える「ファジング」で不具合を探す | 検査対象の設定、見つかった不具合の原因と修正 |
| GitHub Dependabot alerts | 利用中の外部パッケージに既知の脆弱性があるか知らせる | 影響するバージョン、更新後の互換性 |
| GitHub CodeQLによるコードスキャン | コードの構造を分析し、脆弱性や誤りを探す | 指摘の妥当性、検査範囲、修正の影響 |
出典：Anthropic公式リポジトリ、Google OSS-Fuzz、GitHub Docs。右列は、各機能の役割に基づいて本記事で整理したものです。［4］［6］［7］［8］
たとえば、外部パッケージの古いバージョンを使っている問題と、自社コードで権限チェックが抜けている問題は別です。一つの検査を導入しただけで、両方を十分に確認できるとは限りません。
OSS Scannerを導入するからといって、既存の検査を止めるかどうかは慎重に判断する必要があります。重複する指摘をまとめながら、異なる種類の問題を探す検査を組み合わせるのがよいでしょう。
curlの過去事例——報告の質が上がっても負担は増える
通信ソフトウェア「curl」の開発者Daniel Stenberg氏は、2026年4月22日の記事で、報告の質が上がると同時に件数も増えた状況を説明しました。質の低い報告への対応に悩まされていた時期を経て、今度は質の高い報告が大量に届くようになったとしています。［9］
同氏によると、当時の報告頻度は2025年の約2倍でした。脆弱性と確認された報告の割合も、15〜16％程度に回復したと説明しています。これは当時のcurlの状況であり、OSS Scannerの検証結果と直接比較できる数字ではありません。
誤報が減っても、保守の負担が減るとは限りません。本物の問題が増えれば、修正やテストの作業も増えます。報告の質が改善しても、人手不足は解消されない場合があるという事例です。
ただ、負担が増えるから検査を避けるべきだとも言い切れません。報告されなかった問題を、攻撃者が先に見つける可能性もあります。判断する際は、対応にかかる時間が増えることと、重大な問題を早く直せる利点の両方を考える必要があります。
送付が早くても修正は遅れる——三つの時間に分けて考える
安全性への効果は、報告が届く速さに加えて、修正を公開するまでにかかる総時間で評価する必要があります。本記事では、その時間を「送付まで」「受け手の着手待ち」「確認・修正」の三つに分けます。
次の表は、同じ問題に対応する二つの仮想ケースです。Anthropicの実測結果ではありません。人による事前確認を省いて送付が早まっても、受け手の対応が混み合えば、その効果が相殺される場合を示しています。
| 工程 | 事前確認を経て送付する場合 | 確認前に送付する場合 |
|---|---|---|
| 発見から送付まで | 3日 | 0日 |
| 保守担当者が着手するまで | 1日 | 4日 |
| 確認・修正・公開まで | 2日 | 3日 |
| 合計 | 6日 | 7日 |
この例では、送付は3日早まります。しかし、受け手の待ち時間と確認作業が増えるため、修正の公開は1日遅れます。逆に、すぐに着手でき、修正案を短時間で検証できるチームなら、早く報告が届く利点を生かせます。
この試算からは、全プロジェクトへ一律に導入するよりも、受け手の対応能力に合わせて選ぶ必要があると考えられます。Anthropicは、従来どおり人が確認した報告を送る仕組みも継続するとしています。［5］
未確認の報告には、一律の90日公開期限を設けません。ただし、後から従来の仕組みで人が確認した場合は、その通知から90日を起点として公開する可能性があります。将来、方針が変わることもあり得るため、「永久に非公開」とは解釈できません。［2］
Google OSS-Fuzzは、原則として通知から90日後か、修正が公開された後の、いずれか早い時点で問題を公開します。期限の延長などにも条件があります。両者は検査方法に加え、報告後の扱いも異なります。［10］
保守担当者は「再現できるか」と「攻撃に使えるか」を分けて確認する
問題を再現できても、一般利用者への攻撃につながる条件まで確認できたことにはなりません。以下は、届いた報告を整理するために本記事が提案する確認表です。実際の判断では、各プロジェクトがどのように使われているかを踏まえる必要があります。
| 確認すること | 具体的な問い | 判断に役立つ情報 |
|---|---|---|
| 対象 | 配布中のバージョンでも起きるか | 対象バージョン、設定、問題を生じさせた変更 |
| 攻撃条件 | 外部の人が問題のある処理を呼び出せるか | 必要な権限、入力経路、標準設定での影響 |
| 重複 | 既知の問題や別の報告と原因が同じか | 既存の報告、原因となるコード、修正予定 |
| 修正 | 問題を防ぎつつ、正常な使い方も維持できるか | 再現テスト、既存テスト、互換性の確認 |
たとえば、外部から送られたデータで処理が止まる場合と、管理者が特殊な設定をしたときだけ止まる場合では、対応の優先度が変わることがあります。AIが付けた「High」という表示だけで順番を決めると、この違いを見落とす可能性があります。
Anthropicの利用条件にも、AIが深刻度を誤って判定したり、機能を壊す修正案を出したりする可能性が明記されています。報告に基づいてコードを変更する前に、参加者が内容と修正案を確認する責任も定められています。［3］
修正案は、問題を再現するテストと、普段の動作を確認するテストの両方で確かめたいところです。報告された再現ケースだけに対処する変更では、別の経路に問題が残ったり、正常な処理まで止めたりするおそれがあります。
利用者への影響——発見から更新までつながって初めて役立つ
一般利用者が恩恵を受けるには、見つかった問題が修正され、その修正版が利用環境に届く必要があります。スキャンが無料になっても、パソコンやサーバーが自動的に安全になるわけではありません。
企業でOSSを使っているなら、採用している部品とバージョンを把握し、セキュリティ情報を受け取れるようにしておく必要があります。個人利用者は、普段使うソフトウェアに更新がないか確認しましょう。検査サービスが発表されたことだけを理由に、特定のソフトを危険だと決めつける必要はありません。
保守担当者は、まず対応にかかった時間と未処理件数を記録すると、導入の効果を判断しやすくなります。本記事では、初期確認にかかる時間、重大な問題の修正が完了するまでの時間、未処理件数の三つを併せて確認することを提案します。
負担が処理能力を超えるなら、報告の受け取りを一時停止する選択肢もあります。公式の案内では、設定の「disabled: true」で停止を申請できます。参加を取りやめた場合は、通常の、人が確認した報告を受け取る方式に戻ります。［2］
OSS Scannerには、無料で検査を増やせる利点があります。その成果を修正につなげるには、再現手順の質を高め、受け手が対応する時間を確保する必要があります。導入の成否は、発見数に加え、重要な問題をどれだけ早く直せたかで判断することになります。
関連ページ
AIの指摘をどう評価するか、報告の増加にどう対応するかは、次の記事でも解説しています。
出典・計算条件
公式に公開された数値と、本記事の仮定に基づく試算は区別しています。情報の確認日は2026年10月10日です。97件の割合は、公式に公表された件数から計算しました。週6時間・1件15分および5分の試算と、修正公開までの日数は、実測値ではありません。
- Anthropic（2026年10月8日）：Introducing the Anthropic Cyber Mission
- Anthropic：OSS Scannerの概要・FAQ
- Anthropic：OSS Scanner Agreement
- Anthropic：OSS Scanner公式GitHubリポジトリ
- Anthropic（2026年10月8日）：Launching an opt-in vulnerability-finding service for open-source software
- Google：OSS-Fuzz公式ドキュメント
- GitHub Docs：Dependabot alerts
- GitHub Docs：Code scanning
- Daniel Stenberg（2026年4月22日）：High-Quality Chaos
- Google：OSS-Fuzz Bug Disclosure Guidelines
コメントを送信