※本記事は2026年8月時点の情報にもとづいて執筆しています。生成AIサービスの規約や関連法制度の解釈は変化する可能性があるため、実際の運用にあたっては最新の公式情報もあわせてご確認ください。
「うちの会社では、ChatGPTに顧客リストを貼り付けて要約させている社員がいる」——情シス・総務担当者からこうした話を聞くことが増えています。多くの場合、本人に悪意はありません。「議事録をきれいにまとめたい」「見積書の文面を整えたい」という善意の効率化が、結果として顧客の個人情報や自社の営業秘密を外部のAIサービスに送信する行為になってしまっているだけです。
すでに学習オプトアウトの設定方法や、ChatGPTを許可すべきかどうかの判断基準について検討した担当者も多いと思いますが、「AIを使ってよい」と決めた後に必ず必要になるのが、「AIに何を入力してはいけないか」という具体的な線引きです。この論点は抽象的な「機密情報の取り扱いに注意する」という一文だけでは社員に伝わらず、実際に事故が起きてから気づくケースが後を絶ちません。
この記事では、社員が生成AIに機密情報をうっかり入力してしまう事故を防ぐために、どのような情報を「入力禁止」「要確認」「入力可」に分類し、どういう手順で社内ルールに落とし込めばよいかを、具体的な分類表・運用フロー・周知方法まで含めて整理します。すでに生成AI利用ガイドライン全体を策定済みの会社が、入力情報の線引きだけを深掘りする際にも、これから初めてルールを作る会社にも使える内容です。
なぜ「なんとなく注意」では防げないのか
まず押さえておきたいのは、機密情報の入力事故はルールが「無い」会社よりも、ルールが「曖昧」な会社で起きやすいという点です。「機密情報は入力しないでください」という一文だけの通知は、多くの社員にとって実質的に機能しません。
理由は単純で、社員本人が「これは機密情報にあたるのかどうか」を判断する材料を持っていないからです。顧客の会社名は機密情報なのか。社内の会議で決まった来期の方針は機密情報なのか。取引先とのメールのやり取りをAIに要約させるのは問題ないのか——こうした判断を、法務や情シスの知識がない一般社員が都度、自己判断で行うのは無理があります。
判断基準が曖昧なままだと起きる典型的なパターンは次のとおりです。
- 「効率化のため」という善意から、顧客名・取引先名を含んだ資料をそのまま貼り付けてしまう
- 「個人が特定できなければ大丈夫」という誤解のもと、社員番号や部署名付きの人事データを入力してしまう
- 社外秘の議事録やプレゼン資料を、要約や翻訳のために丸ごとアップロードしてしまう
- 開発中のシステムのソースコードやAPIキーを、デバッグ目的でチャットに貼り付けてしまう
これらはいずれも、悪意ではなく「便利だから」「早く終わらせたいから」という動機から起きます。だからこそ、社員の注意力に依存しない、具体的で判断に迷わないルール設計が必要になります。
「機密情報は入力しないこと」という抽象的な一文は、実務上ほぼ機能しない。判断基準は「情報の種類」を具体的に列挙する形で示す必要がある。
2026年8月時点で確認されている法的・制度的な論点
社内ルールを設計する前提として、機密情報のAI入力に関わる法的・制度的な論点を確認しておきます。ここで挙げる内容は、いずれも一次情報にもとづくものに絞っています。
個人情報保護法上の論点
個人情報保護委員会は、生成AIサービスの利用に関する注意喚起を公表しています。この注意喚起では、個人情報取扱事業者が生成AIサービスに個人情報を含むプロンプトを入力する場合、その入力があらかじめ特定した利用目的の達成に必要な範囲内かどうかを十分に確認する必要があるとされています。また、本人の同意を得ることなく個人データを含むプロンプトを入力し、その個人データが応答結果の出力以外の目的(AIサービス側の学習など)で取り扱われる場合には、個人情報保護法の規定に違反する可能性がある点も示されています。
つまり、「個人情報を入力すること」自体が一律に禁止されているわけではなく、次の2点の確認が求められているということです。
- その入力が、あらかじめ特定した利用目的の範囲内であるか
- 入力した個人データが、応答結果の出力以外の目的(学習等)に使われないか(使われる場合は本人同意が必要)
現場の社員がこの2点をその都度確認するのは現実的ではないため、後述するように「個人情報を含む文章はそもそもAIに入力しない」という単純なルールに落とし込むのが実務的な対応になります。
営業秘密(不正競争防止法)上の論点
自社の技術情報や顧客リストなどが不正競争防止法上の「営業秘密」として保護されるためには、次の3つの要件を満たす必要があるとされています。
| 要件 | 内容 |
|---|---|
| 秘密管理性 | 秘密として管理されていること(アクセス制限、マル秘表示など) |
| 有用性 | 事業活動に有用な技術上・営業上の情報であること |
| 非公知性 | 一般的に知られていない情報であること |
ここで実務上問題になるのが「秘密管理性」です。社員が学習利用の可能性がある生成AIサービスに営業秘密を自由に入力できる状態のままだと、「秘密として管理されている」と言えなくなり、後にその情報が漏えいした際に法的な保護を受けられなくなるおそれがあります。一度失われた営業秘密としての法的保護は、取り戻すことが困難です。
この観点からも、「入力先のAIサービスが入出力データを学習利用しない契約になっているか」「守秘義務条項があるか」を確認したうえで、利用してよいAIサービスを絞り込む(ホワイトリスト運用)ことが重要になります。この考え方は、LLM(大規模言語モデル)を提供する各社の法人向けプランと個人向け無料プランとで、入力データの扱いが大きく異なる理由にもつながっています。
AI事業者ガイドラインの位置づけ
総務省・経済産業省が公表している「AI事業者ガイドライン」(2026年8月時点の最新版は第1.2版)でも、AIの利用にあたって個人情報や自社のナレッジ・知的財産等の機密情報がプロンプトとして入力され、AIからの出力等を通じて流出するリスクが指摘されています。このガイドラインは法的な強制力を持つものではありませんが、業界の標準的な考え方を示すものとして、社内ルール策定時の参考にする会社が増えています。ガイドライン全体を踏まえた社内規程の作り方は、別記事の生成AI利用ガイドラインの作り方で章立てのテンプレートを解説しているので、あわせて参照してください。
「入力してはいけない情報」の分類表
法的な論点を踏まえたうえで、実務で使える分類表に落とし込みます。ポイントは、「機密情報」という抽象的な括りではなく、社員が日常業務で目にする情報の種類ごとに、入力可否をあらかじめ決めておくことです。
レベル1: 入力禁止(例外なし)
| 情報の種類 | 具体例 |
|---|---|
| 個人を特定できる情報 | 氏名・住所・電話番号・メールアドレス・社員番号・顧客ID |
| 要配慮個人情報 | 病歴・健康診断結果・犯罪歴・信条など特に配慮を要する情報 |
| 認証情報 | パスワード・APIキー・アクセストークン・秘密鍵 |
| 未公開の財務・経営情報 | 未発表の決算数値、M&A・resignation等の未公表案件 |
| 契約上守秘義務のある取引先情報 | NDAを締結した相手先の固有名詞・取引条件 |
レベル2: 要確認・原則マスキング
| 情報の種類 | 対応方針 |
|---|---|
| 社内の議事録・企画書 | 固有名詞(社名・氏名・数値)を伏せ字にしてから要約させる |
| ソースコード・システム構成 | 会社名・ドメイン・IPアドレス等を含む箇所を削除してから貼り付ける |
| 人事関連(評価・給与) | 個人が特定されない形に加工する、またはそもそも入力しない |
| 顧客からの問い合わせ内容 | 顧客名・連絡先を除去し、問い合わせの要旨のみを入力する |
レベル3: 入力可(通常の業務範囲)
| 情報の種類 | 具体例 |
|---|---|
| 一般公開されている情報 | 自社の公式サイト掲載内容、プレスリリース済みの情報 |
| 固有名詞を含まない一般的な文章 | 汎用的な文面のたたき台作成、文章の校正・言い換え |
| 匿名化・仮名化済みのデータ | 個人・取引先が特定できないよう加工済みのサンプルデータ |
この3段階の分類は、あくまで出発点です。実際に運用する際は、自社の業種特性(医療・金融など個人情報の取扱いに厳格な業界かどうか)や、扱っている情報の性質に応じて、レベル分けの境界線を調整する必要があります。
社内ルールを設計する5ステップ
分類表ができたら、それを実際の社内ルールとして機能させるための手順に進みます。
ステップ1: 自社が扱っている情報を棚卸しする
分類表を作る前に、まず自社がどんな情報を扱っているかを洗い出す必要があります。部署ごとに「業務上、日常的に目にする情報」をリストアップしてもらうのが現実的です。営業部門なら見積・価格交渉、人事部門なら評価・給与、開発部門ならソースコード・顧客の環境情報、といった具合に、部署ごとの実態を反映させます。
ステップ2: 情報を3段階に分類する
前章の分類表をベースに、棚卸しした情報を「入力禁止」「要確認・要マスキング」「入力可」の3段階に振り分けます。このとき重要なのは、抽象的な分類名で終わらせず、必ず具体例を添えることです。「機密情報は禁止」ではなく、「顧客名・電話番号・取引条件を含む文章は禁止」まで書き下ろします。
ステップ3: マスキング・代替入力の具体的な手順を示す
要確認レベルの情報については、「どう加工すれば入力してよいか」まで示すことが実効性を左右します。たとえば次のような手順書を用意すると、社員が迷わず対応できます。
- 固有名詞(社名・氏名・地名)を「A社」「Bさん」のような仮名に置き換える
- 数値情報(金額・数量)は、桁数を保ったダミー数値に置き換える、または「約○○万円」程度に丸める
- 置き換え後の文章を読み返し、元の情報が推測できないか確認する
- 判断に迷う場合は、入力せずに情シス・法務部門へ相談する
ステップ4: 承認・相談のフローを決める
「要確認」に分類される情報のうち、判断が難しいものについては、現場の社員だけで判断させず、相談窓口を明確にしておくことが重要です。小規模な会社であれば、都度の稟議のような重い手続きではなく、チャットツールの専用チャンネルに投げて情シス担当者がその場で回答する程度の軽量な運用でも十分に機能します。重要なのは「誰に」「どうやって」相談すればよいかが、社員全員に周知されていることです。
ステップ5: 利用してよいAIサービスをホワイトリスト化する
同じ「入力禁止」の情報であっても、契約形態によって実際のリスクは変わります。個人向け無料プランでは入力内容が学習に利用される設定になっている場合が多い一方、法人向けプランでは標準で学習対象外になっていることが一般的です。ルールとして「入力してよい情報」を決めるのと並行して、「業務で使ってよいAIサービス」を情シス側で指定し、社員が個人アカウントで無料版を使うことがないよう周知する必要があります。学習利用の設定を個別に確認したい場合は、生成AIに学習させない設定まとめも参考にしてください。
運用を定着させるための工夫
ルールを作って終わりにせず、実際に社員が守り続けられる状態にするための工夫をいくつか紹介します。
具体例をポスターやチェックリストにする。文章だけの規程は読まれません。「入力禁止の情報」を1枚のチェックリストにまとめ、社員が目にする場所(社内ポータルのトップ、休憩スペースの掲示物など)に置いておくと、実務上の抑止力になります。
入社時・異動時のオンボーディングに組み込む。新しく入社した社員や、AIを使う業務に異動してきた社員が最初に目にするマニュアルに、入力禁止情報の分類表を含めておきます。後から個別に周知するよりも、最初のタイミングで習慣化させる方が定着しやすくなります。
定期的な見直しのタイミングを決めておく。生成AIサービスの利用規約や学習ポリシーは数ヶ月単位で変わることがあります。「半年に1回、分類表と利用可能サービスの一覧を見直す」といった頻度をあらかじめ決めておくと、ルールが形骸化しにくくなります。
ルールは一度作って終わりではなく、「誰が」「いつ」見直すかを決めておくことで初めて運用として機能する。
違反が起きたときの対応も決めておく。うっかり機密情報を入力してしまった社員が見つかった場合、懲罰的な対応を前面に出すと、以後の申告が隠蔽される方向に働きかねません。まずは事実確認と影響範囲の把握を優先し、再発防止のための注意喚起にとどめる運用のほうが、結果的に早期発見・早期対応につながりやすいという考え方もあります。すでに社員がルール整備前からAIを使い込んでしまっている状況への対処は、シャドーAI化への事後対応を扱った記事でも詳しく整理しています。
AIサービス側の技術的な対策も併用する
社内ルールによる人的な対策に加えて、技術的な対策を組み合わせることでリスクをさらに下げられます。
- 法人向けプランへの統一: 個人向け無料プランの利用を許可せず、学習利用対象外が明示されている法人プランに統一する
- シングルサインオン(SSO)によるアカウント管理: 業務利用のAIサービスを社内アカウントに紐付け、個人アカウントでの利用を実質的に困難にする
- 入力内容のログ・監査機能の活用: 法人向けプランの中には、社員の入力内容を管理者が事後的に確認できる機能を持つものもあります。監視目的というより、事故が起きた際の影響範囲を特定するための備えとして活用します
こうした技術的対策は、社内ルールの実効性を補強するものであり、ルールそのものの代わりにはなりません。「ツールで防げるから、ルールは曖昧でよい」という考え方は本末転倒になりやすい点に注意してください。
生成AI特有の注意点: ハルシネーションとの違い
機密情報の入力とは別の論点ですが、あわせて押さえておきたいのが、AIの回答をそのまま業務に使う際のリスクです。生成AIは、事実に基づかない情報をもっともらしく生成してしまうハルシネーションと呼ばれる現象を起こすことがあります。機密情報の入力対策とは方向性が逆の話ですが(こちらは「AIから出てくる情報」の正確性の問題)、社内ルールを整備する際には、入力面だけでなく出力の扱い(AIの回答を鵜呑みにせず一次情報で裏取りする)についても触れておくと、より実務に即したガイドラインになります。
また、社内文書を検索対象にしてAIに回答させるRAG(検索拡張生成)のような仕組みを導入する場合は、参照させる文書自体に機密情報が含まれるため、入力時の一時的な情報だけでなく、参照データベースの権限管理もあわせて設計する必要があります。この場合の選択肢は、社内データとAI活用の記事で個別に整理しています。
業種別に追加で意識したいチェックポイント
分類表の3段階は業種を問わない汎用的な出発点ですが、業種によっては追加で意識すべき情報の種類があります。自社の業界特性に応じて、レベル1(入力禁止)の対象を広げる形で調整してください。
医療・介護に関わる情報を扱う場合は、病歴・診療内容・要介護度といった要配慮個人情報が日常的に発生します。これらは通常の個人情報よりも一段階厳格に、匿名化・仮名化した場合でも入力を避ける運用にする会社が多く見られます。
金融・与信情報を扱う場合は、口座情報・与信審査の結果・信用情報機関への照会内容などが対象になります。これらは規制業種特有の監督官庁のガイドラインが別途存在することもあるため、自社の業界団体が発行する指針もあわせて確認しておくと安心です。
製造業で設計・製造情報を扱う場合は、図面データ・製造プロセス・品質不具合の詳細といった技術情報が営業秘密に直結しやすい分野です。デバッグや不具合解析の目的でAIに情報を入力したくなる場面が多い業種でもあるため、開発部門向けに具体例を厚めに用意しておくことをおすすめします。
士業・コンサルティング業など顧客の機密情報を預かる場合は、そもそも自社の情報だけでなく「預かっている顧客の情報」を第三者(AIサービス提供者)に開示してよいかという契約上の論点が加わります。顧客との契約書に守秘義務条項がある場合、AIサービスへの入力がその条項に抵触しないか、契約の文言を個別に確認する必要があります。
部署別のルール例(たたき台)
抽象的な分類表だけでは、実際に運用に落とし込む際に部署ごとの解釈がばらつきがちです。参考として、部署別の禁止・許可例をまとめたたたき台を示します。自社の実態に合わせて調整して使ってください。
営業部門
- 禁止: 顧客名・価格交渉の詳細・見積内容をそのまま貼り付けて提案文を作らせる
- 許可: 商品の一般的な特徴を説明する文章のたたき台を作らせる、業界動向を調べさせる
人事・総務部門
- 禁止: 個人が特定できる評価内容・給与額・懲戒事案の詳細を要約・分析させる
- 許可: 就業規則の条文をわかりやすく言い換えさせる、求人票の文面を整えさせる
開発・情シス部門
- 禁止: 本番環境のAPIキー・データベースの接続情報・顧客環境のIPアドレスを含むログをそのまま貼り付ける
- 許可: 汎用的なエラーメッセージの原因調査、公開されているサンプルコードをベースにした実装相談
経理・財務部門
- 禁止: 未発表の決算数値、特定の取引先との支払条件を含む帳票データ
- 許可: 会計処理の一般的な考え方の確認、仕訳のたたき台作成(具体的な金額・取引先名は伏せる)
入力前のセルフチェックの型を用意する
分類表を覚えてもらうのと並行して、入力する直前に社員自身が確認できる、短いセルフチェックの型を用意しておくと定着しやすくなります。次のような3つの質問に「はい/いいえ」で答えるだけの簡易フローが実務では有効です。
- この文章に、個人が特定できる情報(氏名・連絡先・社員番号など)が含まれていないか
- この文章に、会社名や金額などの固有情報を伏せ字にしないと、誰の・どんな情報か推測できてしまう箇所がないか
- この情報が外部に漏れた場合、会社や顧客に実害が生じる可能性がないか
3つのうち1つでも「いいえ」と言い切れない場合は、入力を止めて分類表を確認するか、情シス・法務部門に相談する、というシンプルなルールにしておくと、社員が都度立ち止まって考える習慣がつきやすくなります。この型自体をチェックリストとして印刷し、デスク周りに置いておく運用も効果的です。
一人情シスがミニマムで始める場合の優先順位
ここまで紹介した内容を、専任の情シス担当者が1人しかいない、あるいは総務が兼任している会社がすべて一度に整備するのは現実的ではありません。時間や人手が限られている場合は、次の優先順位で着手することをおすすめします。
優先度1: レベル1(入力禁止)の分類表だけ先に作って周知する。すべての部署のルールを一度に固めようとせず、まずは「個人情報」「認証情報」「未公開の財務・経営情報」など、業種を問わず共通する入力禁止の情報だけを1枚のリストにまとめ、社内チャットや掲示物で先に周知します。完璧な分類表を作り込むよりも、最低限の禁止事項を早く共有することの方が、実際の事故防止には効果があります。
優先度2: 相談窓口を1つ決める。分類表を完璧に作り込む前に、「判断に迷ったらここに聞く」という窓口だけは先に決めておきます。情シス担当者自身が窓口になる場合も、チャットツールの専用チャンネルを作るだけで運用を始められます。
優先度3: 部署別の具体例は、実際に相談が来た内容から蓄積していく。最初からすべての部署の具体例を網羅する必要はありません。優先度2の相談窓口に寄せられた質問を「よくある質問」として蓄積し、それを分類表に反映していく運用でも、時間をかければ実用的な分類表に育っていきます。
優先度4: 定期的な見直しのタイミングを設定する。ミニマムな運用から始めた場合こそ、定期的な見直しを忘れると形骸化しやすくなります。半年に1回など、あらかじめ見直しのタイミングをカレンダーに入れておくことをおすすめします。
限られたリソースの中でも、この4つの優先順位に沿って着手すれば、完璧なガイドラインが完成するのを待たずに、最も事故が起きやすい「入力禁止情報の周知」から実効性を持たせることができます。
まとめ
生成AIへの機密情報の入力事故は、社員の不注意というよりも、「何が入力禁止なのか」が具体的に示されていないことが根本原因になっているケースがほとんどです。「機密情報は入力しないこと」という抽象的な注意喚起ではなく、情報の種類ごとに入力可否を明示した分類表を作り、判断に迷ったときの相談窓口を用意することが、実効性のあるルール設計の出発点になります。
法的な観点では、個人情報保護法上の利用目的の範囲、不正競争防止法上の営業秘密の秘密管理性という2つの論点を踏まえたうえで、自社の業務実態に合わせた分類表を作成してください。分類表は一度作って終わりではなく、AIサービスの規約変化に合わせて定期的に見直す運用を、あらかじめルールの中に組み込んでおくことが定着の鍵になります。
まだ生成AI利用ガイドライン全体を作っていない場合は、この記事で扱った「入力してはいけない情報」の論点を、ガイドラインの1つの柱として組み込む形で全体設計を進めることをおすすめします。




