Skip to main content

Snykの開発者エクスペリエンスを支える5つの原則

prioritize the security backlog

2026年3月26日

0 分で読めます

AIを活用した開発の時代において、スピードはもはや前提条件です。しかし、AIエージェントがコーディングのペースを速める一方で、セキュリティ上のボトルネックのリスクも高めています。Snykは、この新たな領域を安全に切り拓く唯一の方法は、優れた開発者エクスペリエンス(DX)だと考えています。DXは単なる製品の付加機能ではありません。開発者がAIイノベーションを安全に推進するための基盤です。

私たちは、DXを、積み重なっていく意思決定の体系だと捉えています。開発者がプラットフォームをどれだけ効果的に活用できるかは、あらゆる操作、デフォルト設定、そして目にする情報によって左右されます。

Snykプラットフォームの進化と改善を重ねる中で見いだした5つの原則は、優れたDXを実現するための基盤となっています。この原則は、製品全体にわたる何千もの細かな意思決定を継続的に導き、この取り組みを続けていくという私たちの姿勢を示しています。

1. 開発者が働く場所に行き、こちらに来るよう求めない

開発者向けツールでよく見られる課題は、洗練されたダッシュボードこそが主な利用場所だという思い込みです。しかし実際には、開発者は長年かけて最適化してきた既存のワークフローを優先します。IDE、ターミナル、Gitのフロー、プルリクエスト(PR)のプロセスなどです。こうしたワークフローから別の場所に切り替えることには、大きなコストが伴います。

Snykでも、これを身をもって経験しました。Snykプラットフォームに、優先順位付けされた脆弱性リスト、修正ガイダンス、完全なデータフロートレースを備えた詳細な検出結果画面を構築しました。しかし、開発者はそこを訪れませんでした。コンテキストの切り替えが必要であれば、どれほど価値のあるデータでも見過ごされがちだと分かったのです。セキュリティ情報を既存のPR上のやり取りに移すことで、開発者の自然な作業の流れに合わせました。

私たちはモデルを変えました。開発者にSnykへ来てもらうのではなく、Snykを開発者のもとへ届けるようにしたのです。セキュリティ上の検出結果をプルリクエスト上のやり取りに組み込み、コードレビューが行われているのと同じスレッド内で、SCMに直接表示しました。情報は同じでも、コンテキストの切り替えはゼロ。導入状況は大きく変わりました。

Snyk Code、ライセンス、セキュリティの各チェックに合格し、マージ競合がなく、緑色の「プルリクエストをマージ」ボタンが表示されたGitHubのプルリクエスト画面。

この原則はPRにとどまりません。IDEプラグイン、AIコーディングアシスタントやCLIとの連携、CI/CDのゲートに多大な投資をしているのもそのためです。私たちが常に考えるのは、開発者がすでに作業している場所はどこか、そしてそこにどう入り込めるか、ということです。

従来のIDEから、エージェント型開発環境への大きな移行が進んでいます。AIコーディングアシスタントがもたらす開発速度のもとでは、エージェントの生産性が高まるほど、作業の流れを中断するコストも増すため、コンテキストの切り替えがより大きなボトルネックになります。エージェント型プラットフォームが開発者のワークフローの中核となる中、Snykはすでにそうした環境に統合され、AIが生成したコードを開発の初期段階から保護しています。

2. 開発者はセキュリティの専門家ではない。開発者の言葉で伝える

PR上のセキュリティ検出結果を設計する際、私たちは開発者の思考に合わせて最適化しました。CVSSスコアやCWE分類はセキュリティの専門家には理解しやすくても、開発者にとっては説明が必要な専門用語でした。

Snyk独自のデータフロー分析から生成した、状況に即した自然な言葉による説明を表示します。たとえばSQLインジェクションの脆弱性なら、一般的なアドバイザリを引用するのではなく、HTTPリクエスト本文からの未サニタイズのユーザー入力がSQLクエリ文字列に直接埋め込まれていることを、開発者自身のコードにおける入力元、出力先、その仕組みを明示して説明します。

JavaScriptコード内のSQLインジェクション脆弱性に警告を出すSnykボット。サニタイズされていないユーザー入力がデータベースクエリに直接埋め込まれており、セキュリティリスクとなっています。

この一文で、セキュリティの専門家ではないことも多い開発者に、問題の内容と場所(正確なファイル名と行番号)を、すでに理解している言葉で伝えられます。詳しく確認したい人向けに、完全なトレースも引き続き利用できます。しかし、ほとんどの開発者はそこまで深く掘り下げる必要はありません。行動に移すために必要なことを理解できればよいのです。

Snyk製品のあらゆる画面で、この原則を適用するよう努めています。「この開発者が、今この時点で、持っている知識を踏まえて理解すべきことは何か?」に答えることを目指しています。

3. あらゆる情報はシグナルかノイズかのどちらか。その中間はない

セキュリティツールでは、あらゆる情報を表示しがちです。網羅的に見えますが、役立つどころか、情報過多を招くことも少なくありません。PRでの体験を検証した際、私たちは問いを捉え直しました。開発者が目にする情報として、本当に必要なものは何か?

私たちは表示する情報を慎重に選ぶことにしました。表示内容はワークフローに応じて変わります。予防の段階では、開発者には迅速に実行できるガイダンスが必要です。修正の段階では、リスク低減を重視する開発者に、より深い情報と複数の選択肢が必要です。PRでは、すべての情報が、差し迫った疑問への回答か、明確な次のステップにつながるものであるべきです。PR上の開発者は機能をリリースすることに集中しているため、この文脈は非常に重要です。脆弱性の解消は二次的な課題になります。問題の修正が主な作業となるバックログの場合とは大きく異なります。

段階的な情報開示も、このバランスを取るのに役立ちます。メイン画面では問題、その深刻度、次のステップに焦点を当てます。必要に応じて、より深い階層でデータフローなどの追加情報を確認できます。これにより、体験を明確に保ち、余計な情報を排除できます。

4. 製品の価値は検出ではなく、解決にある

長い間、セキュリティツールは検出件数で成果を測っていました。脆弱性を多く見つけるほど、ツールがより網羅的に感じられたのです。しかし、この指標では本当に重要なこと、つまり脆弱性が修正されたかどうかが見落とされていました。

ほとんどの開発者が求めているのは、問題を知ることではありません。次に何をすべきかを知ることです。明確な次のステップがない脆弱性レポートは、深刻度スコアが付いただけのノイズにすぎません。開発者がそれをノイズとして扱うようになるのも、もっともなことです。

PRの体験に修正案を直接組み込んだのは、脆弱性を特定するだけでなく、ワークフローから離れることなく修正できるよう、解決までの一連の流れを完結させるためです。Snykがコード内の脆弱性を検出したとき、単に警告を表示するだけではありません。AIが生成した具体的な修正案を差分として提示し、PR内にレビューコメントとしてインライン表示します。削除する行は赤、追加する行は緑で示され、ワンクリックでコミットに適用できます。

SQLインジェクション脆弱性に対するSnyk AIエージェントの修正提案。差分では、Node.jsのsqlite3データベース呼び出しにおいて、安全でない文字列補間をパラメータ化クエリに置き換える様子を示しています。

SQLインジェクションの例では、文字列の埋め込みを警告して解決方法を開発者に委ねるのではなく、AI Fixの提案でパラメーター化クエリに置き換えます。開発者が安全なSQLの実践方法を調べる必要はありません。修正案がすでに用意されているからです。解決への道筋が、デフォルトの道筋になります。

優れたDXは問題の修正方法を伝えます。さらに優れたDXは、修正をデフォルトの選択肢にします。

5. 開発者が何をするかだけでなく、なぜそうするかを理解すると、信頼が築かれる

修正案の提供を開始したとき、開発者からのフィードバックに繰り返し現れるパターンがありました。問われたのは「この修正は機能するか?」ではなく、「なぜこの修正でうまくいくのか?」でした。開発者は提案を適用した後、同僚に説明できずに困っていました。修正によって目の前の問題は解決したものの、別の問題が生じていたのです。

そこで、PRチェックの体験に加えたのが、結果として最も大きな効果をもたらした変更の一つとなった、提案した変更によって脆弱性が解消される理由を平易な言葉で説明する機能です。ドキュメントへのリンクでも、CVEへの参照でもありません。コードの具体的な内容に基づき、その修正がどのように脆弱性に対処するのかを説明します。

SQLインジェクションの例では、動的な文字列の埋め込みをパラメーター化クエリに置き換えることで、ユーザー入力を実行可能なコードではなくデータとして扱えること、そしてその違いによって脆弱性が解消される理由を説明します。

この2つの機能、つまり修正案とその説明を組み合わせることは、経験豊富なセキュリティエンジニアが同僚のコードをレビューする方法を反映しています。まず問題を理解していることを確認し、次に適切な実装例を示します。

信頼は、理由を示すことで築かれます。Snykが判断の根拠を説明するたびに、開発者は自分自身のセキュリティ感覚を養うための手がかりを得ます。それこそが、最終的に最も長く役立つ成果です。

優れた開発者エクスペリエンスは、偶然には生まれない

この5つの原則は、何がうまくいかなかったのかを見極め、その理由を理解し、アプローチを変える中で確立されました。

優れた開発者エクスペリエンスには、製品、エンジニアリング、デザインにわたる何千もの小さな意思決定を導く原則が必要です。AIと人間の開発者がより緊密に協働する未来に向け、こうした原則によって、セキュリティが障壁ではなく追い風であり続けるようにします。Snykは、一つひとつの意思決定、一つひとつの修正、一つひとつのデプロイの成功を通じて、常に改善に取り組んでいます。

Snykが築いてきた開発者エクスペリエンスが、プログラムの推進をどのように加速できるかをご覧ください。今すぐデモを申し込む。

AIが生成したコードのセキュリティ対策を始めましょう

無料のSnykアカウントを作成して、AIが生成したコードのセキュリティ対策を数分で始めましょう。または、専門家によるデモを予約して、Snykが開発者セキュリティのニーズにどう応えられるかをご確認ください。

続きを読む

Blog

フロンティアモデルは脆弱性を発見した。攻撃者だけがエクスプロイトチェーンを見つけた。

静的解析で欠陥は見つかりましたが、ライブ攻撃テストで侵害につながる連鎖を実証できたのは唯一でした。Evo COS、Claude Security、Claude Code Securityを比較します。

feature insights context
Blog

自律型攻撃はすでに始まっている。防御もそのスピードに追いつかなければならない。

自律型攻撃者によって、防御に使える時間は短くなっています。継続的な検出、修復、検証、予防で、セキュリティチームが攻撃に歩調を合わせる方法をご紹介します。

Blog

AIコーディングエージェントが不適切なアクセス制御を繰り返し実装する理由

AIコーディングエージェントは、コンパイルが通りレビューも通過する一方で、あるテナントのデータを別のテナントに公開してしまう認可ロジックを生成することがあります。不適切なアクセス制御が検出しにくい理由と、その防止策をご紹介します。