アプリ開発講座⑤セキュリティ監査編

AIの脆弱性指摘49件を9件に絞った手順

Claude Codeにセキュリティ監査をさせたら49件の指摘が返り、1件ずつ反証をかけたら本物は9件でした。空振りを見分けるプロンプトと、監査をやる時期をまとめます。

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

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

・AIが出した脆弱性の指摘を、本物・誤検知・対策済みの3つに仕分けさせられるようになります（わたしの実測では、49件が9件）
・コードが1行も読めなくても、指摘が本当かどうかを自分の手で試せるようになります
・いつ監査をやり、いつやらなくていいかを、その場で判断できるようになります
・書いている最中から自動でチェックさせる仕組みを、自分の環境に合わせて入れられるようになります
・そのためのプロンプト33本と判断表3枚を、コピペできる形で持ち帰れます

こんな人におすすめ

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

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

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

「動いている」と「安全」を同じだと思うのが、一番怖い

わたしは自分のアプリで実際に監査をかけて、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コマンドにも、確信度の低い指摘を自動で捨てる仕組みがわざわざ入っています（後述します）。作り手が承知しているくらい、空振りは前提なのです。

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

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

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

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

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

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

対策は2つあります。

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

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

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

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

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

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

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

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

なかでも引っかかりやすいのが、作業フォルダがgitで管理されていることです。gitは、ファイルの変更履歴を全部残しておく仕組みのこと。ここを外していると、画面には何も出ないまま、点検だけが行われません。「何も言われない＝安全」ではないので、条件は先に確かめてください。

条件の全部と確かめ方は、ここから先にまとめてあります。

このシリーズの5記事について

Claude Codeでアプリを作り、育てていくまでを5本に分けて書いています。

① 要件定義編 ── 何を作るかを、Claude Codeに伝わる形で言葉にする
② 計画→実装→テスト・なぜなぜ分析編 ── 仕様書からアプリを組み上げ、不具合を根本から直す
③ 技術的負債を、AI自身にあぶり出させる ── まだ表面化していない問題を、先回りで洗い出させる
④ AIのなぜなぜ分析が浅くなる理由と、2軸の横並びチェック ── 見つけた1件を、二度と再発しない形で直しきる
⑤ セキュリティ監査編 ── 人に使ってもらう前に、危ない箇所を洗い出す （この記事）

番号は公開順です。読む順ではありません。はじめてアプリを作るなら①②、人に使ってもらう前に⑤、アプリが育ってきたら③④、の順が自然です。どの記事から読んでも単体で完結します。

5本とも、コードを書いたことがない方が読める形にしてあります。③④はコマンドの結果を読む場面が出てきますが、打つのはClaude Codeなので、読んで判断できれば足ります。

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

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

このシリーズは5本とも有料です。1本ずつ買うと、①500円・②780円・③980円・④780円・⑤980円。5本そろえると4,020円になります。

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

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

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

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

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

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

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

これだけでも打てます。7つのうち、指摘が一番よく出るのがこの観点3です。URLの数字を書き換えると他人のデータが見える、というやつがここで出ます。

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

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

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

・7観点の監査プロンプト全文（上に出した観点3を含む完全版。範囲を絞る差し替え版つき）
・49件を9件に絞った反証プロンプトと、指摘が読めないときの聞き返しプロンプト
・ステップ0から最後まで、コピペで使えるプロンプト34本とスラッシュコマンド5本（どこに打つかの印つき）
・判断表3枚（危険度の目安4行・実施タイミング12行・定期監査の頻度4行）
・公式コマンド/security-reviewの使い分け表と、自動チェックプラグインの導入手順（動く条件・上限・費用・止め方つき）
・よくあるつまずき5件と、その場で打てる対処プロンプト
・プロンプトとプロンプトのあいだで詰まる箇所の埋め方（APIキーを外したあとアプリが動かなくなる、翌日どこから再開するか、など）

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