ClaudeやChatGPTにコードを書いてもらうのが当たり前になって、プログラムを作るスピードは本当に速くなりました。ただ、動くコードと安全なコードは別物です。「セキュリティに気をつけて書いて」と一言添えるだけで安心していないでしょうか。この記事では、AIにセキュアなプログラムを書かせるためのプロンプトの考え方を、新規にプログラムを作り始める場合と、既存のプログラムを補強する場合の両方に分けて、コピペで使えるテンプレート付きでまとめてみます。
「セキュリティに気をつけて」だけのプロンプトではダメな理由
まず前提として、AIが書くコードはそのままだと結構危ないです。アプリケーションセキュリティ企業のVeracodeが2025年に公開した調査では、100以上の大規模言語モデル（LLM）を対象に、脆弱性が入り込みやすい80個のコーディング課題を評価したところ、生成されたコードサンプルの45%がセキュリティテストに失敗しました。言語別の失敗率はJavaが72%、C#が45%、JavaScriptが43%、Pythonが38%です。
さらに2026年版の調査では、評価対象全体のセキュリティテスト合格率は平均56%にとどまっています。一方で、2025年10月の追加分析では、一部の新しいモデルで合格率の改善も報告されていて、モデルによって差があるのも事実です。ただ、どのモデルでも「正しく動くこと」と「安全であること」は別問題で、生成されたコードは新しさにかかわらず検証してから使う必要があります。だからこそ、こちらが何を求めるかをはっきり伝えるのが大事になってきます。
ここで効いてくるのがプロンプトです。人間の開発現場でも、発注時に「セキュリティに気をつけて作ってください」とだけ言われても、受け手は何をどこまでやればいいのか分かりません。AIも同じで、守るべき対象、想定する攻撃、従うべき基準を具体的に書かないと、とりあえず動くコードを優先して返してきます。曖昧なお願いは曖昧な結果しか生まない、というのは人もAIも一緒です。※個人の感想です。
セキュリティを意識したプロンプトに入れるべき3つの要素
新規開発でも既存コードの補強でも、セキュリティ系のプロンプトに入れておきたい要素は共通しています。大きく分けると「前提条件」「準拠する基準」「出力の形式」の3つです。この3つが揃っていると、AIの回答のブレがかなり小さくなります。逆にどれかが抜けていると、的外れな対策を延々と提案されたり、肝心な部分がスルーされたりしがちです。
前提条件：何を守るプログラムなのかを書く
一番大事なのに一番忘れられがちなのが前提条件です。実行環境（ブラウザなのか、Node.jsのサーバーなのか、PHPなのか）、扱うデータ（個人情報、決済情報、社内データなど）、利用者（ログインユーザーだけか、誰でもアクセスできるか）を書いておくだけで、AIが気にするポイントが変わります。たとえば同じフォーム処理でも、管理画面の中だけで使うのか、公開されたECサイトの購入フォームなのかで、必要な対策の重さはまったく違います。
準拠する基準：OWASP Top 10やIPAの資料を名指しする
次に、どの基準でチェックしてほしいかを名指しします。代表的なのがWebアプリケーションの代表的なリスクをまとめたOWASP Top 10で、2025年版ではアクセス制御の不備が引き続き1位、新たにソフトウェアサプライチェーンの不備と、例外的な状況への不適切な対応がランクインしています。日本語の資料ならIPAの「安全なウェブサイトの作り方」も定番で、SQLインジェクションやクロスサイト・スクリプティングなどについて、根本的解決と保険的対策を分けて整理しています。
こうした基準をプロンプトに書いておくと、AIは「この観点で見ればいいのね」と理解して、チェック漏れが減ります。人間側も、AIの回答をあとで基準と突き合わせて確認できるので一石二鳥です。ちなみにIPAの資料にはチェックリストも用意されているので、チェック項目をそのままプロンプトに貼り付けるのもアリだと思います。
ただし、どちらも万能のチェックリストではありません。OWASP Top 10は主要なリスクを把握するための啓発資料で、これだけですべての脆弱性を網羅できるわけではありませんし、IPAの資料もWebアプリケーションが中心です。デスクトップアプリやローカルで動くツールなら、対象の技術や脅威に合わせてチェック項目を追加で指定しましょう。用途に応じた具体的なセキュリティ要件を自分で決めておくのが前提です。
出力の形式：理由と残るリスクも書かせる
最後が出力の形式です。コードだけ返されると、どこにどんな対策が入ったのか分からず、レビューのしようがありません。「対策した箇所と理由をリストで書く」「対策しきれていない懸念点があれば明記する」「重大度を高・中・低で付ける」などと指定しておくと、回答がそのままレビュー資料として使えます。地味ですが、ここを指定するかどうかで後工程の楽さがだいぶ変わりますね。
新規にプログラムを作り始めるときのセキュリティプロンプト
ゼロからプログラムを作るときは、いきなり「〇〇を作って」とコードを書かせるのではなく、設計の段階でセキュリティを組み込むのがポイントです。OWASP Top 10にも「安全性を欠いた設計」という項目があるように、設計で抜けた穴は後から実装で埋めるのが大変です。最初の一歩でセキュリティ要件を渡しておけば、その後の生成コードもその前提に沿って書かれやすくなります。
いきなりコードを書かせず、まず設計と脅威を洗い出させる
おすすめの流れは「要件の確認 → 脅威の洗い出し → 設計 → 実装」の順で段階を分けることです。一発で全部作らせると、AIは動くことを優先して入力値の検証やエラー処理を省略しがちです。まずは「このプログラムで想定される攻撃と、その対策方針を一覧にして」と頼み、内容を確認してから実装に進むと、抜け漏れに早い段階で気づけます。手間に見えますが、作り直すコストを考えるとこっちのほうが結果的に速いです。
新規開発用のプロンプトテンプレート
実際に使えるテンプレートを置いておきます。【】の部分を自分のプロジェクトに合わせて書き換えてください。ClaudeでもChatGPTでも、チャット型のAIならそのまま貼り付けて使えます。最初の一行で役割を与えているのは、回答の視点をセキュリティ寄りに固定するためです。なくても動きますが、あったほうが指摘の粒度がそろいやすい印象です。
あなたはセキュアコーディングに詳しいシニアエンジニアです。
これから以下のプログラムを新規に作ります。まだコードは書かず、
まず設計とセキュリティ上の脅威の洗い出しをしてください。
## 作りたいもの
【例：会員がログインして注文履歴を見られるWebアプリ】
## 前提条件
- 実行環境：【例：PHP 8.3 / MySQL 8 / Apache】
- 扱うデータ：【例：氏名、メールアドレス、注文履歴】
- 利用者：【例：ログイン済みの会員のみ】
- 認証・認可：【例：会員は自分の注文履歴だけ閲覧可能】
## 準拠する基準
- OWASP Top 10:2025
- IPA「安全なウェブサイトの作り方」
## 出力してほしいもの
1. 想定される脅威の一覧（重大度：高・中・低）
2. 脅威ごとの対策方針
3. 外部ライブラリを使う場合は候補と選定理由
4. 判断に迷う点があれば、推測せず質問として挙げる最後の「推測せず質問として挙げる」は地味に効きます。AIは情報が足りないと、それっぽい前提を勝手に置いて話を進めることがあるので、分からないことは聞き返すように明示しておくわけです。また「認証・認可」の行を分けているのは、ログインしているかどうかの確認と、そのデータを見る権限があるかの確認が別問題だからです。ここを書かないと、ログインさえしていれば他人の注文履歴も見られる、という典型的な穴が残りがちです。
脅威の一覧に納得できたら、「この方針で実装してください。対策の理由は差分ごとの説明文で示し、あわせて実施すべきセキュリティテストも挙げてください」と次のプロンプトに進みましょう。理由をコードのコメントで全部書かせると、コメントが増えすぎて逆に読みにくくなることもあるので、説明文で受け取るほうが個人的には扱いやすいです。
ルールはファイルにまとめて毎回読ませる
毎回同じセキュリティ要件をプロンプトに書くのは面倒ですよね。Claude Codeを使っているなら、プロジェクト直下のCLAUDE.mdにコーディング規約やセキュリティ要件をまとめておくと、プロジェクトの指示として参照させられます。「SQLは必ずプレースホルダを使う」「APIキーなどの秘密情報をソースコードに直書きしない」「エラーメッセージの詳細を画面に表示しない」といった、プロジェクト全体で守りたいルールを箇条書きにしておくイメージです。
チャット型のAIでも、プロジェクトの指示やカスタム指示に共通ルールを設定できます。毎回コピペする方式だと、いつか貼り忘れます。人間は忘れる生き物なので、仕組みで忘れないようにするのが一番ですね。（自分への戒めも込めて）ただし、指示を書いておけば必ずすべてのルールが守られるわけではないので、重要なルールはコードレビューや自動テストでも確認するようにしましょう。
既存のプログラムを補強するときのセキュリティプロンプト
すでに動いているプログラムのセキュリティを補強する場合は、新規開発とは考え方が少し変わります。一番怖いのは、AIが善意で大量のコードを書き換えて、今まで動いていた機能が壊れることです。既存コードには、仕様書に残っていない事情や、他のシステムとのつながりが含まれていることがよくあります。なので「いきなり直させない」が鉄則です。
まずは診断だけ。修正はさせない
既存コードを渡すときは、最初のプロンプトで「修正はせず、問題点の指摘だけ」と明示します。診断結果を見てから、どれを直すかを人間が決めるわけです。AIに全部任せると、優先度の低い細かい指摘と重大な脆弱性が同じ温度で混ざって返ってくることもあります。重大度で並べ替えさせて、上から順に判断していくのが現実的です。
既存コード補強用のプロンプトテンプレート
以下は本番で稼働中のプログラムです。
セキュリティ上の問題点を診断してください。
※この段階ではコードの修正は行わないでください。
## 前提条件
- 実行環境：【例：Node.js 22 / Express】
- 役割：【例：ECサイトの商品検索API】
- 扱うデータ：【例：商品情報、会員ID】
- 変更してはいけない仕様：【例：レスポンスのJSON形式、URL構造】
## チェックの観点
- OWASP Top 10:2025の各項目
- 入力値の検証漏れ、認可チェック漏れ
- 秘密情報のハードコーディング
- 依存パッケージの古いバージョン
## 出力形式
| 重大度 | 該当箇所（ファイル名・行） | 問題の内容 | 想定される攻撃 | 修正方針 |
の表形式で、重大度の高い順に並べてください。
既存の動作に影響しそうな修正方針には、その旨を明記してください。
## 回答のルール
- コードから確認できた事実と、情報不足で推測にとどまる点を区別する
- 各指摘について、問題が成立する条件と想定される影響を書く
- 修正後に実施すべきテストを修正方針に含める
- 実行していないテストや確認していない挙動を検証済みとして書かない
【ここにコードを貼る】ポイントは「既存の動作に影響しそうな修正方針には明記」の一文と、「回答のルール」の部分です。前者があると、AIが修正による副作用まで考えて回答してくれます。後者は、AIの推測を確定した脆弱性として扱ってしまうのを防ぐためのものです。AIはそれっぽく断言してくることがあるので、事実と推測を分けて書かせておくと、人間側の判断がかなり楽になります。
なお、コードをAIに渡す前には、APIキーやパスワード、データベース接続情報だけでなく、個人情報や社内の機密情報、内部URL、ログ、設定ファイルの中身も確認しておきましょう。必要に応じてダミー値に置き換え、利用するAIサービスのデータ取り扱い条件や組織のルールもチェックしておくと安心です。もし本物の認証情報をすでにどこかに貼ってしまっていたら、コードから消すだけでなく、その認証情報の無効化やローテーションも検討してください。ここで漏らしたら元も子もありません。
修正は1件ずつ、小さく直す
診断結果が出たら、修正は1件ずつ依頼します。「重大度・高の1番だけ直してください。変更は最小限にして、差分だけ見せてください」という頼み方です。まとめて直させると、どの変更がどの問題に対応しているのか追えなくなりますし、何か壊れたときに原因の切り分けもしにくくなります。修正ごとに動作確認をして、問題なければ次へ、というのが遠回りに見えて一番安全なルートだと思います。
Claude Codeの/security-reviewも活用する
Claude Codeには、変更箇所のセキュリティ上の問題を確認する/security-reviewというコマンドが標準で入っています。プロジェクトのディレクトリで実行すると、主にコミット前の変更点を対象に、脆弱性の可能性がある箇所とその理由を説明してくれます。コードベース全体を漏れなく診断するスキャナーではなく、あくまで変更差分のレビュー役と考えておくのがよさそうです。
また、GitHub Actionsを別途導入・設定すれば、プルリクエストのたびにセキュリティレビューを自動で走らせることもできます。コマンドを使うだけで自動連携が有効になるわけではないので、ここは混同しないように注意です。どちらも脆弱性をすべて検出できることを保証するものではないため、静的解析や人のレビューと組み合わせて使いましょう。
面白いのは、このコマンドの中身もプロンプトでできている点です。公開されているsecurity-review.mdをプロジェクトの.claude/commands/フォルダにコピーして編集すれば、自分たちの基準に合わせたレビューにカスタマイズできます。つまり、今回紹介したようなチェック観点を書き込んでおけば、オレオレ診断コマンドが作れてしまうわけですね。既存コードの補強を継続的に回したいなら、かなり相性が良い仕組みだと思います。
プロンプトだけに頼らないための注意点
ここまでプロンプトの話をしてきましたが、プロンプトを工夫すれば安全なプログラムが保証される、というわけではありません。AIのレビューはあくまで目のひとつで、静的解析ツールや依存パッケージの脆弱性チェック、人のレビューの代わりにはなりません。Veracodeも、AIが生成したコードはレビューされていないコードと同じように扱い、スキャンと修正を経てから出荷すべきだという立場をとっています。
依存パッケージとサプライチェーンも見る
OWASP Top 10:2025でソフトウェアサプライチェーンの不備が新たに入ったように、自分で書いたコード以外のリスクも無視できません。AIは存在しないパッケージ名や、古いバージョンを平然と提案してくることがあります。提案されたライブラリは、公式サイトやリポジトリで実在性、メンテナンス状況、配布元を確認しておきましょう。
Node.jsのプロジェクトなら、npm auditなどで依存関係に含まれる既知の脆弱性を確認できます。ただし、監査で問題が見つからなくても安全が保証されるわけではなく、悪意あるコードの混入や保守状況の良し悪しまでは判定してくれません。また、依存パッケージのバージョンを上げるときは、破壊的変更や互換性にも注意が必要です。変更内容を確認して、テストを回してから取り込むのが安全です。
AI機能を組み込むならプロンプトインジェクションにも注意
作るプログラム自体にAIの機能を組み込む場合は、もうひとつ別の問題が出てきます。OWASPの「Top 10 for LLM Applications」2025年版では、入力によってモデルの振る舞いを乗っ取るプロンプトインジェクションが1位（LLM01）に位置付けられています。また、システムプロンプトの漏えいも独立したリスク項目（LLM07）として扱われています。プロンプトに書いた内容は、外に漏れうる前提で設計する必要があるということですね。
具体的には、システムプロンプトを秘密情報の保管場所や認可のためのセキュリティ境界として使わず、APIキーやパスワードを書かないこと。そしてAIの出力を信頼できないデータとして扱い、出力先に応じたエスケープやSQLのパラメータ化、サーバー側での認可チェックを行うことです。AIに渡す権限も必要最小限にしておきましょう。AIの出力も「外部から来た信用できない入力」と覚えておけば、大きく外すことはないと思います。セキュリティのためのプロンプトを書く一方で、自分のプロダクトのプロンプトが攻撃の入口になる。なかなか皮肉な話ですね。
まとめ
AIにプログラムを書かせるとき、「セキュリティに気をつけて」という一言だけでは、必要な対策を十分に指定できません。外部の調査でも、AIが生成したコードの半数近くがセキュリティテストに失敗しており、モデルによる差はあるものの、動くコードと安全なコードは別物だと分かります。だからこそ、前提条件、準拠する基準、出力の形式の3つを具体的に書いたプロンプトで、確認すべき観点をはっきりさせることが効いてきます。
新規にプログラムを作り始めるときは、いきなりコードを書かせず、まず脅威の洗い出しと設計から始めるのがポイントです。共通のルールはCLAUDE.mdやカスタム指示にまとめておけば、毎回書く手間も貼り忘れもなくなります。既存のプログラムを補強するときは、まず診断だけを依頼し、重大度の高いものから1件ずつ小さく直していくのが安全です。Claude Codeの/security-reviewのように、レビュー自体を仕組み化できるツールも積極的に使っていきたいところです。
そして最後に、プロンプトはあくまで品質を底上げするための道具で、安全を保証してくれるものではありません。依存パッケージのチェックや静的解析、人の目によるレビューと組み合わせてはじめて、ちゃんとしたセキュリティ対策になります。AIをうまく使いつつ、最終的な判断は自分で下す。この距離感を保てると、開発スピードと安全性のどちらも諦めずに済むはずです。テンプレートは自由に改変して使ってみてください。
【参考文献】
- OWASP Top 10:2025（日本語）
https://owasp.org/Top10/2025/ja/ - 安全なウェブサイトの作り方｜IPA 独立行政法人 情報処理推進機構
https://www.ipa.go.jp/security/vuln/websecurity/about.html - AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks, Veracode Research Reveals｜Veracode
https://www.veracode.com/press-release/ai-generated-code-poses-major-security-risks-in-nearly-half-of-all-development-tasks-veracode-research-reveals/ - Veracode Research Reveals OpenAI’s GPT-5 Models Lead the Way in Secure Code, While Wider Industry Progress Stalls｜Veracode
https://www.veracode.com/press-release/veracode-research-reveals-openais-gpt-5-models-lead-the-way-in-secure-code-while-wider-industry-progress-stalls/ - Veracode Finds AI-Generated Code Security Has Barely Improved Since Last Year｜SD Times
https://sdtimes.com/agentic-security/veracode-finds-ai-generated-code-security-has-barely-improved-since-last-year/ - Automate security reviews with Claude Code｜Anthropic
https://www.anthropic.com/news/automate-security-reviews-with-claude-code - Automated Security Reviews in Claude Code｜Claude Help Center
https://support.claude.com/en/articles/11932705 - anthropics/claude-code-security-review｜GitHub
https://github.com/anthropics/claude-code-security-review - OWASP Top 10 for LLMs 2025: How GenAI Risks Are Evolving｜HackerOne
https://www.hackerone.com/ai/owasp-top-10-llms-2025
