社内規程をChatGPTで検索、Firstup MCPに残る3つの制限
仕事の未来 4
生成AIの社内ルール、禁止事項だけでは現場が止まる
生成AIの社内ルールは、禁止する情報だけでなく、どの業務にどのツールを使え、誰が出力と対外利用を承認するかまで定める。公開済み資料の要約まで許されるのか分からなければ、社員は作業のたびに確認を待つことになる。迷ったときの相談先と、未承認の使い方を申請する経路も必要だ。
土台になるのは、AIの利用者にも基本的な取組を示す総務省・経済産業省の「AI事業者ガイドライン」だ。内閣府の指針一覧は、これを開発・提供・利用を担う事業者向けの基本的な考え方として掲載している。社内ではその原則を、使う前の判断、使った後の確認、問題が起きたときの報告へ置き換える。
まず利用できる経路を確定する
最初に、業務で認めるツールとアカウントを一覧にする。各項目には利用できる部署と用途、入力可能な情報の区分、管理者、申請先を付ける。ツール名だけを載せても、個人契約と会社契約で条件が違えば社員は判断できない。情報システム担当は契約条件、保存先、学習への利用、管理設定を確認し、業務責任者はその用途を認めるか決める。
利用環境によって入力条件が変わる例もある。東京都の生成AI利用の手引きは、検証済みの庁内共通ツールでは機密性の高い情報を扱える一方、別に調達した庁内環境では入力を認めない場合があると示している。これは都の環境についての扱いであり、企業が自社のツールに同じ許可を広げる根拠にはならない。自社の情報区分と利用環境を組み合わせて条件を決める必要がある。
未承認ツールを使いたい場合は、申請者が用途と扱う情報を示し、情報システム担当がサービスの条件を評価し、業務責任者が用途を承認する流れにする。審査中に試す必要があるなら、公開情報や架空データなど、担当部署が認めた範囲を指定する。禁止事項だけを配るより、承認までの道筋を示した方が、社員は業務を止めずに相談できる。
そのまま記入できる社内規程の骨格
以下の記入欄は、規程本文と承認済みツール一覧をつなぐための骨格だ。Uravationの条文例にも、人による最終判断、機密情報の入力制限、出力検証、承認ツール、事故対応が含まれる。空欄には部署名だけでなく、社員が実際に連絡できる窓口や一覧の所在まで記入する。
- 目的：「当社は［対象業務］で生成AIを［下書き・要約・発想支援など］に利用する。業務上の最終判断は［役職または担当者］が行う」と記す。自動生成した内容をそのまま会社の判断として扱わない範囲を明らかにする。
- 対象者：「本規程は［社員・派遣社員・業務委託先など］に適用する」と書く。委託先も対象にするなら、契約や発注条件との整合を確認し、問い合わせ窓口を知らせる。
- 利用可能ツール：「業務利用は［承認済みツール一覧の所在］に載る［会社管理アカウントなど］に限る。新規ツールは［申請先］が評価し、［承認者］が用途ごとに決める」とする。ツールの追加後は一覧にも反映する。
- 入力禁止情報：「［対象環境］には［顧客の個人情報、契約上の秘密、認証情報、未公表の人事・財務情報など］を入力しない」と区分する。例外を設けるなら、対象データを扱える環境、必要性、事前承認者を明記する。
- 出力検証：「利用者は数字、固有名詞、引用、法令に関する記述を元資料で確認し、確認できない内容は使用しない」と定める。コード、画像、専門的な助言には、それぞれの用途に応じた確認担当を加える。
- 対外利用：「顧客への送付や公開の前に［業務責任者］が内容と権利関係を確認する」と書く。AI利用の表示が取引条件や社内方針で必要なら、その判断者と表示方法も定める。
- 事故報告：「誤入力、情報漏えいの疑い、誤った内容の送付を認識した者は、利用を止めて［連絡先］へ速やかに報告する」とする。使用ツール、入力した情報、送付先、発見時刻を伝える形式にしておく。
- 改訂責任者：「［主管部署・責任者］が［見直し周期］ごとに規程と承認済みツール一覧を確認する」と定める。事故、契約変更、サービス設定の変更があれば、定期見直しを待たずに扱いを再判定する。
入力と公開では確認する人を分ける
入力前に確かめるのは、情報の持ち主、機密区分、利用環境の条件だ。公開済みの製品説明から文章案を作る場合と、顧客名簿を含む問い合わせ履歴を要約する場合では、同じ文章作成でも判断が異なる。後者を伏せ字にしても、取引内容や属性の組み合わせで相手を推測できるなら十分とはいえない。不要な項目を除くか、その情報を扱えると確認済みの環境と承認手続きに切り替える。
出力後は、作成者が元資料に照らして事実を確認する。生成AIがもっともらしい数字や引用元を示しても、資料にその記載があるかを確かめる。社内メモなら作成者の確認で足りる場合もあるが、顧客向けの提案書では価格や契約条件を担当者が照合し、業務責任者が送付を承認する、というように用途で段階を分ける。
対外公開する画像や文章では、正確さに加えて既存作品との類似や権利関係を確認する。疑義があれば公開を保留し、法務や制作の担当者へ回す。確認項目を決める際には、公開前の類似性確認も対象になる。「社員各自が確認する」だけでは、公開の可否を決める人が残らないため、規程には確認者と承認者を別々に書く。
業務例で許可と申請の境界を示す
規程には、社員が日常業務に引き寄せて判断できる例を添える。次は条件付きの例であり、実際の可否は自社の承認済みツール、契約、情報区分によって決める。
- 公開済み情報から研修の構成案を作る：承認済みツールを使い、非公開情報を混ぜなければ利用できる扱いにする。教材として使う前に、作成者が事実関係を確認する。
- 顧客名を含む問い合わせ履歴を要約する：その情報を扱えない環境には入力しない。対応可能と確認済みの環境がある場合も、必要性とアクセス権を確かめ、指定の承認を受ける。
- AIが作った提案文を顧客へ送る：下書きの作成と送付の承認を分ける。担当者が根拠、価格、条件を元資料と照合し、業務責任者が対外利用を決める。
- 未承認のサービスを試す：業務情報を入力する前に申請する。評価中に使える情報の種類とアカウントは、担当部署が指定する。
営業、採用、開発など自社の業務に置き換えたとき、条件が判断できない例には申請先と承認者を追記する。同じ用途の相談が続くなら、個別の例外を積み重ねるだけでなく、扱える情報と環境の条件を一覧に反映する。
事故報告と改訂を運用に組み込む
誤って情報を入力した人が、すぐに報告できる窓口を用意する。社員向けの規程には、まず利用を止め、どこへ何を知らせるかを簡潔に書く。報告を受けた担当部署は入力内容、使用ツール、共有範囲、残っているデータを確認し、必要に応じて管理者への連絡や社内の情報管理手続きへ進める。誤送付なら、送付先と送付済みの内容も初動判断に必要となる。
改訂責任者は、規程本文と承認済みツール一覧を一緒に管理する。新機能や契約条件の変更があれば、以前の承認を別の用途へ自動的に広げず、入力条件を確認し直す。現場からの申請、出力確認で見つかった問題、事故報告を次の改訂に反映させれば、安全に使える経路を実際の業務に合わせて保てる。
関連記事：
関連記事
ニュースレターを購読
Web3、AI、暗号資産の最新ニュースを受信箱にお届けします。
0