【20260528 AI×DevOpsStudy #15】GitLab環境で脆弱性の検知からAIによる修正（MR作成）、チャット通知までを自動化する仕組み

■AI×DevOps Study #15 の概要
2026年5月28日に開催した「AI×DevOps Study」第15回のアーカイブ動画です。

「AI×DevOps Study」は、AI駆動開発やそこに関係するマイクロサービスについて理解を深める場になります。
株式会社ScalarではAIを使ったチーム開発を進めており、参画しているメンバーや協力会社の方から、具体的なAI駆動開発を実施する方法、その中で生まれたマイクロサービスアーキテクチャを使用したAI駆動開発の事例や実際に使えるエージェントについてお話頂き、参加者の皆様と知識の共有や交換を目的としています。
（弊社製品であるScalarDBも絡んだお話も一部出てきますが、汎用的な内容となっておりますのでフラットにお楽しみいいただけます）

■今回のテーマ
「GitLab環境で脆弱性の検知からAIによる修正（MR作成）、チャット通知までを自動化する仕組み」

アウトライン

1. イントロダクション.
・昨今のAIを取り巻く環境と脅威：Claude Mythos等のAI進化で悪用リスクが高まっており、脆弱性の早期検出と解決がより重要になっています。
・セキュリティ対応の課題： 昨今のセキュリティ事故増加を受け、開発の現場では、脆弱性の放置リスクや修正リードタイム短縮を新たな課題として認識しています。

2. 自動修正仕組み導入の前提条件.
・AI活用の最大化：AIツールを導入するだけでこのような仕組みを活用できるわけではありません。脆弱性検知に必要なツール、AIの修正影響度の限定が前提として必要になります。
・前提条件の提示：自動修正の仕組みを活用するにあたって必要な前提条件を、「ツール軸」と「アーキテクチャ軸」に分けて紹介します。

3. 脆弱性検出からAIによる自動修正.
・ジョブのスケジュール実行と動作担保： テストカバレッジによる既存動作の保証を前提とし、自動修正ジョブを他ジョブに干渉しないよう定期実行させる仕組みについて説明します。
・脆弱性チェックとAIによる自動修正： APIを用いた脆弱性の抽出から、未対応の脆弱性を自動でIssue化し、AIが自動修正・MRを開発者に通知するまでの処理フローを、実際のログを用いて解説します。

4. 開発セキュリティ運用におけるAI活用.
・自動化がもたらす効果： 仕組みの導入による、定性的・定量的な効果を共有します。
・AI活用範囲の拡張： 今回の自動修正にとどまらず、今後開発セキュリティ運用でAI活用を広げていくための展望を提示します。

■登壇者情報（敬称略）
増田小波
札幌の株式会社マーベリックスで、フロントエンドを中心にWebエンジニアを務めています。現在はAI駆動型開発案件に参画しており、AIとの協働に留まらず「AI活用でいかに人間の作業を自動化できるか」を日々探求しています。効率化を進める中でセキュリティへの関心も深めており、安全性を担保した上での自動化や堅牢なフロントエンド実装のあり方を模索しています。

■関連コンテンツ
・Youtube（過去の勉強会動画も公開中！）
www.youtube.com/@scalar-labs

・Zenn ブログ
https://zenn.dev/p/scalar_sol_blog

・イベントページ（connpass）
https://scalar.connpass.com/

Transcript

1. GitLab環境における⾃律型 セキュリティ運⽤の導⼊ 2026/05/28 株式会社マーベリックス 増⽥ ⼩波
2. 発表者 ⾃⼰紹介 • 株式会社マーベリックス • Webエンジニア（主にフロントエンド） 3年 • Zenn（https://zenn.dev/msd_sw） • AI活⽤歴：1年弱 ◦ Claude Code / Cursor ◦ Google Workspace（Gemini） 2
3. • 導⼊した脆弱性⾃動修正の仕組みについて紹介 ◦ GitLabのCI/CDパイプラインジョブ上で動く脆弱性検知から「AIによる⾃ 動修正‧MRの通知」までを⼀気通貫で⾃動化した仕組み • 開発セキュリティ運⽤でのAI活⽤についての共有 今回お話しすること 3
4. 発表の⽬次 1. 背景と課題 ◦ セキュリティ危機と運⽤の課題 2. 前提 ◦ AI駆動の仕組みを最⼤限活⽤するための ツール‧プロジェクト構成 3. 解決策‧実装詳細 ◦ ⼈間の⼿動確認からAIを活⽤した⾃律的脆弱性対応への移⾏ ◦ 仕組みのフロー詳細 4. デモ ◦ ログのご紹介 5. 導⼊効果‧今後の展望 ◦ 仕組み導⼊後の効果‧AIを活⽤したセキュリティ運⽤について 4
5. 背景‧課題 5 仕組みを作ろうと思った理由
6. 背景：最近のAIを取り巻く環境 • AIモデルの知能が格段に向上‧強⼒になった（Claude Mythosの登場） • 脆弱性の発⾒性能が格段に向上している ◦ 悪⽤された場合…セキュリティホールを突いたインシデントが⼤量発⽣する可能性⼤ • 脆弱性の早期検出‧対応‧解決 がより重要視される 6
7. 『CVE surge: Why the record rise in new vulnerabilities?』より 種類 脆弱性の発見頻度 大型フレームワーク （Spring / Rails / Django） 数ヶ月に1回〜毎月 Webサーバ （Apache / Nginx） 年数回 JavaScript ecosystem （npm packages） 毎週〜毎月 OS・ブラウザ 毎月 対応項目 頻度 dependency scan 毎日 dependency update 毎週 security patch 即日〜1週間 major upgrade 四半期 背景：AIの登場により脆弱性が数多く⾒つかる
8. 課題：セキュリティ対応のラグ • 脆弱性の検出後、通知されない ◦ 誰かに⾔われるまで気づけない。脆弱性レポート画⾯を⾒に⾏く運⽤ • 脆弱性検知に気付けない → 確認するまで放置してしまうリスク • セキュリティ事故が多発する昨今、修正までのリードタイムを短縮したい • 脆弱性が検知されたら通知する = 放置リスクを排除する • AIに⾃動で修正させる = AIによる初動対応で放置期間を極⼒短縮 8
9. 課題：既存機能のスコープ • GitLab Duo エージェント型⾃動修正の制約 ◦ 対応スコープ：SAST のみ（dependency_scanning は⾮対応） ◦ 利⽤要件：GitLab 18.9+ / Ultimate プラン / Duo Enterprise ◦ 今回の主要ユースケース（npm依存の脆弱性修正）はカバー外 • 独⾃実装で実現した付加価値 ◦ SAST + dependency_scanning を統⼀フローで処理 ◦ npm audit による修正結果の⾃動検証ループ（最⼤2回リトライ） ◦ 既存Issue管理‧ラベル‧レビュアー割り当てとの統合 ◦ Google Chat 通知による即時フィードバック 9
10. 前提 10 環境について（ツール・プロジェクト構成）
11. 前提条件の全体像 11 • ⼤きく分けるとふたつの軸がある • 両⽅が整っている = AIが本領発揮できる環境 がある
12. Application Security Testing（AST） • ソフトウェアやアプリケーションを評価し、攻撃者が悪⽤する可能性のある脆弱性を特 定‧修正するプロセス • コード変更やマージのたびに⾃動で検証を⾏う
13. GitLab > セキュリティ > セキュリティ設定 • リポジトリに最適な セキュリティツール を設定 • CI/CDパイプラインで⾃動実⾏（囲っているもの = 仕組み導⼊先で使⽤） GitLabセキュリティツール：AST 13
14. GitLabセキュリティツール：脆弱性レポート 14 GitLab > セキュリティ > 脆弱性レポート • 検出された脆弱性がレポートとして⼀覧表⽰される • クリックで個別の詳細情報を確認できる
15. 脆弱性レポート詳細 15 GitLab > セキュリティ > 脆弱性レポート > レポート詳細
16. レイヤー別マルチリポジトリのマイクロサービス構成 16 AI活⽤により適した構成
17. レイヤー別マルチリポジトリのマイクロサービス構成 • 役割を分離したアーキテクチャ によるAI活⽤の最適化 ◦ 縦割りのリポジトリ分割：Frontend / BFF / Backend の疎結合構成 ◦ 単⼀責任での機能分解：機能コンポーネントを適切に分解‧独⽴させる ◦ コントラクトベースの遵守： コンポーネント間の連携ルールを厳格化 • なぜこの⼟台が必要なのか？ ◦ 💭 モノリス構成 → AI修正により、他の機能に影響が出るリスクあり。⼈間によるテストが毎回 必要になり、⾃動化が破綻する ◦ ✅ 今回のアーキテクチャ → 修正時の影響範囲が限定されるため、他の機能に影響しない。AIに コードの書き換えを任せられる安全な環境が担保されている 17 AIツールを導⼊するだけでは⾃動化は実現しない 安全にAIを稼働させるには、以下のアーキテクチャが必要
18. • AIを活⽤できる⼟台があり、導⼊できた仕組みである • どのような環境でもそのまま活⽤できるわけではない • 前提のまとめ 18
19. 解決策‧実装詳細 19 課題を解決するための仕組み設計と実装 ※フロントエンド領域
20. 技術スタック • 基盤‧パイプライン：GitLab リポジトリ / GitLab CI • AIモデル： Claude Code ◦ Sonnet 4.6をメイン使⽤ - サブタスクではClaudeが判断しHaikuも利⽤ ◦ なお使⽤モデルはAWS Bedrock側で⾃由に選択可能 • AIインフラ（LLM基盤）： Amazon Bedrock ◦ ※プロジェクト既存のAWS環境を利⽤ • 通知： Google Chat API ◦ ※弊社内使⽤ツールのため 20
21. ジョブフロー 21
22. • CI/CDパイプラインで単体テストを実施 ◦ MR‧mainマージ時に実⾏ • テストカバレッジが⼤事 ◦ 指定したパーセンテージ以上を確認 ◦ AIの修正が既存機能に悪影響を与えていないか を、確実かつ⾃動的に担保するため テストカバレッジ 22
23. • 定期実⾏スケジュール設定 ◦ 実⾏忘れを防ぐ ◦ 定期⾃動実⾏ = ⾮属⼈化 • 他ジョブとは異なる実⾏形態 ◦ 単体テストなど他のジョブはコミットやMRごと に実⾏される ◦ 他パイプラインジョブに⼲渉しないよう設定 スケジュール実⾏ 23
24. • 脆弱性の抽出 ◦ GitLab Vulnerabilities API で脆弱性有無の確認 ◦ 重要度/レポートタイプ/詳細情報（ロケーション、ソ リューションなど）を取得 ◦ 後続の⾃動修正ジョブにアーティファクトとして渡す ◦ 特に、ソリューションをClaudeCodeで修正時に使⽤ • Issue作成 ◦ 脆弱性が検出されなければジョブは終了 ◦ 検出される且つ紐づくIssueがない時のみ実⾏ ▪ すでにIssueに紐づく脆弱性の重複対応を防ぐ 脆弱性チェックジョブ 24
25. • ClaudeCode による修正 ◦ 作業ブランチの有無確認、なければ作成 ◦ 受け取ったアーティファクトから脆弱性のソリュー ションを参考に修正対応を実施 ◦ 修正もれがないか確認（依存関係のみ） • ドラフトMR作成 ◦ ⾃動修正のドラフトMRを作成 ◦ ⼈間によるレビューを必須にする ▪ AIによる修正はあくまで「⼀次対応の⾃動化」 ▪ 完璧な修正ができる魔法の道具ではないため、 ⼈間によるレビューと最終判断が前提となる • チャット通知 ◦ Google ChatのWebhookを利⽤した通知 ⾃動修正ジョブ 25
26. 補⾜：ジョブの条件と例外ケース 各処理の実⾏条件 失敗‧例外ケースの扱い ◦ Claude Codeが修正できなかった場合：未修正件数をMRの説明に記載（要⼈間レビュー） ◦ ⾃動修正ジョブが失敗した場合：Issueにジョブ失敗コメントを⾃動投稿（⼿動対応へ誘導） ◦ ※ Google Chat通知はMR作成成功時のみ 26 処理 スキップ条件 ① 脆弱性チェック 修正するものがない場合 ② Issue作成 紐づくIssueがすでに存在する場合 ③ 自動修正 修正ブランチがすでにある場合
27. デモ/実例紹介 27
28. 実例：脆弱性検出ジョブ実⾏ログ • 脆弱性検出 → Issue有無確認、作成と脆弱性の紐づけ • 脆弱性の詳細をアーティファクト（vulns.json ）として⽣成 28
29. • Issueタイトル ◦ 深刻度 = Critical の脆弱性検出 の場合に表記 ◦ 緊急度がひと⽬でわかる • 概要 ◦ 脆弱性⼀覧 ▪ 主たる情報のみ ◦ 実⾏したパイプラインのURL 実例：脆弱性検出Issue 29
30. 実例：⾃動修正ジョブ実⾏ログ • 30 • アーティファクトから脆弱性情報を読み込む • 修正試⾏開始 ◦ 修正後に修正漏れないか確認 ◦ あればリトライ • ドラフトMR作成 → 通知
31. 実例：⾃動修正ドラフトMR / Chat通知 • 概要 • 脆弱性修正の変更内容 • AIがセルフレビューしたチェッ クリスト • Chatの通知↓ 31
32. 実例：実際に検出‧修正した脆弱性 Mermaid - 複数の脆弱性 • 解決策 ◦ 修正された安全なバージョンへ アップデートすること 32
33. 導⼊効果 33
34. 導⼊効果 定量的効果 • 脆弱性の検出通知：都度⼿動確認 → 最⼤7⽇以内の⾃動通知に改善 • 対応開始までの時間：担当者が気づき次第 → 検出後即時のMR⾃動作成に改善 • 副次効果：仕組みを導⼊したことで脆弱性を意識的に気にかけるようになった（個⼈の感想） 定性的効果 • 作業負担‧属⼈化の解消 ◦ 修正作業の⼼理的ハードル低下 • 「気づいた⼈‧⼿すきの⼈が対応する」という曖昧な作業分担を改善 ◦ 対応漏れ‧先送りの防⽌ • 仕組みとしての堅牢性 ◦ Issue‧MRが⾃動⽣成されることで監査証跡が残る（いつ‧何を‧どう修正したかを記録） • サービスが増えても対応コストが増えないスケーラビリティ 34
35. 今後の課題 / 展望 35
36. 今後の課題 AI⾃動修正精度の継続的な検証  ⇨ 特にSASTの修正は依存関係の修正と異なり、⾃動検証が難しい 修正プロンプトの最適化  ⇨ より⾼精度の⾃動修正を⽬指す 36
37. 開発セキュリティへのAI活⽤の拡張 • 今回の⾃動修正のジョブでは… ◦ 脆弱性の検出‧Claude Codeを活⽤して修正‧MR作成を⾃動化 ◦ 今後はこのAI活⽤をさらに広げ、開発環境全体のセキュリティ強化に取り組んでいく • Clearwing の活⽤ ◦ オープンソースの⾃律型セキュリティエージェント（脆弱性スキャナー兼ソースコードハン ター） ◦ 通常は外部に委託する「ペネトレーションテスト（侵⼊テスト）」をAIによって内製化が可能 ◦ リリース前にシステム全体を通したホワイトボックステストとして活⽤ ◦ AIを取り巻く環境の変化（Claude Mythos等の影響による新たな脅威）にも継続的に対応する 37
38. まとめ 38 発表の総括
39. 1. 導⼊した仕組みの総括 … 本仕組みがもたらす価値 • 脆弱性の検知‧AI修正‧MR通知 までを⼀気通貫で⾃動化する仕組みを紹介 • 放置リスクをなくし、セキュリティ対応の「ラグ（遅れ）」を⼤幅に短縮可能 2. 仕組みを成⽴させる2つの前提 • ツール導⼊だけではなく、アーキテクチャやテストという前提もあってAIによる⾃動 化を活⽤できている 3. 開発セキュリティへのAI活⽤の拡張 • 今回の⾃動修正ジョブにとどまらず、AIを活⽤した⾃律型セキュリティエージェント （ex. Clearwing）の導⼊により、ペネトレーションテストの内製化など、開発環境全 体のセキュリティ強化へとAI活⽤の範囲を広げていく まとめ 39
40. Q1. 修正完了（MRマージ）後、脆弱性のステータスはどうなるのか？ A1. GitLab内のポリシーにて、再スキャンで検出されなくなった脆弱性レポート のステータスを⾃動で「解決済み」に変更されるよう設定しています Q2. GitLab Duoの⾃動修正機能の使⽤でいいのでは？ A2. カスタマイズ性‧汎⽤性を考慮すると、既存機能の使⽤ < 独⾃導⼊ が今回は最 適と判断したため、GitLab Duoの機能の使⽤は⾒送りました FAQ：よくある質問 40