生成AIの社内利用について、「禁止したままでは競争力を失う」「かといって全面解禁は怖い」という板挟みで止まっている組織は少なくありません。この記事では、社内規程に盛り込むべき7つの項目を具体的に示したうえで、部門ごとのリスク度合いに応じて利用範囲を三段階に分ける中間解の設計方法を解説します。規程を作ること自体が目的化せず、現場が実際に運用できる形に落とし込むための観点をまとめました。
なぜ「禁止」も「放任」も機能しないのか
生成AIの利用を全面禁止した組織でよく起きるのが、個人アカウントによる利用の常態化です。会社が提供しないと、従業員は自分のスマートフォンやプライベート端末で使います。この状態は、会社としては最も制御が効かない状態です。何が入力されたかも、どんな出力が業務に使われたかも把握できません。
一方で「常識の範囲で使ってください」という放任も機能しません。生成AIのリスクは、情報漏えい、著作権、出力の誤り、外部への説明責任といった複数の領域にまたがっており、何が「常識」なのかが人によってまったく違うためです。営業担当者にとっての「顧客情報」と、法務担当者にとっての「顧客情報」は範囲が異なります。
必要なのは、リスクの高い行為だけを明確に禁じ、それ以外は自由に使わせる線引きです。禁止事項を具体的に書けば書くほど、それ以外の領域での自由度が上がります。
規程に盛り込む7項目
1. 適用範囲と対象サービスの定義
「生成AI」という言葉だけでは範囲が曖昧です。チャット型のサービスだけを想定していても、実際には議事録の自動要約ツール、コード補完ツール、翻訳サービス、資料作成ツールなど、生成AIを内部で使う製品が業務のあちこちに入り込んでいます。
規程では、会社が正式に契約し利用を認めるサービスを一覧で管理し、その一覧をどう更新するか（誰が申請を受け、誰が承認するか）まで定めます。一覧にないサービスを業務で使う場合の申請ルートを明記しておくことが実務上は重要です。
2. 入力してはならない情報の定義
最も具体的に書くべき項目です。抽象的なカテゴリ名だけを並べず、自社の実際のデータに即して例示します。
| 区分 | 例 | 扱い |
|---|---|---|
| 入力禁止 | 個人情報、顧客から秘密保持契約下で受領した資料、未公開の財務情報、認証情報 | いかなるサービスにも入力しない |
| 条件付き可 | 社内の業務手順、非公開だが機密性の低い企画書 | 学習に利用されない契約のサービスのみ |
| 制限なし | 公開済みの情報、一般的な知識に関する質問 | 自由に利用可 |
ここで判断が分かれやすいのが、「顧客名を伏せれば入力してよいか」という点です。伏せ字にしても文脈から特定できるケースがあるため、匿名化の水準についても具体例で示しておくと現場が迷いません。
3. 契約条件の確認基準
入力データが学習に使われるかどうかは、同じ提供事業者でもプランや設定によって異なります。規程では、利用を認めるサービスの条件として「入力データが学習に利用されないこと」「データの保存期間と保存場所」「サブプロセッサの有無」などを確認項目として定め、確認の記録を残す運用にします。
4. 承認フローと利用申請
新しいサービスを導入したい部門が、誰にどんな情報を出せば承認されるのかを定めます。申請項目としては、利用目的、入力する情報の種類、想定される出力の使途、代替手段の有無あたりが最低限です。
承認に時間がかかりすぎると申請せずに使う人が出るため、判断の期限を決めておくことをおすすめします。低リスクの用途については情報システム部門の判断のみで完結させ、機密情報を扱う場合だけ上位の会議体に上げるといった二段構えが現実的です。
5. 出力物の検証責任
生成AIの出力をそのまま外部に出したことによる問題は、最終的に出した人と組織の責任になります。規程には、出力の事実確認を誰が行うか、どの用途では第三者のレビューを必須とするかを書きます。
特に、契約書のドラフト、外部への技術的な回答、数値を含む資料については、AIの出力を根拠として使わないことを明示しておくと安全です。
6. ログの取得と保全
問題が起きたときに、何が入力されたのかを追えるかどうかが対応の分かれ目になります。法人向けプランでは管理者が利用状況を確認できる機能を備えているものがあり、そうしたサービスを選ぶこと自体が統制の一部です。
併せて、ログの保存期間、閲覧できる人の範囲、閲覧の際の手続きも定めます。従業員の監視という誤解を招かないよう、何のために取得し、どういう場合に見るのかを事前に周知しておくことが必要です。
7. 外部提供時の表示と取引先への説明
納品物や顧客向け資料に生成AIを使った場合の扱いは、業種によって求められる水準が異なります。取引先との契約に、成果物の作成過程に関する条項が含まれていないかの確認も必要です。
自社が生成AIを使ってサービスを提供する場合は、利用者にその旨をどう伝えるかも規程の対象になります。
部門別の三段階運用
全社一律のルールにすると、リスクの高い部門に合わせて厳しくなりすぎるか、低い部門に合わせて緩くなりすぎるかのどちらかになります。部門やデータの性質に応じて三段階に分ける方法が扱いやすい設計です。
| 段階 | 想定部門・用途 | 利用可能な範囲 | 統制 |
|---|---|---|---|
| レベル1（標準） | 総務、広報、一般的な文書作成 | 公開情報・社内一般情報の入力可 | 事前研修の受講のみ |
| レベル2（制限） | 営業、開発、企画 | 学習に利用されない契約のサービスに限定。顧客情報は匿名化を経て一部可 | 利用ログの定期確認、四半期ごとの棚卸し |
| レベル3（厳格） | 人事、法務、経理、機微情報を扱う部門 | 閉じた環境で稼働するサービスのみ。用途を個別に承認 | 案件ごとの申請と記録 |
重要なのは、部門で機械的に分けるのではなく「扱うデータ」で分けることです。営業部門でも、公開済みの製品情報をもとに提案書の構成案を作るのはレベル1相当、顧客の内部資料を要約するのはレベル3相当と考えられます。規程には部門名ではなくデータの区分で書き、部門ごとの標準レベルを別表で示す構成が運用しやすくなります。
規程を作った後にやること
規程は配布しただけでは読まれません。実際に効かせるには次の三つが必要です。
- 具体例の提示：「この作業はやってよい／この作業は駄目」を、部門ごとに10例程度まとめた補助資料を作る
- 相談窓口の設置：判断に迷ったときに即座に聞ける場所を用意する。窓口に来た質問は、そのまま次回の規程改訂の材料になる
- 見直し周期の明示：サービス側の仕様や契約条件は変わります。半年から1年ごとに、認可サービス一覧と契約条件を棚卸しする日程を規程本文に書き込んでおく
規程は完璧なものを一度で作るより、粗くても運用を始めて、現場から出た疑問で埋めていくほうが実態に合ったものになります。
よくある質問
Q: 規程を作る前に、まず何から着手すべきですか
A: 現在の利用実態の把握です。すでに誰がどのサービスを使っているかを、責任追及ではない形でヒアリングします。実態を知らずに作った規程は、現場の作業と噛み合わず形骸化しやすくなります。把握した用途を、前述の三段階のどこに当たるかで分類していくと、規程で優先的に定めるべき論点が見えてきます。
Q: 従業員が個人アカウントで使っているのを止めさせるには
A: 禁止の周知だけでは効果が限定的です。会社として使えるサービスを用意し、個人アカウントより使いやすい状態を作ることが前提になります。そのうえで、個人アカウントでの業務利用を禁じる根拠を規程に明記し、違反時の扱いも定めておきます。使える手段を提供せずに禁止だけを強めると、かえって把握できない利用が増えます。
Q: 小規模な組織でも規程は必要ですか
A: 分量は組織規模に応じて調整できますが、入力禁止情報の定義と、利用を認めるサービスの一覧は規模を問わず必要です。この二つだけでもA4一枚にまとめて共有しておけば、最も重いリスクは相当程度抑えられます。承認フローや詳細な段階分けは、利用が広がってから追加しても遅くありません。
まとめ
生成AIの社内規程は、禁止事項を具体的に書くことで、それ以外の自由を担保する仕組みです。適用範囲、入力禁止情報、契約条件、承認フロー、出力の検証責任、ログ保全、外部提供時の表示という7項目を押さえ、扱うデータの性質に応じた三段階の運用に落とし込むことで、過度な制限にも放任にもならない線引きが可能になります。
作成後は具体例の提示と相談窓口の運用が実効性を左右します。まずは利用実態の把握から始め、現場の疑問を吸い上げながら改訂していく前提で設計してください。
