Geminiで要件・設計のセキュリティレビューを自動化し、工数を90%削減した話

1. はじめに

開発プロセスにおける要件・設計のセキュリティレビューは、専門知識を要するため属人化しやすく、工数の増大が開発全体のボトルネックとなり得る課題です。

本稿では、私たちセキュリティチームがこの課題に対し、生成AIであるGeminiを活用してレビュープロセスを自動化し、工数を大幅に削減した技術的アプローチとその効果について報告します。

2. 対象読者

この記事は、特に以下のような課題を感じている方々に向けて書いています。

• セキュリティレビューの工数増大や属人化に悩むセキュリティ担当者の方
• セキュリティのシフトレフトを考えているエンジニアリングマネージャーの方
• 生成AIを活用した具体的な業務改善事例に興味があるすべての開発者の方

3. 現状のセキュリティ活動と課題

「1:10:100の法則」が示す通り、脆弱性の修正コストは開発の後工程になるほど増大します。故に、開発ライフサイクルの上流、すなわち要件定義・設計段階で脆弱性のリスクを低減させることが、プロダクトの安全性と市場投入速度を両立させる上で極めて重要となります。

この考えに基づき、私たちは開発ライフサイクル全体で、以下のようなセキュリティ活動を実践してきました。

フェーズ	主な活動
1. 要件定義・設計	設計レビュー、脅威モデリングを、認証・契約・決済などの重要機能を中心に実施しています。
2. 実装	セキュアコーディング講座の開催や、生成AIによるコードレビューを取り入れています。
3. テスト	OpengrepによるSAST、AeyeScan(脆弱性スキャナ)とBurp Suiteを組み合わせた自動・手動DASTを実施しています。
4. リリース・運用	GitHub Dependabotによるライブラリの脆弱性管理や、脆弱性スキャナを利用した定期診断の導入を進めています。

これらの活動は確かに効果を上げていますが、現状の取り組みに満足することなく、もう一段階上のセキュリティレベルを目指したいと考えていました。特に、最も費用対効果が高いとされる「要件・設計のセキュリティレビュー」は、その専門性から重要機能に限定されがちで、すべてのプロジェクトで一貫した品質を担保するには、まだ伸びしろがあると感じていました。

この状況を打破するべく 「要件定義・設計段階のセキュリティレビューを、専門知識がない人でも、短時間で、一定の品質で実行可能にする」 ことを目的に、私たちはあるプロジェクトを立ち上げました。

4. 解決策の選定：Geminiの採用理由

この目的を達成する手段として、私たちは生成AIの活用に着目しました。

私たちがパートナーとして Gemini を選んだ理由は、大きく2つあります。

1つ目は、追加コストなしで利用を開始できたことです。GeminiはGoogle Workspaceの契約に含まれていたため、新たな予算を確保することなく、すぐに検証を始めることができました。

2つ目はセキュリティです。Google Workspaceで利用できるGeminiは、入力したデータがAIの学習に利用されません。設計ドキュメントという機密情報を取り扱う上で、これは必須の条件でした。（無料版のGeminiでは学習に利用されるため、業務利用はできません。）

また、モデルの選定も重要なポイントでした。当初は Gemini Flash で検証を開始しましたが、期待するレベルの分析結果は得られませんでした。そこで、より高性能な Gemini Pro に切り替えたところ、出力の質が劇的に改善されたのです。

正直なところ、当初は「まずは試してみよう」という軽い気持ちでした。しかし、実際にGeminiで設計ドキュメントを分析させてみたところ、その性能は私たちの想像を大きく超えるものでした。生成されるレビューの質は、PoC（概念実証）を進める上で十分すぎるレベルだと判断し、本格的な活用へと踏み出すことにしました。

5. 技術的アプローチ：プロンプトエンジニアリングによる精度向上

PoC（概念実証）の初期段階では、単純な指示によるレビューでは期待した成果は得られませんでした。

【初期プロンプト】

この設計ドキュメントをレビューして、セキュリティリスクを指摘してください。

このプロンプトに対する出力は、「入力値の検証」や「最小権限の原則」といった一般的な指摘に終始し、具体的な設計内容に踏み込んだ分析には至りませんでした。

そこで、出力精度を実用レベルまで引き上げるため、以下の要素をプロンプトに組み込む改良を実施しました。

1. 役割（ペルソナ）の付与: AIの専門性を定義します。

あなたは、Webアプリケーション開発におけるセキュリティの脅威と対策に精通した、
経験豊富なセキュリティエンジニアです。

2. タスクの明確化: 実行すべき処理を具体的に指示します。

以下のドキュメントを分析し、潜在的な脆弱性や設計上の懸念事項を特定し、
レビューしてください。  

3. レビュー観点の指定: 思考のフレームワークを提供し、分析の軸を定めます。

レビューの際は、特に以下の観点を重視してください。  
- STRIDEによる脅威分析  
- 個人情報保護法やプライバシーガバナンスガイドブックに基づくプライバシーリスクの特定  
- 法律、規制、社内ルールに基づくコンプライアンス違反  
- その他一般的なセキュリティガイドラインやベストプラクティスからの逸脱

4. 組織固有のコンテキストを追加する: AIの指摘を一般的なものから、より「私たち向け」にカスタマイズするため、私たちの組織特有の情報を与えました。

用語定義:  
- RENOSY：不動産投資をする顧客向けのサービス  
- RENOSY ASSET：不動産投資をする顧客向けのWebサイト  
- RENOSY ACCOUNT：RENOSY ASSETなどで利用される顧客向け認証基盤でOAuth2を使ったSSOを提供する  
社内ルール:  
- 新しいSaaSを導入する場合、法務部門によるコンプライアンスチェックが必要  
- 機微な情報を含むメッセージをSlackに投稿する場合、チャンネルはプライベートとする
- Googleドライブにファイルを保管する場合、マイドライブではなく共有ドライブに配置する

5. 出力形式の指定: 最後に、後続の処理や人間による確認が容易なように、出力を構造化させます。

指摘事項は、以下のフォーマットで、箇条書きで出力してください。

## （ここにリスクの概要を記述） 
（ここにリスクの詳細を記述）  

### 計画されている対策  
（ドキュメントに記載されている対策があれば記述）

### 推奨する対策  
（追加で推奨される対策を記述）  

当初はリスクの「重要度」も出力させていましたが、AIが判断する重要度と、私たちがビジネスコンテキストを元に判断する重要度が合致しないケースが多かったため、あえて出力項目から外しました。

これらの改善を統合したプロンプトは非常に強力ですが、毎回長いプロンプトをコピー＆ペーストするのは非効率です。そこで私たちは、Geminiの Gem という機能を活用しています。

Gemを使うと、このように作り込んだプロンプト（ペルソナや制約条件）を自分専用のショートカットとして保存できます。これにより、レビューのたびに長いプロンプトを準備する必要がなくなり、作業が効率化されました。

6. 導入効果と考察

本アプローチの導入による最も大きな効果は、レビュー所要時間の大幅な短縮です。これまで1件あたり2〜4時間を要していたレビューが、AIによる一次分析を挟むことで10分〜1時間にまで短縮されました。

具体的な事例として、Web画面の情報からZoom会議を自動作成する機能の設計レビューが挙げられます。このレビューにおいてGeminiは、「Zoom会議には必ずパスワードを設定し、待機室を有効にすべき」という、Zoomの利用におけるベストプラクティスに基づいた具体的な対策を推奨してくれました。

従来、このようなSaaS連携機能のレビューでは、セキュリティチームが都度そのSaaSのガイドラインを調査し、設計内容と突き合わせる作業が必要でした。今回のケースでは、その調査工数をかけることなく、AIが有効な推奨事項を提示してくれたのです。

これにより、セキュリティチームのレビュー工数は大幅に削減されました。創出された時間は、AIによる一次分析結果の妥当性評価や、より高度な脅威分析といった専門業務に再配分することが可能になりました。これは、セキュリティ担当者の業務を「調査・作業」から「分析・判断」へとシフトさせる効果をもたらしたと言えます。

7. 結論と今後の展望

本稿では、Geminiを活用した設計レビューの自動化アプローチについて詳述しました。AIは万能ではありませんが、適切なプロンプトエンジニアリングにより、レビュープロセスの一次分析を担う有効なツールとなり得ることを実証しました。

本稿で紹介した取り組みは、さらに発展しています。レビュー基盤はGemini APIを利用する形へ実装を変更し、SlackBotと統合しました。これにより、開発者がセルフサービスでレビューを実行できる環境が完成し、すでに本番運用を開始しています。その技術詳細については、次回の記事で報告する予定です。

2025/10/17 追記
Gemini の Gem が組織内で共有できるようになったので、SlackBotは退役しました！