Semgrepとは？AIで脆弱性の検出と誤検知の仕分けを支える米国企業

コード検査ツールが出す大量の指摘から直すべきものを選ぶ作業は、セキュリティ担当者と開発者の負担です。米国のSemgrepは、製品ページによると、ルールに基づく静的解析にAIの判断を組み合わせ、脆弱性の検出、指摘の仕分け、修正案の作成を支援しています。

国：米国。情報確認日：2026年11月1日。

Semgrepが扱う課題と製品の構成

製品紹介ドキュメントでは、Semgrepについて、コードを実行せずにソースコードの脆弱性を見つけるセキュリティツールと説明しています。提供機能は、静的アプリケーションセキュリティテスト（SAST）、オープンソースの依存関係の脆弱性を調べるソフトウェア構成分析（SCA）、認証情報の露出の検出です。同じ資料によると、オープンソースのCommunity Editionは30以上、商用のSemgrep AppSec Platformは35以上のプログラミング言語に対応しています。

中心となるSemgrep Codeは、パターン照合とデータフロー解析を記述したルールでコードを検査し、ルールに合う箇所を指摘として報告します（Semgrep Codeの説明）。 AIを使う機能は、Semgrep Multimodalとしてまとめられています（Multimodalの説明）。検査結果には、AIによる検査とルールによる検査のどちらで見つかったかが表示されます（AI検査の手順書）。 2026年3月のリリースノートによると、従来のSemgrep Assistantは、この時にSemgrep Multimodalへ名称が変わりました。

AIが担う範囲と人が確認する工程

下の表では、AIへの入力をデータの扱いに関する資料、出力と確認方法をMultimodalの説明、AI検出の概要、Autofixの説明に基づいて整理しました。

機能	AIへの入力	AIの出力	人の作業
指摘の自動仕分け	指摘に関係するコードと最小限の周辺の文脈	無視してよいかの提案と、その理由	提案を確認して判断する
修正ガイダンス	上記に加え、Memoriesに登録した指示	手順付きの修正方法	開発者が修正する
AIによる検出	ファイル全体、アップロードした資料、検査に関するメタデータ	IDORなどの指摘	結果を慎重に確認する
Autofix	検出したパターンと周辺のコード、修正ガイダンス	下書きのPRと変更の説明	レビューしてマージを判断する

指摘の仕分けと修正案

Multimodalの説明によると、AIはプログラミング言語やライブラリの知識、自社のコード、過去の仕分け履歴を使って、指摘を無視してよいかを提案します。無視を勧める場合は、理由の説明を添えます。提案はプルリクエスト（PR）やマージリクエスト（MR）のコメントにも表示されるため、開発者はPRの画面を離れずに判断できます。自動分析の対象は、全体検査では、重大度がCriticalかHighで、確度がHighかMediumの新しい指摘です。 PRやMRで差分を検査する場合は、1回につき新しい指摘を最大10件まで自動で分析します。

ベータ版のノイズ除去機能は、AIが誤検知の可能性があると判断した指摘について、PRへのコメントを出しません。除外された指摘は、セキュリティ担当者が専用画面で確認できます。担当者がAIの判断に同意すると指摘は閉じられ、同意しなければ再び開かれます。

修正面では、手順付きの修正ガイダンスと、コードの差分を含まない修正提案（Suggested fix）を表示します。 Memoriesに組織の方針を指示として登録すると、以後の修正ガイダンスに反映されます。 Multimodalの説明は、コードに秘密情報が直接書かれていた場合に、自社で使う秘密情報の管理ツールに合わせた修正方法を示す例を挙げています。

同社は評価方法の資料で、PRなどで利用者が付けた高評価と低評価の集計を公表しています。 2025年8月21日時点の集計では、AIの提案に人が同意した割合を96%、AIがノイズとして除外したSASTの指摘を平均60%としています。同じ資料は、社内のセキュリティエンジニアによる評価で、AIが誤検知と判断した場合に正しかった割合を96%としています。ただし資料は、この値がすべての誤検知を見つけられるという意味ではないと注記しています。これらは同社の集計で、gennaiが独自に検証した数値ではありません。

ルールでは捉えにくい脆弱性のAIによる検出

AI検出の概要では、静的解析と大規模言語モデル（LLM）の文脈理解を組み合わせ、業務ロジックの欠陥を見つける機能と説明しています。対象は、所有者の確認が欠けているために他人のデータを操作できてしまうIDOR（安全でない直接オブジェクト参照）や、認可の不備、必要な手順を飛ばせてしまう処理の流れなどです。 IDORの検出には各アプリの認可やデータベースの扱いを理解する必要があるため、汎用的なルールを書くのは難しいと同資料は説明しています。 Semgrep Codeの説明によると、この検出では、ルートやコントローラーなど攻撃の入口になる箇所を洗い出し、認証や権限確認の欠落を調べ、レビューが必要な箇所として示します。管理者が設計資料や脅威モデルをアップロードすると、AIによる検査の追加の文脈として使われます（AI検査の手順書）。

AI検出の概要では、確率的な推論に基づく検出のため、同じ検査を繰り返しても同じ結果になるとは限らないと明記しています。同資料は、結果を慎重に確認する必要があるとしています。現時点では全体検査のみに対応し、AIによる指摘の重大度は一律で「高」になり、独自ルールは使えません。検査はSemgrepが管理する環境で行われ、自社のCIで検査している場合も、リポジトリがその環境に複製されます（AI検査の手順書）。

Autofixと、AIコーディングエージェントとの連携

Autofixの説明によると、Autofixでは、AIが修正コードを生成し、ブランチを作って下書きのPRまたはMRを開きます。利用者が指摘の詳細画面で実行を選ぶか、APIを呼び出したときに動き、レビューとマージの判断は利用者が行います。修正案の生成には2〜10分かかり、PRにはAIが作成した変更の説明が付きます。利用には、ブランチを作るためのリポジトリへの読み書き権限と、Anthropic Claudeのモデルを含むAmazon Bedrockの利用承諾が必要です。

Semgrep Guardianの説明では、AIコーディングエージェントが書いたファイルを、開発者の端末上でSemgrepの検査にかける仕組みを紹介しています。指摘が見つかるとエージェントに返され、コードを作り直すかどうかはエージェントが判断します。この仕組みでコードを書くのはエージェント側のAIで、Guardianは書かれたコードを検査する役割を担います。

gennaiの見立てでは、PRでのコード確認にAIを使う製品を比べる場合、Qodoと並べて、AIが判断する範囲と人が判断する箇所の違いを確認すると整理しやすくなります。

日本の開発組織から見る導入条件

データの扱いに関する資料によると、AI機能を使うと、ソースコードの一部がOpenAIやAmazon BedrockなどのAI処理事業者へ送られます。 AIによる検出では、ファイル全体の内容やアップロードした資料も送信対象になります。 AI処理事業者へ送ったデータは、データを保持しない契約に基づいて処理後に削除されると同社は説明しています。一方、Semgrep側ではAIによる検出の元データを最大6か月保存します。保存を減らしたい組織向けには、任意の最小データ保持方針も用意しています。自社のAWSアカウントやAzure OpenAIなど自前の契約を使う方式もありますが、AIによる検出では使えません。

gennaiの見立てでは、日本の企業がまず確かめたいのは、ソースコードを社外のAI処理事業者へ送ることが社内規程で認められるかです。確認した公式資料では、日本語による説明文や修正案の生成、日本国内でのデータ保存について記載を見つけられませんでした。 Autofixはリポジトリへの書き込み権限が必要なため、権限の範囲と、PRを承認する担当者を先に決めておく必要があります。

評価の際は、AIが除外した指摘の件数だけでなく、除外が誤っていた件数と、担当者が確認に使った時間を分けて測ると、自社に合うかを判断しやすくなります。 AIによる検出は結果が毎回同じとは限らないため、同じリポジトリを複数回検査し、指摘のばらつきも確かめると実態をつかみやすくなります。 Semgrepを評価する出発点は、いまの検査で担当者の時間がどこに使われているかです。誤検知の仕分け、修正方法の検討、ルールで捉えにくい認可の不備のうち、どこを減らしたいかを分けて試すと、効果を判断しやすくなります。