生成AI利用ガイドラインのテンプレート｜入力してはいけない情報の一覧つき

生成AI利用ガイドラインとは、社員が生成AIを使うときの「使ってよいツール」「入力してよい情報」「出力の確かめ方」「申請と記録の方法」を定めた社内ルールです。 中心になるのは、情報の区分とツールの種別を掛け合わせて「この情報は、このツールに入力してよいか」を1つの表で判定できるようにすることです。

この記事では、15条の条文のひな形を Markdown で全文掲載し、入力してはいけない情報の一覧（情報の種類／具体例／可否／理由）と、情報区分×ツール種別の判定表を、表計算ソフトにそのまま貼れるタブ区切りでも用意しました。ソースコード・認証情報・ログ・顧客の環境情報といった開発業務向けの項目、利用申請書・出力確認表・例外承認の記入例、改訂履歴の書き方まで含めています。

この記事はひな形であり、法律上の助言ではありません。最終的には、各社の規程・契約・法務部門の確認に従ってください。

確認環境：根拠として挙げた公開資料（AI事業者ガイドライン 第1.1版、JDLA「生成AIの利用ガイドライン」の公開ページ、個人情報保護委員会の注意喚起）は 2026年10月5日に閲覧しました。タブ区切りの表は、列数がそろっていることと、別表1・別表2が Markdown の表と一致することを Python 3.11.15 で確認し、ログの置き換えスクリプトは同じ環境で実行した出力を載せています。会社名・人名・システム名はすべて架空です。

ガイドラインの構成の早見表

根拠にした公開資料と該当箇所

条文を作るときに参照した公開資料です。自社のガイドラインにも「何を参考にしたか」を書いておくと、改訂のときに見直す先がはっきりします。

AI事業者ガイドラインは、AI利用者を「事業活動において、AIシステム又はAIサービスを利用する事業者」としています。社内で生成AIを使う会社は、この「AI利用者」の立場で読むと該当箇所を探しやすくなります。JDLA は条項のみの版と簡易解説付きの版、画像編（2024年2月）を公開しています。いずれの資料も改訂されることがあるので、自社のルールを作るときは最新版を開いて確かめてください。

情報区分とツール種別を決める

判定表の縦と横にあたる2つの区分を先に決めます。すでに情報管理規程がある会社は、その区分に合わせます。

情報区分（6区分の例）

ツール種別（4種別の例）

各サービスが入力をどう取り扱うかは、提供事業者・契約の種類・設定によって異なり、変更されることもあります。種別 T2 として承認する前に、契約する部門が利用規約とプライバシーポリシーを開いて確かめる手順にしておきます。

情報区分×ツール種別の判定表（別表2）

記号は、○＝入力してよい、△＝申請または条件つき、×＝入力しない、です。

タブ区切りです。コードブロックの中をコピーして、表計算ソフトのセル A1 に貼り付けると表になります。

情報区分    T1 未承認のサービス T2 承認済みの外部サービス  T3 自社管理の環境  T4 顧客が指定した環境
C1 公開情報 ○   ○   ○   ○
C2 社内一般 ×   ○   ○   △（顧客との取り決めの範囲で）
C3 社外秘  ×   △（利用申請が必要）  ○   ×
C4 個人情報 ×   △（識別できない形に置き換え、例外承認を受ける）    △（利用目的の範囲内で、利用申請が必要）    ×
C5 認証情報 ×   ×   ×   ×
C6 顧客から預かった情報   ×   △（顧客の書面による承諾と例外承認が必要）   △（契約で認められた範囲で、利用申請が必要）  ○（その顧客の情報に限る）

表の読み方は3つです。

• 認証情報（C5）は、どのツールにも入力しない。 貼ってしまうと、値を取り替える以外に元へ戻す方法がないためです。
• 未承認のサービス（T1）に入力できるのは公開情報だけ。 新しいツールを試すこと自体は止めず、入力する情報で線を引きます。
• 顧客から預かった情報（C6）は、自社のルールより顧客との契約と指示が先。 自社で承認済みのツールでも、顧客の承諾がなければ入力しません。

入力してはいけない情報の一覧（別表1）

可否は、種別 T2（承認済みの外部サービス）に入力する場合を基準にしています。

番号  情報の種類   具体例 可否  理由
1   個人を識別できる情報  氏名、住所、電話番号、メールアドレス、社員番号、顔写真 ×   利用目的の範囲を超える取り扱いになるおそれがある
2   特に配慮が必要な個人の情報   健康状態、信条、採用選考の評価、人事評価    ×   漏れたときの本人への影響が大きい
3   顧客・取引先の担当者の情報   名刺の内容、問い合わせの本文、通話の文字起こし ×   相手の同意の範囲を超えるおそれがある
4   認証情報    パスワード、APIキー、アクセストークン、秘密鍵、接続文字列  ×   第三者が接続に使える。貼った時点で取り替えが必要になる
5   顧客から預かった情報  顧客の設計書、ソースコード、データ、議事録   ×（顧客の承諾と例外承認があれば△）  契約上の秘密保持の義務がある
6   顧客の環境情報 ホスト名、IPアドレス、ネットワーク構成図、アカウント名、製品の版の一覧    ×   攻撃の手がかりになる。契約上の秘密にあたることが多い
7   未公開の経営・営業の情報    事業計画、見積り、価格の根拠、交渉の経緯、未発表の製品情報   △（利用申請が必要）  公開前に外へ出ると事業に影響する
8   自社のソースコード   業務システムのコード、設定ファイル、インフラの定義   △（利用申請が必要。認証情報を除く）  自社の資産であり、弱点の手がかりにもなる
9   ログ・エラーの出力   アプリケーションのログ、アクセスログ、スタックトレース、ダンプ △（置き換えたうえで可）    氏名・メールアドレス・IPアドレス・トークンが混ざりやすい
10  データベースの中身   テーブルを取り出したファイル、問い合わせの結果 ×   個人情報と業務データがまとまって含まれる
11  データベースの定義   テーブル定義、ER図  △（自社のものは利用申請、顧客のものは番号5に従う）  構造そのものが設計上の秘密にあたることがある
12  セキュリティに関する情報    脆弱性診断の報告書、対応前の脆弱性の内容、監視の設定  ×   対応前に外へ出ると悪用されるおそれがある
13  契約書・法務に関する文書    締結前後の契約書、係争に関する文書   ×   相手方との秘密保持の対象である
14  第三者の著作物 購入した書籍・有償の資料の本文、他社の非公開の資料   ×   権利者の許諾の範囲を超えるおそれがある
15  社内一般の情報 社内の手順書、一般的な議事メモ（個人名を除く） ○   承認済みのツールであれば入力してよい
16  公開情報    公開中のウェブページ、公開済みの仕様、一般的な技術の質問    ○   すでに公開されている

ガイドラインのひな形（全文）

架空の「株式会社サンプルシステム」の名前で書いています。{ } の部分と会社名・部門名を自社に合わせて書き換えてください。

# 生成AI利用ガイドライン

- 文書番号: {ISMS-G-012}
- 版: {1.0}
- 制定日: {2026年10月1日}
- 管理部門: {情報システム部}
- 承認者: {情報セキュリティ委員会}

## 第1条（目的）

本ガイドラインは、株式会社サンプルシステム（以下「当社」）の役員および従業員等が、業務で生成AIを安全かつ効果的に利用するために守る事項を定める。生成AIの活用を進めることと、情報と権利を守ることの両立を目的とする。

## 第2条（適用範囲）

1. 本ガイドラインは、当社の役員、正社員、契約社員、派遣社員、および当社の業務に従事する業務委託先の要員（以下「利用者」）に適用する。
2. 本ガイドラインは、当社の業務として行うすべての生成AIの利用に適用する。私物の端末や個人で契約したサービスを業務に使う場合も含む。
3. 顧客または委託元の事業所・環境で業務を行う場合は、第9条に従う。

## 第3条（定義）

1. 「生成AI」とは、文章・画像・音声・プログラムなどを、入力された指示に応じて生成するAI、およびそれを利用したサービスやツールをいう。
2. 「入力」とは、生成AIに送る文章、ファイル、画像、音声、およびツールが自動で読み取って送る内容（開いているファイル、端末の出力など）をいう。
3. 「出力」とは、生成AIが返した文章、画像、プログラムなどをいう。
4. 情報区分は次の6つとする。
   - C1 公開情報：すでに社外へ公開している情報
   - C2 社内一般：社内で広く共有してよい情報
   - C3 社外秘：限られた者だけが扱う当社の情報
   - C4 個人情報：特定の個人を識別できる情報
   - C5 認証情報：パスワード、APIキー、トークン、秘密鍵、接続文字列など
   - C6 顧客から預かった情報：契約にもとづき顧客・委託元から受け取った情報
5. ツール種別は次の4つとする。
   - T1 未承認のサービス：当社が契約条件を確認していないもの
   - T2 承認済みの外部サービス：当社が契約し、入力の取り扱いを確認して承認したもの
   - T3 自社管理の環境：当社の管理下で動かしているもの、または当社専用として契約したもの
   - T4 顧客が指定した環境：顧客・委託元が用意し、利用を指定したもの

## 第4条（利用できるツール）

1. 業務で利用できる生成AIは、{情報システム部}が管理する「承認済みツール一覧」に載っているものとする。
2. {情報システム部}は、ツールを承認する前に、提供事業者の利用規約とプライバシーポリシー等を確認し、次の事項を記録する。
   - 入力した内容が、モデルの学習に使われるか。使われない設定や契約があるか
   - 入力と出力が保存される期間と場所
   - 提供事業者の従業員や第三者が内容を見ることがあるか
   - 利用者の認証の方法と、利用の記録を取得できるか
   - 出力の権利と、商用利用の条件
3. 新しいツールを使いたい利用者は、第10条の利用申請を行う。
4. 未承認のサービス（T1）は、公開情報（C1）だけを入力する範囲で、試しに使うことができる。
5. 承認済みのツールは、当社が発行したアカウントで利用する。個人のアカウントを業務に使わない。

## 第5条（入力してはいけない情報）

1. 利用者は、入力しようとする情報の区分と、利用するツールの種別を確かめ、別表2「情報区分×ツール種別の判定表」に従う。
2. 入力してはいけない情報の具体例は、別表1「入力してはいけない情報の一覧」に定める。
3. 認証情報（C5）は、ツールの種別にかかわらず入力しない。
4. 区分の判断に迷う情報は、より厳しい区分として扱い、{所属長または情報システム部}に相談する。

## 第6条（入力するときの注意）

1. 入力する情報は、目的を果たすために必要な最小限にする。
2. 個人名、社名、製品名、識別子などは、内容に影響しない範囲で、記号や仮の名前に置き換える。
3. ファイルを渡すときは、関係のないシート、コメント、変更履歴、作成者の情報が含まれていないかを確かめる。
4. 個人情報を入力する場合は、その利用が、本人に示した利用目的の範囲内であることを確かめる。
5. ツールの設定（学習への利用、履歴の保存、共有リンクなど）が、{情報システム部}の定めた状態になっていることを確かめる。

## 第7条（出力の確認）

1. 出力には、事実と異なる内容、偏った内容、最新でない内容が含まれることがある。利用者は、出力をそのまま使わず、内容を確かめる。
2. 出力を業務の成果物に使う場合、その内容についての責任は、利用者と、成果物を承認した者が負う。
3. 利用者は、次の事項を確かめる。
   - 事実、数値、日付、固有名詞、引用元が正しいか（一次情報で確かめる）
   - 法令、規格、契約についての記述が正しいか（担当部門に確かめる）
   - 第三者の著作物、商標、氏名、肖像に似ていないか
   - 差別的な表現、特定の人や組織を不当に扱う表現が含まれていないか
4. 社外に出す文書、顧客への納品物、採用・評価など人に関する判断に出力を使う場合は、別紙「出力確認表」で確かめ、第11条に従って記録する。
5. 出力だけを根拠に、人の採否・評価・処遇を決めない。

## 第8条（開発業務での利用）

1. ソースコード、設定ファイル、ログを入力する前に、認証情報と個人情報が含まれていないことを確かめる。含まれている場合は、取り除くか置き換える。
2. 認証情報を誤って入力した場合は、ただちにその認証情報を無効にして取り替え、第13条に従って連絡する。
3. 顧客のソースコード、設計書、データ、環境情報（ホスト名、IPアドレス、構成図、アカウント名など）は、第9条に従う。
4. 生成AIが出力したプログラムは、人が書いたものと同じ基準で、レビューとテストを行う。出力したプログラムであることを理由に、レビューやテストを省かない。
5. 出力したプログラムについて、次の事項を確かめる。
   - 入力の検証、権限の確認、秘密の値の扱いなど、セキュリティ上の問題がないか
   - 提案されたライブラリが実在し、ライセンスと保守の状況が当社の基準に合うか
   - 既存のソフトウェアのコードと長く一致する部分がないか
6. ファイルの読み書きやコマンドの実行を自動で行うツールを使う場合は、次を守る。
   - 読み取りを許すフォルダを、作業に必要な範囲に限る
   - 認証情報を置いたファイル（{.env など}）を読み取りの対象から外す
   - 削除、外部への送信、本番環境への操作は、実行の前に人が内容を確かめる
   - 本番環境の認証情報を持つ端末・アカウントでは使わない
7. 生成AIを組み込んだ機能を自社で開発する場合は、本ガイドラインに加えて、{別に定める開発基準}に従う。

## 第9条（顧客・委託元との関係）

1. 顧客または委託元（以下「顧客」）の業務で生成AIを使う場合は、顧客との契約と顧客の指示を、本ガイドラインより優先する。
2. 顧客が生成AIの利用を認めていない場合、または取り決めがない場合は、顧客から預かった情報（C6）を生成AIに入力しない。
3. 顧客の業務で生成AIを使いたい場合は、{営業担当または責任者}を通じて、顧客に次の事項を示し、書面（電子メールを含む）で承諾を得る。
   - 使うツールの名前と種別
   - 入力する情報の範囲
   - 入力した内容の取り扱い（学習への利用の有無、保存期間）
   - 出力の使いみちと、確認の方法
4. 顧客が指定した環境（T4）を使う場合は、顧客が定めたルールに従う。当社の情報（C2〜C5）を、顧客の環境に入力しない。ただし、社内一般（C2）は、顧客との取り決めの範囲で入力できる。
5. 納品物に生成AIの出力を含める場合の表示や報告は、顧客との取り決めに従う。

## 第10条（申請と例外承認）

1. 次の場合は、利用の前に、別紙「利用申請書」により申請する。
   - 新しいツールの承認を求めるとき
   - 別表2で「△（利用申請が必要）」とされている利用を行うとき
2. 別表2で「例外承認」が必要とされている利用、および別表1・別表2で「×」とされている利用を、業務上のやむを得ない理由で行う必要がある場合は、別紙「例外承認申請書」により申請する。認証情報（C5）の入力は、例外承認の対象としない。
3. 承認者は次のとおりとする。
   - 利用申請：{所属長}および{情報システム部}
   - 例外承認：{情報セキュリティ委員会の委員長}
4. 例外承認には、期限（最長{3か月}）、対象の情報、対象のツール、代わりの安全対策を定める。期限が来たら、利用をやめるか、あらためて申請する。

## 第11条（記録）

1. {情報システム部}は、承認済みツール一覧、利用申請、例外承認の記録を管理する。
2. 利用者は、第7条第4項の確認を行ったとき、出力確認表を成果物とあわせて保存する。
3. 記録の保存期間は{3年}とする。
4. {情報システム部}は、承認済みツールの利用の記録（利用者、日時）を、ツールが提供する範囲で取得し、{四半期}ごとに確認する。

## 第12条（教育）

1. 利用者は、生成AIを業務で使い始める前に、{情報システム部}が定める教育を受ける。
2. 教育は{年1回}行い、本ガイドラインを改訂したときは、変更点を周知する。
3. 教育の内容には、入力してはいけない情報、判定表の使い方、出力の確認、事故のときの連絡を含める。

## 第13条（事故のときの連絡）

1. 利用者は、次のことに気づいたとき、{1時間以内}を目安に、{情報システム部の窓口（内線 0000／security@example.co.jp）}に連絡する。
   - 入力してはいけない情報を入力した、またはその可能性がある
   - 出力に、他人の個人情報や秘密と思われる内容が含まれていた
   - 出力の誤りに気づかないまま、社外に出した
2. 連絡するときは、日時、ツールの名前、入力した内容の概要、いま行った対応を伝える。
3. 利用者は、連絡とあわせて、できる範囲で次の対応を行う。
   - 該当する会話や履歴を、ツールの機能で削除する
   - 認証情報が含まれていた場合は、無効にして取り替える
4. 早く連絡した利用者を、連絡したことを理由に不利益に扱わない。

## 第14条（違反したとき）

本ガイドラインに違反した場合の取り扱いは、{就業規則および情報セキュリティ規程}の定めによる。

## 第15条（見直しと改訂）

1. {情報システム部}は、本ガイドラインを{半年}に1回見直す。次の場合は、時期を待たずに見直す。
   - 関係する法令、国のガイドライン、業界のひな形が改訂されたとき
   - 承認済みツールの利用規約や機能が大きく変わったとき
   - 事故、または事故につながりかねない事象が起きたとき
2. 改訂は、{情報セキュリティ委員会}の承認を得て行い、改訂履歴に記録する。

## 別表1　入力してはいけない情報の一覧

（一覧の表を貼る）

## 別表2　情報区分×ツール種別の判定表

（判定表を貼る）

## 改訂履歴

| 版 | 改訂日 | 改訂した箇所 | 改訂の内容 | 改訂の理由 | 承認者 |
|---|---|---|---|---|---|
| 1.0 | 2026-10-01 | 全体 | 新規制定 | ― | 情報セキュリティ委員会 |

開発業務向けの項目

第8条を、作業の場面ごとに確かめられる形にした表です。

場面  入力する前に確かめること    置き換え・対応の例
ソースコードを貼る   認証情報が直書きされていないか。顧客のコードではないか 値を {API_KEY} などの仮の文字に置き換える。顧客のコードは第9条に従う
設定ファイルを貼る   接続文字列、パスワード、ホスト名が含まれていないか   キーの名前だけ残し、値を仮の文字に置き換える
ログ・エラーを貼る   メールアドレス、IPアドレス、トークン、氏名が含まれていないか 貼る前にスクリプトで置き換える
テーブル定義を貼る   自社のものか、顧客のものか   自社のものは利用申請の範囲で。テーブル名・列名を一般的な名前に置き換える方法もある
テストデータを作らせる 本物のデータを見本として渡していないか 列の定義と条件だけを渡し、架空の値を作らせる
環境の相談をする    ホスト名、IPアドレス、アカウント名、構成図が含まれていないか web01、10.0.0.1 のような一般的な名前に置き換える
出力したコードを取り込む    レビューとテストを行ったか。ライブラリは実在するか   人が書いたコードと同じ手順でレビューする
自動で操作するツールを使う   読み取りの範囲、実行前の確認、認証情報の置き場所    作業用のフォルダに限定し、認証情報のファイルを対象から外す

ログを貼る前に置き換えるスクリプト

第6条第2項の「置き換え」を、手作業に頼らず行うための小さな例です。Python の標準ライブラリだけで動きます。

"""生成AIに貼る前に、ログの中の識別できる値を置き換える。
使い方: python3 mask_log.py < app.log
"""
import re
import sys

RULES = [
    # (説明, パターン, 置き換え後)。上から順に適用する。
    # URL の中の認証情報は、メールアドレスの規則より先に置く。
    ("URLの中の認証情報", re.compile(r"(://)[^/\s:@]+:[^/\s@]+@"), r"\1<USER>:<SECRET>@"),
    ("社内のホスト名", re.compile(r"\b[\w-]+\.internal\.example\.co\.jp\b"), "<HOST>"),
    ("メールアドレス", re.compile(r"[\w.+-]+@[\w-]+(?:\.[\w-]+)+"), "<EMAIL>"),
    ("IPv4アドレス", re.compile(r"\b(?:\d{1,3}\.){3}\d{1,3}\b"), "<IP>"),
    ("Bearerトークン", re.compile(r"(?i)(bearer\s+)[A-Za-z0-9._~+/=-]{8,}"), r"\1<TOKEN>"),
    ("キーと値の形の秘密", re.compile(r"(?i)\b(password|passwd|secret|token|api[_-]?key)(\s*[=:]\s*)\S+"), r"\1\2<SECRET>"),
]


def mask(line: str) -> str:
    for _name, pattern, replacement in RULES:
        line = pattern.sub(replacement, line)
    return line


if __name__ == "__main__":
    for raw in sys.stdin:
        sys.stdout.write(mask(raw))

架空のログ（app.log）です。

2026-10-05 09:12:01 INFO  login ok user=taro.yamada@example.co.jp from=192.168.10.24
2026-10-05 09:12:03 DEBUG connect postgresql://app_user:Pa55w0rd@db01.internal.example.co.jp:5432/reserve
2026-10-05 09:12:04 DEBUG request headers: Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.abc123.def456
2026-10-05 09:12:05 ERROR export failed api_key=key_9f8e7d6c5b4a retry=3
2026-10-05 09:12:06 ERROR NullPointerException at ReservationService.confirm(ReservationService.java:88)

python3 mask_log.py < app.log

2026-10-05 09:12:01 INFO  login ok user=<EMAIL> from=<IP>
2026-10-05 09:12:03 DEBUG connect postgresql://<USER>:<SECRET>@<HOST>:5432/reserve
2026-10-05 09:12:04 DEBUG request headers: Authorization: Bearer <TOKEN>
2026-10-05 09:12:05 ERROR export failed api_key=<SECRET> retry=3
2026-10-05 09:12:06 ERROR NullPointerException at ReservationService.confirm(ReservationService.java:88)

原因の調査に必要な5行目（例外の種類と場所）はそのまま残り、識別できる値だけが置き換わりました。規則の順番には注意が要ります。メールアドレスの規則を先頭に置いて実行したときは、2行目の Pa55w0rd@db01.internal.example.co.jp の部分がメールアドレスとして先に置き換わり、ユーザー名 app_user が残りました。

2026-10-05 09:12:03 DEBUG connect postgresql://app_user:<EMAIL>:5432/reserve

規則は自社のログの形に合わせて足し、置き換えたあとの出力を目で確かめてから貼る、という2段構えにしておくと確実です。氏名のように決まった形のない値は、この方法では拾えません。

利用申請書の記入例

架空の「備品予約システム」の保守チームが、設計書の要約に承認済みツールを使いたい、という想定です。

項目  記入例
申請番号    AI-2026-014
申請日 2026-10-05
申請者 開発部 第2グループ 山田 太郎
申請の種類   別表2で△の利用（C3 社外秘 × T2 承認済みの外部サービス）
使うツール   承認済みツール一覧 No.2（会社契約の対話型サービス）
目的  備品予約システムの詳細設計書（自社資産）の要約と、用語の不統一の洗い出し
入力する情報  詳細設計書 第3章〜第5章（約40ページ）。区分 C3
含まれない情報の確認  個人情報なし／認証情報なし／顧客から預かった情報なし（2026-10-03 に山田が目で確認）
置き換え    社内のホスト名を web01、db01 に置き換える
出力の使いみち 社内レビューの資料。社外には出さない
出力の確認の方法    要約を設計書の原文と見比べる。確認者：第2グループ 佐藤
利用の期間   2026-10-06 〜 2026-10-31
所属長の承認  承認 2026-10-05 開発部長 鈴木
情報システム部の承認  承認 2026-10-05 情報システム部 高橋（条件：履歴は作業の終了後に削除する）

出力確認表の記入例

第7条第4項で使う表です。社外に出す文書（ここでは、利用者向けの操作手順書の下書き）を想定しています。

番号  確認すること  結果  確認の方法・メモ
1   事実・数値・日付・固有名詞が正しい   済   画面名と項目名を、動いている画面と見比べた。2か所を修正
2   引用元・参照先が実在し、内容が合っている    該当なし    引用なし
3   法令・規格・契約についての記述が正しい 該当なし    記述なし
4   第三者の文章・画像・商標に似ていない  済   文章を検索して、一致する公開文書がないことを確認
5   個人情報・秘密の情報が含まれていない  済   画面の例に使った氏名を架空のものに変更
6   不適切・不公平な表現がない   済   通読して確認
7   自社の用語・文体・書式に合っている   済   用語集と照合。「ログオン」を「ログイン」に統一
8   プログラムを含む場合、レビューとテストを行った 該当なし    プログラムなし
9   生成AIを使ったことの表示・報告が必要か確かめた    済   顧客との取り決めなし。社内の記録に残す
10  自分の言葉で内容を説明できる  済   ―

記入欄の頭には、文書名（操作手順書 第2版 下書き）、使ったツール、確認者、確認日を書いておきます。

例外承認の記入例

別表2で「例外承認」が必要とされている利用の例です。利用者からの問い合わせ文を分類したい、という想定で、個人を識別できる部分を置き換えたうえで申請しています。

項目  記入例
申請番号    EX-2026-003
申請日 2026-10-05
申請者 サポート部 伊藤 花子
対象の情報   備品予約システムへの問い合わせ本文 2026年7月〜9月分（約300件）。区分 C4
対象のツール  承認済みツール一覧 No.2（T2）
判定表での扱い C4 × T2 ＝ △（識別できない形に置き換え、例外承認を受ける）
例外が必要な理由    問い合わせを内容別に分類し、よくある質問の案内を見直すため。手作業では約3日かかる
利用目的との関係    問い合わせ対応の品質向上は、問い合わせの受付時に示している利用目的の範囲内（個人情報の管理担当に確認済み）
代わりの安全対策    氏名・メールアドレス・電話番号・社員番号を置き換えスクリプトと目視で取り除く／1件ずつ番号だけで管理する／学習に使われない設定を確認する／作業の終了後に履歴を削除する
残る心配と対応 本文中の自由記述に個人名が残ることがある → 先頭50件を2人で確かめてから残りを処理する
期限  2026-10-06 〜 2026-10-20（延長する場合はあらためて申請）
承認  承認 2026-10-05 情報セキュリティ委員会 委員長 渡辺
承認の条件   置き換えの確認の記録を残す。終了後、結果を情報システム部へ報告する
終了の報告   2026-10-18 終了。履歴を削除済み（伊藤）

例外承認で大切なのは、期限・対象・代わりの安全対策・終了の報告の4つを必ず埋めることです。期限のない例外は、いつのまにか通常の運用になってしまいます。

改訂履歴の書き方

生成AIは、ツールの機能や利用規約、参考にした公開資料が短い間隔で変わります。「どこを・なぜ・誰の承認で変えたか」を1行で追えるようにしておきます。

版   改訂日 改訂した箇所  改訂の内容   改訂の理由   承認者
1.0 2026-10-01  全体  新規制定    ―   情報セキュリティ委員会
1.1 2026-11-15  第4条、承認済みツール一覧   コード補完ツール1件を一覧に追加    開発部からの利用申請（AI-2026-021） 情報セキュリティ委員会
1.2 2027-01-20  第8条第6項  自動で操作するツールの条件に「本番環境の認証情報を持つ端末では使わない」を追加 四半期の見直しで出た指摘    情報セキュリティ委員会
2.0 2027-04-01  別表2 C3×T2 を「△」から「○」に変更  承認済みツールの契約を見直し、入力の取り扱いを確認できたため  情報セキュリティ委員会

版の番号の付け方は、次のように決めておくと迷いません。

改訂履歴には、変えた内容だけでなく理由を書きます。理由が残っていると、次の見直しのときに「この条件はまだ必要か」を判断できます。参考にした公開資料の版（AI事業者ガイドライン 第1.1版 など）も文書のどこかに書いておき、新しい版が出たら見直すきっかけにします。

導入の進め方

最初から完全な形を目指すより、判定表と入力してはいけない情報の一覧を先に配り、申請や相談で出てきた事例をもとに条文を整えていくほうが、使われるルールになります。

よくある質問

Q. 何条くらいの長さが適切ですか？ A. 決まりはありません。このひな形は15条ですが、利用者が日々見るのは判定表（別表2）と一覧（別表1）です。条文は、判定表の根拠と、申請・記録・連絡の手続きを示す役割と考え、読む人が迷う部分だけを厚くします。

Q. 生成AIの利用を全面的に止めるルールにしたほうが安全ではありませんか？ A. 止めるルールは分かりやすい一方、個人で契約したサービスを見えないところで使う動きにつながることがあります。承認済みのツールを用意し、入力する情報で線を引くほうが、会社として利用の状況を把握しやすくなります。

Q. 顧客先で作業する社員には、どちらのルールを適用しますか？ A. 顧客との契約と顧客の指示を優先します（ひな形の第9条）。顧客にルールがない場合は、顧客から預かった情報を入力しないことを基本にし、使いたいときは書面で承諾を得ます。自社のルールは、顧客のルールが定めていない部分を補う位置づけです。

Q. 判定表の「△」が多くて申請が増えそうです。 A. 最初は△を多めにして申請の内容を集め、同じ申請が繰り返されるものを「○（条件つき）」に移していくと、実態に合った表になります。改訂履歴に理由を残しておけば、あとから線引きの経緯を追えます。

まとめ

• 生成AI利用ガイドラインの中心は、情報区分×ツール種別の判定表と入力してはいけない情報の一覧
• 認証情報はどのツールにも入力しない。未承認のサービスに入力できるのは公開情報だけ
• 顧客から預かった情報は、顧客との契約と指示が自社のルールより先
• ツールを承認する前に、利用規約とプライバシーポリシーを開いて、入力の取り扱いを確かめて記録する
• 開発業務では、コード・設定・ログを貼る前に置き換え、出力したコードは人が書いたものと同じ基準でレビューとテストを行う
• 例外承認には、期限・対象・代わりの安全対策・終了の報告を必ず書く
• 改訂履歴に「変えた箇所・内容・理由・承認者」を残し、公開資料の改訂やツールの変更に合わせて見直す

参考・出典

• 総務省・経済産業省「AI事業者ガイドライン（第1.1版）」（令和7年3月28日） https://www.soumu.go.jp/main_content/001002576.pdf （2026年10月5日に閲覧）
• 一般社団法人日本ディープラーニング協会（JDLA）「資料室」内「生成AIの利用ガイドライン」 https://www.jdla.org/document/ （2026年10月5日に閲覧）
• 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」（令和5年6月2日） https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/ （2026年10月5日に閲覧。注意点の本文は同ページの別添資料）

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。