生成AIの社内ルールの作り方｜禁止・承認・更新まで

生成AIの社内ルールは、利用目的と承認済みサービスを決め、入力情報を「禁止・条件付き許可・許可」に分けて作る。さらに、操作の承認、出力確認、事故報告、例外申請、更新責任を記し、社員が業務中に判断できる形にする。

IPAサイトに掲載された卒業プロジェクトの導入・運用ガイドラインは、利用ルールの策定・文書化とリスクマトリクスによる管理を扱う。これは執筆メンバーの見解であり、IPAの公式見解を代表する文書ではない。自社の規程では、用途ごとに扱う情報と影響を見積もり、誰が判断するかまで具体化する。

対象業務と責任者を先に決める

承認する単位はサービス名だけでなく、「誰が、どの機能で、何をするか」まで含める。文章の下書き、社内資料の要約、コードの補助などを業務別に登録し、利用者、入力する情報、出力の利用先を添える。同じサービスでも、下書きの作成と外部システムへの接続では、必要な権限と承認者が変わる。

IPAサイトに掲載された生成AIとAIエージェントの実務手引書は、全社的な管理、導入から廃棄までの流れ、情報漏洩や権限外の操作など7種類の発生被害、対策後の残存リスクを整理している。これも中核人材育成プログラムの卒業プロジェクトによる資料だ。社内では、導入時の審査担当だけでなく、機能や用途が変わったときに再判定する担当も置く。

担当欄には部署名だけでなく、決裁できる役職または窓口、不在時の代行先を記入する。分担例は次のとおり。

経営・事業責任者：利用目的、対外利用の範囲、対策後に残るリスクを受け入れるかを決める。
情報システム・セキュリティ担当：サービスの契約条件、アクセス権限、ログ、外部連携、利用停止の方法を確認する。
法務・個人情報保護担当：個人情報、守秘義務、成果物の権利に関わる条件を確認する。
利用部門の管理者と利用者：用途を申請し、入力前の区分判定と出力後の確認を行う。

入力情報を禁止・条件付き許可・許可に分ける

個人情報保護委員会の注意喚起を踏まえ、公開情報と個人データで生成AIへの入力判断を分ける

個人情報を含む入力は、社内で一括して許可しない。個人情報保護委員会の生成AI利用時の注意喚起は、個人情報を入力する目的が特定済みの利用目的に必要な範囲か確認し、本人の同意なく個人データを入力する場合には、提供者が応答以外の目的で扱わないか、機械学習への利用の有無などを十分に確かめるよう求めている。条件を確認できなければ、社内の承認済みサービスでも送信を保留する。

以下は社内運用のひな型であり、法令が定めた区分ではない。自社の情報管理規程とサービスの契約条件に合わせ、本文への貼り付けだけでなく、添付ファイル、参照先、会話履歴に残る内容にも適用する。

禁止：未承認サービスへの業務情報の入力、パスワードや秘密鍵の入力、契約で外部提供を禁じられた情報の入力。取扱条件を確認できない個人データも、確認が終わるまで入力しない。
条件付き許可：社内資料や業務上必要な個人データなど。承認済みサービスに限定し、必要な項目へ絞ったうえで、利用目的、提供者による利用、保存とアクセス権限を担当者が確認する。確認の結果、入力を認めない場合もある。
許可：公開済みの情報、架空の例文、識別できる情報を含まない一般的な文章案などを、承認された用途と機能の範囲で使う。

たとえば顧客への返信文なら、架空の状況で言い回しを整える作業は「許可」にできる。実際の問い合わせ本文を使う場合は、氏名を消しても文脈から本人を識別できないか確認し、必要なら「条件付き許可」の判断に回す。運用表では利用目的と学習利用の確認を別々の欄にすると、片方だけ確かめて送信することを防ぎやすい。

下書きと外部への実行で承認境界を変える

入力が許可されても、生成AIに任せる操作は別に線引きする。承認済みの用途で下書きを作る行為と、顧客への送信、公開、社内データの更新、外部サービスへの接続では、影響を受ける相手も取り消しやすさも異なる。規程には、閲覧・下書き・実行を分け、事前承認が必要になる地点を書く。

ひな型では、下書きの作成を利用者の判断に任せ、社外への送信や公開は内容の責任者が承認する。顧客データの一括取得、システム設定の変更、支払いを伴う処理をAIに実行させるなら、機能を有効にする前に情報システム担当と事業責任者が審査する。承認記録には、サービスと機能、対象データ、実行者、許可する操作、停止方法を残す。

出力確認も用途に合わせる。利用者は原文や一次資料との一致、数字と固有名詞、権利に関わる素材、個人情報の混入を確かめる。顧客向け文書や公開物では利用部門の責任者が最終版を確認し、確認した版と実際に送った版を追えるようにする。AIの回答をそのまま対外的な事実認定や約束にしないための境界である。

事故報告と例外申請の経路を用意する

禁止情報の誤入力、未承認サービスの利用、権限外の操作、誤った出力の社外利用に気づいたときの報告先を、利用開始前に決める。利用者には追加の入力や送信を止め、指定窓口へ連絡するよう伝える。個人データが関係する報告は、情報システム・セキュリティ担当から法務・個人情報保護担当にも直ちに渡せる経路にする。

報告欄には発見時刻、利用したサービスとアカウント、情報の種類、実行済みの操作、公開・送信の状態、影響を受けた可能性のある相手を設ける。ログの保全、相手への連絡、法令に基づく報告の要否は担当部門が判断する。利用者が自己判断で履歴を消したり、相手への説明を始めたりしないよう、初動の役割を明示しておく。

通常の区分では扱えない用途には例外申請の入口を設ける。申請者は必要性、使う情報、代替手段、利用者、期間、想定される影響を記し、情報システムと法務の確認を経て事業責任者が判断する。認める場合は対象と期限を限定する。繰り返し認める例外は、次の規程改定で通常の区分に移せるか検討する。

配布用ひな型に担当欄と更新条件を入れる

社員向けの本文には判断の原則を置き、サービス別の設定や承認者一覧は更新しやすい別表にする。次の空欄を埋めれば、利用者は作業前の判断と、迷ったときの連絡先を同じ規程で確認できる。

適用範囲：対象部署［　］、対象者［　］、承認済みサービスと機能［　］、利用目的［　］。
入力区分：禁止情報［　］、条件付き許可の情報［　］と承認者［　］、許可情報［　］。添付と参照先にも同じ区分を適用する。
操作の境界：利用者だけで行える操作［　］、事前承認が必要な操作［　］、承認記録の保管先［　］。
出力確認：用途別の確認項目［　］、対外利用の最終承認者［　］、確認記録の保管先［　］。
事故対応：報告窓口［　］、連絡方法［　］、利用者が直ちに止める操作［　］、担当部門への引継ぎ先［　］。
例外と更新：例外申請先［　］、承認者［　］、有効期限［　］、規程の管理者［　］、定期見直しの時期［　］。

規程の管理者は、承認済みサービスの機能と契約条件、社内の利用実態、事故や相談の内容を定期的に確認する。外部連携の追加、扱う情報の変更、重大な事故、公的指針や関連法令の改定があれば、定期見直しを待たずに該当する区分と承認手順を更新する。改定日、変更箇所、承認者、社員への周知方法を記録し、旧版のまま判断されないようにする。