Gemini利用ルールの作り方：入力してよい情報・禁止事項を決める方法

なぜ今「Gemini利用ルール」が必要なのか

Geminiは、入力した情報を材料に回答を生成するため、社内情報の扱い方が曖昧なままだと「うっかり漏えい」「誤った出力の拡散」「著作権トラブル」が起きやすくなります。特に情シスや管理部門が「便利だから使っていいよ」と先に許可してしまうと、現場は善意で試したつもりでも、後から監査・取引先確認・法務対応が必要になるケースがあります。

中小企業でも大企業でも、生成AIのルール作りは「技術の話」というより「情報管理と業務運用の話」です。たとえば次のような日常業務でGeminiはすぐ使われます。

• メール文面のたたき台、謝罪文、提案文の整形
• 議事録の要約、タスク整理、ToDo化
• Excelの関数案、手順書の構成、社内FAQの文章化
• RFPや要件定義の整理、ベンダー比較の観点出し

このとき問題になるのは「使う/使わない」ではなく、何を入力してよいか、何を入力してはいけないか、出力をどう扱うかです。ルールが無いと、担当者ごとに判断がブレて、現場は怖くて使えないか、逆に無自覚に危ない使い方をしてしまいます。

本記事では、専門知識がなくても作れるように「入力してよい情報」「禁止事項」「運用の仕組み」まで、Gemini利用ルールの作り方をひとつの完成形として解説します。

まず決めるべき前提：目的・対象範囲・責任者

ルール作りで最初に詰まりやすいのが、細かな禁止事項から書き始めてしまうことです。先に目的・範囲・責任を決めると、後の判断が一気に楽になります。

目的（何のためのルールか）

おすすめは、目的を3つに絞ることです。

• 情報漏えいの防止：顧客・取引先・社内の機密を守る
• 品質事故の防止：誤情報の社外発信、誤った意思決定を避ける
• 現場の生産性向上：安全に使える状態を整え、禁止だらけにしない

「禁止するため」ではなく「安全に使えるようにする」姿勢にすると、現場が協力しやすく、シャドーIT化（勝手に個人アカウントで利用）が減ります。

対象範囲（誰が、どの端末で、何に使うか）

最低限、次を明確にします。

• 対象者：全社員 / 一部部署のみ / 派遣・委託を含むか
• 利用場所：社内端末のみ / BYOD可否 / 在宅の条件
• 用途：文章作成 / コード生成 / データ分析 / 画像生成 など

情シスが把握しやすい単位（部署、業務、システム）で切るのが実務的です。最初から全社一斉でなく、影響が小さい業務から段階導入しても構いません。

責任者（判断・例外承認・更新）

ルールは「作って終わり」ではなく、運用中に必ず例外が出ます。責任者が不明だと、現場が止まります。

• 主管：情シス（運用、権限、ログ）
• 共同：法務/総務（契約・個人情報）、情報セキュリティ、広報（社外発信）
• 現場代表：営業/CS/開発など（実態に合うルールにする）

例外承認の窓口を1つに決めるだけでも、スムーズに回り始めます。

入力してよい情報の決め方：3段階の情報分類で迷いを減らす

Gemini利用ルールの核は「入力ルール」です。ここを複雑にしすぎると守られません。おすすめは情報を3段階に分類し、原則を先に置くことです。

情報分類の例（公開 / 社内 / 機密）

• レベル1：公開情報（入力OK）…自社サイト掲載内容、公開プレスリリース、公開法令、一般的な業界知識など
• レベル2：社内情報（条件付きOK）…社内規程の一般論、業務手順の抽象化、社内用テンプレの構成など
• レベル3：機密情報（入力禁止）…顧客情報、取引条件、未公開財務、ソースコード、認証情報、個人情報、機微情報など

ポイントは「社内情報を全部禁止」にしないことです。たとえば議事録の要約でも、固有名詞を消して「抽象化」すれば十分役に立ちます。入力してよい形に変換する手順をルールに含めると、現場の生産性を落としません。

条件付きOK（レベル2）を成立させる「抽象化」と「置換」

条件付きで入力する場合は、次の加工をセットにします。

• 固有名詞の削除：会社名、製品名、人名、プロジェクト名を「A社」「新製品X」などに置換
• 数値の丸め：売上や単価などをレンジ化（例：120万円→「100万円台」）
• 識別子の除去：顧客ID、注文番号、メールアドレス、電話番号を削除
• 文脈の分離：具体案件の事情を外し「一般的なケース」として相談

「抽象化して使う」文化が根づくと、Geminiは実務でかなり使いやすくなります。逆に、顧客名入りのメールをそのまま貼る、といった使い方が常態化すると事故は時間の問題です。

入力してよい情報の具体例（そのまま使える）

利用シーン別に「OK例」を書いておくと、迷いが減ります。

• 文章：社内向け案内文の言い回し改善（固有名詞なし）
• 企画：一般的な市場動向の整理、競合比較の観点出し（公開情報のみ）
• 管理：規程文の読みやすい要約（条文そのものが公開でない場合は注意）
• 業務改善：手順書の構成案、チェックリスト作成（自社固有の機密を除外）

「入力してよいこと」を具体例で示すのが、ルールの遵守率を上げる最短ルートです。

入力禁止事項の作り方：禁止リストは「カテゴリ＋例」で短く強く

禁止事項は網羅しようとすると長文化します。現場が読みません。そこで「カテゴリで禁止し、例で補う」形にします。Geminiに限らず生成AI全般で共通化できる設計です。

最低限の入力禁止カテゴリ（テンプレ）

• 個人情報：氏名、住所、電話番号、メール、社員番号、履歴書情報、健康情報など
• 顧客・取引先情報：担当者名、契約内容、見積、単価、納期、与信、クレーム詳細など
• 認証・セキュリティ情報：パスワード、APIキー、秘密鍵、VPN設定、脆弱性情報（未公開）など
• 未公開の経営情報：決算見込み、資金繰り、M&A、採用計画、未発表施策
• 知的財産・著作物：第三者の有償資料、ライセンス制限のあるコード、無断転載文章
• 機密性の高い技術情報：ソースコード、設計書、構成図、ログ（個人情報や鍵が混ざりやすい）

「ソースコードは全部禁止」にすると開発部門は困る場合があります。その場合は、社内の閉域環境で動くツールに限定する、あるいはコード片の持ち出し禁止など、別ルールで設計します（本記事の読者像では、まずは禁止でも問題が起きにくいケースが多いです）。

うっかり起きるNG例（現場に刺さる書き方）

• 顧客への返信メール全文を貼り付けて添削（署名・電話番号が混入）
• 障害調査でログを貼り付け（トークンやメールアドレスが混入）
• 見積の妥当性を相談（単価や取引条件がそのまま）
• 人事評価コメントを要約（センシティブ情報を含む）

「意図せず混ざる」ことを前提に禁止例を書いておくと、現場は自分ごと化します。

出力の扱い方（誤情報・著作権・社外発信）まで決める

入力だけ守っても、出力の扱いが曖昧だと事故が起きます。Geminiの出力は便利ですが、常に正しいとは限りません。さらに、他者の文章と似た表現が混ざる可能性もあります。「出力は下書き」ルールを明記するのが基本です。

誤情報対策：確認の責任を人に戻す

ルール文としては次のように書くと分かりやすいです。

• 出力は参考情報であり、最終判断は利用者が行う
• 重要事項（法務、契約、財務、労務、医療等）は一次情報で裏取りする
• 数値・日付・固有名詞は必ず確認する（架空のものが混ざりやすい）

現場向けには「そのまま送らない」「そのまま貼らない」を合言葉にするのが有効です。

著作権・引用：コピペ運用を止める

社外公開コンテンツ（Web記事、提案書、ホワイトペーパー、SNS投稿）にGeminiを使う場合は、次を最低限入れます。

• 第三者の文章を貼り付けて要約・改変する行為は原則禁止（権利・契約次第で例外）
• 引用する場合は、出典を明記し、引用の範囲を必要最小限にする
• 納品物・公開物はコピペではなく、自社の言葉に書き直す

「AIが書いたから大丈夫」ではなく、従来どおり著作権の考え方が適用される、と整理すると通ります。

社外発信フロー：誰がレビューするか

社外発信はレビューを必須にするだけで、炎上や誤発信の確率が下がります。

• 対外メール：上長確認が必要なケース（謝罪、契約、金額、納期）を定義
• 提案書：営業責任者＋法務/情シスの観点チェック（機密混入の有無）
• Web/SNS：広報または編集責任者レビュー（事実確認・表現・権利）

レビューは重くしすぎないことが重要です。「全件法務」は現実的ではないので、リスクの高い類型だけ必須レビューにします。

ルールを形にする：社内で運用できるテンプレ（そのまま流用可）

ここからは、Gemini利用ルールを「文書」として成立させるための部品を紹介します。情シスが通達として出す場合も、各部門の簡易ガイドとして配る場合も、骨格は同じです。

社内ルールの基本構成

• 目的・適用範囲
• 利用可能なアカウント/環境（会社アカウントのみ、個人アカウント禁止など）
• 入力してよい情報・禁止情報
• 出力の扱い（確認、保管、共有、社外発信）
• 禁止行為（無断利用、外部共有、回避行為）
• 違反時の対応（報告先、一次対応、再発防止）
• 問い合わせ窓口・改定履歴

「どこまでOKか」を迷わせないために、利用可能な環境を先に確定させるのがコツです。会社管理のアカウント、端末、ネットワークで使う方が統制しやすく、監査にも耐えます。

短い「現場向けチェックリスト」もセットで配布する

長文ルールは読まれにくいので、A4 1枚のチェックリストを併設します。

• 入力前に：固有名詞/個人情報/契約金額/ID・鍵が入っていないか
• 出力後に：事実確認したか、出典確認が必要か、社外に出すならレビューしたか
• 迷ったら：入力しない／抽象化する／窓口へ相談

現場での実行力は、結局この1枚で決まることが多いです。

プロンプト例：安全に使うための「前置き」テンプレ

Geminiに入力するとき、毎回同じ安全宣言を付けると事故を減らせます。以下は社内展開しやすい例です。

前提：
- これから入力する内容には個人情報・顧客名・契約条件・認証情報は含めません。
- 出力は下書きとして扱い、事実確認を行います。

依頼：
以下の文章を、社内向けに読みやすく要点を3つに整理し、箇条書きにしてください。
（ここに抽象化した文章を貼る）

「入力してはいけないものを入れていない」ことを自分で確認する儀式になるため、うっかりミスが減ります。

導入から定着まで：情シス・管理部門が押さえる運用ポイント

ルールは作って配っただけでは定着しません。特に予算はあるが詳しくない組織ほど、ツール導入で満足して運用が弱くなりがちです。ここでは「揉める前に決めておく」運用ポイントをまとめます。

例外申請と相談窓口を用意する

禁止が多いと現場は回避し始めます。そこで、次を用意します。

• 例外申請：どうしても必要な場合の申請フォーム（目的、入力内容、期間、責任者）
• 相談窓口：Teams/Slackの専用チャンネル＋情シスの担当者

「相談していい」空気があると、シャドー利用が減ります。

教育は30分でよい：事故りやすいポイントだけ教える

全社員研修を長くするより、短時間で刺さる内容にします。

• 入力禁止のトップ5（個人情報、顧客情報、契約、鍵、未公開情報）
• 抽象化・置換のやり方（例を見せる）
• 出力は下書き、社外発信はレビュー

「やってはいけない」だけでなく「こうすれば使える」をセットにすると、利用価値が伝わります。

ログ・監査・端末統制は「できる範囲」で段階的に

理想は統制を強くすることですが、最初から完璧を目指すと頓挫します。段階的に考えます。

• 第1段階：会社アカウント利用、個人アカウント禁止、社外共有禁止
• 第2段階：アクセス制御、利用部門の限定、教育の定期化
• 第3段階：ログレビュー、DLP（情報漏えい対策）検討、データ分類の整備

「現場の摩擦」と「守るべき情報」のバランスを取りつつ、成熟度を上げていくのが現実的です。

よくある失敗と回避策

• 失敗：禁止が多すぎて誰も使わない → 回避：抽象化OKの範囲を明確にし、OK例を増やす
• 失敗：ルールが長すぎて読まれない → 回避：A4 1枚チェックリストを併設
• 失敗：社外発信で誤情報 → 回避：レビュー対象の類型を決め、事実確認の責任を明記
• 失敗：個人アカウント利用が横行 → 回避：会社アカウントの利便性を上げ、相談窓口を作る

ルールは「縛る」ためだけに作ると反発が出ます。安全に使える道を用意することが、結果的に統制になります。

まとめ

Gemini利用ルールを作る際は、細かな禁止事項より先に、目的・対象範囲・責任者を決めるとブレなくなります。そのうえで、入力情報を「公開/社内/機密」の3段階に分け、社内情報は抽象化・置換で安全に使える道を残すのが実務的です。

また、事故の多くは入力ではなく出力の扱い（誤情報、著作権、社外発信）で起きます。「出力は下書き」「重要事項は一次情報で確認」「社外発信はレビュー」という運用ルールを明記してください。

最後に、ルールを読ませる工夫として、A4 1枚のチェックリストと相談窓口を用意し、段階導入で定着させるのが成功の近道です。安全に使える環境を整えれば、Geminiはメール・要約・資料作成など多くの業務で確実に効果を出せます。