AIコーディング入門講座④前編：Claude Codeで公開前の脆弱性を洗い出す

Claude Codeで作ったアプリを人に使ってもらう前に、脆弱性を洗い出して本物だけに絞る手順です。49件の指摘が9件になるまでの前編。

「そろそろ人に使ってもらおう」と思ったところで、手が止まりました。動くのは確認しました。でも、安全なのかどうかは、まったく分かりません。

前編のゴールは、出てきた指摘の全件を【本物】【誤検知】【対策済み】に仕分け、見逃すと痛いもの（危険度「高」と、秘密情報・権限まわりで【誤検知】になったもの）は自分の手でも確かめた状態です。ここまでは前編だけで終わります。本物を直して公開するのは後編です。

この記事を読むと得られるもの

• 7つの観点（確かめる項目のこと）を指定して、見なかった観点が黙って抜け落ちない形でClaude Codeに監査をかけられるようになります

• AIが出した脆弱性（悪用されると情報漏れなどにつながる、アプリの穴）の指摘を、本物・誤検知・対策済みの3つに仕分けさせられるようになります（わたしの実測では、49件が9件）

• コードが1行も読めなくても、指摘が本当かどうかを自分の手で試せるようになります

• そのためのプロンプト24本（差し替え用の再掲を含む）と判断表1枚を、コピペできる形で持ち帰れます

前編を読み終えた時点で手元に残るのは、仕分け済みの指摘の一覧（security-audit.md）です。どれを直せばよいかが、ここで確定します。本物と確定した指摘を直し、APIキーの漏れに対処し、公開の時期を決めるところは、後編で扱います。

こんな人におすすめ

・Claude Codeで作ったアプリを、そろそろ人に使ってもらいたい人
・セキュリティが不安だけれど、何をどう確認すればいいか分からない人
・AIに指摘された内容が本当に危ないのか、自分では判断できない人

こんな人には向いていません

・お金の決済や医療情報など、事故の被害が重いものを扱っていて、この記事だけで済ませたい人（専門家の診断の代わりにはなりません。併用する前提なら役に立ちます）
・すでにコードを読めて、脆弱性の指摘を自分で真偽判定できる人
・Claude Code以外のツール（Cursor、GitHub Copilotなど）での手順を探している人
・ターミナル（パソコンに文字でコマンドを打つ画面）を開くこと自体に強い抵抗がある人。この記事でターミナルを使うのは数回だけです

このシリーズの6テーマ・9記事について

Claude Codeでアプリを作り、公開し、育てていくまでを6つのテーマ・9本の記事に分けて書いています。番号は読む順です。①から順に読むと「作る→直す→公開する→育てる」の流れになります。④⑤⑥は分量が多いので、それぞれ前編・後編の2本に分けてあります。

① 要件定義編 ── 「思っていたのと違うものができる」を、作る前に防ぐ
② 計画→実装編 ── 「頼んだのにやってくれない」の正体を知って、Auto Modeに任せる
③ 不具合対応の基本編 ── 直したバグが別の画面で再発するのを止める
④ セキュリティ監査編（前編・後編） ── 動くけれど安全か分からないアプリを、確かめてから公開する （この記事は前編）
⑤ 技術的負債編（前編・後編） ── 増えたコードのどこが危ないかを、壊さずに洗い出す
⑥ なぜなぜ分析と横並びチェック 完全版（前編・後編） ── 「他に該当なし」でも再発するのを、機械で止める

はじめてアプリを作るなら①→②→③。人に使ってもらう前に④。アプリが育ってきたら⑤⑥へ進んでください。テーマ①〜⑥はどれから読んでも単体で完結します。ただし④⑤⑥の後編は、前編で作ったものを手元に置いて進む前提です。

9本とも、コードを書いたことがない方が読める形にしてあります。④⑤⑥はコマンドの結果を読む場面が出てきますが、打つのはほぼClaude Codeなので、読んで判断できれば足ります（④で自分で打つのは数回だけです）。

9本を通して一貫しているのは、AIの出力をそのまま信じないという姿勢です。要件定義書も、実装も、AIが出したバグや脆弱性の指摘も、要所で人間が確かめます。その確かめ方を各記事で具体的に扱っています。

動くのは確認した。でも、安全かどうかは分からない

わたしは自分のアプリで実際に監査をかけて、49件の指摘を9件まで絞り込みました。この記事は、そのときに使ったプロンプトと判断の順番を、そのまま置いていくものです。

先に結論を言います。危ないのは脆弱性そのものではありませんでした。指摘の大半が空振りだと知らないまま、全部を直そうとして手が止まること。こちらのほうが厄介でした。その見分け方が、この記事の中心です。

Claude Codeでアプリを作ると、思ったより早く動くものができます。自分で試して、ちゃんと動きました。これで完成、と思いたくなります。

でも「自分が想定した使い方で動く」ことと、「想定していない使われ方をされても壊れない」ことは、まったく別の話です。

そして後者は、動作確認ではまず見つかりません。自分では試さない使い方を確かめるのが、セキュリティ監査だからです。

非エンジニアのアプリで起きやすいのは、この4つ

派手な攻撃ではありません。もっと地味なものです。

・APIキーやパスワードを、ソースコードに直接書いたまま公開してしまう
・エラーの詳細が画面に出る設定のまま公開し、内部の構造が丸見えになる
・URLの数字を1つ書き換えるだけで、他人のデータが見えてしまう
・ログに個人情報がそのまま残り続ける

どれも動作確認では、問題だと気づけません。動くからです。まずはこの4つを、自分のアプリに当てはめてみてください。1つでも心当たりがあれば、監査をかける価値があります。

「セキュリティ監査をしてください」で、本当に動く

Claude Codeに次の一言を打つだけで、監査は実際に始まります。特別な設定も、プラグインも要りません。

このプロジェクトのセキュリティ監査をしてください。

これでClaude Codeはプロジェクトのファイルを読み込み、危険そうな箇所を探し、指摘の一覧を返してきます。わたしもこの一言から始めました。

拍子抜けするくらい簡単です。まずはこれを打ってみてください。打つだけで何かは出てきます。

問題は、そのあと返ってきた一覧を前にして起きます。

一言だけだと2つの穴が空く

この一言のままでは実用になりません。理由は2つあります。

穴1：何を見て、何を見なかったのかが分からない

一言で頼むと、Claude Codeは「セキュリティ」という言葉から自分で観点を組み立てます。そのとき何を見て、何を見なかったかは、こちらには分かりません。

3件の指摘が返ってきたとします。それが「3件しか問題がなかった」のか「3つの観点しか見なかった」のか。区別する方法がありません。

塞ぎ方は決まっています。観点をこちらから指定し、「問題なし」も含めて観点ごとに報告させる。これだけで、見ていない領域が黙って抜け落ちるのを防げます。

穴2：指摘の大半が、実は問題ではない

こちらのほうが深刻です。

わたしが実際にセキュリティ監査をかけたとき、候補として49件の指摘が返ってきました。ずらっと並んだ一覧を見て、ひやっとしました。

そして最初は、素直に上から順に直しにかかりました。途中でアプリが動かなくなって、そこから元に戻すのに時間を取られています。あのとき先に反証をかけていれば、その手間は要りませんでした。わたしは、言われたものを順番に片づけたくなる性格です。

そこで1件ずつ「これは本当に今も成立するのか」を反証する形で確かめました。すると、本物だったのは9件。残り40件、つまり8割は空振りだったことになります。

この記事でいう空振りとは、「直す必要がなかった指摘」のことです。中身は2種類あります。そもそも成立していなかった誤検知と、指摘された懸念自体はあるけれど、すでに対策が入っていたもの。どちらも手を動かす必要はありません。

この「8割」は、わたしのプロジェクト1件で出た数字です。規模も言語も違うあなたのアプリで、同じ比率になる保証はありません。

それでも共有する価値があると思うのは、空振りが一定量まざるという性質のほうは、プロジェクトによらないからです。AIによるセキュリティ分析は、疑わしいものを幅広く挙げる方向に設計されています。実際、公式の/security-reviewコマンド（Claude Codeに最初から入っている、セキュリティ点検用のコマンド）にも、確信度の低い指摘を自動で捨てる仕組みがわざわざ入っています（有料エリアの「ステップ2：公式の/security-reviewコマンドも使う」で説明します）。作り手が承知しているくらい、空振りは前提なのです。

健康診断で「要精密検査」と言われた項目の多くが、精密検査すると問題なしになるのと同じ。比率は人によりますが、精密検査をせずに全部を病気とみなす人はいません。

問題は、非エンジニアには「どれが本物か」を自力で判断できないことです。

コードが読めれば「ああ、これはこの前段で弾いてるから大丈夫だ」と分かります。読めないと、49件すべてが同じ重さに見えてしまいます。結果として、全部直そうとして手が止まるか、逆に全部無視するかの二択になります。

「AIの指摘をAIに検証させても意味がないのでは」

ここは自分でも引っかかったところなので、先に答えておきます。

指摘を出したのも、検証するのも同じAIです。そのまま「この指摘は正しいですか」と聞けば、自分の指摘を擁護する方向に働きます。だから、そのまま聞いてはいけません。

対策は2つあります。

1つは、立場を反転させて聞くこと。「この指摘は間違っていると仮定して、反証してください」と頼むと、成立しない理由を積極的に探しにいきます。49件が9件になったのは、この反転をかけた結果です。

もう1つは、AIの判定を最終判定にしないことです。監査のときに「この指摘が本物かどうかを、私自身が確かめるにはどうすればよいか」まで書かせておきます。

すると、コードを読まずに自分で試せる手順が返ってきます。「ブラウザでこのURLの末尾の数字を変えて、他人のデータが出るか見てください」といった形。最後は自分の目で確かめられます。

この2つの具体的な頼み方を、このあと全文で置いていきます。

監査は3つの層に分かれる

もう一つ、全体像を示しておきます。セキュリティのチェックには深さの違う層があり、それぞれ役割が違います。

真ん中の層と一番下の層は、打つプロンプトは同じです。違うのは、範囲を絞るか全体にかけるかと、いつやるかだけです。

「別のClaude」というのは、同じ会話の中身を知らない、まっさらな状態のClaudeがもう1つ動く、という意味です。自分が書いたものを自分で採点させない、という設計になっています。

一番上の層は、公式のプラグインを入れるだけで自動的に働きます。ただし動く条件があります。

なかでも引っかかりやすいのが、作業フォルダがgitで管理されていることです（もう1つ、Python〈プログラムを動かすための土台のひとつ〉が入っていることも要ります）。gitは、ファイルの変更履歴を全部残しておく仕組みのこと。ここを外していると、この層の点検の大半が、画面には何も出ないまま止まります。「何も言われない＝安全」ではないので、条件は先に確かめてください。どの点検がどう止まるかの細かい話は、後編で扱います。

一番上の層の入れ方と条件は、後編にまとめてあります。前編で扱うのは真ん中の層、つまり「頼んだとき」の監査です。

7つの観点のうち、1つを置いていきます

わたしが使っている監査プロンプトは、7つの観点を指定する形になっています。そのうち観点3を、そのまま貼っておきます。

このプロジェクトのうち、権限のチェックだけを対象に
セキュリティ監査をしてください。

3. 権限のチェック
   ログインしている本人以外のデータを、URLやIDの書き換えだけで
   閲覧・更新・削除できてしまう箇所がないか。
   管理者向けの機能に、権限の確認が入っているか。

問題がなかった場合も「問題なし」と報告してください。
専門用語を使う場合は、必ずかっこ書きで平易な言い換えを
添えてください。

これだけでも打てます。わたしの49件では、7つのうちこの観点3の指摘がいちばん多く出ました。URLの数字を書き換えると他人のデータが見える、というやつがここで出ます。

件数とは別に、出たときの深刻さが一番大きいのは観点1の「秘密情報の埋め込み」です。この2つは役割が違うので、両方見ます。

残り6つの観点と、各指摘に何を書かせるかの指定は、ここから先にまとめてあります。

ここから先で手に入るもの

• 7観点の監査プロンプト全文（上に出した観点3を含む完全版。範囲を絞る差し替え版つき）

• 49件を9件に絞った反証プロンプトと、指摘が読めないときの聞き返しプロンプト

• ステップ0から反証まで、コピペで使えるプロンプト24本（うち、ステップ1のプロンプトの1行目と置き換える差し替え用の冒頭3本）とスラッシュコマンド1本（どこに打つかの印つき）

• 判断表1枚（危険度の目安4行）

• 公式コマンド/security-reviewの使い分け表 ・よくあるつまずき4件と、その場で打てる対処プロンプト

• 翌日どこから再開するか、長いプロンプトが送信されてしまうときの貼り方、などプロンプトのあいだで詰まる箇所の埋め方

所要時間の目安は、監査をかけるところまでで15〜30分。反証は指摘の数しだいで、10件なら15分、数十件なら1〜2時間です。公開の3日前には着手してください。工程ごとの内訳も、有料エリアの冒頭に表で置いてあります。

3本以上読むなら、マガジンのほうが安く済みます

このシリーズは9本（6テーマ）とも有料で、各680円です。9本そろえると6,120円になります。前編・後編も1本ずつ680円です。

マガジン「AIコーディングの開発手法」は1,500円で、このシリーズをまとめてあります。今後追加する回も、追加料金なしで読めます。

3本以上読むつもりなら、マガジンのほうが安いです。この記事1本（680円）で足りるなら、そのまま下へ進んでください。読める中身は同じものです。