AIによるADRのセキュリティレビューの自動化 ― Opus 4.6 によるGitHub ActionとGemini Gemの活用

はじめに

Security Assessmentチームの小竹です。Security Assessmentチームでは、DevSecOpsの推進や脆弱性診断に取り組んでいます。

「セキュリティレビューは、リリース前にまとめてやるもの」——そんな認識がまだ根強い現場も少なくありません。しかし、設計段階で入り込んだリスクを後工程で潰すのは、コストも手戻りも大きくなります。私たちが目指しているのは、設計フェーズからセキュリティの観点が自然に組み込まれている状態、つまり「安全な設計がデフォルトになる世界」です。

その第一歩として、ADR（Architecture Decision Record）に対するセキュリティレビューをAIで自動化する仕組みを作成しました。

1. Gemini の Gem を活用した対話型ADRレビュー
2. Claude Opus 4.6 エージェント による GitHub Action でのPRレビュー自動化

本記事では、それぞれの仕組みと狙い、そして今後の展望を紹介します。

なぜ ADR のセキュリティレビューなのか

ADRは、アーキテクチャ上の意思決定とその背景を記録するドキュメントです。「なぜその技術を選んだのか」「どんな代替案を検討したのか」といった設計判断が明文化されるため、セキュリティの観点でレビューするには最適な対象と言えます。

ただし、ADRが書かれるたびにセキュリティチームが人手でレビューを回すのは、スケールしません。ここにAIを活用することで、設計段階でのフィードバックループを高速かつ低コストに回せるようにしたいと考えました。

1. Gemini Gem による対話型レビュー

Google Gemini の Gemを使い、ADR に記載された設計判断に対して、セキュリティ上のリスクや考慮漏れを指摘する仕組みを構築しました。

使い方

利用者はGemにADRの内容を貼り付けるだけです。Gemが設計の文脈を読み取り、セキュリティの観点から問いかけや指摘を返します。対話形式なので、「この部分をもう少し深掘りしたい」「代替案のリスク比較をしてほしい」といった追加の質問にも柔軟に対応できます。

狙い

このGemは、セキュリティチームへの相談の前段階として機能することを想定しています。ADRの著者が自分で一次レビューを回せるようになることで、設計品質のベースラインが底上げされ、セキュリティチームはより本質的な議論に集中できるようになります。

2. Opus 4.6 エージェントによる GitHub Actionによるレビュー

もう一つの取り組みとして、Amazon Bedrock 経由で Claude Opus 4.6 を呼び出し、Pull Request に対して自動でセキュリティレビューを実行する GitHub Action を作成しました。

仕組み

• ADRを作成・更新するPRが作成されると、GitHub Actions のワークフローがトリガーされる
• ワークフロー内で Amazon Bedrock の Claude Opus 4.6 を呼び出し、差分やADRの内容をエージェントに渡す
• エージェントがセキュリティの観点でレビューを行い、結果をPRのコメントとしてフィードバックする

特徴

GitHub Actions 上で動作するため、開発チームが普段使っている PR ベースのフローに自然に溶け込みます。新しいツールの導入や学習コストはほぼゼロです。さらに、このエージェントの強みは、単純なパターンマッチや静的解析とは異なり、設計の意図やコンテキストを踏まえた指摘ができる点にあります。たとえば「なぜこの認証方式を選んだのか」という設計意図を理解した上で、見落としがちなエッジケースやリスクシナリオを提示します。Opus 4.6 の高い推論能力を活かすことで、人間のレビュアーに近い粒度のフィードバックが可能になりました。

現在のレビュー観点と今後の展望

現在の観点

現時点では、著名なセキュリティガイドラインに沿った指摘を行う構成にしています。具体的には、以下のガイドラインを参照しています。

• AWS Well-Architected Framework — クラウドアーキテクチャのベストプラクティス全般
• OWASP Top 10 / API Security Top 10 — Webアプリケーション・APIにおける代表的な脆弱性
• OWASP ASVS — アプリケーションセキュリティの検証基準
• OWASP MASVS — モバイルアプリケーションのセキュリティ基準
• OWASP Top 10 for LLM — LLMアプリケーション特有のリスク

これらは広く認知されたガイドラインであり、どの組織でも共通して押さえておくべき観点です。まずはこの土台を固めることで、一定水準のセキュリティレビューを自動で担保できるようにしています。

今後の展望：社内ガイドラインへの追従

汎用的なガイドラインだけでは、自社固有のアーキテクチャや運用ルールに最適化されたレビューにはなりません。今後は社内で整備されるセキュリティガイドラインと連動させることで、より実態に即した指摘ができるようにしていく予定です。

たとえば、社内ルールとして「チャットボットには Guardrails for Amazon Bedrock の導入を必須とする」と定めた場合、ADR にその記載がなければエージェントが指摘するといった運用が可能になります。

レビュー観点を細かくカスタマイズできることが、内製化の最大のメリットです。 SaaSのセキュリティスキャナでは「自社ではこうすべき」というポリシーまでは見てくれません。内製だからこそ、組織の成長やルールの変化に合わせてレビューの精度を継続的に高めていくことができます。

おわりに

今回紹介した2つの仕組みは、いずれもまだ発展途上です。しかし、「設計段階でセキュリティのフィードバックを得られる」という体験を開発チームに届けられたことは、大きな一歩だと考えています。

セキュリティレビューは、ゲートではなくガードレールであるべきです。開発を止めるのではなく、安全な方向に自然と導く仕組みをつくる。その延長線上に、安全な設計がデフォルトになる世界があると考えています。

引き続き、DevSecOps の推進を通じて、開発とセキュリティの距離を縮めていきます。