https://buildersbox.corp-sansan.com/entry/2026/02/26/100000

はじめに

2025年12月に情報セキュリティ部Product Securityグループでインターンをしました床井です。

Product Securityグループは、ビジネスデータベース「Sansan」や経理AXサービス「Bill One」をはじめとする、Sansanが提供する全てのプロダクトのセキュリティ向上を目的とした業務に取り組んでいます。具体的には、内製で脆弱性診断や、実装に着手する前の設計書をセキュリティ観点でレビューする「セキュリティ設計レビュー」などを行っています。

今回はこのセキュリティ設計レビューを一部自動化するAIエージェント「Hayami」の作成に取り組みました。インターン後に内定をいただき承諾したため、入社する前からAIで自分の仕事を奪うことに成功してしまいました。

そもそもセキュリティ設計レビューって？

開発者が機能の実装に入る前に、セキュリティ上の懸念を確認するプロセスのことです。実装後に脆弱性が発覚して修正する後戻りコストを削減することが主な目的です。

ソフトウェア開発ライフサイクルの中では、要件定義フェーズの後、実装フェーズの前に行います。

セキュリティ設計レビューでは「機械的なチェック」と「経験と直感に頼るチェック」の2種類を行います。

機械的なチェックでは社内のセキュリティガイドラインを満たしているか、あるいはRFCなどの仕様に基づいた機能であれば、それに準拠しているかなどを確認します。

一方、経験と直感に頼る部分では、より自由な発想で幅広い視点から懸念点を洗い出します。コードの臭いを察知する開発者の経験と直感に近い領域です。

課題

一つ目の課題は、機械的なチェックに当たる社内ガイドラインへの準拠を毎回網羅することが難しかったということです。Sansanの全てのプロダクトのセキュリティレビューを少人数のメンバーで対応しており、開発スピードを落とさないように迅速な対応が求められます。しかし、160以上ある項目すべてに毎回目を通すのは現実的に難しく、「設計書の内容からガイドラインの該当箇所を推測して参照する」という運用にとどまっていました。

二つ目は、今後セキュリティ設計レビューの依頼数が増加していくという予測です。Product Securityグループとしてレビューのカバレッジをもっと広げたいという思いに加え、AI活用の浸透によって開発側のアウトプット量が増えることも要因です。コーディングの工数が減れば、同じ時間でより多くの機能開発を行えるため、自ずとレビュー対象の設計書も増えます。開発者の生産性が向上しても、セキュリティレビューがボトルネックになってしまっては組織全体としての生産量は増やせません。

まとめると、セキュリティ設計レビューの質と量を担保する必要がありました。

AWS Security Agentとの比較

自分たちで開発せずとも既存製品で解決できるならそれを導入したいと考え、セキュリティ設計レビューが可能なAWS Security Agentを検討しました。

インターンのオンボーディングが終了して業務に取り掛かり始めた初日にちょうどプレビューがアナウンスされました。正直焦りました。未来の自分の仕事を、自分より先にAWSに奪われてしまったかと。

実際に触れてみるとレビュー結果の表示画面や、デフォルトで搭載されているsecurity requirementに基づく指摘は的確でした。

しかし、使用は見送りました。その理由は、独自の設計レビューの要件に合わせたカスタマイズが難しかったためです。

AWSが提供するsecurity requirement以外にも、カスタムのものを記述することができますが、160以上ある社内ガイドラインの項目を所定のフォームに整形する必要があります。

この作業が一度で済むなら取り組んでみる価値はありますが、社内ガイドラインを常に更新し続けているため、メンテナンスの運用が難しいと判断しました。

また、私たちのチームではセキュリティ設計レビューの対象かどうかを判定する基準を設けていますが、この判定を行ってくれるワークフローがありません。

さらに、既存の依頼フローはSlackを通じて行われていますが、AWS Security AgentとSlackを柔軟に連携させることも現時点では難しいという結論に至りました。*1

今回開発したHayami

既存製品ではワークフロー上の要件を満たせないと判断し開発したのが「Hayami」です。主な構成は下図の通りです。

既存の運用フローの流れに組み込めるよう設計しました。Slack上で開発者がレビューワークフローを開始すると、設計書と社内のガイドラインを取得します。その後、整形したプロンプトがLLMに渡され、分析結果がProduct Securityのメンバーに通知される仕組みです。

実際の出力はお見せできませんが、イメージとしては以下のような形式で出力されます。

レビュー精度

実際に依頼を受けた設計書を対象にベンチマークを測定しました（Product Securityメンバーの判断を正解とした比較）。

設計書とガイドラインの適合率:

Hayami: 正答率95.8%、抜け漏れ0%、過検知4.2%
AWS Security Agent: 正答率72.1%、抜け漏れ4.8%、過検知23.0%

Hayamiを使うことでセキュリティ設計レビューの質を一定担保できることが確認できました。セキュリティ業務において、抜け漏れが発生することはクリティカルです。「多少ノイジーで時々空気を読んでくれないが、懸念点を見逃さないAI」という具合に調整しました。

また、レビューのリードタイムの面でも効果が見込めます。2025年7月〜11月の平均初動応答時間に基づくと、Hayamiが最初のレビューコメント（明らかな情報の不足や抜け漏れの確認など）を代行することで、レビュー終了までの時間を最大18.76営業時間短縮できる計算になります。

今後の展望

Hayamiの改善と発展として、以下のような展望を考えています:

計測の自動化: Hayamiの効果や精度を継続的に計測していきたいです。そのためにベンチマーク測定をある程度自動化したいと考えています。
他業務への横展開: 例えば同じ情報セキュリティ部のSecurity GovernanceグループではAIツールの利用申請の対応をしていますが、与える情報を変えれば応用できそうです。
「経験と直感」の言語化: 現在、Hayamiはガイドライン比較などの機械的な部分を担っていますが、今後は「これとこれが組み合わさると、このような脆弱性につながる」といった、熟練者の思考プロセスを言語化してプロンプトに組み込み、より高度な検出を目指します。

また、Product Securityグループとしてさらにシフトレフトを進めていきたいと考えています。設計フェーズでは既にある程度仕様が固まっているため、さらに手前の要件定義フェーズから関与すべきというフィードバックもいただきました。Hayamiによる自動化で生まれた時間を使って、より上流工程のセキュリティ向上に取り組んでいきたいです。