AI生成の業務自動化スクリプト、9本全てに脆弱性

研究・論文
2026.07.30

【更新 2026-07-31】本記事を見直し、修正しました。主な修正点：紹介していた「テキスト生成AIの導入・運用ガイドライン」の発行主体を訂正（IPAの公式見解ではなく、IPA産業サイバーセキュリティセンター 中核人材育成プログラム 卒業プロジェクト第7期生による成果物）。

非エンジニアの社員がChatGPTに「このフォルダのファイルを自動で仕分けするスクリプトを書いて」と頼み、返ってきたコードをそのまま業務で動かす——情シスの目が届かないところで、いま最も増えている「新しいシャドーIT」かもしれません。2026年7月22日に公開された査読前（プレプリント）の研究論文は、ChatGPT・Microsoft Copilot・Google Geminiに同じ指示で業務自動化スクリプトを書かせ、生成された9本全てに悪用可能な脆弱性が含まれていたと報告しました。しかも各モデルの危険度の差は10%未満で、「どのAIを使うか」ではリスクが減らないことを示しています。

この記事でわかること

  • AIが生成した業務自動化スクリプトに、どんな脆弱性がどれだけ含まれていたか（研究の数字）
  • なぜ「安全なAIを選ぶ」というアプローチが効かないのか
  • 非エンジニアのAI活用を止めずに、情シスがリスクを下げるための現実的な打ち手

本記事は査読前（プレプリント）の研究を扱います。結果は今後の査読・追試で変わりうるため、断定的な結論としてではなく「傾向を知る材料」として読んでください。研究自体の限界は記事後半で整理します。

どんな研究か（1文で）

ひとことで言えば、プログラミングの専門知識がない人が業務自動化のために生成AIに書かせたコードは、そのまま動かして安全なのかを、3つの主要な生成AIで横並びに検証した研究です。

論文名は「Security Vulnerability Patterns in AI-Generated Code: A Cross-Model Comparative Study」（著者: Shanna M. Kahn、John D. Hastings／ダコタ州立大学、arXiv:2607.20713、2026年7月22日公開）。研究チームが立てた問いは明快で、「非エンジニアが作った自動化コードは、レビューなしで運用して悪用可能な脆弱性を含むのか」「同じ指示なら、モデルによって安全性は変わるのか」の2点です。

検証の方法

研究では、実務でよく依頼される自動化タスクを洗い出したうえで、次の3領域を選んでいます。いずれも情シスから見て「総務や営業の担当者が普通に頼みそう」な業務です。

検証した業務領域 生成されたスクリプトの役割
Webスクレイピング・データ抽出 指定URLからデータを収集する
メール・文書の自動化 CSVを読み込んで定型メールを一括送信する
ファイル・ワークフローの自動化 フォルダを監視してファイルを自動仕分けする

3モデル × 3領域で計9本のPythonスクリプトを、全モデルに同一のプロンプトを与えて生成。プロンプトの巧拙という変数を意図的に排除し、「一度頼んで返ってきたものをそのまま使う」という非エンジニアの実際の使い方を再現しています。その後、標準化した手順で各スクリプトのコードレビューを行い、検出された脆弱性をCVSS v3.1でスコアリングし、OWASP Top 10:2021とMITRE ATT&CKにマッピングしました。

何が分かったのか（主な数字）

生の指摘は45件で、重複を整理した結果17種類の脆弱性クラスが確定しました。主な結果は次の通りです。

観点 結果
悪用可能な脆弱性を含んでいたスクリプト 9本中9本（全て）
3モデル全ての生成コードに現れた脆弱性クラス 17種類中9種類
2モデル以上に現れた脆弱性クラス 17種類中14種類
1つのモデルにしか出なかった脆弱性クラス わずか3種類
モデル別の検出件数 ChatGPT 13件／Copilot 14件／Gemini 12件
加重CVSSスコアのモデル間の差 10%未満
総リスクの約80%を占める脆弱性クラス 17種類中11種類

なぜ「安全なAIを選ぶ」では解決しないのか

結論を先に言えば、脆弱性がモデル固有ではなく「作らせた業務の種類」に紐づいていたからです。この研究で最も示唆的なのは、脆弱性が見つかったこと自体ではなく、どのモデルに書かせても同じ場所に同じ脆弱性が出たことでした。

  • スクレイパー系のスクリプトには、3モデルともSSRF（サーバサイドリクエストフォージェリ）が入り込んだ
  • メール送信スクリプトには、3モデルともテンプレートインジェクションと過度に広い例外処理が入った
  • ファイル監視スクリプトには、3モデルともシンボリックリンクの脆弱性と、設定ファイル経由のパストラバーサルが入った

プロンプトは完全に同一で、変数はモデルだけ。それでも同じ実装パターンに収束したということは、これらのモデルが同種の自動化ツールを求められたときに似た書き方をする、という構造的な傾向を示しています。つまり情シスが「どのAIツールなら信用できるか」を比較検討しても、この問題は動きません。研究者らが投げかけているのも「どのツールを信じるか」ではなく「レビューなしで動かしてよいのか」という問いです。

なお、17種類はOWASP Top 10:2021のA01（アクセス制御の不備）、A03（インジェクション）、A05（セキュリティ設定ミス）、A10（SSRF）といったおなじみのカテゴリに収まりました。目新しい攻撃ではなく、セキュリティチームが何年も前から追いかけている、実際に悪用されている脆弱性だという点が重要です。インジェクション系の基本についてはSQLインジェクションとは？仕組みと情シスの対策を解説、SSRFの実害イメージはLangflowのSSRF脆弱性、AI開発ツールの守り方も参考になります。

「正しく動く」と「安全に動く」は別物

見落とされがちな点として、9本のスクリプトはいずれも依頼どおりに正常動作していました。スクレイパーはデータを取得し、メール送信スクリプトはメールを送り、ファイル監視スクリプトはファイルを仕分けた。依頼した本人から見れば「ちゃんと動いた＝問題ない」わけです。動作確認では脆弱性は一切見えません。ここが、非エンジニアによるAI活用の最も厄介なところです。

悪用はどれくらい簡単か

研究が指摘する攻撃シナリオは、いずれも高度な技術を必要としません。

  • スクレイパーに悪意あるURLを渡すだけでSSRFが成立し、内部ネットワークの探索や認証情報の収集につながる
  • CSVの1フィールドを攻撃者が操作できれば、送信メールのヘッダを注入して本文を書き換えたり、宛先を丸ごと変更したりできる
  • 設定ファイルの保存先フォルダを任意のパスに書き換えれば、認証なしでファイルシステムに直接アクセスできる

さらに問題なのは、これらが単発では終わらず連鎖することです。パストラバーサルは「機密ファイルを読まれる」で止まらず、任意の場所に書き込めるようになった時点で永続化の入り口が開きます。研究では、検出された脆弱性がMITRE ATT&CKの初期アクセス・実行・永続化・認証情報アクセス・持ち出しという広範な戦術に対応づくと整理されました。業務効率化のための小さなスクリプトが、権限昇格すら不要な足がかりになりうるということです。スクリプトは実行したユーザーの権限をそのまま引き継ぐため、多くの企業環境ではそれで十分に届いてしまいます。

脆弱性が単独ではなく組み合わさって現れる傾向は、別の査読前研究でも報告されています（AI生成コードの脆弱性は連鎖する 査読前研究の指摘）。

もうひとつ現場的に痛いのが、Copilotが生成したスクレイパーに含まれていたデッドコードです。実際に呼ばれているのは別の関数なので、ライブラリを更新しても該当箇所には効かない。パッチ適用したつもりで守れていない、という状態が生まれます。CVSSスコアはSSRFの9.3に対しデッドコードは4.8と低めですが、「脆弱性管理の前提が崩れる」という意味では軽視できません。

現場目線の課題

この研究を読んで正直に思うのは、「これ、うちで起きていても絶対に気づけない」ということです。

脆弱性管理といえば、資産管理台帳に載っているソフトウェアのバージョンを追い、ベンダーの更新情報を確認して展開する——という流れが基本です。ところが、経理担当者がChatGPTに書かせて共有ドライブに置いた30行のPythonスクリプトは、台帳のどこにも載りません。バージョンもなければベンダーもなく、脆弱性情報も出ません。書いた本人は「便利なマクロ」くらいの認識で、セキュリティレビューの対象だと思っていない。情シスに相談が来ることもまずないでしょう。

これは新しい問題というより、Excelマクロや野良Accessの時代からずっとあった問題です。ただ、以前は「作れる人が限られていた」ことが自然な歯止めになっていました。生成AIはその歯止めを外し、しかもそれらしく動くコードを一発で返してしまう。動作品質が上がったぶん、かえって疑われにくくなったとも言えます。台帳にも載らず、EDRのアラートも上がらず、動作は正常。見つけようがない、というのが率直な実感です。

AI生成コードの検証がなぜ本質的に難しいのかについては、AIが書いたコードを誰が検証するか──情シスが直視すべき現実でも扱っています。

情シスはどうすべきか

この手の話で「全社的にAIコード生成を禁止する」は現実的ではありませんし、業務効率化の芽を摘むだけで隠れて使われるようになります。まずは公的機関の指針を土台に、自社のルールを整えるのが近道です。

  • AI利用者のためのセキュリティ豆知識（IPA）… AIやセキュリティに詳しくない利用者本人向けのスライド資料。今回の論文が想定する「非エンジニアの利用者」にそのまま配れる形式で、社内啓発の出発点として使いやすい
  • テキスト生成AIの導入・運用ガイドライン（IPA産業サイバーセキュリティセンター 中核人材育成プログラム 卒業プロジェクト第7期生・2024年7月31日公開）… 導入・運用する管理側向け。組織としてのルール整備を検討する際の骨格になる。なお本書はIPAのサイトに掲載されているものの、ページに「IPAおよび産業サイバーセキュリティセンターの意見を代表するものではない」と明記されており、IPAの公式見解ではない点に注意
  • 中小企業の情報セキュリティ対策ガイドライン（IPA）… 限られた人員での体制づくり全般。専任者を置けない組織ほど参照価値が高い
  • 対策のしおり（IPA）… エンドユーザー啓発向けの配布資料

そのうえで、今回の研究から導ける論点を挙げるなら次の3つでしょう。1つ目は、「AIに書かせたコードを業務で動かす前に情シスに一報を入れる」というルールを作り、まず存在を可視化すること。技術的な検査より前に、どこで何が動いているかを知らないと手の打ちようがありません。2つ目は、優先順位をつけること。研究のパレート分析では17種類のうち11種類が総リスクの約8割を占め、特にテンプレートインジェクション、SSRF、メールヘッダインジェクション、パストラバーサルが上位でした。全部を等しく厳格にレビューするのは現実的でないので、外部ネットワークにアクセスするもの・メールを送るもの・共有フォルダのファイルを操作するものから見る、という切り方が有効です。3つ目は、地道な啓発。「動いた＝安全ではない」という一点を利用者に伝えるだけでも、情シスへの相談は増えます。

なお、研究者らはCVSSスコアについて「最悪ケースを前提とした出発点であり、確定的なリスク指標ではない」と明確に注意しています。ネットワーク接続のない隔離端末で動くスクリプトと、ドメイン環境の共有ドライブ上で動くスクリプトでは、同じコードでもリスクは全く異なります。自社の環境と既存の統制を踏まえて判断してください。

この研究の限界

著者ら自身が挙げている制約は、そのまま読み手が注意すべき点でもあります。

  • 生成は1モデル1タスクにつき1回のみ。「一度頼んで返ってきたものを使う」実態を再現する意図的な設計だが、LLMは非決定的なので、別の生成では違う結果になりうる
  • 対象は3モデル・3業務領域のみ。オープンソースモデルや、データベース操作・API連携・帳票生成といった他の業務では傾向が異なる可能性がある
  • コードレビューはLLM（Claude Code）による標準化プロンプトで実施し、1ファイルあたり最大5件に上限を設定。上限のため拾えなかった低深刻度の指摘がありうる
  • 各指摘の手動確認は行っていない。著者らも、LLMによるレビューは形式的な静的解析やセキュリティ専門家によるレビューと同等ではないと明記している
  • サンプル数は9本と小規模。統計的な一般化には追試が必要

一方で、9モデルのLLM生成Cプログラムの62%超に脆弱性が見つかり、モデル間の差は小さかったとする先行研究（Tihanyiら）とも方向性は一致しており、傾向としては受け止めておくべき内容だと言えます。

まとめ

  1. ChatGPT・Copilot・Geminiに同一プロンプトで業務自動化スクリプトを書かせた査読前研究で、生成された9本全てに悪用可能な脆弱性が見つかった。17種類のうち9種類は3モデル全てに共通していた。
  2. 加重CVSSの差は10%未満で、リスクはモデルではなく「作らせる業務の種類」に紐づく。「安全なAIを選ぶ」ではなく「レビューなしで動かさない」が論点になる。
  3. 脆弱性の中身はOWASP Top 10:2021のおなじみのカテゴリで、しかもスクリプトは正常に動作するため利用者は気づけない。情シスはまず「AI生成コードが社内のどこで動いているか」を可視化し、外部通信・メール送信・ファイル操作を伴うものから優先的に見ていくのが現実的。

出典

タイトルとURLをコピーしました