見出し画像

生成AIの安全対策は「機密情報を入力しない」だけでは足りない──AIを業務につないだ瞬間、守るべきものが変わる

VICTOR CONSULTING

今回抽出した論文

論文名：
Emerging Challenges in Threat Modeling for GenAI-Augmented Systems: A View from the Trenches
著者：Nicolás E. Díaz Ferreyra、Manish Mahesh Kumar、Nohemí Villarrealほか
公開日：2026年7月30日
出典：arXiv

生成AIを仕事で使う際の注意事項として、
「個人情報を入力しない」
「機密情報を入力しない」
「AIの回答を鵜呑みにしない」
といったルールを設けている企業は増えています。

もちろん、これらは重要です。

しかし、生成AIをメール、顧客データ、社内資料、業務システムなどに
つなぎ、AIエージェントとして仕事をさせるようになると、それだけでは
不十分になります。

今回の研究では、生成AIを組み込んだ実際の中小企業の業務システムを対象に、生成AI向けに設計された3種類の脅威分析手法を適用し、どのような
セキュリティリスクを発見できるのかを比較しました。

研究対象となったシステムは、顧客から届くメールや添付PDFを処理し、
顧客情報や過去データを参照しながら、顧客ごとの市場レポートを自動生成する仕組みです。

Microsoft Power Platformで業務をつなぎ、Azure OpenAIを使って生成AI処理を行い、Power BIで顧客向けのレポートを表示します。

システム全体には10の処理、7つのデータ保存領域、27のデータの流れがあり、そのうち3つの処理にLLMが組み込まれていました。

単に社員がChatGPTの画面を開いて文章を書かせるケースとは違います。

生成AIが、企業の仕事の流れそのものに組み込まれています。

今回の研究が問いかけているのは、こうした使い方が増えたとき、従来の
セキュリティ対策だけで十分なのか、という問題です。研究は2026年のESEM（Empirical Software Engineering and Measurement）に
採択されています。


小規模事業者が見るべきポイント

「生成AIに何を入力するか」だけを考えていては足りない

社員が生成AIを単体で利用する場合には、
何を入力してよいか、
機密情報を入力していないか、
生成された回答が正しいか、
といった問題が中心になります。

しかし、生成AIを業務システムにつなぐと、状況が変わります。
今回の事例では、AIが外部から届いたメールやPDFを読みます。
社内に蓄積された顧客情報や過去データも参照します。
その情報をもとに処理を行い、顧客向けの成果物まで作ります。

ここでは、
「社員がAIに何を入力したか」
だけを管理しても十分ではありません。

外から何が入ってくるのか。
AIはどの社内情報を見ることができるのか。
AIの出力は、その後どの業務へ渡されるのか。
AIには何を実行する権限が与えられているのか。
まで考える必要があります。

生成AIの安全対策は、「利用ルール」から「業務全体の設計」の問題へ
変わります。

生成AI向けの新しい分析手法でも、すべてのリスクを拾えなかった

研究チームは、文献調査で337件の研究候補を調べ、最終的に生成AI
システムに適用可能な3つの脅威分析手法を選びました。

評価したのは、

  • AI-as-a-Service Framework

  • ADMIn Framework

  • ThreatFinderAI

の3手法です。

いずれも、従来の一般的なセキュリティ分析をそのまま使ったもの
ではありません。

生成AIやAIを含むシステムを意識して作られた手法です。

それでも、研究対象となったシステムへ適用すると、カバーできるリスクには大きな差がありました。

プロンプトインジェクション。
機密情報の漏えい。
データやモデルの汚染。
AIを大量に動かして計算資源を消費させる攻撃。

こうした問題は、一定程度検出できました。
一方、3つの手法すべてで検出できなかった重要なリスクもありました。

例えば、

AIサプライチェーンの問題。
自社が使っているAIモデル、外部サービス、ライブラリなど、その上流に
問題が生じた場合のリスクです。

AIの出力を、そのまま次のシステムへ渡す問題。
AIが誤った値や危険な内容を生成したとき、その出力を別システムが無条件に処理すれば、誤りが業務全体へ広がります。

AIに必要以上の権限を与える問題。
資料を読むだけのAIと、顧客データを書き換えたり、メールを送信したり
できるAIでは、失敗したときの影響がまったく違います。

システム内部の指示が漏れる問題。
AIをどのように動かしているのかという内部設定が、外部へ露出する可能性があります。

AIが誤った情報を生成する問題。
もっともらしい誤情報が、そのまま業務の判断材料になる可能性が
あります。

研究では、これらに対応するOWASP（Webアプリケーションや生成AIの
セキュリティに関する国際的な非営利コミュニティ）が整理したLLM向けの主要リスク分類と照らし合わせても、3手法とも十分に拾えない項目が
ありました。
（注）OWASPは、生成AI・LLMを組み込んだシステムで注意すべき代表的なセキュリティリスクを「OWASP Top 10 for LLM Applications」として
整理・公開しています

ここは重要です。

生成AIに対応した専門的なセキュリティ分析手法でさえ、現在のAIシステムが持つリスクを完全には捉えられていません。

AIエージェントでは「何を知っているか」だけでなく「何ができるか」が
重要になる

特に経営者が注目すべきなのが、「Excessive Agency」という問題です。

直訳すれば「過剰な代理権」です。

例えば、顧客から届いたメールをAIが読み、その内容を分類するだけなら、AIの権限は限定されています。

しかし、
顧客DBを書き換える、
返信メールを送信する、
見積金額を変更する、
発注処理をする、
別のシステムを動かす、
といった権限まで与えると、AIの誤判断や外部からの不正な指示が、
そのまま実際の行動へつながる可能性があります。

今回評価された3手法は、この「Excessive Agency」に対応するリスクを
検出できませんでした。

生成AIが文章を作るだけだった時代には、
「回答が間違っていないか」
を確認すればよかったかもしれません。

AIエージェントが実際に仕事を動かす時代には、

「間違えたときに、どこまで実行できてしまうのか」

まで考える必要があります。

AIエージェントに仕事を任せるほど、セキュリティは「情報漏えい対策」
から「権限と判断の設計」へ広がります。

最後に残るのは、人間の問題

もう一つ、研究で興味深い結果があります。

3つの分析手法とも、人間を含む社会技術的なリスクの評価が弱く、
実務担当者による評価でも、この項目の得点が最も低くなりました。

例えば、AIが誤った回答を作る。
担当者が「AIが作ったのだから大丈夫だろう」と考える。
確認が不十分なまま次の工程へ流す。
別の担当者も、その情報を正しいものとして利用する。
最終的に顧客へ誤った情報を伝える。

問題は、AIが一度間違えたことだけではありません。

その誤りが、人間の過信によって業務の中を伝播していくことです。

研究者は今後の脅威分析では、

  • AIが作った誤った内容がどこへ伝わるのか

  • 誰が確認責任を持つのか

  • どの場面でAIへの過信が危険になるのか

までモデル化する必要があると指摘しています。

AIセキュリティというと、サイバー攻撃だけを考えがちです。

しかし、

AIを信じすぎる人間そのものも、システムのリスク要因になる。

これが今回の研究から読み取れる重要な点です。

なぜこの論文を抽出したか

世界中では、生成AIやAIエージェントに関する研究が次々に発表されて
います。

この経営インテリジェンス配信サービスの役割は、その中から経営者が注目すべき動きを選び、自社の経営判断に使える形へ整理することです。

今回、この論文を抽出した理由は、次のとおりです。

中小企業でも「AIを使う」から「AIを業務につなぐ」段階へ
進み始める

生成AI活用の初期段階では、一人の社員がChatGPTなどを開き、
文章を作る、
資料を要約する、
アイデアを出す、
調査をする、
という使い方が中心です。

この段階では、社員教育と利用ルールが重要になります。
しかし、生成AIの利用が進むと、次の段階が始まります。

メールとつなぐ。
社内資料とつなぐ。
顧客管理システムとつなぐ。
会計システムとつなぐ。
業務フローとつなぐ。
AIエージェントに複数工程を任せる。

今回の研究対象となった中小企業のシステムは、まさにその段階に
あります。外部からのメールやPDF、社内顧客情報、LLM処理、顧客向け
レポートが一つの仕事としてつながっています。

これから中小企業のAI活用が進めば、同じ問題に直面する会社は増える
でしょう。

「AI利用規程」だけでは守れない領域が増える

生成AI導入というと、
社員向けガイドラインを作る、
入力禁止情報を決める、
会社として利用可能なサービスを指定する、
といった対応がまず考えられます。

それ自体は必要です。

しかし、AIが業務システムの中へ入れば、
入力される情報、
参照できる情報、
AIが作る情報、
その情報を受け取る別システム、
AIが実行できる処理、
それぞれについて、安全性を考えなければなりません。

社員がルールを守っていても、外部から届いたPDFの中に悪意のある指示が埋め込まれている可能性があります。

AIが正しく動いても、利用している外部サービスや部品に問題が発生する
可能性があります。

AIが間違った情報を生成し、それが自動的に次の処理へ渡される可能性が
あります。

社員教育だけでは解決できません。

AIを組み込んだ仕事そのものを、安全に設計する必要があります。

「人が確認するから大丈夫」も万能ではない

AI導入では、
「最終的には人間が確認するので問題ありません」
という説明がよく行われます。

確かに、人による確認は重要です。

しかし、昨日取り上げたOmegaUse-OfficeValの研究では、AIエージェントが人間より安く速く仕事を処理しても、成果物の品質はまだ人間水準に
届かず、人による確認と修正が重要であることが示されました。

今回の研究は、さらにその先の問題を示しています。

人が確認すれば安全なのではなく、その人がAIを過信しない仕組みまで
必要になる。

人間が形式的に承認ボタンを押すだけなら、確認工程が存在していても意味がありません。

何を確認するのか。
何が間違っていたら止めるのか。
誰が判断責任を持つのか。
その人に必要な情報が表示されているのか。

まで設計する必要があります。

AI時代の「Human in the Loop」は、単に人を途中に置けばよいという話ではありません。

セキュリティの専門手法自体も、まだ発展途上である

今回評価された3つの手法は、生成AIを考慮した比較的新しい脅威分析方法です。

それでも、供給網、AIの過剰な権限、出力の扱い、人間による過信など、
重要な領域を十分にカバーできませんでした。

研究者自身も、今後は供給網に関する情報を自動的に取り込む仕組みや、
チェックリスト、プロンプトを使った分析支援、人間による過信を含む
新しい分析方法が必要だと述べています。

つまり、
「このセキュリティチェックを実施したから安全」
と言える段階ではありません。

だからといって、AI導入を止める必要もありません。

重要なのは、

現在の安全対策にも限界があることを理解したうえで、AIに任せる範囲を
段階的に広げることです。

自社で考えるなら

まず「AIにつながっているもの」を書き出す

AIを業務で使用している会社では、最初にシステム図を作る
必要はありません。

紙一枚でも構いません。

例えば、

顧客メール　⇒　添付PDF　⇒　生成AI　⇒　社内顧客データ
⇒　レポート作成　⇒　担当者確認　⇒　顧客送信

と書くだけでも、AIがどこに位置しているのかが見えます。

そして、それぞれについて考えます。

外部から何が入ってくるのか。
AIはどのデータを見るのか。
AIが作ったものはどこへ行くのか。
誰が確認するのか。
その後、自動的に何かが実行されるのか。

AI単体ではなく、AIの前後まで含めて仕事を見ることが第一歩です。

AIの権限を確認する

次に、
「このAIは何ができるのか」
を確認します。

読むだけ。
下書きを作るだけ。
データを検索できる。
ファイルを書き換えられる。
メールを送れる。
顧客情報を更新できる。
発注できる。
支払い処理へ進める。

権限が大きくなるほど、失敗した際の影響も大きくなります。

最初は、

AIが提案する。人間が実行する。

という分担から始める方法があります。

安定性を確認した後で、自動実行する範囲を少しずつ広げます。

「技術的に自動化できるから自動化する」のではなく、

「間違えた場合の影響を許容できるから自動化する」

という考え方が必要です。

AIの出力を、無条件で次工程へ渡さない

AIが作った数字。
AIが作った顧客分類。
AIが作った見積条件。
AIが作ったメール文章。

これらを、そのまま別のシステムへ渡す場合には注意が必要です。
AIが間違えたとき、その誤りが自動的に拡大するからです。

特に、金額、契約、品質、法令、個人情報、顧客への正式回答、

などに関係する処理では、AI出力をどこで止め、人が何を確認するのかを
決めておく必要があります。

「人が確認」の中身を決める

「最終確認は担当者が行う」
だけでは十分ではありません。

例えば、見積書なら、金額、数量、顧客名、納期、過去案件との整合、
特別条件を確認すると決めます。

顧客向けレポートなら、元データとの一致、重要な数字、AIによる
推測部分、引用元、顧客固有情報を確認します。

人間の役割を具体的な確認項目にします。
そうしなければ、人は次第にAIの出力に慣れ、

「今回も大丈夫だろう」

と考えるようになります。

AIを人が監督する仕組みには、人がAIを過信することまで織り込む
必要があります。

最初から完璧な安全対策を目指さない

中小企業が生成AIを使うために、大企業と同じセキュリティ体制を最初から作ることは現実的ではありません。

しかし、
何も考えずにつなぐ、
と、
完璧な仕組みができるまで使わない、
の二択でもありません。

例えば最初は、
機密性の低い情報だけを扱う。
AIには読み取り権限だけを与える。
外部送信は人が行う。
重要な数字は人が確認する。
処理履歴を残す。
問題が起きた場合に止められるようにする。
という形から始められます。

使う範囲が広がるたびに、権限とリスクを見直します。

生成AIの安全性は、一度チェックリストに○を付けて完成する
ものではありません。

AIに任せる仕事が変われば、安全対策も変わります。

この研究を見る際の注意点

今回の研究は興味深い結果を示していますが、一般化には注意が必要です。

対象となったのは、1社の中小企業が提供した一つのシステムです。

また、実務側の評価に参加したのは、この企業の開発チーム7人でした。

さらに、この7人が3種類の脅威分析手法を長期間実際に運用した
わけではありません。研究チームが各手法をケーススタディへ適用し、
その結果をまとめたレポートを開発チームが確認したうえで、使いやすさや導入負担などを評価しています。研究者自身も、単一ケースであるため
他の企業やシステムへそのまま一般化できないことを明記しています。

したがって、
「現在のAIセキュリティ手法は使えない」
という結論ではありません。

今回の研究が示しているのは、

生成AIを組み込んだ業務システムでは、従来とは異なるリスクが
生まれており、それを評価する方法自体もまだ発展の途中にある

ということです。

この研究はarXivへ2026年7月30日に公開された初版ですが、2026年10月開催予定のInternational Symposium on Empirical Software Engineering and Measurement（ESEM 2026）への採択が記載されています。

経営インテリジェンス配信サービスのご案内

当社では、経営者専用の経営インテリジェンス配信サービスを提供して
います。

重要顧客、競合企業、注目技術、制度変更など、それぞれの経営者が関心を持つテーマや固有名詞を設定し、関連する動きを生成AIでスクリーニング
します。

また、世界中の最新学術論文データベース「arXiv」から、経営に影響する
可能性のある研究も抽出しています。

今回の論文も、
「生成AIのセキュリティには注意しましょう」
だけで読めば、よくある注意喚起に見えます。

しかし、実際の研究内容まで確認すると、
生成AIを単体で利用する段階、
社内データとつなぐ段階、
業務フローへ組み込む段階、
AIに実行権限を与える段階、
では、考えるべきリスクそのものが変わることが見えてきます。

生成AIを業務につないだ瞬間、守るべきものが変わる。

最新の研究から、自社が次に考えるべき問題を見つける。
そのための、経営者専用のAI情報レーダーです。
詳しくはこちらをご覧ください。

いいなと思ったら応援しよう！