2026年8月4日
Snykプラットフォームサブスクリプション
Snykプラットフォームサブスクリプションについて
Snykプラットフォームサブスクリプションは、Snykプラットフォームの機能を利用量に応じて課金するライセンスです。これらの機能を利用すると、以下に記載する料金表および測定単位に基づき、事前購入済み残高からクレジットが差し引かれます。事前購入済みクレジット残高を使い切った後の利用分は、オンデマンド利用として請求されます。
クレジット料金表
機能 | クレジット消費率 | 測定単位 |
Code | 1.0クレジット | アクティブコントリビューター1人・1日あたり |
Open Source | 1.0クレジット | アクティブコントリビューター1人・1日あたり |
IaC | 0.33クレジット | アクティブコントリビューター1人・1日あたり |
Secrets | 0.66クレジット | アクティブコントリビューター1人・1日あたり |
AI-SPM | 0.66クレジット | アクティブコントリビューター1人・1日あたり |
Container | 0.33クレジット | 監視対象イメージ1件・1日あたり |
API and Web | 3.0クレジット | プロビジョニング済みターゲット1件・1日あたり |
Coding Agent Security | 1.0クレジット | アクティブマシン1台・1日あたり |
AI Pentesting | 4,000クレジット | アセスメント1件あたり |
「アクティブコントリビューター1人・1日あたり」の計算方法
「アクティブコントリビューター1人・1日あたり」で測定されるプラットフォーム機能のクレジット消費量は、その機能が監視するすべてのリポジトリにおけるアクティブコントリビューター数の日次集計によって決まります。消費は監視を開始した日に始まり、リポジトリが監視対象から削除された翌日に終了します。1日の一部だけ監視されたリポジトリも、1日分のクレジットを消費します。
アクティブコントリビューターとは、直近90日間にSnykが監視するプライベートリポジトリへコミットした、ユーザーまたはお客様に代わって活動する一意のコントリビューターです。人間の場合も、人間以外の場合もあります。たとえば、従業員、独立請負業者、エージェント、サードパーティ製ボット、自動化システム、サービスアカウントなどが含まれます。<snyk-bot@snyk.io>など、Snykネイティブの自動化ボットはこの数に含まれません。
リポジトリは、組織にインポートされ、そのプロジェクトの少なくとも1つが当該機能でアクティブになっている場合に、その機能によって監視されます。機能用のプロジェクトを作成すると、ステータスはアクティブに設定され、非アクティブ化されるまで維持されます。特定の日に積極的なスキャンが実行されていなくても、リポジトリは監視対象としてカウントされます。
特定の機能におけるアクティブコントリビューター数を数えるため、Snykはその機能が監視するすべてのリポジトリで各コントリビューターをユーザー名によって識別します。一意のユーザー名1つにつき、監視対象リポジトリに何件登場するかにかかわらず、アクティブコントリビューター1人としてカウントされます。
Snykは、コントリビューターのメールアドレスを小文字に変換し、余分な空白を削除し、サブアドレス(プラス記号、および解析されたユーザー名とドメインの間にあるすべての文字を含む)を除去し、ドメインを削除することでユーザー名を導出します。重複排除ロジックは、標準的なメールエイリアスやGitHubおよびGitLabで使用されるプライベートno-replyアドレスなど、同一人物を示す一般的なバリエーションも認識し、1つのユーザー名に統合します。以下の例は、異なるメール形式がどのようにユーザー名へ変換されるかを示しています。
Snykは、正確なアクティブコントリビューター測定を回避するためにユーザー名の操作やその他の身元情報パターンが使用されていると合理的に判断した場合、アカウントアクティビティおよびコントリビューターの身元情報データを確認する権利を留保します。
重要な注意事項:
個人用メールアドレス:Snykは個人用メールアドレスを企業用メールアドレスに確実に関連付けることができないため、個人用メールアドレスから導出されたユーザー名はアクティブコントリビューターとしてカウントされます。
IPアドレスのドメイン:ドメインがIPアドレスであるメールアドレスはユーザー名に変換されず、メールアドレス全体が1人のアクティブコントリビューターとしてカウントされます。
シナリオ | メールアドレスの例 | アクティブコントリビューターのユーザー名 |
|---|---|---|
標準ドメインのメールアドレス | john.doe@snyk.io | john.doe |
GitHubプライベートメールアドレス | 12345678+jane.doe@users.noreply.github.com | 12345678 |
GitLabプライベートメールアドレス | 12345678+john.doe@users.noreply.gitlab.com | 12345678 |
メールエイリアス(プラスアドレス) | jane.doe+qatest@gmail.com | jane.doe |
IPアドレスのドメイン | root@192.0.2.5 | root@192.0.2.5 |
2つのメールアドレスを持つユーザー | mike.smith@snyk.io | mike.smith |
例:

「監視対象イメージ1件・1日あたり」の計算方法
Containerのクレジット消費量は、特定の日に確認された監視対象イメージ数に基づきます。監視対象イメージとは、その日にSnykへインポートされた、同期済みレジストリで確認された、またはCLIやIDEでテストされた一意のコンテナイメージで、開いているContainerプロジェクトを持つものです。一意のコンテナイメージはSHA-256ダイジェストで識別されます。Snykは、アカウント内で何件のプロジェクト、組織、グループが参照しているか、またその日に何回スキャンされたかにかかわらず、各一意のイメージを1日1回だけカウントします。
監視対象イメージは、開いているContainerプロジェクトによって監視されている日にクレジットを消費します。Containerプロジェクトは、削除またはアーカイブされるまで開いた状態です。暦日の一部でも開いているContainerプロジェクトを持つ監視対象イメージは、その日の1日分のクレジットを消費します。消費は、Containerプロジェクトが削除またはアーカイブされた翌日に停止します。プロジェクトは、監視ステータスが非アクティブとして設定されるとアーカイブされ、これにより自動の日次スキャンとセキュリティアラートが直ちに一時停止します。Containerプロジェクトの削除、プロジェクトのアーカイブ、またはレジストリの同期解除によりイメージは監視対象から外れ、翌日から消費が停止します。削除されたイメージも、削除された当日の測定には含まれます。一意のイメージに関連付けられた開いているContainerプロジェクトがない場合、そのイメージは監視対象外となり、その日のクレジットは消費されません。
プロジェクトを作成しないCLIでの監視対象外テストによる一回限りのテストは、監視対象イメージの測定には含まれません。Dockerfileスキャンはイメージ数とは別に扱われ、測定には寄与しません。dockerfile-scanプロジェクトは監視対象イメージではなく、この測定単位では消費しません。DockerfileスキャンはEnterprise Snykプラットフォームサブスクリプションに含まれます。
コンテナイメージのSHA-256ダイジェストは、重複排除における一意性の唯一の基準です。1つのダイジェストは、アカウント内で参照するタグ、リポジトリ、プロジェクト、組織、グループの数にかかわらず、1回だけカウントされます。同じタグを共有していても、異なるダイジェストに解決される2つのイメージは別々のイメージです。可変タグが新しいダイジェストで再構築されると、新しい監視対象イメージが作成されます。重複排除はアカウント全体で行われます。アカウント配下のすべての組織およびグループにある全プロジェクトは、カウント前に日ごとに1つの一意なダイジェスト集合へ統合されます。
「プロビジョニング済みターゲット1件・1日あたり」の計算方法
API and Webのクレジット消費量は、アカウント内のプロビジョニング済みターゲット数に基づきます。消費はターゲットが追加された日に始まり、削除された翌日に終了します。1日の一部だけプロビジョニングされたターゲットも、1日分のクレジットを消費します。
プラットフォームで定義された一意のベースURLごとに、プロビジョニング済みターゲット1件として扱われます。管理者は、API and Webプラットフォームの[Targets]セクションでプロビジョニング済みターゲットを表示および管理できます。

ターゲットを削除すると、その記録は破棄され、復元できません。
プロビジョニング済みターゲットには、さまざまなスキャン種別へのアクセスが含まれます。
スキャン種別 | 定義 |
標準スキャン | ターゲットアプリケーションの攻撃対象領域全体を網羅することを試みる、包括的なセキュリティテストです。 標準スキャンでは、ターゲットURLからアクセス可能なページをマッピングします。 |
縮小範囲スキャン | アプリケーションの攻撃対象領域の定義された一部に焦点を当てる、対象を絞ったセキュリティテストです。 縮小範囲スキャンは、スキャン設定で定義された特定のURL、パス、または領域に限定されます。 |
増分スキャン | 新規または更新されたURLのみをスキャンする部分スキャンです。 増分スキャンには、ベースラインとして完了済みの標準スキャンが必要です。 |
再テスト | 修正が正常に適用されたことを確認するため、脆弱性を再テストするマイクロスキャンです。 再テストでは、特定の脆弱性に対する特定のエンドポイントをスキャンし、修正が有効だったかをすばやく確認できます。 |
「アクティブマシン1台・1日あたり」の計算方法
Coding Agent Securityのクレジット消費量は、1日にSnykが確認したアクティブマシン数に基づきます。アクティブマシンとは、AIエージェントを実行するエンドユーザーデバイスまたは仮想環境のいずれかで構成される開発者向け環境です。次の対象テレメトリーイベントのいずれかがその日に発生した場合、そのマシンはアクティブです。
Agent Scan:環境のスキャンが完了した場合。
Agent Guard:サポート対象エージェントからの代表的なフックイベント(preToolUseフック)。
同じアクティブマシンで特定の日に両方のテレメトリーイベントが確認された場合、Snykは測定上、そのアクティブマシンを1回だけカウントします。アクティブマシンは、その日に対象イベントのいずれでどれだけのテレメトリーが確認されたかにかかわらず、1日につき1回請求されます。マシンはアクティブな日にのみクレジットを消費します。対象テレメトリーイベントが発生しない状態で丸1日が経過した場合、そのマシンはアクティブとしてカウントされず、その日のクレジットも消費しません。マシンのアクティブ状態は、以前にアクティブだった他の日とは独立して決定されます。
Snykは、アクティブマシンを2種類に分類します。
エンドユーザーデバイス - Snykフックバンドルが、MDM登録、手動インストール、スクリプトによるプロビジョニングなど、任意のデプロイ方法でインストールされたノートパソコン、デスクトップ、またはワークステーション。
仮想環境 - dev containerテンプレート、ワークスペースイメージ、または同等のプロビジョニング成果物を介してSnykがインストールされた、コンテナベースまたはVMベースのクラウドホスト型ワークスペース(例:GitHub Codespaces、Gitpod/Ona、Coder、JetBrains)。
Snykは、安定した一意のOSレベルのハードウェア識別子に基づいてエンドユーザーデバイスをカウントします。Snykが使用する具体的な識別子はプラットフォームによって異なります(macOSではIOPlatformUUID、WindowsではSMBIOS / Win32_ComputerSystemProduct.UUID、Linuxでは/etc/machine-id)。一方、仮想環境は、ワークスペースインスタンス自体ではなく、クラウドプラットフォーム所有者のログイン、ユーザー名、またはプリンシパルID(プラットフォームに応じて該当するもの)の一意かつ安定した識別子によってカウントされます。そのため、1人の開発者が1日に仮想環境(クラウドプラットフォーム所有者識別子自体)内で複数の一時的なワークスペースを起動しても、アクティブマシンは1台としてカウントされます。ただし、同じ開発者がエンドユーザーデバイス上と仮想環境上の両方でCoding Agent Securityを実行している場合、Snykは測定上、これを2つの一意で独立した単位、すなわち2台のアクティブマシンとしてカウントします。さらに、1人の開発者が複数の異なる仮想環境(CoderとJetBrainsなどの異なるプラットフォーム間、または同一プラットフォーム内の複数のログイン)でCoding Agent Securityを実行する場合、その開発者のアクティビティは一意のログイン識別子ごとに測定され、各識別子が別個のアクティブマシンとなります。Snykは、エンドユーザーデバイスと仮想環境の両方におけるアクティブマシン数の合計を測定し、Coding Agent Securityにおける顧客の1日の総クレジット消費量を算出します。
「アセスメント1件あたり」の計算方法
AI Pentestingのクレジット消費量は、完了したアセスメント数に基づきます。アセスメントとは、単一のアプリケーションに対してSnykのAIペネトレーションテストエージェントを完全に実行することを指し、そのアプリケーションが呼び出す関連マイクロサービスおよびアセスメントの一環として実行される修正後の再テストも含みます。
アプリケーションとは、アセスメントで評価されるターゲットです。プライマリWeb URL、追加のスコープ内URL、許可リスト、拒否リスト、およびユーザー認証情報によって定義されます。マイクロサービスとは、アプリケーションが呼び出す追加のバックエンドサービスまたはAPIであり、実行中に観測されたコールグラフによって特定され、テストで実行されます。これらすべてのマイクロサービスは1件のアセスメント料金に含まれ、マイクロサービスごとの個別料金は発生しません。
修正後の再テストは、Assessmentで特定された脆弱性をユーザーが修正した後、その修正を確認するために、ユーザーがエージェントに同じ脆弱性の再テストを促すことができる、後続のワークフローです。再テストの結果、その脆弱性は修正済みであることが確認されるか、脆弱性が残存している場合は、再テストのワークフローを繰り返すことができます。再テストは既存のAssessmentの脆弱性に固有のものであり、「Assessment単位」の料金における当初の請求イベントの一部として含まれ、新たなイベントとして請求されることはありません。
Assessmentの完全なライフサイクルには、ユーザーによる開始、ターゲットの検証、脆弱性テスト、リスク分析、レポート作成が含まれます。Assessmentは、Snykまたはユーザーによってキャンセルされず、Scan Failureにもならなかった場合にのみ完了します。請求対象の使用量としてカウントされるのは完了したAssessmentのみであり、失敗したスキャンはそのカウントから除外されます。
Scan Failureは、試行されたAssessmentが完了しなかった場合に発生します。失敗の想定ケースには、認証情報の不足、ターゲットに到達できないこと、WAFによるブロックなどがあります。Scan Failureに対する料金は発生しません。
各Assessmentでは、単一のApplicationとそのセカンダリURLをテストします。固有のテスト深度が必要な特に複雑なターゲットの場合、完了したレポートで、より深く専用のテストを行う価値のある攻撃経路が示されることがあります。これらを追求する場合は、お客様が実行を選択する別個のAssessmentとなります。テスト段階では、Snykは2,000米ドル相当のトークン推論上限を適用します。Assessmentがこの上限に近づくと、エージェントは追加の分析が必要な領域を特定し、それらの領域をレポートに記載したうえで、フォローアップAssessmentを推奨します。当初のAssessmentは、完全なAssessmentレポートとともに完了します。お客様は、フラグが付けられた領域を別個の請求対象Assessmentとして追求することを選択できます。
テスト上限
Snyk製品には、該当するOrderに記載され、さらにこのページで詳しく説明されているテスト上限が適用される場合があります。
クレジット利用ポリシー
Snyk Platform Credits(「Credits」)は、Snykの製品およびサービスに対して発行されるサブスクリプション割当および限定的なライセンス許諾の一部です。CustomerがCreditsを使用すると、Snykは該当するサービスに必要なCredits数をCustomerのCredit残高から差し引きます。Creditsは、該当するOrderの期間内に使用する必要があり、その後、未使用のCreditsは失効し、引き換え、返金、またはクレジット付与を受けることはできません。Creditsは現金と引き換えることはできず、譲渡もできません。Customerの前払いCreditsを使い果たした場合、Snykは、Rate Cardに定める適用されるCredit消費料率および該当するOrderに定めるCustomerのCredit単価に基づき、Customerの前払いCredit割当を超えて消費されたCreditsについてCustomerに請求書を発行することがあります。