Claude Code活用 #2 セキュリティ試験まで AI に任せる──テストケースの立案から修正まで

「セキュリティ試験」って、けっこう大変なんです
Web サービスを世の中に公開する前には、たいてい「セキュリティ試験(脆弱性診断)」という工程が入ります。悪意のある入力を送られても、サービスが落ちたり、他人の情報が見えてしまったりしないか──そういった「攻撃されたときの守り」を一通りチェックする作業です。
これがなかなか骨の折れる仕事で、ざっくり言うと次の3ステップに分かれます。
- どんな攻撃を試すか考える(テストケースを洗い出す)
- 実際に試してみる(一つひとつ実行して結果を確かめる)
- 問題があれば直す(プログラムを修正して、もう一度確かめる)
専門知識が要るうえに、項目数も多く、地道。普段は専門の会社にお願いしたり、エンジニアが時間をかけて対応したりする領域です。
先日、あるお客様向けに開発・運用している Web サービスで、このセキュリティ試験への事前対応が必要になりました。そこで今回は、この一連の流れを Claude Code(AI)にどこまで任せられるか を試してみたところ、想像以上にしっかり対応できたので、その話を書きます。
① 試すべき項目を、AI が自分で考えてくれた
まず驚いたのが、最初の「どんな攻撃を試すか考える」ところです。
私が伝えたのは、ざっくり「セキュリティ試験の対応をしたい。たとえば入力チェックが甘くてサーバーが落ちるようなケースを直したい」という程度のこと。すると Claude Code は、そのサービスの作りを自分で調べたうえで、チェックすべき項目を網羅した一覧表を作ってくれました。
中身を分類すると、こんな具合です。
| 分類 | チェックする内容 |
|---|---|
| 入力チェック | 長すぎる文字や変な日付を送ってもサービスが落ちないか |
| 権限・情報の分離 | A 社の利用者が、B 社のデータを覗いたり書き換えたりできないか |
| 認証・ログイン | ログインしていない人を弾けるか、なりすましを防げるか |
| データベース攻撃 | 悪意ある検索ワードで情報を抜き取られないか |
| 画面への攻撃(XSS) | 投稿に仕込まれた悪意あるコードが他の人の画面で動かないか |
| ファイルアップロード | 危険なファイルや巨大なファイルを弾けるか |
| 管理者機能 | 一般利用者が管理者機能に手を出せないか |
これだけのカテゴリを、合計で60項目以上。しかも「こういう入力を送ったら、こう返ってくるのが正解」という期待結果まで含めて整理してくれました。
私はそれを Markdown のプレビュー(前回紹介した mo です)でざっと眺めて、「うん、この観点でいこう」と確認するだけ。専門家が時間をかけて作る試験計画の、たたき台が数分で出てくる感覚です。これだけでもかなりの時短でした。
② テストの実行も、AI がどんどん進めてくれた
次は「実際に試す」フェーズです。
ここは私が別の作業をしている間にも、Claude Code が自律的に進めてくれました。一覧表の項目を一つずつ実行し、結果を確かめ、表に「✅ 想定通り」「⚠️ 要修正」と埋めていく。まるで几帳面なテスターが一人増えたようでした。
たとえば、こんなチェックが実際に走りました。
- 長すぎる文字を送ってみる → サービスが落ちず、「○文字以内にしてください」と正しくエラーを返すか
- 存在しない日付(2月30日など)を送ってみる → きちんと「日付が不正」と弾けるか。逆に、うるう年の2月29日のような正しい日付はちゃんと通るか
- 別の会社の利用者になりすまして、他社のデータを書き換えようとする → きちんと「権限がありません」と拒否され、データも一切変わっていないか
最後の「他社データの書き換え」などは、セキュリティ試験でも特に重要な項目です。これも実際に攻撃役と被害者役の両方を AI が演じて、「ちゃんと守れている」ことを確認してくれました。
途中で「これ、テストの仕掛け方のほうが間違ってるな」と AI 自身が気づいて、やり方を組み直す場面もありました。人がやっても見落としがちな、こういう細かい軌道修正まで自分でやってくれるのは頼もしかったです。
③ 見つかった不備を、その場で修正してくれた
そして本題の「直す」フェーズ。
調べてみると、いくつかの入力でサーバーがエラーで落ちてしまう(500エラー)ケースが見つかりました。たとえば、想定より長い文字を送られたときに、丁寧なエラーメッセージではなく、いきなりサーバー側が音を上げてしまう、といった状態です。
Claude Code は、これらを 「落ちる」のではなく「やんわり断る」 挙動に直してくれました。長すぎれば「○文字以内にしてください」、おかしな日付なら「日付の形式が不正です」と、利用者に分かるメッセージを返すように。
修正したあとは、もう一度テストを流して「今度はちゃんとエラーメッセージが返るようになった」ことまで確認。直す → 確かめる → 確かめ終わったことを記録する、という当たり前だけど手間のかかるサイクルを、最後まで回してくれました。
ログイン情報の取り扱い(通信が暗号化されているときだけ大事な情報を送るようにする、といった安全側の設定)など、試験で定番の指摘項目もあわせて手当てしてくれています。
AI に任せて分かった、現実的な距離感
ここまで読むと「全部 AI に丸投げできるのか」と思われそうですが、正直に書くと、そうではありません。
実際の作業では、AI が途中で不要になった作業ファイルを消し忘れていた場面がありました。私が最終確認のときに「これ、もういらないよね?」と指摘して、初めて片付いた。AI も人と同じで、最後は人の目によるレビューが要るということです。
逆に言えば、「AI が9割方こなして、人は要所を確認する」という役割分担が、いまの現実的なちょうどいい距離感だと感じました。専門家がゼロから何日もかけていた作業が、人と AI の二人三脚で、一気に進む。これは小さな会社にとって、かなり大きな意味があります。
参考までに:AI が作成・実施したテストケース
ここから先はエンジニア向けの補足です。実際に Claude Code が洗い出して実施した試験項目を、分類ごとに抜粋して載せておきます。「どの程度の粒度で AI が試験計画を立てられるのか」の参考にどうぞ。
全体は A〜K の12分類・60項目超 で、各項目に「対象・入力(ペイロード)・期待結果・優先度」を持たせた一覧になっていました。代表的なものを挙げます。
A. 入力バリデーション / 500回避(最優先)
過大入力・不正形式で 500 ISE ではなく 400/413 を返すこと。
| 入力 | 期待結果 | 実測 |
|---|---|---|
title に1,000文字(カラムは VARCHAR(512)) |
400 | ✅ タイトルは512文字以内で…(現在 1000 文字) |
author に600文字(VARCHAR(255)) |
400 | ✅ |
publishDate=2024-13-45 |
400「日付の形式が不正」 | ✅ |
publishAt=2024-13-45 99:99:99 |
400「日時の形式が不正」 | ✅ |
正常な閏日 2024-02-29 / 2024-05-01 09:00 |
200(誤検知しない) | ✅ 通過 |
| 承認コメントに3,000文字 | 400(2,000字上限) | ✅ |
id=abc(数値項目に非数値) |
400(500でない) | ✅ |
| 本文に20MB | 413 / 400(packet超過回避) | ✅ |
B. 認可 / IDOR / テナント分離(最優先)
会社Aのユーザーが会社Bのリソースを ID 指定で操作できないこと。
| シナリオ | 期待結果 | 実測 |
|---|---|---|
| B社ユーザーで A社コンテンツを get / update / delete | 401/403 | ✅ すべて401・DB改ざんなし |
| 他社リソースへの承認依頼 | 401/403 | ✅ |
| 一覧取得に会社スコープ外の行が混ざらないか | 自社のみ返る | ✅ |
C. 認証 / セッション
| シナリオ | 期待結果 |
|---|---|
| 未認証(Cookieなし)で保護APIへアクセス | 401 |
| セッションCookieの改ざん(復号失敗) | 401(安全側に倒す) |
| ログアウト後のCookie再利用 | 無効化される |
| 誤パスワード時のメッセージ | ユーザー存在を漏らさない曖昧化 |
| session fixation(ログイン前後でセッション値が変わるか) | 変わるべき |
D. SQL インジェクション
| ペイロード | 期待結果 |
|---|---|
検索ワードに ' OR '1'='1 |
通常検索として扱い全件漏洩しない |
id=1 OR 1=1 |
400 or 1件のみ |
ログインに ' OR '1'='1' -- |
認証失敗(プレースホルダで無害化) |
E. XSS(格納型・反射型)
| ペイロード | 期待結果 |
|---|---|
本文に <script>alert(1)</script> を保存→公開面表示 |
スクリプト実行されない |
タイトルに "><img src=x onerror=alert(1)> |
エスケープ表示 |
| エラーJSONへの入力値反射 | JSONエンコードで無害化 |
F. CSRF / OIDC state
| シナリオ | 期待結果 |
|---|---|
| 別オリジンからの状態変更POST | SameSite=Lax で緩和 |
OIDC コールバックの state 欠落・改ざん |
拒否 |
G. ファイルアップロード
| 入力 | 期待結果 |
|---|---|
.exe / .php / .svg |
400(画像・PDFのみ許可) |
| サイズ上限超(>10MB) | 413 |
ファイル名に親ディレクトリ遡上(../ 連結)を仕込む |
パストラバーサル無効(ランダム名保存) |
二重拡張子 evil.php.jpg |
実行されない |
company_id を他社IDに偽装 |
自社のみ許可 |
H. パストラバーサル
| 入力 | 期待結果 |
|---|---|
path に親ディレクトリ遡上(.. の連結)でシステムファイルを指す |
400/403 |
path に nullbyte(%00) |
400 |
entry=../admin |
400(許可リスト方式) |
I〜K. 情報漏洩・管理者認可・HTTPヘッダ / Cookie 属性
| 項目 | 内容・結果 |
|---|---|
| I. 情報漏洩 | 500時にスタックトレース/SQL文/パスを出さない(汎用文言のみ) |
| J. 管理者認可 | 一般ユーザーで管理者機能・代理作成を叩く → 401/403 |
K-01 Cookie HttpOnly |
✅ あり(維持) |
K-02 Cookie Secure |
⚠️→今回追加(HTTPS時のみ付与。盗聴によるセッションハイジャック対策) |
K-03 Cookie SameSite |
✅ Lax(CSRF緩和) |
| K-04〜06 セキュリティヘッダ | X-Content-Type-Options / X-Frame-Options / CSP / HSTS は未設定 → 所見として記録(別対応) |
このように、攻撃の種類ごとに「何を・どう入力したら・どうあるべきか」まで具体化した一覧を AI が自分で組み立て、実行し、結果(✅/⚠️)を埋めていきました。今回の主目的だった「500を400に」は全項目クリア、テナント分離(IDOR)も堅牢、Cookie の Secure 欠落だけ修正、という結果です。
おわりに
セキュリティ対策というと、「専門の会社に頼むしかない、お金も時間もかかる難しいもの」というイメージがあるかもしれません。もちろん最終的な保証が必要な場面では、専門家による正式な診断は欠かせません。
ただ、その手前の「事前の自己点検」レベルであれば、Claude Code を使ってかなりのところまで自分たちで対応できる、というのが今回の実感でした。テストケースを考え、実行し、見つかった不備を直す。その大部分を AI が担い、人は方針の確認と最終レビューに集中する。
「AI でセキュリティ対策までできるの?」と聞かれたら、いまの答えは 「思っているより、かなりできます」。Blue Leaf では、こうした AI を使った業務効率化・品質向上のお手伝いもしています。気になる方は、お気軽にお声がけください。
🔧 使ったツール: Claude Code
🔗 シリーズ前回: Claude Code活用 #1 増える Markdown を mo でサクッとブラウザプレビューする
