生成AIに合わせて社内規程を見直す方法｜既存条文の改訂例つき

社内で生成AIの利用ルールを決めるときも、外部サービスの承認手順や情報区分のように、すでにある規程で決まっていることはそのまま使えます。生成AIを使うときに初めて問題になる条件だけを条文か別表に書き足し、どの文書を直すのか、直した内容を誰が承認するのかも改訂作業のなかで一緒に決めます。

この記事では、すでに規程が整っている会社を想定して、新旧対照表を作るところから説明します。掲載した条文は説明のために作った例です。実際に改訂するときは、自社の定義や契約、規程の承認手続きに合わせて文言を直してください。

見直す規程と条文

まず、情報セキュリティ規程や外部サービスの利用規程を読み返します。AIという言葉が一度も出てこない規程でも、機密情報の外部送信やアカウント管理のルールは、生成AIの利用にそのまま当てはまることがあります。たとえば機密情報を外部サービスへ送る前に承認を得る決まりがあるなら、生成AIへの入力がそこに含まれるかを確かめます。AIで作った文書を社外に出すときの承認についても、既存の規程に定めがないか見ておきます。

確認する文書	既存の条文で確かめること	生成AIを使うと新たに確認が必要になること
情報セキュリティ規程	情報区分と社外へ提供する条件	添付ファイルや検索機能から渡す情報も対象に入るか
外部サービス利用規程	承認者、対象契約、許可された用途	承認したプランや機能をどこで確認できるか
文書の承認手順	顧客へ出す前に誰が何を確認するか	AIで作成した数値や仕様の照合を誰が担うか
アカウント管理手順	発行、権限変更、退職時の停止	外部アプリへの接続権限も停止対象として追えるか

表の項目ごとに対応する条文番号を書き出して、一覧にしておきます。条件を満たしている条文はそのまま残し、足りないところだけ改訂案を作ります。同じ条件を複数の文書に書き足すと、次に変えるとき片方だけ古いまま残りがちなので、条件を正式に書く文書は一つに決めておきます。

条文の改訂例

架空の会社を例に、旧条文と改訂案を新旧対照表にしました。旧条文のどこが足りないかを見せるために、内容はかなり簡略化しています。

旧条文の例	足りない点	改訂案の例
外部サービスは管理部の承認を得て利用する。	承認の範囲がサービス名だけで、機能や用途を特定できない	利用者は、承認一覧に定める契約、用途、機能及び設定の範囲内で外部サービスを利用する。
機密情報は会社の許可なく外部へ送信しない。	ファイル添付や外部アプリ接続を、外部提供として判断できるか不明	外部サービスへの情報提供には、入力、添付、及び接続先からの取得を含む。情報区分ごとの提供条件は、情報取扱基準に従う。
対外文書は所属長の承認を受ける。	所属長へ回す前の事実確認が担当者任せ	作成者は、AI生成箇所に含まれる数値、商品仕様及び約束事項を所管資料と照合し、その根拠を確認者へ示す。送付の承認は対外文書承認手順に従う。
サービスの追加は事前に申請する。	既存サービスの機能追加が申請対象に入らない	承認範囲を超える情報の取扱い、接続先又は実行権限の変更は、変更申請の対象とする。

条文を直しても、入力してよい情報が増えるわけではありません。機密情報の条文に送信の定義を補っても、情報取扱基準や契約の条件を満たさなければ、その情報は入力できません。社内で承認を出したからといって、取引先と交わした約束が変わることもありません。

承認一覧や変更申請という言葉を条文に入れたら、その一覧と申請の受付先も実際に用意してください。条文には書いてあるのに別表が見つからない状態では、社員は判断のしようがありません。

本文と別表の使い分け

規程本文には、判断の原則と責任者、従うべき手続きまでを書きます。どのサービスのどの機能を使ってよいかは頻繁に変わるので、別表に切り出しておけば、そのたびに本文を改訂せずに済みます。

承認一覧の1行の例

営業部が、会社で契約したサービスAを、公開済みの商品説明の文章整理に使う。入力はチャットのみで、外部アプリとの接続は認めない。仕様は商品担当者が確認し、管理責任者は情報システム担当とする。承認日と次回の確認日を記録する。

1行にここまで書いてあれば、社員は自分の使い方が承認の範囲内かどうかを確かめられます。別表を誰が変更できるかは、本文か既存の規程管理手順で決めておきます。担当者が更新しやすい文書に分けたとしても、禁止範囲まで担当者の判断で変えてよいことにはなりません。

改訂時の確認同じ別表の更新でも、サービス名を足すとき、入力できる情報を広げるとき、送信の権限を加えるときで、確認する担当者は変わります。別表を更新した人と、その内容を承認した人は分けて記録してください。

改訂の手順

改訂案を関係部門に回すときは、変更の理由も添えます。「生成AIに対応するため」とだけ書くより、「外部アプリ接続を認めるかどうかを既存の条文では判断できない」と具体的に書いた方が、受け取った部門も何を確認すればよいか分かります。

対象の文書と条文番号を特定し、変更のきっかけになった業務の例を書き添える。
情報管理、契約、業務上の確認工程について、それぞれの担当者に照会する。回答が来ていない部分は保留として残しておく。
別表や申請書、説明資料にも同じ変更が必要かを確かめ、版を揃える。
承認日と適用日を分けて記録し、旧版を指しているリンクや共有フォルダを差し替える。

適用日より前から試験的に使っている部署があるなら、移行時の扱いも書いておきます。新しい条件のまま続けてよいのか、追加の確認が済むまで止めるのかは、案件ごとに決めます。

国の指針と照らし合わせるなら、経済産業省が公開しているAI事業者ガイドラインから確認を始めるとよいでしょう。この記事では第1.2版を参照しました。どの版を参照したかを改訂記録に残しておくと、ガイドラインが更新されたときに見直す範囲がすぐ分かります。

よくある質問

AI専用の規程を新しく作る必要がありますか

必ずしも作る必要はありません。既存の規程と別表で利用条件を整理できるなら、まずは改訂で対応できます。ただ、社員が複数の文書を行き来しないと判断できない状態なら、参照先をまとめた利用ガイドを別に用意した方が判断しやすくなります。その場合も、正式な条件を定めた規程と、説明のための資料は分けて管理します。

新機能を追加するたびに、規程本文の改訂が必要ですか

本文で定めた権限と手続きの範囲に収まる変更なら、別表の更新だけで済むことがあります。ただし、入力する情報や操作の権限が変わる場合は、承認済みのサービスであっても改めて確認が必要です。どちらに当たるかは、自社の変更承認の手順に沿って判断してください。