マネージャー向け

生成AIの利用規程に何を書くか — 他社がつまずく5つの箇所

この記事の結論
  • 規程が守られない主因は厳しさではなく、現場が自分のケースを判断できないこと
  • 「原則禁止・個別承認」は申請が滞留して形骸化しやすい。データ種別で既定を決めるほうが回る
  • 出力の責任所在と、AI利用の記録をどこまで求めるかを先に決めないと、後から揉める

規程が守られない理由は「厳しさ」ではない

生成AIの利用規程を作ったあと、現場から同じ質問が繰り返し寄せられる状態になったら、規程の書き方に問題があります。

守られない規程の多くは、厳しすぎるのではなく自分のケースが該当するか判断できないものです。「機密情報の入力を禁止する」と書かれていても、目の前の議事録が機密情報にあたるのかは書いていない。結果として、律儀な人は使わなくなり、そうでない人は自己判断で使います。

規程の目的は禁止することではなく、現場が迷わず判断できる状態を作ることです。以下は、実際に問い合わせが集中する5つの論点です。

1. 入力してよいデータの線引き

最もよく聞かれる論点です。抽象的な分類語(機密情報、重要情報)ではなく、社内で実際に使われている文書名で書くと問い合わせが激減します。

禁止      顧客名簿、個人情報を含む問い合わせ履歴、
          未公開の決算資料、ソースコード、締結済み契約書

条件つき  社内議事録、企画書の下書き、社外提出前の提案書
          → 会社が契約したサービスに限る

自由      公開済みのプレスリリース、一般的な調べもの、
          自分で書いた文章の推敲

判断に迷ったら禁止側に倒すという原則を添えておくと、境界事例の問い合わせが減ります。

2. 「原則禁止・個別承認」にするかどうか

新しいAIツールを使うたびに申請させる方式は、統制としては筋が通っていますが、申請が滞留して形骸化することが多い箇所です。

情報システム部門の処理能力を超えると、申請が数週間止まります。すると現場は申請せずに使うか、使うのをやめるかの二択になります。前者なら統制は効いておらず、後者なら業務効率を落としているだけです。

代替案は、ツール単位ではなくデータ種別で既定を決める方式です。会社が承認したサービスを1つ用意し、そこで扱ってよいデータを1で定義しておけば、個別申請は「承認済みサービス以外を使いたい場合」に限定できます。申請件数が1桁変わります。

3. 出力の責任は誰にあるか

生成AIの出力をそのまま社外に出して誤りがあった場合、責任の所在を規程に書いていないと、事後に揉めます。

実務上は、AIを道具として使った人が成果物の責任を負うと明記するのが一般的です。表計算ソフトの計算式を間違えた場合と同じ整理です。

そのうえで、次の点を具体的に書きます。

3つめは軽視されがちですが、実在しない論文や条番号が生成される事例は継続的に報告されています。

4. AI利用の記録をどこまで求めるか

「AIを使ったことを記録に残すか」は、決めておかないと後から統一できない箇所です。

すべての利用を記録させると現場の負担が大きく、実際には守られません。一方でまったく記録しないと、問題が起きたときに影響範囲を追えません。

現実的な線は、社外に出る成果物と、意思決定の根拠になる文書に限って記録するというものです。記録の粒度も「AIを利用した」という事実だけで足りる場合が多く、対話内容の保存まで求めると運用が続きません。

なお、EUで事業を行う場合は AI Act により、用途によって透明性の義務が生じます。国内のみの事業であっても、取引先から利用状況の開示を求められる場面は増えています。

5. 規程の見直し頻度を決めておく

生成AIの環境は、サービス仕様も規制も動き続けています。規程に見直し時期を書いていないと、実態と乖離したまま放置されます。

年1回の定期見直しに加えて、次の場合は臨時で見直すと明記しておくと、更新の判断が属人化しません。

規程のひな形として使える構成

1. 目的と適用範囲(誰に適用されるか。業務委託先を含むか)
2. 用語の定義(生成AI、承認済みサービス、業務利用)
3. 入力してよいデータ / いけないデータ  ← 具体的な文書名で
4. 利用できるサービス(承認済み一覧と、それ以外の申請手順)
5. 出力の取り扱いと責任の所在
6. 記録の対象と保存期間
7. 違反時の取り扱い
8. 見直しの時期と契機

3と5でつまずく企業がほとんどです。ここに具体性があるかで、規程が使われるかどうかが決まります。

導入前の確認項目は生成AI導入セキュリティチェックリスト、把握できていない利用への対処はシャドーAIをどう把握し、どこまで禁止するかを参照してください。

まとめ

この記事を読んだあとに