Snykとは？コードと依存関係の脆弱性を検出し、AIで修正案を作る開発セキュリティ
アプリケーションを開発するエンジニアやセキュリティ担当者にとって、コードや依存するオープンソースの脆弱性は、見つけた後の確認と修正にも手間がかかります。Snykは、ソースコードの脆弱性を検出し、AIが生成した修正候補を静的解析で検証してから開発者に示す仕組みを提供しています。
アプリケーションを開発するエンジニアやセキュリティ担当者にとって、コードや依存するオープンソースの脆弱性は、見つけた後の確認と修正にも手間がかかります。 Snykは、ソースコードの脆弱性を検出し、AIが生成した修正候補を静的解析で検証してから開発者に示す仕組みを公式ドキュメントで説明しています。
国：米国（2020年の公式発表の発信地による）。 情報確認日：2026年11月1日。 DeepCode買収の公式発表は米国ボストンを発信地としていますが、確認した資料では本社所在地の明記を確認できませんでした。
Snykが扱うコードと依存関係の脆弱性
Snykは公式ドキュメントで、従来の脆弱性対応では、開発者が指摘を1件ずつ確認し、修正方法を決め、適用し、結果を確かめる必要があると説明しています。 Snyk Codeの公式ドキュメントによると、Snyk Codeはソースコードを対象とする静的アプリケーションセキュリティテスト（SAST）の製品です。 IDE、リポジトリ、CI/CDパイプラインでコードをスキャンし、開発の流れの中で脆弱性を示すと同ドキュメントは説明しています。 同社は、AIを用いたエンジンによって開発者が受け取る誤検知が減ると同ドキュメントで説明しており、これは企業側の主張です。 検出した問題について、入力元から危険な処理に至るまでのデータの流れを段階的に表示する機能もあります（公式ドキュメント）。 このAIについて同社は「DeepCode AI」と呼び、記号的AIと生成AI、複数の機械学習手法、Snykのセキュリティ研究者の知見を組み合わせて知識ベースを作ると公式製品ページで説明しています。
依存関係については、Snyk Open Sourceを、オープンソースの依存関係の脆弱性をソフトウェア構成分析（SCA）で見つける製品と公式ドキュメントで位置づけています。 修正に関する公式ドキュメントでは、Snyk Open Sourceの修正方法として、パッケージのアップグレード、間接依存のバージョン固定、Snykのパッチを挙げています。 ソースコード管理サービスとの連携を設定すると、修正用のプルリクエストを開くこともできます（公式ドキュメント）。 確認した資料では、Snyk Open Sourceで依存関係の脆弱性を見つける工程そのものにAIを使うとの記載を確認できませんでした。 一方でDeepCode AIの製品ページでは、影響を受けるパッケージの普及度や、脆弱なコードへの到達可能性を評価するリスクスコアをDeepCode AIが支えると説明しています。
次の表は、Snyk Agent Fixの公式ドキュメントとRemediation Agentの公式ドキュメントに書かれたAIの役割を、gennaiが整理したものです。
| 機能 | AIへの入力 | AIの出力 | 人の作業 |
|---|---|---|---|
| Snyk Agent Fix | Snyk Codeが検出した脆弱性と、同じ種類の脆弱性の修正例 | 静的解析で検証された修正候補 | 候補をレビューして適用し、再スキャンする |
| Remediation Agent（早期提供） | Snyk Open Source、Snyk Code、Snyk Containerのスキャン結果 | 修正計画、依存関係のバージョン変更、ソースコードの修正 | 変更をレビューしてからマージする |
Snyk Agent Fixが修正案を作る工程
公式ドキュメントによると、DeepCode AI FixはSnyk Agent Fixに名称が変わり、2026年5月にエージェント型の構成へ更新されました。 Snyk Agent Fixは、Snyk独自のセキュリティ情報と大規模言語モデル（LLM）を組み合わせ、Snyk Codeが検出した脆弱性の修正コードを提示します（公式ドキュメント）。 同ドキュメントが示す工程は次のとおりです。
- 静的解析エンジンが、通常のスキャンで脆弱性を見つけます。
- 3万5,000件を超える、人が書いた修正例のデータベースから、同じCWE（脆弱性の種類の分類）の修正例を取り出します。
- LLMが、取り出した修正例を手がかりに複数の修正候補を生成します。
- 静的解析エンジンが、各候補で脆弱性が消え、新しい脆弱性が入っていないかを確かめます。
- 検証に失敗した候補は、エラーをエージェントへ戻して作り直します。
- 検証を通った候補を開発者に示します。
開発者はIDEのSnykパネルで「Generate AI fix」を選び、提案を確認して適用し、ファイルを保存して再スキャンで解消を確かめます（公式ドキュメント）。 利用前の準備として、VS Code、Visual Studio、Eclipse、JetBrains製IDE向けのプラグインが案内されています（公式ドキュメント）。 同ドキュメントは、提案がアプリケーション全体の設計と合っているかを人がレビューする必要があると明記しています。 修正の対象は1ファイル内の修正が中心で、複数のファイルにまたがる脆弱性は自動では修正しません（公式ドキュメント）。 セキュリティと機能の基準を満たす修正を作れなかった場合、提案は表示されません（公式ドキュメント）。 大きなファイルで再試行が重なると、最大2分ほどかかる場合があると説明しています（公式ドキュメント）。 Snyk Agent Fixは、顧客のコードを基盤モデルの学習、データセットへの追加、性能改善に使わないと説明しています（公式ドキュメント）。
ここからはgennaiの見立てです。 例えば、ユーザー入力を文字列連結でSQL文に埋め込んだコードが指摘された場合、開発者は、修正候補が入力をパラメータとして渡す形に変わっているか、呼び出し元の処理と矛盾しないかを確かめることになります。 静的解析の検証は脆弱性が消えたかを確かめる工程なので、業務上の動作が変わっていないかは、既存のテストやレビューで別に確認する必要があると考えられます。 試験導入では、提案が表示された割合、手を加えずに採用できた割合、レビューにかかった時間を分けて記録すると、自社のコードに合うかを判断しやすくなります。
Remediation Agentによる依存関係の修正
Remediation Agentの公式ドキュメントでは、スキャン、修正計画の作成、修正の適用、検証を自動で進める仕組みとして説明しています。 対象は使う場所で異なり、Snyk CLIではSnyk Open Source、Snyk Code、Snyk Containerのスキャン結果を扱います（公式ドキュメント）。 依存関係の修正ではバージョンを上げるか上書き設定を加え、ソースコードではSnyk Agent Fixの提案を適用し、コンテナではDockerfileを編集します（公式ドキュメント）。 適用後は再スキャンで解消を確かめ、単体テストなどアプリケーションの既存テストも実行します（公式ドキュメント）。 依存関係を変更する前には、そのバージョンアップでビルドが壊れる可能性をSnykが評価し、結果をエージェントに渡します（公式ドキュメント）。 この評価はプレビュー段階で、利用できないときはローカルの簡易な評価に切り替わります（公式ドキュメント）。
修正を実行する環境と人の確認は、公式ドキュメントで次のように分けられています。
| 使う場所 | 修正を実行する環境 | モデル | 人の確認 |
|---|---|---|---|
| コーディングアシスタント（Snyk Studio経由） | 開発者の開発環境 | アシスタントのスキルとして動作 | マージ前に変更を確認する |
| Snyk CLI | CLIを実行する環境 | 利用者が設定したモデル提供元 | 修正ごとに確認する（--auto-approve指定時を除く） |
| Evo by Snykの修正キャンペーン | Snykが運用する環境 | Snykが提供 | エージェントが開いたプルリクエストを確認してマージする |
コーディングアシスタントでは、ビルドを壊すリスクがないと評価された場合、エージェントが自動で修正を進めます（公式ドキュメント）。 CLIで設定できるモデル提供元として、Anthropic、OpenAI、Amazon Bedrock、Google Vertex、LiteLLMが挙げられています（公式ドキュメント）。 コーディングアシスタントとCLIからの利用は早期提供（Early Access）で、修正キャンペーンにはEvo by Snykが必要です（公式ドキュメント）。 同ドキュメントは、Remediation Agentが急速に開発中で、オプション名や既定値が変わる可能性があるとしています（公式ドキュメント）。
gennaiの見立てでは、依存関係の更新を自動化するほど、どこまでを人の確認なしで進めるかの線引きが導入の要点になります。 --auto-approveや自動修正を使う前に、既存テストがどこまで動作を守れるかを確かめておくと、レビューで見るべき変更を絞りやすくなります。
DeepCodeの買収と現在の位置づけ
Snykは2020年9月23日、AIを用いたリアルタイムの意味的コード解析を提供するDeepCodeを買収することで合意したと公式発表しました。 DeepCodeは、機械学習とプログラミング言語の研究者が創業したチューリッヒ工科大学（ETH Zurich）発の企業です（公式ブログ）。 同じ発表では、通常の完了前の条件を満たしたうえで、2か月以内に買収が完了する見込みとしていました（公式発表）。 確認した資料では、買収完了日、完了の発表、買収額、対価の種類、取得した持分の範囲を確認できませんでした。 公式ブログでは、DeepCodeの技術をSnykのプラットフォームに統合し、それまでのオープンソース、コンテナ、IaCに加えて、開発者が書く独自コードの解析に広げると説明していました。 現在、DeepCodeの名称は、Snyk AI Security Platformを支えるAI「DeepCode AI」として公式製品ページに残っています。 同ページは、学習データに寛容なライセンスのオープンソースプロジェクトと検証済みの修正を使い、顧客データは使わないとしています（公式製品ページ）。
日本の開発組織から見る導入条件
Snyk Codeの公式ドキュメントによると、Snyk Codeは対応する拡張子の4MB未満のファイルをまとめてSnykへ送信します。 Snykのサイトでは、Enterpriseプランの利用者向けに米国、EU、オーストラリアの環境が案内されており、データの保存地域は各地域の契約に従うと説明しています（公式サイト）。
ここからはgennaiの見立てです。 日本で使う前に、自社の言語やパッケージ管理が対応範囲に入るか、契約で選べるデータ保存地域、CLIで外部のモデル提供元を使う場合にコードがどこへ送られるかを確かめる必要があります。 同じくコードの脆弱性検出を扱うSemgrepなどと比べる場合は、検出数だけでなく、誤検知を除く手間と、修正候補をそのまま採用できた割合を自社のリポジトリで測ると違いが見えやすくなります。
Snykを評価する出発点は、脆弱性の発見から修正の確認までのどこに時間がかかっているかです。 検出、修正候補の生成、人のレビュー、テストによる確認を分けて測ると、自社の開発工程に合うかを判断しやすくなります。