RAKUDA AI INSIGHTS

生成AIの社内ルールを作る手順|禁止事項・例外・更新責任の決め方

生成AIの社内ルールは、禁止事項を書くだけでは完成しません。経営承認、利用実態の棚卸し、区分案、レビュー、施行、例外申請、改定までをつなぎ、各工程の担当者・入力・成果物・完了条件を決めます。専任AI部門がなくても、役割を分けて記録すれば実行可能です。

生成AIの利用実態と既存規程を、担当者のレビューと承認を経て社内ルール・例外記録・更新履歴へまとめる流れ

生成AIの社内ルールは、禁止事項を書くだけでは完成しません。経営承認、利用実態の棚卸し、区分案、レビュー、施行、例外申請、改定までをつなぎ、各工程の担当者・入力・成果物・完了条件を決めます。専任AI部門がなくても、役割を分けて記録すれば実行可能です。

作り始める前に全工程と完成物を確認する

生成AIの社内ルール作りは、経営承認から施行後の改定までを一つの業務フローとして設計し、ルール本文と運用記録の両方を完成させる作業です。

この記事では実務を次の8工程に分けます。8という数は、公的資料が定める必須のステップ数ではなく、従業員50〜300人で専任AI部門がない企業が作業を分担しやすいように整理したものです。

総務省・経済産業省の「AI事業者ガイドライン(第1.2版)」は、環境・リスク分析、ゴール設定、運用、評価、環境・リスクの再分析と継続改善という流れを示しています。ただし、同ガイドラインは非拘束的なソフトローであり、社内規程の作成を法令上の義務として定めるものではありません。

工程 主担当 レビュー・承認者 入力 成果物 次へ進む条件
1. 経営承認・所管決定 経営者、AI導入責任者 最終承認者 利用目的、対象範囲、想定リスク 目的、適用範囲、役割表、承認経路 誰が決め、誰が更新するか明記されている
2. 現状の棚卸し 事務局、現場代表 情報管理・情シス 利用サービス、業務、入力情報、出力先、既存規程・契約 利用実態一覧、参照資料一覧 未承認利用を含めて現状を把握できている
3. 利用区分案の作成 所管者、現場代表 情報管理、法務・個人情報担当 棚卸し結果、公式資料 通常利用・条件付き利用・禁止の区分案 区分理由と人が判断する条件を説明できる
4. 相談・報告経路の設計 所管者 情シス、法務、労務 既存の申請・事故対応フロー 問い合わせ先、例外申請、事故報告、記録先 実在する担当者と連絡手段が決まっている
5. 草案作成 事務局 所管者 前工程の成果物、利用可能なひな形 本文、別表、申請様式、変更履歴欄 自社固有の名称や条件が入り、空欄がない
6. 横断レビュー・承認 所管者 現場、情報管理、法務・個人情報、労務、経営 草案一式 指摘一覧、対応記録、承認記録 重大な未解決論点がなく、施行が承認されている
7. 施行・周知・移行 所管者、総務・社内広報 経営、各部門長 承認版、対象者一覧 施行通知、保管場所、移行案内 対象者が最新版と窓口へアクセスできる
8. 運用・改定 所管者 確認担当、最終承認者 問い合わせ、例外、事故、契約・機能等の変更 確認記録、改定判断、改定版、再周知記録 変更理由、承認者、適用開始日を追跡できる

社内ルールの目的や盛り込む領域を詳しく検討したい場合は、「生成AIの社内ルールとは?盛り込む項目と運用の判断基準」で判断軸を確認し、本記事では作成工程へ集中してください。周辺テーマを探す場合は、AI関連記事一覧も参照できます。

経営承認・所管者・最終承認者を決める

最初に、利用目的と許容するリスクを経営が承認し、日常の所管者と最終承認者を記録上で明確に分けます。

「AI事業者ガイドライン(第1.2版)」は、各主体にアカウンタビリティを果たす責任者を設定する考え方を示しています。一方、部署名や人数までは指定していません。そのため、専任AI部門を新設することを前提にせず、既存の経営企画、情シス、総務、法務などから自社の実態に合う担当を置けます。

兼務は可能ですが、草案を書いた人が自分の例外申請を承認し、さらに最終承認まで完結する状態は避けます。少なくとも記録上は、草案作成者、例外申請者、最終承認者を区別してください。

役割 担当する判断 記録する内容 兼務時の注意
経営スポンサー・最終承認者 利用目的、適用範囲、リスク許容、施行 承認日、適用開始日、承認条件 高い影響を持つ例外の最終判断を現場任せにしない
ルール所管者 正本管理、問い合わせ、改定起票 所管部署・氏名、連絡先、版、変更履歴 事務局を兼ねても、自己承認だけで改定しない
事務局・草案担当 棚卸し、会議運営、草案、指摘管理 入力資料、草案版、指摘への対応 判断権限の所在を文書上で曖昧にしない
関係者レビュー担当 現場適合、情報管理、契約、個人情報、労務の確認 指摘、根拠、反映・不採用理由 全部署を一律参加させず、論点に必要な担当を選ぶ
例外承認者 用途、期間、条件、低減策の審査 承認・否認理由、条件、期限 申請者本人だけで判断しない
運用確認担当 例外、事故、問い合わせ、変更の確認 確認結果、要改定・変更不要の判断 可能なら対象利用への関与が薄い人を含める

この工程の完了条件は、役職名を並べることではありません。「誰が草案を作り、誰が論点を確認し、誰が施行を承認し、誰が改定を起票するか」を一件ごとにたどれる状態です。

利用状況と既存規程・契約を棚卸しする

草案を書く前に、利用中・利用希望のサービス、対象業務、入力情報、出力の利用先、既存規程と契約条件を同じ一覧へ集めます。

ヒアリングでは「使ってよいサービス」だけでなく、現場が個人アカウント等で試している未承認利用も把握します。処罰のための調査にすると申告されにくいため、現状をルールへ反映するための棚卸しであることを先に伝えます。

最低限、各利用場面について次を記録します。

  • サービス名、契約・アカウントの種別、管理者
  • 利用部門、対象業務、利用目的、利用者の範囲
  • 入力する情報の種類と社内の情報区分
  • 出力を社内下書き、顧客対応、公開物、意思決定のどこに使うか
  • 外部送信、更新、確定、削除などの操作があるか
  • 利用規約、プライバシーポリシー、契約、管理者設定の確認者と確認日
  • 関連する情報セキュリティ規程、個人情報保護規程、就業規則、秘密保持契約

個人情報は「すべて法律上一律禁止」と単純化せず、区分して確認します。個人情報保護委員会の2023年6月2日の注意喚起は、個人情報を含むプロンプトについて、特定した利用目的を達成するために必要な範囲内か確認するよう示しています。また、本人の同意なく個人データを入力し、それが応答結果の出力以外の目的で取り扱われる場合には法令違反となる可能性があるため、提供者が機械学習に利用しないことなどを十分に確認するよう示しています。

したがって、棚卸しでは「個人情報」と「個人データ」を混同せず、利用目的、本人同意の状況、提供者による取扱い、契約・設定、自社の既存規程を分けてレビューします。そのうえで、自社方針として禁止または条件付き利用に分類します。

利用区分案と人の判断を介在させる条件を作る

棚卸し結果を通常利用・条件付き利用・禁止の区分案へ変換し、重大な影響や被害が生じ得る場面だけに必要な人の判断を設計します。

この3区分は、法令が定める必須の分類数ではなく、社内で判断をそろえるための編集上の整理です。区分表には個々の禁止事項を長く並べるのではなく、対象業務、入力情報、出力先、外部操作、確認者、判断理由を記録します。

「AI事業者ガイドライン(第1.2版)」のAI利用者向け部分は、出力によって重大な影響または被害が生じ得る場合に、人間の判断を適宜介在させる考え方を示しています。すべての入力や出力に一律の上長承認を置く趣旨ではありません。

たとえば、社内だけで使う文章のたたき台と、顧客への確定回答、採用・評価等の判断、外部への公表、データの更新・削除では影響が異なります。影響が大きい場面は、担当分野を理解する人の確認、根拠資料との照合、承認記録などを条件にします。法令、契約、サービス規約、既存の社内規程で許されない利用は、社内の例外承認で解除できないため禁止に分類します。

なお、「ユーザーやシステムに付与する権限を業務遂行に必要な最小限に設定する」はAI提供者向け、「AIの判断に必要な最小限の範囲にデータ入力・参照を限定する」はAI開発者向けの記述です。AIを業務で使う企業への公式要求として転記せず、自社がサービスを選ぶ際に提供者・開発者へ確認する観点として扱ってください。

問い合わせ・事故報告の経路を設計する

草案の条文より先に、迷ったときの問い合わせ、ルールへの指摘、例外申請、事故・ヒヤリハットの連絡先と記録先を決めます。

窓口には担当部署名だけでなく、連絡手段、一次応答する人、不在時の代替先、記録場所を設定します。利用者が「入力前に相談したい」のか、「誤った出力を社外送信した」のか、「個人情報や機密情報を入力した可能性がある」のかで、必要な対応は異なります。

事故報告はAI専用の孤立したフローにせず、既存の情報セキュリティ事故、個人情報事故、顧客対応の経路へ接続します。報告者に原因の確定まで求めると初動が遅れるため、発生・発見日時、利用サービス、対象業務、入力・出力・操作の概要、影響が及ぶ可能性のある範囲、すでに行った措置をまず記録できるようにします。

AI利用者については、利用前にログの管理体制を整えることと、利用中に適正な範囲・方法かを定期的に確認することが「AI事業者ガイドライン(第1.2版)」の別々の項目で示されています。これらを一続きの「操作履歴を定期報告する義務」と言い換えず、何を記録するかと、誰がどの機会に運用を確認するかを別々に決めます。

本文・別表・申請様式の草案を作る

変更頻度の異なる情報を本文・別表・運用様式に分け、棚卸しと区分案で決めた自社固有の条件を反映します。

公開されているひな形は、目次や論点を漏らさないための入力資料です。完成品としてコピーすると、自社では使っていないサービス名、存在しない部署、既存規程と矛盾する情報区分、運用できない承認経路が残りやすくなります。

文書 主に記載する内容 分ける理由 草案の完了条件
ルール本文 目的、適用範囲、基本原則、区分の考え方、責任、例外・報告・改定の原則 組織共通の基準として安定させる 他の規程と矛盾せず、用語と責任主体が一貫している
別表 承認サービス、アカウント条件、対象業務、情報区分、確認条件 サービスや用途の変更に追随しやすくする 棚卸し一覧と対応し、確認日と所管が分かる
早見表 通常利用、条件付き利用、禁止の具体的な利用場面 現場が業務時に判断しやすくする 各行に理由、相談先、人が確認する条件がある
例外申請様式 目的、期間、条件、リスク、低減策、承認・否認 個別判断を追跡可能にする 期限、失効、終了時判断を記録できる
問い合わせ・事故報告様式 発生状況、対象、連絡経路、初動、引継ぎ 既存の事故対応へ速やかにつなぐ 受付担当、保存先、エスカレーション先が実在する
変更履歴 変更理由、変更箇所、承認者、適用開始日、再周知 最新版の識別と説明を可能にする 旧版との違いと適用日を追跡できる

草案の完了は文章が整った時点ではなく、空欄や仮の部署名がなく、本文・別表・様式の間で承認者や用語が一致した時点です。

関係者レビューと最終承認を記録する

草案は自社の論点に必要な関係者がレビューし、指摘への対応と最終承認を後から説明できる形で残します。

現場代表は業務で守れるか、情シス・情報管理はサービス設定やデータ管理、事故対応との整合、法務・個人情報担当は契約・権利・個人情報、労務担当は就業規則や違反時対応との整合を確認します。すべての会社に同じ部署数を求めるものではありません。論点がなければ参加を省き、社内に専門家がいない論点だけ外部確認する方法もあります。

レビュー記録には、指摘箇所、指摘内容、リスク区分、反映・不採用の判断、理由、対応者、確認者を残します。口頭で合意した内容も記録へ戻し、未解決の重大な法令・契約・個人情報・機密情報の論点があれば承認へ進めません。

最終承認では、承認対象の版、適用対象、施行日、移行措置、所管者、問い合わせ先を一緒に確定します。承認日だけを残すのではなく、どの版に何を承認したのかが分かる状態を完了条件にしてください。

施行・周知・移行を完了させる

施行は、対象者が正本、早見表、申請・報告先へアクセスでき、旧運用から切り替えられた時点で完了です。

施行通知では、適用開始日、対象者、最新版の保管場所、問い合わせ先、例外申請と事故報告の入口、旧版や暫定運用の終了日を伝えます。本文を一度配布するだけでなく、別表が更新されたときも最新版を識別できるよう、版、改定日、所管者を見える位置に置きます。

移行時には、利用中サービスの継続・停止・条件変更、個人アカウントから会社管理アカウントへの切替、申請中案件の扱いなど、現場が迷う項目を決めます。一般社員向け教育の詳細やプロンプト演習は本記事の範囲外ですが、少なくとも対象者が「何が変わったか」「迷ったらどこへ聞くか」を理解できたかは確認が必要です。

施行後は、正本へのアクセス、窓口の応答、条件付き利用の確認記録、期限切れ例外、現場利用と承認サービス一覧の一致を確認します。業務削減率などの効果数値ではなく、まずルールの運用が実在しているかを確かめる段階です。

例外申請と更新責任を運用へ落とし込む

例外は申請から終了時判断まで期限付きで記録し、その蓄積を所管者がルール改定の判断へつなげます。

例外は「禁止を無条件で解除する許可」ではありません。自社裁量で設けた制限について、目的と範囲を限定し、低減策と人による確認を条件に審査する仕組みです。法令、契約、サービス規約に反する利用は、承認者が同意しても例外にはできません。

申請・審査項目 記録する内容 審査者が確認すること 終了時の扱い
申請者・目的 所属、担当者、対象業務、必要性 通常手順で代替できないか 申請者と承認者を区別する
サービス・利用範囲 サービス、アカウント、利用者、出力先 契約・設定・管理者が確認済みか 対象外の利用へ拡張しない
入力情報・操作 情報区分、外部送信・更新・確定・削除等 法令・契約・既存規程に反しないか データや権限の後処理を確認する
リスク・低減策 想定影響、確認者、照合方法、停止条件 重大な影響に人の判断が介在するか インシデントや指摘を記録へ戻す
承認条件 用途、担当者、環境、追加確認 条件が実行・確認可能か 条件未達なら失効・停止する
期限・失効 開始日、終了日、失効条件 無期限の例外になっていないか 継続、通常化、終了を判断する

同じ例外が繰り返される場合、承認作業を増やし続けるのではなく、通常利用へ移せるか、別表の条件を変えるか、禁止を維持するかを検討します。個別例外の蓄積は、ルールが現場とずれている兆候にもなります。

固定の見直し頻度をすべての会社へ当てはめる公的根拠は確認されていません。定例の確認機会は自社で決めつつ、変更が発生したときに随時改定を判断する方が実務に合います。デジタル庁の第2.0版は政府向けであり民間企業の義務ではありませんが、利活用ルールとリスクケース対応ルールを分け、所管者が最新動向や利用状況などに応じて随時改定する実装例は、民間企業が更新責任を設計する際の参考になります。

変更トリガー 確認担当 改定時の成果物 承認・再周知
サービス規約・プライバシーポリシー・契約の変更 所管者、法務・個人情報担当 影響確認、別表または本文の改定案 必要な承認を得て対象利用者へ通知
学習利用、保存、共有、外部連携等の機能・設定変更 情シス、所管者 設定確認記録、利用条件の変更 管理者と利用部門へ再周知
新しい用途・入力情報・出力先の追加 現場、所管者、必要な専門担当 区分案、確認条件、別表更新 影響度に応じた承認を記録
問い合わせ集中、例外の反復 所管者 原因整理、通常化・条件変更・禁止維持の判断 判断理由と適用日を周知
事故・ヒヤリハット 事故対応責任者、所管者 初動記録、再発防止、本文・様式の改定案 既存事故対応と接続し、変更点を通知
法令・公的ガイドライン・社内規程の変更 法務、所管者 適用範囲の確認、整合修正 最終承認者が改定版を承認

変更があっても本文を直す必要がない場合は、「変更不要」とした理由と確認日を記録します。改定する場合は、所管者が起票し、関係者レビュー、最終承認、変更履歴、適用開始、再周知までを一つの工程として完了させます。

よくある質問

生成AIの社内ルール作りで迷いやすい、ひな形、所管者、見直し、例外の考え方を簡潔に整理します。

Q1. 雛形をそのまま使ってよいですか?

そのまま完成品として使うのは避けてください。対象者、利用サービス、用途、入力情報、出力先、既存規程・契約、問い合わせ先、例外承認者を自社用に置き換え、本文・別表・様式の整合をレビューします。ひな形は論点を集めるための入力資料です。

Q2. 専任AI部門がない場合、誰を所管者にすべきですか?

経営企画、情シス、総務など、正本管理と関係者調整を継続できる部署・担当者を所管者にします。公的資料は具体的な部署名や人数を指定していません。兼務する場合も、草案作成者、例外申請者、最終承認者は記録上で区別します。

Q3. 社内ルールはどのタイミングで見直しますか?

自社で定例の確認機会を決めるとともに、契約・設定・機能・用途・入力データ・事故・法令や公的ガイドラインの変更があった時点で改定要否を判断します。四半期、半年、年次などを全企業共通の公式頻度として扱わないことが重要です。

Q4. 禁止事項に例外を設けてもよいですか?

自社裁量で設けた制限には、用途、担当者、条件、期限、低減策、承認者、失効を定めた例外審査を設けられます。ただし、法令、契約、サービス規約に反する利用は社内承認で解除できません。終了時には継続・通常化・終了を判断します。

まとめ

生成AIの社内ルールは、担当者、入力、成果物、承認、例外、改定責任がつながって初めて運用できます。

経営承認と所管を決め、利用実態と既存規程・契約を棚卸しし、利用区分と人が判断する条件を作ります。その結果を本文・別表・申請様式へ分け、関係者レビュー、最終承認、施行、例外運用、変更トリガーに応じた改定まで記録してください。完成物はルール本文だけではなく、承認記録、例外記録、事故報告、変更履歴を含む一式です。

参考資料

本記事が参照した公式資料は次のとおりです。

START WITH THE RIGHT PROBLEM

AIで何ができるか、ではなく
どの業務から変えるか。

30分の無料相談で、現在の課題、最初に検証する業務、必要な支援の形を整理します。

AI顧問AI検索最適化AI研修・講演AIコンサルAIエージェント開発
30分無料相談を予約する 相談後、必要な場合だけ次の有料提案をご案内します。
PAGE TOP