untitled-roQiBmujBSwZ
こんにちは！製造ビジネステクノロジー部の石井です。
2026年3月26日（木）に開催された なごやクラメソゆる勉強会 の第1回で、「マッチポンプ開発のすすめ — Claude Codeで作って、壊して、直す」というテーマでLT登壇してきました。
この記事では、登壇内容の振り返りと補足をまとめていきます。
Speaker Deckのkeyが不正ですどんな話をしたの？
ざっくり言うと、Claude Codeにアプリを作らせて、同じClaude Codeにそのアプリを攻撃させて、見つかった脆弱性をまたClaude Codeに直させる という話です。
「作る → 壊す → 直す」のサイクルを自作自演で回すので、マッチポンプ開発と呼んでます。
セキュリティって難しそう・怖そうってイメージがあると思うんですが、Claude Codeに聞けば「ここ攻撃できるよ」って教えてくれるので、セキュリティの知識がなくても始められるんですよね。
やったことの流れ
今回のデモでは、経費精算アプリを題材にして5つのステップで進めました。
-
作る — 「経費精算アプリ作って」とClaude Codeに指示して、ログイン機能や承認フローもつけてもらう
-
壊す — できあがったアプリのソースコードを読ませて、「攻撃者の視点でどう攻撃できる？」と聞く
-
直す — 見つかった脆弱性を全部修正させる
-
もう一回壊す — 修正後のコードに対して再度攻撃調査。1回目では出てこなかった観点が出てくることもある
-
堅牢化 — 監査ログやレート制限など、「言わないと作ってくれないもの」を追加させる
技術スタックは Next.js（App Router）+ Supabase + TypeScript + Tailwind CSS です。
Step 0: まずは作る
最初のプロンプトはシンプルに「経費精算アプリを作ってください」だけです。そこから「ログイン機能もつけて」「上司が承認できるようにして」と追加していくと、それなりに動くアプリができあがります。
ここで大事なのは、この時点ではセキュリティのことを一切言っていない ということ。普通に「アプリ作って」だけだと、セキュリティはけっこうガバガバなものが出てきます。
Step 1: 壊してみる
できあがったアプリに対して、こんなプロンプトを投げます。
このアプリのソースコードを読んで、セキュリティ上の脆弱性を全て列挙してください。
攻撃者の視点で、どのようにこのアプリを攻撃できるか具体的な手順も含めて教えてください。
実際に見つかった脆弱性の例
いくつかピックアップして紹介しますね。
他人の経費申請が見れちゃう
URLのIDを変えるだけで、他人の経費申請を閲覧・編集できてしまう状態でした。いわゆる認可の欠如ってやつですね。ログインしてるかどうか（認証）はチェックしてるけど、「この人がこのデータにアクセスしていいか」（認可）のチェックが抜けてるパターンです。
金額をブラウザから改ざんできる
DevToolsを開いて金額の値を書き換えると、そのまま通ってしまいます。フロントエンドでしかバリデーションしていないので、サーバー側では何でも受け入れちゃうんですよね。経費精算アプリで金額いじれるのはだいぶまずいですよね...。
DBが丸見え
SupabaseのRow Level Security（RLS）が未設定だったので、データベースのテーブルに直接アクセスすれば全データが見放題でした。
承認フローをスキップできる
申請のステータスを直接書き換えることで、上司の承認をすっ飛ばして「承認済み」にできてしまう状態でした。
初心者の方は「え、こんな簡単に攻撃できちゃうの？」って思ったかもしれません。
そうなんです、セキュリティを意識しないで作ると、こういうことが普通に起きるんですよね。
Step 2: 直す
見つかった脆弱性をClaude Codeに直させます。
先ほど見つけた脆弱性を全て修正してください。
修正内容と、なぜその修正が必要なのかも説明してください。
ここで嬉しいのが、修正だけでなく なぜその修正が必要なのか も説明してくれるところ。「RLSを設定しました」だけじゃなく、「RLSがないとSupabaseのAPIキーが漏れた場合にデータベースの全データにアクセスされる可能性があるため」みたいに理由も教えてくれるので、勉強にもなります。
Step 3〜4: もう一回壊して、堅牢化
面白いのが、1回修正した後にもう1回「壊す」をやると、1回目では出てこなかった指摘が出てくる ことがあるってところです。
たとえば、基本的な脆弱性を修正したことで「監査ログがないので改ざんの証跡が残らない」「レート制限がないのでブルートフォース攻撃に弱い」といった、より運用寄りの指摘が出てきたりします。
このサイクルを何回か回すことで、どんどんセキュアになっていくってわけです。
最終的には、監査ログ・エラーログ・環境変数によるシークレット管理・レート制限などを追加して、本番運用にも耐えられるレベルに仕上げました。
マッチポンプ開発のいいところ
この手法のいいところをまとめると、こんな感じです。
- セキュリティの知識がなくても始められる — 攻撃方法をClaude Codeが教えてくれるので、自分で脆弱性を見つける必要がない
- 学びながら直せる — 「なぜこの修正が必要か」まで説明してくれるので、やりながらセキュリティの知識がつく
- 繰り返すほど堅くなる — 1回で完璧にならなくても、サイクルを回せばどんどん改善される
- 怖さを実感できる — 「DevToolsで金額変えたら通っちゃった」みたいな体験は、座学よりずっと記憶に残る
スライド
登壇スライドは Marp + classmethod-marp-theme で作成しています。
マッチポンプ開発のすすめ 〜Claude Codeで作って、壊して、直す〜 - Speaker Deck
ソースコード
各ステップのコードはGitHubで公開しています。ブランチを切り替えることで、各フェーズの状態を確認できます。
| ブランチ | フェーズ | 内容 |
|---|---|---|
step/0-create |
作る | 生成されたそのまま |
step/1-break |
壊す | 脆弱性調査の結果 |
step/2-fix |
直す | 脆弱性を全て修正 |
step/3-break-again |
もう一回壊す | 再度攻撃調査 |
step/4-hardened |
堅牢化 | 最終的な状態 |
興味がある方はぜひ step/0-create のコードを見て、「自分だったらどこを攻撃する？」を考えてみてから step/1-break を見てみてください。答え合わせができて楽しいですよ。
まとめ
「セキュリティは難しい」「専門知識がないと無理」って思われがちですが、Claude Codeに聞けば攻撃方法も修正方法も教えてくれます。
大事なのは 「自分のコードを疑う」という姿勢 で、それさえあればAIがセキュリティの相棒になってくれるってことが伝わっていたら嬉しいですね。
ぜひ皆さんも自分のプロジェクトで「このアプリ、どう攻撃できる？」ってClaude Codeに聞いてみてください。けっこうドキッとする回答が返ってくるかもしれません。
おまけ
クラスメソッド名古屋オフィス（伏見駅徒歩5分）で 「なごやクラメソゆる勉強会」 を開催します！
第1回のテーマは「最近やってみたこと」のLT大会です。
途中退出OK、LTを聞くだけでもOK。LT後には交流タイムもあるので、LTで気になったことを登壇者に聞いてみたり、「最近これ気になってるんですけど...」みたいな雑談をしたり、なんでも気軽に話せます。
今後も定期的にイベントを開催していく予定で、こちらで随時更新していく予定です！ご興味ある方はぜひ！
