生成AIへの情報入力基準：社内データ分類フレームワークの整備方法

社内での生成AI活用が広がるにつれ、「AIに何を入力してよいか」を定めた社内基準が整備されていない企業で、情報漏洩リスクや社員の判断ブレが表面化しています。本記事では、情シス担当者が即日使えるデータ分類テーブルと社員向けの判断フローを整理します。

この記事を読んだほうが良い人

• ChatGPT / Claude / Gemini 等の生成AIツールを社内展開しており、情報入力範囲のルール整備を進めている情シス担当者
• ISMS（情報セキュリティマネジメントシステム）またはプライバシーマークを取得済みで、既存のデータ分類基準をAI対応に更新したい担当者
• 「この資料をAIに貼っていいですか？」という社員からの確認が増えており、判断基準を一本化したい人

社内の生成AI情報入力基準が整備されていない場合のリスク

生成AIサービスを利用するとき、入力したプロンプトや添付データがどのように扱われるかはサービスおよびプランによって異なります。API経由の利用やエンタープライズ契約では入力データが学習に使われないことを明示しているサービスが多い一方、無料・個人向けプランでは設定を変更しない限り学習対象になるものもあります。詳細は各サービスの利用規約とデータ処理ポリシーで確認が必要です。

基準がないまま社内展開を進めると、次のような問題が起きます。

• 社員が取引先の個人情報を含む文書をそのままAIサービスに貼り付ける
• 未公開の製品ロードマップや価格交渉の経緯がプロンプトに含まれる
• 情報の重要度を個人の感覚で判断し、社員間で基準がばらつく
• 問題が発覚した後に事後対応になり、損害が拡大する

特に見落としがちなのが、複数の低リスク情報を組み合わせた際のリスク上昇です。氏名だけなら社内公開情報であっても、氏名・役職・メールアドレス・電話番号を一覧表にまとめると個人情報保護法の対象となる個人情報リストになります。「一件一件は問題なさそう」という感覚的な判断が、実際には要注意な組み合わせになっている点は、ルールを整備する際に明示しておくべきポイントです。

「AIの利用を禁止する」だけでは業務効率化の恩恵を失います。「何を渡してよいか」を定義してから展開する順番が重要です。

データ分類テーブル：AIガイドラインの土台となる4段階基準

情報の機密性に応じた4段階の分類テーブルを設計します。以下の分類はISMS・プライバシーマーク取得企業の情報資産台帳と整合する構成を意識しています。

分類ラベル	定義	AIへの入力可否	該当する情報の例
公開可	すでに外部公開されている情報	◎ 可	自社プレスリリース、公式サイトのコンテンツ、公開版製品マニュアル
社内限定	社員全体が参照可能な社内情報	△ 条件付き可	社内FAQ、業務手順書、機密事項を含まない議事録、社内報
機密	限定された関係者のみが扱う情報	× 原則NG	契約書、財務データ、未公開の事業計画、M&A関連資料
要個別判断	個人情報・顧客情報・取引先の非公開情報	⚠ 事前確認必須	氏名・メールアドレス・電話番号、顧客リスト、人事評価・給与情報

「社内限定」が「条件付き可」になる理由

社内情報であっても、利用するAIサービスが入力データを学習に使わないことをエンタープライズ契約やデータ処理委託契約で保証している場合は、入力可として扱えます。確認が取れていないサービスでは、社内情報も機密情報に準ずる慎重な扱いが必要です。

この条件確認は、情シスが社内許可するAIサービスリストを作成する際に一括で実施しておくと、社員が個別に判断する手間を省けます。「このサービスはエンタープライズ契約済みのため社内情報まで入力可」「このサービスは学習利用の確認が取れていないため公開情報のみ」という形でリスト化するのが実用的です。

「機密」指定の対象を事前に明文化する

機密分類で運用上の曖昧さが最も出やすいのは、「誰が機密指定をするのか」という点です。役員承認を要する案件情報は機密ですが、部長が作成した提案書が機密か否かは組織によって異なります。情報資産台帳に「機密指定者・承認ルート」を記載しておくと、現場の境界線が明確になります。

「要個別判断」の取り扱いを定型化する

個人情報・顧客情報は「要個別判断」とし、都度確認を求める運用が現実的です。ただし確認の手続きが重すぎると、社員が申請をスキップして「バレなければいい」という行動を取るリスクが生まれます。

実際の運用では、次のような簡易フォームを社内ポータルに用意することで、申請コストを下げながらトレーサビリティを確保できます。

• 入力する情報の概要（例：顧客A社との打ち合わせ議事録の一部）
• 入力する目的（例：議事録の日本語要約）
• 使用するAIサービス名とプラン（例：ChatGPT Enterprise）
• 申請者の氏名・部署

申請後は情シスが2営業日以内に承認・否認を返答するルールにすると、社員側の待ち時間が明確になり、判断のスキップを防ぎやすくなります。

社員向け判断フロー：その情報をAIに渡してよいか？

分類テーブルだけでは「この資料はどの分類か」と現場で迷う場面が出ます。Yes/Noで辿れる判断フローをセットで提供することで、情シスへの問い合わせを減らせます。

以下のステップを順番に確認してください。

ステップ1：外部公開済みか？

• Yes → 公開可：AIに入力してOK
• No → ステップ2へ

ステップ2：個人情報・取引先の非公開情報が含まれるか？

• Yes → 要個別判断：情シスまたは法務に確認してから使用
• No → ステップ3へ

ステップ3：社外秘・機密指定されているか、または限定メンバーのみが知る情報か？

• Yes → 機密：AIへの入力NG（承認された社内専用AIのみ可）
• No → ステップ4へ

ステップ4：社員全体がアクセスできる社内情報か？

• Yes → 社内限定：使用するAIサービスのデータ処理ポリシーが確認済みなら入力可。未確認なら情シスに相談
• No → 情シスに相談（社外に出てはいないが社内でもアクセス制限がない部門資料など、判断が難しい情報はここへ）

このフローはA4 1枚に収まる構成で、社内ポータルや情報セキュリティポリシーの別紙として配布する形が実用的です。

判断に迷う「グレーゾーン」への対処

フローで判断できないグレーゾーンは必ず出ます。たとえば「社外に出たことはないが機密指定もされていない部門別の売上データ」は、上記フローでは"社内限定"に当たりますが、内容によっては経営情報の一部として扱うべきケースもあります。

こうしたグレーゾーンは「迷ったら申請」というルールを明文化して、判断を情シスまたは法務に委ねる経路を設けることが重要です。「エスカレーション先が明確である」こと自体が、社員に安心感を与えます。フロー図に「判断に迷ったら → 情シスへ（○○申請フォーム）」という出口を明示してください。

よくある誤入力パターン：生成AI機密情報リスクの実例5ケース

ルールを整備した後でも、以下のようなケースは起きやすいパターンです。社員向けの周知と合わせて具体例として示しておくと、認識の定着に役立ちます。

ケース1：顧客対応メールをそのまま貼り付ける

メールの文章をAIに校正させる際、顧客の氏名・メールアドレス・電話番号が本文に含まれたまま貼り付けてしまうケース。個人情報保護法の観点から、個人を特定できる情報の第三者提供に該当する可能性があります。個人情報は仮名化・匿名化してから入力するルールを明示することが有効です。具体的には、氏名を「Aさん」、メールアドレスを「×××@example.com」に置き換えてから入力する手順を社内標準として案内しておくと、リスクを大幅に下げられます。

ケース2：契約書・見積書を翻訳・校正させる

取引先との契約書や社外秘の提案書をAIで翻訳・校正するケース。守秘義務条項がある情報をサービス提供者に渡すことが契約違反になる可能性があります。利用可能な範囲は、法務と連携して事前に明確化しておくことが必要です。なお、社内専用の閉域AIを整備している場合は、そちらを利用するルーティングを設けることで、機密文書の翻訳ニーズにも対応できます。

ケース3：議事録の機密度を誤認識する

「社内の会議資料なら大丈夫」と判断した議事録に、未公開の経営方針やM&A関連の検討事項が含まれていたケース。議事録は参加者が限定されている場合でも機密情報に該当するものが多いため、作成時点で分類ラベルを付ける運用が有効です。ファイル名に分類を明記する（例：[社内限定]_○○定例_20260615.docx）だけでも、作成者本人の意識づけになります。

ケース4：人事評価・採用候補者の情報を入力する

面談フィードバックや給与テーブル、採用候補者のプロフィールをAIで整形・要約させるケース。こうした情報は個人情報かつ機密情報の双方に該当します。HRツールやATS（Applicant Tracking System：採用管理システム）のAI機能を使う場合でも、外部AIサービスへの入力は禁止とし、情シスが承認した環境のみで扱うルールを設けることが必要です。

ケース5：複数の低リスク情報を組み合わせてリスト化する

氏名だけ、役職だけでは問題がなくても、会社名・氏名・部署・連絡先を一覧表にして入力すると個人情報リストとして扱われます。情報の組み合わせによってリスク分類が変わる点は判断フローでは表現しにくいため、「複数件の個人情報を組み合わせたリストは要個別判断」と社内ガイドラインに明記することを推奨します。

ルール整備から運用定着まで：情シスが次に取り組むこと

分類テーブルと判断フローを作成したら、次は定着化と見直しの仕組みを整えます。

1. 社内へのアクセスポイントを確保する

作成した基準を社員が参照できる場所に掲載します。情シスのみが把握しているドキュメントでは機能しないため、社内ポータル・情報セキュリティポリシー・社員ハンドブックのいずれかに組み込んでください。入社時の情報セキュリティ研修の必修コンテンツに追加するだけでも、新入社員への展開コストを下げられます。

2. 許可済みAIサービスリストと紐づける

データ分類基準は「許可済みAIサービスリスト」と一体で機能します。「このサービスはデータ学習なし（確認済み）・社内情報まで入力可」「このサービスは学習利用の確認未了・外部公開情報のみ」という形でサービスと入力可能範囲をマッピングしておくと、社員が判断する際の迷いを大幅に減らせます。

3. 年1回以上の定期見直しを計画する

生成AIサービスの利用規約とデータ処理ポリシーは頻繁に更新されます。プラン変更や利用規約改定があった際は、分類基準の「条件付き可」の前提条件を再確認してください。見直しのトリガーは「年1回（情報セキュリティ方針の定期見直しに合わせる）」と「サービスの利用規約変更の通知を受けたとき」の2本立てが実用的です。

4. 既存のISMS・プライバシーマーク管理体制に組み込む

既存の情報資産台帳や情報セキュリティポリシーと乖離した基準を別個に作ると、監査時に矛盾が生じます。AI利用に関するセクションとして既存ポリシー文書に追記する形が現実的です。特に、ISMS認証の情報資産台帳に「AIサービスへの入力データ」を情報資産の一種として登録しておくと、リスクアセスメントの対象として正式に扱えます。

Google Workspace を利用している場合は、Gemini の管理設定や DLP（Data Loss Prevention：データ損失防止）機能と組み合わせることで、ポリシーの明文化と技術的なガードの二重構造が作れます。データ分類基準と管理コンソールの設定を並行して整備することを推奨します。

まとめ

生成AIへの情報入力基準を整備するポイントは3点です。

• データ分類テーブルで情報を4段階に定義し、AIへの入力可否を明確にする
• Yes/No形式の判断フローをセットで提供し、社員が現場で迷わない状態を作る
• よくある誤入力パターンを具体例として周知し、定着化の仕組みを同時に設計する

「AIに何を渡してよいか」という基準は、ツール選定や技術設定よりも先に決めておくべき前提条件です。ポリシーがなければ、技術的なガードをいくら強化しても人の行動は変わりません。

分類基準の整備が一段落したら、次は「許可していないAIツールの利用検知」「管理コンソールでのAI機能の制御」「DLPルールによる機密情報の入力ブロック」へと展開してください。ポリシーと技術制御が両輪で機能する体制が完成すると、情シスが個別に対応する問い合わせ件数も減っていきます。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。