生成AI利用ルールを3か月ごとに見直すチェックリスト

生成AIの利用ルールを作った後、実際の使い方と条文がずれていませんか。今回は既存ルール、匿名化した利用記録、確認済みの仕様変更をAIで照合し、「どの条項をどう見直す候補にするか」を表へ整理します。完成する成果物は条項別の改訂候補表と、人が確かめる未確認事項の一覧です。3か月という間隔は運用の提案であり、法令上の一律の期限ではありません。

準備する資料と入力できる範囲

現行ルールは社内で承認された最新版から入手し、版番号、確認日、条項IDを記録します。利用記録は担当者が保管している記録から対象期間分を抜き出します。記録がない場合は担当者へ「使った機能・確認した手順・困った点」を聞き、事実として確かめられた項目だけを記入します。AIに社内の利用履歴を勝手に探してもらう手順ではありません。

仕様変更は提供元の公式ヘルプや発表を人が読み、URL、確認日、適用対象、確認できた内容を短く書きます。噂や別契約の条件は混ぜず、未確認なら未確認と表示してください。顧客名、社員名、メールアドレス、契約額、社内URL、認証情報、案件固有の説明は除きます。人物を役割名に置き換えるだけで本人を特定できる場合は、該当行を渡さない方法を選びます。

使う条文自体に機密が含まれる場合も、承認された公開可能な抜粋だけにします。省いた部分は「非提供」と記録し、AIが補完できるとは考えません。判断に必要な資料を出せない項目は、担当者が原資料を見て処理する欄へ残します。

利用環境を確認してテキストで渡す

例としてパソコンのブラウザ版Geminiを使います。会社が利用を認めたアカウントでGeminiを開き、利用条件とデータ設定を確認してから新しいチャットの入力欄へ文章を貼り付けます。今回の作業にファイルアップロード、外部サービスとの接続、社内資料へのアクセス許可は必要ありません。資料の抽出と業務文書への反映は人が行います。

個人アカウントと職場・学校アカウントでは適用される取扱いが異なるため、会社が定めた環境に従ってください。Googleの説明では一時チャットなどでも安全性のため一定期間の保持があり、設定だけで機密情報を入れてよいと判断することはできません。本手順は入力してよいと確認した情報に限定します。利用できる機能や表示が説明と違うときは、現行ヘルプと管理者の設定を確認します。

書き換える箇所が分かる入力テンプレート

角括弧の部分を自社の確認済み情報へ置き換えます。実名を入れず、条項と記録にIDを付けてください。原文、事実、意見を分けることで、出力を元の資料と照合できます。

対象期間：[開始日〜終了日]
現行版：[版番号／確認日]
ルール：
R1｜原文：[公開可能な条項の原文]
R2｜原文：[公開可能な条項の原文]
利用記録：
U1｜関連条項：[R番号]｜確認済みの事実：[実施した手順]｜困った点：[事実と意見を分ける]
仕様変更：
S1｜対象製品・契約：[確認した適用対象]｜確認日：[日付]｜公式URL：[URL]｜確認できた内容：[短い要約]
非提供・未確認：[抜粋から除いた資料／まだ調べていない事項]

コピーして使えるプロンプトと架空例

あなたは利用ルールの改訂候補を整理する補助者です。
以下の入力だけを根拠に、条項別の改訂候補表を作ってください。
列：条項ID／現行原文／根拠ID／不一致または不足／改訂候補文／人が確かめる事項／判定（候補・変更不要・保留）。
入力の事実と意見を区別し、根拠のない変更を作らないでください。
仕様が未確認なら断定せず保留にしてください。非提供の資料を読んだとは言わないでください。
法律の適合判断や承認はしないでください。最後に不足資料を列挙してください。
以下が入力です：
[上のテンプレートに記入した内容をここへ貼り付ける]

以下はすべて架空例です。実際の顧客や社内運用を示すものではありません。

現行版：架空の第1版
R1｜原文：公開する回答は担当者が確認する。
R2｜原文：確認済みのデータ設定を利用記録に残す。
U1｜関連条項：R1｜事実：担当者が原資料と照合して公開した。｜困った点：なし。
U2｜関連条項：R2｜事実：設定を確認したが確認日を記録しなかった。｜困った点：後から確認時点が分からなかった。
仕様変更：なし（この例では新機能の仕様は入力しない）。
未確認：他部門の記録は非提供。

期待する出力の形（編集者が作成した架空例）

条項	根拠	候補と判定	人の確認
R1	U1	入力した範囲では変更不要	他部門まで同じ運用かは未確認
R2	U2	設定の確認日も記録する案を候補にする	記録欄の管理者と運用負担を確認

この表はGeminiを実操作して得た回答の転載ではありません。入力と根拠IDを照合できる出力形式の例です。モデルや入力によって結果は変わり、同じ回答になる保証はありません。

回答が合わないときは根拠単位で直す

根拠IDがない候補には「根拠のない行を保留にし、不足資料を示してください」と追加します。条項の原文が変わっていたら「現行原文は入力から一字ずつそのまま写してください」と指示します。過度に細かい案が出たら「U2の不足だけを扱い、新しい承認段階や製品を追加しないでください」と範囲を絞ります。

操作上は入力したプロンプトを編集して更新する方法も公式ヘルプで案内されています。ただし、修正しても根拠がない判断が続く行は人が処理します。AIの文体の自然さより、R・U・SのIDが原資料へ戻れることを優先してください。情報を追加する際は毎回機密や個人情報が残っていないか確認します。

原資料と照合し承認後に業務へ反映する

1. 現行原文を承認済みルールと照合し、根拠IDを利用記録へ戻って確認する。
2. 仕様に関わる候補は対象の製品・契約・確認日の公式情報を再確認する。
3. 採用・不採用・保留と理由を人が記録し、承認者へ候補表を渡す。
4. 承認された変更だけをルールの改訂版へ反映し、版番号と適用日を付ける。
5. 該当担当者へ変更点を伝え、旧版の参照先を更新する。
6. 次の対象業務で新しい記録欄が使えるか試し、記録漏れと負担を確認する。

架空例のR2を採用した場合は、確認日欄を追加した利用記録を一件記入して、後から誰が見ても時点が分かるか確認します。周知メールを送っただけで完了にせず、実際の記録が残るところまで見ます。AIは改訂候補の整理を助けますが、承認、文書の配布、業務上の実行を自動で済ませる手順ではありません。

出典：Geminiアプリを使用する、Geminiアプリのプライバシーハブ。

LIFESEEDSでは島田市の中小企業に向けて、業務と情報の整理を支援しています。AI活用・業務効率化支援をご確認いただき、課題の整理はお問い合わせからご相談ください。