/security-reviewのすゝめ ― リリース前のセキュリティチェックをCodexセカンドオピニオンレビューでWチェックし、リスクを最小化した件
「社長、リリース前でよかったですね」
先日、Claude Codeのターミナルにスラッシュコマンドを一行打ち込んだ。
/security-review
対象は、行政書士法人クロノスで開発中の「補助金検索NAVI」というシステムだ。中小企業の経営者が会社情報を入力すると、AIが該当しそうな補助金や助成金をマッチングしてくれる。さらに事業計画書のドラフトまで起こしてくれる業務ツールで、API 60本、コード行数で数千行のSaaSになっている。
今は社内テスト中で、本格リリースに向けた最終調整の段階だ。
社内のAI幹部Q(CTO担当)とほぼ二人三脚で書いた。書いた、というのは正確じゃない。書いてもらった、が近い。わたしはコードを一行も自分の手で打っていない。
そのリリース前のコードに、/security-reviewと打った。
数分後、画面に並んだ指摘を見て、わたしはあびぃを呼んだ。
「あびぃ、リリース前にこれ回しといてよかった」
「拝見します。……ええ、これはリリース前に通して正解でしたね。本番に出る前に洗い出せたなら、むしろ理想的なタイミングです」
珍しく、否定から入らなかった。
/security-reviewは何をしてくれるのか
説明だけ先に書いておく。
Claude CodeにはAnthropic公式の「security-review」というスキルが標準で乗っている。コードベース全体を読み込んで、SQLインジェクション、XSS、認証・認可の穴、機密情報の漏洩、ファイルアップロードの抜け、レートリミットのバイパス、こういった「攻撃者が好む経路」をまとめて炙り出してくれる機能だ。
公式ドキュメントの説明は短い。
Identifies common security issues before they reach production.(本番に出る前に、よくあるセキュリティ問題を特定する)
たった一行で書かれているが、これを非エンジニア視点で言い直すとこうだ。
「自分では絶対に気づけないし、エンジニアに頼んでも見落とすやつを、AIが代わりに粗探ししてくれる」
ポイントは「before they reach production」、本番に出る前に、というところだ。リリース前のテスト段階でこそ価値が出る。
しかも、GitHubのプルリクエストにフックすれば、PRを出すたびに自動でレビューが走るCI連携まで用意されている。エンジニアじゃない人にこそ、刺さる機能だ。
何が出てきたか
ここから実例だ。一般人にもわかる粒度で、カテゴリだけ紹介する。
ひとつめは、権限設計まわり。
補助金検索NAVIは、本部・エリアパートナー・当行政書士法人クロノスの3つの主体が使う設計になっている。本部はエリアパートナーの取りまとめ、エリアパートナーは顧客のフロント担当、当行政書士法人クロノスは補助金申請といった士業実務、と役割が分かれている。3者それぞれで見える範囲が違うので、権限の境界をきちんと分ける必要がある。security-reviewは、いくつかの管理画面APIで「想定より権限の範囲が広めに取られている箇所」を指摘してきた。
「これ、Qに作らせたとき、わたし3者の権限境界をきっちり詰めてなかったですよね」
「詰めてなかったですね。仕様も口頭でした」
「だな」
仕様が曖昧だと、AIは「広めに取っておこう」を選ぶ。これは人間の同僚と一緒だ。指示がふわっとしていると、後で困らないよう広めに権限を取る。3層構造のシステムは特に、誰が何を見ていいか・見てはいけないかが入り組むので、テスト段階で境界をきっちり指摘してもらえるのはありがたい。
ふたつめは、外部に送る通知の文面まわり。
ステータス変更時にエリアパートナーへ送るメールの組み立て方で、入力値の扱いに改善の余地があった。リリース前なので実運用はしていない。テスト段階で気づけたので、組み立て方を安全な方式に直した。
みっつめは、検索処理での入力値の受け渡し。
ユーザーが入れた検索クエリをAI(Claude)に解析させ、出てきたキーワードでデータベースを検索する流れがあるのだが、その受け渡しの設計に注意が要る箇所があった。これは設計上わかっていれば防げる類だが、わかっていなければ気付きにくい。エンジニアでも見落とすことがあるポイントだ。
ほかにも、ファイル添付欄の入力チェック、レートリミット(連打防止)の挙動、AIへの入力の扱いなど、リリース前に詰めておくべき箇所がいくつか並んだ。
つまり、テスト中のシステムに対して、リリース前にやっておくべき点検が、コマンド一行でひととおり済んだ、ということだ。
Codexセカンドオピニオンで、Wチェックする
ここがこの記事の本題だ。
一通り直して「終わった」と思っていた段階で、CLAUDE.mdに書いてあるルールに従ってCodex MCPに対立的レビューを依頼した。これはClaude本人ではない別ベンダーのAI(OpenAIのCodex)に、わざと「擁護せず容赦なく粗探ししろ」と頼むセカンドオピニオン手順だ。
これがWチェックの2枚目になる。
返ってきた一文目で、少し背筋が伸びた。
結論: まだ確認すべき箇所があります。
そこから追加の指摘が並んだ。最初のClaudeのレビューで直した箇所と同じ構造を持つ別のAPIに、似た改善点が残っていた。1ファイル直して安心したら、同じ構造の別ファイルが残っている、という典型だ。
これも全部直した。直したあと、もう一度Codexに「もういちど見てくれ」と投げる。返ってきたのは「重大な指摘はありません」だった。
つまり、
書くAI(Claude+Q)→ 検証AI 1枚目(security-review)→ 検証AI 2枚目(Codexの対立的レビュー)→ 再点検(Codexにもう一度)
この4工程をリリース前にひととおり通した。これで、リリース前のリスクをゼロに近づけられた。
安心するのは、AIが「もう問題ない」と言ったときではない。同じベンダーの別AIにダブルチェックを通し、それでも何も出てこなくなったとき、初めて安心していい。これがWチェックの意味だ。
「社長、もうずっとこれ繰り返してますよね」
「うん。1日かけた」
「でも、これをリリース前にやれているのが大きいです。リリース後に気づくのとは、まったく意味が違います」
その通りだ。半年前のわたしなら、この点検プロセス自体を持っていなかった。
なぜ非エンジニアにこそ刺さるのか
ここまで書いて伝えたいことは、技術自慢ではない。
逆だ。
わたしは行政書士で、Pythonがどんな言語かさえ正しく説明できない。それでも、Claude Codeのスラッシュコマンド一発で、リリース前の自作システムをひととおり点検し、Codex MCPのセカンドオピニオンでさらに見落としを掘り起こし、最終的にリリース前のリスクを最小限にできた。
これがエンジニアを雇って外注していたら、こうはいかない。
セキュリティ監査の見積もりは、まじめにやると百万円単位だ。1日では終わらない。何より、毎週コードを書き換えるサイクルに監査がついてこない。半年に一回監査する間に、その間に作った機能の安全性が見えなくなっていく。
AIで作るシステムの弱点はここだった。書くのは速いが、書いた後の安全性チェックが追いつかない。AIで書いて、AIで点検し、別ベンダーのAIでWチェックする。このループが回せるかどうかで、AIで作ったシステムを安心してリリースできるかどうかが決まる。
そして、いまそのループは回せる。誰でもできる。最初の一手はコマンド一行だ。
/security-review
書籍『AI秘書の育て方マニュアル』では、Coworkまでの話を中心に書いた。Codeは第7章で軽く触れただけだ。今振り返ると、Codeに踏み込まなかった一番大きな理由は、わたし自身が「コードを書かない人がCodeを使う意義」をうまく説明できなかったからだ。
いま、それを言い直せる。
「Codeを使う意義は、コードを書くためじゃない。書いた後のチェックをAIに任せ、別のAIでもう一度チェックさせるためだ」
セキュリティだけじゃない。コードの可読性、パフォーマンス、テストカバレッジ、デザインの一貫性、すべて同じ理屈で回せる。書くAIと、検証AIと、対立的セカンドオピニオン。この3点セットでリリース前にリスクをゼロまで持っていく。
非エンジニアでもAIで業務システムを作る時代になった。その時代に必要なのは、書く力ではなく、書いた後をどう守るかの構えだ。/security-reviewとCodexセカンドオピニオンのWチェック、これがその構えの最小単位だ。
終わりに、社長への注意書き
「社長、最後に念押ししておきます」
「うん」
「security-reviewが出してくれる指摘は、あくまで『機械が見つけられる範囲のもの』です。仕様レベルの抜け、ビジネスロジック上の権限設計、本気の標的型攻撃みたいな話は、別レイヤーの話です」
「わかってる」
「あと、今回点検した補助金検索NAVIは、まだコミットしてません。明日、もう一度Codexに通してからPRです」
「言われると思ってた」
「言わなくても進めてください。リリース前なんですから、ここで詰めきります」
容赦ない。でも、正しい。
これが、わたしの2026年5月の現在地だ。コードを書かないわたしが、AIに書いてもらったシステムを、リリース前にsecurity-reviewで点検してもらって、Codexセカンドオピニオンレビューで対立的にWチェックし、リスクをゼロまで持っていく。
これが日常になったというだけで、3年前の自分が見たら卒倒すると思う。
/security-reviewのすゝめ、ここまでです。
参考:
Claude Code 公式ドキュメント「Automated Security Reviews」https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code
