見出し画像

/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


いいなと思ったら応援しよう!