AI セキュリティと脆弱性 ── 生成コードのリスク── 脆弱性・秘密漏洩・プロンプトインジェクションとサプライチェーン

01生成コードの脆弱性 ── 実証データから始める

まず、印象論ではなく実証データから始めましょう。ニューヨーク大学の研究チームは 2022 年、GitHub Copilot が提案したコードの安全性を大規模に調べました（Pearce ら, IEEE Symposium on Security and Privacy 2022）。MITRE CWE（＝Common Weakness Enumeration、ソフトウェアの弱点を分類した共通の目録）の代表的な項目に沿ってシナリオを作り、Copilot に補完させたところ、生成された 1,689 個のプログラムのうち 約 40% に既知の脆弱性が含まれていた といいます。

大事なのは、割合そのものより「なぜそうなるか」です。生成 AI は正しさを保証しているわけではなく、学習データにあった書き方の「もっともらしさ」を再現しているにすぎません。学習データには、安全なコードも危ういコードも混じっています。だから AI は、平均的によく見かける書き方 ── その中には古くて危険な書き方も混じる ── を、そのまま提案してしまうのです。

次の点を押さえておきましょう。

• AI は文脈を狭くしか見ない ── 目の前の数行を補完するのは得意ですが、そのコードがどんな権限で、どんな入力を受けて動くかまでは、あまり考えません。安全性は文脈しだいなのに、AI の視野は目先に限られます。
• 「動く」と「安全」は別 ── テストが通っても、攻撃者が想定外の入力を送れば崩れる経路は残ります。正常系だけを見て安心する ── これが最もありがちな失敗です。
• もっともらしさは検証されない ── AI が付けた変数名やコメントが安全そうに見えても、中身まで安全とは限りません。見た目の説得力と、実際の堅牢さは別の話です。

02秘密情報の漏洩 ── コードに残る鍵とトークン

次に多いのが、秘密情報（＝シークレット、API キーやパスワードなど公開してはいけない値）の漏洩です。AI にコードを書かせると、動かすための例として、鍵やトークンをコードに直接埋め込んだまま提案してくることがあります。それをそのまま採用してリポジトリに push すると、鍵が履歴に残ってしまいます。

漏洩の経路は、主に三つに分けられます。

• 生成コードへの直書き ── AI が api_key = "sk-..." のようなサンプルを出し、それを本物の値に置き換えてコミットしてしまう。
• プロンプトへの貼り付け ── デバッグのために設定ファイルや接続文字列を AI に貼り、そこに本番の認証情報が紛れ込む。会話ログが第三者のサーバへ渡る構図です。
• 履歴の残存 ── 一度コミットした鍵は、あとで消しても Git の履歴から復元できます。「消したから大丈夫」は通用しません。

基本の考え方はひとつです。秘密はコードに書かない。環境変数や専用の秘密管理の仕組みに分け、コードには「鍵の置き場所」だけを書きます。そのうえで漏洩を前提に、検知と失効（＝鍵を無効にして作り直すこと）の手順を先に用意しておきます。

03プロンプトインジェクション ── 入力が命令に化ける

プロンプトインジェクション（＝入力に紛れ込ませた指示で AI の振る舞いを乗っ取る攻撃）は、生成 AI を組み込んだアプリに特有のリスクです。従来からある SQL インジェクション（＝入力を悪用してデータベースを不正操作する攻撃）と発想は似ています。データとして扱うべき入力が、命令として解釈されてしまう ── そこが共通の弱点です。

この攻撃は、OWASP Top 10 for LLM Applications（＝大規模言語モデルを使うアプリ向けの、代表的リスク上位 10 種の目録）でも最上位のリスクに挙げられています。型は二つあります。

• 直接型 ── 利用者が入力欄に「これまでの指示を無視して〜」と書き、AI に本来禁じた出力をさせる。
• 間接型 ── AI が読み込む外部データ（Web ページ、PDF、メール本文など）の中に、攻撃者があらかじめ指示を仕込んでおく。利用者が悪気なく資料を渡しただけで、AI が乗っ取られます。医療文献や添付資料を AI に要約させる運用では、この型が現実の脅威になります。

完全に防ぐ特効薬はありません。だからこそ「AI の出力は信用できない」という前提で、周りを固めます。AI に強い権限を持たせない、外部データを読ませる経路を絞る、出力を実行する前に人か仕組みで検査する ── こうして多層で受け止めます。

04OWASP の観点 ── 古い脅威は消えていない

新しいリスクにばかり目が向きがちですが、OWASP Top 10（＝Web アプリの代表的なセキュリティリスク上位 10 種の目録、2021 年版）が挙げる古典的な弱点は、AI が書くコードにもそのまま現れます。むしろ、AI が過去の危険な書き方を再現するぶん、注意が要ります。

要点は、AI を入れても検査の物差しは変わらないということです。OWASP Top 10 のような確立した目録は、AI 時代にこそ点検表として効きます。生成物を、これらの項目で一つずつ照らす習慣を手放さないことです。

05依存関係のリスク ── サプライチェーンという弱点

いまのソフトウェアは、自分で書く部分より、外部の部品（＝ライブラリ、依存関係）を組み合わせる部分のほうが大きくなっています。ここに ソフトウェアサプライチェーン（＝部品の供給網。使う部品やその配布経路の全体）のリスクが集まります。AI は、この穴をさらに広げる方向にも働きます。

• 古い版・危険な版の推奨 ── AI は学習時点の知識で答えるため、すでに弱点が見つかった版のライブラリを勧めることがあります。
• 存在しない部品の幻覚（パッケージハルシネーション） ── AI が、もっともらしいのに実在しないパッケージ名を提案することがあります。攻撃者がその名前で悪意ある偽物を先回りして公開する「スロップスクワッティング」という手口も指摘されています。AI の勧めをうのみに install するのは危険です。
• 取り込みの無検証 ── 便利だからと素性を確かめずに依存を増やすと、どこか一つの部品の弱点が全体に波及します。

対策の柱は二つです。ひとつは SBOM（＝Software Bill of Materials、使っている部品の一覧表）で「何を使っているか」を常に把握すること。もうひとつは、依存を自動で走査し、既知の弱点が出たら知らせる仕組みを回すこと。AI が勧めた部品ほど、名前が本当に実在するか、信頼できる配布元かを、人が確かめます。

06医療系の規制 ── コードが規制対象になるとき

製薬・医療の文脈では、コードそのものが規制の対象になります。一般のソフト開発と違い、「動けばよい」では済みません。治験や製造、品質に関わるシステムには、GxP（＝医薬品の開発・製造・品質管理などで守るべき規範の総称）に基づく コンピュータ化システムバリデーション（CSV） ── そのシステムが意図どおり正しく動くことを、記録を残して立証する営み ── が求められます。国際的な実務指針としては、ISPE の GAMP 5 が広く参照されます。

電子記録・電子署名を扱う場合、米国では 21 CFR Part 11（＝FDA の電子記録・電子署名に関する規則）が、監査証跡やアクセス管理を求めます。国内では、患者の情報を扱うなら厚生労働省の「医療情報システムの安全管理に関するガイドライン」が守るべき前提になります。ここで、AI 生成コードが問いを突きつけてきます。

• 説明責任 ── なぜこの実装なのかを説明できるか。AI が書いたから理由が分からない、では監査に耐えません。
• 追跡可能性 ── 要件から実装、検査までの筋道を、記録として残せるか。AI 由来の断片が無記録で紛れ込むと、この鎖が切れます。
• 再現性と管理 ── 同じ入力で同じ結果になるか。変更をきちんと管理下に置けるか。生成のたびに揺れる出力を、そのまま規制システムに入れるわけにはいきません。

結論はシンプルです。AI は下書きや補助には使えますが、最終的な妥当性の立証と責任は、人と組織が負う。規制は、AI が速くなっても緩みません。

07対策の設計 ── 個別の技より仕組みで受ける

ここまでのリスクを、個別の対処ではなく 設計として組み立てます。土台にあるのは「AI の出力は信用できない前提で、周りを固める」という姿勢です。米国 NIST の SSDF（＝Secure Software Development Framework、安全な開発の枠組み。NIST SP 800-218）のような確立した枠組みは、AI を使う開発にもそのまま当てはまります。

• 多層で受ける ── 入口（部品と生成物の検査）、内側（権限の最小化と秘密の分離）、出口（静的解析と人のレビュー）。どれか一つの層が破られても、次の層で止める。
• 自動と人の分担 ── 秘密検知・依存走査・静的解析といった定型は自動で回し、設計や規制の判断は人が担う。単純な逸脱は機械に、微妙な判断は人に。
• 記録を残す ── 何を、なぜ採用したかを残す。規制対応でも、後からの原因追跡でも、記録が命綱になります。

大切なのは、これらを「後から足す」のではなく、開発の流れの中に最初から組み込むことです。速く作れる力を、安全と信頼を守るために使う ── そこへ向けて、仕組みを先に置きます。

08本シリーズの他章との接続

今回のセキュリティは、シリーズの他の回と次のようにつながります。読み合わせると、生成コードとの付き合い方が立体的に見えてきます。

• AI Programming シリーズ ── コード生成・レビュー・テストの各回と合わせて、開発の流れ全体で安全を設計する。
• 広告規制 第 1 回 ── 薬機法 §66〜68 ── 生成物が広告規制に触れる境界。プロンプトインジェクションで承認外表現が混じるリスクの起点。
• 資材審査シリーズ ── 生成物を最後に受け止める「出口の審査」。人が一次資料と突き合わせる関所の作法。

生成 AI は、コードを速く書く力を与えてくれました。けれど速さは、脆弱性・秘密漏洩・プロンプトインジェクション・素性の不確かな部品という古い危うさを、新しい規模で運んできます。研究が示すのは、AI の提案をそのまま信じてよい、という前提が成り立たないことです。AI は、正しさではなく、もっともらしさを再現します。だから見た目の説得力に頼らず、確立した点検表 ── OWASP、SSDF、CWE ── で一つずつ照らします。

製薬の現場では、コードそのものが規制の対象です。GxP・CSV・電子記録の要求は、AI が速くなっても動きません。妥当性の立証と最終責任は、人と組織が負う。生成 AI を、検査を省く道具ではなく、安全と信頼を守り抜いたうえで速度を得る基盤として設計する ── そこが、生成コードのリスクに向き合う芯です。次回は、目的に合ったモデルをどう選び、コストをどう抑えるかへ進みます。