リリース前のセキュリティチェック AIが書いたコードを誰が判断するか
要約： VAONの10ステップの開発フローを適用している案件では、各バージョンをリリース前にセキュリティの関門に通します。Claude Codeがそのバージョンの変更全体を確認し、シニアエンジニアが指摘を一件ずつ読んで、本物の問題と誤検知を分け、リリースするか先に修正するかを判断します。この関門は、すべての案件で動いている基本チェックの上に置いています。
目次
- リリース前の関門は、プルリクエストごとのチェックと何が違うのか
- プルリクエストごとに確認済みなのに、なぜバージョン全体を見直すのか
- リリース前の関門はどんな手順で進むのか
- リリースは誰が、何をもとに判断するのか
- 国の注意喚起やNIST SSDFとはどう関係するのか
- この関門が動かない場合、足りない場合
- よくあるご質問
1. リリース前の関門は、プルリクエストごとのチェックと何が違うのか
VAONのリリース前セキュリティチェックはバージョンごとに1回行うもので、第1層のチェックはプルリクエストごとに動くものです。適用範囲と、見えている範囲が異なります。
| 第1層（プルリクエストごと） | リリース前の関門 | |
|---|---|---|
| 適用 | すべての案件 | 10ステップのフローを適用している案件（多くの案件、すべてではない） |
| タイミング | プルリクエストごと | バージョンごと、リリース前 |
| 見えている範囲 | 一つの変更 | バージョン内の変更全体 |
| 内容 | シークレットスキャン、依存関係スキャン、静的解析（SAST） | AIによるセキュリティレビュー、人による結果の確認 |
| 判断する人 | 仕組みが止める。マージはチームリーダーが承認 | シニアエンジニアがリリースか修正かを判断 |
第1層には、すべての案件で守っている基本ルールも含まれます。
- メインブランチを保護し、レビューなしにはマージしない
- 会社が管理するClaude Codeの共通設定（禁止コマンド、サンドボックス、承認済みのMCPサーバー）
- AIが提案したパッケージ名は、インストール前に実在を確認する（AIは存在しない名前を挙げることがあるため）
- 開発環境に本番の鍵を置かない
リリース前の関門は、Claude Codeを使った開発フローの最終工程です。Claude Codeの共通設定については、Claude Codeを業務で使うためのルールでご紹介しています。
2. プルリクエストごとに確認済みなのに、なぜバージョン全体を見直すのか
バージョン全体を見直すのは、複数の変更が組み合わさって初めて表に出る脆弱性があるためです。プルリクエストのレビューでは、レビュアーはそのPRの範囲しか見ていません。
説明のための例を挙げます。1つ目のPRで、顧客一覧を出力するAPIを権限チェック付きで追加しました。2週間後、別の不具合を直すため、2つ目のPRで共通の権限チェック関数を変更しました。どちらのPRも単体では妥当です。しかし組み合わさると、出力APIに権限のない利用者がアクセスできてしまう可能性があります。
自動スキャンは、コードに紛れ込んだ鍵や、脆弱性が公表済みのライブラリのように、パターンで見分けられる問題に強い仕組みです。業務ルールに沿った権限の誤りには、たいていパターンがありません。Claude Codeのドキュメントによると、/security-reviewコマンドは現在のブランチの変更を対象に、インジェクション、認証まわりの問題、データ露出などの脆弱性を分析します。
3. リリース前の関門はどんな手順で進むのか
VAONのリリース前の関門は5つの手順で進み、AIが担うのは2番目だけです。
- 範囲を確定する。前のバージョンから今回のリリース候補までの変更をすべて特定します。
- AIによるセキュリティレビュー。Claude Codeがその変更を確認し、疑わしい箇所を場所と理由つきで挙げます。
- 人が指摘を一件ずつ読む。シニアエンジニアがコードと仕様書に照らし、「本物」「誤検知」「確認が必要」のいずれかに分けます。
- 判断する。未修正の本物の問題があれば、先に修正し、再度確認してからリリースします。
- 記録する。各項目の結論を、リリースの記録とあわせて保存します。
この関門の前には、プルリクエストごとの3段階レビューがあります。順序と理由はAIコードレビューの手順でご説明しています。
4. リリースは誰が、何をもとに判断するのか
リリースを判断するのは案件のシニアエンジニアで、AIではありません。AIが出すのは疑わしい箇所の一覧だけです。どのデータをお客様が意図して公開しているのか、どの画面が社内ネットワークからしか使えないのか、AIは知りません。
次の表は、人が指摘をどう読むかを示す説明のための例で、実案件の結果ではありません。
| AIの指摘 | 人が確認すること | 考えられる結論 |
|---|---|---|
| 利用者の入力を文字列連結してクエリを組み立てている | 入力が検証処理を通っているか | 本物：リリース前に修正 |
| APIがほかの利用者のメールアドレスを返している | この画面でメールアドレスを表示する仕様か | 確認が必要：業務上の意図次第 |
| サンプル設定ファイルにAPIキーらしき文字列がある | 本物の鍵か、ダミーの文字列か | ダミーなら誤検知 |
AIをセキュリティレビューに取り入れてわかったのは、誤検知は珍しくないということです。関門の価値は、一覧の長さではなく、結果を読む人にあります。また、この関門がVAONの唯一のセキュリティ対策というわけではありません。VAONには専任のインフラチームがあり、セキュリティテストも担当しています。CTOとテックリードはすべての案件に参加しているため、リリースの判断には必ず責任を持つ者の名前が残ります。
修正によってリリースが遅れる場合や範囲が変わる場合は、週次報告の「リスク」と「ご判断いただきたい事項」でお知らせします。
5. 国の注意喚起やNIST SSDFとはどう関係するのか
VAONのリリース前の関門は、二つの文書を参考にしています。照らし合わせる枠組みとして使っているもので、いずれかの基準を満たしている、認証を受けているという意味ではありません。
一つ目は、内閣官房国家サイバー統括室（NCO）と経済産業省による2026年5月18日付の注意喚起（ソフトウェア・ベンダ向け）で、Project YATA-Shieldとあわせて公表されたものです。その1項目めでは、リリース前のソフトウェアについて高性能AIを積極的に活用し、リリース後に脆弱性が見つかる可能性を下げたうえでリリースするよう求めています。特定のツール名や、満たすべき基準は示されていません。
二つ目は、NIST SP 800-218（SSDF、バージョン1.1、2022年2月）です。どの開発モデルにも組み込める、安全なソフトウェア開発の実践をまとめたものです。注意喚起の内容については、AIコーディングのセキュリティ対策で詳しくご説明しています。
6. この関門が動かない場合、足りない場合
リリース前の関門には明確な限界があります。お客様の案件がどれに当たるか、事前にご確認ください。
- コードをAIに渡すことをご許可いただいていない場合。AIの手順は実施しません。第1層の自動チェックと、人によるコードレビューで確認します。
- 10ステップのフローを適用していない案件。プルリクエストごとの第1層は動きますが、バージョン全体の見直しはありません。
- 問題がコードの外にある場合。サーバー設定やインフラ設計は、変更差分には現れません。これらはセキュリティテストの範囲で、契約で取り決めます。
- リリース後。リリース後に新しい脆弱性が公表されることがあります。脆弱性情報の監視、パッチ対応、24時間365日の監視体制は、契約で個別に取り決めます。
AIによるセキュリティレビューは人を補うものであり、人の代わりにはなりません。誤検知もあり、見落としもあり得ます。
7. よくあるご質問
/security-reviewで、ペネトレーションテストの代わりになりますか。 代わりにはなりません。/security-reviewコマンドは変更されたコードを確認するもので、稼働中のシステムに攻撃を試みるものではありません。VAONには専任のインフラチームがあり、セキュリティテストも担当しています。案件ごとのセキュリティテストの範囲や、24時間365日の監視を含めるかどうかは、作業開始前に契約で取り決めます。
AIの誤検知が多い場合は、どうしますか。 AIによるセキュリティレビューで誤検知が出るのは珍しくないため、すべての結果を人が読みます。シニアエンジニアが各項目をコードと仕様書に照らして確認し、誤検知と判断した場合はその理由を記録します。理由を残しておけば、次回同じ項目で議論を繰り返さずに済み、お客様も、なぜその項目を対応不要としたのかをご確認いただけます。
コードをAIに渡さない場合、バージョンは何で確認されますか。 ご許可をいただいていない場合、VAONはコードをAIツールに渡さず、AIによるセキュリティレビューも実施しません。それでも、すべての案件で動いている第1層は適用します。プルリクエストごとのシークレットスキャン、依存関係スキャン、静的解析、メインブランチの保護、そしてマージ前の人によるレビューです。
VAONは、NIST SSDFやYATA-Shieldをどのように扱っていますか。 セキュリティの手順は、NIST SP 800-218（SSDF）と、NCOと経済産業省による2026年5月18日付の注意喚起を参考にしています。照らし合わせる枠組みとして使っており、基準を満たしているという意味ではありません。注意喚起は要請であり、取得する基準や認証はありません。そのため、表示やラベルではなく、具体的な手順と記録をお見せしています。
修正が間に合わない指摘があっても、リリースしますか。 リリースするか先に修正するかは、各項目の結論にもとづいてシニアエンジニアが判断します。本物の脆弱性と判断した項目は、修正して再確認してからリリースします。修正によってリリースが遅れる場合や範囲が変わる場合は、週次報告の「リスク」と「ご判断いただきたい事項」でお知らせします。
今日からできることが一つあります。開発チームに、直近のリリースについて尋ねてみてください。「セキュリティレビューの結果を誰が読み、どの項目を誤検知と判断したのか、理由は何か」。「ツールの結果は問題なしでした」という答えであれば、そのリリースを判断した人はいなかったことになります。
この関門を貴社の案件に当てはめるとどうなるか、無料相談（60分）でご説明します。CEOが同席します。資料のご準備は不要で、ご契約を前提としたものではありません。
参考資料
- Claude Code Docs「Commands」（/security-review）：https://code.claude.com/docs/en/commands（2026年10月29日確認）
- 内閣官房国家サイバー統括室・経済産業省「AI性能の高度化を踏まえたサイバーセキュリティ対策の強化について（ソフトウェア・ベンダに対する注意喚起）」令和8年5月18日：https://www.cyber.go.jp/pdf/press/20260518_AI_CS_software_vendor.pdf（2026年10月29日確認）
- NIST SP 800-218「Secure Software Development Framework (SSDF) Version 1.1」2022年2月：https://csrc.nist.gov/pubs/sp/800/218/final（2026年10月29日確認）
