ChatGPTを学習させない設定と社内ルールの最新完全安全ガイド

「履歴オフにしているから、うちの会社は大丈夫」
この思い込みが残っている時点で、すでに情報は静かに外へ流れ始めています。

ChatGPTに「学習させない」設定を入れても、社内での使い方が今のままなら、ソースコードも会議の中身も、採用計画も、他社と変わらないリスクに晒されたままです。しかも厄介なのは、多くの現場が次の3つを混同していることです。

• チャット履歴の表示オン/オフ
• モデル改善へのデータ提供オン/オフ
• 無料版／Plus／Team／Enterpriseの違い

この3つを分けて設計しないまま「禁止か解禁か」の議論だけを進めると、結果としてシャドーChatGPT（個人アカウントの裏利用）を増やし、情シスからは何も見えない状態になります。「学習させない」つもりが、「把握できない利用を増やす」という逆効果です。

この記事は、設定画面のスクリーンショット集ではありません。
Samsungのコード流出など実際に起きたパターン、セキュリティ企業のログ分析から見える「グレーゾーン入力」、大学がとっている段階的導入など、公開されている事実だけを材料に、

• どこまでが設定で止められるリスクか
• どこから先は社内ルールと教育でしか防げないのか
• 無料版を完全禁止せずに、現実的にコントロールする線引きはどこか

を、情シスと現場の両方が合意しやすい形に整理します。

読み進めれば、次のような状態を作れるはずです。

• 「履歴オフ＝学習オフ」という誤解を社内から一掃できる
• 無料版とTeam/Enterpriseの違いを、数行で経営陣に説明できる
• 「入力していいもの／絶対ダメなもの」を、1枚のシートとして即配布できる
• 全面禁止ではなく、「見える化してから絞る」運用に切り替えられる

この記事全体で手に入る武器と、解消される課題は次の通りです。

「ChatGPTを学習させない」を、単なるスイッチ操作ではなく、社内で再現できる運用プロセスに落とし込む。そのための設計図として、この先の本文を使い倒してほしい。

「履歴オフにしてるから安全」は危険信号？ “学習させない”前にほどく3つの誤解

「履歴オフにしてるから、うちは大丈夫ですよ」
情シスや現場から、こう返されたら要注意です。Samsungのソースコード流出や、Cyberhaven社の調査で「職場利用8.2％のうち3.1％が機密入力」という数字が出ている今、“なんとなくの安心”が一番危ない状態になっています。

まずほどいておきたい誤解は、この3つです。

履歴オフ＝学習オフだと思い込んでいる現場のリアル

履歴は「あなたの画面に会話を残すかどうか」のスイッチであって、モデル改善（学習利用）のスイッチとは別物です。
にもかかわらず、現場アンケートをすると次のような反応が出やすいです。

• 履歴オフ＝「サーバー側にも残らない」と信じている

• 過去の履歴を削除すれば、学習にも使われなくなると思っている

• モデル改善オフという項目の存在を知らない

この状態で、職務経歴書や取引先名入りのメール文面を貼り付けている人は少なくありません。しかも、WebとスマホアプリでUIが微妙に違うため、「PCは学習オフだけど、スマホはオンのまま」という中途半端なアカウントも生まれがちです。

“学習させない”を徹底したいなら、
履歴オフ→安心ではなく、モデル改善オフの有無をまず棚卸しする必要があります。

「無料版だから危ない」「有料版なら絶対安全」という2つの極端

もう1つ多いのが、「プラン＝安全性」と短絡的に結びつける発想です。

• 無料版：なんとなく怖いから禁止

• Plus：個人の裁量でOK

• Enterprise：導入した瞬間にすべて安心

実際には、リスクの内訳はもっと地味です。

• 無料／Plus

  • デフォルトではモデル改善オン → オフ設定が必須
  • ただし、正しく設定すれば「学習させない」運用は現実的

• Team/Enterprise

  • モデル改善に使わないポリシーが基本
  • それでも「APIキー貼り付け」「契約書PDF丸投げ」といった入力側の事故は防げない

つまり、「どのプランか」より「どう使うか」の設計が勝負です。
プラン比較だけして安心するのではなく、

• 入力禁止情報の線引き

• アカウント管理（共有禁止、多要素認証）

• 利用ログの確認範囲

といった“運用の細部”まで詰めない限り、「有料なのに漏れた」という典型的な後悔パターンに踏み込みます。

禁止か解禁かの二択が、シャドーChatGPTを生む逆説

世界的な調査では、企業の約4分の1が生成AIを全面禁止にしているという報告もあります。ところが、現場のPCログを追うと、次の現象が見えてきます。

• 社内ネットワークからはブロックされている

• それでも、自宅PCや個人スマホからChatGPTを使う社員が一定数いる

• 結果として、「どの部署が何を入力しているのか」が情シスから完全に見えない

禁止で防げるのは「社内からの正面玄関」だけです。
一方で、静かに増えていくのは“シャドーChatGPT”です。

• 上司に相談しづらい若手ほど、こっそり個人アカウントを作る

• 成果物だけは社内に入ってくるが、元のプロンプトは誰も知らない

• 問題が起きた時、「どこから漏れたのか」を逆算できない

本当に守りを固めたいなら、「禁止か解禁か」のスイッチをガチャガチャ動かすよりも、

• まず現状の利用実態をログやアンケートで“見える化”

• 低リスク用途から“条件付きで許可”

• 高リスク用途は代替手段を用意して明確に禁止

という、段階を踏んだコントロールが必要です。
シャドー利用を減らしたいなら、「全部ダメ」ではなく「ここまではOK、その先は要相談」という“グラデーションのある線引き”を見せることが、最初の一歩になります。

ChatGPTに「学習させない」とは何を止めることか――仕組みを3レイヤーで分解する

「学習させない」を1つのスイッチだと考えると、必ずどこかで踏み外します。現場で安全に運用するなら、3レイヤーの仕組みを切り分けて見る必要があります。

履歴保存・モデル改善・ビジネス向けプラン：ごちゃ混ぜになりやすい3つのスイッチ

多くのユーザーが、次の3つを頭の中でごちゃ混ぜにしています。

• 履歴保存（チャット一覧に残すか）

• モデル改善（入力データを学習に使うか）

• ビジネス向けプラン（Team/Enterprise）のデータポリシー

整理するとこうなります。

履歴を削除しても、モデル改善がONなら既に送った入力データが学習に使われる可能性は残る、という点が最大の誤解ポイントです。逆に、モデル改善をオフにしても、履歴をオンにしていれば、端末乗っ取り時には会話内容が丸見えになります。

Team/Enterpriseの「学習に使わない」ポリシーで消えるリスク・残るリスク

ChatGPT Team / Enterpriseは、OpenAIが「モデル改善に顧客データを使わない」と明示しているゾーンです。ここで消えるリスクと残るリスクを分けておきます。

• 消えるリスク

  • ユーザー入力が、パブリック向けモデルの学習データとして再利用されるリスク
  • 将来、不特定多数への回答の中に、自社データが紛れ込むリスク

• 残るリスク

  • アカウント共有やパスワード流出による、社外からの覗き見
  • 端末マルウェアによる画面・キーログの盗み見
  • 社員が入力禁止情報をそのまま入れてしまうヒューマンエラー

Team/Enterpriseは「外側のAIモデルへの拡散」を抑える保険にはなりますが、社内からの“のぞき見”や人間の入力ミスは一切止めない、ここを勘違いしたまま導入すると痛い目を見ます。

モデル改善オフでも防げない“外側”の攻撃面（乗っ取り・プロンプトインジェクションなど）

モデル改善オフは、あくまでクラウド側の再利用停止スイッチです。現場で本当に怖いのは、そこより外側にある攻撃面です。

• アカウント乗っ取り

  • メール使い回し・MFA未設定のアカウントは、突破された瞬間に全履歴と今後の入力が丸裸になります。

• 端末側マルウェア

  • スクリーンショット型マルウェアやキーロガーは、ブラウザやアプリの画面自体を盗み見ます。学習ON/OFFとは無関係です。

• プロンプトインジェクション

  • 研究ベースの報告では、悪意あるWebページを閲覧しただけで、ブラウザ連携中のAIからセッション内の情報が吸い出されるケースが確認されています。

ここまでを一言でまとめるなら、「学習させない設定」は必須のスタートラインであって、ゴールではありません。
だからこそ、設定記事だけで終わらせず、社内ネットワーク制御や端末管理、入力ルールとセットで設計することが、情シスにとっての本番になります。

Samsungのコード流出はなぜ起きたのか？「うっかり入力」が招く典型トラブルを分解する

「便利だから、とりあえず全部突っ込んだ」が数十億クラスの損失リスクに直結したのが、Samsungのソースコード流出事件だ。ここで押さえるべきポイントは、悪意ある内部犯行ではなく、“善意の効率化”がそのまま事故のトリガーになった点にある。

Cyberhaven社の分析では、ナレッジワーカーの8.2％が職場でChatGPTを利用し、そのうち3.1％が機密データを入力していたと報告されている。Samsungは、その「3.1％側」に典型的にハマったケースと見てよい。

バグ相談のつもりが丸ごと貼り付け：開発現場で起きやすいパターン

開発者視点で見ると、やりがちな流れはこうだ。

• エラーが出て原因が分からない

• スタックトレースと問題の関数をChatGPTに貼り付けて質問

• それでうまくいくと、次はクラス全体、最終的にプロジェクト単位のコードを投入

ここで問題になるのは、「どこからが機密コードか」を本人が意識していないことだ。たとえば次のようなフラグが紛れ込んでいても、本人は「ただの定数」としか見ていないケースが多い。

「バグの文脈」と一緒に貼られるコードは、設計思想や依存関係まで丸裸にする設計図だ。モデル改善オプトアウト以前に、「投入する単位を最小化する」「ダミーデータ化する」といった運用ルールがなければ、同様の事故はどの開発部門でも起こり得る。

議事録作成の効率化が、会議の中身まるごとの流出リスクになる理由

Samsungでは、会議録音の文字起こしをそのままChatGPTに投げて議事録を作成したケースも報道されている。ここで見落とされがちなのは、会議データは「全部グレー」であり、DLPが検知しづらい点だ。

• 明示的な個人情報がなくても

• 「来期の値上げ幅」「買収候補の社名」「トラブル中の顧客名」

といった文脈ベースの機密情報が会話に大量に含まれる。

録音テキストは、送信した瞬間に「誰が何をいつ話したか」が1ファイルに集約された、セキュリティ的には最悪に近いデータ構造になる。これを外部AIサービスへ投入すると、たとえモデル改善に使われなくても、アカウント乗っ取りや端末マルウェアの侵入口さえあれば、“会議室の壁一面がガラス張りだった”状態と同じになる。

「使うな」より先に必要だったのは、入力NGラインと承認フロー

Samsungが最終的に取ったのは「利用制限」だったが、多くの企業が同じ轍を踏んでいる。実務的には、禁止より前にやるべきだったことが3つある。

• 入力NGラインの明文化

  • ソースコードのどこまで
  • 会議録のどのレベル
  • 顧客・取引先情報の扱い

• 利用目的ごとの承認フロー

  • 「PoCでの一時利用」
  • 「本番業務での継続利用」

• 利用状況の可視化

  • どの部署が、どの時間帯に、どのドメインへアクセスしているか

この3点がないまま「便利だから試してみて」と現場任せにすると、最初は生産性が跳ね上がり、あとから一気に監査・謝罪・規制強化が押し寄せる。Samsungの事例は、「学習させない設定」以前に、運用設計と教育をサボると何が起きるかを示す実物サンプルになっている。

情シスが一番見落としがちな“グレーゾーン入力”とは何か

「個人情報もソースコードも入れてないから、うちは安全」
そう言い切れる組織ほど、グレーゾーン入力で足をすくわれやすい。

Cyberhaven社が約160万人分の業務ログを分析したところ、ナレッジワーカーの8.2％が職場でChatGPTを利用し、そのうち3.1％が機密データを入力していたと報告されている。この「機密データ」は、必ずしもマイナンバーやクレカ番号だけではない。DLPやフィルタが検知しにくい、“文脈的に危ない情報”が大量に紛れ込んでいる。

個人情報でも極秘情報でもないのに、出ていくと致命傷になるデータ

情シスが制度設計でまず想定するのは、個人情報と機密情報だが、実際にChatGPTへ入力されやすいのはその「一歩手前」の情報だ。

• 取引先名＋担当者の口癖や性格を含むクレームメール草案

• まだ発表していない商品コンセプトや価格帯、販売予定時期

• 社内の評価制度のドラフト、降格候補者の名前を伏せた評価コメント

• M&A検討中の「匿名化したつもりの」候補企業の状況メモ

見た目は「個人名も数字も消してあるメモ」だが、文脈がそろえばその企業ならではの経営戦略や弱点が透けて見える。財布から現金は抜かれていないのに、家計簿だけ丸ごとコピーされているような状態だ。

このグレーゾーンをルールで明示しない限り、ユーザーは「ここまではセーフだろう」と自分基準で線を引く。その“自己判断のばらつき”こそが、漏洩リスクの最大の温床になる。

DLPやフィルタが拾えない「文脈的な機密」のやっかいさ

多くの企業は、次のようなDLP・フィルタ条件をまず設定する。

• 住所・電話番号・メールアドレスなどのパターン検出

• 社名・商品名・顧客名を辞書登録してブロック

• 「機密」「社外秘」ラベル付き文書のアップロード禁止

ところが、実際によく入力される“文脈的な機密”はパターン検出をすり抜ける。

数字や固有名詞を消した会議メモは、DLPから見れば「ただのテキスト」だが、外部に出れば競合に手の内を晒す文書になる。Samsungの事例のように、バグ相談のつもりで貼り付けたコードに、コメントや変数名を通じて企業固有の情報が含まれていたケースは典型だ。

「何を入れたらアウトか」を“文字種”ではなく“文脈”で説明することが、グレーゾーン対策の第一歩になる。

ログを取って初めて見える“誰がどこから何を投げているか”の現実

グレーゾーン入力の厄介さは、発生していること自体が見えにくい点にある。禁止か許可かの議論より前に、まず「現実に何が起きているか」を可視化する必要がある。

情シスが最低限押さえたいログの視点は次の通り。

• どのネットワーク（社内／社外VPN／自宅Wi-Fi）からChatGPTへアクセスしているか

• どの時間帯・どの部署のトラフィックが多いか

• 1回あたりの送信文字数が極端に多いユーザーがいないか（丸ごとコピペの兆候）

• ChatGPT以外に、GeminiやCopilotなど別クラウドAIへのアクセスも増えていないか

TeamやEnterpriseであれば、管理コンソール側である程度の利用状況を把握できる。一方、無料版や個人アカウントのシャドー利用は、プロキシログやエンドポイント管理ツール（LANSCOPEなど）を組み合わせないと見えてこない。

ログを取り始めると、多くの組織で次の“現実”が露わになる。

• 利用禁止の通達後も、深夜や自宅IPからのアクセスが残っている

• 想定外の部署（法務・人事・経理）が、長文テキストを頻繁に送信している

• 「生成AI活用プロジェクト」より、現場の個人利用の方が圧倒的にトラフィックが多い

このギャップを把握せずに「学習させない設定をしたから大丈夫」と考えると、グレーゾーン入力は水面下で増え続ける。設定だけで完結させず、ログ→実態把握→ルール修正→再教育のループを回せるかどうかが、ChatGPT時代の情シスの腕の見せ所になる。

「全部禁止」は本当に守りになるのか？ シャドーChatGPTが生まれる組織の条件

「ChatGPTは社内全面禁止」。紙では強そうに見えるこのルールが、現場では“抜け道づくりマシン”になっているケースが多い。情シスが把握していない個人アカウントのAI利用こそ、本当の漏洩リスクの温床だ。

VPNの外で静かに動く“個人アカウントChatGPT”の実態

企業ネットワークからはアクセス制限、しかし従業員のポケットにはスマホと自宅PC。Cyberhavenの分析では、ナレッジワーカーの8.2%が職場でChatGPTを利用し、その3.1%が機密データを入力していたとされる。禁止しても、「昼休みに個人アカウントでちょっとだけ」という利用は簡単に始まる。

こうした“シャドーChatGPT”が起きやすい条件は決まっている。

• 無料版とTeam/Enterpriseの違いを説明していない

• 入力NG情報の具体例が社内に配布されていない

• VPN外や私物端末でのAI利用をログで一切追えていない

結果として、「どこで何が起きているか分からない状態」で、情報だけが静かにクラウドへ流れていく。

「禁止したら終わり」運用と、「見える化してから絞る」運用の決定的な差

セキュリティベンダーの現場では、禁止運用と見える化運用で、インシデント発見の質がまるで違うことが見えている。

禁止で終わらせる組織は、「使ってはいけない」という抽象ルールだけを投げて、実際の入力データやログを一切見ていない。逆に、LANSCOPEのように利用状況を可視化してから対策をかけるアプローチでは、

• どの部署がChatGPTを多用しているか

• どの時間帯に大量コピペが発生しているか

• 海外拠点やリモート環境からのアクセス傾向

といった“生の運用データ”が見える。ここまで把握して初めて、「この範囲は許可、ここはTeam/Enterprise強制」といった精度の高い制限が設計できる。

情報漏洩インシデントの多くが「ルール違反」ではなく「ルール空白」で起きる理由

Samsungのソースコード流出も、「禁止を破った悪意ある従業員」というより、“グレーゾーンのまま放置された業務フロー”が原因に近い。バグを直したい開発者にとっては、「少し貼れば回答精度が上がる便利なツール」にしか見えない。

現場でよく聞くパターンは共通している。

• 「顧客名はNGだが、社名だけなら良いのか分からない」

• 「議事録の要約はOKと言われたが、会議の中身の線引きが曖昧」

• 「無料版は危険という話は聞いたが、どこまでが危険か不明」

これはサボりではなく、ルール設計側が“グレーの具体例”を提示していないことが問題だ。Cisco調査で約27%の企業が生成AIを全面禁止している一方、禁止だけではシャドー利用を防げないという指摘が増えているのも同じ構造だと考えた方がいい。

「chatgpt 学習させない」を本気で目指すなら、やるべき順番は逆転する。

1. 現状の利用と入力データをログで見える化する
2. グレーゾーンの具体例を洗い出し、利用ガイドラインに落とす
3. その上で、禁止領域とTeam/Enterprise強制領域を明確に区切る

全面禁止は“最終手段”であって“最初の一手”ではない。見える化と設計をサボったまま禁止だけ宣言しても、VPNの外側で回り続ける個人アカウントのChatGPTを止めることはできない。

大学・教育機関のやり方に学ぶ：ゼロにもフル解禁にも振らない“段階的導入”の設計図

「禁止でもフル解禁でもない、第3の道」を一番うまく歩き始めているのが大学だ。学生という“暴れ馬”を相手にしながらも、レポートの質もセキュリティも両立させようとすると、感覚ではなく設計が必須になる。

まずは学習オフ＋入力禁止例の周知から始めたケース

東京経済大学などの事例では、最初の一手をシンプルに絞っている。

• ChatGPTのモデル改善（学習）をオフにする手順を公式マニュアルで提示

• そのうえで「入力禁止情報」を具体例つきで列挙

• 利用自体は許可しつつ、「ここから先は赤信号」と線を引く

典型的な禁止例は次のような整理になる。

ポイントは、「抽象的なNGワード」ではなく、学生や教職員の日常業務に即した入力例ベースで示すこと。読む人が「自分が昨日投げたテキスト」を即座に連想できるレベルまで落とし込むと、守られやすくなる。

レポート・課題でのChatGPT利用を“バレない不正”にしないルールの作り方

大学が一番警戒しているのは、ChatGPTが“カンニングマシン化”することだ。実務寄りに設計しているところほど、次の3本柱を明文化している。

• 利用範囲の宣言義務

  「構想段階のブレストには利用可」「本文生成は参考まで。最終文章は自分でリライト」など、用途を分解して許可・禁止を分ける。

• 出力の開示ルール

  「ChatGPTの回答を引用した場合は、プロンプトと日付をレポート末尾に添付」といった形で、“隠させない”設計にする。

• 評価軸の変更

  完成文章の出来だけを見るのではなく、プロンプトの工夫や考察プロセスを評価項目に入れる。AIを使った方が、むしろ思考の深さを問われる構造にする。

これにより、「こっそり丸投げした方が得」というインセンティブを潰し、「うまく使った方が成績も伸びる」にひっくり返せる。

画面キャプチャ主体マニュアルがすぐ陳腐化する問題と、その回避策

教育機関の現場からよく出る悲鳴が、「せっかく作ったスクリーンショット付きマニュアルが、数カ月で全部使い物にならなくなる」というものだ。UI変更が激しいクラウドサービスでは、画像頼みの運用は必ず詰む。

そこで、更新が追いついている大学ほど、マニュアルを“画面の説明書”から“スイッチの意味の説明書”に寄せている。

• 「どのボタンを押すか」ではなく「この設定がオンだと、どこまでデータが保存・学習に使われるか」をテキストで説明

• 画面名や文言が変わっても通用するように、レイヤー構造で整理

  例：

  1. アカウント共通設定（データ管理・プライバシー）
  2. チャット単位設定（履歴オン/オフ）
  3. プラン単位ポリシー（無料/Plus/Team/Enterprise）

さらに、キャプチャは「参考」として最小限に絞り、毎年のシラバス改訂タイミングで差し替える前提にする。重要なのは、学生や教職員がUI変更に振り回されず、“設定の意味”で判断できる状態まで育てることだ。

この発想は企業にもそのまま転用できる。情シスが作るべきなのは“ボタンの場所マニュアル”ではなく、「このスイッチを上げると、どこまで社外に出るか」を一枚で説明する“データの蛇口マップ”だ。

「学習させない設定だけ」では終わらせない：現場で回るチェックリストと教育ネタ

「モデル改善オフにしたからもう安全」と言い切れる情シスは危ないゾーンに足を踏み入れている。現場で本当に効くのは、設定よりも“何を投げていいかを迷わない仕組み”と“一度見たら忘れない教育ネタ”だ。

情シスが最初に配布すべき「入力していいもの／絶対ダメなもの」シート

最初に配るべきは長い利用ガイドラインではなく、A4一枚の一覧表だと現場で痛感している。ポイントは「法令用語」ではなく「業務での具体名」で書くこと。

この表を基準に、社内向けには次のような3ステップチェックリストとして配布すると迷いが激減する。

• ステップ1: その情報は「社外の誰に見られても困らない」か

• ステップ2: 顧客名・個人名・メールアドレス・住所・電話番号が含まれていないか

• ステップ3: 「これが明日の朝ニュースサイトに載っても耐えられるか」を10秒で想像する

この3つのうち1つでも怪しければ、ChatGPTや他のAIサービスへの入力はストップさせる運用にする。システムの制限ではなく判断の型を共有することが目的だ。

社内研修で必ず見せたい“やってはいけない質問例”コレクション

抽象論の研修は眠気を誘うだけなので、「これはアウト」なプロンプト例を画面に映す方がはるかに効く。実務で頻発するのは次の3パターンだ。

• 開発・IT系

  • 「このバグを直して」と言いながら、リポジトリからコピペしたソースコードを数百行ペースト
  • 「本番環境のDB接続情報はこれです。セキュアな設定案を」など、認証情報入りのプロンプト

• 営業・企画系

  • 「A社・B社・C社との個別契約内容を要約して」と3社分の契約書をそのまま貼る
  • 「来月発表予定の新サービスの企画書をブラッシュアップして」と未公開資料を投入

• 人事・管理部門

  • 「この社員の評価コメントを書き直して」と、名前や部署入りの評価シートを貼る
  • 「この退職予定者リストを分析して離職防止策を」と、個人情報フルセットを投入

研修では、これらのプロンプトをあえて赤字で「NG」ラベル付きで見せ、次に参加者に「どう書き換えれば安全か」をペアワークで考えさせる。
たとえば「未発表企画書そのもの」ではなく「要素を抽象化した箇条書き」に変えてから投げる、顧客名を「A社」「B社」に変える、といった“安全な書き換えスキル”を身につけさせるのが狙いだ。

Team/Enterprise導入後にやり直しになりがちな“雑なガイドライン”の共通点

ChatGPT TeamやEnterpriseを導入した後、半年でガイドライン総入れ替えになる組織には共通点がある。どれも「ツール前提で書いて、人前提で書いていない」ことだ。

• 「モデル改善にデータを使わないから安全」とだけ書いている

  • 外部への学習オプトアウトに触れる一方で、端末乗っ取りやアカウント共有など社内側のリスクが抜けている

• 「Teamアカウント以外は禁止」と書いて終わっている

  • 個人アカウントや他サービスの生成AI、CopilotやGeminiなど周辺ツールの扱いが空白になり、シャドーAI利用を招く

• 「機密情報は禁止」とだけ書いている

  • 機密の定義がふわっとしており、「どの画面・どのファイルが禁止か」が具体的にイメージできない

ガイドラインを作り直す際は、少なくとも次の3ブロックで構成すると破綻しにくい。

1. 利用範囲の宣言

   • 利用してよいサービス（ChatGPT Team、Enterprise、社内専用AIなど）
   • 利用禁止のサービス（個人アカウントの無料版、非承認の外部AIなど）

2. 入力データのランク分けと例示

   • ランクA: 絶対入力禁止（顧客データ、機密コード、人事情報など）
   • ランクB: 匿名化すれば入力可
   • ランクC: 制限なく利用可（公開情報、社内外で既に共有済み資料）

3. 監査・教育の回し方

   • ログの取得・確認方法
   • 年1回のリテラシー研修で扱う「最新のやらかし例」更新ルール

「学習させない設定」はスタートラインにすぎない。設定を土台に、現場の迷いを減らすシートと“ゾッとするNG例”の共有まで落とし込んだ組織だけが、AI活用とセキュリティの両立ゾーンに入っていける。

ケーススタディで読み解く：中小企業・大企業・大学、それぞれの最適解

同じ「chatGPTに学習させない」でも、従業員100名の会社と数千名のグループ企業、大学では、正解の設計図がまったく違います。現場で実際に相談がくるパターンごとに、現実的な落としどころを整理します。

従業員100名規模：無料版とどう距離を取るか、現実的な落としどころ

予算も情シスの人数も限られる100名規模で「ChatGPTを完全に管理する」は現実的ではありません。狙うのは“致命傷だけ避ける”ミニマム設計です。

まず決めるのは次の3点です。

• 無料版の利用可否（業務利用は「禁止」に寄せるか「条件付き許可」にするか）

• 入力NG情報の具体例

• 代替手段（どうしても使いたい部署向けの選択肢）

特に効果が出やすいのがA4一枚の「入力していいもの／絶対ダメなもの」シートです。

• 入力OK例：一般公開済みの商品説明、汎用的なビジネス文章のテンプレ作成

• 入力NG例：顧客名入りの文書、見積金額、ソースコード、契約書ドラフト

このレベルでも、「履歴オフ＝学習オフではない」「無料版はデフォルトでモデル改善に使われる」という基本を押さえるだけで、漏洩リスクはかなり削れます。

数千名規模：部署ごとの温度差を潰しながら、ビジネス向けプランに寄せていく道筋

数千名規模になると、「ChatGPT禁止」を掲げても、実態としてシャドーChatGPTが必ず動きます。Cyberhaven社の分析では、ナレッジワーカーの約8.2%が職場でChatGPTを利用し、その一部が機密データを入力していると報告されています。

ここで効くのは「禁止→黙認→事故」の三段跳びを避ける段階的導入です。

• 第1段階：利用実態の可視化

  • プロキシやエンドポイント管理ツールで、どの部署からChatGPTや他の生成AI（Gemini、Copilotなど）にアクセスしているか把握

• 第2段階：安全ゾーンの提示

  • ChatGPT Team/Enterpriseなど、モデル改善にデータを使わないプランを正式な“安全レーン”として提示

• 第3段階：グレーゾーン潰し

  • 開発部門のソースコード、営業部門の顧客リストなど、「DLPが拾いにくい文脈的な機密」を例示し、入力禁止を徹底

最終的には、「回答精度を落とさず、入力データは学習させない」ビジネス向けプランへの集約を目指しつつ、禁止ではなく“安全な選択肢への誘導”でシャドー利用を減らしていくのが現実的です。

大学・専門学校：学生の暴走を防ぎつつ、学びを止めないための線引き

教育機関は「情報漏洩」と同じくらい、「学習そのものが崩れるリスク」を気にします。東京経済大学のように、まずはモデル改善オフの手順をスクリーンショット付きで配布するケースが典型です。

ポイントは3本柱に整理できます。

• プライバシー保護

  • 学籍番号や氏名、成績情報をChatGPT等に入力しないルール
  • Web版・アプリ版のモデル改善オフ設定マニュアルを学生向けポータルに掲載

• 学習評価の公平性

  • レポートやレジュメ作成でのAI利用を「全面禁止」ではなく、「利用時は明記」「ドラフトまで可、本番は自分で修正」など段階的に許容

• 教育コンテンツ化

  • “ChatGPTに丸投げしたレポート例”と、“AIを下書きに使い自分で肉付けした例”を見比べるワークを授業で実施

画面キャプチャだけのマニュアルはUI変更で陳腐化しやすいため、「右上の自分のアイコン→Settings→Data controls→モデル改善をオフ」のように、画面遷移を文章でも記載しておくと、改訂コストを抑えながら最新状態を維持できます。

この線引きを丁寧にやっておくと、学生の“暴走入力”を抑えつつ、「AI時代に必要な情報リテラシー教育」という本来の目的にもつながります。

それでもChatGPTを“攻めて使いたい”組織が踏むべき最後の一手

「守りきれないから使わない」から「漏れない前提で設計する」への発想転換

情報システム担当が本当に握るべきスイッチは、「禁止／許可」ではなく設計だ。
Samsungのコード流出も、全面禁止企業のシャドーAI化も、本質は同じで、「入力ルールと環境設計をサボったツケ」が爆発しただけだ。

攻めて活用する組織が最初に変えるべきは、次の視点だ。

• 「ユーザーはうっかり機密を投げる前提」でルールを作る

• 「学習させない設定＋技術対策＋教育」を3点セットで設計する

• 「禁止」ではなく、「この環境ならここまでOK」を具体的に示す

禁止はブレーキだが、設計はガードレールだ。ガードレールを敷いたうえでアクセルを踏める状態を、ChatGPTや他の生成AIサービスにも作るイメージに切り替える。

API・ローカルLLM・社内専用環境…どこまで行けば“外に出さない”と言えるのか

「どこまで閉じれば安心か」は、利用目的と予算次第で変わる。代表的な選択肢を、リスクと現実解で整理するとこうなる。

「外に出さない」に最も近いのはローカルLLMだが、回答精度・運用コストが重くのしかかる。
多くの企業にとって現実的なのは、

1. ChatGPT Team/Enterpriseや同等のビジネス向けプランで「学習に使わない」環境を確保
2. API経由で、入力データをマスキング・フィルタしてから送る

というクラウド前提の“漏れにくい設計”だ。

1年後に後悔しないための、「今、最低限やっておくべき3アクション」

1年後、「あの時きちんとやっておけば…」を避けるために、規模を問わず今すぐ着手できるのはこの3つだ。

1. 入力NG一覧をA4一枚に落とす
   個人情報、顧客名、未公開の企画書、ソースコードなど、具体例付きで「投げたらアウト」を明文化する。
   情シス用ではなく、現場の言葉で書くことがポイント。

2. 利用環境を“見える化”する
   プロキシやエンドポイント管理ツールで、誰がどの生成AIサービスへアクセスしているかを把握する。
   CiscoやCyberhavenの調査が示す通り、「8.2%が職場で利用し、3.1%が機密を投入」という現実を他人事と見ない。

3. ビジネス向けプラン/APIへの移行ロードマップを作る
   すぐにEnterpriseを契約できなくても、

   • どの部門からTeam/Enterpriseを試すか
   • どの業務プロセスにAPI組込みを検討するか
     を3〜6カ月スパンで決めておく。

守り切れないからChatGPTを封印する時代は、もう終わっている。
「漏れない前提で設計する」組織だけが、AI活用の効率とセキュリティの両方を取りにいける。

執筆者紹介

本記事の執筆者は、［主要領域例：情報システム／セキュリティ設計／生成AI運用ポリシー策定］を専門とし、これまでに［実績数値例：○社以上のガイドライン策定・研修支援］を担当してきました。現場の「禁止か解禁か」の二択を避け、設定・ルール・教育を一体で設計する実務支援を特徴としています。