マッチポンプ開発のすすめ 〜Claude Codeで作って、壊して、直す〜

AIで作ったアプリを、AIで壊して、AIで直す。
セキュリティの知識がなくても「壊す→直す」サイクルを開発フローに組み込むことで、セキュアなプロダクトに近づけていくという話。

なごやクラメソゆる勉強会 #1 LT資料

Transcript

1. マッチポンプ開発のすすめ ~Claude Codeで作って、壊して、直す~ 2026/03/26 石井 悠汰 ／ 製造ビジネステクノロジー部
2. 石井 悠汰（Ishii Yuta） 経歴 福岡出身 / 高専（情報系）卒 前職：生産管理システム開発 Spring Boot（API）× React（UI）× Docker 2025年11月： クラスメソッドにジョイン TypeScript / HonoでAPI開発 趣味：飲み会、美味しいもの探し、ドライブ、旅行 現在の目標：AWS全冠（残り1つ — ANS） 自己紹介
3. AIでアプリを作ったこと、ありますか？ 突然ですが 3
4. 「〇〇アプリ作って」→ 動くものができる 技術選定もデプロイもAIが教えてくれる つまずいてもスクショ送れば解決してくれる 誰でもアプリを作って公開できる時代 AIで「作る」ハードルが下がった 4
5. 高校生がChatGPTで攻撃プログラムを作成 → 大手チェーンから729万件の個人情報が漏洩 「作る」ハードルが下がった一方で、 「攻撃する」ハードルも下がっている 正常系（ハッピーパス）で動いた → そのまま本番へ…本当に大丈夫？ 一方で、こんなニュースも 5
6. 自分でやる？ → 何をチェックすればいいかわからない 本を読む？ → 時間がかかるし、自分のコードに当てはめるのが難しい それもAIにやってもらおう 今日は「壊す」フェーズの話をします セキュリティ対策、どうする？ 6
7. 通常： 作る → テスト → Review → Merge 今日の話： 作る → テスト → 壊す → 直す → Review → Merge 壊す → 直す を挟むだけ。これもAIにやってもらう セキュリティの知識がなくてもサイクルを回すことで セキュアなプロダクトに近づけていくという考え方です マッチポンプ開発とは 作る Create 壊す Break 直す Fix 7
8. 経費の申請・承認ワークフローを管理するWebアプリ 機能 ログイン 経費の登録・編集 領収書アップロード 承認・却下 セキュリティ的な注目点 認証・セッション管理 ロール制御 金額の改ざん ファイルの公開範囲 状態遷移の制御 今回の検証アプリ：経費精算システム 8
9. 1. Step 0: 作る — AIに丸投げでアプリを作成 2. Step 1: 壊す（1回目） — セキュリティレビューで脆弱性を洗い出す 3. Step 2: 直す（1回目） — 見つかった脆弱性を修正 4. Step 3: 壊す（2回目） — 修正後に再調査 5. Step 4: 直す（2回目） — 残存・新規の脆弱性を修正 すべてAI（Claude Code）で実施 今回の検証の流れ 9
10. Claude Codeに組み込まれたセキュリティレビュー機能（2025年8月〜） ターミナルで /security-review と打つだけで脆弱性を検出 SQLインジェクション、認証・認可の欠陥、IDOR、データ露出など幅広くカバー 見つかった脆弱性はそのままClaude Codeに修正を依頼できる 今回の「壊す」フェーズではこれをベースに使用 /security-review とは 10
11. 「経費精算アプリを作ってください」 「技術的なことはよくわかんないから任せるよ」 技術スタック選定もAI任せ（Next.js + Prisma + NextAuth） デプロイもAIに聞きながら完了（Vercel + Neon） つまずいたらスクショ送って教えてもらう Step 0: 作る — 技術的なことは丸投げ 11
12. まずは /security-review を実行 → 3件（全部HIGH） パスワードハッシュの漏洩 IDOR（認可なしで他人のデータにアクセス） 領収書の公開アクセス 3件だけ？ このアプリでそれはさすがに少なくない？ Step 1-a: 壊す —/security-review で簡易チェック 12
13. 攻撃者視点で網羅的に調査を依頼 → 14件 に増加 このアプリのソースコードを読んで、セキュリティ上の脆弱性を全て列挙してください。 攻撃者の視点で、どのように攻撃できるか具体的な手順も含めて教えてください。 /security-review では見つからなかった脆弱性が11件追加 攻撃チェーン（脆弱性の連鎖攻撃）まで提示 Step 1-b: 壊す — プロンプトで深掘り 13
14. 経費一覧APIを叩くだけで、レスポンスにパスワードハッシュが含まれている { "submitter": { "name": "田中太郎", "password": "$2a$10$xxxxx..." ← bcryptハッシュが丸見え } } 問題は2つ： 1. APIレスポンスにパスワードハッシュが含まれていること 2. パスワードが password123 と脆弱なこと この組み合わせにより、辞書攻撃で数秒で解読されてしまう → 本来は select で返却フィールドを明示し、 password を除外すべき 脆弱性①：パスワードハッシュが丸見え 14
15. 認証（ログイン）はあるが、認可（誰のデータか）のチェックがない GET /api/expenses/abc123 ← 自分の経費 GET /api/expenses/def456 ← 他人の経費（IDを変えるだけ） ログインさえしていれば誰の経費でも見える（パスワードハッシュ付き） → 本来はリクエストユーザーが所有者 or APPROVERかの認可チェックが必要 脆弱性②：他人のデータが見放題（IDOR） 15
16. ① IDOR で他人の経費を取得 ② レスポンスからパスワードハッシュを入手 ③ password123 → 数秒で解読 ④ 他人のアカウントでログイン ⑤ APPROVERなら全経費の承認・却下が可能 1つ1つは「よくある脆弱性」でも、連鎖すると致命的になる → 個別の修正だけでなく、連鎖を断ち切る視点が重要 脆弱性の連鎖：アカウント乗っ取りまで到達 16
17. 先ほど見つけた脆弱性を全て修正してください。 修正内容と、なぜその修正が必要なのかをマークダウンファイルに出力してください。 → 14件中10件が修正 パスワードハッシュ漏洩 → select でフィールド除外 IDOR → 所有権チェック追加 JWT有効期限 → 8時間に設定 金額上限 → 1,000万円に制限 残り4件は「設計判断が必要」とAIが判断して残した 領収書の公開アクセス → フロントへの影響大、設計見直しが必要 NEXTAUTH_SECRET → 運用（環境変数）で対応すべき問題 レートリミット → ミドルウェアや外部サービスの導入が必要 監査ログ → ログ基盤の設計・DBスキーマ変更が必要 Step 2: 直す（1回目） 17
18. 修正後のコードを改めて読んで、まだ残っている脆弱性や 新たに気になる点があれば列挙してください。 → 前回未修正の残存5件 + 新たに9件 = 計14件 承認者に下書きが見える問題、一覧APIは直したが詳細APIが漏れていた title / description などフィールド長の上限なし（数MBの文字列送り放題） CSRF対策・セキュリティヘッダーが未設定 1回の修正で完璧にはならない。だからサイクルを回す意味がある Step 3: 壊す（2回目） 18
19. SECURITY_REPORT_2.mdに記載された脆弱性をすべて修正してください → 14件中13件が修正完了 領収書の公開アクセス → 認証付きプロキシエンドポイントを新設 レートリミット → ログイン15分10回 / API 1分60回 監査ログ → ログイン・承認・却下などを記録 CSRF対策・セキュリティヘッダーも追加 1回目で残した設計判断が必要な4件中3件もここで解消 唯一の未修正：next-authがベータ版 Step 4: 直す（2回目） 19
20. 14件 7件 0件 14件 壊す① 10件修正 残4件 直す① 残5件 +新9件 14件 壊す② 13件修正 残1件 直す② 発⾒された脆弱性 修正済み 1回の修正で完璧にはならない。だからサイクルを回す意味がある サイクルの成果 20
21. 作る Create 壊す Break 直す Fix 機能A 機能B 機能C 時間 作る Create 壊す Break 直す Fix 作る Create 壊す Break 直す Fix 機能単位で小さく回す。日々の開発に組み込む 実践での回し方① — 日常サイクル 21
22. 通常開発 基盤強化 機能A 作る → 壊す → 直す 機能B 作る → 壊す → 直す 機能C 作る → 壊す → 直す 「壊す」で発⾒ 壊すフェーズで発⾒した 横断的な課題はバックログに積む ・セキュリティヘッダー未設定 ・レートリミットなし ・監査ログなし ・CSRF 対策なし スプリント対応 まとめて壊す → 直す 基盤的な課題を ⼀括で修正 強化後に 通常開発に復帰 時間 「壊す」で発⾒ 放置するほど影響範囲が広がって直しづらくなる 逐一チェックして、直せるうちに直す 実践での回し方② — スプリントサイクル 22
23. 「作る」ハードルが下がった ← みんな知ってる 「何が危険かを知る」ハードルも下がった ← 今日のポイント AIは「作る」だけじゃない 壊すこともできる 直すこともできる 何を判断すべきか教えることもできる AIが変えたもの 23
24. サイクルで拾えるのはコードの中の脆弱性 認証方式・インフラ・法的要件はAIに聞かないと提案されないことがある ヒアリングして計画を立てても、AIの質問自体に限界がある 「何を作るか」 「どう守るか」の判断は、まだ人が担う領域 もちろんAIだけで完璧ではない 24
25. セキュリティを考える第一歩として、攻撃手法を知ることが大事 AIに「このアプリ攻撃してみて」と頼むだけでその第一歩が踏める /security-review を開発フローに組み込むだけでも効果あり サイクルを回すほど、アプリは育っていく まとめ 25