社内生成AI利用ルールをどう作るか｜申請・審査・禁止事項の実務設計

なぜ生成AI利用ルールは「禁止事項」だけでは足りないのか

生成AIの社内ルールを作ろうとすると、多くの企業でまず「何を禁止するか」から議論が始まります。個人情報を入れてはいけない、秘密情報を入れてはいけない、社外秘を出力させてはいけない——これらは必要ですが、禁止だけでは制度として機能しません。

禁止列挙型ルールが機能しない3つの理由

1. 現場が「では何ならできるのか」が分からない——禁止事項しか書かれていない規程は、結果として「よく分からないから隠れて使う」シャドーAI利用を生みます。
2. 利用区分が設計されていない——すべての業務を同じ統制レベルで縛ると、定型業務まで承認を要求することになり、ルールが現場から敬遠されます。
3. 申請・審査・教育・違反対応が接続されていない——ルール本体と運用フローが分離していると、規程はあるのに誰もゲートキーパーになっていない状態が生じます。

参照すべき外部規範

社内ルールを設計する際は、以下を参照基盤として押さえておきます。

社内ルールに入れるべき基本項目

社内生成AI利用規程は、最低限、以下の項目をカバーしておく必要があります。単体で完結させず、就業規則・情報管理規程・情報セキュリティ規程との整合をとることが前提です。

表1：社内生成AIルールに入れるべき項目一覧

利用区分ごとの設計

社内ルールを「全面禁止か全面解禁か」という二者択一にすると、どちらを選んでも制度として歪みます。実務的には、業務の性質とリスクに応じた3段階程度の利用区分を設け、それぞれに統制レベルを対応させるのが合理的です。

3段階モデルの考え方

• 自由利用：公開情報のみを扱う、汎用的な調査・要約・表現調整等。個別承認不要。
• 条件付利用：社内情報の一部を扱うが、機微情報・個人情報・営業秘密を含まない業務。入力制限の遵守とログ記録が前提。
• 要申請利用：個人情報・営業秘密・取引先情報を扱う可能性がある業務、または社外提出物の生成。用途・データ範囲・承認者を特定した事前申請を要する。

ホワイトリスト型包括承認の併用

要申請利用の範囲を広く取ると、申請件数が膨張し、審査が滞留してシャドーAI利用の誘因になります。そこで、法務・情シスが事前に安全性を確認した「特定ツール×特定プロンプト×特定業務」の組み合わせについては、個別申請を要さず、部門単位の包括承認で足りるとする運用を併走させる設計が合理的です。契約書レビュー補助・定型契約ドラフト・議事録要約など、反復性が高く統制可能な業務から順にホワイトリスト化していくと、要申請利用の乱用とシャドー利用の双方を抑えられます。

表2：利用区分別の統制レベル比較表

利用区分を設計するときの3つの視点

1. データ機微性——入力されるデータが公開情報か、社内情報か、個人情報・営業秘密かで区分を切る。
2. 出力の使途——社内メモか、社外文書か、意思決定の基礎資料か。使途が外部に向くほど統制を強める。
3. 責任の所在——誰がその出力に署名・承認するのかを事前に決めておく。決定者不在の出力は作らない。

申請・審査・承認フローの考え方

要申請利用の範囲を決めた次に設計すべきは、「誰が・何を・どこまで見るか」という審査の設計です。ここが曖昧だと、申請は上がってきても承認が滞留し、最終的に現場がフォームを回避するようになります。

申請フローの基本構造

• 申請：利用者が用途・対象業務・入力データ種別・期間を申請書に記載。
• 一次審査（情シス）：ツール選定の適否、技術的統制（入力ログ、学習拒否設定、リージョン等）の確認。
• 二次審査（法務）：契約上の制約（NDA・顧客契約・ベンダー契約）、個人情報保護法・著作権・弁護士法72条等の法令適合性。
• 三次審査（人事・コンプラ）：就業規則・情報管理規程との整合、懲戒連動、教育要件の充足。
• 承認・登録：権限者による承認後、利用登録台帳に反映。有効期限・再審査タイミングを設定。

新規ベンダー導入と社内利用の接続

社内利用ルールは、ベンダーとの契約審査と切り離せません。入力データの学習利用可否、データ保存期間、サブプロセッサーの所在、モデル更新時の挙動変更、インシデント通知義務——これらが契約で抑えられていないツールを社内ルール上「要申請利用」枠に入れても、入力情報の行方をコントロールできません。ベンダー契約で確保できていない水準は、社内ルールでも実現できないという前提で、契約審査と社内ルールを連動させる必要があります。

取引先NDA等による「上書き」への注意

近年の取引先NDAや業務委託契約では、「第三者提供禁止」にとどまらず、「自動処理・機械学習による処理の禁止」「AIを含む再委託についての事前承諾」を明記する例が増えています。社内ルールで「要申請利用」としてハードルを設定していても、個別の顧客契約・NDAがそれより厳しい制約を課している場合は、契約条件が社内ルールを上書きする点を現場に周知する必要があります。審査フローの中に「対象業務に紐づくNDA・顧客契約の確認」を明示的なステップとして組み込むのが安全です。

表3：法務・情シス・人事・事業部の役割分担表

教育・周知・違反対応

規程は作って終わりではなく、守られる状態をいかに作るかが設計の本体です。教育・周知・違反対応は三位一体で設計します。

教育の設計

• 初期研修——入社時・配属時に必須受講。入力禁止情報、申請フロー、違反時の影響を具体例ベースで扱う。
• 定期研修——年1回以上、法改正・ガイドライン改訂・ツール変更を反映。受講履歴を人事側で管理。
• ケーススタディ型教育——実際に起きた入力事故・出力事故を匿名化して教材化する。抽象論より定着率が高い。

周知の設計

規程本文そのものを全社員に読ませることを目的にせず、利用シーンごとの「簡易ガイド」「1枚マニュアル」「部署別FAQ」に分解して届けます。就業規則・情報管理規程の該当条項とのマッピング表を併せて提示すると、現場の納得感が変わります。

違反対応の設計

• 相談窓口——「迷ったら事前に相談できる」ルートを明示することが、事後対応より効果的です。
• インシデント発生時のフロー——発見→一次報告→原因調査→影響評価→是正→再発防止→記録保全、までを定型化。
• 懲戒連動——就業規則の懲戒事由に、情報管理規程違反・社内規程違反として位置付けておく。生成AI利用規程を孤立させない。

チェックリスト

まとめ