生成AIのセキュリティ対策とは？中小企業が安全に業務活用するための判断基準

最終更新日：2026年09月22日

監修：株式会社アスタ 代表取締役 小路雅也

生成AIを仕事に使いたいものの、顧客情報を入力してよいのか、社員が個人のアカウントで使っていないかが気になる。禁止すれば安心とも言い切れず、どこまで許可すべきか迷っている経営者もいるのではないでしょうか。

生成AIで何を禁止すべきかは、会社や業務の条件によって異なります。まず、実現したい業務と守るべき情報を整理し、会社としての利用方針を決めます。その方針に、利用するAIの設定・社内ルール・管理体制・取引先との契約が合っているかを確かめることが対策の基本です。法人向けプランの契約や禁止事項の配布だけで、判断を終えないようにします。

この記事では、中小企業の経営者・実務責任者に向けて、生成AIの主なリスク、導入前に確かめる条件、無理なく続けられる運用を解説します。特定製品の安全性を保証するものではなく、自社の利用方法を判断するための考え方を整理します。

生成AIのセキュリティは、情報の流れ全体で考える

生成AIのセキュリティとは、AIを利用する過程で、情報を許可のない相手へ渡したり、意図しない操作を実行したりするリスクを抑えることです。入力欄へ貼り付ける文章だけでなく、添付ファイル、参照する社内資料、会話履歴、出力された文書、外部サービスとの接続までが確認の対象になります。

たとえば、営業担当者が提案書の下書きを作る場面を考えます。入力する商談メモには顧客名や取引条件が含まれ、AIが参照する共有フォルダには別の顧客の資料があり、完成した文書は社外へ送られます。入力時の注意だけでは、他社の条件を混ぜることや、完成後の共有範囲の誤りまでは防げません。これは説明用の仮定ですが、身近な一業務でも複数の確認点があるとわかります。

IPAは、AI利用に伴うセキュリティ上の脅威やリスク、利用者向けの対策情報を公開しています。自社で検討する際も、AIという名称だけで危険・安全を決めず、扱う情報と使い方に分けて確かめることが重要です。参考：IPA「AIセキュリティ」。

主なリスクは、情報漏えい・過剰な権限・不適切な出力

まず注意したいのは、業務情報が想定外の範囲で扱われることです。社員が未承認のサービスへ資料をアップロードする場合だけでなく、会社で認めたサービスでも、共有設定や連携先の権限を誤れば問題になります。サービス自体の対策と、利用企業側の設定・運用は分けて確認します。

学習への利用と、保存・共有は別の確認事項

入力した情報がAIの学習に使われるかは大切な条件です。ただし、学習に使われない契約でも、会話履歴の保存、管理者による閲覧、共有リンク、外部連携などの条件が同じとは限りません。「学習に使われない」ことだけを根拠に、すべての機密情報を入力してよいとは判断できません。

同じブランドのAIでも、個人向けと法人向け、画面からの利用とシステム連携では条件が異なる場合があります。実際に契約するプランの規約と管理画面を確認し、不明な点は提供元へ問い合わせます。無料か有料かという区別だけで安全性を決めないことも必要です。

社内資料の検索や自動実行では、見せる範囲を広げすぎない

社内資料を検索して回答するAIでは、その社員が本来読めない資料を回答の根拠に使わせない設計が必要です。共有フォルダをつなぐと便利だからと、全社の資料をまとめて参照可能にすると、人事情報や顧客別の条件まで回答へ含まれるおそれがあります。利用者ごとの権限が検索と回答へ反映されるかを、実際の利用者権限で検証します。

AIにメール送信やデータ更新を任せる場合は、読む権限と変更する権限も分けます。外部のWebページやファイルに含まれる指示に影響され、意図しない出力・操作へ誘導される問題は「プロンプトインジェクション」と呼ばれます。OWASPは、必要最小限の権限や重要操作の人による承認を対策として挙げています。AIへの注意書きだけで防げると考えず、システム側でも操作範囲を制限します。出典：OWASP「LLM01:2025 Prompt Injection」。

また、情報が漏れなくても、誤った数字や別の顧客情報を含む回答をそのまま送れば、業務上の損害につながります。情報保護と出力品質は別の問題ですが、実務では両方を確認します。社外へ出す文書は、内容の根拠と宛先を確認できる人が承認する形から始めるのが現実的です。

入力してよい情報は、業務上の必要性と契約条件で分ける

情報を分類するときは、「社内資料だから全部だめ」「社名を消したから大丈夫」と単純化しないことが大切です。何のためにその情報が必要なのかを先に考え、不要な部分を減らしたうえで、利用環境に合うかを判断します。顧客との約束や社内規程で外部提供が制限されている情報は、その条件も確認します。

表は一律の利用許可を示すものではありません。たとえば、公開資料にも著作権や利用条件があり、個人情報を扱う場合には利用目的や必要な手続きを含めた確認が必要です。法的な判断が必要な案件は、社内の法務担当者や専門家と確認します。

名前を記号に置き換えても、取引日、地域、案件内容などを組み合わせれば相手を特定できる場合があります。単に氏名を削除した処理を、完全な匿名化とみなさないようにします。目的が文章の構成を考えることなら、実在の顧客データを使わず、仮の条件で試す方法もあります。

取引先との契約も、AI利用の条件になる

AI提供元の規約だけでなく、取引先から預かった情報を自社がどう扱ってよいかも確認します。たとえば、外部サービスへの送信が契約上制限されている資料なら、AI側の学習利用を止める設定だけでは、その制限を解消できません。利用方法を変えるか、契約内容の見直しや取引先との協議・交渉が必要かを検討します。

契約の変更を前提に進めるのではなく、対象情報、利用目的、送信先、管理方法を説明できる状態にし、必要な合意を得るまでは既存の条件に従います。法的な解釈や契約条項は、法務担当者や顧問弁護士などへ確認します。AI提供元との契約を検討する際には、データの利用範囲などを整理した経済産業省の「AIの利用・開発に関する契約チェックリスト」も参考になります。

会社の利用方針とAIの設定を照らし合わせ、必要な変更を行う

会社として、何の業務にAIを使い、どの情報をどの条件で扱うかを決めたら、利用環境がその方針に合うかを確認します。新しいサービスの選定だけでなく、すでに社員が使っている環境も対象です。LLM（文章の理解や生成を担う大規模言語モデル）を利用するサービスについて、契約するプランの条件と実際の管理画面を照合します。

• 入力情報の学習利用、保存期間、削除方法、提供元や委託先での取り扱い
• アカウント管理、多要素認証、共有範囲、利用記録を確認できる機能
• 接続するストレージや業務システムの権限と、送信・更新を許可する範囲
• 契約終了・退職・異動時のアクセス停止と、データの回収・削除方法

会社の方針とずれている設定は、必要に応じて更新し、変更後の動作も確かめます。管理者が一元的に変えられる範囲と、利用者ごとに対応が必要な範囲を分け、誰が何を確認・変更したかを記録します。設定では満たせない条件があれば、入力する情報や使う環境を見直します。設定を変えれば、どんな用途でも安全になるという意味ではありません。

自社専用システムを作る場合も同じです。画面が自社専用でも、処理の途中で外部AIや別のサービスへ情報を送る構成なら、その送信先と保存条件を確認します。外部へ送らない構成にも、権限管理、更新、障害対応などの運用は必要です。自社開発か既製サービスかだけで安全性や安さを決めることはできません。

中小企業では、禁止事項だけでなく使える道筋を用意する

専任の情報システム部門やセキュリティ担当者を置ける大企業と、総務や業務責任者が兼務する中小企業では、続けられる運用が違います。大企業と同じ審査書類をそろえることを目標にすると、確認する人が足りず、利用判断だけが止まる場合があります。ただし、会社が小さいことを理由に、顧客情報や機密情報の確認を省いてよいわけではありません。

会社の方針や管理体制に合わせ、初期運用では業務と環境を限定する方法があります。たとえば「公開済みのサービス資料から案内文の下書きを作る」と定めれば、必要な情報と確認点を絞れます。逆に「常識の範囲で使う」といった説明では、社員ごとの判断がばらつきます。何に使ってよいかを具体化し、困ったときの相談先も決めます。

ルールを作った後は、利用の承認、設定変更、定期的な確認を誰が担うかまで決めます。少人数の会社では兼務でも構いませんが、判断できる範囲と経営者へ相談する条件を明確にします。新しい機能や連携先を追加するとき、担当者が替わるときにも、設定とルールが会社の方針に合っているかを見直せる体制が必要です。

未承認のAI利用が見つかった場合も、注意だけで終わらせず、何を解決したくて使っていたかを聞きます。会社が認めた手段では仕事が進まない、相談しても判断が返ってこないなど、業務の仕組みに原因があるかもしれません。禁止すべき行為を明確にしつつ、必要な仕事を進められる代替手段を用意することが、運用を実態に近づけます。

IPAの中核人材育成プログラムの成果物でも、未承認のAI利用への対応や、企画から運用までのリスク評価が整理されています。規程の有無だけでなく、どの場面で誰が対策を実行するかを考える際の参考になります。参考：「セキュリティ担当者のための生成AIセキュリティ」。

本格導入の前に、権限と失敗時の動きを試す

導入前の検証では、便利に使えた場面だけでなく、使わせてはいけない情報や操作が制限されるかも確認します。実際の機密情報を試しに漏らすのではなく、検証用の資料やアカウントを使って動きを確かめます。提供元の説明と、自社の設定で実現できている状態を照合することが目的です。

• 権限のない部署の資料が、検索結果や回答へ含まれないか
• 顧客向けの送信や重要データの更新が、必要な承認なしに実行されないか
• 利用者の異動・退職や連携解除の後に、アクセス権限が残らないか

少人数で試す場合も、試用アカウントに全社管理者の権限を与えて検証を終えないようにします。本番で使う一般社員の権限で試し、できる操作とできない操作を確かめます。判断できないことがあったときに、AIや利用者が誰へ引き継ぐかも確認しておくと、運用開始後の混乱を減らせます。

効果は作業時間だけで見ません。AIが下書きを速く作れても、機密情報の混入確認に以前より時間がかかれば、仕事全体の負担は減っていない可能性があります。確認に要した時間、修正件数、利用範囲から外れた依頼の発生状況も合わせて見ます。安全性を無視して速度だけを求めず、確認を含めて続けられるかを判断します。

誤入力や漏えいの疑いがあるときに、すぐ動ける状態にする

事故への備えは、問題が起きた後に考えるのでは間に合いません。社員が機密情報を誤って入力した場合に、責められることを恐れて報告が遅れないよう、連絡先と最初の対応を決めておきます。実際の対応は情報の種類や契約、被害の状況によって変わるため、担当責任者が状況を確認して判断します。

• いつ、どのサービス・アカウントへ、何を入力・共有したかを記録して報告する
• 担当者の指示のもとで、共有や連携など必要な利用範囲を止め、確認に必要な記録を保全する
• 提供元や必要な専門家と、削除の可否、影響範囲、通知・報告の要否を確認する

画面の会話を削除しただけで、関係する保存先から完全に消えたとは限りません。逆に、状況を把握する前に記録をすべて消すと、何が起きたかを確認しにくくなります。必要な記録を確保しながら、情報の拡散を止める対応を進めます。法令上の報告や顧客への通知が必要かは、該当する情報と状況に応じて確認してください。

同じ誤入力が繰り返されるなら、注意喚起を増やすだけでなく、入力画面や手順、相談への応答を見直します。ルールを守れない原因が、個人の知識だけでなく仕事の進め方にないかを確かめます。AIを使う場所が増えたときや契約・担当者が変わったときにも、前提条件を更新します。

会社方針から設定・契約・運用まで整える、アスタの支援

株式会社アスタは、従業員10〜200名規模の中小企業に特化し、全国でAI導入・活用を支援しています。特定のAIツール導入を前提にせず、経営課題と現場業務の整理から、設定・試行・運用改善・定着まで実務に伴走します。

アスタには、生成AIで何を許可し、何を禁止すべきかという相談がよく寄せられます。私たちは、禁止事項を一概に決めることはできないと考えています。まず実際の業務と守るべき情報を確かめ、会社としての方針を整理します。そのうえでLLMを利用するサービスの設定を確認し、必要な更新と利用ルールの作成を進めます。

ここで重視するのは、ルールを作ることと、そのルールに沿った状態を管理し続けることは別だという点です。誰が利用を承認し、設定を変更し、問題が起きたときに判断するかまで整えます。社内の設定だけでなく、取引先との契約内容の見直しや交渉が必要な場合もあるため、その観点も含めて利用条件を整理します。契約の法的判断や専門的なセキュリティ監査は、必要な専門家と確認する領域として切り分けます。

たとえば、必要以上に多い情報を毎回貼り付けているなら、注意を増やすだけでなく、必要な項目だけを入力できる手順や画面を考えます。既存サービスの設定変更・連携と自社専用システムを比較し、権限や情報の流れ、保守を含めて選びます。技術の設定と組織の動きを一緒に整え、現場が判断に迷ったまま使い続ける状態を減らすことが、アスタの実務伴走です。

まずは、社内で使いたい一つの業務について、入力する情報と出力の共有先を書き出してみてください。どこが不安で、何がまだ確認できていないかが見えると、次に調べる条件を絞れます。具体的な運用づくりは、アスタの中小企業AI業務改善でご相談いただけます。