言語モデルで脆弱性を探し、検証で誤検知を絞り込むOSS「OpenAnt」を解説

「AIでコードの脆弱性を探せる道具が次々に出ているが、指摘が多すぎて結局人が全部見直すことになるのではないか」「検出したものを実際に攻撃して確かめると聞くと、社内で動かしてよいのか判断がつかない」——自社開発のシステムを抱える企業のセキュリティ担当者から、こうした声を聞くようになりました。言語モデルを使った脆弱性探しは、見つける力の話として語られがちです。しかし現場で効くのは、見つけた候補のうち、どれが本物かを絞り込む仕組みのほうです。この記事では、検出に加えて「本当に悪用できるか」を確かめる段階を持つOSS「OpenAnt」を取り上げ、仕組みの考え方、公開されている数字の読み方、検証の段階を社内で扱うときに守るべき条件を整理します。導入や操作の手順は扱いません。

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

OpenAntは、GitHubで公開されているOSSです。READMEでは、言語モデルを使って脆弱性を見つけ、修正まで支援するもので、防御側が確かめられた欠陥を、誤検知と見逃しの両方を抑えながら見つけることを助けると説明されています。見出しの言葉は「第1段階で検出し、第2段階で攻める。生き残ったものが本物だ」というものです。

公開元は、Knosticという企業の組織アカウントです。このラインの精査を行った2026年10月20日時点で、組織のアカウントは2023年9月に作られ、公開リポジトリは9件でした。OpenAntのリポジトリは2026年2月26日の作成で、最後の更新は10月19日。スターは779、派生は120で、1日あたりのスターの伸びは約3.3件です。ライセンスはApache-2.0で、商用を含めて使える条件です。

READMEは、もともと研究の計画として始まったもので、新しい機能は試験版として出すことが多いと断っています。研究の内容は2026年6月にarXivで論文として公開されました。対応する言語は、Go、Pythonなど3つが正式、ほかの6つが試験版とされています。Knostic自身は、主な事業はAIエージェントや開発用のAIの保護であり、脆弱性研究そのものではないため、OSSとして無償で公開したと説明しています。

なぜ言語モデルによる脆弱性探しが注目されるのか

コードの脆弱性を探す方法として、これまでは静的解析（プログラムを動かさずにソースコードを読んで問題を探す方法）と、ファジング（大量の想定外の入力を与えて異常を探す方法）が中心でした。論文の冒頭は、静的解析は誤検知が多く、ファジングは大がかりな設備が要るうえ、狙える欠陥の種類が限られると整理しています。

言語モデルは、コードの意味を読み取って推論できます。ただ、リポジトリ全体に当てはめると、読ませる範囲、費用、そして指摘が正しいかの確かめ方が課題になる、と論文は述べています。とくに最後の点について、運営元のブログは、言語モデルに「これは悪用できるか」と尋ねるだけでは相手に合わせて「できる」と答えがちで、誤検知が増えると指摘しています。

同じ時期には、大手のAI企業も同種の仕組みを出しています。READMEは、OpenAIのCodex SecurityやAnthropicのClaude Code Securityの名前を挙げ、それらと競うつもりはないと書いています。OpenAntの位置づけは、オープンソースの保守者が攻撃者より先に欠陥を見つけるための道具だということです。運営元は、オープンソースのプロジェクトを無償で調べる受付も設けています。

コードを小さな単位に分け、外から届く部分に絞る

運営元のブログによると、OpenAntはまずコードを「単位」に分けます。単位とは、関数などのまとまりに、それを呼ぶ側と呼ばれる側の情報を添えたものです。言語モデルが、その部分だけを見ても悪用できるかどうかを判断できるだけの文脈を持たせるための工夫だとされます。

次に、外部からの入力を受け取る入口からたどって、実際に届くコードだけを残します。この絞り込みは言語モデルを使わない処理で、費用はかかりません。論文は、これで調べる範囲を最大97％減らせたと報告しています。ブログに載ったOpenSSLの例では、15,232の単位が390まで減りました。

この発想は、防御側の考え方とよく合います。外部から届かないコードの欠陥は、悪用の経路がないか、あっても優先度が下がります。限られた費用と人手を、外から届く部分の欠陥に集中させる設計です。ただし、入口のたどり方が漏れれば、届くはずの部分も外れてしまいます。論文も、大きな関数や深い呼び出しの連なりは読み切れない場合があると限界に挙げています。

第1段階：疑わしい箇所を見つける

絞り込んだ単位に対して、言語モデルの助けを借りた分類が行われます。ブログによると、まず各単位が外部にさらされているのか、内部だけで使われるのか、守りの仕組みそのものなのか、どれでもないのかを、呼び出し元をたどりながら判定します。そのうえで、外部にさらされている単位について、上位の言語モデルが脆弱性の疑いを挙げます。

READMEによると、処理の段階ごとに使う言語モデルを選べます。Anthropic、OpenAI、Googleの各社のもののほか、Bedrock経由のもの、複数の会社のモデルを一つの窓口で使える中継サービス、手元で動かすOllamaにも対応します。推奨は、検出や検証には推論の強いモデルを、報告づくりなどには軽いモデルを使う組み合わせとされています。

ここで押さえておきたいのは、解析のためにソースコードが、設定した言語モデルの提供元に送られるとREADMEに明記されていることです。外部のサービスを使う設定なら、自社のコードが社外に出ます。手元で動かすモデルを選べばその心配は減りますが、READMEは、小さなモデルでは道具を使う処理がうまく動かない場合があるとも書いています。

第2段階：本当に悪用できるかを確かめて誤検知を減らす

OpenAntの特徴は、第1段階の候補をそのまま報告しない点です。運営元のブログによると、第2段階では、言語モデルが攻撃者の立場で、その欠陥に外部から実際に到達して悪用できるかを吟味します。このとき、攻撃者が最初から持っていない権限を前提にしないよう条件をつけ、外部から起こせない欠陥は「悪用できない」として外す、とされています。目的は一つで、「理屈の上では危ないが、現実には起こせない」指摘を落とすことです。

さらに、残った候補は動的な検証にかけられます。論文によると、言語モデルが再現のための環境を用意し、それを隔離したコンテナ（他から切り離した小さな実行環境）の中で動かし、終わったら捨てます。コンテナは読み取り専用で、使える記憶領域や処理能力、時間に上限を設け、権限を上げられない条件で動かすと説明されています。

つまり、OpenAntの検証は「攻撃して確かめる」と表現されていても、その狙いは報告の確からしさを上げ、人が見直す量を減らすことにあります。一方で、検証のために再現のコードを生成し実行する以上、どのコードを対象にし、どの環境で動かすかは、使う側が厳しく管理する必要があります。この点は後の章で詳しく扱います。

修正の案をつくる機能と、人が判断する範囲

READMEには、見つかった欠陥や既知の脆弱性に対して、修正の案をつくる機能も載っています。対象のコードの中で根拠を確かめ、修正の計画を立てて案をつくり、別の視点で反論を試み、最後に「信頼の報告書」を書く流れだとされます。報告書は、検証の後に適用してよい、人の確認が必要、適用しない、のように結論から書かれます。

注目したいのは、作りの上での歯止めです。READMEによると、修正の案は対象のリポジトリには決して直接当てられず、一時的な複製にだけ当てられます。本番に反映するかの判断は人に残すと明記され、報告書の推奨も、モデルの自己申告の自信ではなく、決められた方針に沿って決まるとされています。

READMEは限界も率直に書いています。同じ処理をくり返しても言語モデルの結論が変わりうること、反論役も同じモデルが担うため、同じ盲点を共有しうること。そのため、この機能は人による見直しの代わりではなく、判断を助ける材料だと位置づけています。「適用してよい」という結論が出ても、脆弱性が直ったことの証明にはならないとも書かれています。

公開されている数字をどう読むか

運営元と論文は、いくつかの数字を公表しています。論文によると、8つのプロジェクトで第1段階が挙げた候補は376件、第2段階で190件に絞られ（約半分を除外）、そのうち144件、約76％が隔離環境で再現されました。8プロジェクト分の費用は合計で約1,461ドルと報告されています。

対象（論文の報告）	第1段階の候補	第2段階で残った件数	隔離環境で再現	費用の目安
OpenSSLの事例	28件	3件	1件	約443ドル
Flowiseの事例	129件	85件	64件	約229ドル
WordPressの事例	67件	20件	13件	約244ドル
8プロジェクトの合計	376件	190件	144件	約1,461ドル

読み方には注意が要ります。製品の紹介の頁は「誤検知を最大99.98％なくす」とうたっていますが、ブログの数字を見ると、これは入口からの絞り込みを含めた、調べる対象の減り方に当たるもので、誤検知の割合を他の道具と比べた結果ではありません。論文も、他の道具との誤検知率の比較はしていません。

費用も一様ではありません。ブログは、単位の数はコードの大きさに比例しないため事前に見積もるべきで、実際の費用は当初の見積もりのほぼ倍になることもあると書いています。また、絞り込みをしなければ数千ドルから数十万ドルかかりうるという試算も示されています。OpenSSLについて、ブログでは確認済みの脆弱性を3件としていますが、論文の表では再現は1件で、資料によって数え方が異なる点も押さえておきます。

従来の静的解析と何が違うのか

OpenAntの位置づけを、従来の静的解析の道具と比べて整理します。確認できた資料の範囲での比較で、優劣ではなく役割の違いとして読んでください。

比べる点	従来の静的解析	OpenAnt
判定のしかた	決められた規則や型との照合	言語モデルがコードの意味を読んで推論
誤検知の扱い	人が一件ずつ見直すことが多い	悪用できるかの吟味と隔離環境での再現で絞り込む
結果の安定性	同じ入力なら同じ結果	くり返すと結論が変わりうる
費用	道具の費用が中心	言語モデルの利用料が対象の大きさに応じてかかる
コードの送り先	多くは社内で完結	外部の言語モデルを使えば社外に送られる
実行を伴うか	伴わない	検証の段階で再現のコードを生成し実行する

表のとおり、OpenAntは静的解析の置き換えというより、静的解析では判断のつきにくい「この指摘は本当に危ないのか」に答える層を足すものと考えるのが妥当です。規則で確実に見つけたい欠陥は従来の道具で押さえ、OpenAntの結果は優先度づけの材料として重ねる組み合わせが現実的でしょう。

また、結果の揺れも意識しておく必要があります。従来の道具なら、前回と今回の結果の差はコードの変更で説明できます。言語モデルを使う道具では、コードを変えていなくても指摘が出たり消えたりする可能性があります。社内の判断の記録には、いつ、どのモデルで調べたかを残しておくことが大切です。

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

このラインでは、紹介するOSSを公開されている事実だけで精査しています。OSSを入手したり動かしたりはしていません。OpenAntの判定は「注意付き」です。

問題が見つからなかった点から挙げます。ライセンスはApache-2.0で、利用の条件に独自の制限はありません。公開元は2023年から活動している企業の組織アカウントで、論文の著者も明らかです。GitHub上にこのリポジトリのセキュリティ勧告は登録されておらず、取り込んだだけで自動的に動く処理も確認されませんでした。スターの伸びも1日あたり約3.3件で、不自然な水増しの兆候は見られませんでした。

注意付きとした理由は、道具の性質にあります。OpenAntは、検出した欠陥が本当に悪用できるかを確かめる段階を持ち、そのために再現のコードを生成して実行します。対象と権限の管理を誤れば、許可のない相手への攻撃や、社内環境への悪影響につながりうるということです。なお、勧告がないことや問題が見つからなかったことは、安全の保証ではありません。精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。

運営の体制と、まだ整っていない点

READMEには、責任ある使い方についての断り書きがあります。このプロジェクトは防御と研究の目的に限ったもので、自分が所有するコードか、調べることを明確に許可されたコードだけを対象にするよう求めています。他者のプロジェクトで見つけた欠陥は、関係者と調整したうえで公表する手順を踏むよう求め、悪用について運営側は責任を負わないとしています。

一方で、整っていない点もあります。2026年10月20日時点で、リポジトリには脆弱性の報告の窓口を定めたセキュリティ方針の文書が置かれておらず、正式なリリースも登録されていません。未解決の課題は58件ありました。研究の計画から始まり、多くの機能が試験版という状態で、版を固定して検証し、変更を追う運用は利用者の側で用意する必要があります。

ブログで確認できる範囲では、隔離環境で動かす段階について、隔離の詳しい作りまでは説明されていませんでした。論文には記憶領域や時間の上限などの条件が書かれていますが、その条件が現在の版でも同じかは、確認した資料からは分からない状態です。運営元は管理された版の提供も予告していますが、内容や価格は公開されていません。

悪用されうるリスク

OpenAntは防御を目的に公開された道具ですが、仕組みの上では、他人のコードの欠陥を探して悪用できるかを確かめることにも使えてしまいます。READMEが対象を自分のコードか許可のあるコードに限るよう求めているのは、そのためだと考えられます。公開されたOSSのコードは誰でも読めるため、攻撃者が同種の道具で公開ソフトの欠陥を先に見つける可能性は前提にしておくべきです。

社内で使う場合の危険もあります。次に挙げるのは推測ですが、検討の材料になります。一つは、検証の段階で生成されたコードが、隔離の不十分な環境で動いてしまうことです。もう一つは、外部の言語モデルに送ったソースコードや、生成された報告書そのものが、自社の弱点の一覧として流出することです。報告書には、悪用できると判定された箇所がまとまって書かれるからです。

さらに、言語モデルの提供元の鍵の扱いも論点になります。READMEによると、鍵は利用者の手元の設定ファイルに保存され、所有者だけが読める権限で置かれます。鍵が漏れれば、利用料の不正な消費につながりえます。なお、OpenAntが実際に悪用された事例は、2026年10月20日時点で確認した一次情報からは見つけられませんでした。

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

検討するときは、動かす前に、資料と社内の取り決めで確かめられる点から整理します。下の手順は、OSSを動かす前の段階で終えられるものに絞っています。

この手順の要は、対象・送り先・環境・承認の四つを、動かす前に人が決めることです。道具の側の歯止めは、使う側の取り決めの代わりにはなりません。

企業が取るべき対策

一つ目は、脆弱性を調べる道具の利用規程を整えることです。OpenAntに限らず、言語モデルで脆弱性を探す道具は今後も増えます。対象にしてよいコード、使ってよい言語モデル、検証を動かしてよい環境を、道具ごとではなく、種類としてまとめて規程にすると、新しい道具が出るたびに判断し直す手間が減ります。

二つ目は、報告書を機密として扱うことです。悪用できると判定された箇所の一覧は、攻撃者にとって最も価値のある情報の一つです。保管場所、閲覧の権限、保存の期間を、脆弱性情報の扱いの決まりに合わせます。三つ目は、修正までの流れとつなげることです。見つけた欠陥が直るまでの期限と担当を決めておかなければ、検出の精度が上がっても守りは強くならないからです。

四つ目は、外部からの攻撃の速度が上がる前提で備えることです。同種の道具は攻撃者も使えます。自社が使うオープンソースの部品の更新を早く当てる体制、外部に公開している部分の把握を見直します。五つ目は、調達のときの確認です。セキュリティ方針の文書や正式なリリースがないこと、多くの機能が試験版であることを踏まえ、社内で使える段階かどうかを文書で判断します。

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

OpenAntは、言語モデルに欠陥を探させ、言語モデルに吟味させ、言語モデルに修正の案まで書かせる道具です。だからこそ、AIに判断させない部分を先に決める必要があります。

具体的には、どのコードを対象にするか、検証をどの環境で動かすか、修正を本番に反映するか、見つけた欠陥を誰にどう知らせるか。この四つはAIにも道具にも委ねず、人が決めて記録に残します。指摘ごとに、なぜ悪用できると判断したのかという根拠を書かせ、人が後から確かめられるようにしておくと、誤った判定の傾向もつかめます。人が確認する範囲を先に決めておかなければ、指摘の山はただ積み上がるだけです。やってはいけない向き合い方を挙げます。

• 許可を得ていない他者のコードや、取引先のシステムを対象にする
• 検証の段階を、本番の環境や社内の網につながった端末で動かす
• コードを社外に送ってよいかを確かめずに、外部の言語モデルを設定する
• 修正の案の「適用してよい」という結論だけを見て、人の見直しなしに反映する
• 再現できなかった指摘を、安全が確かめられたものとして扱う
• 報告書を共有の場所に置き、誰でも読める状態にする

裏を返せば、人が決める範囲ははっきりしています。何を調べ、どこで確かめ、誰が反映を決め、どう知らせるか。この四つが決まっていないまま道具を入れても、守りの厚みは増えません。

よくある質問：検証を通った指摘は、すべて本物の脆弱性なのか

答えは「そうとは限らない」です。論文自体が、言語モデルの推論に頼るため欠陥の種類によって得意不得意があること、競合状態（処理の順番によって起きる不具合）や複数の機械にまたがる欠陥は隔離環境で再現しにくいことを限界に挙げています。また、ブログは、生成された再現の試験が欠陥を確かめていても、試験の組み立て方そのものが弱い場合があると認めています。

逆の方向にも注意が要ります。論文は、悪用に失敗したことは、脆弱性がないことの証明にはならないと明記しています。第2段階で外された指摘や、再現できなかった指摘の中に本物が残っている可能性はあります。OpenAntの結果は、優先度をつけるための材料であり、合否の判定ではありません。

では入れる意味がないのかというと、そうではありません。数多い指摘の中から、外から届き、悪用の道筋が説明できるものを先に見られることは、限られた人手で守る組織には確かな助けになります。まずは自社の小さなリポジトリで、従来の道具の結果と見比べながら、当たり外れを自社の記録で確かめるのが無理のない入り方でしょう。

• OpenAntの機能・処理の考え方・数字は、GitHubのリポジトリとREADME、セキュリティの頁、運営元のブログと製品の頁、arXivの論文を2026年10月20日に確かめた範囲に基づきます。正式なリリースがなく、内容は変わる可能性があります
• 検証の段階の隔離の作りが現在の版でも論文と同じか、管理された版の内容と価格、他の道具との誤検知率の比較は、確認した一次情報の範囲では確かめられませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順や、検証の段階の中身は扱いません

まとめ

OpenAntは、コードを小さな単位に分けて外から届く部分に絞り、言語モデルで脆弱性の疑いを挙げたうえで、本当に悪用できるかを確かめる段階で誤検知を減らすOSSです。Apache-2.0で公開され、2023年から活動する企業が運営しています。GitHub上にセキュリティ勧告は登録されていません。

一方で、検証の段階では再現のコードを生成して実行し、解析のためにソースコードが言語モデルの提供元に送られます。セキュリティ方針の文書や正式なリリースはまだなく、公表された数字にも読み方の注意があります。対象は自社の資産か許可のあるコードに限り、隔離した環境で、承認を経て動かし、結果は人が見直すことが、OpenAntとの現実的な付き合い方です。

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