なぜ「AIに渡す情報」の管理が必要なのか

ChatGPT、Claude、Gemini といった生成AIを、見積書の作成、議事録のまとめ、顧客への返信文の下書きに使う。こうした使い方は、すでに多くの中小企業に広がりつつあります。便利さは確かなものです。

一方で、AIを業務に取り入れる際に見落とされがちな問いがあります。「自社のどの情報を、AIに渡してよいのか」という問いです。社員名簿、顧客リスト、見積もりの原価、取引先から預かった資料。日々の業務でAIに頼みごとをするとき、私たちは何気なくこうした情報を入力欄に貼り付けています。しかし、その情報がどこへ行き、どのように扱われるのかを、立ち止まって考える機会は多くありません。

本記事では、AIを安全に業務へ取り入れるための土台として、「渡す情報をどう分類し、誰がどこまで触れてよいか（権限）をどう設計するか」を整理します。不安を煽るためではなく、最初の一歩を踏み出すための地図として読んでいただければと思います。

入力した情報はどこへ行くのか（学習利用・保持・外部送信）

生成AIに何かを入力すると、そのテキストは利用しているサービスのサーバーへ送られて処理されます。このとき、入力した内容がどう扱われるかは、使うサービスやプラン、契約によって異なります。

ここで知っておきたいのが「学習利用」という考え方です。学習利用とは、入力した内容がAIの性能を高めるための学習（トレーニング）に使われることを指します。一般的な傾向として、消費者向け（個人向け）のプランでは入力内容が学習に使われる設定が初期状態になっている場合があり、法人向けプランやAPIでは契約上、初期状態では学習に使用しないという構図が、主要なベンダーで見られます。

ただし、この扱いはベンダーやプランごとに異なり、仕様そのものも変わりうるものです。「このプランなら学習されない」と思い込むのではなく、後述する観点で各社の最新の公式情報を確認する姿勢が大切です。

学習利用のほかにも、入力・出力のデータがどれくらいの期間サーバーに保持されるか（保持期間）、データがどの国・地域で保存・処理されるか、といった点が、情報の扱いを左右します。

クラウド／海外サーバーという見えない前提（データ越境）

多くの生成AIサービスは、クラウド上で動いています。手元のパソコンの中だけで処理が完結しているわけではなく、入力した情報はネットワークを通じて外部のサーバーへ届きます。そして、そのサーバーが日本国内にあるとは限りません。

個人情報を扱う場合、この「保存先がどこか」は確認しておきたい項目の一つです。データがどの国・地域で保存・処理されるかは、サービスの選定や見直しの際に確認する観点になります。

ただし、「保存先が海外だから、ただちに本人の同意が必要になる」と単純に結びつけて考えるのは適切ではありません。個人情報保護法は、個人データを外国にある第三者へ提供する場合について、一定のルールを定めています。もっとも、海外のサーバーで処理されるサービスを使うことが、こうしたルールの対象となるかどうかは、サービス提供者が個人データをどのように取り扱うか（自社のための委託にあたるのか、第三者への提供にあたるのか、など）、契約の内容、利用の目的や形態によって異なります。保存・処理の地域は確認項目の一つと位置づけたうえで、自社のケースで法令上の論点が生じるかどうかは、個別に確認することが大切です。判断に迷う場合は、利用するサービスの公式情報や契約内容を確認し、必要に応じて専門家に相談するのが確実です。

なお、本記事は「自社が能動的にAIへ渡す情報」をどう管理するかに焦点を当てています。外部の資料やWebページ、メール、PDFを「AIに読ませること自体」に潜むリスク（プロンプトインジェクションなどの攻撃面）は、性質の異なるテーマのため、別の関連記事で扱います（本記事末尾の関連記事を参照）。

一般的なクラウド型の生成AIにおいては、AIへ情報を入力するということは、「自社の外へ情報を一度出す」ことに近い行為です（ローカルで処理が完結するものや、閉域・専用の環境で動かすものは、この限りではありません）。だからこそ、何を渡してよいかを事前に決めておくことが、安全に使うための出発点になります。

まず情報を分類する（中小企業でも回せる粒度）

「何を渡してよいか」を一件ずつ判断していては、現場は回りません。そこで役立つのが、情報をあらかじめ大まかに分類しておく考え方です。

情報資産を重要度や機密性に応じて分類し、それに見合った取り扱いをする――これは情報セキュリティの基本的な考え方として、公的なガイドラインでも示されています。IPA（独立行政法人 情報処理推進機構）の「組織における内部不正防止ガイドライン」は、情報の機密性に応じた分類と、分類に応じたアクセス権の管理を基本に据えています。また、IPAの「中小企業の情報セキュリティ対策ガイドライン」は、中小企業の実情に即した段階的な情報資産管理を前提としています。

とはいえ、中小企業が大企業並みの細かい分類を運用するのは現実的ではありません。そこで役立つのが、「機密度の3段階」と「注意ラベル」という二つの軸で考える方法です。難しく見えますが、やることは「まず大まかな段階に分け、特別な注意が要る情報には目印（ラベル）を重ねる」だけです。

二つの軸で考える：機密度の3段階＋注意ラベル

情報を整理するときは、性質の異なる二つの軸を分けて考えると、迷いにくくなります。

軸1：機密度の3段階（どれくらい外に出してはいけないか）

  • 公開可：すでに公開している、または公開してよい情報（会社案内、公開済みの製品情報など）
  • 社内限：社外には出さないが、社内では通常やりとりする業務情報
  • 機密：漏えいすると事業に重大な影響が出る情報（重要な経営情報、漏れては困る取引条件など）

まずは、すべての情報をこの3段階のどれかに当てはめます。これが「土台」となる区分です。

軸2：注意ラベル（法律や契約の面で、特別な取り扱いが必要か）

機密度の3段階とは別に、次のような情報には「注意ラベル」を重ねて付けます。

  • 個人情報・要配慮：法令上の取り扱い義務がある情報（顧客や従業員の個人情報など）
  • 顧客・NDA：顧客から預かった情報や、秘密保持契約（NDA）の対象となっている情報
  • 営業秘密：自社の営業秘密にあたる情報（後述の三要件を満たすもの）
  • 認証情報：パスワード、APIキー、トークンなど

ここで大切なのは、注意ラベルは機密度の区分と「どちらか一方」ではなく、重ねて付くものだという点です。たとえば、顧客の連絡先リストは「社内限」（機密度）であると同時に「個人情報・要配慮」（注意ラベル）でもあります。取引先から預かった図面なら「機密」であり、かつ「顧客・NDA」のラベルが付くこともあります。一つの情報に複数のラベルが同時に付くのは、ごく普通のことです。

「これは公開可？　機密？」と機密度を決めたうえで、「個人情報は含まれていないか」「預かりものではないか」「認証情報ではないか」と注意ラベルを重ねて確認する。この二段構えにすると、『機密度は低いが法律上の注意は要る情報』（たとえば、社外秘ではない問い合わせ対応記録に個人情報が含まれる場合）を見落としにくくなります。

この考え方はあくまで出発点です。自社の業務に合わせて言葉や粒度を調整して構いません。大切なのは、社員が「これはどの機密度で、どの注意ラベルが付くか」を迷わず判断でき、それに応じて「AIに渡してよいか」の方針を持てることです。

用語の整理

  • 営業秘密（不正競争防止法）：①秘密として管理されていること（秘密管理性）、②事業活動に有用であること（有用性）、③公然と知られていないこと（非公知性）の三つの要件をすべて満たす情報を指します。
  • 個人情報（個人情報保護法）：生存する個人に関する情報であって、氏名などにより特定の個人を識別できるものを指します。
  • 要配慮個人情報（個人情報保護法）：人種、信条、病歴、犯罪の経歴など、取り扱いにとくに配慮を要する情報を指し、取得には原則として本人の同意が必要とされています。

AIに渡してよい情報／渡してはいけない情報の線引き

情報を分類できたら、次は「AIに渡す前に立ち止まるべき情報」を見分ける線引きです。すべてを禁止すればAIの利便性は失われますが、無制限に渡せば思わぬリスクを抱えます。とくに、前章で挙げた注意ラベルが付く次の4類型は、入力する前に「このツール・このプランで本当に渡してよいか」を確認したいものです。

渡す前に立ち止まりたい4類型（注意ラベルが付く情報）

一つ目は、個人情報です。顧客名簿や従業員情報などをAIに入力する場合、個人情報保護法上の論点が生じうるため、利用目的の範囲、本人の同意、第三者提供といった観点を確認する必要があります。「個人情報を入力したら違法」と一律に決まるわけではありませんが、扱い方によっては法令上の論点が生じうる、という認識を持つことが出発点です。

二つ目は、顧客から預かった情報や取引先の機密です。秘密保持契約（NDA）を結んでいる情報をAIに入力すると、契約違反となるリスクがあります。自社の情報でなくても、預かっている以上は慎重な扱いが求められます。

三つ目は、営業秘密です。営業秘密として保護されるには、前述の三要件、とくに「秘密として管理されている」という秘密管理性が問われます。社外のサービスへ不用意に入力することで、この秘密管理性が損なわれ、営業秘密としての保護を失うリスクが議論されています。

四つ目は、認証情報です。パスワード、APIキー、各種のトークンといった認証情報は、入力すること自体が漏えいの経路になりうるため、AIの入力欄には入れないことを原則とします。

個人情報・要配慮個人情報・営業秘密・認証情報は、入力する前に必ず立ち止まってください。「このツール・このプランで、この情報を本当に渡してよいか」を確認する一手間が、後の大きなトラブルを防ぎます。判断に迷う情報は、まず渡さないという選択も有効です。

「誰がどこまで触れてよいか」を決める権限設計

何を渡すかと同じくらい重要なのが、「誰が」AIを使い、「どこまで」触れてよいかという権限の設計です。同じツールでも、全員が何でもできる状態と、役割に応じて範囲を決めた状態とでは、リスクの大きさが変わります。

アカウント分離と最小権限

情報セキュリティの基本的な考え方に「最小権限」があります。総務省の「国民のためのサイバーセキュリティサイト」は、すべての利用者にすべての権限を与えるのではなく、必要最低限の利用者にのみ必要最低限のアクセスを許可することを推奨しています。これはAIの利用にもそのまま当てはまります。

AIの文脈に具体化すると、次のような考え方になります。

  • 個人アカウントの業務利用をできるだけ避け、組織で管理されたアカウントや法人向けプランに集約する。これにより、管理者機能やログといった統制の手段が使えるようになります。ただし、法人向けプランにすれば自動的に安全になるわけではありません。管理者機能・学習利用の設定・保持期間・ログ・保存先リージョンといった項目を実際に確認し、設定して初めて統制として機能します。
  • 情報の機密区分や注意ラベルに応じて、「誰がどのツールに何を入力してよいか」を役割で分けます。たとえば、機密区分の情報や個人情報を扱えるのは特定の担当者に限る、といった整理です。
  • 人事異動、退職、入社など人員構成が変わったときには、その都度アクセス権を見直し、定期的にアクセス権の棚卸しを行います。

自社版の「権限の対応表」をつくる

ここまでの考え方を、一枚の表に落とすと、現場で使えるものになります。次の表は、前章で整理した「機密度の3段階」と「注意ラベル」を、利用環境・利用者・前処理や承認・記録と対応づけたひな型です。

情報区分・注意ラベル利用可能な環境利用者前処理・承認記録
公開可承認済みのAIツール一般の利用者原則不要必要に応じて
社内限組織で管理された環境業務担当者固有名詞の削除など利用履歴を残す
機密／顧客・NDA／個人情報個別に確認した環境のみ指定された担当者匿名化・上長などの承認記録を必須にする
認証情報入力禁止なし例外なし万一入力した場合はインシデントとして記録

匿名化や承認は、入力を許可する「免罪符」ではありません。NDA・契約・法令・社内ルールが優先します。これらで禁じられている情報は、前処理や承認の有無にかかわらず入力しないことが大前提です。前処理・承認は「渡してよいと確認できた情報を、より安全に扱うための手順」と位置づけてください。

これは「厳密な正解表」ではなく、自社版を作るためのひな型として捉えてください。業種や体制によって、適切な利用環境や承認のしかたは変わります。自社の実情に合わせて、列の中身を書き換えていくことが目的です。なお、この表は「設計の考え方」を一枚に整理したものであり、組織全体のルールとして文書化し、運用の制度に落とし込む段階については、別の関連記事（社内でAIを使うためのルールの作り方）に譲ります。

共有設定・ログ・監査の考え方

生成AIには、チャット履歴を共有したり、会話を公開リンクとして発行したりできる機能があるものがあります。便利な反面、意図しない共有が情報の流出につながることもあります。たとえば、社内で共有するつもりで発行したリンクが、設定によってはURLを知っている第三者が閲覧できる状態になっている場合があります。利用するツールの共有設定を確認し、機密性の高い内容が意図せず外部から見える状態になっていないかを点検しておきましょう。とくに、外部の協力会社や退職者とのやりとりで使ったチャットや、テスト目的で一時的に発行したリンクは、用が済んだら共有を解除する習慣をつけておくと安心です。

あわせて、誰がいつ何を入力・出力したかを後から確認できる体制（ログ・監査）も、できる範囲で整えておきたい要素です。万一のときに事実を確認できることは、原因の特定と再発防止の土台になります。記録を残し、必要に応じて確認できるようにしておくことは、内部不正の防止という観点でも重要とされています。

ログ・監査というと大がかりな仕組みを思い浮かべるかもしれませんが、中小企業では、まず「組織で管理されたアカウントや法人向けプランに集約する」ことが出発点になります。法人向けプランの管理者機能には、利用状況を把握できる仕組みが備わっていることがあり、個人アカウントの寄せ集めでは得られない統制が利くようになるためです。どこまでの記録を、どれくらいの期間残せるかは、ツールやプランによって異なります。導入や見直しのタイミングで、後述する「ツール選定時に確認すべき仕様」の管理者機能の観点とあわせて、自社で確認できる範囲を把握しておくとよいでしょう。

権限設計は「人を疑うため」のものではありません。誰がどこまで触れてよいかを明確にすることは、現場の社員が「これは自分が判断してよい範囲だ」と安心して動けるようにすることでもあります。

ツール選定時に確認すべき仕様

AIツールを選ぶとき、機能や使いやすさに目が向きがちですが、情報管理の観点では「データの扱い」に関する仕様こそ確認したいポイントです。同じ生成AIでも、提供元やプランによって扱いが異なります。だからこそ、特定の製品が「より安全」と決めつけるのではなく、次の観点で各社の公式情報を比較・確認することをおすすめします。

ツール選定で確認したい5つの観点

  • 学習利用（オプトアウト）：入力したデータがAIの学習に使われるか。法人向けプランやAPIでは初期状態で学習に使われない設定になっているか。学習利用をやめる設定（オプトアウト）があるか
  • 保持期間：入力・出力のデータがどれくらいの期間、保持・保存されるか
  • 保存先リージョン：データがどの国・地域で保存・処理されるか（データ越境の観点）
  • 管理者機能：組織で一元管理できるか。権限の管理やログの取得ができるか
  • 契約上の取り扱い：法人契約における秘密保持やデータ取り扱いの条項はどうなっているか

いずれも、各社の公式のデータ利用ポリシー、管理者向けドキュメント、利用規約・契約書で確認できます。網羅的な確認項目をお探しの方は、別途の関連記事（AI導入前のセキュリティ確認をまとめたチェックリスト）もあわせてご覧ください。

参考までに、本記事執筆時点（2026年6月）の各社公式情報では、たとえば次のような扱いが示されています。ただし、仕様は変わりうるため、必ず各社の最新の公式情報をご確認ください。

  • 法人向けのプランやAPIでは、入力・出力を初期状態ではモデルの学習に使用しない、とする提供元が見られます。一方、個人向けプランでは学習利用が初期状態で有効になっており、手動でオプトアウトする必要がある場合があります。
  • データの保持期間や、エンタープライズ向けデータを人間がレビューしないといった扱いについても、各社が公式に記述している場合があります。

これらは各社・各プランで異なり、随時更新されます。本記事の記述をもって判断するのではなく、導入を検討するタイミングで、必ず提供元の公式ページで最新の内容を確認してください。

中小企業が最初に踏む現実的なステップ

ここまで読んで、「やるべきことが多そうだ」と感じた方もいるかもしれません。しかし、最初から完璧な体制を目指す必要はありません。IPAの中小企業向けガイドラインも、実情に即した段階的な対策を前提としています。大切なのは、全部をいちどにやろうとせず、小さく始めて運用しながら育てることです。

現実的な第一歩として、次の順序をおすすめします。

  1. 「絶対にAIに入れない情報」をまず決める

    認証情報、要配慮個人情報、営業秘密の核となる情報など、入力を禁止するものを明確にし、全社に周知します。線引きは少数から始めて構いません。たとえば「パスワードやAPIキーは入力しない」「採用・人事評価・健康に関する情報は入力しない」といった、迷う余地の少ないものから決めると、現場に浸透しやすくなります。

  2. 業務利用を法人向け・組織管理のアカウントに寄せる

    個人アカウントでの「野良利用」を減らし、管理者機能やログが使える状態に近づけます。すでに個人アカウントでの利用が広がっている場合は、まず「誰が、どのツールを、どんな業務で使っているか」を把握するところから始めると、移行の見取り図が描きやすくなります。

  3. ツールを選ぶときは公式情報で確認する習慣をつける

    前章の5つの観点を、導入や見直しのたびに公式ページで確認します。新しいツールを試すときも、無料だから・話題だからではなく、「データがどう扱われるか」を一度確認してから業務データを入れる、という順序を習慣にします。

  4. 簡単な情報分類（機密度3段階＋注意ラベル）と役割を決める

    「誰が何を入れてよいか」をおおまかに整理します。最初から精緻な台帳を作る必要はなく、「この区分の情報はこのツールまで」という大まかな対応づけ（前述の「権限の対応表」のひな型が出発点になります）から始めて構いません。

  5. 運用しながらルールを育てる

    最初から完璧を目指さず、現場の声をもとに少しずつ調整していきます。「判断に迷った事例」を持ち寄って線引きを見直す場を、月に一度でも設けておくと、ルールが実態に合ったものになっていきます。

組織全体のルールとして文書化し、運用の制度に落とし込む段階に進みたい方は、別途の関連記事（社内でAIを使うためのルールの作り方）が参考になります。本記事で整理した「情報の分類」と「権限の設計」は、そのルールづくりの前提となる土台です。

安全なAI活用は、一度の大がかりな取り組みで完成するものではありません。「入れない情報を決める」「使うアカウントを整える」という小さな一歩から始め、運用しながら自社に合った形へ育てていく――この姿勢が、無理なく続けられる土台になります。

引用元・参考文献

日本の公的機関

AIベンダー（公式）