AIが生成したコードを画面に開き、動くことは確認できたうえで「これ、セキュリティは大丈夫だろうか」ともう一段落ち着いて見直している開発者
テスト・品質約16分

AI生成コードのセキュリティ確認｜見落としやすい穴の型

AIに書いてもらったコードが、ちゃんと動いた。テストも通った。 ほっとして、そのままコミットしようとした手が、ふと止まる——「これ、動くのはわかったけど、セキュリティ的に大丈夫なんだっけ」。

APIキーがそのまま書かれていないか。ユーザーの入力をそのままクエリに入れていないか。出力をエスケープせずに画面へ返していないか。AIが生成したコードは「動く」ことは得意でも、「安全である」ことは保証してくれません。動作確認では緑になるのに、セキュリティの穴だけは静かにそこに残る——このすれ違いは、AIコーディングでいちばん見落とされやすい場所のひとつです。

「AIを使え」と急かされている現場ほど、スピードは出るけれど、この一段だけ確認が飛ばされがちです。でも大丈夫。セキュリティのすべてを毎回見張る必要はありません。穴が空きやすい場所は、だいたい決まっています。まずそこだけ立ち止まれるようになれば、大きな踏み外しの多くは防げます。今日は、その「見るべき場所」を一緒に整理していきましょう。

結論：AI生成コードのセキュリティは、穴が空きやすい3カ所を先に見ると効率よく確認できます。①入力と出力の境界（外から来た値をそのままクエリ・コマンド・画面に流していないか＝インジェクション/XSS）／②秘密と権限（APIキーやパスワードのべた書き、認可チェック漏れがないか）／③依存とデフォルト（AIが提案したライブラリが実在し安全か、verify=False やワイルドカード許可のような危険な初期設定が混ざっていないか）。明日からできるのは、(1) 外部入力がクエリ・コマンド・HTMLに直接つながる箇所を探して、パラメータ化・エスケープされているか見る → (2) 秘密情報のべた書きと、権限チェックの有無を確認する → (3) 追加されたライブラリと危険なデフォルト設定を洗うの3つ。末尾にレビュー用プロンプトとチェックリストを置きました。なお本記事は一般的な実務情報です。重要なシステムでは、必ず自社のセキュリティ担当や専用ツールの確認も併用してください。

セキュリティの確認は、AIを疑って足を止めるためではありません。 「これは安心して本番に出せるコードだ」と自分で言えるようにするための、最後のひと手間です。

なぜAIのコードは「動くのに危ない」ことがあるのか

AIは、大量のコードを学習して「よくある書き方」を再現します。だから多くの場合、それらしく動くコードが返ってきます。ただ、学習元には急ぎで書かれた例やセキュリティが甘い例も混ざっていて、AIは「動く書き方」と「安全な書き方」を必ずしも区別しません。

しかも、セキュリティの穴は動作確認ではまず見えないのが厄介なところです。

つまり「テストが緑だから安全」ではないのです。安全かどうかは、攻撃者の視点で、わざと変な値を入れたらどうなるかを別に確かめないとわかりません。ここはAIが自動でやってくれない部分で、人が意識して見る必要があります。とはいえ闇雲に全部を疑うと疲れてしまうので、次の3カ所に的を絞ります。

穴が空きやすい3カ所を先に見る

AI生成コードでセキュリティの穴が空きやすい「入力と出力の境界」「秘密と権限」「依存とデフォルト」の3カ所を示した概念図
全部を疑うのではなく、穴が空きやすい3カ所から。ここを押さえれば大きな踏み外しは防げる

セキュリティの穴は無数にあるように感じますが、AI生成コードで実際によく出るものは、大きく3カ所にまとまります。この順で見ると、少ない手間で効きます。

3つとも、AIが「動くコード」を作るときに素通りしやすい場所です。次から一つずつ、具体的に何を見るかを見ていきます。

①入力と出力の境界を見る

いちばん被害が大きくなりやすいのが、外から来た値の扱いです。AIは「まず動く形」を優先するため、入力を検証せずそのまま使うコードを返しがちです。

見るコツはシンプルです。「外から来た値」を目でたどり、それがクエリ・コマンド・HTML・ファイルパスに触れる瞬間に、加工（パラメータ化・エスケープ・検証）が挟まっているかを確認する。ここだけでも、大きな穴の多くは見つかります。

②秘密と権限を見る

APIキーのべた書きと認可チェック漏れという2つの見落としを、コードを指さしながら確認している開発者の場面図
「鍵がむき出しになっていないか」「その操作をしてよい人か確かめているか」の2点を先に

次に、秘密情報と権限まわりです。ここは「うっかり」で起きやすく、しかも漏れると影響が大きい場所です。

ポイントは、「鍵がむき出しになっていないか」と「その操作をしてよい人か確かめているか」の2点を、機能の正しさとは別に必ず一度見ることです。動作確認では素通りしてしまう部分だからこそ、意識して目を向けます。

③依存とデフォルトを見る

3つ目は、AIが追加した「材料」と「初期設定」です。地味ですが、ここも穴になりやすい場所です。

依存とデフォルトは、機能そのものには見えないので後回しにされがちです。でも、追加されたライブラリの一覧と、初期値・設定まわりをさっと一度洗うだけで、見つかる穴は少なくありません。

場面ごとに、かける手間を変える

3カ所すべてを毎回フルで見るのは続きません。扱うものの重さで手間を変えるのが現実的です。

場面リスクかける手間
個人の実験・使い捨てスクリプト低秘密のべた書きだけ確認すればOK
社内ツール・限定利用中①入出力の境界＋②秘密と権限を確認
外部公開・ユーザー入力を受ける高3カ所すべて＋依存の脆弱性チェックを実行
個人情報・決済・認証に触れる高自己判断せず、セキュリティ担当・専用ツールも併用

大事なのは、全部を最高レベルで疑わないことです。すべてに全力を出そうとすると確認が形骸化して、本当にこわい所を見逃します。「外部に公開する・ユーザー入力を受ける・機密や決済に触れる」——このどれかに当てはまるときにだけ、しっかり手をかければ十分です。

こういうときは、特に立ち止まる

以下は、セキュリティの穴が残りやすい「サイン」です。ひとつでも当てはまったら、コミット前にもう一段だけ丁寧に見る合図と考えてください。

これらは「危険だから怖がれ」という合図ではありません。どこで一段だけ丁寧に見ればいいかの目印です。目印を知っていれば、それ以外の場所では安心してスピードを出せます。

ありがちな落とし穴と、その回避

落とし穴の多くは、「動いたから大丈夫だろう」で確認を飛ばすことから来ます。 でも、見るべきなのは毎回すべてではありません。入出力の境界・秘密と権限・依存とデフォルト——この3カ所。そこにだけ目を向ければ、負担を増やさずにリスクは大きく減らせます。

明日からやること（小さく始める3つ）

一度に全部を仕組み化しようとすると続きません。まずこの3つから。

  1. 外部入力がクエリ・コマンド・HTMLに触れる箇所を探し、加工が挟まっているか見る：パラメータ化・エスケープ・検証のどれかが入っているか。ここがいちばん被害が大きい場所です。
  2. 秘密のべた書きと、権限チェックの有無を確認する：鍵がむき出しになっていないか、その操作をしてよい人か確かめているか。
  3. 追加されたライブラリと、緩いデフォルト設定を洗う：名前は実在するか、verify=False や全許可が紛れていないか。可能なら依存の脆弱性チェックを一度実行。

この3つだけでも、「なんとなく不安」が「どこを見ればいいか分かっている」に変わります。 慣れてきたら、依存の脆弱性チェックをCIに組み込んだり、チームで観点を共有したりと、少しずつ広げていけば十分です。

コピーして使う「AI生成コード セキュリティ確認プロンプト」

AIにレビューさせる一次チェックとして使うと、観点の抜けが減ります。ただしAIの指摘は当たり外れがあるので、最後は必ず人が確認する前提で。

以下のコードを、セキュリティの観点だけでレビューしてください。
機能の良し悪しではなく、攻撃者の視点で「悪用できる穴」を探してください。

次の3カ所を重点的に見て、該当箇所を行単位で指摘してください。
1. 入力と出力の境界：外部入力がクエリ・コマンド・HTML・ファイルパスに
   検証やエスケープなしで流れていないか（インジェクション/XSS/パストラバーサル）
2. 秘密と権限：APIキー・パスワード等のべた書き、認可（権限）チェックの抜け、
   エラーやログからの情報漏れがないか
3. 依存とデフォルト：実在しない/古い/脆弱なライブラリ、verify=False や
   CORS全許可・デバッグ有効などの危険な初期設定がないか

各指摘には「なぜ危険か」「どう直すか」を短く添えてください。
判断に自信がない箇所は「要人間確認」と明記してください。

--- 対象コード ---
（ここにコードを貼る）

AI生成コード セキュリティチェックリスト

コミット前・公開前に、1項目ずつ「○／要確認／該当なし」を付けながら使ってください。各セクションの ★印は「これだけは外せない最低ライン」。忙しい日は★だけ、残りは余裕のある日に——と読んでください。

①入力と出力の境界

②秘密と権限

③依存とデフォルト

共通

最後に

AI生成コードのセキュリティを気にするのは、AIを疑って臆病になるためではありません。 「これは安心して本番に出せるコードです」と、自分の言葉で言えるようにするための、最後のひと手間です。

セキュリティの話は、専門用語も多くて身構えてしまいますよね。でも、現場のエンジニアに求められるのは、セキュリティ専門家になることではありません。穴が空きやすい3カ所を知っていて、そこで一段だけ立ち止まれること。それだけで、あとで冷や汗をかく場面の大半は防げます。

今日できたのが、コードの中の鍵のべた書きをひとつ見つけて外しただけでも、それはもう「動いたからOK」で流さなかった、確かな一歩です。

よければ、こちらも

書いたコードの確認をもう少し体系立てたいなら、AI生成コードのレビュー・検証チェックリストや、AIにレビューさせてもバグが残る——人が見るべき観点、そして最低限の動作確認をそろえる生成コードをそのまま使わない動作確認の型とあわせて読むと、AIコードの「こわさ」を一つずつ減らしていけます。

セキュリティの確認を終えて「これで安心して本番に出せる」と納得し、前を向いて一息つく開発者

すべてを一度に完璧にする必要はありません。 穴が空きやすい所を一つ、今日ちゃんと確認できたなら、それで十分です。明日また一つ、落ち着いて積んでいきましょう。

関連用語