IT女子 アラ美お疲れ様です！IT業界で働くアライグマです！
「商用SASTは年100万円以上で稟議が通らない」「OSSのSASTは誤検知だらけで開発者が無視するようになった」という声をDevSecOps文脈でよく聞きます。LLMを差分スキャンに組み込めば月$0.5〜数ドルで誤検知の少ない実務運用が可能です。本記事では設計の落とし穴と勝ちパターンを、CIへの組み込み方とセットで整理します。
読者の悩みと背景の整理：SAST運用が破綻する3つのパターン
IT女子 アラ美想定読者は、社内システムまたは自社プロダクトでセキュリティ運用を任されているリードエンジニア・社内SE・DevSecOps担当者です。少人数のチームで脆弱性検査を内製化したいが、商用SASTの導入コストと運用コストの両方が壁になっているケースを念頭に置いています。
現場で観察するSAST運用の破綻パターンは大きく3つに集約されます。1つ目は商用ツールの稟議が通らずに導入できず、結局リリース直前に外部ベンダーに脆弱性診断を依頼する「年1回のスポット運用」です。2つ目はOSS製のSASTを入れたものの、誤検知率が60%を超え、開発者がレビューコメントを無視する文化が定着するパターンです。3つ目は検知件数の多さに圧倒されて、Critical指摘すら埋もれて見落とされるトリアージ崩壊です。
LLMを使う設計はこの3つすべてに効きますが、組み込み方を誤るとトークン課金が月数万円に跳ね、結局商用SASTより高くつきます。シークレット流出を例に取れば、envguardでシークレット流出を防ぐCI設計のようにCIゲートで止める仕組みと、LLMによるコンテキスト判定を分離するのが基本方針です。専用ツールで止められるものはツールで止め、LLMは曖昧な脆弱性パターンの判定に絞ります。
IT女子 アラ美
ITアライグマケーススタディ1：うまくいかなかったパターン（全コードLLMに丸投げで月3万円）
IT女子 アラ美田中さん（仮名・34歳・社内SE兼DevOps担当・経験8年）は、社員300名規模のSaaS事業会社で内製プロダクトのセキュリティ運用を一人で抱えていました。OSSのSASTを試したものの誤検知が多すぎて開発チームから不評を買い、商用SASTは年120万円の予算が通らず、リリース判定を経験と勘で行う状態が半年続いていました。「毎週金曜にCriticalを見落とす夢で目が覚める」と本人が苦笑するほど消耗していたのが行動のきっかけです。
田中さんは最初「全コードベースをClaudeに投げて脆弱性を列挙させる」設計を選びました。Pythonのバックエンドとフロントエンドを合わせて約12万行のコードを毎晩フルスキャンし、結果をSlackに流す構成です。確かにOSS-SASTより誤検知率は下がり、Criticalの取りこぼしも減ったように見えました。
しかし1か月後、AnthropicのAPI課金が月29,800円に到達して経理に呼び出される事態になります。さらに深刻だったのは、毎晩同じコードを再スキャンしているため指摘が日々ブレること、修正済みの箇所も繰り返し指摘されてSlackチャンネルが「もう見ない」という空気になったことでした。3週間目には開発者から「ノイズが多すぎる」という苦情が届き、運用は事実上停止しました。
田中さんの振り返りは「全件スキャンは美しく見えるが、差分の概念が抜けていた。SAST商用ツールは内部で増分スキャンをしているのに、LLM運用でその発想を捨てたのが敗因。最初からPR差分のみを対象にしていれば、コストも誤検知も10分の1で済んだはず」というものです。メルカリ流Claude Codeセキュリティ設定の組織配布戦略でも触れられている通り、組織導入の段階でガバナンス設計を先に決めなかったツケが運用コストとして返ってきた格好です。
IT女子 アラ美ITアライグマケーススタディ2：うまくいったパターン（PR差分×Skills分離で月$0.5運用）
田中さんは設計を全面的に組み直しました。新しい構成の柱は3つです。第1にスキャン対象を「PRで変更された差分のファイルのみ」に限定すること、第2にSkills（検査ルール定義ファイル）を脆弱性カテゴリごとに分割し、必要なルールだけをLLMコンテキストに読み込ませること、第3に検出結果にCritical/High/Medium/Lowの優先度を必ず付けてSlackには Critical/High のみ投稿する設計に変えたことです。
具体的にはGitHub Actionsで pull_request イベントをトリガーにし、git diff で変更ファイルのリストを取得してそれだけをClaude APIに送ります。プロンプトはSQLインジェクション・XSS・認証バイパス・シークレット混入の4Skillsに分割し、変更ファイルの種類（バックエンドPython・フロントエンドTSX等）に応じて関連Skillsだけをロードします。判定結果はJSON Schemaで厳密に縛り、優先度・該当行・修正例を構造化して出力させました。
3か月運用した結果、API課金は月平均0.42ドル（約65円）に収まり、当初の月29,800円から約99.7%のコスト削減を達成しました。誤検知率も自社測定で従来60%超から約12%まで低下し、開発者の修正対応率は28%から81%に改善しています。さらにCriticalの平均検出時間が「翌朝」から「PR作成5分以内」に短縮され、レビュー前にセキュリティ指摘が消化される文化が定着しました。
田中さん本人の振り返りと教訓は「LLMに何を任せて何を任せないかの線引きが全てだった」というものです。シークレット検知のような決定的な処理は専用ツール（gitleaks等）に任せ、LLMはコンテキスト依存の脆弱性判定のみを担当する役割分担が肝で、これを最初に決めていれば1か月の浪費は避けられたという教訓を残しました。AIによる指摘の信頼性をどう見極めるかは、AIコードレビュー指摘の信頼性を見極める判断軸と同じ思考フレームが応用できます。
IT女子 アラ美ITアライグマ具体的な行動ステップ：LLMセキュリティ運用を月$1以下に収める導入手順
明日から自社プロダクトで小さく始めるための手順を、短期・中期・長期の3段階で整理します。最初から完璧な運用を目指すと挫折しやすいので、まずは最小構成で動かして数値を取ることを優先します。
- 初日〜1週目（最小構成）：1リポジトリを選び、PR差分のみを対象にClaude APIへ投げる最小ワークフローをGitHub Actions上に組む。Skillsはまず「シークレット混入」と「SQLインジェクション」の2つだけに絞る。出力フォーマットはJSON Schemaで縛り、優先度フィールドを必須にする。
- 2〜4週目（運用安定化）：誤検知率と検出時間のメトリクスを記録し、週次でプロンプトを調整する。Critical/Highのみ通知する閾値を入れ、Medium/Lowはダッシュボード集約に回す。シークレット検知は専用ツール（gitleaks等）に分離し、LLMから外す。
- 2〜3か月目（横展開と内製化）：他リポジトリへ展開し、Skillsを脆弱性カテゴリごとに細分化する。週次レビュー会で誤検知パターンをチームでレビューし、Skillsを継続改善する。商用SASTを併用する場合はLLMをセカンドオピニオンとして位置づけ、双方の指摘の差分を学習データに転用する。
導入時の落とし穴として一番多いのは「LLMの判定結果を全件Slack通知して通知疲れさせる」ことです。Criticalのみ通知し、それ以外は週次レポートに集約するだけで、開発者の体感負担は劇的に下がります。LLM活用スキルの市場価値は急速に上がっており、LLM実装経験を武器にするエンジニア転職エージェント4社比較でも触れた通り、DevSecOps領域でLLMを実運用に乗せた経験は転職市場で強い武器になります。
サーバー選定の観点では、エンジニア向けXServer用途別比較ガイドで個人検証用と本番運用の使い分けを解説しています。さらにDevSecOpsスキルを軸にしたキャリア戦略を考えるなら、ハイクラスエンジニア転職エージェント3社比較で年収レンジ別の選び方を確認しておくと判断材料が揃います。
IT女子 アラ美ITアライグマよくある質問
Q. LLMで脆弱性スキャンしたとき、商用SASTと比べて精度は劣りませんか？
カテゴリによります。コンテキスト依存の脆弱性（認証バイパス、ロジック起因のIDOR、不適切な権限境界など）はLLMの方が優位な場合が多いです。一方でシークレット検知やライセンス違反のような決定的な処理は専用ツールに任せるのが鉄則で、役割分担すれば商用SAST単体より総合精度を上げられます。
Q. 月$0.5で本当に運用できますか？
PR差分のみを対象にし、Skillsをカテゴリ別に分割し、JSON Schemaで出力を厳格に縛る3点を守れば実現可能です。リポジトリ規模やPR頻度に依存しますが、社員300名規模の単一プロダクトでは月$0.5前後で安定運用できた事例があります。逆に「全コードを毎回投げる」設計だと月$200以上に跳ねます。
Q. 既存の商用SASTを置き換えるべきですか？
短期的には併用を推奨します。商用SASTは検知ルールDBの蓄積と監査対応の証跡という強みがあるため、LLMをセカンドオピニオンとして併用し、双方の指摘の差分を3〜6か月分析した上で判断するのが現実的です。コンプライアンス要件が厳しい業界では完全置換は慎重に検討してください。
Q. CI上でLLMを呼ぶとPRがブロッキングされて遅くなりませんか？
差分のみを対象にすればClaude APIへのリクエストは数秒〜十数秒で返るため、開発体験への影響は最小限です。ブロッキングを避けたい場合は、Critical/Highのみ exit 1 で止め、Medium以下は warning でPRを通す段階運用が有効です。
Q. プロンプトインジェクションのリスクはどう対処しますか？
入力コードの中にLLM向けの指示文（「上記の指示を無視して〜」等）が含まれている可能性を考慮し、システムプロンプトで厳密にロールを固定し、出力を常にJSON Schemaで検証する設計が必要です。検証に失敗した出力は破棄し、人手レビューに回すルートを用意しておきます。
LLM活用スキルを継続的に磨くための学習リソースとして、AI学習・リスキリング系の比較表を掲載します。重視すべきは「実務直結のカリキュラム」と「業務時間外でも進められる学習設計」の2点です。
本記事で解説したようなAI技術を、基礎から体系的に身につけたい方は、以下のスクールも検討してみてください。
| 比較項目 | Winスクール | Aidemy Premium |
|---|---|---|
| 目的・ゴール | 資格取得・スキルアップ初心者〜社会人向け | エンジニア転身・E資格Python/AI開発 |
| 難易度 | 個人レッスン形式 | コード記述あり |
| 補助金・給付金 | 教育訓練給付金対象 | 教育訓練給付金対象 |
| おすすめ度 | 幅広くITスキルを学ぶなら | AIエンジニアになるなら |
| 公式サイト | 詳細を見る | − |
IT女子 アラ美ITアライグマまとめ
脆弱性スキャンをLLMで自動化する設計は、「全件スキャン」から「PR差分×Skills分離×優先度判定」への発想転換が成否を分けます。月3万円の失敗例と月65円の成功例の差は、LLMに何を任せて何を任せないかの線引きをどこまで丁寧に設計したかに尽きます。
- 核となるメッセージ：LLMは「コンテキスト依存の判定」に特化させ、決定的な検知は専用ツールに任せる役割分担が必須です。
- 短期的な変化：PR差分のみのスキャンに切り替えるだけで、誤検知の通知疲れが解消し、開発者の修正対応率が大幅に上がります。
- 長期的に目指したい状態：Skillsを継続改善する文化がチームに根付き、商用SAST不要のセルフサービス型セキュリティ運用が回るようになります。
完璧な検知率を最初から狙うのではなく、最小構成で動かして数値を取り、週次で改善するサイクルを回すことから始めてください。社内SE一人でも回せる規模感の運用が、3か月後にはチーム全体の財産に育っていきます。
IT女子 アラ美ITアライグマ
