生成AIのセキュリティ｜7つのリスクと会社で安全に使う仕組み

生成AIのセキュリティとは、ChatGPTなどの生成AIを業務で使うときに、情報の漏洩、AIそのものへの攻撃、誤った出力の利用といった被害を防ぎ、起きたときに原因を追える状態を保つための対策の全体です。結論から言うと、社員10〜200名の会社が取るべき対策の中心は、生成AIを禁止することではなく、会社が安全性を確かめたAIを全員に配り、学習の設定・ログ・権限・アカウントを会社側で管理することです。この記事では、IPA（情報処理推進機構）のサイトで公開された手引書の7つの発生被害でリスクを整理し、会社で安全に使う仕組みを4つの要素に分けて、社員数別の進め方まで解説します。

※この記事で引用する手引書は、IPAのサイトに2026年7月31日に掲載された「生成AIおよびAIエージェントを安全に活用するための手引書」です。IPA産業サイバーセキュリティセンターの中核人材育成プログラム受講者（9期生）によるプロジェクトの成果物で、IPAが組織として定めたガイドラインではありません。内容は執筆時点（2026年6月）の情報に基づき、IPAの意見を代表するものではないと明記されています。ページ番号は同PDFのものです。

生成AIのセキュリティとは｜従来の対策だけでは守れない理由

生成AIのセキュリティで守る対象は、社員が入力する情報、AIがつながる社内のデータ、AIが返す答えの3つで、どれも従来のネットワーク対策だけでは守り切れません。生成AIのリスクの多くは、正規の利用者が正規のサービスを普通に使う中で起きるためです。

生成AI特有のリスクが従来の対策（ファイアウォール・WAF・EDR）では防ぎにくい理由

ファイアウォールは通信の出入りを制御し、WAFはWebアプリケーションへの攻撃を防ぎ、EDRは端末の不審な動きを検知する仕組みです。いずれも重要ですが、生成AIのリスクには次の3つの理由で効きにくくなります。

• 入力は正規の通信として流れる：社員が顧客情報をAIに貼り付けて送る通信は、許可されたWebサービスへの通常のアクセスで、普段の閲覧と区別がつきにくくなります。
• 攻撃が普通の文章で書かれる：プロンプトインジェクションは、メールや文書に紛れ込ませた文章でAIをだます攻撃で、不正なプログラムの形を取らないため端末の監視では捉えにくくなります。
• 誤りが攻撃なしに起きる：生成AIは確率的に文章を作るため、攻撃を受けていなくても事実と違う答えを返すことがあります。手引書も、誤った出力の利用という被害は攻撃だけでなく、生成の仕組みそのものに起因して起きる点が他の被害と異なると説明しています（p.39）。

この事情は公的な資料にも表れています。手引書は、AIサービスへのデータ送信に特化した検知機能を持つ製品が登場し、従来のセキュリティ製品では識別が困難だったAI固有の通信パターンを検知できるようになりつつあると紹介しています（p.18）。総務省のガイドラインも、対策例を実装してもAIの性質上、脅威を生じさせる要因を完全に排除することは困難だとし、複数の対策を重ねてリスクを下げる考え方を示しています。

公的な資料は、それぞれ誰に向けて書かれているか

公的な資料は、想定する読者が違います。IPAのサイトで公開された手引書は、発生被害をユーザ企業の立場から選んだと書いており、AIを業務で使う会社に近い視点です。一方、総務省「AIのセキュリティ確保のための技術的対策に係るガイドライン」（令和8年＝2026年3月）は、想定読者をAI開発者とAI提供者と明記しており、利用する会社の手順書ではありません。後半で示すように、配るAIの提供者へ確認する項目として使えます。利用者側については、総務省・経済産業省「AI事業者ガイドライン」が、機密情報等や個人情報を不適切に入力しないよう注意を払うことを求めています（引用は原文を確認できた第1.1版から。最新版は第1.2版・2026年3月31日公表）。

生成AIのリスクを7つの発生被害で整理する

生成AIのリスクは、手引書の7つの発生被害で並べると、社員の使い方で防ぐものと、AIの仕組みや提供者の対策で防ぐものを分けて考えられます。手引書は被害を受ける会社の立場から、業務上の実害につながる被害を7つに整理しています（表4-1・p.33）。

※発生被害の記号と名称は手引書の表4-1（p.33）によります。場面と防ぐ手段は、手引書の説明をもとに社員10〜200名の会社向けに整理したものです。

社員がチャット画面で生成AIを使う段階の会社では、当面の中心はAの情報の漏洩とEの誤った出力の利用です。手引書も、AIエージェントではない単体の生成AIの場合、付与権限外の操作のリスクは限定的だとしています。B・C・F・Gは、AIにメール送信やファイル操作の権限を持たせたり、APIで自社のシステムに組み込んだりしたときに大きくなります。会社で今起きている問題点の一覧はAIの問題点、国内で公表された事案は生成AIの情報漏洩・シャドーAI事例にまとめています。

機密情報・個人情報の入力による漏洩と、入力データの学習利用・保存

発生被害Aのうち、10〜200名の会社で起こりやすいのは社員の入力による漏洩です。入力した情報は、サービスの提供者の設備に送られます。個人向けプランでは設定によって学習に使われうるほか、学習に使われない場合でも一定期間は保存されます。学習に使われるかどうかと、どこにどれだけ保存されるかは、分けて確認する必要があります。

2023年5月には、韓国のサムスン電子が主要部門の社員に対し、社用端末と社内ネットワークにつながる端末での生成AIの利用を当面禁じたと報じられています（Bloomberg・TechCrunch 2023年5月2日）。国内でも、RIZAP株式会社が2026年9月3日、社員が個人で使っている外部の生成AIサービスに顧客の情報を誤ってアップロードしたと公表しています。

個人情報を扱う会社は、個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」（2023年6月2日）も確認しておく必要があります。事業者に向けて、個人情報を含むプロンプトの入力が利用目的の達成に必要な範囲内かを十分に確認すること、提供事業者が個人データを機械学習に利用しないこと等を十分に確認することを求めています。違反かどうかは個別の判断ですが、学習に使わないことを会社として確かめた環境が前提になります。個人情報に絞った論点はChatGPTに個人情報を入力するリスクで、学習させない設定の画面手順はChatGPTに学習させない方法で解説しています。

プロンプトインジェクション（直接・間接）とデータポイズニングなど、AIそのものへの攻撃

プロンプトインジェクションとは、AIに細工をした入力を与えて、本来しない出力や動作をさせる攻撃です。総務省のガイドラインは、細工をしたプロンプトを直接入力するものを直接プロンプトインジェクション攻撃、細工をしたデータをAIに参照させるものを間接プロンプトインジェクション攻撃と呼び分けています。会社にとって注意が必要なのは後者です。AIに読ませたWebページ、メール、添付ファイルに悪意のある指示が埋め込まれていると、利用者が何も悪いことをしていなくても被害が起きえます。

手引書は情報の漏洩の事例として、Microsoft 365 CopilotのEchoLeakを挙げています（p.34）。Aim Security社が発見し2025年6月に公表されたもので、細工したメールを送るだけで、利用者の操作なしに機密情報が流出しうる状態だったと説明されています。メール本文に埋め込まれた指示をAIが実行してしまう問題で、Microsoftは2025年5月に修正を適用しています。社員が入力に気をつけるだけでは防げない被害の例です。

データポイズニングは、AIが学習するデータや参照するデータに細工をして、誤った出力をさせる攻撃です。総務省のガイドラインはその他の脅威として、データポイズニング攻撃、細工をしたモデルの導入を通じた攻撃、モデル抽出攻撃を挙げています。社内文書をAIに参照させる仕組み（RAG）を使う場合は、参照先に誰が文書を書き込めるかが、発生被害Cの改ざんの防ぎ方に直結します。RAGの仕組みはRAGとはで解説しています。

これらの攻撃は、利用する会社だけで完全に防ぐことはできません。手引書も、指示とデータを構造的に分ける対策について、現時点では多くのAIモデルがこの分離を十分に実現できていないとしています。会社にできるのは、AIがつながる範囲を必要な分に絞ること、外部の情報を読ませる使い方を把握すること、提供者がどんな対策をしているかを確かめることです。

ハルシネーション（誤情報）を確認せず業務や社外発信に使うリスク

ハルシネーションとは、AIが事実と異なるもっともらしい情報を作ってしまうことで、発生被害Eにあたります。手引書は事例として、米国の損害賠償訴訟で原告側の弁護士がChatGPTで法律調査をし、実在しない判例などを裁判書面に記載した2023年の件を挙げています（p.39）。裁判所は必要な確認を怠ったとして、弁護士2名と法律事務所に連帯して5,000ドルの制裁金などを命じたと紹介されています。

対策の考え方は、AIの答えは誤りを含む前提で工程を組むことです。社外に出す文書、数字、法令や規約の解釈、出典の記載は、人が一次情報で確かめてから使うルールにします。手引書も、全社のガイドラインに記載すべき事項として、人間による出力の事実確認と、ハルシネーションを前提とした運用設計を挙げています（表2-2・p.17）。

著作権・知的財産権の侵害

生成AIの出力が既存の著作物に似ていた場合などには、権利侵害を問われるおそれがあります。手引書は、権利侵害を含む出力を確認せずに使うことも発生被害Eに含め、社内ガイドラインの記載事項に第三者の権利侵害の確認を入れています。社外に公開する画像・文章は、似た作品がないかと、サービスの規約での商用利用の扱いを確認する工程を入れておきます。判断の基準は生成AIと著作権で詳しく解説しています。

ディープフェイクによるなりすまし・送金詐欺

ディープフェイクとは、AIで人物の顔や声を本物らしく作り変えた映像や音声のことで、手引書も偽情報として悪用されるリスクに触れています。会社にとっては、経営者や取引先の声・映像をまねて送金や振込先の変更を求められる形の脅威です。社内でAIを使っているかに関係なく受けうるため、対策は業務の手順が中心になります。送金や振込先の変更は電話・メール・ビデオ会議だけで決めず、登録済みの連絡先へ折り返して確認する、一定額を超えたら2人で承認する、といったルールを決め、急がせる依頼ほど確認を省かないことを教育で伝えます。

AIエージェントで大きくなる、権限外の操作・停止・過剰課金

AIエージェントとは、メール送信やファイル操作まで自律的に進めるAIのことです。手引書は発生被害Bの事例に、AIエージェントにメールの権限を与えた結果、意図せず数百通のメールが削除された2026年に報じられた事案を挙げ、原因を過剰な権限と、実行前の人の承認をシステムに組み込んでいなかったことだとしています（p.35）。発生被害Gでは、盗まれたクラウドの認証情報でAIが不正利用され、被害企業の損失が1日あたり最大4万6,000ドルと試算された2024年の事案を、Sysdig社の報告（同社の試算）として紹介しています（p.41）。

AIに社内システムの権限を渡す、APIキーを発行するといった段階では、権限を必要な分だけにする、削除や送信の前に人が承認する、利用料の上限と通知を設定する、AIが止まったときの業務の回し方を決める、の4点が基本です。

シャドーAIと、全面禁止の落とし穴

会社が把握していないAIの利用は、禁止を強めるほど見えにくくなるため、禁止より先に公認の手段を用意する順序で考えます。

シャドーAI（会社が把握しない個人のAI利用）

シャドーAI（野良AI）とは、会社が認めていない、または把握していないAIサービスを、社員が個人の判断で業務に使うことです。個人アカウントでの利用は、学習させない設定が本人任せになる、会社がログを見られない、退職後もアカウントと会話履歴が本人の手元に残る、という3つの点で管理が効きません。発生被害Aの多くは、この経路から起きます。定義と背景は野良AI（シャドーAI）とは、社内で使われているツールの見つけ方は野良AI（シャドーAI）の見つけ方で解説しています。

全面禁止ではなく管理する（禁止するとシャドーAIが増える）

全面禁止にしても、業務で使いたい社員が個人のスマートフォンで使う動機は残ります。手引書は、シャドーAIの発生は多くの場合、悪意ではなく業務上のニーズから生じるため、禁止を先行させるだけでは申告されない利用が増え、実態の把握がさらに難しくなるリスクがあると指摘しています（p.18）。手引書が示す全社のAI利活用ガイドラインの留意点としても、過度に厳格なルールは利用者の回避を招き、かえってリスクを高める可能性があるとし、禁止一辺倒ではなく代わりの手段とセットでルールを作ることを勧めています（p.17）。

禁止は、生成AIそのものではなく、特定の危険なサービスや入力してはいけない情報に向けると、ルールと業務の実態が離れにくくなります。

手引書が示すシャドーAIへの3つの統制方法

手引書はシャドーAIへの対応として、次の3つを挙げています（p.18）。

1. 組織公認AIの提供：業務に使いたいのに公式な手段がない状況を大きな要因に挙げ、IT部門が安全性を検証した組織公認AIを全社（または情報漏洩リスクの高い部署から優先的に）提供することが、シャドーAI対策の有効な前提条件の一つだとしています。
2. ルールの明文化と教育：承認したAIの一覧と、それ以外の利用禁止をガイドラインに書き、新しいAIの審査手順を用意します。審査の観点や却下されやすい条件を先に示すと、承認も早くなるとしています。
3. 技術的な検知・遮断：許可していないAIへの通信を製品で検知・遮断する方法です。費用と工数がかかるため明らかに危険なサービスに絞ったスモールスタートが現実的とし、会社のネットワークを経由しない端末からの利用は技術的な制御が困難だとも書いています。

専任がいない会社では、3の遮断を先に整えるのは負担が大きく、効果にも限界があります。1の公認AIを配り、2のルールで使い方を決める順に進めるのが現実的です。

会社で安全に使う仕組みは4つの要素でできている

公認のAIを配るときに会社側で押さえるのは、学習させない設定の固定、ログの保存、権限と使えるモデルの管理、アカウントの配布と停止の4つです。

①学習させない設定を社員任せにせず会社側で固定する

個人向けプランの学習の設定は本人がそれぞれの画面で行うもので、会社からは状態を確認しにくくなります。社員一人ひとりの操作に頼らず、法人向けの契約と管理画面で全員の条件をそろえるのが1つ目の要素です。

法人向けプラン・学習に使われない環境の選定：OpenAI・Anthropic・Googleの学習と保存期間

法人向けプランは、学習に使われないかだけでなく、誰が保存期間を決めるか、削除した会話がいつ消えるかまで確認します。主要3社の公式の記載は次のとおりです。

※各社の記載は、2026年9月17日〜18日時点で公式ページ（OpenAI「エンタープライズプライバシー」、Anthropicのプライバシーセンターとヘルプ、Google Workspace「生成AIに関するプライバシーハブ」2026年8月14日更新）を確認したものです。機能の範囲はプラン・契約により異なり、変更されることがあります。Anthropicの保持期間の設定・監査ログ・Compliance APIはEnterpriseプランの機能です。

3社とも既定で学習に使わない点は共通で、違いは保存期間を会社が決められるか、管理者がどこまで会話を確認できるかです。選ぶときは、データの処理を委託する先（サブプロセッサー）など第三者への提供の範囲も、公開資料や契約書で確かめます。ChatGPTの法人プランの料金と違いはChatGPTの法人プラン、国内の法人向けサービスの横並びは法人向け生成AIサービスの比較にまとめています。

学習に使われないことと、管理者が会話を見られることは別の論点

学習に使われないことは、社内の誰にも見られないという意味ではありません。表のとおり、ChatGPT Businessでは管理者がメンバーの会話履歴を閲覧・書き出し・削除でき、ログを取れば誰がいつ何を入力したかも確認できます。

社員が後から知ると、監視されていたという不信感につながります。導入時には、誰が（管理者は何名か）、何を（利用日時・使ったモデル・入力と出力の本文のどこまで）、どんなときに（定期確認か、問題が起きたときだけか）、どれだけの期間見られるのかを文書で伝えておきます。手引書も、ログ自体に機密情報が含まれる場合はログの閲覧権限の管理が必要だとしています（p.73）。

②アクセス権限の管理とログの取得・監視：取得する項目と保存期間の例

2つ目の要素はログです。ログがなければ、情報が漏れたかもしれないときに、誰が何を入力したのかを確かめられず、報告の要否も判断できません。手引書は、インシデントの原因究明と不正利用の検知のために取得すべきログとして、次の項目を挙げています（p.72）。

• 利用者と端末：ユーザID、所属部門、端末の情報、IPアドレス
• 利用時間：アクセスとリクエストの日時
• 利用したシステム：どのAIシステムの、どの基盤モデルを使ったか
• 入力：入力したプロンプトの生データ、添付ファイル名
• 出力：AIが生成した出力の内容、消費したトークン数（AIが処理した文字量の単位）
• 制御：入力を検知・遮断する仕組みによるブロックやマスキングの履歴

保存期間については、すべての入出力の本文を長く残すと保管の費用が膨らむとして、日時やユーザIDなどのメタデータは長期保存（例：1年）、容量の大きいプロンプトや出力の本文は短期保存（例：3か月）とする例を示しています。10〜200名の会社なら、まず利用者・日時・モデル・入出力の本文が残る状態を作り、保存期間を社内規程に書くところから始めます。無期限に残すと、ログ自体が漏れたときの被害が大きくなります。

ログ監査は3段階で考える

手引書は、ログの確認を組織の成熟度に応じて3段階で高めていく方法を示しています（p.73）。

1. レベル1　ログの蓄積と事後確認：ログを残し、問題が起きたときの調査や月次などの定期確認に使います。未然防止はできませんが、AIシステムを導入するすべての企業が最低限実施すべきレベルとされています。
2. レベル2　キーワード・パターン検知による自動通知：機密情報の名称などを登録しておき、検知したら担当者に自動で通知します。一定の費用はかかりますが、明らかなルール違反を自動で見つけられます。
3. レベル3　監査用AIの導入：入力を監査用のAIにも読ませて文脈で判定します。利用料が実質2倍になるなど、費用対効果の見極めが必要だとしています。

専任がいない会社はレベル1から始め、月に1回、利用が急に増えた人や深夜の大量利用がないかを見ます。手引書は、ログの存在自体が内部不正の抑止力になるとも説明しています（p.77）。

入出力フィルタリングとDLPの位置づけ

DLPは機密情報の送信を検知・遮断する仕組み、入出力フィルタリングはAIへの入力と出力を検査し、決めたパターンを止めたり伏せ字にしたりする機能です。手引書は、情報の漏洩に対してまず取り組むべき基本対策として、入出力のフィルタリング、連携先システムへのアクセス制御、ログの有効化による漏洩監視、個別システム特有のルール策定の4つを挙げています（付録・p.76〜78）。

ただし、残るリスクも明記されています。ブロックリストに登録していないパターンは検出漏れが起き、機密情報が言い換えや要約された形で出力された場合はルールでの検知が難しいとしています（p.76）。導入には設定変更や業務影響の調査が必要なため、機密情報を扱う部門に絞って始めるのが現実的だとしています（p.72）。フィルタリングは公認AIとログの上に重ねる対策です。

③管理者が権限と使えるモデルを管理する

3つ目の要素は、管理者が権限と使えるモデルを切り替えられることです。モデルによってデータの経路や保存の条件が違うため、使わせたくないモデルや機能を管理画面で止められる状態にしておきます。

社内の文書やデータをAIにつなぐ場合は、権限の設計がさらに重要になります。手引書は、AIが到達できるデータの範囲と、利用者がAI経由で引き出せるデータの範囲の両方を制限する必要があり、どちらか一方だけでは不備を補えないとしています（p.77）。総務省のガイドラインも、社内文書を参照させる仕組みでは、参照権限をユーザーや役割に応じて設定することを提供者の対策に挙げています。

④アカウントの配布と退職時の停止、社員への事前説明

4つ目の要素は、アカウントを会社から配り、会社が止められる状態にすることです。手引書は、アクセス制御に残るリスクとして異動者・退職者の無効化の漏れを挙げています（p.77）。

• 入社時に会社のアカウントを発行する個人アカウントを業務に使わないことを入社時の説明に入れます。
• 退職日と異動日にアカウントを止める手順を決めるパソコンやメールと同じ入退社の手順書に1行入れておきます。
• 管理者が見られる範囲を事前に説明するログの項目・確認する人・確認のタイミング・保存期間を、利用開始前に文書で伝えます。
• 個人アカウントに残った業務の会話の扱いを決める公認AIへ移るときに、本人に確認と削除を依頼します。

ルールと教育で、仕組みの届かない部分を補う

仕組みで防げない部分は、入力してよい情報の区分と、出力を確かめる習慣をルールと教育で定着させて補います。

利用ガイドラインと、入力してよい情報・禁止情報の区分、定期的な見直し

手引書は、ガイドラインに記載すべき事項に、利用可能なAIの一覧と申請手順、データ入力基準、出力結果の取扱い、禁止事項、インシデント時の対応などを挙げています（表2-2・p.17）。データ入力基準では、情報を公開情報・社内情報・機密情報・個人情報などに分類して入力禁止の情報を定義し、迷ったときの相談窓口を決める例を示しています。

手引書は最低限の内容から始めて更新していく運用を勧め、利用の実態は最低でも年1回を目安に定期的に把握し直し、主要なAIの大きな更新や、社内外で重大なインシデントが起きたときにも見直すことが望ましいとしています（p.19）。ガイドラインの項目とひな形は生成AIの社内ガイドラインの作り方、今の状態を点検する30項目は生成AIのセキュリティ対策チェックリストにまとめています。

従業員教育・リテラシー向上

手引書は、AIを使うすべての従業員に対する定期的な教育に含める項目として、ガイドラインの内容、AIが引き起こす発生被害とその事例、ハルシネーションを前提とした出力確認の重要性、組織公認AIがある場合はそれを使うべき理由を挙げています（p.21）。半年前の知識が古くなることもあるため、1回で終わらせないことを求めています。

また、禁止事項の押し付けだけでなく、公認AIには安全策があり安心して使えるという前向きな伝え方で、ルールの順守率を高められるとしています。社員10〜200名の会社なら、利用開始時に30分の説明会を開き、その後は半年に1回、社内で起きたヒヤリとした例を共有するところから始めるとよいでしょう。研修の組み立て方は生成AI研修で解説しています。

配るAIの提供者に確認すること

総務省のガイドラインは提供者向けの資料ですが、利用する会社にとっては、配るAIの提供者に何を確認するかの項目として使えます。プロンプトインジェクションのように利用者側だけでは防げない被害は、提供者の対策で差が出るためです。

ガイドラインは主な脅威にプロンプトインジェクション攻撃とDoS攻撃（大量の処理でサービスを止める攻撃）を挙げ、想定事例の1つ目に内部向けチャットボット（RAG利用）を取り上げています。提供者の対策を確認の質問に置き換えると次のとおりです。

• 入力されたプロンプトに不正な指示がないかを検証しているか検知時に無害化や処理の拒否をするかを聞きます。
• Webページや添付ファイルなど、外部のデータに含まれる指示を検証しているか間接プロンプトインジェクションへの対策です。
• 出力に、出すべきでない情報が含まれていないかを検証しているか権限のない社員に情報が返らないかにも関わります。
• 社内文書を参照する機能の権限を、ユーザーや役割ごとに設定できるか連携するシステムの権限を必要最小限にしているかもあわせて確認します。
• 監査ログを保存しているか、会社側でどこまで確認できるかガイドラインは、監査ログの保存によるトレーサビリティ（後から経緯を追えること）の確保を基本的な対策に挙げています。
• 大量のアクセスを抑える制限（レートリミット）や、利用量の上限があるか発生被害Gの過剰課金を防ぐことにもつながります。
• 入力した個人データを機械学習に利用しないことを、契約や公開資料で確認できるか個人情報保護委員会の注意喚起が求める確認点です。保存期間と保存場所もあわせて聞きます。

ガイドラインは、こうした対策を講じて秘密のデータを適切に管理しているAIシステムを利用すれば、そこから漏洩した場合でも、不正競争防止法の営業秘密の要件の1つである秘密管理性を満たし、保護を受けられるものと考えられる、という見方も示しています（営業秘密として保護されるには、有用性と非公知性も必要です）。

社員数別の進め方

進め方は、社員数と、情報システムの専任や兼任の担当者がいるかどうかで分けると決めやすくなります。

社員10〜50名・情報システムの専任がいない会社

1. 公認AIを1つ決め、全員に配る：一部だけに配ると、残りの人が個人アカウントに流れます。
2. 個人アカウントでの業務利用を止める：配った日から切り替えます。
3. 入力禁止の情報を1枚にまとめる：顧客の個人情報、預かった資料、未公表の数字など具体的に書きます。
4. アカウントの停止を入退社の手順に入れる：パソコンやメールと同じ手順書に加えます。
5. 月に1回ログを見る：手引書のレベル1にあたります。担当は総務などの兼任で構いません。

社員50〜200名・兼任の担当者がいる会社

1. 部門ごとに権限と使えるモデルを分ける：人事・経理などは参照できる社内文書を別に設定します。
2. ログの項目と保存期間を社内規程に書く：メタデータ1年・本文3か月といった手引書の例を参考に、自社の期間を決めます。
3. ログの定期確認を担当と日程で決める：機密情報の名称の検知（レベル2）は、機密情報を扱う部門から試します。
4. 例外申請の窓口を作る：申請先と審査の観点を公開し、シャドーAIに流れる前に相談が来る状態にします。
5. AIエージェントやAPIの前に発生被害B・C・Gを点検する：権限・承認・利用量の上限を決めます。

※社員数による分け方は目安です。業種や扱う情報（個人情報・医療情報・顧客から預かる機密情報など）の量によって、50名未満でも50〜200名の手順が必要になる場合があります。

漏えいが起きたときの報告期限を先に確かめておく

個人データの漏えい等が起き、報告の対象に当たる場合、個人情報保護委員会への速報は発覚日から3〜5日以内、確報は30日以内（不正な目的で行われたおそれがある場合は60日以内）が目安です。公認AIを配る時点で手順に入れておきます。

民間事業者の報告の対象は次の4つで、いずれも漏えい等のおそれがある場合を含みます。

1. 要配慮個人情報（病歴など）が含まれる個人データの漏えい等
2. 不正に利用されることで財産的な被害が生じるおそれがある個人データの漏えい等
3. 不正の目的をもって行われたおそれがある個人データの漏えい等
4. 本人の数が1,000人を超える個人データの漏えい等

※報告期限と対象は、2026年9月18日時点で個人情報保護委員会の漏えい等の報告に関するページで確認したものです。生成AIへの入力が対象に当たるかは個別に判断されます。

報告の要否を判断するには、誰がいつどのAIに何を入力したかを確かめる必要があり、ここで2つ目の要素のログが役立ちます。個人アカウントでの入力は、本人の記憶に頼ることになります。社員が誤って入力してしまったときの社内の初動はChatGPTに個人情報を入力するリスクでチェックリストにまとめています。

よくある質問

生成AIの業務利用は禁止したほうが安全ですか？

全面禁止は、かえって会社から見えない利用を増やすおそれがあります。IPAのサイトで公開された手引書も、禁止を先行させるだけでは申告されない利用が増えるリスクを指摘しています。使ってよいAIを会社で決めて全員に配り、入力してはいけない情報と危険なサービスを禁止する形が現実的です。

法人向けプランにすれば、セキュリティ対策は十分ですか？

十分ではありません。学習に使われない状態にできても、入力のルール、出力を人が確認する工程、ログの確認、退職時のアカウント停止は会社が整える必要があります。また、学習に使われないことと会話が保存されないことは別なので、保存期間と管理者から見える範囲も確かめてください。

社員数が少ない会社でも、ログを残す必要はありますか？

必要です。ログがなければ、誰がいつどのAIに何を入力したかを確かめられず、個人情報保護委員会への報告の要否も判断できません。手引書は、ログを蓄積して事後や定期的に確認する段階を、AIを導入するすべての企業が最低限実施すべきレベルとしています。

管理者が社員の会話を見られるのは問題になりませんか？

問題になりやすいのは、社員が知らないまま見られていたと後で分かる場合です。導入時に、確認する人、見られる項目、確認するタイミング、保存期間を文書で伝えておくと、管理のための確認として理解を得やすくなります。

プロンプトインジェクションは、社員が注意すれば防げますか？

社員の注意だけでは防げません。メールや添付ファイルに埋め込まれた指示をAIが読み込む間接プロンプトインジェクションは、利用者が操作しなくても起きえます。AIがつながるデータと権限を絞ること、提供者が入力・外部データ・出力を検証しているかを確かめることが対策になります。

まとめ

生成AIのセキュリティは、社員が入力する情報、AIがつながる社内データ、AIが返す答えを守る対策の全体で、ファイアウォールなど従来の対策だけでは守り切れません。IPAのサイトで公開された手引書の7つの発生被害で整理すると、社員がチャットで使う段階の会社では、情報の漏洩と、誤った出力の利用が当面の中心になります。

対策の中心は、禁止ではなく、会社が安全性を確かめたAIを全員に配ることです。そのうえで、学習させない設定を会社側で固定する、ログを残して項目と保存期間を決める、管理者が権限と使えるモデルを管理する、アカウントを配布して退職時に止め、管理者が会話を見られることを事前に説明する、の4つを整えます。

仕組みで届かない部分はルールと教育で補い、提供者の対策は総務省のガイドラインをもとに確かめ、漏えい時の報告期限も導入時に手順へ入れておいてください。法人のAI活用に関する他の記事はAI活用コラム一覧をご覧ください。