Claude Codeを「読み取り専用」で自社Webアプリを診断したところ、重大な認可不備を含む14件の問題を発見できました。
社内で運用している自社Webアプリを見直したくなったのですが、本番に近いシステムなので、AIにいきなりファイルを触らせるのはちょっと怖いです。
そこで今回は、Claude Codeに「コードは読むだけ。編集や削除はしない」という前提で脆弱性チェックをお願いしてみました。
すると、重大な認可不備を含む14件の問題が見つかりました。
しかも、見つけて終わりではなく、優先度順に整理しながら改善案まで出してもらえたので、かなり実務的でした。
この記事では、実際にどう進めたのか、どこまでAIに任せて、どこを人が判断したのかをまとめます。
※具体的な攻撃手順や詳細コードは載せず、公開しても問題ない範囲で運用の型だけを書いています。
「読むだけ」で見てもらう形にした理由
今回チェックしたのは、社内で運用している自社のWebアプリです。
自分で作ったシステムでもあるので、だいたいの構造は分かっています。
ただ、認可や入力検証まわりは、作っている本人ほど思い込みで見落としやすいです。
とはいえ、本番運用中のシステムに対して、AIにそのまま修正を入れさせるのは抵抗があります。
そこで今回は、最初から「ファイルは編集しない」「削除しない」「静的に読んで指摘だけする」という形で進めました。
これなら、システムを壊すリスクを増やさずに、第三者レビューに近い視点だけを先に取り入れられます。
実際にやった流れ
やったことはシンプルです。
1. Claude Codeにアプリ一式を読んでもらう
2. 見つかった問題を深刻度つきで整理してもらう
3. Before / Afterの修正方針を出してもらう
4. 実際の修正は自分で1件ずつ反映する
5. ブラウザや実機で確認する
今回は、指摘内容をExcelにまとめて、重要なものから順番に対応していきました。
この進め方の良かったところは、AIはレビュー担当、人間は修正と確認担当にきれいに役割分担できたことです。
実際に見つかった問題
今回見つかったのは合計14件でした。
その中でも、特に優先度が高かったのは次のような内容です。
1. 認可まわりの重大な不備
2. ログイン保護の弱さ
3. 管理画面まわりのアクセス制御不足
4. 入力値の扱いで見直したい箇所
5. 公開領域の扱いで気になった実装
6. 認証まわりの整合性不足
もちろん14件すべてが同じ重さではありません。
ただ、1件目のような「権限チェックと実際の処理対象の結びつきにズレがある」タイプの不備は、かなり危ないです。
自分で作っていると見落としやすいポイントでもあるので、ここを最初に拾えたのは大きかったです。
▼ ClaudeCodeに実際に出力してもらったExcel一覧
いちばんインパクトが大きかったのは認可まわりの不備
今回いちばん印象に残ったのは、認可まわりの不備でした。
ざっくり言うと、「チェックしている条件」と「実際に処理される対象」がきれいにつながっていない状態です。
この手の問題は、画面上では普通に動いて見えるので、普段の動作確認だけだとなかなか気づきにくいです。
でも、レビューとしてコードを読み解いていくと、処理のつながりの違和感として見えてきます。
「ちゃんと本人確認しているから大丈夫」と思っていたところに穴があったのは、かなり学びになりました。
AIに任せてよかったところ
今回、AIにレビューを任せてよかったのは、単に「怪しいです」と言うだけで終わらなかったことです。
どこが危ないのか、なぜ危ないのか、どう直すべきかを優先度順に整理してもらえたので、次にやるべきことがすぐ見えました。
特に助かったのは、修正案がBefore / Afterの形で出てきたことです。
こちらはその内容を見ながら、1件ずつ自分で反映できます。
いきなり全部を丸投げしなくていいので、安心感がありました。
もうひとつ大きかったのは、「読んでもらうだけでも十分価値がある」と分かったことです。
AI活用というと、つい「自動修正」まで期待しがちですが、実務ではまずレビュー役として使うだけでもかなり強いです。
最後は人が修正して、人が確認した
ここは大事なのですが、今回の修正はClaude Codeが直接ファイルを書き換えたわけではありません。
実際にやったのは、AIが出した指摘と改善案を見ながら、自分で修正して、自分で確認する流れです。
たとえば、
1. 想定していない値が送信されていないかをブラウザで確認する
2. ログイン制限が本当に効くかを実機で試す
3. 権限のない状態で管理機能に入れないことを確認する
4. 想定外の入力で不自然な動きにならないかを確かめる
といった形で、修正後の挙動までひとつずつ見ています。
この流れにしておくと、AIの提案をうのみにせずに済みますし、レビュー結果をそのまま品質改善につなげやすいです。
このやり方がよかった理由
今回のやり方でよかったのは、次の3点です。
1. AIに本番系ファイルを触らせずに済む
2. 指摘内容を優先度つきで整理できる
3. 修正と確認の責任を人間側で持てる
特にセキュリティまわりは、便利さよりも安全さを優先したほうが安心です。
その意味でも、「まずは読むだけでレビューさせる」という使い方はかなり相性がよかったです。
自分のシステムで試すなら
もし自分のシステムでも試すなら、最初は次の形がおすすめです。
1. AIには最初に「編集しない」「削除しない」と明示する
2. 認可、入力検証、レート制限、管理画面保護あたりを優先して見てもらう
3. 指摘は深刻度順に並べてもらう
4. 修正は1件ずつ人が反映する
5. 実機確認まで終わってから次に進む
あと、これはかなり大事ですが、脆弱性チェックの詳細レポートは共有範囲に注意したほうがいいです。
件数やカテゴリ、効果の共有はしやすいですが、攻撃手順まで分かる生のレポートは、そのまま広く配らないほうが安全です。
まとめ
今回やってみて思ったのは、AIは「全部自動で直す道具」として見るより、「安全にレビューの視点を増やす道具」として使うほうが、かなり実務向きだということです。
実際、今回はファイルを一切触らせずに、重大な不備を含む14件の問題を洗い出せました。
しかも、修正の優先順位づけや改善案づくりまで進められたので、読み取り専用レビューとしては十分すぎる成果でした。
自社システムや社内ツールを持っている方は、まずは「読むだけレビュー」から試してみると、思った以上に発見があるかもしれません。
最短で最大の成果を上げる AIアウトプットの全技法
AIで「3か月で5億円」を実現した著者が明かす、全60の技法を完全公開
発売10日で5万部突破！コピペで使えるプロンプト満載、AIで本当に「結果を出す」人になるための一冊です。