「ChatGPTは危ないから全面禁止にしておけば安全」──この思考が、社内で最も危険な情報漏洩リスクを生んでいる現実があります。禁止された瞬間から、情シスやDX担当の目が届かない「シャドーAI利用」が静かに増え、個人アカウント＋履歴オンのChatGPTにソースコードや営業マニュアルが貼り付けられていく。Samsungのような“うっかり入力”は、禁止の有無とは無関係に起きます。違いを決めるのは、どこからが情報漏洩かを明確に線引きし、現場が守れる条件付き容認の仕組みを持っているかどうかです。
多くの記事は、「個人情報は入力しない」「履歴オフにする」「ChatGPT Enterpriseなら安全」といったキーワードを並べるだけで終わります。しかし、あなたが本当に知りたいのはそこではないはずです。
どの業務シーンで、どの程度までならChatGPTに任せてよいのか。
個人利用／Business／Enterprise／API接続の違いを、情シスとしてどう説明し、どこに限界があると判断すべきか。
そして、50ページの社内ルールではなく、現場が今日から動ける「これだけはやらない」短文ルールと監査の仕組みをどう作るか。
このガイドは、ChatGPT 情報漏洩を「怖いから止める／便利だから黙認する」という二択から解放し、条件付き容認でリスクを管理しながら業務効率を上げるための実務ロジックだけを扱います。社内告知だけで止まらない勝手利用のパターン、ソースコード・営業マニュアル・議事録の三つの典型シナリオ、個人アカウントとEnterpriseの“安全度”の差、API接続の落とし穴まで、情シスとDX推進が同じテーブルで議論できる言葉に分解します。
さらに、「これ、ChatGPTに聞いても大丈夫ですか？」と相談された場面をLINE／メール風に再現し、その場で返せる判断軸と回答例を提示します。形式だけのガイドラインではなく、日々の問い合わせに迷わず答えられる自分軸が手に入ります。最後に、エンドポイント管理やDLP、ログ監査を「監視」ではなく「保険」として位置付け直し、PoCがセキュリティレビューで止まらない段取りと、月次レビューで見るべき数字まで整理します。
この記事を読み終えたとき、あなたは「禁止か解禁か」ではなく、どのレベルの情報を、どのプランのChatGPTに、どの条件で許容するかを自信を持って決められるようになります。これは、インシデント後に責任を問われないための防御線であり、生成AI活用を前に進めるための攻めの土台です。
| セクション | 読者が手にする具体的な武器（実利） | 解決される本質的な課題 |
|---|---|---|
| 前半（禁止の落とし穴〜典型シナリオ〜プラン比較） | シャドーAIを前提にした「どこからが情報漏洩か」の線引きと、個人／Business／Enterprise／APIの安全度を整理する判断軸 | 「ChatGPTは危ない」の感覚論から抜け出せず、社内に説明できない状況 |
| 後半（ルール設計〜相談対応〜数値管理〜DXとの調整〜教育） | 業務シーン別の短文ガイドライン、現場への回答テンプレ、簡易スコアリングとツール活用、PoCが止まらない進め方、継続教育の型 | ルールは作ったが守られない、セキュリティとDXが対立し、結局“グレーな利用”だけが増える現状 |
ChatGPTの情報漏洩リスクは、「恐れて距離を置く人」と「構造から分解して管理する人」で、これから決定的な差がつきます。後者側に立つための具体的な手順を、この先で一つずつ解き明かします。
目次
「ChatGPT＝危ないから禁止」の落とし穴──シャドーAIが増える会社の共通点
「ChatGPTは危ない。明日から業務利用は禁止」
ここでほっとするのは、経営陣と一部のコンプラ担当だけだ。情シス・DX担当の頭に浮かぶのは別の光景だろう。
「営業は私物スマホで続けるな」「若手は個人アカウントでこっそり使うな」――そう、“見えないところでの利用”が一気に加速する。
国内調査でも、業務でのChatGPT利用経験者は約4割いる一方で、多くが情報漏洩に不安を感じていると報告されている。不安は強いが、便利さも知ってしまった現場は「禁止」と書かれた紙一枚では止まらない。
社内告知だけで止まらない、“良かれと思った”勝手利用の現場
実際の現場で起きているのは、悪意ではなく善意のシャドーAI利用だ。
-
納期に追われたエンジニアが、バグ解消のためにソースコードを貼る
-
資料づくりに追われた営業が、顧客名入りの提案書を「分かりやすくして」と投げる
-
議事録担当が、「要約して」と未発表プロジェクトの会議録を入れる
本人たちの頭の中には「会社を楽にしたい」「怒られるほどの情報ではない気がする」という感覚がある。
ここを感覚任せにしたまま「禁止」だけ出すと、リスクは社内ネットから“私物スマホの4G/5G”へ逃げる。情シスはもう、ログですら追えない。
なぜ全面禁止が「最もログが残らないリスク状態」を生むのか
セキュリティの実務で危ないのは、「使われているのに、痕跡がない状態」だ。ChatGPTでも同じ構図になる。
| 状態 | 利用場所 | ログの見え方 | 情シスから見たリスク |
|---|---|---|---|
| 公認利用 | 会社PC＋公式ブラウザ | プロキシ・DLPで可視化 | 高いが管理可能 |
| 黙認状態 | 会社PC＋個人アカウント | 一部のみ把握 | 実態が読めない |
| 全面禁止後 | 私物スマホ・自宅PC | 事実上見えない | 規程上はゼロ、実態は最大 |
「禁止にしたからリスクゼロ」と思っているのは紙の上だけで、現場は“ログが一切残らない形”で続行する。
Samsungのようにソースコードが外部に送られた事例では、少なくとも「どの端末から」「どのタイミングで」使われたかを後から追えた。全面禁止の世界では、その痕跡すら失われる。
安易な禁止と、現場が守れる“条件付き容認”の決定的な違い
現場を止めずにリスクを落とす現実解は、「禁止」ではなく“条件付き容認＋ログ確保”だ。
-
使ってよい用途を明示する
例: 公開済み情報の要約、テンプレ文面のたたき台づくりなど
-
絶対に入れてはいけない情報を短い言葉で線引き
「実名」「未発表の数字」「契約条件」「ソースコード」はNGと、業務シーン別に示す
-
公式なアクセス経路を1本用意し、そこでだけ使うよう徹底
プロキシやDLPでログを取り、「誰が、どの程度使っているか」を見える化する
現場が守れるルールは、「3行で説明できるかどうか」でだいたい決まる。
情シス・DX担当が狙うべきは、“ゼロリスク幻想”ではなく、“ログが残る範囲にAI利用を引き戻すこと”だ。ここを外すと、気づいたときには「誰が、どの情報を、いつ外に出したのか」が永遠に分からない世界に足を踏み入れる。
どこからが「情報漏洩」なのか？情シスが説明に詰まるグレーゾーンを言語化する
「そのプロンプト、もう社外にデータを出した扱いですよ」
多くのマネージャーがここを言い切れずに、判断を先送りしています。
情報漏洩かどうかは、“どんな情報を・どこまで外部のクラウドに渡したか”で決まります。ChatGPTは便利なAIサービスですが、OpenAIのクラウドに情報を送る行為そのものが「外部提供」です。Slackやメールと同列ではなく、「国外クラウド事業者への送信」として評価される点をまず押さえる必要があります。
個人情報・機密情報・社外秘…ChatGPTに入力してはいけないラインの引き方
現場で使える線引きは、法務用語より「相手にそのまま渡せるかどうか」で考えると整理しやすくなります。
| 情報の種類 | 代表例 | ChatGPTへの入力方針（業務利用前提） |
|---|---|---|
| 特定個人情報 | マイナンバー、健康情報 | 全面NG：マスキングしても極力避ける |
| 個人情報 | 氏名＋所属＋メール等 | 原則NG：どうしても必要なら完全匿名化 |
| 機密情報 | 未公開の仕様、ソースコード、価格表 | NG寄り：原本は投入しない。要素分解して相談 |
| 社外秘レベル | 社内マニュアル、議事録 | 加工前提で注意：固有名詞と数値を落として利用 |
| 公開情報 | プレスリリース、公開Web記事 | OK：要約・翻訳・ドラフト作成に活用可 |
ポイントは、「Samsungのソースコード入力」のように本人は“ただの業務データ”と思っていても、クラウド保存された瞬間に社外持ち出しと同じ評価になることです。
情シスとしては、「この情報を取引先のサーバーに丸ごと置けるか？」と聞き直すだけで、多くの現場利用を整理できます。
「学習される／されない」と「漏洩リスク」は別問題、というプロの視点
ChatGPT EnterpriseやBusinessでは、「入力データはモデルの学習に使わない」とOpenAIが明言しています。この違いは重要ですが、学習されない＝安全ではない点を説明できないと、経営会議で詰まります。
-
学習の話
- モデルの改善に再利用されるかどうか
- 他社ユーザーの回答に自社の情報が“にじみ出る”リスク
-
学習とは別に残るリスク
- 通信経路（ネットワーク）での盗聴・攻撃
- 誤設定によるアクセス権限のミス
- アカウント乗っ取り・パスワード流出
- 管理者・委託先による誤操作
つまり、Enterpriseを入れても「外部クラウドに置いてよい情報か？」という判断は依然として必要です。API接続であっても、DLPやエンドポイント管理を併用して「誰が・いつ・どの業務データを送ったか」を見える化しておかないと、インシデント発生時に説明できません。
Slackやメールより危ない？“クラウド越境”という観点で見直すべき点
「社内メールで回すのと何が違うのか」と聞かれたときは、クラウド越境で説明すると腹落ちしやすくなります。
| 比較対象 | データの行き先 | 契約・管理範囲 | 情報漏洩リスクの見え方 |
|---|---|---|---|
| 社内メール | 自社メールサーバー（多くは国内） | 既存の情報セキュリティポリシー内 | ログ・バックアップ・監査の前提がある |
| Slack等SaaS | ベンダーのクラウド（主に特定リージョン） | 利用規約・DPAで把握済み | すでに情シスがリスク評価済み |
| ChatGPT | OpenAI等のグローバルクラウド | 導入前は未評価のことが多い | 「どの国の、どの仕組みで保存されるか」が曖昧になりやすい |
情シスが押さえるべきポイントは次の3つです。
-
行き先が「自社ドメイン内」から「国外クラウド事業者」へ越境している
-
既存の資産管理・ログ監査の網に最初は引っかからないサービスである
-
一度送ったデータは、ユーザー側で完全に削除できるとは限らない（ログやバックアップに残る）
この構造を押さえたうえで、「だからこそChatGPTだけを悪者扱いするのではなく、クラウド越境する全てのツールを同じ物差しで評価する」というスタンスを示すと、DX推進側とも建設的な議論がしやすくなります。
Samsungだけじゃない、“うっかり入力”で燃え上がる典型シナリオ分解
エンジニアがソースコードを貼った瞬間に何が起きているのか
「コンパイルエラー直したいだけなんだけど」
エンジニアがChatGPTにソースコードを入力した瞬間、機密コードは外部クラウド上のストレージにコピーされる。
個人アカウントで履歴オンなら、OpenAI側でログ保存され、設定次第ではモデル学習の候補にもなる。
ポイントは、エンジニア本人の感覚では「画面上のチャット相手に見せただけ」でも、実態は第三者クラウドへの持ち出しになっていること。Samsung事例が象徴するのは、悪意ではなく「納期優先の善意」が情報漏洩を起こす構造だ。
営業マニュアルの添削依頼で、取引先情報が丸ごと外部に出る構造
営業マニュアルの文章をコピペして「もっと分かりやすく」と依頼すると、内部では以下が一括で送信される。
-
取引先名
-
単価・条件
-
社内略語や案件コード
これらは全文1セットのテキストとしてクラウドに保存されるため、「名前だけ消せば安全」とは言い切れない。価格帯や商流パターンが組み合わさると、特定企業を推定できる場合があるからだ。
議事録要約・メール文面作成…「よくある業務3パターン」のリスク比較
よく相談される3パターンを、リスクの質で整理すると次のようになる。
| 利用パターン | 典型シーン | 主な漏洩リスク |
|---|---|---|
| 議事録要約 | 会議メモを丸ごと入力 | 未発表企画、社内の力学が外部クラウドに保存 |
| メール文面作成 | 顧客名入りドラフトを入力 | 取引先情報・クレーム内容の流出 |
| テンプレ作成 | 架空の設定だけ渡す | 実データを入れない限りリスクは相対的に低い |
「生の業務データを丸ごと貼るほど赤信号」という感覚を、情シス側が数字と具体例で示せるかどうかが勝負どころになる。
ChatGPT Enterprise / Business / 個人利用の「安全度」を冷静に比較する
「どのプランなら“情シスとして眠れる”のか」。ここを言語化しないまま議論すると、声の大きい人の“なんとなく安全そう”で決まってしまう。情報漏洩リスクは“気合い”ではなく、仕様×運用で冷静に比較した方が早い。
個人アカウント＋履歴オン／オフでどこまで変わるのか
まず多くの従業員が今まさに使っているのが、個人用のChatGPT（Personal）。ポイントは履歴＝モデル学習のオン／オフだ。
| 観点 | 個人：履歴オン | 個人：履歴オフ |
|---|---|---|
| モデル学習 | 入力がOpenAIのモデル改善に使われる | モデル学習には原則使われない |
| データ保存 | ベンダー側ログに一定期間保存 | ログ保存は継続、学習のみ停止 |
| 管理者の可視性 | 企業側からはほぼ見えない | 同左 |
| 情報漏洩リスク | 「再利用＋クラウド保存」の二重リスク | 「クラウド保存」のリスクは残存 |
履歴オフは「学習オプトアウト」であって「送信キャンセル」ではない。
つまり、個人情報や機密情報を入力すれば、それ自体はクラウドに送られ、一定期間は保存される。
情シス視点では、履歴オフは「最低限の衛生管理」であって、「業務利用の公式ルート」とみなすには足りない。
現場に伝える時は、次のテンプレが通りやすい。
-
入力OK：既にWeb公開している情報、プレスリリース、採用ページ
-
条件付き：社内資料を匿名化・マスキングしたうえでの要約
-
完全NG：顧客名、社員名、未公開の数値、ソースコード、契約書ドラフト
履歴オフ＝何を入れても安全と誤解されているケースが多いので、ここをまず潰しておく。
Enterprise／Businessで“学習に使われない”ことの意味と限界
次に、企業が検討しがちなChatGPT Business / Enterprise。ここは「学習に使われない＝何を入れてもよい」ではない点を、経営層にも腹落ちさせる必要がある。
| 観点 | Business / Enterprise |
|---|---|
| モデル学習 | 入力はOpenAI共通モデルの学習に使われないと明示 |
| アクセス管理 | SSO、IP制限、ロール権限など企業向け機能 |
| ログ・監査 | 管理者向けログ閲覧、利用状況レポート |
| 契約 | 法人向け利用規約、データ処理契約(DPA) |
意味合いとしては、
-
「自社データが“世界中のユーザーが使う汎用モデル”に混ざらない」
-
「誰がどの程度利用したかを、管理者が追える」
というガバナンス上の大きな前進が得られる。一方で、次のリスクは残る。
-
社員が誤って入れてはいけない情報を入力する（ヒューマンエラー）
-
アクセス権限の設計ミスで、見えなくてよいログに別部署がアクセス
-
ID連携・端末側セキュリティの甘さからのアカウント乗っ取り
つまり、Enterprise / Businessは「クラウド側の守りを固めるサービス」であり、入力ラインの設計と社員教育を免除してくれるものではない。
情シスとしては「このプランを入れればOK」ではなく、「このプランを土台に、どこまでの情報を許可するか」を社内ルールで明文化することが仕事になる。
API接続なら安心？技術仕様と運用ミスという2つの落とし穴
「API経由なら学習されないから安全」と説明される場面も多いが、ここも“半分だけ正しい”状態だ。
| 観点 | OpenAI API利用 |
|---|---|
| モデル学習 | デフォルトで学習に使わない方針が示されているケースが多い |
| データ経路 | 自社システム → APIサーバー → 応答が戻る構造 |
| リスク1 | 自社側アプリやログに、入力データを残し過ぎる |
| リスク2 | 開発・検証環境で本番データを投入してしまう |
API接続の場合、クラウド側の学習リスクはかなり小さくできる。一方で、リスクの主戦場は自社側に移る。
-
開発チームがデバッグログにプロンプト全文を出力し、長期間保存
-
GitHub等のリポジトリに、APIキーとともにコードサンプルを公開
-
テスト用に本物の顧客データを使い、そのまま検証環境に残置
このあたりはDLPやエンドポイント管理ツールが効いてくる領域で、「APIを使っています」だけでは1ミリも安心材料にならない。
必要なのは、次の3点セットだ。
-
API仕様とプライバシーポリシーを読み込んだうえでの、データフロー図の作成
-
ログに残す項目の最小化（個人情報・機密情報をそもそも書き出さない）
-
開発・検証環境の権限管理とマスキングルール
プラン選定の議論では、「どのプランが安全か」だけでなく、「どのプランなら自社の運用レベルでコントロールしやすいか」まで踏み込むと、情シスとしての説明責任を果たしやすくなる。
「とりあえずルール作りました」が失敗する理由と、現場が動くガイドライン設計
50ページPDFを誰も読まない──ルールが形骸化するプロセス
ChatGPTの情報漏洩対策で、最初にやりがちな失敗が「分厚いPDF量産」です。情シスやマネージャーは安心しますが、現場の従業員から見るとこう動きます。
-
最初の1ページだけ眺めて閉じる
-
必要なときに検索しても、どこに何があるか分からない
-
「とりあえず禁止っぽいから個人アカウントでこっそり使う」シャドーAI化
形骸化するプロセスを分解すると、次の3ステップです。
- 抽象論中心（「機密情報の漏洩リスクに注意」レベル）
- 自分の業務シーンに引き直せない
- 面倒なので守らない → 監査ログにも残らない形で利用
情報漏洩リスクを下げたいのに、「最もログが残らない危険な状態」を自ら作っている企業が多いです。
業務シーン別「これだけはやらない」短文ルールの作り方
現場が本当に使うのは、業務シーン別の一行ルールです。ポイントは「職種×シーン」でざっくり切ること。
例として、情シスが最初に作ると動きやすい軸は次の4つです。
-
営業メール作成
-
議事録要約
-
ソースコード相談（開発）
-
人事・総務の文書ドラフト
この単位で、「これだけはやらない」を短文に落とします。
| シーン | 禁止ルールの例 |
|---|---|
| 営業メール作成 | 実在の顧客名＋案件名を含む本文をそのまま入力しない |
| 議事録要約 | 未発表の企画名や個人名は、役職＋イニシャルに置き換えて入力する |
| ソースコード相談 | 社外非公開リポジトリのコードを丸ごと貼らない（関数単位まで） |
| 人事・総務文書 | 社員の氏名・社員番号・個人情報を含む原文は入力しない |
ChatGPT活用を止めるのではなく、「どこまでの入力なら会社として許容するか」を具体的な日本語で決めておくことが、ガイドラインの中核になります。
LINE/メール風テンプレで伝える：現場に刺さるNG・OK例の見せ方
PDFではなく、LINEやメールでそのまま流せるテンプレに落とし込むと、現場の定着率が一気に上がります。情シスが社内ポータルやTeamsに投稿するイメージです。
例：営業向けテンプレ
「ChatGPT利用ルール（営業版・超ざっくり）
NG：実在の顧客名＋案件名を含むメール本文をそのままコピペして入力
OK：顧客名や金額を『A社』『○万円』に置き換えたうえで、文章の言い回しだけ相談
迷ったら：このチャットにスクショ送ってください」
例：開発向けテンプレ
「ChatGPT利用ルール（開発版）
NG：社外非公開リポジトリのコードをファイルごと貼る
OK：バグ箇所と思われる関数だけを切り出し、社名やサービス名は別名に変更
補足：コード相談を業務で使う場合は、必ずEnterpriseかBusinessプラン＋履歴オフ設定を利用」
このレベルまで具体化すると、従業員は「使ってはいけない」ではなく「こうすれば安全に使える」と理解できます。結果として、シャドーAIを減らしつつ、ChatGPTの情報漏洩リスクを現実的なラインまでコントロールできます。
実務で本当に起きている“相談の中身”を分解する（LINE/メール再現風）
「ChatGPTの情報漏洩リスクは分かってきた。でも、目の前のこの文章を“今”入れていいのかが分からない。」
情シスやDX担当に飛んでくるLINEやメールは、だいたいこの温度感です。
「これ、ChatGPTに聞いても大丈夫ですか？」と聞かれたときの判断軸
現場からの相談は、ざっくり次の3要素で瞬時に仕分けできます。
- 情報の中身（誰の何の情報か）
- 情報の粒度（個人特定・企業特定ができるか）
- 送信先のコントロール性（個人アカウントか、管理されたサービスか）
LINE風に書くと、やり取りはこうなります。
-
現場「この議事録、ChatGPTに要約させていいですか？」
-
担当「①個人名や社名は入ってる？②まだ公開していない企画？③個人アカウントから？」
-
現場「個人名と社名は入ってます。新サービスの内容も。個人アカです。」
-
担当「そのままはNG。最低でも名前と社名、金額、未発表の固有名詞はマスキングして。業務用アカウントが整うまでは、一般論だけを投げて。」
判断フローのイメージ
| 見るポイント | OKに近い状態 | NGに近い状態 |
|---|---|---|
| 情報の中身 | 公開済み情報ベース | 個人情報・機密情報を含む |
| 粒度 | 匿名化・集計済み | 個人名・社名・金額が生 |
| 送信先 | Enterprise/Business等の管理環境 | 個人アカウント＋履歴オン |
この3軸をその場で聞き取り、「どこを削れば安全側に寄るか」を一緒に整理してあげると、現場も納得しやすくなります。
ありがちな質問ベスト3と、その場で返した具体アドバイス
現場から本当によく飛んでくる質問は、次の3つに集約されます。
-
「営業メールの文面、これをベースにうまく書き直してほしい」
- アドバイス
- 顧客名、見積金額、社内の略称は「〇社」「XX円」「自社製品A」に置き換えてから入力。
- 「個別案件」ではなく「こういう条件の営業メールを作って」とプロンプトを組み替える。
- アドバイス
-
「ソースコードのバグをChatGPTに見てもらっていいですか？」
- アドバイス
- 特定顧客向けのカスタム部分やAPIキー、URL、内部IPは必ず削除。
- 可能なら、問題のある関数だけを抜き出し、顧客名や内部構成が分からない形にする。
- アドバイス
-
「会議の文字起こしを丸ごと入れて要約してもいいですか？」
- アドバイス
- 参加者名、会社名、未発表プロジェクト名をすべて記号に置き換える。
- 機微な人事情報や評価コメントが多い会議は、ChatGPTではなく社内ツール側で要約。
- アドバイス
【即レス用・ショートメッセージ例】
-
「名前・社名・金額・まだ外に出していない固有名詞が“生”なら一旦NG。そこを伏せて“型だけ”にしてからChatGPTに投げてください。」
-
「個人アカウント＋履歴オンでの利用は、原則“公開されても困らないレベルの情報だけ”にしてください。」
「その使い方ならOKだが、ここをマスキングしてから」と伝えるコツ
禁止だけを伝えると、シャドーAI利用に流れます。ポイントは「OKゾーンを先に示してから、削る場所を具体的に教える」ことです。
【マスキング指示のコツ】
-
抽象ではなく赤ペン感覚で具体的に
-
「固有名詞を消して」ではなく「顧客名・金額・日付・住所は全部〇〇にしてから」と列挙する
-
「この3種類は“絶対に入れない”」と、ルールを3つに絞る
【チャットでの伝え方サンプル】
-
「この文章なら、
- 顧客名
- 社員名
- 見積金額
だけ“○社”“Aさん”“XX円”に直せば、ChatGPTに投げてOKです。
それ以外は触らなくて大丈夫。」
-
「企画名と日付を伏せれば“汎用の社内説明文”になるので、その状態で要約を依頼してください。」
こうした“その場で使える一文”をいくつかテンプレにしておくと、情シス・DX担当が数十秒で安全な活用に誘導できるようになります。
情報漏洩リスクを“感覚”から“数字と仕組み”に引きずり出す
「なんとなく危ない」を放置すると、情シスの頭の中だけがブラックボックスになる。ChatGPTの情報漏洩リスクは、“勘”ではなくチェックシート＋ログ＋月次レビューで数字に落とすと、一気に社内説明がしやすくなる。
利用実態＋リスクを簡易スコアリングするチェックシートの考え方
まずやるべきは「何点なら経営に報告レベルか」を決めること。項目は多くなくていい。現場ヒアリングとログから、利用シーン×データの機密度で点数を付ける。
例として、情シスがよく使う軸はこの5つ。
-
入力するデータの機密度（公開情報/社外秘/機密）
-
利用プラン（Personal/Business/Enterprise/API）
-
デバイス（会社貸与/私物端末）
-
アカウント管理（SSO/個人メール/パスワード使い回し）
-
利用目的（ドラフト作成/本番文書/ソースコード）
| 評価軸 | 低リスク=1点 | 中リスク=2点 | 高リスク=3点 |
|---|---|---|---|
| データ機密度 | 公開済み資料 | 社外秘（氏名なし） | 個人情報・機密 |
| プラン | Enterprise | Business/API | Personal |
| デバイス | 社給＋MDM | 社給のみ | 私物端末 |
| アカウント | SSO | 法人メール | 個人メール |
| 利用目的 | 叩き台 | 一部流用 | ほぼ本番 |
各シーンの合計点を出し、例えば「12点以上は“要是正”」などの閾値を決めると、上司への説明が「危ない気がする」から「高リスクシーンが〇件」に変わる。
エンドポイント管理・DLP・ログ監査…ツールを「監視」ではなく「保険」に変える
次に、エンドポイント管理やDLPを“サボり検知ツール”ではなく“保険”として位置づけ直すと、現場の反発が落ちる。
ポイントは3つだけ共有する。
-
ChatGPTへのアクセスログは「犯人探し」ではなく、「利用実態の可視化」に使う
-
DLPのブロック条件は、まず「個人情報＋ChatGPTドメイン」など最小構成から始める
-
アラートが出た社員には、怒るのではなく「このケースはどうすれば安全か」を一緒にレビューする
こう伝えると、「監視される側」から「守られている側」に意識が切り替わりやすい。
月次レビューで見るべき数字と、現場に返すフィードバックの型
月次レビューは、分厚いレポートより3つの数字＋1つのメッセージが効く。
-
ChatGPTアクセス延べ件数
-
高リスクスコア（例：12点以上）の利用シーン数
-
DLPやフィルタでブロックされた試行回数
この3つを部門別に出し、現場には次のフォーマットで返す。
-
先月との比較（＋/−何％か）
-
高リスクだった具体シーン1〜2件
-
「この業務なら、ここをマスキングすればOK」という代替案
禁止事項だけで終わらせず、「どうすれば業務効率を落とさず安全にできるか」までセットで返すと、情シスと現場の距離が一気に縮まる。
DX推進×セキュリティの“仲直りポイント”──PoCが止まらない進め方
「PoCやりたいです」「情報漏洩リスクは？」で空気が凍る。この瞬間を潰せるかどうかが、DX推進とセキュリティの分かれ目になる。鍵は、最初の仕様書と段取りだ。
PoCの仕様書に最初から入れておくべき「データ取り扱い」の項目
PoC仕様書は機能よりデータから書くと衝突が減る。最低限、次の4軸は必須項目にしておきたい。
-
利用するデータ種別（個人情報・機密・社外秘・公開情報）
-
データの所在（オンプレ／クラウド／SaaS）と移動経路
-
ChatGPTプラン・API利用の有無（Personal／Business／Enterprise）
-
保存・ログ・マスキング方針（履歴オフ・オプトアウト設定など）
| 項目 | 例示記載 |
|---|---|
| データ種別 | 顧客名はハッシュ化、営業マニュアルは社外秘扱い |
| プラン | ChatGPT Enterprise、学習利用なしを前提 |
| 保存・ログ | プロンプトはDLPで監査、PoC終了時に削除 |
このレベルまで書いて初めて、セキュリティ側は「どこが本当の漏洩リスクか」を議論できる。
セキュリティレビューで“後出しNG”と言われないための段取り
止まるPoCの多くは、「もう外部ベンダー決めました」の事後相談だ。やるべき順番はシンプルに3ステップ。
- 概要1枚：目的・対象業務・利用データの粗い棚卸しだけを共有
- リスク洗い出し会：情シス・情報セキュリティ・DX推進で30分のオンラインMTG
- PoC仕様書ドラフト：上記の指摘を反映し、再確認を1回だけ行う
この流れにしておくと、「そんな仕様聞いてない」「このクラウドは社内ポリシー違反」といった後出しNGが激減する。
「守りの人」が納得する、攻めの生成AIプロジェクトの説明フレーム
セキュリティ担当は、ワクワクより“最悪ケース”で物事を見る職種だ。そこで、説明は次のフレームに乗せると刺さりやすい。
-
目的：工数何％削減・どの業務プロセスの効率向上かを明示
-
リスク：ChatGPT特有の漏洩リスク（入力・学習・クラウド越境）を自ら列挙
-
コントロール：プラン選定（Business/Enterprise/API）、利用ガイドライン、監査ログ・DLP連携の案をセットで提示
-
撤退条件：インシデント・誤回答率など、PoC中止ラインも最初から決めておく
「リスクはゼロではないが、ここまで仕組みで押さえ込む。その代わり、この業務で月X時間の削減が見込める」という“守りの人向けプレゼン”ができると、PoCは止まりにくくなる。
社員教育は「1回の研修」ではなく“日常の小さな警告”で回す
ChatGPTの情報漏洩リスクは、年1回のeラーニングでは防げない。
現場で本当に効くのは、「毎日少しずつ“思い出させる仕掛け”」だと感じている担当者は多いはずだ。
ポイントは、3〜5分で読める“即行動ネタ”を、業務動線のど真ん中に差し込むことだ。
朝礼スライド1枚で伝える「今日から変える1アクション」
朝礼・部門ミーティングに、ChatGPTと情報漏洩ネタを1枚だけ差し込む。長い説明は不要で、やるのは次の3要素だけに絞る。
-
1行キャッチコピー
例「議事録を貼る前に、“社外秘ワード”を5秒チェック」
-
NGスクショ1枚
「顧客名＋金額が丸見えのプロンプト画面」など、目で分かる例
-
今日から変える“1アクション”
「顧客名・金額は●●に置き換えて入力」「個人情報を含む内容はそもそも入力しない」など
朝礼ネタの設計は、業務シーン別に1テーマずつが鉄則だ。
-
営業：提案書・営業メール
-
バックオフィス：人事評価コメント・労務相談
-
開発：ソースコード・エラーログ
この粒度に落とすと、情シスやDX推進が「抽象的なセキュリティ意識」ではなく、ChatGPT利用ルールとして具体的に刺さる。
社内ポータル・Teams投稿を使った“週1・3分”のマイクロラーニング
「情報セキュリティ月間」より効くのが、週1回・3分で読み切れる投稿だ。
社内ポータルやTeamsの全社チャネルで、次のようなフォーマットをテンプレ化すると回り始める。
【タイトル例】
「ChatGPTで“営業マニュアル”を直したくなったときのチェック3つ」
【本文構成】
-
よくあるシーンの一言説明
「新任営業向けマニュアルを、ChatGPTで分かりやすく書き直したくなる場面」 -
NGパターン
「顧客名・契約条件が入ったWordファイルを、そのままアップロード」 -
OKに近づけるポイント
- 顧客名は「A社」「B社」に置き換える
- 金額・条件は具体数値を削る
- 社外秘情報が多い場合は、“使わない判断”も選択肢
投稿のねらいは「禁止」ではなく「条件付きで活用」を繰り返し刷り込むことだ。
国内調査でも、従業員の多くが「便利だが情報漏洩リスクが怖い」と感じている。この“揺れ”に具体的な判断軸を差し込めると、シャドーAIの減少にもつながる。
インシデント未遂を“責めずに共有”する文化づくりのポイント
社員教育で一番効く教材は、自社で起きかけたヒヤリハットだ。
ただし、犯人探しを始めた瞬間、情報は地中深く潜る。設計すべきは「告白しても得しかしない仕組み」だ。
インシデント未遂共有の型を、ざっくり整理すると次の通り。
| 項目 | 押さえるポイント |
|---|---|
| 収集方法 | 匿名フォームや情シス直通メールで「未遂報告」を受付 |
| 公開範囲 | 個人が特定されない形で、部門横断に共有 |
| フィードバック | 「責める」のではなく、「次に迷わないチェックリスト化」 |
共有する際は、技術用語より“行動レベルの学び”に翻訳することが重要だ。
-
悪い例
「クラウドサービスへの機密情報入力による情報漏洩リスクが…」
-
良い例
「顧客名と具体金額を、そのままChatGPTに貼らないようにしよう」
このサイクルが回り始めると、社員教育が「イベント」から“現場の自走メカニズム”に変わる。
ChatGPTの活用と情報漏洩対策を両立させる企業は、例外なくこの「小さな警告の積み上げ」を仕組みとして持っている。
執筆者紹介
主要領域は生成AI利活用と情報セキュリティ。本記事は、「ChatGPT 情報漏洩」の検索意図分析、国内競合5社の比較、Samsung等の公開インシデント、国内調査データを精査し、情シス・DX担当が社内説明に使える実務ロジックとして再構成した執筆者がまとめています。禁止と容認の二択ではなく、シャドーAIを前提にした条件付き容認とガバナンス設計の視点から、現場が今日から使える判断軸とルール設計の型だけを抽出しています。
