生成AIの社内利用ルール・利用規定｜そのまま使える9章の章立てと可否の判定表

禁止事項だけのガイドラインで起きること

生成AIの社内ルールとして最初に配られる文書は、利用規定という名前で制定される場合も、ガイドラインとして周知される場合も、多くは同じ構成になっています。個人情報を入力しない。機密情報を入力しない。出力をそのまま使わない。業務利用は申請制とする。

書かれている内容そのものは間違っていません。ただ、この文書を受け取った人が明日から何をしてよいかは分かりません。「機密情報」が自分の扱っている資料を指すのかどうかを、各自が判断することになります。判断の材料がないので、安全側に倒します。すると入力できるのは公開済みの情報だけになり、AIに聞けることは検索の言い換え程度に縮みます。

申請制も同じ形で詰まります。承認者が1人か2人に集まっていると、申請が届いた順に処理されます。1週間待つと分かった時点で、多くの人は申請しません。使うのをやめるか、自分のアカウントで済ませます。

つまり禁止事項の列挙で起きるのは、危険な利用が止まることではなく、業務のなかで通せる経路がなくなることです。ルール文書を点検するときに見るのは、何を禁止しているかではなく、現場が迷わずに通せる経路がいくつ書かれているかになります。

「社内ルール」「利用規定」「ガイドライン」の言い分け

同じ文書が、社内では違う名前で呼ばれます。呼び方が混ざったまま作り始めると、どこまで拘束力があるのか、変えるときに誰の決裁が要るのかで止まります。作る前に整理します。

呼び方	社内での位置づけ	変えるときの手続き
ガイドライン（手引き）	判断のよりどころ。外れても直ちに違反にはならない	所管部署の判断で改定する
利用規定（規程）	社内の規程体系に載る内部規則。違反時の扱いが就業に関する規程とつながる	規程の改訂手続き（決裁・周知）を通す
運用手順・別紙	規定を実行するための表と様式。情報区分表、可否表、申請様式	所管部署の決裁で差し替える

社内ルールという言い方は、この3つをまとめて指す日常語として使われます。制定するときに決めるのは、どの層に何を書くかです。違反したときに人事上の扱いが生じる部分と、社外との契約で守ると約束している部分は規定に置きます。どのサービスにどの情報を入れてよいかは月単位で変わるため、別紙に置きます。

ガイドラインだけで運用している会社は珍しくありません。規定まで作るかどうかの目安は、違反したときにどうするかを文書に書く必要があるかです。書く必要があるなら規定として制定します。無ければ手引きのまま別紙を充実させる方が早く回ります。どちらを選ぶかで、次に見る章立てのうちどこまで要るかが変わります。

そのまま使える利用規定の章立て（9章）

ここからは、規定として社内の規程体系に載せる場合の章立てを見ます。目的や適用範囲、所管部署、改訂手続き、違反時の扱いといった条が要ります。既存の情報管理規程や情報セキュリティ規程と用語が食い違うと、どちらが優先するかで止まるため、用語は既存側に合わせます。

章立てで先に決めておきたいのは、規定の本体に書くことと、別紙に置くことを分ける点です。情報区分と利用形態の可否表は、サービスの契約条件が変わるたびに直す必要があります。これを規定の本体に埋め込むと、1行直すのに規程の改訂手続きが要ることになり、実態と文書がずれたまま放置されます。本体には「別紙の区分表と可否表に従う」と書き、表は所管部署が差し替えられる別紙にします。

章	書くこと	質問を減らすために添えるもの
目的	何のために利用を認めるか	禁止ではなく業務での利用を前提にする旨を1文で書く
適用範囲	誰が、どの端末・アカウントで、どの利用形態を使う場合が対象か	業務委託・派遣・出向者を含むかを明記する
用語の定義	生成AI、情報区分、利用形態の呼び分け	既存の情報管理規程の用語をそのまま使う
利用の原則	通してよい経路と、通す前に確認すること	別紙の区分表・可否表への参照
情報の取り扱い	入力してよい情報の線引きと、出力を業務に使うときの確認責任	置き換え方の具体例、入れてよい例
申請と承認	届出で済む範囲、本審査が要る範囲、返答期限	窓口の連絡先と様式の置き場所
例外	誰がどの範囲まで例外を認められるか、記録の残し方	例外の有効期限
所管と改訂	所管部署、点検の頻度、版の記録	別紙だけを差し替える場合の決裁者
報告と違反時の扱い	事故やヒヤリハットの連絡経路、違反時に何が起きるか	報告した人を不利に扱わない旨

表のうち、書き方で迷いやすいところを補足します。適用範囲でつまずきやすいのは、社員以外の扱いです。業務委託や派遣の方が同じ業務を担っている場合、規定の対象外にすると、同じ資料が対象外の経路で扱われます。契約側でどう縛るかとあわせて決めます。

違反時の扱いは、処分の根拠を新しく作るのか、既存の就業に関する規程に委ねるのかで書き方が変わります。ここは法務と決める部分で、規定側では連絡経路と、報告した人を不利に扱わないことを書くまでに留める形が扱いやすくなります。事故が起きたときに最初に必要なのは、処分ではなく事実の把握だからです。

分量は、本体を数ページに収めて、判断に使う表を別紙に出す形が現実的です。本体が長いほど読まれず、結局は窓口に質問が集まります。

情報を機密度で区分する

線引きの前に、区分が必要です。生成AI用に新しい分類体系を作る必要はありません。情報管理規程や文書管理規程がすでにあるなら、そこの区分に紐づけます。無い場合でも、4段階程度に収めます。

公開済み情報（すでに社外に出しているもの）
社内限（一般的な社内文書、手順書、社内向けの資料）
取扱注意（顧客情報、個人情報、未公表の財務・人事情報）
厳格管理（契約上の守秘義務の対象、法令で取り扱いが制限されるもの、認証情報）

段階を細かくしすぎると、区分を当てる作業そのものが止まります。区分は現場が数秒で当てられる粒度に保ちます。

このとき先に決めておきたいのは、区分を当てにくいものの置き場所です。会議の録音と文字起こし、画面のスクリーンショット、システムのログ、ソースコード、他社から預かったデータ。これらは元の規程に想定がないことが多く、質問が集中します。どの区分に入れるかを最初に決めて、区分表に例として書いておきます。

なお、第三者から預かったデータは自社の機密度区分では決まりません。預かった際の契約の守秘条項が優先します。区分表とは別枠で扱います。

情報区分と利用形態で可否を決める判定表

同じ情報でも、どの経路で使うかによって可否が変わります。生成AIの利用形態は、契約条件の面で次のように違います。

入力したデータが学習に使われるか
入力・出力の保存有無、保存期間、保存される場所
管理者側で利用ログを取得・監査できるか
再委託先（サブプロセッサ）の範囲
利用停止時・退職時のデータの削除方法

個人向けのプラン、法人契約のチャットサービス、API経由、クラウド事業者のサービスとして自社テナント内で使う形では、これらの条件が一致しません。「あのサービスは学習に使われない」といった伝聞で決めず、各サービスの利用規約とデータ処理に関する条件で確認します。条件は契約更新やプラン変更で変わるため、確認した日付と規約の版を記録に残します。

ここまで揃ったら、1枚の表にします。行に情報区分、列に利用形態を置き、各セルに「可」「条件付き可」「不可」を入れます。条件付き可のセルには、条件を具体的に書きます。伏せてから入力する、上長の承認を得る、保存を無効にする設定を確認する、といった内容です。

書き方の例を挙げます。自社の規程と各サービスの規約で確認したうえで、可否と条件は自社で決めます。

情報区分	個人向けプラン	法人契約のチャットサービス	API・自社テナント内の構成
公開済み情報	可	可	可
社内限	不可	可	可
取扱注意	不可	条件付き可（個人が特定できる記載を置き換える／保存を無効にする設定を確認する）	条件付き可（ログの保存先と保存期間を確認する）
厳格管理	不可	不可	条件付き可（守秘条項と法令要件を法務が確認したものに限る）

この表があると、現場から来る質問の多くはその場で解決します。逆にこの表がないまま文章だけでルールを書くと、質問はすべて窓口に集まります。

「迷ったら使わない」で終わらせると、判断が必要な業務ほどAIから外れます。判断できないものの行き先と返答期限まで決めておきます。

入力してよい情報の線引きの粒度

区分と経路が決まっても、「取扱注意の情報は伏せてから入力する」という一文だけでは現場は動けません。何をどう伏せるのかが分からないためです。判断できる粒度まで下ろします。

実在する個人が特定できる記載（氏名、所属、連絡先、社員番号、顧客ID）は置き換えてから入力する。置き換え方も示す（取引先はA社、担当者はXなど）
相手方から受領した未公開の資料は、原文を貼らず、自分が書いた要約と質問に置き換える
認証情報（パスワード、APIキー、アクセストークン）は、検証用のものでも入力しない
金額や件数そのものを渡さず、集計や判断の手順だけを聞く形に置き換えられないか先に検討する

同時に、入れてよいものの例も書きます。禁止例だけを並べると、読んだ人は判断に迷った全件を禁止側に寄せます。「自分が書いた文章の推敲」「公開されている情報の整理」「社内手順書の下書き」のように、確認なしで進めてよい範囲を明示しておきます。

そのうえで、迷ったときの窓口と返答期限を書きます。翌営業日までに一次回答を返す、といった形です。「迷ったら使わない」で終わらせると、判断が必要な業務ほどAIから外れていきます。

例文は各部門から実際の依頼内容を集めて作ります。抽象的な例だけでは、自分の手元の資料に当てはめられません。運用を始めた後は、窓口に来る質問の内容が粒度の点検材料になります。同じ質問が繰り返し来るなら、その項目の書き方が足りていません。

個人アカウントでの生成AI利用をどう扱うか

規程で禁止しても、個人アカウントでの利用は残ります。禁止して失われるのは、利用そのものではなく利用の可視性です。無償で使えるプランは個人のメールアドレスだけで登録できるため、会社側の管理を通りません。

使われている範囲を先に把握する

経費精算・立替申請にAIサービスの支払いが含まれていないか
業務用端末のブラウザ拡張機能の一覧
社内のアカウントに対する外部アプリの連携（OAuth）許可の記録
匿名を含むアンケートで、何にどう使っているかを聞く

アンケートを取るときは、報告した利用を処分の対象にしないことを先に伝えます。伝えないまま集めると、集まった回答は実態を表しません。

正規の経路を用意してから期限を切る

移行の順序を逆にしないことが重要です。先に同等以上のことができる正規の経路を用意し、次に期限を切って移行を依頼し、最後に個人アカウントでの業務利用を規程に位置づけます。正規の経路がないまま通知だけを出すと、報告されない利用に変わるだけです。

正規の経路が揃うまでの期間をどう書くかも決めておきます。空白にすると、各自の判断で使い続けます。公開済み情報に限って個人アカウントでの利用を認める、といった形で、暫定の範囲と期限を明示する方が実態に近づきます。

規程には禁止・条件付き・当面の容認のどれで書くか

書き方	成立する条件	起きやすいこと
禁止する	全員が使える正規の経路があり、機能の差が小さい	差がある機能は個人アカウントに残り、報告されなくなる
条件付きで認める	入れてよい情報を公開済み情報などに絞れる	「公開済み」の当てはめで質問が出る。区分表の例で補う
当面は容認する	正規の経路の導入時期が決まっている	期限を書かないと恒久化する

どれを選ぶかは、正規の経路がどこまで揃っているかで決まります。揃っていない段階で禁止と書くと、文書と実態が離れ、以後どの条も参照されなくなります。容認から始める場合は、いつまでの扱いかと、次の見直し時期を同じ条に書きます。

外部サービスへのアカウント連携は先に許可制にする

なかでも優先度が高いのは、外部のAIサービスに社内のメールやファイルへのアクセスを許可する連携です。テキストを貼り付ける利用と違い、許可した時点で継続的にデータが外へ流れます。しかも設定するのは個人です。管理者側でアプリごとの許可制を先に入れておきます。

どの経路がどれだけ使われているかを継続的に見る方法は AI導入の効果測定と投資判断で扱っています。

ルールを作る側と使う側の役割分担

ルールが更新されなくなる原因の多くは、担当が決まっていないことです。特に「この業務でこの資料を入力してよいか」は、情報システム部門も法務も判断しきれません。その資料に何が書かれているかを知っているのは、業務を持っている部門です。

分担の形としては次のようになります。

情報システム部門：利用形態ごとの技術条件（アカウントと権限の管理、ログ取得、外部連携の許可、保存設定）
法務・コンプライアンス：契約条件と法令の当てはめ、第三者から預かったデータの扱い
業務部門の責任者：自部門が扱う情報がどの区分に当たるかの割り当てと、部門内の例外承認
各部門の担当窓口：日常の質問への一次回答と、判断できないものの引き上げ

あわせて、区分表と可否表の更新担当、点検の頻度、版の記録を決めます。サービスの条件は変わるため、半年で内容が古くなります。

例外を申請する経路も必要です。例外を認めない規程は、破られる形で運用されます。誰がどの範囲まで例外を出せるか、記録をどこに残すかを書いておきます。

社内でAIを作り始めた段階で増える審査観点

チャット画面に文章を貼る利用と、業務に組み込んだAIを動かす利用では、審査する項目が変わります。非エンジニアが自分で作れる環境が整うと、後者が部門ごとに増えていきます。このとき追加で決めておく観点は次のとおりです。

参照範囲。 参照先のデータが、作った人の権限ではなく使う人の権限で絞られているかを確認します。共有フォルダを丸ごと参照させると、元のフォルダ権限では読めない内容まで回答に出てきます。作った時点では気づきにくく、後から範囲を狭めるのは手間がかかります。

実行権限。 読み取りだけか、書き込み・送信・支払い・社外への連絡を伴うかで扱いを分けます。社外に出る動作は人の承認を挟みます。

認証情報の持ち方。 個人のアカウントで動いている場合、その人の異動や退職で止まるか、逆に権限が残ります。誰の権限で動いているかを記録します。

ログ保全。 入力、出力、参照したデータ、実行した操作を、誰がいつまで見返せるかを決めます。保存期間と保存場所、事故が起きたときに経緯を再現できるかまで含めます。

停止手順と引き継ぎ先。 誰が止められるか、止めたときに業務のどこが止まるか、作った人が異動した後は誰が見るかを決めておきます。

追加する観点	確認すること
参照範囲	参照先が、作った人ではなく使う人の権限で絞られているか
実行権限	読み取りだけか、書き込み・送信・支払い・社外への連絡を伴うか
認証情報の持ち方	誰の権限で動いているか。異動や退職で止まるか、権限が残るか
ログ保全	入力・出力・参照データ・操作を、誰がいつまで見返せるか
停止手順と引き継ぎ先	誰が止められるか、止めると業務のどこが止まるか、作った人の異動後は誰が見るか

審査は段階を分けます。自分の担当業務の範囲で、読み取りのみ、社外に出力しない、という条件に収まるものは届出だけにします。部門を越えるデータを参照する、社外へ何かを送る、支払いが発生する場合に本審査を通します。すべてを同じ審査に通すと承認待ちが積み上がり、作る動きそのものが止まります。

社内で作れる人を育てる進め方は AI内製化の進め方、検証から本番運用に載せるまでの工程は AIエージェント開発の進め方で整理しています。

公開した後に改訂していく手順

利用規定は公開した時点から古くなっていきます。使えるサービスも契約条件も、社内でAIを使う場面も、翌月には変わります。改訂の手順を規定に書いていないと、直す人が決まらないまま古い版が残り、現場は文書を見ずに判断するようになります。

まず、改訂の引き金を先に列挙します。日付だけを決めた定例点検にすると、間の期間に起きた変化を拾えません。

改訂の引き金	見直す箇所	決裁
新しいAIサービスを導入する／プランを変える	可否表の列、契約条件の確認日と規約の版	所管部署の決裁で別紙を差し替える
サービス側が利用規約やデータの扱いを変えた	可否表の該当セル、条件付き可の条件	同上。条件が厳しくなる場合は法務が確認する
事故・ヒヤリハットが報告された	線引きの書き方、報告経路、審査の段階分け	所管部署が案を作り、規程の改訂手続きに乗せる
同じ質問が窓口に繰り返し来る	区分表の例、入れてよい例の書き方	所管部署の決裁で別紙を直す
社内で作ったAIが業務に組み込まれ始めた	審査観点、届出と本審査の線引き	規程の改訂手続きに乗せる
法令・ガイドライン・契約条件が変わった	適用範囲、第三者データの扱い、違反時の扱い	法務が確認したうえで改訂手続きに乗せる
定例点検（半年ごとなど）	全体。特に契約条件の確認日が古い行	変更が無ければ点検した記録だけ残す

決裁の重さを分けるのが要点です。別紙の表まで規程の改訂手続きに乗せると、サービス側の条件が変わってから文書に反映されるまで数か月かかります。その間、現場は古い表を見て判断します。本体の条（適用範囲、承認の仕組み、違反時の扱い）は改訂手続きを通し、表の差し替えは所管部署の決裁で回せるようにしておきます。

改訂したら、版番号、改訂日、変更点の要約、適用開始日を残します。過去の版も参照できるようにしておくと、事故が起きたときに「その時点のルールで何が認められていたか」を後から確認できます。

周知は全文の再配布ではなく、変更点だけを1枚にします。全文を配ると読まれず、変わったことに気づかないまま運用が続きます。可否が緩む方向の変更は特に伝わりにくいため、これまで不可だったものが通るようになった点は明示します。

次の改訂で何を直すかは、運用の記録から決めます。窓口に来た質問の内容と件数、例外申請の理由、届出と本審査それぞれの件数と待ち時間。同じ質問が繰り返し来ている項目は、書き方が足りていない箇所です。待ち時間が伸びている場合は、審査の段階分けか承認者の人数を見直します。この記録を残していないと、改訂のたびに担当者の記憶で優先順位を決めることになります。

自社のルールの点検

手元のガイドラインを次の項目で見ると、活用を止める型になっていないかが分かります。

手引きとして配るのか規程として制定するのかが決まっていて、拘束力が要る部分だけ規定に置かれているか
禁止事項だけでなく、通してよい経路が具体的に書かれているか
「機密情報」のような語が、現場が当てはめられる区分に紐づいているか
情報区分と利用形態の可否が1枚で分かるか
迷ったときの窓口と、返答期限が書かれているか
個人アカウントでの利用に対して、代替となる正規の経路が用意されているか
外部サービスへのアカウント連携が許可制になっているか
判断に使う区分表・可否表が別紙になっていて、本体の改訂手続きを通さずに差し替えられるか
更新担当、点検頻度、版が記録されているか
定例点検だけでなく、サービスの条件変更や事故の報告が改訂の引き金として書かれているか
業務に組み込むAIの審査基準が、貼り付け利用と分けて書かれているか

埋まっていない項目が、次に決めることです。文書を全面的に書き直す必要はありません。区分表と可否表の2枚を足すだけで、質問の大半は現場で解けるようになります。

まとめ：使わせながら守るルールにするための要点

禁止事項の列挙で失われるのは危険な利用ではなく、業務で通せる経路である。点検の観点は「何を禁止しているか」ではなく「どう通せるか」
手引き（ガイドライン）・規程（利用規定）・別紙の3層に分ける。違反時の扱いと契約上の約束は規程、可否の表は別紙。呼び方を混ぜると変えるときの決裁で止まる
規定の本体には目的、適用範囲、承認の仕組み、所管部署と改訂手続きを書き、情報区分と可否の表は別紙に出す。表を本体に埋めると1行直すのに改訂手続きが要る
情報区分は新規に作らず既存の規程に紐づけ、4段階程度に収める。区分を当てにくいもの（録音、スクリーンショット、ログ、コード、預かりデータ）の置き場所を先に決める
利用形態ごとに学習利用、保存、ログ、再委託先、削除方法の条件が違う。規約で確認し、確認日と版を記録する
情報区分と利用形態のマトリクスを1枚作り、条件付き可の条件まで書く
線引きは置き換え方の例まで下ろす。入れてよい例も併記し、迷ったときの窓口と返答期限を明示する
個人アカウントの利用は、正規の経路を用意してから期限を切って移行する。規程には禁止・条件付き・当面の容認のどれで書くかを、経路の揃い方から決める。外部サービスへのアカウント連携は先に許可制にする
技術条件は情報システム部門、契約と法令は法務、自部門の情報区分の割り当ては業務部門が持つ。更新担当と点検頻度も決める
業務に組み込むAIには、参照範囲、実行権限、認証情報の持ち方、ログ保全、停止手順の観点を追加する。審査は届出と本審査に分ける
改訂の引き金（サービスの条件変更、事故の報告、窓口への同じ質問、定例点検）を先に列挙し、別紙の差し替えと本体の改訂で決裁を分ける。版と変更点を残し、周知は変更点だけを配る

Augueでは、非エンジニアの方が自部門の業務をAIに任せられるようになるまでの支援のなかで、こうした利用ルールと審査の運用整備も一体で進めています。自社のガイドラインが活用を止める形になっていないか整理したい方は、是非ご相談ください。

まずは現状をお聞かせください

弊社では具体的な要件が固まっていない段階でも、無料相談で現状をお聞きしていますので、お困りの際はご相談ください。

無料相談を予約する →

よくある質問

禁止事項を並べたガイドラインの何が問題なのですか？

危険な利用が止まるのではなく、業務のなかで通せる経路がなくなります。「機密情報を入力しない」と書かれていても、自分の資料がそれに当たるかを各自が判断することになり、材料がないので安全側に倒します。点検の観点は、何を禁止しているかではなく、現場が迷わず通せる経路がいくつ書かれているかです。

他社や業界団体のひな形をそのまま使ってよいですか？

章立ての参考にはなりますが、可否の中身までは流用できません。ひな形が想定している契約形態と、自社が実際に契約しているプランやテナントの条件が一致しないためです。目的や適用範囲、改訂手続きといった枠はひな形に寄せ、どの情報をどの経路で扱ってよいかは自社の規程と各サービスの規約を見て埋めます。

情報の区分は新しく作るべきですか？

既存の情報管理規程や文書管理規程があれば、その区分に紐づけます。無い場合でも4段階程度に収めます。細かくすると区分を当てる作業自体が止まります。会議の録音、スクリーンショット、ログ、ソースコード、他社から預かったデータは質問が集中するため、置き場所を先に決めて区分表に例として書いておきます。

第三者から預かったデータはどの区分に入れますか？

自社の機密度区分では決まりません。預かった際の契約の守秘条項が優先します。区分表とは別枠で扱い、契約条件の確認を法務が持ちます。

「学習に使われない」かどうかは何で確認すればよいですか？

各サービスの利用規約とデータ処理に関する条件で確認します。伝聞で決めないでください。学習利用のほかに、入出力の保存有無と保存期間、管理者側でログを取得できるか、再委託先の範囲、利用停止時の削除方法も確認します。条件は契約更新やプラン変更で変わるため、確認した日付と規約の版を記録に残します。

個人アカウントでの利用が見つかったらどうしますか？

順序を逆にしないことが要点です。先に同等以上のことができる正規の経路を用意し、次に期限を切って移行を依頼し、最後に個人アカウントでの業務利用を規程に位置づけます。実態を把握するためのアンケートでは、報告した利用を処分の対象にしないことを先に伝えます。

申請制にすると承認待ちで止まります。どうすればよいですか？

情報区分と利用形態の可否を1枚の表にすると、質問の多くはその場で解決します。審査も段階を分けます。自分の担当業務の範囲で読み取りのみ、社外に出力しないものは届出だけにし、部門を越えるデータを参照する場合や社外へ送る場合に本審査を通します。窓口には返答期限を書きます。

社内でAIを作り始めたら、追加で何を見ますか？

参照範囲（使う人の権限で絞られているか）、実行権限（読み取りだけか、書き込みや送信を伴うか）、認証情報の持ち方（誰の権限で動いているか）、ログ保全（誰がいつまで見返せるか）、停止手順と引き継ぎ先の5つです。文章を貼り付ける利用とは審査基準を分けて書きます。