生成AIを業務に入れる前のセキュリティ確認リスト

2026年5月9日

要点

生成 AI を業務に入れるとき、最初に決めることは「どの AI を使うか」だけではありません。もっと重要なのは、何を入力してよいか、誰の権限で使うか、AI が外部サービスや社内データに触れる場合にどこで止めるかです。鍵を渡す前に、どの扉を開けてよいか決める話です。

NIST は生成 AI 向けのリスク管理資料で、AI を作る組織だけでなく、AI を使う組織もリスクを管理しやすくすることを目的にしています。OpenAI も法人向けデータの扱いとして、入力・出力データの利用範囲、暗号化、保持期間の管理を説明しています。Google Security Blog は、外部文書やメールに埋め込まれた指示が AI の動きを変える「間接プロンプトインジェクション」を、継続的に備えるべき脅威として扱っています。

対象は、はじめて AI 利用ルールを作る責任者です。専門部署がなくても、最初の線引きはできます。

確認リスト

1. 入力してよい情報を決める

  • 個人情報、顧客情報、未公開の売上、契約書、給与情報を入力してよいか決めた
  • 入力禁止の情報を、現場が判断できる言葉で書いた
  • 「迷ったら入力しない」相談先を決めた

生成 AI は便利ですが、入力した内容がサービス側でどう保存・利用されるかは、契約プランや設定で変わります。OpenAI は法人向けサービスと API について、既定では入力・出力をモデル学習に使わないこと、暗号化、保持期間の管理を説明しています。ただし、これは「何を入れてもよい」という意味ではありません。

最初は「入力してよい例」よりも「入力してはいけない例」を決める方が現場で迷いにくくなります。たとえば「顧客名を伏せた問い合わせ要約は可」「契約書の原文全文は不可」「会議メモは個人名と会社名を消してから可」。実際の業務単位で書くと、現場の判断が止まりません。

2. AI が触れるデータの範囲を狭くする

  • AI ツールが社内ドライブ、メール、チャット、顧客管理システムのどこに接続するか確認した
  • 全社データではなく、必要なフォルダやプロジェクトだけを接続した
  • 退職者・異動者・外部委託先のアクセス権を見直した

Google は、間接プロンプトインジェクションを「複数のデータソースを使う複雑な AI アプリケーション」を狙う脅威として説明しています。AI がメール、文書、Web ページ、外部ツールをまとめて読めるほど、悪意ある指示を拾う入口が増えます。

対策の基本は、AI に必要以上のものを見せないことです。人間の担当者に「経理フォルダ全部を見てよい」とは言わないのと同じで、AI にも必要な範囲だけを渡します。導入初期は、小さなチーム、小さなフォルダ、限定した用途から始める方が安全です。

3. AI に任せてよい操作を分ける

  • 要約、分類、下書きなど、AI が行ってよい作業を決めた
  • 送信、削除、承認、発注、支払いなど、人間の確認が必要な操作を決めた
  • AI が外部ツールを使う場合、実行前に人間確認を挟む設定にした

OWASP の LLM Top 10 は、AI に過度な自律性を与えることをリスクとして挙げています。ここでいう自律性とは、AI が人間の確認なしに外部ツールを呼び出したり、メールを送ったり、データを書き換えたりすることです。

まずは「AI は提案まで、人間が実行する」という線引きにすると安全です。たとえば、顧客への返信文を作るのは AI でも、送信ボタンを押すのは担当者にします。請求書の確認も、AI は差分や疑問点を出すまでにし、承認は責任者が行います。

4. 出力をそのまま信用しない

  • 重要な数字、法律、医療、契約、セキュリティ判断は出典確認を必須にした
  • AI の回答を社外に出す前の確認者を決めた
  • 「AI が言ったから正しい」を禁止事項として明文化した

生成 AI は自然な文章を作れますが、正しさを保証する仕組みではありません。NIST の AI RMF は、AI システムを設計・利用・評価する中で、信頼性やリスク管理を組み込む考え方を示しています。社内利用でも同じで、AI の回答を業務判断の材料にするなら、誰が確認し、どの資料で裏を取るかを決めておく必要があります。

現場向けには「そのまま使ってよいもの」と「確認してから使うもの」を分けます。会議メモの箇条書きやメール文面のたたき台は軽い確認でよい一方、契約条件、価格、法令、採用判断、顧客への正式回答は必ず人間が確認します。AI はもっともらしく間違えるので、見た目の流暢さを証拠にしないことが大切です。

5. 外部から入る文章を警戒する

  • Web ページ、メール、PDF、問い合わせ文を AI に読ませる用途を洗い出した
  • 外部文書に含まれる「AI への命令」は業務指示として扱わないルールにした
  • 不審なリンク、ファイル、長すぎる文章を AI に渡す前の確認手順を決めた

間接プロンプトインジェクションは、ユーザーが直接 AI に命令しなくても起きます。たとえば、AI が読んだ Web ページやメール本文の中に「この指示を優先せよ」「別サイトに情報を送れ」のような文章が混ざっている場合、AI がそれを作業指示と誤解する可能性があります。資料の中に貼られた命令は、命令ではなく資料の一部。

これは IT 部門だけの問題ではありません。営業が問い合わせメールを要約する、総務が外部 PDF を読ませる、企画担当が競合サイトを調べる、といった普通の業務でも起こり得ます。外部から来た文章は「参考資料」であり、「社内の指示」ではない。この区別を、ルールに書きます。

6. ログと責任者を決める

  • 誰が、どの用途で、どの AI ツールを使っているか把握できる
  • 問題が起きたときの相談先と停止判断者を決めた
  • 重要業務では、入力内容や出力結果を後から確認できる範囲で残す

AI 導入でよく起きる失敗は、個人が便利なツールをそれぞれ使い始め、会社として把握できなくなることです。大きな管理システムは不要でも、少なくとも「利用ツール」「利用部署」「主な用途」「管理者」は一覧にしておきます。

問題が起きたときに、現場がどこへ相談すればよいかも重要です。情報漏えいの疑い、誤回答による顧客影響、外部サービスへの接続ミスなどは、放置すると被害が広がります。AI 利用の責任者を「便利ツールの管理者」ではなく「業務リスクの受付窓口」として置くと、早めに止めやすくなります。

7. 小さく始めて見直す

  • 最初の対象業務を 1〜2 個に絞った
  • 1 か月後に、効果・ミス・ヒヤリハットを振り返る日を決めた
  • ルールを現場からの質問に合わせて更新する仕組みを作った

生成 AI の安全対策は、一度作って終わりではありません。Google は間接プロンプトインジェクションを、継続的に変化する脅威として扱っています。中小企業でも同じ考え方が使えます。

最初から全社一斉に広げるより、よく使うが被害が限定的な業務から試します。たとえば「社内文書の要約」「FAQ の下書き」「営業メールのたたき台」。そこで出た質問や失敗例を使って、入力禁止情報、確認者、外部連携のルールを更新します。

よくある誤解

有名な AI サービスなら、社内ルールはいらない

サービス側の対策と、自社の使い方のルールは別物です。暗号化やデータ保持の設定があっても、社員が顧客情報を不要に入力したり、AI に過大な権限を渡したりすれば、リスクは残ります。

AI を禁止すれば安全になる

全面禁止にすると、社員が個人アカウントや未承認サービスを使う「見えない利用」が増えることがあります。安全に使える範囲を決め、相談しやすくする方が現実的です。

プロンプトを工夫すれば十分に防げる

プロンプトは役に立ちますが、それだけでは足りません。外部文書、権限、ツール連携、ログ、人間確認を組み合わせる必要があります。特に AI がメール送信やファイル操作などを行う場合は、技術設定と業務ルールの両方が必要です。

次のステップ

まず、次の 4 つを書き出してください。

  1. 入力してはいけない情報
  2. AI に使わせてよい社内データ
  3. AI に任せてよい作業と、人間確認が必要な作業
  4. 問題が起きたときの相談先

この 4 点が曖昧なままツールを増やすと、後から止めにくくなります。逆に、最初の線引きがあれば、現場は安心して試しやすくなります。

出典

CTA

まずは「入力してよい情報」と「AI に任せてよい操作」を社内で 1 枚にまとめましょう。