生成AI社内ルールの作り方｜テンプレートを自社用に削る基準

生成AIの社内ルールは「A4 1枚・7条」で足りる

生成AIの社内ルールを作ろうとして検索すると、章立てが十近くあり、項目数が数十に及ぶ大部のガイドラインが出てきます。あれは情報システム部門と法務部門が分かれていて、規程改訂の専任者がいる規模の会社を前提にした分量です。専任者のいない情シス兼任・総務兼任の担当者が同じものを目指すと、書き始める前に「この章はうちに関係あるのか」で止まります。実際に社内で運用に乗るのは、A4で1枚、条文にして7つ程度の分量です。まずは次の7つだけを埋めれば、社内文書として発効できる水準に達します。

• 第1条 目的と適用範囲
• 第2条 利用を認めるツール
• 第3条 入力してはいけない情報
• 第4条 出力の検証と責任の所在
• 第5条 著作権と第三者の権利の扱い
• 第6条 インシデント時の連絡先
• 第7条 改訂

この記事は、この7条を「作る→削る→書き直す→既存規程につなぐ→測る」の順で自社のものにしていく手順で進みます。テンプレートを配って終わりにするのではなく、配ったあとに守られる文書にするところまでが範囲です。

作る前の30分：いま社内で誰が何に使っているかを棚卸しする

ルールの文面を書き始める前に、必ず先にやることがあります。いま社内で生成AIが実際にどう使われているかを見ることです。多くの会社では、ルールが無いあいだにも現場は使い始めています。無いのは利用ではなく、把握です。ここを飛ばして「原則禁止、利用は申請制」から入ると、すでに使っている人は申請を出さずに使い続けます。会社から見える利用がゼロになるだけで、利用そのものは個人アカウントの側に潜り込みます。禁止は利用を止めるのではなく、利用を見えなくするという形で効いてしまいます。だから順序として、測ってから決めます。所要は30分程度で十分です。部署ごとの担当者に、次の4列だけを埋めてもらいます。

部署	使っているツール	入れている情報	業務での用途
回答者の所属部署を書きます	個人アカウントか会社アカウントかも併記します	実際に貼り付けている内容の種類を書きます	何のために使っているかを一行で書きます

重要なのは3列目です。ここに何が挙がるかで、第3条（入力禁止情報）に書くべき具体名が決まります。抽象的な禁止語を先に決めるのではなく、実際に貼られているものを見てから禁止の線を引く、という順番です。

棚卸しの過程で、承認していないツールの利用や、本来出してはいけない情報の入力が見つかることがあります。ここでの初手は、責めない・止めない・記録するの3つです。責めれば次から正直な回答が来なくなり、その時点で棚卸しは二度と機能しません。緊急に止める必要があるものだけを個別に扱い、それ以外は記録に残してルールの側で吸収します。

社内ルールの作り方 5ステップ（担当・所要日数つき）

ここまでの棚卸しを含めて、発効までの全体像を先に示します。この章は地図であり、各ステップの中身は次章以降で扱います。全体としては2週間から3週間で発効まで到達できる規模です。長くなるとしたら、たいていは起草に時間がかかっているのではなく、レビューと承認の段階で「既存の規程との関係」を聞かれて止まっているケースです。その論点は後の章で先回りして潰します。担当と日数の目安は次のとおりです。

ステップ	内容	担当	所要日数の目安
1	現状の棚卸し	情シス・総務の担当者と各部署の窓口	1日
2	方針の決定（認めるツールと禁止の線）	担当者と決裁者	2日
3	起草（テンプレートを埋めて削る）	担当者	3日
4	レビューと承認	法務担当または顧問、決裁者	1週間
5	周知と質問受付	担当者と各部署の窓口	3日

【テンプレート】そのまま使える生成AI社内ルール 全7条

ここから実際の条文です。そのままコピーして社内文書の体裁に貼れる形で書いています。ただし、貼った時点では完成していません。テンプレートというのは、どの会社にも当てはまる部分だけを残した抜け殻なので、自社の固有名詞が入る箇所は必ず空いています。そこを埋めないまま配ると、読んだ人は「誰に聞けばいいのか」「どのツールなら使っていいのか」が分からず、結局これまでどおり自己判断で使うことになります。まず全7条を提示し、そのあとで貼ったあとに必ず書き換える箇所を指定します。

第1条〜第7条のひな形本文

以下は、従業員が数十名から数百名規模の会社を想定した最小構成です。条番号と見出しはそのまま使えます。各条の本文は、自社の実態に合わせて語を差し替える前提で読んでください。前章の棚卸し表で挙がった内容が、第2条と第3条に反映されるべき材料になります。

第1条（目的と適用範囲） 本ルールは、当社における生成AIの業務利用について、安全に利用するための基準を定めます。適用範囲は、当社の役員および従業員（雇用形態を問わず）が、業務のために生成AIを利用するすべての場合とします。私物の端末や個人アカウントを用いる場合も含みます。

第2条（利用を認めるツール） 業務で利用できる生成AIは、会社が承認したものに限ります。承認済みのツールは別紙に一覧で示し、追加を希望する場合は事前に情報システム担当へ申請します。入力した内容が提供者の学習に利用されない設定であることを、承認の条件とします。

第3条（入力してはいけない情報） 承認済みのツールであっても、次の情報はそのまま入力しません。顧客および取引先を特定できる情報、未公表の財務・人事に関する情報、契約書その他の秘密保持義務の対象となる資料、個人情報、当社の技術上の秘密です。該当箇所を伏せたうえで利用することは差し支えありません。

第4条（出力の検証と責任） 生成AIの出力は、そのままでは業務上の成果物として扱いません。事実関係・数値・引用元は、利用者が一次情報にあたって確認します。社外に提出する文書に生成AIを用いた場合の責任は、当該文書の作成者および承認者が負います。

第5条（著作権と第三者の権利） 生成された文章・画像等が、既存の著作物と同一または類似となる場合があります。社外公開または商用利用をする成果物については、公開前に類似の有無を確認します。他者の著作物を入力する場合は、利用目的が引用等の範囲に収まるかを確認します。

第6条（インシデント時の連絡先） 入力してはいけない情報を入力した、または出力に誤りがある状態で社外に提出したことに気づいた場合は、直ちに定められた窓口へ連絡します。連絡した時点での不利益な取り扱いは行いません。

第7条（改訂） 本ルールは定期的に見直し、必要に応じて改訂します。改訂は所定の決裁を経たうえで、全従業員に周知します。

以上が全文です。分量としてはA4で1枚に収まります。この時点ではまだ一般論の集合なので、次に自社の情報を差し込みます。

貼ったあとに必ず書き換える3か所

このテンプレートには、埋めないと機能しない箇所が3つあります。逆に言えば、この3つさえ埋まっていれば、残りが一般的な表現のままでも文書としては動きます。1つ目は第2条の承認ツール名です。「会社が承認したもの」とだけ書いて別紙を作らないと、現場は自分が使っているツールが該当するのか判断できず、判断できないものは各自の解釈に委ねられます。棚卸しで挙がったツールを、認める・認めないの二列に分けて別紙に固定してください。

2つ目は第6条の連絡先です。「所定の窓口」ではなく、部署名と担当者名、そして連絡手段（メールなのかチャットの特定チャンネルなのか）まで書きます。事故に気づいた人が動くのは、気づいた直後の数分間だけです。そこで連絡先を探す手間が挟まると、報告は上がってきません。

3つ目は第7条の改訂サイクルです。「定期的に」ではなく、次の見直しを行う時期と、その会議体の名前を書きます。ここが空欄のまま配られたルールは、改訂の担当者が不在になり、そのまま古くなります。この3か所を空欄で配ることが、形骸化の最も一般的な入口です。

テンプレートは「足す」より「削る」——自社に要らない条文の見極め方

テンプレートを手に入れた担当者がまず考えるのは、「足りない項目は何か」です。しかし実務で詰まるのは、たいてい逆方向です。手元にある雛形が大きすぎて、どれが自社に関係あるのかが分からず、着手できないという詰まり方をします。ここで全部を残す判断をすると、自社に該当する業務が存在しない条文まで抱えることになります。関係のない条文が混じった文書は、読んだ人に「これは自分の仕事とは関係ない文書だ」という印象を与え、関係のある条文まで読み飛ばされます。だから、条文は足す前に削ります。削るのは手抜きではありません。守られる範囲まで文書を縮める作業です。

残す条文・削る条文を分ける3つの基準

削るかどうかは、好みではなく次の3つの基準で機械的に判定できます。

1つ目は、その条文が対象とする業務が自社に存在するかです。社内に開発部門がなく、コードを書く人が一人もいないなら、生成AIによるコード生成とライセンスの条文は要りません。存在しない業務についての条文は、読む人にとって意味を持たないだけでなく、「この文書はよそから借りてきたものだ」という印象を最初に与えます。

2つ目は、違反したときに実際に検知できるかです。検知できない禁止は、守った人と守らなかった人の区別がつかないので、時間が経つほど守った人が損をします。たとえば「個人の端末では利用しない」と書いても、会社が個人端末を見る手段を持っていなければ、その条文は運用されません。書くのであれば、検知の手段とセットにするか、検知できる別の行為（申請の有無など）に言い換えます。

3つ目は、既存の規程に同じことがすでに書かれていないかです。情報の持ち出しや秘密保持は、多くの会社で就業規則や情報セキュリティポリシーに既に規定があります。同じ内容を二重に書くと、片方だけ改訂されたときに矛盾が生まれます。重複部分は削り、「本件については情報セキュリティポリシー第何条による」という参照に置き換えます。

従業員50名以下／有資格業種で分岐する条文

分量の判断は、規模と業種でおおよそ分岐します。従業員50名以下で、社外向けの制作物を大量に扱う部門がない会社であれば、前章の7条をそのまま、削らずに使って構いません。これ以上増やすと運用の手が足りなくなり、これ以下に削ると入力禁止情報の定義が抜けます。7条が下限であり、同時に十分でもある水準です。

一方で、条文の追加を検討すべき類型が2つあります。ひとつは、法令上の守秘義務や資格に基づく職業倫理がある業種です。医療、士業、金融などでは、社内ルール違反が同時に法令違反や資格上の問題になるため、第3条の入力禁止情報に、その業種で定義されている秘密の類型（診療情報、依頼者の情報、顧客の取引情報）を名指しで書き足します。もうひとつは、受託開発や受託制作を行う会社です。この場合、自社の秘密ではなく委託元の秘密を預かっているため、契約上の再委託・第三者提供の制限に生成AIの利用が抵触しないかという条文が要ります。委託元への事前確認を要するかどうかを明記してください。

現場が判断できる文言にする——「機密情報を入力しない」が守られない理由

社内ルールは、違反を取り締まるための文書ではありません。現場の一人ひとりが、上司に聞かずにその場で判断を下せるようにするための文書です。この定義に立つと、良いルールの条件は「厳しさ」でも「網羅性」でもなくなります。読んだ人が、目の前にあるファイルについて白か黒かを自分で決められる粒度になっているか、おそらくその一点に収束します。前章で条文を削ったのも、この章でこれから文言を書き換えるのも、次章で守られているかを測るのも、すべてこの同じ基準から出てきます。

その目で「機密情報を入力しない」という一文を読むと、問題がはっきりします。この文は内容として正しいのですが、読んだ人は目の前のファイルが機密に当たるかを判定できません。判定できない以上、実際に起きるのは二択です。安全側に倒して使わなくなるか、自己判断で使うかです。前者なら導入した意味がなく、後者なら基準がないまま個人差で運用されます。曖昧な文言は、判断のコストを現場から会社に返さず、逆に現場へ押し付けます。

NG文言 → OK文言の書き換え例

書き換えの原則は、「情報の性質」で書かず「見れば分かる特徴」で書くことです。機密かどうかは解釈ですが、顧客名が入っているかどうかは目で見て分かります。判定に解釈が要らない形にまで下ろすと、現場は迷いません。

判断できない文言	判断できる文言
機密情報を入力しない	顧客名・取引金額・未公開の人事情報が含まれるファイルは、そのままアップロードしません（該当箇所を伏せれば利用できます）
適切なツールを利用する	別紙の承認済みツール一覧に記載のあるツールを利用します。一覧にないものは利用前に申請します
出力は必ず確認する	社外に出す文書は、数値・固有名詞・引用元の3点を一次資料と照合してから提出します
著作権に配慮する	社外公開する画像・文章は、公開前に既存の著作物との類似がないかを検索して確認します

右列はいずれも長くなっていますが、長さは問題になりません。読む回数が多いのは配布時の一度きりで、判断する回数のほうが圧倒的に多いからです。

グレーゾーンの相談先を条文に書く

どれだけ具体的に書いても、どちらとも言えない場面は必ず残ります。むしろ、実際の事故はそのグレーゾーンで起きます。ここで相談先が用意されていないと、人は自分で判断するしかなくなり、判断に自信がない人ほど「聞かずに使う」を選びます。禁止だけを書いたルールが隠れた利用を生むのは、この経路です。

ですから条文には、迷ったときの逃げ道を明示的に書きます。書くべきことは3つです。誰に聞くか（部署名と担当者名）、どこで聞くか（チャットの特定のチャンネルなど、他の人からも見える場所が望ましいです）、そして聞いたことによって不利益な扱いを受けないことです。相談を公開の場所に集めると、同じ質問が繰り返されなくなり、蓄積した質問がそのまま次回改訂の材料になります。相談先を書くことは、親切のためではなく、判断を会社側に取り戻すための仕組みです。

既存の情報セキュリティポリシー・就業規則とどうつなぐか

条文を書き上げて決裁に持っていくと、ほぼ確実に問われる質問があります。「これは既存の情報セキュリティポリシーとどういう関係になるのか」です。ここが決まっていないと、内容がどれだけ良くても社内文書として発効しません。選択肢は2つです。ひとつは独立した文書として新設する方法、もうひとつは既存ポリシーの追補（章や条の追加）として組み込む方法です。

判断の軸は2つあります。ひとつは、既存ポリシーがISMSやプライバシーマークの認証範囲に含まれているかです。含まれている場合、追補にすると認証の文書体系の一部となり、改訂のたびに所定の手続きが必要になります。もうひとつは、改訂の決裁レベルです。既存ポリシーの改訂が取締役会決議を要するのに対し、新設文書なら部門長決裁で足りる、という会社は多くあります。

生成AIの領域は、使えるツールも提供者側の仕様も短い周期で変わります。改訂が重い文書に組み込むと、四半期ごとの見直しが物理的に回らなくなり、実態と合わない条文が残り続けます。したがって、専任の規程担当がいない規模の会社では、独立文書として作り、既存ポリシーからは「生成AIの利用については別途定めるルールによる」と一行で参照する形が現実解になります。あわせて、両者の記述が食い違った場合にどちらが優先するかを、第1条の適用範囲に明記しておいてください。この一文があるかどうかで、後から生じる解釈の争いがなくなります。

配ったあと、守られているかを測る3つの兆候

形骸化させない方法として語られるのは、たいてい打ち手の列挙です。定期的にリマインドする、研修を年に一度行う、好事例を共有する。どれも間違いではありませんが、これらは「守られていない」と気づいたあとに打つ手であって、気づくための仕組みではありません。実際に困るのは、守られていないことに誰も気づかないまま時間が過ぎることです。ルールが守られていない状態は、違反の報告という形では現れません。むしろ、何も起きていないように見える形で現れます。だから、打ち手の前に兆候の見方を決めます。

兆候の見つけ方（ログ・申請・質問の3経路）

見るべき兆候は3つあり、それぞれ別の経路から拾えます。

1つ目は、ツールの利用申請が一定期間まったく出てこないことです。申請がないのは使われていないからだと解釈されがちですが、棚卸しの段階で利用実態が確認できている以上、より自然な解釈は「申請せずに使っている」です。申請の件数がゼロで、かつ現場で使われている形跡がある場合、申請の経路が使いにくいか、申請の存在が知られていません。

2つ目は、出力の検証記録が残っていないことです。社外に出す文書について照合したかどうかは、成果物のレビュー記録や承認の履歴から見えます。第4条を書いたのに検証の痕跡がどこにもないなら、その条文は読まれていないか、実行の手順に落ちていません。

3つ目は、ルールについての質問が一件も来ないことです。これが最も見落とされます。質問が来ない状態は、全員が理解した状態ではなく、読まれていない状態であることのほうが多いのが実情です。前章で相談先を公開の場所に置くのは、この経路を可視化するためでもあります。

3か月に1回の見直しで何を見るか

見直しは3か月に1回で十分ですが、その場で何を議題にするかを先に決めておかないと、条文の追加提案を聞く会になります。追加から入ると文書は必ず膨らみ、膨らんだ分だけ読まれなくなります。見直しの議題は、次の順序で固定してください。

最初に、この3か月で起きた事故とヒヤリの有無を確認します。無かった場合は、無かったのか、報告されていないのかを、前項の3つの兆候から判断します。次に、前項の兆候それぞれについて現状を確認し、変化があれば原因を探ります。そのうえで、削れる条文がないかを確認します。運用してみて一度も参照されなかった条文、実際には検知できないことが分かった条文は、この場で落とします。条文の追加を検討するのは最後です。追加が必要になるのは、承認ツールが増えたときと、業務の種類が増えたときのほぼ2つに限られます。この順序にしておくと、見直しのたびに文書が短くなる方向の力が働き、読まれる分量が保たれます。

まとめ：今日決める3つ

テンプレートは手元に揃いました。あとは、自社のものにする作業だけが残ります。全部を一度に進める必要はありません。今日のうちに決めておくべきことは、次の3つに絞られます。

1つ目は、現状の棚卸しを誰がいつやるかです。担当者名と実施日を決めてください。ここが動き出さないと、以降のすべてが一般論のまま止まります。2つ目は、提示した7条のうち、自社に必要な条数です。3つの基準に照らして、削れるものを削ってください。3つ目は、第6条に書く報告先の実名です。部署名と担当者名、そして連絡手段まで決めます。この3つが決まっていれば、残りは3週間で発効まで到達します。

あわせて読みたい

• クラウドの受注管理システムでできること｜機能表の先を読む──クラウドの利点、定着する運用、つないで効く一元化