生成AIのセキュリティリスクを4つの経路で整理する

生成AIのセキュリティリスクは、情報漏えいや誤情報、外部からの攻撃のように、目立つ事象ごとに語られることが少なくありません。ただ、リスクが生じる起点が違えば、誰がどこで何を制御すべきかも変わってきます。不安の大きいものから順に手を打つと、別の経路が手薄なまま残るおそれがあります。

入力、出力、外部の文書やツールを経由した乗っ取り、アカウントと連携先の権限という4つの経路に分けると、経路ごとに被害の起点と広がり方が見えてきます。

入力した情報が社外のサーバーに渡る

クラウド型の生成AIに入力した内容は、提供元のサーバーへ送信され、サービスによっては学習や品質改善に使われる場合があります。たとえば、経理担当者が請求書の文面を貼り付けて確認を頼めば、取引先名や金額が社外のサーバーに渡ります。

個人データの漏えい等報告を受け付ける国の機関、個人情報保護委員会（PPC）は、生成AIサービスの利用に関する注意喚起を公表しました。個人データを含むプロンプト（AIへの質問や作業指示）を入力する際は、提供元が機械学習に利用しないことなどを十分に確認するよう求めています。

参照元：個人情報保護委員会｜生成AIサービスの利用に関する注意喚起等について

出力した内容が誤りや権利侵害を含む

生成AIは、事実と異なる内容を自然な文章のまま出力することがあり、この現象はハルシネーションと呼ばれます。存在しない統計値や架空の出典が、もっともらしく示される場合も珍しくありません。たとえば、IR担当者が株主向け説明資料の数値をAIの出力のまま掲載すれば、公表後に訂正しても、受け取った人の手元には誤りが残ります。

独立行政法人情報処理推進機構（IPA）の「情報セキュリティ10大脅威 2026 解説書［組織編］」でも、米国テキサス州の弁護士が生成AIで作成した意見書に実在しない判例が引用されていたことが判明し、2025年1月に裁判所で公聴会が開かれた事例が紹介されています。

生成物が既存の著作物に似た表現となり、権利侵害につながる可能性もあります。出力の内容に責任を負うのはAIではなく、利用した企業と担当者です。

参照元：独立行政法人情報処理推進機構｜「情報セキュリティ10大脅威 2026」解説書［組織編］

外部の文書やツール経由で指示を乗っ取られる

利用者が不正な指示を入力していなくても、AIが読み込んだWebページや文書に指示が埋め込まれていれば、AIはその指示に従う場合があります。これはプロンプトインジェクションと呼ばれる攻撃です。

たとえば、購買担当者が取引先候補の会社案内をAIに読ませて比較表を作らせた際、資料内の見えない文字列に従って社内の価格情報を回答に含めてしまう事態が起こり得ます。AIが参照できる社内データと、メール送信やファイル操作など実行できる操作の範囲が広いほど、乗っ取られたときの被害も大きくなります。

先に挙げたIPAの解説書では、業務用AIアシスタント「Microsoft 365 Copilot」で2025年6月に報じられた脆弱性「EchoLeak」も取り上げられています。メールなどに仕込まれた不正な指示をAIが読み込むと、利用者が操作しなくても、AIに参照を許可した社内の秘密データが外部へ流出するおそれがあったというものです。

参照元：独立行政法人情報処理推進機構｜「情報セキュリティ10大脅威 2026」解説書［組織編］

アカウントと連携先の権限から被害が広がる

生成AIのアカウントが乗っ取られると、過去のやり取りに加え、連携した社内ストレージなどのデータまで、そのアカウントの権限で参照されるおそれがあります。APIキーやアクセストークン（AIを外部から呼び出す際の認証情報）の管理に不備があれば、推論API（AIに処理を依頼する窓口）を第三者に不正利用され、利用料金の急増やサービス停止を招きかねません。

連携先の数も影響し、AIを共有ストレージ、勤怠システム、チャットツールの3つにつなげば、侵害の起点になり得る箇所も3つに増えます。

攻撃者による悪用と実際に起きた事故も押さえる

4つの経路は自社が生成AIを使う場面のリスクですが、攻撃者が生成AIを悪用する脅威も別の軸として押さえておく必要があります。IPAの「情報セキュリティ10大脅威 2026」でも、組織向けの3位に「AIの利用をめぐるサイバーリスク」が初めて選ばれました。

生成AIは、本物らしいフィッシングメール（実在の企業などを装って情報をだまし取るメール）の文面を大量に作ったり、マルウェア（不正なプログラム）の作成を補助したりする用途に悪用されるおそれがあります。実在の人物の顔や声をまねたディープフェイクで役員になりすまし、送金を指示する詐欺も懸念されています。

実際に2023年3月には、米OpenAIが提供する対話型AIサービス「ChatGPT」で、オープンソースのライブラリの不具合により、一部の利用者に他の利用者のチャット履歴のタイトルが表示される事態が起きました。サービスを選ぶ際に提供元のセキュリティ対策を確かめ、不審なメールや指示を疑う従来の対策も続けることが欠かせません。

参照元：独立行政法人情報処理推進機構｜情報セキュリティ10大脅威 2026

参照元：OpenAI｜March 20 ChatGPT outage: Here’s what happened

従来のセキュリティ対策では防ぎきれない理由

ファイアウォールや脆弱性診断といった従来のセキュリティ対策は、ネットワークや端末、アプリケーションを外部からの攻撃から守ることに重点を置いてきました。一方で生成AIのリスクは、AIが文章をどう解釈し、どこにつながり、何を出力するかという振る舞いそのものから生じます。

従来の対策が想定してこなかった生成AIの性質は、指示の扱い方、接続先の広さ、出力の安定性という3つの観点で捉えると違いがはっきりします。

指示とデータを区別せずに動作する

生成AIは、システム側があらかじめ与えた指示も、利用者の入力や読み込んだ外部文書も、同じ自然言語として解釈して応答を組み立てます。そのため、先に挙げたプロンプトインジェクションのように、プログラムの欠陥を突く従来の攻撃とは異なり、文章そのものが攻撃の手段になります。

たとえば、総務担当者が問い合わせメールの分類をAIに任せた場合、本文に紛れた指示を入口の検知だけで漏れなく見分けるのは困難です。不正な指示が通っても被害を抑えられるよう、AIに与える参照範囲と操作の権限を絞る設計が欠かせません。

社内データや業務システムに接続される

生成AIが社内のデータや外部のAPIに接続されると、リスクの対象はAI単体ではなく、接続先を含めたシステム全体に広がります。第三者が提供するモデルやライブラリ（プログラムの部品）を利用する場合も同様で、供給元が侵害されたり部品に脆弱性があったりすれば、その問題を自社が引き継ぐことになります。

たとえば、品質保証部門が不具合報告の分析に外部のモデルと報告データベースをつなげば、モデルの提供元や部品の開発元まで確認の対象に入ります。接続先を増やすほど、情報システム部門が把握すべき範囲も増えていきます。

同じ入力でも出力が変わる

生成AIは、決められた手順を毎回同じように実行するわけではありません。プロンプトや文脈、取得したデータに応じて、確率的に出力を組み立てる仕組みのためです。動作の予測が難しく、導入前に検証を重ねても、想定外の出力を完全には排除できません。

たとえば、研修担当者が確認テストの問題をAIに作らせる場合、試行時には正確でも、本番で依頼文が少し変わっただけで誤った正答が混ざることも起こり得ます。出力を人が確かめる工程は、レビューと承認の手順として業務の流れそのものに組み込んでおく必要があります。

社内ルールとして決めておくこと

4つの経路のうち、入力と出力、アカウントの扱いは、利用者の行動次第で事故の起きやすさが変わります。ただ、禁止事項を並べただけのガイドラインは、忙しい現場ほど便利さに押されて守られなくなりがちです。社内ルールでは、現場が迷わず判断できる線引きと、問題が起きたときの動き方を決めておく必要があります。

入力してよい情報、使ってよいサービスとアカウント、出力の確認手順、事故時の報告ルートの4項目について、決めておく内容を順に解説します。

入力してよい情報を機密度で線引きする

「機密情報を入力しない」と伝えるだけでは、どの情報が機密にあたるのかを現場は判断できません。区分があいまいなままだと、迷った末にとりあえず入力してしまうためです。個人情報、社外秘の資料、取引先から預かった情報、公開情報といった区分ごとに、入力の可否と、例外を認める環境や承認者を定めておきます。

たとえば、人事面談の議事録を要約させれば社員の評価が、海外取引先の仕様書を翻訳させれば守秘義務の対象が、新製品発表資料のたたき台を作らせれば未公開の発売日が、原文ごと入力されてしまいます。

利用を許可するサービスとアカウントを決める

業務で使ってよい生成AIサービスを一覧で指定し、会社が管理するアカウントでのみ利用させることをルールに明記します。個人アカウントでの利用では、入力内容も利用状況も会社から見えず、事故の原因を追えなくなるからです。

新しいサービスを使い始める際は、利用目的と対象業務を示して情報システム部門の事前承認を受ける手順も設けます。扱う情報の機密度は部門で異なるため、マーケティング部門には広告文の作成を認め、経理部門は公開情報の調査に限るなど、部門ごとに利用範囲を分ける方法も選べます。

出力を確認する手順と責任の所在を決める

生成AIの出力は完成品ではなく下書きとして扱い、社外に出す前に人が確認する工程をルールで定めます。誤りはもっともらしい文章に紛れるため、確認すべき箇所を指定しておかなければ見落とされやすくなります。

確認対象として明記したいのは、数値や統計、法令や規制、製品名や日付などの固有名詞、引用元やURLです。誰が確認の責任を負うのかも業務ごとに決めておきましょう。顧客向けの操作手順書は作成者本人が画面表記まで照合し、社外向けニュースレターは部門長が数値と引用元を承認する、といった形が一例です。

事故が起きたときの報告ルートを決める

機密情報を入力してしまった、誤った出力を社外に出したといった場面に備え、誰に、何を、いつまでに報告するかを決めておきます。令和2年改正個人情報保護法により、令和4年4月1日から、要配慮個人情報を含む場合や1,000人を超える場合など、法令で定める一定の個人データの漏えい等が発生したときは、先に挙げた個人情報保護委員会への報告と本人への通知が義務となりました。

報告をためらわせないよう、利用者が申告しやすい窓口も用意しておきたいところです。ただし、ルールを整えても現場の注意だけでは防ぎきれない範囲が残るため、仕組みで守る対策が欠かせません。

参照元：個人情報保護委員会｜漏えい等報告・本人への通知の義務化について

仕組みで守る技術的な対策

社内ルールは、利用者が正しく判断することを前提にしています。しかし、うっかりした入力や確認漏れは注意だけではなくせないため、ルールが破られても被害が広がらない仕組みを技術面で用意しておく必要があります。

参照範囲の制限、認証の保護、利用状況の記録、利用環境の選定と制限という4つの対策は、それぞれ人の判断を補う役割を担います。4つの対策ごとに、システム側で備えておく内容と、選ぶときの判断の観点を示します。

参照元：総務省｜AIのセキュリティ確保のための技術的対策に係るガイドラインの公表

AIに参照させるデータの範囲を権限で絞る

AIが参照できる情報は、利用者自身に付与されたアクセス権の範囲に限るのを基本とします。AIを通せば本来見られない資料まで取り出せる状態では、権限設計が意味を失うためです。機密度の高いデータは参照対象から切り離し、部門や業務の単位で参照範囲を分けておきます。

たとえば、経営企画部の中期計画資料は全社向けのAIの参照先から外し、同部門専用の環境でのみ扱う方法があります。実行を許す操作も必要最小限にとどめ、メール送信やファイル削除など影響の大きい操作には人の承認を挟みます。

認証とアカウント・認証情報を保護する

生成AIのアカウントは会社で管理し、シングルサインオン（1回の認証で複数サービスを使える仕組み）など社内の認証基盤と連携させます。異動や退職時に権限を一括で止めるためです。ログインには多要素認証（パスワード以外の要素も使う本人確認）を必須とし、パスワードもサービスごとに変えます。

APIキーやアクセストークンはソースコードや設定ファイルに直書きせず、専用の管理ツールで保管しましょう。AIを組み込んだ自社サービスを公開するなら、推論APIに認証とレート制限（一定時間の利用回数の上限）が欠かせません。

利用状況を記録し後から追跡できるようにする

生成AIを、誰が、いつ、どのデータを対象に使ったのかを記録に残しておきます。記録がなければ、事故が起きても誰が何を入力し、どこから漏れたのかを確かめられないためです。たとえば、担当外の部門の資料をAI経由で繰り返し参照している利用者がいれば、記録から早い段階でその兆候をつかめます。

万一の際も、対象となったデータと利用者をたどれるので、影響範囲を特定できます。ただし、記録は取得しただけでは役に立ちません。確認する担当者と頻度を決め、定期的に内容を見直す運用まで定めておく必要があります。

利用する環境を選び、それ以外の利用を制限する

同じ生成AIサービスでも、個人向けプラン、法人向けプラン、API経由の利用、閉域環境（会社が管理する専用網）では、入力データの扱いが変わります。提供形態を比べる際は、学習利用の可否、入力と出力の保持期間、管理機能の有無、操作記録の取得可否という観点で確認します。

ただし、通信経路を限定しても、機密情報がそのまま入力される問題や出力の誤りは解決しません。提供形態の見直しは、ここまでの3つの対策と組み合わせてはじめて効果を発揮します。

機密情報の入力そのものを抑えるには、選んだ環境以外で生成AIが使われない状態も作る必要があります。プロキシやCASB（クラウドサービスの利用状況を把握し制御する仕組み）で未許可のAIサービスへの接続を制限すれば、会社が把握していないAI利用、いわゆるシャドーAIを減らせます。DLP（機密情報の持ち出しを検知して止める仕組み）などで入力内容を検査し、禁止した情報を含む送信に警告を出したり止めたりする方法も有効です。4つの対策が自社でどこまで整っているかは、次章で点検できます。

参照元：独立行政法人情報処理推進機構｜「情報セキュリティ10大脅威 2026」解説書［組織編］

対策の着手順を自社で判断する

対策の着手順は、経路ごとに手当て済みの範囲と手つかずの範囲を切り分けてから決めます。優先すべき経路は一般論では決まらず、自社が扱う情報の機密度と、AIを社内データにどこまで接続しているかで変わるためです。

たとえば、AIをまだ社内データにつないでいない段階なら、入力のルールとアカウントの管理を先に固めます。社内のストレージや業務システムにすでに接続している、または接続を予定している場合は、参照範囲の制限と操作の記録を最優先に据えましょう。どちらの段階でも、機密度の高い情報を多く扱う部門から順に手を付けると、限られた工数で影響の大きい経路を先に塞げます。

経路別に最初に確認することと、確認に必要な情報の所在を下表に示します。

表をふまえ、次の8項目で自社の現状を点検してください。

• ●業務で利用してよい生成AIサービスを一覧で示せる
• ●入力してはいけない情報を、機密度の区分で説明できる
• ●利用中のサービスで入力データが学習に使われるかを確認済みである
• ●社外に出す文書で、AIの出力を人が確認する手順が決まっている
• ●AIが参照できる社内データの範囲を管理者が把握している
• ●生成AIのアカウントに多要素認証を適用している
• ●生成AIに関する操作の記録を、後から確認できる
• ●事故が起きたときの報告先と連絡手順が決まっている

点検で手つかずの経路が複数見つかれば、技術的な対策より先に社内ルールの整備から着手します。ルールを整えたあとは、技術的な対策のうち参照範囲の制限と操作の記録から仕組みに落とし込みます。とくにAIを社内文書につなぐ段階では、この2つを文書の保管基盤の側で担保する方法を検討しておきましょう。

DirectCloudで実現する生成AIのデータ統制

AIに渡すデータそのものを統制するには、社内文書の保管場所とAIの接続口を同じ管理下に置く方法があります。法人向けクラウドストレージのDirectCloudが提供するDirectCloud AIでは、ファイルの権限管理や操作記録の仕組みを、AI経由の利用にもそのまま適用できます。先に挙げた提供形態の比較観点に照らすと、入力データを学習に使わない点、管理者が利用者を制御できる点、操作の記録を残せる点がDirectCloud AIの特徴です。

参照範囲の制限、データの保管と学習利用、操作の記録という3つの観点から、DirectCloud AIで実現できる統制の機能を紹介します。

権限のあるフォルダだけをAIに参照させられる

DirectCloud AIでは、DirectCloudで利用者に設定したアクセス権がそのままAIにも適用されます。MCPサーバー（お使いのAIと社内文書をつなぐ接続機能）を通じて検索する場合も、AIが扱えるのは利用者に権限のあるフォルダーのデータだけです。

たとえば、人事部のフォルダーに権限のない社員の質問に、人事部の資料が使われることはありません。AIを使えるのは管理者が許可したユーザーに限られます。MCPによる接続も初期状態では無効とし、二段階のホワイトリスト（利用を許可する対象を登録した一覧）で段階的に開放します。管理者や当社が内容を閲覧できる範囲も、初期状態では無効です。なお、利用者の制御など一部の管理機能は、ご契約のプランで対応範囲が変わります。

参照元：DirectCloud｜データ基盤を活用したAIサービス DirectCloud AI

原本を国内に保管したままAIで活用できる

原本ファイルは国内のデータセンターに保存したまま、AIによる検索や要約にご利用いただけます。AI用にファイルを複製したり、別のサービスへ移したりする必要はありません。

入力データや生成結果をAIモデルの学習に使用することもなく、回答の生成時には氏名、メールアドレス、住所に限り個人情報をマスキング（読み取れないよう隠す処理）します。なお、MCPで外部の生成AIに接続する場合、取得後のデータの扱いは接続先の契約と利用規約にも左右されるため、あわせて確認しておくと安心です。

参照元：DirectCloud｜DirectCloud AI（セキュリティ）

誰がいつ何をしたかをログで確認できる

DirectCloud AIでは、誰が、いつ、何を操作したかを記録しており、AIを経由した操作もすべてログに残ります。記録は監査や内部統制の場面で後から確認でき、AIの利用が社内ルールどおりだったかを検証する材料になります。たとえば、退職予定の社員がAI経由で参照したファイルを、記録から一覧で確かめることが可能です。

事故が起きたときも対象のファイルと利用者をたどれるため、影響範囲を特定し、権限設定の見直しなど再発防止策を具体化できます。操作記録の保存期間は、ご契約のプランによって異なります。

参照元：DirectCloud｜DirectCloud AI（MCPのセキュリティ）

AI活用の前提となるデータ統制を整えた事例

生成AIに参照させるデータを権限で絞り、操作を記録で追うには、まずファイル管理の土台が整っている必要があります。紹介する事例はいずれもAI導入を目的とした取り組みではありませんが、権限の一元管理、保管先の統合、操作記録の取得は、AIを社内データにつなぐ前提にあたります。

DirectCloudをご利用いただいている3社について、導入前に抱えていた課題と、導入後に実現した状態を紹介します。

権限が分散した状態から一元管理できる状態へ

再生可能エネルギー事業を手がけるリニューアブル・ジャパン株式会社様では、ファイルサーバーがActive Directory（社内のIDを一元管理する仕組み）のドメインに登録されていませんでした。デバイスごとのアクセス制限もなく、IPアドレスとIDとパスワードが分かれば接続できたといいます。

DirectCloudの導入後は管理者画面での一括管理が可能になり、デバイス認証とAzure Active Directory（現Microsoft Entra ID）との連携で、安全なログインを実現しています。

複数ストレージの乱立から参照範囲を絞れる状態へ

医療・介護などの領域で40以上のサービスを展開する株式会社エス・エム・エス様では、用途に応じて複数のクラウドストレージを使い分けていました。社員からはどのサービスを申請すればよいのか分からないという問い合わせが寄せられ、ユーザーごとに細やかなセキュリティ設定を施すことも難しかったといいます。

DirectCloudへの統合後は使うツールが明確になり、社内問い合わせへの対応工数が減っています。社内ユーザーと外部のゲストごとにアクセス権を設定できるようになったことも、成果のひとつです。

操作を追えない状態から記録で追跡できる状態へ

総合化学メーカーの東ソー株式会社様から情報システム部門が独立して生まれた東ソー情報システム株式会社は、システム開発やネットワーク構築を担っています。同社が社外とのやり取りに使っていたオンラインストレージは、利用者のファイル操作を記録に残せない仕様でした。共通アカウントの利用もあり、有事に操作した人を特定しにくかったといいます。

DirectCloudの導入後は、ユーザーと管理者を合わせて250種類以上の操作ログを取得できるようになり、インシデント発生時に誰が何をしたのかをたどれる体制を整えました。

よくある質問

生成AIの業務利用を進める際には、ルールや仕組みを決める段階で、情報システム部門や情報セキュリティ担当者が迷いやすい疑問がいくつかあります。

無料版の扱い、生成されたコードの使い方、著作権の確認方法、セキュリティを学ぶための資料の4つについて、本文の内容もふまえて質問ごとにお答えします。

まとめ

生成AIを安全に業務へ取り入れる鍵は、リスクが生じる経路を見極め、自社の状況に合わせて対策の順番を決めることにあります。生成AIは指示とデータを区別せずに動き、社内のデータや業務システムにもつながるため、従来の境界での防御だけでは守りきれません。入力、出力、外部経由の乗っ取り、権限という経路ごとに手当てを考える必要があるのはそのためです。

まずは社内ルールで判断の基準をそろえ、そのうえでAIに渡すデータを権限と記録で統制する仕組みへ進めば、情報漏えいや誤った発信を抑えながら、現場が迷わず生成AIを使える環境に近づきます。手当て済みの範囲と手つかずの範囲を切り分けることが、活用と安全を両立させる近道となります。

DirectCloudは、保存した社内文書を生成AIで活用できる「DirectCloud AI」を備えた法人向けクラウドストレージです。利用者のアクセス権がAIにもそのまま適用され、AIを経由した操作も記録に残るため、参照範囲の制限と追跡を同じ基盤で実現できます。生成AIの活用に向けてデータ統制の土台を固めたい企業のご担当者様は、ぜひ導入をご検討ください。