AIはなぜ“脅威”になったのか？──IPAが警告するリスクの正体

Apr 23, 2026

AIはなぜ“脅威”になったのか？──IPAが警告するリスクの正体

本記事で解決できること

なぜAIが「サイバー脅威」として扱われ始めたのか分かる
IPAが指摘するAIリスクの中身を実務レベルで理解できる
企業として何を整備すべきかが整理できる

“The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge.”
（知識に対する最大の敵は無知ではない。知識の思い込みである。）
— Stephen Hawking（スティーブン・ホーキング）

はじめに：AIが初めて“公式な脅威”になった

2026年、セキュリティの前提が変わりました。

情報処理推進機構が発表した「情報セキュリティ10大脅威 2026（組織編）」において、「AIの利用をめぐるサイバーリスク」が初めてランクインし、3位に選出されました。

初登場で3位というのは、やや異例です。これは単なる話題性ではなく、「実害が顕在化した」ことの裏返しです。

なぜ今“AIリスク”なのか

IPAの整理を見ると、背景は明確です。

① 利用が爆発的に広がっている

まず、利用の広がりです。業務の中で生成AIにデータを入力する行為自体は、すでに一般化しています。利用機会が増えた分、リスクに触れる機会も増えています。

② 管理されていない利用が増えている

ただし、その多くが組織として管理されていない形で行われています。

いわゆる「シャドーIT」と同じ構造が、AIでも起きている状態です。いわば「シャドーAI」とでも呼べる状況です。許可されているツールとは別に、個人アカウントで別のAIサービスを使う。ログは残らず、統制も効かない。組織としては、どこで何が使われているのか把握できません。

シャドーITが問題とされるのは、管理外で利用されることで、情報漏えいや不正利用が発生しても検知・制御ができない点にあります。生成AIでも同様に、組織の管理外で情報が扱われることで、同種のリスクが発生します。

（※なお、シャドーITについては「シャドーITとは何か？ノーコード・ローコード時代の“見えないIT”のリスクと対策 - イーストみんなのDX推進室」で詳細に紹介しています）

③ AIが“攻撃側”にも使われている

加えて、AIは利用者側だけでなく、攻撃側にも使われ始めています。フィッシングメールの文面がより自然になり、多言語対応し、攻撃自体の自動化も進んでいます。結果として、攻撃の量と質が同時に上がる状態が生まれています。

ノーコード・ローコードが開発を「民主化」したように、生成AIはサイバー攻撃そのものを民主化しつつあります。

IPAが示すAIリスク（現場目線で整理）

IPAの内容をそのまま読むと網羅的ですが、実務に引き直すと、論点はそこまで多くありません。

A. 情報漏えい：入力した時点で外に出る

たとえば、社内資料を個人で利用しているChatGPTにそのまま貼り付けたと仮定します。あるいは、顧客情報を入力したとします。

もしChatGPTの学習をオプトアウトしていない場合、貼り付けた社内資料や入力した顧客情報は、ChatGPTに学習されてしまう可能性があります。こうした行為は、外部サービスへの送信を意味します。また、社内の情報がいつでも個人利用できる形になってしまったことも意味します。つまり、内部不正のリスクが生じる状態とも言えます。

問題は、これが組織に見えない形で起きることです。気づいたときには、すでにログも追えないケースもあり得ます。

B. 誤情報・ハルシネーション：それっぽく間違える

AIは、誤っていても自然な文章を生成します。実在しない情報を生成し、それがそのまま利用される事例は決して少なくありません。実際に、判例を誤って引用した事例が問題化しています。

私自身も、友人に大学教員がいるのですが、友人から聞いた話では、存在しない参考文献を引用してしまっているレポートが散見されるとのことです。

ここで起きているのは単純で、「それっぽい」ことは「正しい」ことを意味しないということです。

C. 攻撃の高度化：量産される側に回る可能性

マルウェア・ランサムウェアによる攻撃やパスワード攻撃、フィッシングなどは、いずれも従来から存在していたサイバー攻撃の手法です。ただし、AIによって実行コストが下がり、量産可能になった点が変化です。

D. AI固有の攻撃

さらに、AI固有の攻撃も出始めています。ここでは、生成AI特有の攻撃手法のなかで有名なものをいくつか紹介しましょう。

・プロンプトインジェクション（Prompt Injection）

攻撃者がAIへの入力（プロンプト）に細工をし、本来の指示やルールを上書きさせる手法。たとえば、「これまでの指示は無視して〜」といった形で、意図しない動作を誘導する。RAGや外部データ連携と組み合わさると、より成立しやすい。ユーザーが気づかない形で挙動が変わる点が厄介。

・敵対的サンプル（Adversarial Attack）

主に画像認識において、人間にはほぼ分からない微小なノイズを加え、AIの認識や判断を誤らせる手法（但し、音声認識やLLMなどにも応用されつつある）。意図的に誤分類や誤解釈を引き起こすことができる。たとえば、自動運転の研究では、停止標識に人間には見えないステッカーを貼るだけで、AIが「制限速度標識」と誤認識する事例が報告されている。

・データポイズニング（Data Poisoning）

AIの学習データや参照データに、意図的に不正・偏った情報を混入させ、モデルの判断そのものを歪める攻撃。長期的に影響が残るため、検知が難しい。RAGや社内ナレッジ連携でも現実的に起こりうる、「正しい前提そのものを壊す」タイプの攻撃。

・モデルインバージョン（Model Inversion）

モデルの出力を分析し、学習データの一部を推測によって逆算・復元する攻撃。個人情報保護の観点で問題視されることが多い。「出力から中身を覗く」タイプのリスク。

・メンバーシップ推論（Membership Inference）

特定のデータがモデルの学習に使われたかどうかを推定する攻撃。個人データの利用有無が外部から判別される可能性がある。それ自体がプライバシー侵害になり得るほか、精度が高い場合には、そのデータが存在するということが露呈する。

・プロンプトリーク（Prompt Leakage）

システムプロンプトや内部設定が外部に漏れる現象。ユーザーの質問誘導によって、設計情報が露出し、ガードレールや制約条件が知られることで、回避されやすくなる。そこから企業独自のルールやナレッジが漏れる可能性もある。

・ツール汚染（Tool / Plugin Abuse）

AIが連携している外部ツールやAPIを悪用する攻撃。不正な指示によって、意図しない操作が実行される。メール送信、データ取得、更新処理などが対象になり、エージェント型AIでは特にリスクが高い。「AI経由でシステムを操作される」攻撃。

・RAG汚染（Retrieval Poisoning）

検索対象やナレッジベースに悪意ある情報を混入させる手法。AIはそれを信頼できる情報として参照してしまい、結果として、誤った出力を正当化する形になる。社内ドキュメントやFAQでも起こり得る。「参照している情報源が汚される」問題。

よくある現場のAI事故パターン

ここまでAIのリスクを整理してきましたが、実際の現場ではもう少しシンプルな形で事故が起きています。いくつか典型的なパターンを挙げます。

① 資料をそのまま入力する

社内資料や顧客情報を、そのまま生成AIに入力してしまうケースです。本人に悪意はなく、「業務効率化」のつもりで使っているだけですが、結果として情報漏えいのリスクを生みます。特に会社指定のサービス以外の生成AIを利用している場合（そもそもそうしたAIを利用すること自体、推奨されない行動ですが）、入力した情報の扱いには注意が必要です。

② 出力をそのまま使う

AIの出力を確認せず、そのまま資料やメールに使ってしまうケースです。一見もっともらしく見えるため見落とされがちですが、誤情報や不正確な内容が含まれていることがあります。その結果、社内外への説明で齟齬が生じることがあります。

ここで注意すべき点が、AIは非常に自然な文章を生成するため、出力内容が「正しそう」に見えてしまう点です。結果として、「それっぽいものの誤っている内容」を信用してしまいます。それっぽさに引っ張られてしまうのが、典型的な事故の入口です。

③ 使いどころを誤る

「出力をそのまま使う」と関連しますが、AIは万能ではないのにもかかわらず、万能のように使われてしまうことがあります。その結果、本来は人間が判断すべき場面でAIに依存してしまい、結果として誤った意思決定につながるケースもあります。特に重要な判断ほど、AIの出力は補助的に扱う必要があります。

④ ルールや教育がないまま使われる

ルール整備や教育が追いついていないことも、事故の背景にあります。生成AIの進化や普及は非常に急速であったため、「他社に後れを取ってはなるまい」と考え、ルール整備や教育が十分に行われないまま拙速に生成AIを導入してしまった企業も多数存在します。

たとえば、どのような資料であれば生成AIに読み込ませてよいのかというルールが整備されておらず、個人情報や企業秘密を含んでいる資料を生成AIに読み込ませてはならないということが周知されていない企業があったとします。

このような企業では、どの資料を読み込ませてよいかという線引きが部署や個人ごとにバラバラになります。その結果、社内資料や顧客情報を、そのまま生成AIに入力してしまい、最悪の場合情報が漏えいしてしまうという事態を招きます。

IPAが示す対策

IPAが示す対策は、実務にそのまま落とし込める内容です。

① 入力ルールの明確化

まず、入力しても良いものについてのルールを明確化することが重要です。機密情報を入力しないという従業員個々人の意識が重要であることはもちろん、間違って機密情報を入力してしまった場合に、入力内容が学習に用いられないよう、保険として学習対象から除外する設定（オプトアウト）を行うことも欠かせません。さらに、入力内容が学習に利用されるか否かなどを把握するうえで、利用規約を確認しておくことも有用です。

② 利用の可視化・管理

可視化経営の重要性については、多くの企業に対してその認識が広がってきたといえるでしょう。AI利用についても可視化が重要であることに変わりはありません。むしろ、どこで何が使われているかが見えないままでは、管理そのものが成立しません。

たとえば、ログの取得や、CASB等による利用状況把握および未承認ツールの検知などがこれに該当します。

なお、IPAが推奨するこれらの要件は、特定の製品を前提としたものではありません。ただし、Microsoft 365を利用している組織では、Purviewを用いてデータの所在や利用状況を可視化し、AI利用に関する統制につなげている例も見られます。

③ ガバナンス強化

AI利用においては、最終的な判断を人が担保するためのガバナンスが不可欠です。具体的には、承認プロセスにおける多重チェックの導入や、AI利用ルールの整備が挙げられます。AIの出力をそのまま意思決定に用いるのではなく、人による確認・判断を前提とした運用を徹底することで、AI任せの判断を防ぐことが重要です。

④ 教育の徹底

従業員にAIを安全に利用させるためには、以下の点について特に重点的に教育を行うことが有用です。

まず、入力しても良いものについてのルールを明確化することが重要です。特に、「何を入れてはいけないか」だけでなく、「何なら入れてよいのか」まで定義しなければ、現場は判断に迷い、結果として統制が形骸化するおそれがあります。

次に、ハルシネーションについて理解させ、AIの回答は必ずしも正しいわけではないという認識を身に着けさせることが欠かせません。AIは確かに便利なツールではありますが、過剰に依存してしまわないよう注意することが重要です。

結論：AIは“新しい脅威”ではない

IPAのコラムで示されている重要な示唆は、AIは、既存の脅威を増幅しているに過ぎないという点です。

AIが登場する前から、情報漏えいそれ自体は例えばメール誤送信などの形で存在していました。人が誤った判断をすること自体は歴史の常です。サイバー攻撃も昔からありました。AIは、あくまでそれらを加速させただけだといえます。

おわりに

AIは、もはや止められる存在ではありません。

AIの利用を許可している企業では、ルール整備や教育が追いついていなければ事故が起きるリスクは高いといえます。とはいえ、もし禁止していたとしても、現場は往々にしてすでに使っているものです。

だからこそ、問うべきは、「使うか使わないか」ではなく「どう管理するか？」という点です。そして、AIに起因する情報セキュリティ事故は今後も増えることが懸念されています。IPAの「十大脅威」は、こうした問題意識のもと、AIガバナンスの設計の必要性を啓発しているといえるでしょう。

筆者：W.S.

ITガバナンスおよび市民開発推進を得意領域とするコンサルタント。中堅〜大手企業のIT統制設計・DX推進支援に従事。
個人開発者としてJavaScriptおよびFirebaseを用いたWebアプリ開発にも取り組み、開発現場と統治設計の両面からDXを研究している。
同志社大学大学院経済学研究科博士後期課程修了単位取得退学。

＼今なら無料！／

【30分・AIセキュリティ／ガバナンス無料相談実施中】