生成AIを会社で使いたい。
でも、情報漏洩がこわい。
だから、社内ルールを作らないといけない気がする。
この相談は、これから中小企業や小規模事業者でもかなり増えると思っています。
業務で使えるAIはどんどん増えています。
文章を書ける。
議事録を要約できる。
問い合わせ返信の下書きを作れる。
Excelの見方を整理できる。
コードも直せる。
便利です。
めちゃくちゃ便利です。
でも、便利だからこそ怖いんですよね。
お客様の名前を入れていいのか。
見積書を貼っていいのか。
社内の議事録を要約させていいのか。
問い合わせ内容をそのまま入れていいのか。
外部公開する文章をAIに作らせていいのか。
ここが曖昧なまま使うと、現場では2つのことが起きます。
1つは、怖くなって誰も使わない。
もう1つは、便利だからこっそり使う。
どちらも、あまり良い状態ではありません。
禁止だけだと、使える人ほど隠れて使います。
解禁だけだと、何を入れてよいか分からないまま使います。
だから僕は、生成AIの社内ルールは「禁止事項」から作り始めない方がいいと思っています。
最初に決めるべきなのは、入力してよい情報の線引きです。
前回の Codexに入れた情報はどこから漏れるのか では、AIに入れた情報がどこから漏れる可能性があるのかを書きました。
今回はその続きとして、では小さな会社が生成AIを使うとき、どんな社内ルールから作ればいいのかを整理します。
難しい規程を作る話ではありません。
明日から現場で迷わないための、最初の実務ルールです。
生成AIの社内ルールは、「使うな」ではなく「何を、どこまで、誰が確認して使うか」を決めるもの。
ここを先に決めると、AI活用は怖いものではなく、社内で育てられる仕組みになります。
生成AIの社内ルールは、禁止事項より利用場面から決める
社内ルールを作ろうとすると、最初にやりがちなのが禁止リストです。
個人情報を入れてはいけない。
機密情報を入れてはいけない。
契約書を入れてはいけない。
顧客情報を入れてはいけない。
未公開情報を入れてはいけない。
もちろん、これは大事です。
でも、禁止事項だけを並べると、現場ではこうなります。
「じゃあ、何なら使っていいんですか？」
ここで止まります。
そして、だいたい使われなくなります。
いや、気持ちは分かります。
禁止リストって、作った瞬間にちゃんと仕事した感じが出るんですよね。
でも、実務で大事なのは、禁止そのものではなく判断できることです。
たとえば、ブログの構成案を作る。
問い合わせ返信の言い回しを整える。
社内マニュアルのたたき台を作る。
会議メモを要約する。
営業資料の流れを確認する。
こういう使い方は、入力する情報を整えればかなり現実的です。
逆に、顧客名、契約条件、個人情報、未公開の売上、APIキー、パスワード、医療や法律の専門判断をそのまま入れるのは危険です。
つまり、同じ「AIを使う」でも、使う場面によってリスクはぜんぜん違います。
最初の社内ルールでは、次の3つだけ決めると始めやすいです。
1つ目は、どの業務で使ってよいか。
2つ目は、どの情報を入れてよいか。
3つ目は、出力を誰が確認して使うか。
この3つです。
総務省・経済産業省のAI事業者ガイドラインでも、AIを開発する側、提供する側、利用する側に分けて、それぞれが取り組む事項が整理されています。
ただ、小さな会社が最初から分厚いガイドラインを読み込んで、完璧な規程を作るのはなかなか大変です。
だからこそ、まず自社の業務に落とします。
うちでは、AIを何に使うのか。
そこに、どんな情報が入るのか。
間違ったとき、誰が気づくのか。
この順番で考える方が、ルールは生きたものになります。
中小企業の生成AI導入は、ツール選びより最初の業務テーマから考える でも書きましたが、AI導入の最初はツール名ではなく業務テーマです。
セキュリティルールも同じです。
どの業務で使うかが決まるから、守るべき情報も決まります。
入力情報は「入れていい・確認して入れる・入れない」に分ける
生成AIの社内ルールでいちばん最初に作りたいのは、入力情報の区分です。
難しい言葉で「情報分類」と呼んでもいいのですが、最初はもっとシンプルで十分です。
僕なら、まず3つに分けます。
入れていい情報。
確認してから入れる情報。
入れない情報。
この3つです。
入れていい情報は、すでに公開されている情報や、個人や取引先を特定できない情報です。
たとえば、自社ホームページに掲載済みのサービス説明。
公開済みのブログ記事。
一般的な業界情報。
個人名や会社名を抜いた相談パターン。
架空のサンプルデータ。
こういうものは、比較的使いやすいです。
もちろん、出力の正確性チェックは必要です。
でも、入力しただけで大事故につながる可能性は低い。
次に、確認してから入れる情報です。
ここがいちばん大事です。
たとえば、会議メモ。
問い合わせ内容。
提案書の下書き。
見積もりのたたき台。
社内マニュアル。
お客様の課題メモ。
これらは、AIに入れると便利です。
ただし、そのまま入れると危ないことがあります。
お客様の名前。
担当者名。
メールアドレス。
電話番号。
具体的な金額。
契約条件。
未公開のサービス内容。
こういう情報が混ざっているからです。
だから、確認してから入れる情報では、先にマスキングします。
会社名は「A社」。
担当者名は「担当者」。
金額は「数十万円」。
日付は「来月上旬」。
具体的な商品名は「対象サービス」。
このくらいに置き換えるだけでも、リスクはかなり下がります。
最後に、入れない情報です。
これは明確にしておいた方がいいです。
顧客の個人情報。
本人の同意や利用目的の確認がない個人データ。
営業秘密。
未公開の財務情報。
契約書の全文。
APIキー、パスワード、アクセストークン。
本番環境の設定ファイル。
人事評価や健康情報。
医療、法律、税務などの専門判断を含む情報。
ここは「迷ったら入れない」にしておく方が安全です。
個人情報保護委員会も、生成AIサービスに個人情報を含むプロンプトを入力する場合は、利用目的の範囲や、サービス提供者側で機械学習に利用されないこと等を十分確認するよう注意喚起しています。
つまり、「AIに入れる情報」は、ただのメモではありません。
社外サービスに渡す可能性がある情報です。
だから、最初のルールはこうでいいと思います。
公開済みの情報は使ってよい。
社内情報は、個人名・会社名・金額・契約条件を外してから使う。
個人情報、営業秘密、認証情報は入れない。
完璧な情報セキュリティ規程を作る前に、この3行を現場に配る。
まずはそこからで十分です。
無料版・個人アカウント・会社アカウントで扱う情報を変える
生成AIの社内利用で、意外と見落とされやすいのがアカウントの違いです。
個人の無料アカウントで使っているのか。
個人の有料アカウントで使っているのか。
会社で契約したビジネス向けワークスペースで使っているのか。
APIで自社システムから使っているのか。
ここで、データの扱い、管理者設定、ログ、保持期間、学習利用の扱いが変わることがあります。
OpenAIの場合、ChatGPT Business、ChatGPT Enterprise、API Platformなどのビジネス向け利用では、ビジネスデータを標準ではモデル学習に使わないと説明されています。
一方で、個人向けChatGPTでは、データコントロール設定や利用状況によって扱いを確認する必要があります。
もちろん、これはOpenAIに限りません。
どのAIサービスでも、利用規約、プライバシーポリシー、管理者設定、連携機能、保存期間を確認する必要があります。
ここで大事なのは、「有名なAIだから安全」と思わないことです。
同じサービス名でも、プランや設定で扱える情報は変わります。
そして、AIツールは単体では終わらなくなっています。
ブラウザを操作できるAI。
Google DriveやGmailにつながるAI。
GitHubやローカルフォルダを読めるAI。
社内ナレッジを検索できるAI。
こういう連携が増えるほど、AIが見える情報の範囲は広がります。
IPAの「AI利用者のためのセキュリティ豆知識」でも、クラウドAIに営業秘密を教えないこと、AIブラウザを社内用と社外用で分けること、RAGでは情報を混ぜないことなどが、利用者向けの対策として挙げられています。
これはかなり実務的です。
たとえば、社内システムへログインしたブラウザと、外部サイト調査に使うAIブラウザが同じだとします。
AIがページ内容を読める状態で操作しているなら、意図せず社内情報がAIの文脈に入る可能性があります。
Google Drive連携も同じです。
便利だから全部つなぐ。
これは危ないです。
最初は、AIに見せるフォルダを限定する。
社外秘フォルダは連携しない。
個人アカウントでは顧客情報を扱わない。
会社アカウントで使うツールを決める。
このくらいの線引きからでいいです。
生成AIの社内ルールでは、「何を入力してよいか」だけでなく、「どのアカウントで、どこまで見える状態で使うか」も決めておく必要があります。
AIは、貼り付けた文字だけを見る時代から、ファイル、ブラウザ、リポジトリ、クラウドストレージまで見に行く時代になっています。
だから、アカウントと連携範囲は、立派なセキュリティ設定です。
出力をそのまま使わず、公開前チェックを業務に入れる
生成AIのリスクは、入力だけではありません。
出力にもあります。
AIが作った文章。
AIが要約した議事録。
AIが直したコード。
AIが作ったFAQ。
AIが作った提案資料。
これらを、そのまま外に出すと危ないことがあります。
内容が間違っている。
古い情報が混ざっている。
断定しすぎている。
お客様に見せてはいけない社内事情が残っている。
著作権や商標の確認が必要な表現がある。
コードにセキュリティ上の問題がある。
個人名や会社名が残っている。
AIは、文章を自然に整えるのが得意です。
でも、自然に見えることと、正しいことは別です。
ここ、ほんとに罠です。
それっぽい文章ほど、通ってしまう。
だから、社内ルールでは「AIの出力を誰がどう確認するか」を決めておく必要があります。
僕なら、公開前チェックを3つに分けます。
1つ目は、事実チェックです。
数字、日付、料金、固有名詞、制度、引用元、サービス仕様。
ここは人が確認します。
2つ目は、情報管理チェックです。
個人名、会社名、メールアドレス、電話番号、契約条件、社外秘の事情が残っていないか。
ここも人が見ます。
3つ目は、責任チェックです。
そのまま公開してよい内容か。
お客様へ送ってよい表現か。
専門家確認が必要な内容ではないか。
自社の言葉として言い切れるか。
ここを確認します。
特に、ホームページ、ブログ、メール、提案書、FAQ、採用文、契約まわりの文章は、AIの出力をそのまま使わない方がいいです。
下書きとして使う。
人が直す。
公開前に見る。
この流れを業務に入れる。
それだけで、かなり安全になります。
開発支援AIを使う場合も同じです。
コードを直してもらったら、差分を見る。
秘密情報が入っていないか確認する。
テストを走らせる。
git status を見る。
不要なファイルが増えていないか確認する。
本番反映前にレビューする。
AIが作業してくれるほど、人の確認ポイントは大事になります。
AIに任せる範囲を広げるなら、人間の確認もセットで設計する。
これが、現実的なセキュリティ対策だと思います。
ルールはPDFより、いつもの依頼文とチェックリストに落とす
生成AIの社内ルールを作ると聞くと、きれいなPDFを作りたくなります。
目的。
適用範囲。
禁止事項。
責任者。
違反時の対応。
もちろん、会社の規模や業種によっては必要です。
でも、小さな会社の最初の一歩としては、PDFよりも日常の使い方に入る形の方が効きます。
つまり、依頼文とチェックリストです。
たとえば、AIへ文章を依頼する前に、こういう型を用意しておきます。
目的：
この文章は、社内確認用の下書きです。
入力情報：
個人名、会社名、メールアドレス、金額、契約条件は削除済みです。
依頼：
以下の内容を、読みやすいメール文に整えてください。
事実を追加せず、分からない点は「確認が必要」と書いてください。
確認：
出力後、人が事実・表現・情報漏洩の有無を確認してから使用します。これだけでも、使い方はかなり変わります。
AIに何をさせるのか。
何をしてはいけないのか。
人がどこを見るのか。
それが依頼文の中に入るからです。
チェックリストも、最初は短くていいです。
AIに入れる前のチェック。
- 個人名や会社名を外したか。
- 顧客情報や契約条件を入れていないか。
- APIキー、パスワード、認証情報が含まれていないか。
- このツールに入れてよい情報か。
AIの出力を使う前のチェック。
- 数字、日付、固有名詞は確認したか。
- 社外秘や個人情報が残っていないか。
- 専門家判断が必要な内容を断定していないか。
- 自社の言葉として公開してよいか。
このくらいで十分です。
大事なのは、現場が使えることです。
読み込まないPDFを作るより、毎回の依頼文に入るルールの方が強い。
誰かが社内チャットに貼れるチェックリストの方が強い。
テンプレートとして残る依頼文の方が、教育にもなります。
生成AIの社内ルールは、完成した文書ではなく、毎日の使い方に入って初めて機能します。
だから、最初から立派な規程を目指さなくていいです。
まずは、3つの入力区分。
会社で使うAIアカウント。
公開前チェック。
よく使う依頼文。
この4つを整えるだけで、AI活用はかなり落ち着きます。
最初の30日は、小さく使ってログと相談先を残す
社内ルールは、一度作って終わりではありません。
むしろ、最初から完璧にしようとしない方がいいです。
AIツールは変わります。
機能も増えます。
連携先も増えます。
社内での使われ方も、実際に始めてみないと分かりません。
だから、最初の30日は試運用にするのがおすすめです。
対象業務は、1つから3つに絞る。
たとえば、ブログ構成案。
問い合わせ返信の下書き。
社内マニュアルの整形。
このくらいです。
そのうえで、使った記録を軽く残します。
使った日。
使ったAIツール。
使った業務。
入力した情報の種類。
出力をどこで使ったか。
困ったこと。
ヒヤッとしたこと。
次に直したいこと。
これをスプレッドシートやNotion、社内メモに残すだけで十分です。
ログというと大げさに聞こえますが、最初は「使いながらルールを直すためのメモ」でいいです。
30日たつと、だいたい見えてきます。
この業務は使いやすい。
この情報は毎回マスキングが必要。
このツールは個人アカウントでは不安。
この出力は確認に時間がかかる。
この依頼文はうまくいく。
このあたりが見えてきます。
そこからルールを直せばいいです。
最初から100点の社内ルールを作ろうとすると、重くなります。
でも、ルールなしで使い始めると、怖くなります。
だから、30日だけ小さく使う。
使った記録を残す。
週1回だけ見直す。
迷ったときの相談先を決める。
このくらいが、現場にちょうどいいです。
相談先は、必ずしも情報システム部門でなくてもかまいません。
小さな会社なら、代表、管理担当、AI担当、外部パートナーでもいい。
大事なのは、「これ、AIに入れていいですか？」と聞ける場所があることです。
迷った人がひとりで判断しなくていい状態を作る。
これが、社内ルールの本当の役割です。
生成AIは、使わなければ安全というものでもありません。
使わないままだと、業務改善のチャンスを逃します。
でも、何でも入れていいわけでもありません。
だから、禁止か解禁かの二択にしない。
入力していい情報を決める。
確認が必要な情報を決める。
入れない情報を決める。
使うアカウントを決める。
出力の確認方法を決める。
最初の30日で見直す。
この順番で十分です。
カタチ舎の AI内製化パートナー でも、ツールの導入だけでなく、業務棚卸し、入力情報の整理、依頼文テンプレート、公開前チェック、社内で続ける運用づくりまで一緒に設計しています。
AIを怖がりすぎず、でも雑に扱わない。
この真ん中の道を作るのが、これからの小さな会社に必要なAI活用だと思っています。
「うちでは何をAIに入れていいのか」
そこから一緒に整理したい方は、お問い合わせ から気軽に相談してください。
参考情報
- 総務省・経済産業省：AI事業者ガイドライン第1.2版
- IPA：AI利用者のためのセキュリティ豆知識
- 個人情報保護委員会：生成AIサービスの利用に関する注意喚起等
- OpenAI Enterprise privacy
- OpenAI Data Controls FAQ
Author
村上龍平
カタチ舎代表。言葉、生成AI活用、資料・Web制作を行き来しながら、事業の考えを届く形へ整理しています。